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 <m-chawdhry@ti.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
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 <trini@konsulko.com>
Quentin Schulz <quentin.schulz@cherry.de> 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/20251119-corvus-led-red-green-v1-0-ce86b8d59dfc@cherry.de
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 <quentin.schulz@cherry.de>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
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 <quentin.schulz@cherry.de>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
The last user of it was removed in a previous commit so let's remove its
support entirely.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
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 <quentin.schulz@cherry.de>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
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 <quentin.schulz@cherry.de>
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 <quentin.schulz@cherry.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Commit 76386d6195 ("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: 76386d6195 ("arm: Remove cm_t35 board")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
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 <quentin.schulz@cherry.de>
The last CONFIG_MVS in code was removed almost 12 years ago in commit
3b98b57fa7 ("include: delete unused header files").
STATUS_LED_PAR was last seen 8 years ago when removed in commit
5b8e76c35e ("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 <quentin.schulz@cherry.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Heinrich Schuchardt <heinrich.schuchardt@canonical.com> 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/20251123225711.227016-1-heinrich.schuchardt@canonical.com
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 <heinrich.schuchardt@canonical.com>
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 <heinrich.schuchardt@canonical.com>
On the power architecture the bdinfo command prints architecture specific
information. The test needs to accept these output lines.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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 <heinrich.schuchardt@canonical.com>
Hexdumps for types other then byte look different in dependence of the
endianness.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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>
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 <heinrich.schuchardt@canonical.com>
If CONFIG_CONSOLE_RECORD_INIT_F=y we need additional memory according to
CONFIG_CONSOLE_RECORD_OUT_SIZE_F.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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 <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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 <heinrich.schuchardt@canonical.com>
On ARM the bdinfo command prints architecture specific information.
The test needs to accept these output lines.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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>
CI: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/28641
_ 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
Tom Rini
Quentin SchulzandTom Rini
Heinrich SchuchardtandTom Rini
Heinrich SchuchardtandTom Rini
Patrice Chotard