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

Jerome Forissier jerome.forissier at linaro.org
Thu Nov 20 17:22:30 CET 2025



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?

> 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.

Thanks,
-- 
Jerome


More information about the U-Boot mailing list