Hi Sasha,
On 4/17/20 9:15 PM, Jevtic, Sasha wrote:
[Previous message to list canceled; resending with added detail]
Harald,
To be clear, the language I used was to imply *only* that I observed this problem as recently as the latest release; none over the earlier builds I have prepared for RPi4 worked better. The reference to other hardware and older U-Boot was simply intended to suggest that the network infrastructure, notably including the DHCP and TFTP servers, have been proven to work with U-Boot.
Moreover, I would like to point out that I am chain loading U-Boot from the RPi4 firmware via TFTP. This could be a significant point since the RPi4 firmware will have clearly already have initialized the Ethernet hardware previously.
Could you try this with a u-boot booted from the SD card, so that we can see if the problem happens there as well?
Regards, Matthias
Thanks.
Sasha
-----Original Message----- From: Harald Seiler hws@denx.de Sent: Friday, April 17, 2020 4:12 AM To: Jevtic, Sasha sasha.jevtic@continental-corporation.com; u-boot@lists.denx.de Cc: Matthias Brugger mbrugger@suse.com Subject: Re: Network functionality in v2020.04 on Raspberry Pi 4
Hello Sasha,
adding Matthias Brugger on Cc as he is the maintainer for Raspberry Pi.
On Thu, 2020-04-16 at 20:25 +0000, Jevtic, Sasha wrote:
Hello all,
I am encountering considerable difficulty with the networking functionality on Raspberry Pi 4 on the latest release (2020.04). In particular, I have observed:
* any network operation that fails renders networking functionality inoperable until reboot. * ping always fails. * TFTP download attempt of non-existent file fails (resulting in subsequent network operations failing). * TFTP download of an existing file usually works, but occasionally experiences timeouts during transfers; some are timeouts are intermittent (the transfer ultimately resumes), and some are permanent. * TFTP download of a script usually works (as above). The script will run, but any additional TFTP downloads performed by a script all fail.It is not entirely clear right now whether this is a problem in U-Boot (i.e., instead of in the execution environment set up by the Raspberry Pi firmware), but the TFTP infrastructure I am using is known to work well with other hardware running an older version of U-Boot. Also, there are also no network issues in the Linux environment that I ultimately boot, so hardware also seems unlikely. Thus, suggestions for things to check would be appreciated; I am of course also happy to provide any supporting data required to investigate.
If you have know which older version still worked, you can use git-bisect [1] to find out where the regression was introduced. Ideally, if you can automate installation of a newly built U-Boot version, this can run entirely unattended to find out where the bug was introduced.
Please also be aware that I initially posted a very similar inquiry to the Raspberry Pi Forum:
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=271068
Thanks.
Sasha
-- Harald