lmb_reserve() is just calling lmb_reserve_flags() with LMB_NONE.
There's not much we gain from this abstraction.
So let's remove the latter, add the flags argument to lmb_reserve()
and make the code a bit easier to follow.
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Tested-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
(cherry picked from commit 900a8951c3)
Rather than always going through this state, require callers to
explicitly request it. This will allow the option to be enabled without
affecting the boot, unless the user expressly requests it.
Signed-off-by: Simon Glass <sjg@chromium.org>
This feature was designed for tracing but can be useful for debugging
too, since it is possible to examine the state of the system just before
handing off to the OS.
Provide a separate CONFIG_BOOTM_FAKE_GO option to allow this feature to
be used separate from tracing. Enable it for the EFI app.
Signed-off-by: Simon Glass <sjg@chromium.org>
This shows an image type as an OS, which is not correct. Fix it up to
show both.
Series-changes: 2
- Add a colon so it is clear that 'load_os type' is not a compound term
Signed-off-by: Simon Glass <sjg@chromium.org>
The conversion to using an event was not done correctly, with the
result that it has no effect. Fix it, by passing in the length and
actually using the returned address.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 207bf34de7 ("boot: efi: Use an event to relocate the OS")
This function is very simple at present, only supporting a fixed buffer
of a fixed size.
For cases where the address is not provided, we may still want to set a
limit on the size.
Support lmb reservation of an existing buffer as using lmb to reserved a
new buffer. Use the provided size information to select a suitable size
for the decompression buffer.
Signed-off-by: Simon Glass <sjg@chromium.org>
If the OS size is not known, or zero, refuse to decompress it.
Note that the 'booti' command does not have this information, but in
that case, kernel loading is handled by its own function called
booti_start()
Signed-off-by: Simon Glass <sjg@chromium.org>
The size of the loaded OS file can be useful when decompressing, or to
check that the. FIT image matches its size. Add an os_size field for
this in struct bootm_info so it can be recorded.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some environment variables affect the operation of bootm. Reading these
variables is buried within the boot code at present.
Ideally this information should be in struct bootm_info so that it can
be provided directly, without needing the environment variables. Also it
should support allocation if the variables are not provided.
As a first step towards this, add an explicit read of the variables,
storing the values. For now this only covers kernel_comp_addr_r and
kernel_comp_size
Signed-off-by: Simon Glass <sjg@chromium.org>
The bootm code handles a large number of variables. It is helpful to be
able to see which code paths are taken, when something doesn't work as
expected.
Add some debugging which can be enabled if needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present this function only uses two fields, but it also needs to
access the kernel-compression info. In preparation for that, pass in the
whole struct.
Series-to: concept
Series-cc: heinrich
Cover-letter:
boot: Start to remove dependency on kernel_addr_r etc.
Before bootstd, boot scripts were used to boot distros. These worked by
using a 'load' command to load a file and a 'bootm' command to boot.
Obviously these commands need addresses, so the approach taken was to
define a number of environment variables to provide them, for the
various situations. These are documented at [1].
With bootstd, booting is built into U-Boot so there is no real need for
these variables. Also, bootstd records all loaded images in a list, so
knows where and what they are.
However, since bootstd uses much of the same code as the bootm command,
for example, to date it has used these same variables.
This is OK to some extent, since boards maintainers have got used to the
need to statically configure the addresses used for a kernel, ramdisk,
devicetree, etc. But is does cause problems:
- since the kernel and initrd can grow quite a bit from year to year,
sometimes the values need to be updated to save space [2]
- some boards don't have fixed addresses (such as the EFI app)
- fixed values means that much more space must be provided than is
normally needed; for this reason the ramdisk is generally at the
highest address
The variables do have some benefit, e.g. for people who want things
loaded at a known location, so it makes sense to keep them around. But
they should be optional.
This series starts the process of removing the requirement for these
variables, focussing on the extlinux code. It mostly consists of
refactoring.
Several functions are updated to support lmb reservation. At least for
filesystems, bootstd can query the file size and use lmb to reserve the
required amount of (aligned) memory. The bootmeth read_file() method is
updated to handle this. When decompressing, bootm is updated to support
reservation (instead of an address) for the decompressed file.
With these in place, various patches are provided to work this new
feature into the pxe_utils code used by extlinux.
The next step after this is to attack the bootm code itself, so that the
struct bootm_info controls the addresses, without any environment
variables. That will be the subject of the next series.
[1] https://docs.u-boot.org/en/latest/develop/distro.html#required-environment-variables
[2] https://patchwork.ozlabs.org/project/uboot/patch/20241220003447.2913443-5-sjg@chromium.org/
END
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide some helper functions which can set the string value of a field
in struct bootm_info from an address.
Signed-off-by: Simon Glass <sjg@chromium.org>
Normally bootm proceeds sequentially through the various states, from
'start' to 'go'.
In some cases we want to load the devicetree from one FIT and the kernel
and ramdisk from another. This requires two bootm commands.
Of course it is possible to just do a second 'bootm start' to load the
kernel. But that removes all record of the devicetree from the
boot_images information, so it is then not provided to the OS.
Add a 'restart' subcommand which allows more images to be loaded,
without erasing those already loaded.
If an error is returned, leave the return arguments alone. There is no
point in setting them to zero, since the caller already knows (from the
error code) that they are not being returned.
This makes things simpler for callers which have an existing ramdisk.
Handle the -ENOPKG error code in bootm_find_images()
Signed-off-by: Simon Glass <sjg@chromium.org>
Since 'select' is already assigned in the declarations for this
function, there is no need to do it again. Drop the duplicate
assignment.
Signed-off-by: Simon Glass <sjg@chromium.org>
Move disabling of interrupts to bootm_final() so it is done for bootm
and EFI boot paths. Drop the now-duplicate calls.
Signed-off-by: Simon Glass <sjg@chromium.org>
The logic in bootm to re-enable interrupts if the OS fails to boot does
not seem very useful, since the board resets immediately afterwards.
Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Rather than a weak function, use the recently added event to adjust the
OS load-address. Tidy up the code a little while here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Currently, when decompressing a gzip-compressed image during bootm, a
generic error such as "inflate() returned -5" is shown when the buffer is
too small. However, it is not immediately clear that this is caused by
CONFIG_SYS_BOOTM_LEN being too small.
This patch improves error handling by:
- Detecting Z_BUF_ERROR (-5) returned from the inflate() call
- Suggesting the user to increase CONFIG_SYS_BOOTM_LEN when applicable
- Preserving the original return code from zunzip() instead of overwriting
it with -1
By providing clearer hints when decompression fails due to insufficient
buffer size, this change helps users diagnose and fix boot failures more
easily.
Signed-off-by: Aristo Chen <aristo.chen@canonical.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
The booti command does not use the CONFIG_SYS_BOOTM_LEN value and
instead sets a maximum decompression-buffer size of 10x the size of the
compressed data.
Add this as an option in bootm_load_os() so that booting without the
command-line works in the same way as the 'booti' command.
Link: https://lore.kernel.org/u-boot/2ad3b1c5-b6e7-47e2-b225-834b821cc5c4@kwiboo.se/
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Fixes: b13408021d ("boot: pxe: Use bootm_...() functions where possible")
RISC-V uses a similar linux 'Image' format to ARM64, so add support for
it in bootm_load_os()
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Move this logic into a function so we can give it a sensible name.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
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
A compressed booti image relies on the compression-format's header at
the start to indicate which compression algorithm is used.
We don't support this elsewhere in U-Boot, so assume that a compressed
file is always a booti file. Once it is decompressed, a check is made to
make sure that it actually is.
Simplify the implementation by adding a new function which returns the
booti image-type if compression is detected.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the booti format is handled separately, in its own command.
Provide a way to boot uncompressed booti images within the bootm code,
so that eventually we can boot these images without CONFIG_CMDLINE
Update bootm_init() to attach the images for all formats which use them.
Add some debugging while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
This code cannot be compiled by boards which don't have this option. Add
an accessor in the header file to avoid another #ifdef
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
We want to jump into the EFI stub in the kernel so it can perform
appropriate init and call ExitBootServices. Add support for doing that,
including ensuring that we copy the kernel to somewhere that's not
currently being used by the firmware.
Signed-off-by: Matthew Garrett <mgarrett@aurora.tech>
Reviewed-by: Simon Glass <sjg@chromium.org>
Drop use of image_info_t:
Signed-off-by: Simon Glass <sjg@chromium.org>
All three addresses printed are in hexadecimal format, but only the
first two have the "0x" prefix. The patch aligns the format of the
"end" address with the other two by adding the "0x" prefix.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Remove a couple of superfluous LMB stub functions, and instead put a
check for calling the lmb_reserve() function.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
With the move to make the LMB allocations persistent and the common
memory regions being reserved during board init, there is no need for
an explicit reservation of a memory range. Remove the
lmb_init_and_reserve_range() function.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
With the introduction of separate config symbols for the SPL phase of
U-Boot, the condition checks need to be tweaked so that platforms that
enable the LMB module in SPL are also able to call the LMB API's. Use
the appropriate condition checks to achieve this.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-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()]
USB is stopped using driver model now, in dm_remove_devices_flags() in
announce_and_cleanup() at the top of this file.
The usb_stop() call actually unbinds devices.
When a USB device is unbound, it causes any bootflows attached to it to
be removed, via a call to bootdev_clear_bootflows() from
bootdev_pre_unbind(). This obviously makes it impossible to boot the
bootflow.
However, when booting a bootflow that relies on USB, usb_stop() is
called, which unbinds the device. At that point any information
attached to the bootflow is dropped.
This is quite risky since the contents of freed memory are not
guaranteed to remain unchanged. Depending on what other options are
done before boot, a hard-to-find bug may crop up.
Drop the call to this old function.
Leave the netconsole call there, since this needs conversion to
driver model.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Shantur Rathore <i@shantur.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
commit 97707f12fd ("tpm: Support boot measurements") moved out code
from the EFI subsystem into the TPM one to support measurements when
booting with !EFI.
Those were moved directly into the TPM subsystem and in the tpm-v2.c
library. In hindsight, it would have been better to move it in new
files since the TCG2 is governed by its own spec, it's overeall cleaner
and also easier to enable certain parts of the TPM functionality.
So let's start moving the headers in a new file containing the TCG
specific bits.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The PC client spec [0], doesn't describe measurements for DTBs. It does
describe what do to for ACPI tables though.
There is a description for ACPI in 3.3.4.1 PCR[0] – SRTM, POST BIOS,
and Embedded Drivers and they explicitly mention ACPI in there. There's
no mention of ACPI in 3.3.4.2 PCR[1] – Host Platform Configuration.
However, in Figure 6 -- PCR Mapping of UEFI Components ACPI is shown
in PCR1. The general description also mentions PCR0 is for code and PCR1
is for data such as ACPI and SMBIOS.
So let's switch over the DTB measurements to PCR1 which seems a better
fit.
[0] https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Eddie James <eajames@linux.ibm.com>
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d, reversing
changes made to 2ee6f3a5f7.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
Change type of ulong env_get_bootm_low() to phys_addr_t env_get_bootm_low().
The PPC/LS systems already treat env_get_bootm_low() result as phys_addr_t,
while the function itself still returns ulong. This is potentially dangerous
on 64bit systems, where ulong might not be large enough to hold the content
of "bootm_low" environment variable. Fix it by using phys_addr_t, similar to
what env_get_bootm_size() does, which returns phys_size_t .
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Sometimes the kernel is built as an EFI application rather than a
binary. We still want to support compression for this case.
For arm64 the entry point is set later in the bootm_load_os() function,
since these images are typically relocated due to the 2MB-alignment
requirement of arm64 images. But since the EFI image is not in the same
format, we need to update the entry point earlier.
Set the entry point always, for kernel_noload to resolve this problem.
It should be harmless to do this always.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass <sjg@chromium.org> says:
This series continues refactoring the bootm code to allow it to be used
with CONFIG_COMMAND disabled. The OS-handling code is refactored and
a new bootm_run() function is created to run through the bootm stages.
This completes the work.
A booti_go() function is created also, in case it proves useful, but at
last for now standard boot does not use this.
This is cmdd (part d of CMDLINE refactoring)
It depends on dm/bootstda-working
which depends on dm/cmdc-working
Create a common function used by the three existing bootz/i/m_run()
functions, to reduce duplicated code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
In a few places, the booti command is used to handle a boot. We want
these to be done without needing CONFIG_CMDLINE, so add a new
booti_run() function to handle this.
So far this is not used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
In a few places, the bootz command is used to handle a boot. We want
these to be done without needing CONFIG_CMDLINE, so add a new
bootz_run() function to handle this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
