[PATCH v2 3/4] Gitlab: sage: Add Pine64+ platform

[Tom Rini]

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 <trini at konsulko.com>
> >>> ---
> >>> Cc: Andre Przywara <andre.przywara at arm.com>
> >>> Cc: Jerome Forissier <jerome.forissier at linaro.org>
> >>>
> >>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20251120/48f372c5/attachment.sig>