Hey guys, I’m currently working on a project using a hardware replica of 
the Beaglebone Black, and I’m running into some issues with U-Boot and 
Device Trees. I haven’t been involved with the hardware side of the board 
(which I’ll affectionately call the Beagleclone from here on out) but I’ve 
been assured that the hardware is *identical *to what’s on the BBB except 
for a changed Ethernet PHY and different headers and such. 

Right now the Beagleclone is booting from an SD card with both U-Boot 
(2013.04-dirty) and Angstrom Linux (v2012.12 with the 3.8.13 kernel) as 
they’re packaged with the BBB. I’ve made various modifications to U-Boot 
while trying to prove some of this stuff out, but all of the information in 
my post is using the default BBB U-Boot/Angstrom files. 

When I boot the Beagleclone, U-Boot goes through its process without any 
major issues and Angstrom Linux starts. The problem is that I’d like to 
connect a simple TFT LCD display to the Beagleclone using the LCD pins on 
the AM335x. As far as I know this is possible, but the pins/driver need to 
be configured to make this happen. I’ve never worked with BBB before, but 
some quick research has indicated that Device Trees are the best way to 
implement this.

The Beagleclone does not seem to have the Device Tree slots that are 
necessary to accomplish this. The documentation I’ve seen on Device Trees 
and the BBB (mostly this 
guide<http://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/overview>)
 
suggest that there should be a /sys/devices/bone_capemgr*/slots file which 
stores the present Device Tree configuration and allows for modifications. 
Once my Beagleclone boots into Linux, I can navigate to the 
/sys/devices/bone_capemgr* directory, but there is no slots file in the 
directory. There are the normal subdirectories in the folder as well, with 
no directories for the specific slots entries, which makes sense given that 
the file doesn’t exist. Since this file doesn’t exist, I don’t really know 
if it’s possible to use Device Trees to change the hardware configuration.  
I’ve 
also tried modifying uEnv.txt to add Device Trees while booting, but I 
haven’t had any success with this either. Since I can’t even get the slots 
file to show up I thought I’d try to tackle that first. 

Here's the serial output I get when booting the 
Beagleclone<http://pastebin.com/ZBmatVgk>

Since I have no experience with the BBB and I’m not all that familiar with 
U-Boot, the output linked above isn’t exactly enlightening for me, but here 
are the main things I noticed:

1. U-Boot SPL fails to identify the Beagleclone as a BBB since its ID isn’t 
stored in EEPROM. It seems like U-Boot immediately assumes that the board 
is a BBB and continues on. I’m not 100% sure that this isn’t an issue, but 
I’d imagine an SPL failure would stop the system from booting into Linux so 
I doubt that this is causing the issue.

2. U-Boot also fails to identify the Beagleclone. There is no reassuring 
message this time about assuming the board is a BBB, but since SPL assumes 
I’m using “Black.musb-hdrc” and  U-boot refers to “musb-hdrc” after the ID 
failure, I’m going to guess that the assumption made by SPL carries over to 
the main U-Boot process. 

3. The Ethernet PHY initialization fails. I’m using a different PHY with a 
different address from the BBB PHY so this isn’t very surprising.

4. uEnv.txt is being read properly. I’m using the default BBB environment 
right now, but as I made modifications to uEnv.txt, this status output 
reflected the size of my modified uEnv.txt. I originally thought U-Boot 
might be ignoring my uEnv.txt file but it’s definitely reading it even if 
its contents aren’t doing anything when I change them.

5. When the kernel is booted, bone_capemgr throws a few errors because of 
the EEPROM ID failure. This seems like the most likely cause of my problem 
(since it involves bone_capemgr directly) but I’m not sure if this would 
stop me from using the slots file. U-Boot seems to be able to assume the 
Beagleclone is a BBB, but does the kernel *need *the ID to work? I could 
try writing the ID to EEPROM using U-Boot to accomplish this I guess, but 
I’m not sure what the ID is and where I should write it. 

6. There are also some kernel errors regarding GPIO pinmuxing. I’ll look 
into this later but I’m pretty confident that this isn’t holding me back.

That’s all the information I have. I really have no idea where to go from 
here. As I said, I’m not experienced with any of this stuff so I’m really 
just hoping that somebody here can help me figure this out. 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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to