It isn't necessarily safe to move the kernel (up to) 2MB higher in
memory. If the kernel is in a FIT, this may overwrite other data such as
the devicetree.
Use lmb (where available) as is done with other image relocations. Update
the return value to provide more specific information on failure.
Signed-off-by: Simon Glass <sjg@chromium.org>
When an FDT is not provided, U-Boot currently says:
FDT and ATAGS support not compiled in
even if CONFIG_OF_LIBFDT and CONFIG_LMB are enabled. This can send
people on a wild goose chase. Add a separate message for a devicetree
not being present.
Signed-off-by: Simon Glass <sjg@chromium.org>
This variable is tricky to set up and is only used to show an address.
Drop it and use the source variable instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some machines start U-Boot in a different exception level, so provide a
way to view it.
Series-changes: 2
- Use the existing current_el() function
Signed-off-by: Simon Glass <sjg@chromium.org>
Provides some debugging info while doing bootm processing.
Series-changes: 2
- Make the messages longer and more explanatory
Signed-off-by: Simon Glass <sjg@chromium.org>
This option is used on most other boards. Leaving it disabled creates
situations where the linker fails to build, due to symbols which are
referenced only it code that would have been garbage-collected.
To keep this disabled we would need to introduce #ifdefs not needed by
other platforms, which would be annoying.
The only current reason why this cannot be enabled is that the
linker lists are lost. Add a KEEP() around these, and enable the option.
Signed-off-by: Simon Glass <sjg@chromium.org>
Now that ARM's announce_and_cleanup() function includes the same steps
as bootm_final(), just use the latter.
Move over part of a comment which seems useful.
Signed-off-by: Simon Glass <sjg@chromium.org>
Move the declaration of this function to a common header. Make sure it
is included by files which define it.
Fix up a few whitespace problems while here.
Signed-off-by: Simon Glass <sjg@chromium.org>
The bdinfo command makes use of quite a few functions which show a label
followed by a value, on a single line.
This sort of thing is generally useful outside of bdinfo, so move it to
a generic place. Use 'l' (for label) as the prefix.
The margin is still hard-coded to 12, which seems a reasonable limit for
a label.
Signed-off-by: Simon Glass <sjg@chromium.org>
Each arch has its own set of functions related to booting. Rather than
including them for each enabled command, have a single rule to include
them, using the new CONFIG_BOOT
Signed-off-by: Simon Glass <sjg@chromium.org>
The mcr and msr instructions are available in Thumb mode only if
Thumb2 is supported. Therefore, if __thumb2__ is not set, make
sure we switch to ARM mode by inserting a .arm directive in the
inline assembly.
Fixes LTO link errors with kirkwood platforms, triggered by a later
commit:
tools/buildman/buildman -o /tmp/build -eP sheevaplug
[...]
{standard input}:24085: Error: selected processor does not support `mrc p15,0,r3,c1,c0,0' in Thumb mode
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
This is not needed now, as the startup protocol is handled in
arch-specific code early in boot.
Drop BLOBLIST_PASSAGE_MANDATORY as well, as OF_BLOBLIST is enough to
cover this. With standard passage the devicetree is accessed before the
bloblist is inited.
Signed-off-by: Simon Glass <sjg@chromium.org>
Accept a bloblist and control devicetree from a previous phase in
registers 0 to 3, as documented in the Firmware Handoff
specification[1].
Note that there is currently a weak function called save_boot_params()
which happens to save the same registers as are needed for this
protocol. But it seems better to implement this feature as a first-class
citizen, if for no other reason than that many boards have their own
version of save_boot_params() which may not happen to save the required
registers. A weak function is not a good basis for an API.
Commit-notes:
While some efforts were made to encourage Intel to adopt this
specification, this has not yet been successful. However I do intend to
use my proposed x86 handoff in U-Boot, once this series is in.
END
Series-changes: 2
- Use three registers instead of two for the entry
Series-changes: 3
- Update registers to match the Firmware Handoff protocol
- Add support for aarch64 also
Series-changes: 4
- Update commit message to indicate this can only be for ARM at present
- Update commit message to mention why save_boot_params() is not used
[1] https://firmwarehandoff.github.io/firmware_handoff/main/index.html
Signed-off-by: Simon Glass <sjg@chromium.org>
Change-Id: I56d9d06e5d74724c963eaffbbe1c2aa400b60bb8
It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our
Makefiles as part of the macros to determine when to do something in our
Makefiles based on what phase of the build we are in. For consistency,
bring this down to a single macro and use "$(PHASE_)" only.
Signed-off-by: Tom Rini <trini@konsulko.com>
Now that we have the same option for SPL and TPL, simplify the logic for
determining the initial stack.
Note that this changes behaviour as current SPL_STACK is a fallback for
TPL. However, that was likely unintended and can be handled with Kconfig
defaults if needed.
Series-changes: 2
- Add new patch to use CONFIG_VAL() to obtain the SPL stack
Series-changes: 3
- Fixed 'VPL' typo
- Update commit message to mention the behaviour change
- Update TPL_HAVE_INIT_STACK to drop the SPL fallback
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Suggested-by: Tom Rini <trini@konsulko.com>
At present there is a hex value SPL_STACK which both determines whether
SPL has its own initial stack and the hex value of that stack.
Split off the former into SPL_HAVE_INIT_STACK with SPL_STACK depending
on that and only providing the latter.
Series-changes: 2
- Add new patch with an SPL_HAVE_INIT_STACK option
Signed-off-by: Simon Glass <sjg@chromium.org>
The most common word for features that make a platform work is to use
'HAVE_xxx'. Rename this option to match.
Update the help to use the word 'phase' rather than 'stage', since
that is the current terminology. Also clarify that, absent this setting,
the stack pointer generally comes from the value used by U-Boot proper,
rather than SPL.
Move the option just above TPL_STACK which depends on it.
Series-changes: 2
- Add new patch to rename TPL_NEEDS_SEPARATE_STACK
Series-changes: 3
- Reword the Kconfig help for TPL_HAVE_INIT_STACK
Signed-off-by: Simon Glass <sjg@chromium.org>
We don't need to manually add the PE header, since binutils has support
for this now. Remove it to simplify the file.
Set the link-target to efi-app-aarch64 so that binutils knows what to
do. Add rules to pick up the arm64 files.
Make some updates to the link-script for arm64, so this all works:
- Pass .hash .eh_frame and .reloc sections through to objcopy
- Put RELA pieces into a single section
- Put linker lists into .data
- Embed the dtb
Add a config.mk fragment into the baord directory.
Note that it does not seem to be possible to use this approach with
32-bit ARM, so this is left alone.
Signed-off-by: Simon Glass <sjg@chromium.org>
Build in the EFI-app startup code as well as the code to relocate U-Boot
to the loaded position, since this is under the control of the previous
firmware.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
The EFI app uses different startup and relocation code and the existing
code uses symbols not present in the app. Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
This code is not used with the EFI app, since it enters through a call
to efi_main(). Remove start.S and crt files from the build.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
The previous bootloader has already set up the page tables, so don't try
to do it again.
This fixes a crash in QEMU when booting from EDK2
Signed-off-by: Simon Glass <sjg@chromium.org>
The previous bootloader has likely done this already, so avoid trying to
do it again. This fixes a crash in QEMU when booting from EDK2
Signed-off-by: Simon Glass <sjg@chromium.org>
It is confusing to have a camel-case indentifier in the these files.
Rename them to fit with U-Boot's snake-case style.
The image_base symbol is already used in the x86 link-scripts.
Signed-off-by: Simon Glass <sjg@chromium.org>
The 'vendor' concept comes from arch/x86. Rather than letting this
spread around the tree, rename it to ARCH_EFI.
While EFI is not quite an architecture in the strict sense, it is
similar to sandbox in that it sits somewhat above the CPU architecture.
Signed-off-by: Simon Glass <sjg@chromium.org>
Implement support for launching U-Boot via an EFI stub app on ARM64.
This is more or less a straight port of the x86 implementation, but due
to the highly x86/qemu specific nature of that implementation I decided
to just split it out to its own file.
Unlike the x86 implementation, there is no debug UART here since ARM
platforms don't have a standard UART interface. However it is usually
possible to port over the debug uart implementation for you platform for
bringup purposes.
Currently this implementation doesn't provide a DTB to U-Boot and
expects U-Boot to use a built-in one, however this ought to be a fairly
trivial addition in the future.
The other significant difference to the x86 version is that rather than
copying U-Boot to CONFIG_TEXT_OFFSET, we require that U-Boot is built
position independent and copy it to EFI allocated memory.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Arm invented a new format for arm64 and something similar is also used
with RISC-V. Add this to the list of supported formats and provide a way
for the format to be detected on both architectures.
Update the genimg_get_format() function to support this.
Fix up switch() statements which don't currently mention this format.
Booti does not support a ramdisk, so this can be ignored.
Signed-off-by: Simon Glass <sjg@chromium.org>
This replaces dm_remove_devices_flags() calls in all boot
implementations to ensure non vital devices are consistently removed
first. All boot implementation except arch/arm/lib/bootm.c currently
just call dm_remove_devices_flags(DM_REMOVE_ACTIVE_ALL). This can result
in crashes when dependencies between devices exists. The driver model's
design document describes DM_FLAG_VITAL as "indicates that the device is
'vital' to the operation of other devices". Device removal at boot
should follow this.
Instead of adding dm_remove_devices_flags() with (DM_REMOVE_ACTIVE_ALL |
DM_REMOVE_NON_VITAL) everywhere add dm_remove_devices_active() which
does this.
Fixes a NULL pointer deref in the apple dart IOMMU driver during EFI
boot. The xhci-pci (driver which depends on the IOMMU to work) removes
its mapping on removal. This explodes when the IOMMU device was removed
first.
dm_remove_devices_flags() is kept since it is used for testing of
device_remove() calls in dm.
Signed-off-by: Janne Grunau <j@jannau.net>
Patrick Rudolph <patrick.rudolph@9elements.com> says:
Based on the existing work done by Simon Glass this series adds
support for booting aarch64 devices using ACPI only.
As first target QEMU SBSA support is added, which relies on ACPI
only to boot an OS. As secondary target the Raspberry Pi4 was used,
which is broadly available and allows easy testing of the proposed
solution.
The series is split into ACPI cleanups and code movements, adding
Arm specific ACPI tables and finally SoC and mainboard related
changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the
mandatory ACPI tables are supported, allowing to boot into Linux
without errors.
The QEMU SBSA support is feature complete and provides the same
functionality as the EDK2 implementation.
The changes were tested on real hardware as well on QEMU v9.0:
qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \
-pflash secure-world.rom \
-pflash unsecure-world.rom
qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \
-smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \
-dtb bcm2711-rpi-4-b.dtb -nographic
Tested against FWTS V24.03.00.
Known issues:
- The QEMU rpi4 support is currently limited as it doesn't emulate PCI,
USB or ethernet devices!
- The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly
cache related).
- PCI on RPI4 isn't working on real hardware since the pcie_brcmstb
Linux kernel module doesn't support ACPI yet.
Link: https://lore.kernel.org/r/20241023132116.970117-1-patrick.rudolph@9elements.com
On Arm platforms that use ACPI they cannot rely on the "spin-table"
CPU bringup usually defined in the FDT. Thus implement the
'ACPI Multi-processor Startup for ARM Platforms', also referred to as
'ACPI parking protocol'.
The ACPI parking protocol works similar to the spin-table mechanism, but
the specification also covers lots of shortcomings of the spin-table
implementations.
Every CPU defined in the ACPI MADT table has it's own 4K page where the
spinloop code and the OS mailbox resides. When selected the U-Boot board
code must make sure that the secondary CPUs enter u-boot after relocation
as well, so that they can enter the spinloop code residing in the ACPI
parking protocol pages.
The OS will then write to the mailbox and generate an IPI to release the
CPUs from the spinloop code.
For now it's only implemented on ARMv8, but can easily be extended to
other platforms, like ARMv7.
TEST: Boots all CPUs on qemu-system-aarch64 -machine raspi4b
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Fill the MADT table in the GIC driver and armv8 CPU driver to
drop SoC specific code. While the GIC only needs devicetree
data, the CPU driver needs additional information stored in
the cpu_plat struct.
While on it update the only board making use of the existing
drivers and writing ACPI MADT in mainboard code.
TEST: Booted on QEMU sbsa-ref using GICV3 driver model generated MADT.
Booted on QEMU raspb4 using GICV2 driver model generated MADT.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
Add a generic GICV2 driver that:
- parses the DT and generates the ACPI MADT subtables
- implement of_xlate() and allows irq_get_by_index() to return the
correct interrupt mappings
Map DT interrupts to ARM GIC interrupts as follows:
- Interrupt numbers ID32-ID1019 are used for SPIs
- ID0-ID15 are used for SGIs
- ID16-ID31 are used for PPIs
TEST: Booted on QEMU raspb4 using GICV2 driver model generated MADT.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Translate IRQs by implementing of_xlate() as required by
irq_get_by_index() to parse interrupt properties.
Map DT interrupts to ARM GIC interrupts as follows:
- Interrupt numbers ID32-ID1019 are used for SPIs
- ID0-ID15 are used for SGIs
- ID16-ID31 are used for PPIs
TEST: Booted on qemu sbsa-ref that has a GICV3.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Moritz Fischer <moritzf@google.com>
The code accesses the gic-v3 node, but not the gic-v3-its node,
thus rename the objects to clarify which node it operates on.
The following commit will make use of the gic-v3-its node for real.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a new method to acpi_ops to let drivers fill out ACPI MADT.
The code is unused for now until drivers implement the new ops.
TEST: Booted on QEMU sbsa using driver model generated MADT.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
Add generic ACPI code to generate
- MADT GICC
- MADT GICD
- MADT GICR
- MADT GIC ITS
- PPTT processor
- PPTT cache
as commonly used on arm platforms.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Simon Glass <sjg@chromium.org>
Simon Glass <sjg@chromium.org> says:
When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL
Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.
For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:
#if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)
In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.
This series starts a change in terminology and usage to resolve the
above issues:
- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_
It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.
This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.
The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.
Use PHASE_ as the symbol to select a particular XPL build. This means
that SPL_TPL_ is no-longer set.
Update the comment in bootstage to refer to this symbol, instead of
SPL_
Signed-off-by: Simon Glass <sjg@chromium.org>
The link rule (for $(obj)/%_efi.so) in scripts/Makefile.lib handles
pulling in efi_crt0.o and efi_reloc.o so drop the 'extra' rules.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
This is not actually a command so the name is confusing. Use
BOOTEFI_HELLO_COMPILE instead. Put it in the efi_loader directory
with the other such config options.
The link rule (for $(obj)/%_efi.so) in scripts/Makefile.lib handles
pulling in efi_crt0.o and efi_reloc.o so drop the 'extra' rules.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Sughosh Ganu <sughosh.ganu@linaro.org> says:
This is a follow-up from an earlier RFC series [1] for making the LMB
and EFI memory allocations work together. This is a non-rfc version
with only the LMB part of the patches, for making the LMB memory map
global and persistent.
This is part one of a set of patches which aim to have the LMB and EFI
memory allocations work together. This requires making the LMB memory
map global and persistent, instead of having local, caller specific
maps. This is being done keeping in mind the usage of LMB memory by
platforms where the same memory region can be used to load multiple
different images. What is not allowed is to overwrite memory that has
been allocated by the other module, currently the EFI memory
module. This is being achieved by introducing a new flag,
LMB_NOOVERWRITE, which represents memory which cannot be re-requested
once allocated.
The data structures (alloced lists) required for maintaining the LMB
map are initialised during board init. The LMB module is enabled by
default for the main U-Boot image, while it needs to be enabled for
SPL. This version also uses a stack implementation, as suggested by
Simon Glass to temporarily store the lmb structure instance which is
used during normal operation when running lmb tests. This does away
with the need to run the lmb tests separately.
The tests have been tweaked where needed because of these changes.
The second part of the patches, to be sent subsequently, would work on
having the EFI allocations work with the LMB API's.
[1] - https://lore.kernel.org/u-boot/20240704073544.670249-1-sughosh.ganu@linaro.org/T/#t
Notes:
1) These patches are on next, as the alist patches have been
applied to that branch.
2) I have tested the boot on the ST DK2 board, but it would be good to
get a T-b/R-b from the ST maintainers.
3) It will be good to test these changes on a PowerPC platform
(ideally an 85xx, as I do not have one).
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>
