| Age | Commit message (Collapse) | Author |
|---|
|
https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request efi-2026-01-rc4
CI: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/28652
Documentation:
* Correct and add missing pytest hook script environment variable names
* board: verdin-am62p: Fix boot log output
* Add a page for downloading the U-Boot logo with and without text
UEFI:
* Fix a memory leak when retrieving device paths from boot vars
|
|
Fix boot log output not being rendered correctly, fix
it doing the same as done in verdin-am62.rst.
Fixes: b8c43968b801 ("board: toradex: add verdin am62p support")
Signed-off-by: Francesco Dolcini <[email protected]>
|
|
get_dp_device() is used to derive the device path from a boot variable.
However, if the last efi_get_variable_int() call fails, we return an
error without freeing 'buf'.
There's no need to call efi_get_variable_int() for variables we don't
know the size since we have the efi_get_var() wrapper.
Replace that in the two instances we use it. The first one will also
fix the memory leak.
A nice sideeffect is that the code size is also reduced, since we are
re-using functions instead of open coding them
$~ bloat-o-meter u-boot u-boot.new
add/remove: 0/0 grow/shrink: 1/2 up/down: 6/-196 (-190)
Function old new delta
version_string 70 76 +6
efi_launch_capsules 2288 2196 -92
get_dp_device 244 140 -104
Total: Before=1222331, After=1222141, chg -0.02%
Fixes: c74cd8bd08d1 ("efi_loader: capsule: add capsule_on_disk support")
Signed-off-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
Add the _EXTRA variants of U_BOOT_BUILD_DIR and U_BOOT_RESULT_DIR to the
list of environment variables set for hook scripts.
These were added in commit 8f2a9fa7d6e7 ("test: Support testing with two
board-builds") but were not documented.
Signed-off-by: David Lechner <[email protected]>
|
|
Fix the names of environment variables set for hook scripts. These
have a U_BOOT_ prefix, not UBOOT_.
Signed-off-by: David Lechner <[email protected]>
|
|
Add a page showing the logo with and without text.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
The logo with the text 'U-Boot' has been used in multiple presentations.
Up to now it was only available from my upload to wikimedia.org.
Make it available in our repository.
Link: https://upload.wikimedia.org/wikipedia/commons/9/9e/U-Boot_Logo.svg
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Andrew Goodbody <[email protected]> says:
Smatch reported an error where a value calculated by ERR_PTR was not
used. Fixing this to return the generated value led to a test failure
which meant updating the sandbox clock code so that it would still cause
the tests to pass with the above correction.
Debugging this problem led to a SIGSEGV which is addressed in 1/3.
Possible memory leaks noticed are addressed in 3/3.
Link: https://lore.kernel.org/r/[email protected]
|
|
In clk_set_default_rates() memory is allocated to store the clock rates
that are read. Direct returns fail to free this memory leading to a
memory leak so instead use 'goto fail;' which will then perform the free
before exiting the function.
Signed-off-by: Andrew Goodbody <[email protected]>
|
|
In clk_set_default_get_by_id ret is passed to ERR_PTR but nothing is
done with the value that this calculates which is obviously not the
intention of the code. This is confirmed by the code around where this
function is called.
Instead return the value from ERR_PTR.
Then fixup the sandbox code so that the test dm_test_clk does not fail
as it relied on the broken behaviour.
Finally disable part of the test that does not work correctly with
CLK_AUTO_ID
This issue found by Smatch.
Signed-off-by: Andrew Goodbody <[email protected]>
|
|
If LOG_DEBUG is defined and a NULL clk is passed to clk_enable or
clk_disable then an attempt is made to dereference NULL in the debug
statement. Guard against this.
Signed-off-by: Andrew Goodbody <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
|
|
The macro U_BOOT_DEVICE has been renamed to U_BOOT_DRVINFO.
This patch updates the reference in reboot-mode-gpio.h.
Signed-off-by: Cibil Pankiras <[email protected]>
|
|
If noffset is negative, do not pass it to fit_get_name() and then further to
libfdt, this will crash sandbox with SIGSEGV because libfdt can not handle
negative node offsets without full tree check, which U-Boot inhibits to keep
size lower.
Instead, always check noffset before use, and if the return value indicates
failure, exit right away.
Signed-off-by: Marek Vasut <[email protected]>
Acked-by: Heinrich Schuchardt <[email protected]>
|
|
The DA8xx GPIO driver was not being built as part of the A53 U-Boot
image on AM64x and AM65x. This meant only i2c GPIO expanders were
accessible to the users from the U-Boot prompt.
This patch fixes it by setting CONFIG_DA8XX_GPIO.
Signed-off-by: Anshul Dalal <[email protected]>
|
|
Otherwise the custom-cape eeprom (at address 57) reports NACK which
results into "i2c_write: error waiting for data ACK (status=0x116)" and
terminates further scanning.
Signed-off-by: Marian Cingel <[email protected]>
|
|
Commit 5f70be08b015 ("Fix autoboot countdown printing wrong") introduces
inconsistency in how the countdown is displayed. For example, in case
when BOOTDELAY=5, the next output is observed during the boot:
Hit any key to stop autoboot: 5
Hit any key to stop autoboot: 4
Hit any key to stop autoboot: 3
That happens due to different printf format (%2d vs %1d). Moreover, the
mentioned commit fails to handle the case when the user is holding some
key before the countdown is shown. E.g. if BOOTDELAY=101, the next
malformed output is being produced:
Hit any key to stop autoboot: 1 0
That's because the fast path code wasn't modified accordingly, and still
tries to erase the number using '\b\b\b' format.
Fix both issues by introducing a dedicated routine for printing the
whole countdown line.
Fixes: 5f70be08b015 ("Fix autoboot countdown printing wrong")
Signed-off-by: Sam Protsenko <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Acked-by: David Zang <[email protected]>
|
|
lthreads is of size MAX_THREADS, hence id must be lower than
MAX_THREADS to avoid any potential buffer overflow in
thread_start function.
Signed-off-by: Francois Berder <[email protected]>
|
|
If realloc failed, raw was not freed and thus memory
was leaked.
Signed-off-by: Francois Berder <[email protected]>
|
|
- Fix temp memory leak
- Free memory during error handling
Signed-off-by: Francois Berder <[email protected]>
|
|
Attempting to build with "allyesconfig" means that we try and build all
available options for the sandbox platforms. Doing so exposes that the
drivers under drivers/clk/ti/ can only be compiled or linked on
ARCH_OMAP2PLUS platforms as some drivers require platform specific
headers while other drivers depend on these first drivers to link.
Express those requirements in Kconfig as well.
Reviewed-by: Manorit Chawdhry <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
The ALTERA_QSPI driver conflicts with the regular FLASH_CFI_DRIVER as
both implement the same high level functionality and so use the same
global namespace. In a similar fashion, all NAND drivers are mutually
exclusive due to namespace collisions. For the remaining drivers which
did not already have some architecture specific dependency, add them.
Signed-off-by: Tom Rini <[email protected]>
|
|
Quentin Schulz <[email protected]> says:
Only the Siemens corvus board seems to be using these two status LEDs
from the legacy LED API.
Since we're trying to get rid of the last users of the legacy LED API,
let's migrate Corvus to the modern LED API instead, which uses DM. For
Corvus's case, it also uses DM_GPIO (already enabled in defconfig).
Since there was no use for the green status_led (not compiled in), it
simply is removed without migrating it to the modern API. If need be, we
can always add a new gpio-led in the FDT.
Note that I do not own a Siemens Corvus board so it's a bit of a shot in
the dark whether it'll work on the first try, only build tested.
The red LED should be on whenever reaching U-Boot proper CLI, if not we
have an issue.
The LED should be controllable with the led command from U-Boot proper
CLI.
Link: https://lore.kernel.org/r/[email protected]
|
|
To the exception of red_led_on in the arm-specific assembly code, all
code interacting with the red status LED was guarded by the
CONFIG_LED_STATUS_RED symbol, which is enabled in none of the upstream
defconfigs.
Since the last board which overrode the weak red_led_on function got
migrated to the new LED mechanism, there's also no user of the
arm-specific assembly code anymore, therefore it can be removed along
the other unreachable code sections.
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
red_led_on is either called from the legacy LED shell command (which is
disabled for corvus) or from arm-specific assembly code right before
jumping into board_init_r() in U-Boot proper.
Let's migrate to use the more modern LED subsystem by migrating to DM.
The default-state is set to on to mimic red_led_on() from the
arm-specific assembly code as a missing default-state FDT property
currently means the LED is not probed except if explicitly done via the
led shell command. Note though that this is running much later in the
boot process, once DM is started.
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
The last user of it was removed in a previous commit so let's remove its
support entirely.
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
green_led_on and green_led_off are only called by the legacy LED command
(CONFIG_LED_STATUS_CMD) when CONFIG_LED_STATUS_GREEN is enabled, both of
which aren't enabled for corvus, so let's simply remove it as it's dead
code.
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
Quentin Schulz <[email protected]> says:
This is a follow-up to:
- https://lore.kernel.org/u-boot/[email protected]/
- https://lore.kernel.org/u-boot/[email protected]/
to continue the effort of getting rid of the legacy LED API. This series
depends on the series listed above.
Link: https://lore.kernel.org/r/[email protected]
|
|
No PPC upstream defconfig actually enables CONFIG_LED_STATUS and we're
trying to get rid of the legacy LED API, so let's remove one of its last
users.
Signed-off-by: Quentin Schulz <[email protected]>
|
|
The code is guarded by a condition none of the defconfigs meet (that is
CONFIG_SYS_FAULT_ECHO_LINK_DOWN and CONFIG_LED_STATUS_RED both enabled),
so we can remove the unreachable code sections.
When doing that, there's no caller for miiphy_link anymore, so it can be
removed.
This in turns makes CONFIG_SYS_FAULT_ECHO_LINK_DOWN and
CONFIG_SYS_FAULT_MII_ADDR unused so they are removed as well.
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Commit 76386d6195a1 ("arm: Remove cm_t35 board") removed support for the
board that was built when TARGET_CM_T35 is selected, but removal of the
symbol was forgotten, so let's fix this oversight.
While at it, update the README for omap3 to remove the last mention of
cm_t35.
Fixes: 76386d6195a1 ("arm: Remove cm_t35 board")
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
The last user of coloured_LED_init has been recently removed, so we can
remove all places it's called and defined as it does nothing now.
Nobody makes use of the yellow and blue status LEDs from the legacy API,
so let's remove all references to it.
Signed-off-by: Quentin Schulz <[email protected]>
|
|
The last CONFIG_MVS in code was removed almost 12 years ago in commit
3b98b57fa796 ("include: delete unused header files").
STATUS_LED_PAR was last seen 8 years ago when removed in commit
5b8e76c35ec3 ("powerpc, 8xx: remove support for 8xx").
If CONFIG_LED_STATUS_BOARD_SPECIFIC is not defined, the build will fail
so we won't even reach this part of the code.
Let's simplify the if block to actually possible configurations.
Signed-off-by: Quentin Schulz <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Newer versions of libfdt strictly check whether the FDT blob
passed to them is at 8-byte aligned offset, if it is not, then
the library fails checks with -FDT_ERR_ALIGNMENT . Currently,
'abootimg get dtb --index=1 addr size' may return non 8-byte
aligned FDT address which points directly into the abootimg.
Copy the result into temporary location before validation to
avoid FDT alignment check failure.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
Newer versions of libfdt strictly check whether the FDT blob
passed to them is at 8-byte aligned offset, if it is not, then
the library fails checks with -FDT_ERR_ALIGNMENT . Currently,
android_image_print_dtb_contents() passed FDT directly mapped
from abootimg to libfdt, and this FDT is not always aligned to
8-byte offset. Specifically, the FDTs are somewhat packed in
the abootimg, therefore if the first FDT blob is e.g. 0xfd bytes
long, then the next FDT blob ends up at 0xfd offset, which is
not 8-byte aligned.
Fix this by first extracting the header into 8-byte aligned buffer,
checking only the header for validity, and then by copying the
entire FDT into newly allocated 8-byte aligned buffer. While this
is not efficient, it is the correct way to handle DTs, which must
be at 8-byte aligned offsets. Mitigate the inefficiency for the
common case by checking whether the DT might be 8-byte aligned and
if it is, map it directly.
Signed-off-by: Marek Vasut <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
Heinrich Schuchardt <[email protected]> says:
Many C unit tests are not executed if CONFIG_CONSOLE_RECORD is not set.
Hence Tom suggested to let UNIT_TEST imply CONSOLE_RECORD.
The first patch makes the skipped C unit tests visible.
The rest of the series deals with hidden bugs in our tests.
The 'fdt get value' command returned incorrect values on low-endian
systems. So this needed fixing too.
Link: https://lore.kernel.org/r/[email protected]
|
|
The cmd and the log test suites rely on CONFIG_CONSOLE_RECORD.
The log test suite is always built if CONFIG_UNIT_TEST=y.
The print_do_hex_dump test relies on CONFIG_HEXDUMP. Imply it too.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
The 32bit cells of a device-tree property are big-endian. When printing
them via 0x08x we must first convert to the host endianness.
Remove the restriction to 20 bytes length. This would not allow to read an
SHA256 value.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
On the power architecture the bdinfo command prints architecture specific
information. The test needs to accept these output lines.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
The ppce500 is not as fine grained as expected.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
The original value of the first variable msr (0x200) is not controlled by
U-Boot. Don't make any assumption.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Hexdumps for types other then byte look different in dependence of the
endianness.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
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 <[email protected]>
|
|
The value of boot_params is device specific and non-zero on many boards.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
The test relates to the 'font' and not to the 'fdt' command.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
The font test makes assumptions about video devices and selected fonts that
may not hold true on other configurations like qemu-x86_64_defconfig.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
If CONFIG_CONSOLE_RECORD_INIT_F=y we need additional memory according to
CONFIG_CONSOLE_RECORD_OUT_SIZE_F.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
256 GiB is the default memory size of the sandbox. But in our CI other
boards like qemu-x86_64_defconfig run with a different memory size.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
The exit command is not available if CONFIG_HUSH_PARSER=n
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Skipping to the line starting with tsc reaches the tsc_base output not the
final tsc output.
Expect all the X86 specific lines in the bdinfo output.
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
Skip the test if CONFIG_HEXDUMP=n
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
