Hi Alex,
I added this delay 1 second idea on the u-boot version v2015.01 and did the
power on / off test on BBB. I did 263 board boot up. Among them 254 times
Ethernet interface successfully started up. The other 9 times the u-boot
just could not detect Phy. Below is the u-boot log comparison between a
successful boot and a (Ethernet) bad boot -
Successful one:
U-Boot 2015.01-dirty (Feb 13 2015 - 00:46:39)
Watchdog enabled
I2C: ready
DRAM: 512 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment
Net: <ethaddr> not set. Validating first E-fuse MAC
cpsw
Hit any key to stop autoboot: 0
gpio: pin 53 (gpio 53) value is 1
switch to partitions #0, OK
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
Checking for: /uEnv.txt ...
Checking for: /boot.scr ...
Checking for: /boot/boot.scr ...
Checking for: /boot/uEnv.txt ...
......
Bad boot:
U-Boot 2015.01-dirty (Feb 13 2015 - 00:46:39)
Watchdog enabled
I2C: ready
DRAM: 512 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment
Net: <ethaddr> not set. Validating first E-fuse MAC
Phy 0 not found
cpsw
Hit any key to stop autoboot: 0
gpio: pin 53 (gpio 53) value is 1
switch to partitions #0, OK
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
Checking for: /uEnv.txt ...
Checking for: /boot.scr ...
Checking for: /boot/boot.scr ...
Checking for: /boot/uEnv.txt ...
......
Note the "Phy 0 not found" line shown in the bad log.
So unfortunately this idea does not work here. The Ethernet failure rate is
about the same with or without this 1-second delay added or not. The hunt
has to go on...
John Zhang
On Thursday, February 5, 2015 at 10:16:55 AM UTC-8, [email protected]
wrote:
>
> Hello everybody,
>
> After I and my colleagues had fruitlessly tried many things, our hardware
> developer came up with a working solution: delaying the PHY initialization
> performed by the U-Boot we use (v2014.10, git checksum
> c43fd23cf619856b0763a64a6a3bcf3663058c49). This ensured that U-Boot code
> tried to access LAN8710A only after this chip had come out of reset. So,
> inserting "udelay(1000000);" at the beginning of "board_eth_init()"
> function in board/ti/am335x/board.c and recompiling U-Boot worked in our
> experiments.
>
> We haven't yet done many experiments, but at least the board, whose PHY
> failed almost every time before, always starts successfully now. I would
> appreciate if you repeat this experiment with the delayed PHY
> initialization and report the results here.
>
> I guess the problem was, as described in the reply from Texas Instruments
> mentioned
> by Micka
> <https://groups.google.com/d/msg/beagleboard/9mctrG26Mc8/2aova_Jd__EJ> (I
> misunderstood that earlier), that LAN8710A starts to function correctly at
> a slightly higher voltage level than the microprocessor, and may come out
> of reset too late with respect to the microprocessor. This agrees with the
> observation that a higher capacity on nRESET_INOUT only worsens things,
> because it makes the slope of the reset pulse more flat, thus increasing
> the time lag between the starts of the two chips.
>
> @ c2h2: Thank you for your reply. As far as I understand, you delayed the
> reset of the microprocessor with respect to the reset of LAN8710A by means
> of some RC circuit, right? If this is correct, could you please provide
> more details about that circuit?
>
> @ Vince Caldeira: Could you please explain, why you marked the topic as
> complete? If you know any better solution of the problem, please share that
> with us.
>
> Regards,
>
> Alex
>
>
>>>>>>
--
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/d/optout.
