Hi Tom, On Wed, 30 Apr 2025 at 08:15, Tom Rini <tr...@konsulko.com> wrote: > > On Wed, Apr 30, 2025 at 07:54:46AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Tue, 29 Apr 2025 at 16:32, Marcel Ziswiler > > <marcel.ziswi...@codethink.co.uk> wrote: > > > > > > Hi Jerome > > > > > > On Fri, 2025-04-04 at 15:50 +0200, Jerome Forissier wrote: > > > > This series replaces the dynamic initcalls (with function pointers) with > > > > static calls, and gets rid of initcall_run_list(), init_sequence_f, > > > > init_sequence_f_r and init_sequence_r. This makes the code simpler and > > > > the > > > > binary slighlty smaller: -2281 bytes/-0.21 % with LTO enabled and -510 > > > > bytes/-0.05 % with LTO disabled (xilinx_zynqmp_kria_defconfig). > > > > > > > > Execution time doesn't seem to change noticeably. There is no impact on > > > > the SPL. > > > > > > > > The inline assembly fixes, although they look unrelated, are triggered > > > > on some platforms with LTO enabled. For example: kirkwood_defconfig. > > > > > > > > CI: > > > > https://source.denx.de/u-boot/custodians/u-boot-net/-/pipelines/25514 > > > > > > This series seems to cause a regression on rock5b. E.g. on today's master: > > > > > > => pci enum > > > => setenv ipaddr 192.168.10.2 > > > => ping 192.168.10.1 > > > failed to initialize card: -12 > > > failed to initialize card: -12 > > > failed to initialize card: -12 > > > failed to initialize card: -12 > > > failed to initialize card: -12 > > > failed to initialize card: -12 > > > failed to initialize card: -12 > > > failed to initialize card: -12 > > > No ethernet found. > > > failed to initialize card: -12 > > > failed to initialize card: -12 > > > ping failed; host 192.168.10.1 is not alive > > > > > > Seems the rtl8169 driver runs out of memory trying to allocate > > > descriptors? > > > > > > If I revert this series on top of today's master: > > > > > > => pci enum > > > => setenv ipaddr 192.168.10.2 > > > => ping 192.168.10.1 > > > > > > Warning: eth_rtl8169 MAC addresses don't match: > > > Address in DT is 00:e0:4c:68:01:5a > > > Address in environment is fe:b1:db:60:25:69 > > > Using eth_rtl8169 device > > > host 192.168.10.1 is alive > > > > > > I just completed the bisection and will now look into what exactly could > > > be going on. > > > > > > Any insights are much appreciated. > > > > > > Thanks! > > > > I have one of these boards in my lab. Could you please apply the > > pending lab patches, e.g. [1]? Also, can we get this board running > > network tests? > > Your lab patches sadly stopped applying, I think somewhere around where > you didn't comment on my feedback about needing to fix problems with how > modern i.MX platforms do/don't handle blobs, and also the "all" make > target.
I believe it was when you didn't want to disable boards which don't work (e.g. samus). Still, any conflicts are trivial, so perhaps just apply them? Regards, SImon
