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>) 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> 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, -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
