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

[Jerome Forissier]

On 11/20/25 17:27, Tom Rini wrote:
> 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.

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

Excellent, thanks!

-- 
Jerome