KeOu,
I made the connections you described and powered the board up, but still
had that "phy not found", 7 times out of 10.
Also, I did another interesting experiment: in U-Boot, I manually changed
the PHY address of the transceiver to 2, after it had started successfully
with the address 0 ("mdio write 0 18 0xe2"). Then I restarted the CPU by
the U-Boot command "reset" and noticed that the network works anyway, with
PHY address 2, both in U-Boot and when Linux runs, although U-Boot shows
the message "Phy not found" and fails to list MDIO buses (i.e. shows "0 -
Generic PHY <--> cpsw" instead of the expected "2 - SMSC LAN8710/LAN8720
<--> cpsw" after running the command "mdio list").
So, that means that a "nonstandard" PHY address of a transceiver alone is
not a problem, it is totally acceptable to the CPU, and I was wrong when I
said <https://groups.google.com/d/msg/beagleboard/9mctrG26Mc8/RCYIJK687YAJ>
that this patch
<https://groups.google.com/d/msg/beagleboard/9mctrG26Mc8/SRlnumt0LoMJ>
doesn't work. There is some difference between this "non-zero address case"
and the case when the network really doesn't work. In the latter case the
transceiver not only has a wrong PHY address (which wouldn't be a problem
alone), but also remains in some "unhealthy" state, that could be changed
only by the reset signal on the nRST.
Regards
Alex
On Thursday, December 11, 2014 4:48:09 PM UTC+1, KeOu Chao wrote:
>
> Alex,
>
> This is very interesting; in your case, the debug connection did not make
> any difference. Assuming there is a difference on the TTL connection, can
> you try (c), with patch between GPIO and debug port. In my case, with this
> patch, I do not see any ethernet failure.
>
> P9 1 (GND) to J1 (serial GND)
> P9 3 (VDD_V3V) to J4 (serial RXD)
> P9 4 (VDD_V3V) to J5 (serial TXD)
>
> Without debug port connection, I just run ping from terminal continuously;
> the successful response shows Ethernet come up after power cycle.
>
> These were discussion on the TI e2e forum, this seems to be the same issue
> we have here
> Phy Address Issue beaglebone U-boot - Sitara Processors Forum - Sitara™
> Processors - TI E2E Community
> <http://e2e.ti.com/support/arm/sitara_arm/f/791/t/366351>
>
> Regards
>
> KeOu
>
> On Dec 9, 2014, at 3:40 PM, [email protected] <javascript:> wrote:
>
> KeOu,
>
> Thank you for the data. It looks like "phy not found" does not happen
> very often with your boards.
>
> I also run that "update_kernel.sh" to update the kernel to 3.8.13-bone68.
> And I tried 3.14.22-ti-r31 too, and had a lot of "phy not found" in this
> case as well. In all my experiments the console port was always connected
> to a PC.
>
> Regards
>
> Alex
>
> On Tuesday, December 9, 2014 6:10:37 PM UTC+1, KeOu Chao wrote:
>>
>> Alex,
>>
>> I did more testing by using a remote power switch; using 3 BBBs with 3
>> different Kernel, no modification on U-Boot, Kernel.
>>
>> - 3.8.13-bone47 - that came with the board
>> - 3.8.13-bone68 - upgrade via on board script
>> /opt/scripts/tools/update_kerenl.sh
>> - 3.14.22-ti-r31 - download from run-ee.net
>>
>> My test scripts turn power switch wait for 50 seconds, send TCP SYN
>> request per second for 5 times, if no ACK received, declare Failure; then
>> power off for 5 seconds, repeat.
>>
>> One thing I found is that with Console port connected, there was no
>> failure on all my tests (other then bone47). Do you have console port
>> connect when testing ?
>>
>> This is my test results, each test has 600 power cycles,
>>
>> Test 1 Test 2 Test 3 Test 4
>> 3.8.13-bone47 50 8.33% (a) 46 7.76% (a) 41 6.83% (a) 40 6.67% (b)
>> 3.8.13-bone68 20 3.33% (a) 0 0% (b) 0 0% (b) 21 3.5% (a)
>> 3.14.22-ti-r31 0 0% (b) 27 4.5% (a) 0 0% (c) 24 4% (a)
>>
>> (a) no console connected
>> (b) with console connected
>> (c) with patch - DGGND to console GND, VDD_3V3 to Console Tx, VDD_3V3 to
>> Console Rx.
>>
>> I just start looking into this, and have not digest all the notes /
>> manual yet; Hope the information help.
>>
>> Regards
>>
>> KeOu
>>
>>
>> Hi KeOu,
>>
>> I guess with 3.8.13-bone67 I had "phy not found" as frequently as with
>> the original image. On one board with 3.8.13-bone67, I had just one
>> occurrence of "phy not found" in 50 power-on resets. On the other board
>> with the same kernel I had 22 "phy not found" out of 50 power-on resets.
>> Then I updated the kernel to 3.8.13-bone68, and still had that error, 12
>> times out of 50 power-on resets.
>>
>> To perform that kernel update, I followed the instructions from the error
>> message that showed up after I attempted to run "install-me.sh" from
>> http://rcn-ee.net/deb/wheezy-armhf/v3.8.13-bone68/ Could you please
>> describe in more detail what prebuilt image you tried and how exactly you
>> installed that? Did you also install some other U-Boot?
>>
>> Some time ago, I installed and tried one of the rcn-ee.net images
>> following a procedure similar to that described here
>> <http://www.armhf.com/boards/beaglebone-black/bbb-sd-install/>. But it
>> didn't help.
>>
>> There is one important thing to remember: "phy not found" happens before
>> autoboot in U-Boot, and if that happens, no matter which Linux is loaded
>> afterwards - the transceiver chip doesn't work properly. So, both
>> 3.8.13-bone67 and 3.8.13-bone68 fail to detect the chip, if it wasn't
>> detected by U-Boot.
>>
>> Regards,
>> Alex
>>
>> On Saturday, December 6, 2014 5:59:56 PM UTC+1, [email protected] wrote:
>>>
>>> Hi Alex,
>>>
>>> In past couple days, I went through the same path as you did. However,
>>> with my limited tests, I see improvement on 3.8.13-bone68. I have BBB Rev C
>>> from Element14 with a generic 5V 2.8A switch power supplier.
>>>
>>> - with 3.8.13-bone47 (the original image) power cycle 50 times, there
>>> were 2 "phy not found"
>>> - with 3.8.13-bone68 (prebuild image from http://rcn-ee.net/, power
>>> cycle 50 times, there were no "phy not found"
>>> I also tested 3.14.22-ti-r31, power cycle 50 time, and no "phy not
>>> found".
>>>
>>> I'll do more test to see if the issue show up. In you tests, did you see
>>> any improvement in 3.8.13-bone67 vs earlier version ?
>>>
>>> Thanks
>>>
>>> KeOu
>>
>>
>>
>
--
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.
