Custom U-Boot and Kernel for Custom Board

Joe,

Here is what I would go through to bring your board up and running:

1. Bypass the EEPROM check in Beagleboard image(https://beagleboard.org/latest-images) by following the instructions here and boot the board:

https://octavosystems.com/forums/topic/osd3358-boot/#post-4733

2. Program the EEPROM by grounding the EEPROM_WP of the OSD335x-SM to boot standard beagle images. There are a couple of ways of doing this. You can boot patched Linux image from sdtep 1 and use the SYSFS interface to write the ID to EEPROM directly. You can also use the I2C commands in u-boot to program the EEPROM: http://beagleboneblack.blogspot.com/2016/01/bbb-magic-number-programming.html.

3. Use the device tree rebuilder(https://github.com/RobertCNelson/dtb-rebuilder) to modify the RED board device tree source files(https://github.com/octavosystems/OSD335x-Device-Tree) to reflect the hardware on your board and compile it to .dtb. This is the kernel device tree. You should more than likely not have to modify the u-boot device tree.

4. Place the custom .dtb file in /boot/dtbs/[Kernel Version]/ and modify dtb variable in /boot/uEnv.txt to your custom device tree file

Your board should boot up with the custom device tree at this point and you should be able to start integrating your software. Make sure you can access your SD card offline through a host computer so you can iterate the device tree modifications easily.

You should not have to modify u-boot in order to boot the board. If you want to, you can use a u-boot overlay to customize the boot(https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays). Here is a repository of overlays: https://github.com/beagleboard/bb.org-overlays .If you see strange behavior in u-boot, it may be  because u-boot prefers to boot Linux from the MMC0 interface and this may result in some things not working as they do in the standard beagle image configuration. In this case you have to modify some u-boot config files to work around this.

Dear Neeraj Dantu,

I have reopen this thread because I am working again in this project and I am not able to bring up the Ethernet. After check the design files with Martin, it seems that there are not HW issue related because the Ethernet part is exactly the same that in the OSD red board. Lets me explain the current situation and the testing done.

As you know, I am using a custom board which is practically the same that the OSD3358 SM red board, but with some peripherals removed. The schematics, signal and layout related with the Ethernet part are exactly the same that the red board. This part has been checked with Octavo HW.

First of all, I have bypassed the eeprom ID check building a u-boot to do it. After that, I have write the ID in the EEPROM with the u-boot commands. You can see in this screenshot that they are correctly written.

After that I have used the reference image from octavo webpage (OSD3358-SM-RED-Custom-Debian-9.1-lxqt-09-19-2017-1.1.img). So that it means that the u-boot is not hard-coded to bypass the EEPROM. It boot correctly, but the Ethernet does not work.

Some points to take in mind:

• When I plug the Ethernet wire in the board connector and PC or router, it does not light.
• Although I have configured a static IP in the interfaces file, the board does not get it from the beginning. But when I do ifdown and ifup eth0, the IP is correctly assigned.
• With the DHCH and connected the board to a router, it does not get any IP.
• In my PC, every time I see the message that a device was disconnected and after that connected.
• The Atheros PHY driver is correctly detected. As you can see in the attached log, the board is able to get the MAC address.
• I have tested the Ethernet wire in others boards, and it works correctly. So the issue is not caused by the wire.

Could you please help me to answer the following questions?

1. My main guess about the root cause is that is caused because the Ethernet PHY mode is not correctly configured. As far as I know, the OSD red board should use the RGMII instead of the MII which is used for the Beaglebone. But in the u-boot log, I see that the eth0 mode is MII. Could you please confirm it?
2. After by pass the EEPROM and write the ID number in the u-boot, using the OSD3358 red board image that you provided me, the u-boot should detect the board as Beaglebone and model OSD3358 red board and it implies configure the PHY in RGMII mode?
3. Which is the correct ID for the OSD-red-board: “BNLT” or “BBNR”? I have try with both, with the same results (Ethernet does not work) but the u-boot detected different model of board.
4. Please lets me know a way to debug deeply the PHY Ethernet configuration
   • Are there some file descriptor to check the status?
   • Is possible check in the Linux which pins related with the PHY have been configured?

Attached you can find the EEPROM ID values, u-boot log and kernel log. As you can see, in this case the model is not detected correctly. But if I use the u-boot to by pass the EEPROM, the board is detected correctly.  The logs are related with these images, the same board and the same EEPROM ID:

1. u-boot.txt and kernel.txt. With the osd-red-board image (without uboot by pass).
2. u-boot_Bypassed.txt and kernel_Bypassed.txt: with the beaglebone image and the checked EEPROM ID hard-coded in the board.c file.

Thanks a lot.

Olmo,

Here are some inputs on your questions:

1. The Beagle U-Boot does not setup ethernet well. This does not effect the kernel configuration though. I would suggest you follow the below procedure to get Ethernet working in U-Boot:

2. Yes, EEPROM ID is responsible for selecting the device tree with which the board will boot. We would suggest you try the RED board image linked here: https://octavosystems.com/octavo_products/osd3358-sm-red/#Software as it has been verified to be working with the RED. Also note that your PHY address would also have to match the RED board in order for it to work.

3. The EEPROM ID is bypassed in OSD3358-SM-RED image and device tree is selected using /boot/uEnv.txt (dtb=). On Beagle images RED board ID ends with OS00. Note that latest Beagle images have not been verified to work on the RED board.

4. The kernel log you have attached does not show all the kernel messages. Output of dmesg command could give us better understanding of what is going on. We suggest the following steps as to debug:

– Use the OSD3358-SM-RED image to boot the board and look at ethernet related logs in the output of dmesg

– Use the above procedure(in #1) to fix U-boot and get Ethernet to work in U-Boot. This procedure has been verified to be working on the RED board.

Besst,

Neeraj