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: <ethaddr> not set. Validating first E-fuse MAC*
> *Phy not found*
> *PHY reset timed out*
>

After my modifications, I got the following:


>
>
>
> *Net: <ethaddr> not set. Validating first E-fuse MACCould 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<http://eewiki.net/display/linuxonarm/BeagleBone+Black>with the addition 
of this 
patch<https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2013.10/0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.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

-- 
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