The video sync sometimes takes 8ms on this board when running under
emulation, so increase the limit to 15ms.
Signed-off-by: Simon Glass <sjg@chromium.org>
Before booting using extlinux we must add the memory map to the FDT.
Provide a ft_system_setup() function to handle this.
To determine the memory size, scan the memory map looking for entries
that look like real memory.
Signed-off-by: Simon Glass <sjg@chromium.org>
When booting an OS with a large ramdisk, we need enough memory to load
it. Expand the app's memory to 512M to allow this.
Signed-off-by: Simon Glass <sjg@chromium.org>
When extlinux is used, the boot partition is often 2, which is ignored.
Use the 'bootflow scan' -p flag to resolve this.
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")
When running under QEMU the FDT is available at the start of RAM. Set
fdt_addr to this address, so that the FDT can be passed onto the OS.
If the OS provides its own devicetree, that is used instead of the QEMU
one.
Signed-off-by: Simon Glass <sjg@chromium.org>
When the app is booting a kernel without using EFI, it must first exit
the boot services provided by EFI. Add a hook for this, using
bootm_final()
Signed-off-by: Simon Glass <sjg@chromium.org>
It is common to run the EFI app without a display, e.g. for testing.
Drop the unwanted warnings about this:
EFI graphics output protocol not found (err=-524)
No video mode configured in EFI!
Signed-off-by: Simon Glass <sjg@chromium.org>
It is sometimes useful to display the memory type in logs, etc. Add a
function to convert it to a string, which is more user-friendly than a
number.
Signed-off-by: Simon Glass <sjg@chromium.org>
The 'efi mem' command dumps out the memory map. This is useful within
the app, even if commands are not enabled, so move it to a common file.
Rename it from 'print' to 'dump' since most things that dump information
use that word.
Signed-off-by: Simon Glass <sjg@chromium.org>
We can never hope to have a definitive list of GUIDs, but add four more,
discovered when booting from QEMU on ARM.
Signed-off-by: Simon Glass <sjg@chromium.org>
The declarations in efi_api.h are inconsistent. Tidy them up, so that
the final 8 bytes appear on their own line aways.
Signed-off-by: Simon Glass <sjg@chromium.org>
The EFI serial driver checks for keypresses but does not allow other
events to be processed. For devices which have a USB keyboard, the USB
message must be processed before any keys can emerge for the serial
driver to pick up.
Add a periodic timer to the list of events. This allows the keyboard to
work on Qualcomm laptops, for example.
Series-changes: 2
- Add a comment to serial_efi_get_key() about the 1ms delay
Signed-off-by: Simon Glass <sjg@chromium.org>
This function is not called from the app at present. Even if it were, it
would be called later, after stdio is working, so there is no need to
use printhex2() and the like.
Move the function into the stub.
Signed-off-by: Simon Glass <sjg@chromium.org>
When running in CI it is better to specify the build directory rather
than provide a device. Add a --build-dir option.
Signed-off-by: Simon Glass <sjg@chromium.org>
In some cases a board may wish to do some final processing before
starting the OS. An example is the EFI app, which may wish to call
exit-boot-services.
Add an event to permit this.
Series-to: concept
Cover-letter:
boot: Allow lmb-allocation of compression buffer with booti
ARM 'booti' images (as created by Linux 'make Image') typically need to
be compressed. At present the decompression buffer is described by a
pair of environment variables: kernel_comp_addr_r and kernel_comp_size
This is quite inflexible, since the buffer size and location must be
pre-set in the environment, before the OS size is known.
For the EFI app, it is quite difficult to work with a fixed buffer. It
is not in control of the memory map so it may be that the requested
buffer address is not available.
This series updates the boot implementation to allow the variables to
be omitted, with lmb allocations done in this case. This resolves the
problem in the EFI app, with kernels which come from extlinux.conf
When the EFI app loads another app, a similar problem is present, but
with the EFI bootmeth, also resolved in this series.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
Unfortunately no one else has taken up this migration. For now, reword a
a comment to more correctly describe what the event uses.
Signed-off-by: Simon Glass <sjg@chromium.org>
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>
The app cannot know the address to use in advance, so does not have a
value for kernel_addr_r in its environment, if it even has an
environment.
Allocate memory for the kernel instead. Limit it to 64MB which seems
like plenty for the distros out there. It is enough to load a full
kernel 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>
Converting back and forth between a string and a ulong does not make
much sense. Simplify the code by adding a separate value for the kernel
address.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function is needlessly convoluted, reading the kernel address as a
string, possibly adding the FIT configuration, then parsing that to
obtain the kernel address again.
Create a kern_addr variable to hold the kernel address, so we can
simplify the code.
Signed-off-by: Simon Glass <sjg@chromium.org>
We normally require environment variables when loading files using PXE/
syslinux. This is not really necessary, since we can use lmb to find a
suitable space.
Add support for reserving space in get_relfile_envaddr(), which is the
commonly used function for reading a file. Use env_get() so no error is
shown if the environment variable does not exist.
Signed-off-by: Simon Glass <sjg@chromium.org>
It doesn't seem worth allocating space for a label when it is normally
going to be under 20 characters. Use a fixed-sized string (with plenty
of space) instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
This is a string, so add a string suffix to make that clear.
Switch the assignment order in label_run_boot(), since the FDT is loaded
after the kernel.
Signed-off-by: Simon Glass <sjg@chromium.org>
Several of the strings in this struct would be better off as addresses,
now that they are passed around a fair bit.
Start by converting initrd_addr_str to ulong
Signed-off-by: Simon Glass <sjg@chromium.org>
Update this function to return the address obtained from the environment
variable. That will allow the caller to know where the image ended up.
For now this is not used.
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>
In some cases we don't have a particular address to read into so would
like one reserved. Adjust this function to support that.
Signed-off-by: Simon Glass <sjg@chromium.org>
In some cases we don't have a particular address to read into so would
like one reserved. Adjust this function to support that.
For now, sysbot_read_file() fails if the address is not provided. This
will be resolved in a later patch.
Signed-off-by: Simon Glass <sjg@chromium.org>
In some cases we don't have a particular address to read into so would
like one reserved. Adjust the read_file() method to support this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some callers may want a maximum size smaller than 1G so add a parameter
for the caller to use.
Series-to: concept
Cover-letter:
Continue development of the EFI app (part A)
This series expand the EFI app to include more of the required
functionality for booting:
- access to device-path functions
- disable networking (to be dealt with later)
- rename BOOTMETH_EFI_LOADER since this should be usable by the app
- move towards getting EFI booting going in the app
- various script improvemens to support continued development
END
Signed-off-by: Simon Glass <sjg@chromium.org>