The bootz method is special in that it uses its own implementation of
several of the bootm states.
The existing do_bootz() function calls bootz_run() but first does a few
other things. These are missing in the direct call to bootz_run(). I
probably missed this because bootz_start() sets up its own
struct bootm_info so I assumed it was independent. While the struct
itself is independent, changes to the images member (which is a pointer)
persist.
Move the required code into bootz_run()
This change was manually tested on an rpi2 with postmarketOS added,
using standard boot and also the 'bootz' command.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 47eda7e80e ("boot: pxe: Use bootm_...() functions where possible")
Reported-by: Svyatoslav Ryhel <clamor95@gmail.com>
Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # LG P895
Enable bloblist on vexpress64 platforms to facilitate information
passing from TF-A using the firmware handoff framework.
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
When the configuration option CONFIG_BLOBLIST_PASSAGE is selected, the
bloblist present in the incoming standard passage is utilised in-place.
There is no need to specify the size of the bloblist as the system
automatically detects it using the header information.
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
When booting into the Linux kernel with semi-hosting, use the device
tree provided by hardware unless one is provided in the current
directory.
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
This patches tidies up a few things in the recently added EFI app for
ARM:
- Use 0 as the value for SYS_LOAD_ADDR
- Reword help for TARGET_EFI_ARM_APP64
- Do the same for x86-app targets, for consistency
- Delete efi-arm_app32 MAINTAINERS entry since there is no such thing
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Caleb Connolly <caleb.connolly@linaro.org>
If a series is sent without a cover letter, there is no indication of
the base commit. Add support for this, since single patches of small
series may not always have a cover letter.
Signed-off-by: Simon Glass <sjg@chromium.org>
VPL has the same needs as TPL in situations where the stack is at the
top of SRAM. Add an option for this and implement it for arm
Series-changes: 2
- Reply on existing CONFIG_VAL() to select the VPL stack
- Correct reference to TPL when VPL was intended
Series-changes: 3
- Use 'phase' instead of 'stage' in VPL_STACK
- Split off into its own 'vbh' series
Series-to: u-boot
Series-version: 3
Series-cc: jonas
Cover-letter:
xPL-stack cleanup
This series was split from the VBE part H series. It adjusts the logic
for selecting the top of the stack so that it is more consistent across
xPL phases.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
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>
Provide a -A flag to select ARM instead of x86. For now, only the app
is supported and only for 64-bit ARM.
Signed-off-by: Simon Glass <sjg@chromium.org>
Introduce an EFI app for arm64 and update the documentation.
Provide a value for LOAD_ADDR to avoid a link error.
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>
As opposed to the payload, which is built normally with just an EFI
stub, the app is build homogenously using EFI flags. Update
PLATFORM_CPPFLAGS to enable this.
Signed-off-by: Simon Glass <sjg@chromium.org>
This feature should not be used with the app, since we don't know where
U-Boot will be loaded. Disable it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
The app should be built as a shared library, with position-independent
code and the -shared flags. Update the Makefile to handle this.
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>
Adjust the conditions to support the EFI app when running on ARM.
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 option cannot be used with a shared library, since it results in
everything being removed. Disable it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
It isn't worth the hassle of omitting this field for the app, since code
is shared between the payload and the app. Adjust the condition to avoid
a build error in the 'efi' command with the app on 64-bit ARM.
Signed-off-by: Simon Glass <sjg@chromium.org>
The switch_to_non_secure_mode() function cannot be used since EFI is in
charge of managing exception-levels.
Build just the exceptions.S file.
Modify the existing SPL rule to cater to the EFI app too.
This is quite confusing, so add an issue to clean this up:
https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/36
Signed-off-by: Simon Glass <sjg@chromium.org>
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 EFI app likes to use a simple variable for global data. Implement
this for ARM (for use only with 64-bit ARM at present).
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
The previous bootloader has already set up the cache, 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 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>
The app does not have this symbol. Also the memory where the app is
loaded is not under U-Boot's control.
There is no sense in relocating from one alloced region to another.
U-Boot is not able to relocate to the top of memory, nor decide what
other parts of memory are used for.
For these reasons, the EFI app skips relocation. It is not running at
the address pointed to by the _start symbol.
So disable this reservation for the EFI app.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
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>
Use the available functions for setting and getting the global_data
pointer so that EFI-startup can operate on 64-bit ARM as well as x86.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present only x86 supports the EFI app and (apart from Qualcomm) the
payload. In preparation for supporting 64-bit ARM more generally, rename
the existing ARCH_EFI option to ARCH_EFI_X86, using that to define a
generic ARCH_EFI which will be enabled for all architectures.
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>
This code is not actually x86-specific, so move it into the lib/efi dir
where other archs can use it.
Drop inclusion of the unnecessary x86-specific header.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
So far only x86 supports the EFI app. ARM is going the same way, so
allow these options to be enabled for 64-bit ARM too.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Since we plan to support the EFI app and payload on 64-bit ARM too,
rename the x86 target.
Adjust the Kconfig rules to allow non-x86 builds to be added.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
This function calls dm_pci_read_bar32() which is only available if PCI
is enabled. Add this condition here too, so that the EFI app can build
without needing --gc-sections
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
There is no need to use the global struct provided by PCI. Declare a
local structure instead, so this can be used on ARM without including
support for PCI ROMs.
Signed-off-by: Simon Glass <sjg@chromium.org>
This helper is used by the EFI driver and we would like to use that on
ARM. Move the helper function into its own file, separate from PCI ROMs,
which are an x86 thing.
Add a forward declaration for struct udevice so that the header can be
included directly.
Signed-off-by: Simon Glass <sjg@chromium.org>
This value is not available with the EFI app. Add a condition to avoid
introducing errors when linking.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
When BLOBLIST_TABLES is used, the ACPI tables are not currently added to
the list of EFI tables. While we don't want to create a new memory
region, we do want to tell EFI about the tables.
Fix this by covering this case. At some point the non-bloblist code can
likely be removed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 3da59ee957 ("efi_loader: Avoid mapping the ACPI tables twice")
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Get tpm event log from bloblist instead of FDT when bloblist is
enabled and valid from previous boot stage.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
