malta: increase SYS_MALLOC_F_LEN and SYS_MALLOC_LEN
If CONFIG_CONSOLE_RECORD_INIT_F=y we need additional memory according to
CONFIG_CONSOLE_RECORD_OUT_SIZE_F. Similarly CONFIG_SYS_MALLOC_LEN must be
increased by CONSOLE_RECORD_OUT_SIZE.
Go with the default values for CONFIG_CONSOLE_RECORD_INIT_F and
CONFIG_SYS_MALLOC_LEN.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
We invoke the ut command in test_ut.py. Currently we only check for
failures. Instead we should also indicate if sub-tests were skipped.
With this change we will get output like the following for skipped tests:
test/py/tests/test_ut.py ..sssss......ss..............s.sssss.s.s...
================================ short test summary info ================================
SKIPPED [1] test/py/tests/test_ut.py:597: Test addrmap addrmap_test_basic has 1 skipped sub-test(s).
SKIPPED [1] test/py/tests/test_ut.py:597: Test bdinfo bdinfo_test_eth has 4 skipped sub-test(s).
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
_ update LED management for STMicroelectronics boards
_ Add 1 GiB DRAM support for STM32MP13x DHCOR SoM
_ Fix 512 MiB DRAM support for STM32MP13x DHCOR SoM
_ Fix handling OPTEE in middle of the DRAM
_ Add missing debug UART build for STM32MP1 DHSOM
Patrice Chotard [Fri, 14 Nov 2025 16:23:55 +0000 (17:23 +0100)]
ARM: dts: stm32: Drop "u-boot-led" and "error-led" from stm32mp157c-ed1-u-boot
Remove obsolete properties "u-boot, u-boot-led" and "u-boot,error-led"
from stm32mp157cf-ed1-u-boot.dtsi.
Remove led-red and led-blue nodes which are available in kernel DT.
See kernel series: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=1022570
Patrice Chotard [Fri, 14 Nov 2025 16:23:54 +0000 (17:23 +0100)]
ARM: dts: stm32: Drop "u-boot-led" and "error-led" from stm32mp157c-ed1-scmi-u-boot
Remove obsolete properties "u-boot, u-boot-led" and "u-boot,error-led"
from stm32mp157c-ed1-scmi-u-boot.dtsi.
Remove led-red and led-blue nodes which are available in kernel DT.
See kernel series: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=1022570
Patrice Chotard [Fri, 14 Nov 2025 16:23:36 +0000 (17:23 +0100)]
board: st: Update LED management for stm32mp1
Remove get_led() and setup_led() which became obsolete since
led_boot_on() introduction. led_boot_on() is automatically called
from board_r.c
Regarding "u-boot,error-led" property can't be used anymore since commit
Since commit 516a13e8db32 ("led: update LED boot/activity to new property implementation")
Instead get the LED labeled "red:status".
See kernel series: https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=1022570
Marek Vasut [Tue, 18 Nov 2025 23:17:23 +0000 (00:17 +0100)]
ARM: stm32: Add missing build of debug UART init code on DH STM32MP1 DHSOM
Commit c37a6684818d ("stm32mp: fix compilation issue with DEBUG_UART")
split the debug UART initialization code into two files, but failed to
update other non-ST boards. This did not lead to noticeable breakage
until debug UART is enabled, which is not the default. Update the
Makefile accordingly to allow debug UART to work.
Fixes: c37a6684818d ("stm32mp: fix compilation issue with DEBUG_UART") Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Tue, 18 Nov 2025 23:19:36 +0000 (00:19 +0100)]
ARM: dts: stm32: Add 1 GiB DRAM settings for DH STM32MP13xx DHCOR SoM
Add DRAM settings for 1 GiB variant of DH STM32MP13xx DHCOR SoM
and support for SoM DRAM coding HW straps decoding and automatic
DRAM configuration selection. Enable CONFIG_BOARD_EARLY_INIT_F on
all STM32MP1 DHSOM, as it is required for the HW straps decoding.
Signed-off-by: Marek Vasut <marek.vasut@mailbox.org> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Tue, 18 Nov 2025 23:17:14 +0000 (00:17 +0100)]
stm32mp: Fix handling of OPTEE in the middle of DRAM
STM32MP13xx may have OPTEE-OS at 0xdd000000 even on systems with 1 GiB
of DRAM at 0xc0000000, which is not the end of DRAM anymore. This puts
the OPTEE-OS in the middle of DRAM. Currently, the code sets RAM top to
0xdd000000 and prevents the DRAM range past OPTEE at 0xe0000000..0xffffffff
from being set as cacheable and from being usable. The code also sets the
area over OPTEE as invalid region in MMU tables, which is not correct.
Adjust the code such, that it only ever sets RAM top just before OPTEE
in case the OPTEE is really at the end of DRAM, mainly to be backward
compatible. Furthermore, adjust the MMU table configuration such, that
the regions over the OPTEE are simply skipped and not reconfigured, and
the regions between end of OPTEE and RAM top are set as cacheable, if
any actually exist.
Tom Rini [Wed, 19 Nov 2025 14:55:41 +0000 (08:55 -0600)]
vexpress_aemv8: Stop disabling device tree relocation
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Tom Rini [Wed, 19 Nov 2025 14:55:33 +0000 (08:55 -0600)]
pcm052: Stop disabling device tree relocation
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Tom Rini [Wed, 19 Nov 2025 14:55:32 +0000 (08:55 -0600)]
omap3_evm: Stop disabling device tree relocation
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Tom Rini [Wed, 19 Nov 2025 14:55:27 +0000 (08:55 -0600)]
hikey960: Stop disabling device tree relocation
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Tom Rini [Wed, 19 Nov 2025 14:55:25 +0000 (08:55 -0600)]
hikey: Stop disabling device tree relocation
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Tom Rini [Wed, 19 Nov 2025 14:55:22 +0000 (08:55 -0600)]
bcmstb: Make use of bootm_size rather than fdt_high
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS. However, this platform also has a large comment
block that explains that given previous stage loaders and other parts of
the memory map (that may not be in the device tree we see?), adjust this
to use bootm_size to restrict relocation to be below the CMA area and
update the comment to match.
Tom Rini [Wed, 19 Nov 2025 14:55:20 +0000 (08:55 -0600)]
am335x_shc: Stop disabling device tree relocation
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Reviewed-by: Heiko Schocher <hs@nabladev.com> Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Wed, 19 Nov 2025 14:55:17 +0000 (08:55 -0600)]
qemu-arm-sba: Stop disabling device tree relocation
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Tom Rini [Tue, 18 Nov 2025 14:26:40 +0000 (08:26 -0600)]
adi: Stop disabling device tree relocation
Remove setting of fdt_high to ~0, which disables device tree relocation,
from the default environment. Doing so prevents U-Boot from correcting
problems such as having an unaligned device tree and leads to various
failure modes in the OS.
Tested-by: Greg Malysa <malysagreg@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com>
Tom Rini [Tue, 2 Dec 2025 21:20:33 +0000 (15:20 -0600)]
boot/image-fit.c: Use aligned_alloc(...) not memalign(...)
With the changes in commit 8fbcc0e0e839 ("boot: Assure FDT is always at
8-byte aligned address") to call memalign(...) we now always call
memalign(...) rather than malloc(...) when allocating a buffer that may
contain a device tree. However, memalign(...) is not portable among all
of the host OSes we support. The C11 standard does require that
aligned_alloc(...) exist and it takes the same parameters as
memalign(...) does. Change this file to call aligned_alloc rather than
memalign, and for the non-USE_HOSTCC case define that function back to
memalign.
Fixes: 8fbcc0e0e839 ("boot: Assure FDT is always at 8-byte aligned address") Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Tom Rini <trini@konsulko.com>
Maksim Kiselev [Fri, 29 Aug 2025 08:25:00 +0000 (11:25 +0300)]
clk: Only enable the parent clock if the clock was enabled before reparenting
The current implementation of clk_set_parent() unconditionally enables
the new parent clock, even if the target clock was not previously enabled.
To avoid this implicit behavior, this patch adds a check for whether
the target clock has been enabled before parent enabling..
Fixes: ac30d90f336 ("clk: Ensure the parent clocks are enabled while reparenting") Signed-off-by: Maksim Kiselev <bigunclemax@gmail.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tom Rini [Thu, 4 Dec 2025 15:39:11 +0000 (09:39 -0600)]
Merge patch series "Add support for SM3 secure hash"
Heiko Schocher <hs@nabladev.com> says:
Add SM3 secure hash, as specified by OSCCA GM/T 0004-2012 SM3 and described
at https://datatracker.ietf.org/doc/html/draft-sca-cfrg-sm3-02
TPMv2 defines hash algo sm3_256, which is currently
not supported and prevented TPMv2 chip with newer
firmware to work with U-Boot. Seen this on a ST33TPHF2XI2C
u-boot=> tpm2 init
u-boot=> tpm2 autostart
tpm2_get_pcr_info: too many pcrs: 5
Error: -90
u-boot=>
Heiko Schocher [Tue, 18 Nov 2025 04:30:38 +0000 (05:30 +0100)]
lib: import sm3 256 hash parts from linux
Implement SM3_256 Hash algorithm, based on
linux commit f83a4f2a4d8c: ("Merge tag 'erofs-for-6.17-rc6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs")
Tom Rini [Thu, 4 Dec 2025 15:38:46 +0000 (09:38 -0600)]
Merge patch series "clk: Fix some error detection"
Andrew Goodbody <andrew.goodbody@linaro.org> says:
The function clk_get_rate() returns a ulong with 0 meaning an invalid
clock rate and also negative error codes being returned for other
errors. But being an unsigned return value this cannot simply be tested
for with a < 0 test. Instead use the IS_ERR_VALUE() macro to check for
negative errors appearing as very large positive values. Fix those
places that test for <= 0. Also fix some places checking the return of
clk_register() that incorrectly used ERR_PTR().
Andrew Goodbody [Tue, 21 Oct 2025 16:08:30 +0000 (17:08 +0100)]
timer: imx-gpt: Fix error detection
Testing an unisgned ivariable to be <= 0 will only detect the
case when it is 0. So correct this error test to a working version that
will behave as expected.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Andrew Goodbody [Tue, 21 Oct 2025 16:08:29 +0000 (17:08 +0100)]
i2c: imx_lpi2c: Fix error detection
Testing an unisgned ivariable to be <= 0 will only detect the
case when it is 0. So correct this error test to a working version that
will behave as expected.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Heiko Schocher <hs@nabladev.com>
Andrew Goodbody [Tue, 21 Oct 2025 16:08:28 +0000 (17:08 +0100)]
i2c: npcm: Fix error detection
Testing an unisgned member of a struct to be <= 0 will only detect the
case when it is 0. So correct this error test to a working version that
will behave as expected.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Heiko Schocher <hs@nabladev.com>
Andrew Goodbody [Tue, 21 Oct 2025 16:08:27 +0000 (17:08 +0100)]
clk: microchip: mpfs: Fix error detection
clk_register() will return standard error codes so the use of ERR_PTR()
is incorrect. Furthermore the code was ineffective as it lacked a return
statement that would have actually made use of the result. Add the
return statement and remove the use of ERR_PTR to correct this.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Acked-by: Conor Dooley <conor.dooley@microchip.com>
Andrew Goodbody [Tue, 21 Oct 2025 16:08:26 +0000 (17:08 +0100)]
mmc: fsl_esdhc_imx: Cannot test unsigned to be < 0
Testing an unisgned member of a struct to be <= 0 will only detect the
case when it is 0. So correct this error test to a working version that
will behave as expected.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Andrew Goodbody [Tue, 21 Oct 2025 16:08:25 +0000 (17:08 +0100)]
mmc: hi6220_dw_mmc: Fix error detection for clk_get_rate
clk_get_rate() returns a ulong and that return value is assigned to a
member of a struct that is an unsigned int. So testing this value to <=
0 will only detect a return of 0. Also the code in the if block assumes
ret holds the return value when it does not. So update the test to one
that will work as intended and update the if block to actually refer to
the return value.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Tom Rini [Wed, 3 Dec 2025 17:04:32 +0000 (11:04 -0600)]
Merge patch series "led: remove u-boot,boot-led and u-boot,error-led + add cmd doc"
Quentin Schulz <foss+uboot@0leil.net> says:
u-boot,boot-led and u-boot,error-led aren't actually handled by some
generic code but rather by board or architecture specific code. They
also aren't properties that are part of the official dt-binding so they
cannot be upstreamed. For u-boot,boot-led, there's actually a proper
replacement which is /options/u-boot/boot-led[1] (+ CONFIG_LED_BOOT=y).
For Rockchip boards, either nothing (for RK3066, PX30 and RK3399) was
using that property or (for RK3188) the code handling it was guarded by
symbols that were not enabled in the defconfig. For those, the property
and guarded code are removed.
For the Sam9x60 Curiosity, it seems that even though the LED is
controlled whenever CONFIG_LED is enabled, it isn't enabled by default
in the defconfig (but the code was added without modifying the
defconfig, explicitly leaving a choice to the user). I decided to keep
that feature by simply migrating it to the new API, though I cannot test
it as I do not own the device.
The STM32 boards will be migrated in the near future once their upstream
(kernel) Device Trees gain the new way to specify this (via
/options/u-boot/boot-led). I'll let Patrice handle this, see
https://lore.kernel.org/u-boot/94ed1988-13e8-4fe3-bdff-ba2c9973c556@foss.st.com/
and
https://lore.kernel.org/u-boot/2a3aa43a-ce19-41e1-ab56-556629ce5cf9@foss.st.com/
After this, only one user of u-boot,boot-led will be left, based on
STM32: board/dhelectronics/dh_stm32mp1/board.c. @Patrice, maybe that's
something you want to have a look at as well, this seems to be some
evaluation kit?
The only users of u-boot,error-led are STM32 boards, so I'll leave this
to Patrice as well, I do not know what's the way to go for that one.
In any case, I would like to not encourage people to use out-of-spec DT
properties when there is another option (u-boot,boot-led), so I remove
the properties from the dt-binding document from U-Boot.
The help text for the blink subcommand of the led command was misleading
so this is now fixed.
This also moves the content of doc/README.LED into the doc/api/led.rst,
while clearly stating one shouldn't be using this anymore.
This also gets rid of dt-binding that we already have in dts/upstream.
Finally, this adds documentation for the led shell command.
Quentin Schulz [Wed, 12 Nov 2025 17:48:16 +0000 (18:48 +0100)]
doc: remove u-boot,boot-led and u-boot,error-led from "binding"
We're aiming to reduce the amount of U-Boot-specific and out-of-spec
Device Tree additions.
Those two properties haven't been doing anything for a long time
already, except when read by board files manually. This is still the
case for STM32 boards but those will be migrated in the near future
according to their maintainer. In any case, let's not encourage people
to add either of these properties to new or existing Device Trees and
remove it from the bindings.
Quentin Schulz [Wed, 12 Nov 2025 17:48:15 +0000 (18:48 +0100)]
sam9x60-curiosity: migrate Boot LED setup to use /options/u-boot/boot-led
This board is one of the last users of /config/u-boot,boot-led property
which is a U-Boot property out of the DT spec.
Let's migrate it to use the in-spec /options/u-boot/boot-led property.
When enabling LED_BOOT, U-Boot proper will lit the LED right before
entering the main loop, so nothing needs to be done in board files.
As explained in the commit adding support for this u-boot,boot-led
property, let's keep backward compatibility in case LED_BOOT isn't
selected.
Note that this is not tested as I do not own this device.
Cc: Alexander Dahl <ada@thorsis.com> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Tested-by: Alexander Dahl <ada@thorsis.com>
Additionally, if we ever want to enable this LED as Boot LED, we should
instead be using boot-led phandle property in /options/u-boot[1] Device
Tree node with the "new" LED UCLASS devices.
So let's simply remove this unused property to not mislead users.
Further more, the HW default state of that LED is on and migrating this
to the LED_BOOT implem brings no benefit as it'll stay on if U-Boot
reaches its main-loop. Blinking the LED_BOOT also doesn't help because
it doesn't blink for long enough to be noticeable before it's kept on.
This is by design, c.f.
https://source.denx.de/u-boot/u-boot/-/blob/v2025.10/include/led.h#L32-34
If we want this LED to be doing something different, it'll need to be
handled by a board file anyway.
Considering it hasn't worked in many years (if ever), let's just remove
it.
Further more, the HW default state of that LED is on and migrating this
to the LED_BOOT implem brings no benefit as it'll stay on if U-Boot
reaches its main-loop. Blinking the LED_BOOT also doesn't help because
it doesn't blink for long enough to be noticeable before it's kept on.
This is by design, c.f.
https://source.denx.de/u-boot/u-boot/-/blob/v2025.10/include/led.h#L32-34
If we want this LED to be doing something different, it'll need to be
handled by a board file anyway.
Considering it hasn't worked in many years, let's just remove it.
Quentin Schulz [Wed, 12 Nov 2025 17:48:11 +0000 (18:48 +0100)]
rockchip: rk3188: remove setup_led from xPL
There's not a single device making use of that code and it anyway
shouldn't be using the old deprecated u-boot,boot-led /config property
anymore but rather boot-led from /options/u-boot[1] Device Tree node.
Because spl_board_init() is only present to call this now removed
function, we can remove it as well as SPL_BOARD_INIT which is the symbol
guarding calls to spl_board_init() (which is now also removed).
This property is only read in arch/arm/mach-rockchip/rk3188/rk3188.c
when CONFIG_SPL_LED is enabled, which isn't the case for this board, so
let's remove dead code.
Additionally, if we ever want to enable this LED as Boot LED, we should
instead be using boot-led phandle property in /options/u-boot[1] Device
Tree node with the "new" LED UCLASS devices.
Quentin Schulz [Wed, 12 Nov 2025 17:48:09 +0000 (18:48 +0100)]
doc: dt-bindings: remove duplicates with dts/upstream
doc/device-tree-bindings/leds/leds-bcm6328.txt can be found at
dts/upstream/Bindings/leds/leds-bcm6328.yaml.
doc/device-tree-bindings/leds/leds-bcm6358.txt can be found at
dts/upstream/Bindings/leds/leds-bcm6358.txt.
doc/device-tree-bindings/leds/leds-gpio.txt can be found at
dts/upstream/Bindings/leds/leds-gpio.yaml.
doc/device-tree-bindings/leds/leds-lp5562.txt can be found at
dts/upstream/Bindings/leds/leds-lp55xx.yaml.
Only two LED dt-bindings are left in U-Boot: leds-bcm6858.txt and
leds-pwm.txt. The former is partially supported by
dts/upstream/Bindings/leds/leds-bcm63138.yaml but is lacking all
optional properties we have listed in "downstream" dt-binding in U-Boot.
However, there doesn't seem to exist any user of that compatible.
The latter is partially supported by
dts/upstream/Bindings/leds/leds-pwm.yaml but is missing the
u-boot,default-brightness property, which is used by
arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi at the moment. The
default-brightness property is probably not what we want here as it
defaults to max-brightness if missing. I'm assuming we want a different
value for U-Boot (127) and the kernel (255 via max-brightness as a
default), which would prevent us from upstreaming this property, which
doesn't change the status quo, so let it be for now.
Quentin Schulz [Wed, 12 Nov 2025 17:48:07 +0000 (18:48 +0100)]
doc: move legacy API documented in README.LED to doc/api/led.rst
This moves the content of the legacy LED API from doc/READ.LED to
doc/api/led.rst, applying minimal cosmetic changes to "nicely" integrate
it with the current docs and adding a small introduction to the legacy
API section.
Tom Rini [Wed, 26 Nov 2025 23:49:46 +0000 (17:49 -0600)]
Azure: Rework jobs for disk space and 29 jobs
The problem we face currently with Azure jobs is that we're running out
of disk space on the runners as we build. There's not a good way to
split approximately 1500 configurations across 10 jobs and not be close
to or exceeding that limit. Split this in to 29 jobs instead with a goal
of averaging an hour per job. This split gets us close, but there are
still some challenging jobs to try and break up further. The list is
mostly alphabetized but with some intentional changes (catch-all are
last, mx/imx are together, SoC family splits are just grouped together).
The average build time should be close to the same, but outliers can and
will happen.
Tom Rini [Sun, 30 Nov 2025 21:19:48 +0000 (15:19 -0600)]
CI: Update to latest container images
- Bump to noble-20251013
- Include tools for sage lab, build TF-A for platforms there.
- Switch to distro provided trace-cmd, add libengine-pkcs11-openssl
- Use mirrors for GNU projects
- Switch to QEMU 10.1.x
Tom Rini [Sun, 30 Nov 2025 20:34:58 +0000 (14:34 -0600)]
Merge patch series "CI: use mirrors for GNU tools"
Quentin Schulz <foss+uboot@0leil.net> says:
I have to add one (1) package to the Dockerfile as a new dependency and
wanted to build the image to verify it works. I wasn't able to because
GNU servers are just not reliable at all.
The git server URL we're using doesn't seem to be a mirrored one, and
switching to mirror URLs seem to make fetching possible again.
Unfortunately, we don't have the option to do that for coreboot's
dependencies, though we can ask coreboot to download the dependencies
through its own mirror, which we do in this series.
Quentin Schulz [Fri, 21 Nov 2025 17:10:54 +0000 (18:10 +0100)]
CI: add libengine-pkcs11-openssl package for pkcs11
In the future, we'll need proper pkcs11 support so that we can validate
mkimage/binman works well with pkcs11 OpenSSL engine/provider via
softhsm2-util (already installed).
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Tom Rini <trini@konsulko.com>
Tom Rini [Wed, 26 Nov 2025 21:52:00 +0000 (15:52 -0600)]
Dockerfile: Switch to distro-provided trace-cmd
Now that we have moved to Ubuntu 24.04 the distribution provided
trace-cmd is new enough for our needs. Switch to installing that and
stop building it from source.
Tom Rini [Wed, 19 Nov 2025 14:34:53 +0000 (08:34 -0600)]
Docker: Update QEMU to 10.1.x
The current release of QEMU is 10.1.2 and we should be tracking at least
that new currently, to help find and fix emulation problems. This will
make it smaller of a change when we move to 10.1.3 which will re-enable
sifive_unleashed_sdcard testing again.
Tom Rini [Sun, 30 Nov 2025 19:34:47 +0000 (13:34 -0600)]
Merge patch series "Gitlab: Add a "sage-lab" stage to access a board farm"
This series adds support for Gitlab pipelines to run our pytest suite on
a limited number of hardware platforms. While better documentation and
some further enhancements will be coming soon, this can be triggered by
passing '-o ci.variable="SAGE_LAB=1"' to git push, or adding
'pushOption = ci.variable="SAGE_LAB=1"' to the .git/config file for the
project. It can also be invoked manually from the pipeline webpage on a
an existing pipeline.
Tom Rini [Tue, 18 Nov 2025 21:00:15 +0000 (15:00 -0600)]
Gitlab sage, Docker: Add snmp and rsync
Add snmp and rsync to the normal docker image. While these tools are
only required for the lab on sage, I think it's a small enough addition
to be worth always including at this point. A higher level TODO I think
may be to see if we can / should split the resulting container up, or
if there's host tooling we can remove at a later step, after building
all the software we require.
Tom Rini [Tue, 18 Nov 2025 21:00:14 +0000 (15:00 -0600)]
Gitlab: sage: Add Pine64+ platform
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.
projects / thirdparty / u-boot.git / log
