Ethernet timeout

[arrmo]

Hi,

 

Trying to get the latest U-Boot working on my ESPRESSObin board - a v5, DDR3, 1 GB, 1cs version. I have no issues flashing it, and tftpbooting ... with the "old" supplied U-Boot. But wanting to run a recent version of OpenWrt on the board, so trying to update U-Boot.

 

I flashed the latest version of U-Boot for it ... U-Boot comes up fine (I have serial access), but - ethernet seems to have an issue (for tftpboot, or even ping), I get,

 

=> ping 192.168.2.1
(NULL udevice *): mvneta_setup_txqs: can't create txq=0
Using ethernet@30000 device
timeout: packet not sent
timeout: packet not sent
timeout: packet not sent
timeout: packet not sent

 

I can go back to the old U-Boot (circa 2017), and it works again (flashing from USB). But ... has anyone seen the issue above? And of course, any fixes? 

 

Thanks!

[Igor]

15 hours ago, arrmo said:

flashed the latest version of U-Boot for it ... U-Boot comes up fine

 

Its not uncommon and is highly possible that network drivers were not ported to modern u-boot. Or they are just not enabled? We switched to the modern u-boot about a year ago and lack of this functionality does not bother us.

[arrmo]

OK, that makes sense, thanks! But, to understand ... 

13 hours ago, Igor said:

lack of this functionality does not bother us

But this is needed for tftp boot, right? OK without that?

 

Thanks!

[Igor]

5 hours ago, arrmo said:

But this is needed for tftp boot, right?

Yes. 

[arrmo]

OK, NP - just trying to understand. I would have thought that's a core thing, but I could be wrong (obviously ).

 

Thanks!

 

[Igor]

7 hours ago, arrmo said:

just trying to understand

 

NP. Happy to clarify. 

 

It took us and other projects and people several years turning this board of electronics into something usable. Out of, lets say, 1000 hours of our private time we lost dealing with HW and frustrated users, few minutes were compensated by users donations, not a second by people that were selling you this HW. And people remain unsatisfied (vendor does not communicate with you for a very long time) as not every feature works in upstream code and it probably never will. With time, features can going to break anyway if not well maintained ...

 

If this is a core thing for you, you can try to add it. Use our SDK, which will save you several weeks on the top of the code that was already cleaned and improved by community. All this is top notch compared to the "SDK" shipped by vendor(s) (its hard to imagine what kind of shit software support was shipped by vendor). Then start working on it. This is how things go. Perhaps this feature is already developed by someone (similar hardware can have same driver), just not shipped upstream or driver exists, just need enabling, adjustment of config, timings. Again - going this path is something normal in this world.

[arrmo]

Fully understand, thanks for the detailed answer!

[Pali]

On 8/27/2022 at 9:51 PM, arrmo said:

But wanting to run a recent version of OpenWrt

 

Use upstream U-Boot and not some OpenWRT fork which was broken.

 

And after upgrading reset env variables to default and beware to not erase mac address of network controller (stored in env too).

 

Armbian boot scripts explicitly erased mac address which lead to your U-Boot errors.

 

Recent upstream U-Boot from this year used to work without any issues on Espressobin v5.

[arrmo]

Will check this out, thanks!

[Igor]

On 9/11/2022 at 3:07 PM, Pali said:

Armbian boot scripts explicitly erased mac address which lead to your U-Boot errors.

Can you point to that boot script?

 

On 9/11/2022 at 3:07 PM, Pali said:

Recent upstream U-Boot from this year used to work without any issues on Espressobin v5.

https://github.com/armbian/build/blob/master/config/sources/families/mvebu64.conf#L3

[ManoftheSea]

On 9/11/2022 at 9:07 AM, Pali said:

Armbian boot scripts explicitly erased mac address which lead to your U-Boot errors

This is no longer true.

In the u-boot environment, it is possible to set the `ethaddr` (eth0) and `eth[1,2,3]addr` variables (wan, lan0, lan1) to long-term set the MAC address of these ports.  I understand Pali as saying these variables need to be set for tftpboot to work.