On Thu, Nov 20, 2025 at 05:22:30PM +0100, Jerome Forissier wrote: > > > On 11/20/25 17:06, Tom Rini wrote: > > On Thu, Nov 20, 2025 at 04:51:46PM +0100, Jerome Forissier wrote: > >> Hi Tom, > >> > >> On 11/18/25 22:00, Tom Rini wrote: > >>> This adds the Pine64+ platform to the sage lab, for both legacy and lwIP > >>> networking stacks. In order to build this platform we need to copy > >>> certain files that were built in the container to /tmp and then set > >>> BINMAN_INDIRS to /tmp in order to find them when building. > >>> > >>> For now, we disable the test_net_pxe_boot_config test on lwIP as it > >>> leads to a crash that needs to be investigated. > >>> > >>> Signed-off-by: Tom Rini <[email protected]> > >>> --- > >>> Cc: Andre Przywara <[email protected]> > >>> Cc: Jerome Forissier <[email protected]> > >>> > >>> Andre, Jerome, how would you like to handle looking in to this issue? > >>> https://source.denx.de/u-boot/u-boot/-/jobs/1303375#L2235 shows the > >>> crash and I don't have enough sunxi targets to know if this is more > >>> broadly breakable or not. But it doesn't happen on lwIP + Pi for > >>> example, nor lwIP + Hummingboard (mx6cuboxi defconfig). I can't at this > >>> point give remote access to the lab directly, but I can help come up > >>> with a gitlab job that'll acquire the board, build and try and boot > >>> whatever you have. > >> > >> Well the crash dump doesn't tell much on its own, except that we have > >> an invalid read at address 0x17. But we do have the ELR so it would be > >> helpful to have the u-boot.elf file. Could it be made available as a job > >> artifact, especially in case of failure (or always)? > > > > We do not have a literal 'u-boot.elf' in this case, but we do have the > > full u-boot file gdb can read for example, would that help? > > Let me check... > > $ make pine64_plus_defconfig > [...] > $ make -j$(nproc) CROSS_COMPILE="ccache aarch64-linux-gnu-" > [...] > $ file u-boot > u-boot: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically > linked, with debug_info, not stripped > > So yes, it would definitely help locate the instruction causing the crash. > What would be even better is if we could enable a stack dump on exception, > but is that available in U-Boot?
We have something I believe, yes. However, this particular platform is fairly constrained, I can't enable as much additional testing as I usually do as SPL chokes on memory and I haven't dug at the memory map enough to see if SPL can have more space. > > Given that > > we expire artifacts after a week, this is probably OK, or maybe a > > commented out section for "To debug things, add ..." if I don't see how > > to only save it on failures (there are options to do specific actions on > > failures, but, need to look in to it). > > Yeah. Whatever allows to have an image file when we need to troubleshoot a > crash would be great. Will do. I'll point you off-list to an updated failure job to see if it's got everything you'd like. -- Tom
signature.asc
Description: PGP signature
