Beaglebone Black Clone Device Tree Problems

GoogleGroups
1

Hey guys,

I’m working on a project which is using a clone of the BBB hardware and I’m running into some issues with Device Trees. I wasn’t involved with the hardware design, but as far as I know, the BBB hardware has been duplicated exactly. Specifically, the clone board will be directly connected to an LCD using the LCD data pins on the AM335x. I’ve never worked with Device Trees before, but after some initial research (mostly based on this summary) I’m thinking that they are the best way to accomplish what I’m looking for (enabling the LCD pins and configuring the driver to use them). I’m not concerned about the details of implementing this right now, since I’m having issues with Device Trees in general that I need to address first.

The board is booting from an SD card with two partitions: one for U-boot and one for the Angstrom (v2012.12 with 3.8.13 kernel) image, both of which are the standard images which ship with the Beaglebone. I’m not having problems getting the board to boot. It has no problem running U-boot and it can start Linux without any catastrophic failures using the default images. Once Linux boots, if I go to /sys/devices/bone_capemgr.8, there are all the files you’d find on a regular BBB except slots and the slots-* files. As far as I know, without these files I can’t add or modify device trees for the board. I still could by rebuilding the kernel I suppose, but as far as I know this is a deprecated approach.

Here’s a pastebin showing the serial output of the clone while it boots

I only have a basic understanding of U-Boot, so the output during the boot sequence doesn’t help me to much, but here are the main things I’ve noticed while skimming through it:

  1. Right at the start of the SPL process, the magic number check in EEPROM fails. This makes sense since the cloned board has a blank EEPROM. I’m not sure if this is a problem, but the assumption in the next lines (Beaglebone LT/Black.musb-hdrc) seem to work. The board is able to get past the SPL stage so I’d figure that this assumption is accurate enough.

  2. The main U-Boot process also checks the EEPROM and fails the ID check. There is no reassuring message this time (“Assuming Beaglebone” or something to that effect) so I’m not sure if this is a larger problem.

  3. The PHY initialization fails. The only hardware difference I know of between the clone and the BBB is the PHY, so this isn’t very surprising. I’m pretty sure the PHY uses a different address so I’ll deal with this when it becomes an issue.

  4. The uEnv.txt is being read. I originally thought this might have been a problem, but if I modify uEnv.txt U-boot reports the correct file size. In this example I’m just using the default one though.

  5. U-boot mentions the device tree addresses, but I don’t know if there is any significance to this.

  6. While booting the kernel, U-boot throws some bone-capemgr errors relating to the EEPROM. This makes me think that the EEPROM failure might be messing up the device tree configuration through bone-capemgr but I’m not sure. There are also some GPIO mux errors but I’m not sure that they really matter for my problems right now.

That’s all I’ve got right now. As I said, this is my first time working with anything related to the BBB and I don’t really have any experience with U-Boot, so unfortunately I’m mostly relying on support from you guys at this point. If you need any more information just let me know.

Thanks,

2

Hey guys,

I'm working on a project which is using a clone of the BBB hardware and
I'm running into some issues with Device Trees. I wasn't involved with the
hardware design, but as far as I know, the BBB hardware has been duplicated
exactly. Specifically, the clone board will be directly connected to an LCD
using the LCD data pins on the AM335x. I've never worked with Device Trees
before, but after some initial research (mostly based on this summary<http://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/overview&gt;\)
I'm thinking that they are the best way to accomplish what I'm looking for
(enabling the LCD pins and configuring the driver to use them). I'm not
concerned about the details of implementing this right now, since I'm
having issues with Device Trees in general that I need to address first.

The board is booting from an SD card with two partitions: one for U-boot
and one for the Angstrom (v2012.12 with 3.8.13 kernel) image, both of which
are the standard images which ship with the Beaglebone. I'm not having
problems getting the board to boot. It has no problem running U-boot and it
can start Linux without any catastrophic failures using the default images.
Once Linux boots, if I go to /sys/devices/bone_capemgr.8, there are all the
files you'd find on a regular BBB *except *slots and the slots-* files.
As far as I know, without these files I can't add or modify device trees
for the board. I still could by rebuilding the kernel I suppose, but as far
as I know this is a deprecated approach.

Here's a pastebin showing the serial output of the clone while it boots<http://pastebin.com/ZBmatVgk&gt;

I only have a basic understanding of U-Boot, so the output during the boot
sequence doesn't help me to much, but here are the main things I've noticed
while skimming through it:

1. Right at the start of the SPL process, the magic number check in EEPROM
fails. This makes sense since the cloned board has a blank EEPROM. I'm not
sure if this is a problem, but the assumption in the next lines (Beaglebone
LT/Black.musb-hdrc) seem to work. The board is able to get past the SPL
stage so I'd figure that this assumption is accurate enough.

There are some rather basic configuration components that require board
detection to work. I suggest you hard-code it in the SPL/u-boot or program
the EEPROM.

3

hacking the kernel to pretend EEPROM contains my board id

diff --git a/arch/arm/mach-omap2/board-am335xevm.c b/arch/arm/mach-omap2/board-am335xevm.c
index 3f17cf8…aad2738 100644
— a/arch/arm/mach-omap2/board-am335xevm.c
+++ b/arch/arm/mach-omap2/board-am335xevm.c
@@ -4287,13 +4287,21 @@ static void am335x_evm_setup(struct memory_accessor *mem_acc, void *context)
if (ret != sizeof(config)) {
pr_err(“AM335X EVM config read fail, read %d bytes\n”, ret);
pr_err(“This likely means that there either is no/or a failed EEPROM\n”);

  • goto out;
  • //goto out;
  • {
  • char ar[] = {0xaa, 0x55, 0x33, 0xee, ‘A’, ‘3’, ‘3’, ‘5’, ‘U’, ‘S’, ‘O’, ‘M’, 0};
  • memcpy((char *)&config, (char *)&ar, sizeof(ar));
  • }
    }

if ((config.header != AM335X_EEPROM_HEADER) && (config.header != BONEA2_EEPROM_HEADER)) {
pr_err(“AM335X: wrong header 0x%x, expected 0x%x\n”,
config.header, AM335X_EEPROM_HEADER);

  • goto out;
  • //goto out;
  • {
  • char ar[] = {0xaa, 0x55, 0x33, 0xee, ‘A’, ‘3’, ‘3’, ‘5’, ‘U’, ‘S’, ‘O’, ‘M’, 0};
  • memcpy((char *)&config, (char *)&ar, sizeof(ar));
  • }
    }

/*

4

Thanks for the replies guys. I don’t seem to have the board-am335xevm.c file in my kernel sources (grabbing them this way or this way) so I can’t really make the appropriate modifications. I’ve found the board file online, but is there a specific kernel source I should use that already includes that file? And if I download the file and make the appropriate modifications, will the kernel build process even do anything? I’m guessing I would need to specify am335xevm as the target or something to that effect? I’ve never built the Linux kernel before so this is all pretty new to me.

Thanks,

5

If it truly is a 100% clone of the BeagleBone Black with just a blank
eeprom.. Disable the write protect on that eeprom and boot with this
flasher image:

http://rcn-ee.net/deb/testing/2014-02-18/BBB-blank-eMMC-flasher-debian-7.4-2014-02-18-2gb.img.xz

However if it is not a 100% clone do not use that.

Regards,

6

Thanks for the advice…but I just found out that there actually is no EEPROM on the board at this point. I’m not sure why the guy who did the hardware neglected to mention this earlier, but I can’t do much for now other than work around it.

If I do make the kernel modifications to avoid the EEPROM check, will there be any other complications if an EEPROM isn’t available? This is a pretty big change and I’m not sure if the BBB relies on the EEPROM for anything else.