I’m working with a board based around the Beaglebone Black, and I’m having some issues surrounding U-Boot. One difference between my board and the shipped BBB is the Ethernet PHY used; the BBB’s PHY has a default address of ‘0’, whereas the PHY I’m replacing it with (TI TLK105) has an address of ‘1’. I’ve been working off the demo images for Angstrom up until now, but this means that my PHY isn’t being detected. I haven’t looked into the board file enough to know what’s really going on, but I’m guessing that the PHY address is hard-coded into U-Boot, and if U-Boot can’t find the PHY then you’re out of luck.
I tried to correct this by compiling U-Boot myself. I did a bit of research into PHY configuration in U-Boot and I made a few modifications. I added #define CONFIG_CMD_MII to the include/configs/am335x_evm.h file. Once I built and deployed my compiled U-Boot, mii was a listed command and mii info 1 confirmed that there was a PHY at that address.
I also added #define CONFIG_PHY_ADDR 1 and hoped that this would change the default PHY address and everything else would take care of itself, but this didn’t really happen. When I was using the pre-compiled U-Boot binaries, it reported:
Net: not set. Validating first E-fuse MAC
Phy not found
PHY reset timed out
After my modifications, I got the following:
Net: not set. Validating first E-fuse MAC
Could not read the EEPROM; something fundamentally wrong on the I2C bus.
Could not get Board ID, assuming BeagleBone Black.
Could not get PHY for cpsw: addr 0
I don’t really understand why the nature of the PHY error would change so much. Any help with getting my PHY up and running would be appreciated, or at least some confirmation that I’m going about this the right way.
I built U-Boot using this guide with the addition of this patch to deal with some EEPROM issues I’m having. There is an EEPROM on the board, but right now it doesn’t have the correct BBB data written to it. The weird thing is, the demo U-Boot images are able to read the EEPROM (reporting 0xFFFFFF as its contents) while my modified U-Boot image cannot even use the I2C bus. The hardware is identical, and if I jump back and forth between the two U-Boot images, only the pre-compiled one is able to read my EEPROM. It seems like there is some difference between the configuration of the demo U-Boot images and the ones I’ve built from source, but I can’t find any documentation regarding the demo images so I have no idea what they might be. Are the sources for the images available? Since my uEnv.txt file is blank, once U-Boot loads it just hangs and waits for me to tell it what to do. The uEnv.txt file in the demo image is also blank, but U-Boot does some configuration and loads the kernel. I’m guessing that this is hard-coded into the compiled U-Boot that’s used, but it would be nice to have it as a reference so I could eventually implement the same behavior myself. I know that the demo image boots near-perfectly on my board, so being able to add PHY support to that source would be much easier than adding PHY support to the original U-Boot source and then guess every modification made for the demo images. Implementing this stuff myself is a useful learning experience and everything, but I feel like I’m reinventing the wheel since I already had a working image to begin with.
Thanks