Simon Glass <sjg@chromium.org> says:

Each arch does something slightly different before booting the OS. Some
archs even do different things depending on the CPU type.

It is quite hard to know what actually happens in the final milliseconds
before the OS boot.

This series attempts to start cleaning up U-Boot in this area.

The basic intent is to create a new bootm_final() function which can be
called by all archs. It provides some flags for a couple of necessary
variations but otherwise it is generic.

All architectures are converted over to use this new function.

board_quiesce_devices() is moved into bootm_final() so that all archs
benefit from it.

This series fixes a bug in device_remove() is fixed where removing a
parent with specialised flags (e.g. DM_REMOVE_ACTIVE_ALL) could leave
children activated, since they do not match the flags. This fixes is
needed to avoid bootm_final() causing test failures on sandbox.

Future work could take this a little further:
- Convert EFI loader to use the same function
- Improve comments for cleanup_before_linux() across architectures
- Support fake-run tracing on all archs

Link: https://lore.kernel.org/r/20260306023638.2678886-1-sjg@chromium.org

Add a call to bootm_final() before jumping to the kernel. This adds
the "Starting kernel" message, bootstage tracking,
board_quiesce_devices() and dm_remove_devices_active() which were not
previously called on m68k.

Signed-off-by: Simon Glass <simon.glass@canonical.com>
Acked-by: Angelo Dureghello <angelo@kernel-space.org>
Tested-by: Angelo Dureghello <angelo@kernel-space.org>
Acked-by: Kuan-Wei Chiu <visitorckw@gmail.com>

Quentin Schulz <quentin.schulz@cherry.de> says:

This migrates the last user of the legacy LED API, IMX233-OLinuXino and
net/bootp.c, to the modern LED framework.

I do have concern about being able to use BOOTP in SPL? In which case, I
should probably add an additional check on CONFIG_IS_ENABLED(LED) in
addition to IS_ENABLED(CONFIG_LED_BOOT)?

I haven't tested this as I do not own an IMX233-OLinuXino, so please
give this a try if you own this device.

Then, since there's no user left of this legacy API, it is entirely
removed.

Link: https://lore.kernel.org/r/20251120-legacy-led-removal-v1-0-369d44338358@cherry.de

No user of the legacy LED API anymore (except Sunxi with the PinePhone
but that is now a Sunxi-specific implementation), so let's remove
anything related.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

Add support for the Motorola 68040 architecture. Currently, m68k
support in U-Boot is primarily focused on ColdFire variants. Introduce
the necessary infrastructure to support the classic M680x0 series,
specifically targeting the M68040 as emulated by QEMU.

The implementation includes exception vectors, early startup code, and
minimal CPU initialization and relocation stubs. It also defines the
standard m68k boot information structure used for passing hardware
information to the operating system. To ensure compatibility, ColdFire-
specific library objects such as cache and interrupt handling are
excluded from the build when M68040 is selected.

Additionally, apply a specific workaround during the early memory
reservation stage. Use a manual loop to clear global data instead of
the standard memset() function, as utilizing memset() at this point was
observed to cause a hang on the QEMU platform.

Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
Acked-by: Angelo Dureghello <angelo@kernel-space.org>
Reviewed-by: Simon Glass <simon.glass@canonical.com>

For armv8 we are adding proper page permissions for the relocated U-Boot
binary. Add a weak function that can be used across architectures to change
the page permissions

Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on AML-S905X-CC
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

All of the current definitions of arch_lmb_reserve() are doing the
same thing -- reserve the region of memory occupied by U-Boot,
starting from the current stack address to the ram_top. Introduce a
function lmb_reserve_uboot_region() which does this, and do away with
the arch_lmb_reserve() function.

Instead of using the current value of stack pointer for starting the
reserved region, have a fixed value, considering the stack size config
value.

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

The current LMB API's for allocating and reserving memory use a
per-caller based memory view. Memory allocated by a caller can then be
overwritten by another caller. Make these allocations and reservations
persistent using the alloced list data structure.

Two alloced lists are declared -- one for the available(free) memory,
and one for the used memory. Once full, the list can then be extended
at runtime.

[sjg: Use a stack to store pointer of lmb struct when running lmb tests]

Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
[sjg: Optimise the logic to add a region in lmb_add_region_flags()]

Only m68k and powerpc use this field, so move it to the arch-specific
info, to reduce the size for other archs.

Signed-off-by: Simon Glass <sjg@chromium.org>

Drop all duplicate newlines. No functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>