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.
Christian Marangi <ansuelsmth@gmail.com> says:
This series is a reworked version of the previous seried:
misc: introduce STATUS LED activity function
This series port and expand the legacy concept of LED boot from
the legacy Status LED API to new LED API.
One thing that many device need is a way to communicate to the
user that the device is actually doing something.
This is especially useful for recovery steps where an
user (for example) insert an USB drive, keep a button pressed
and the device autorecover.
There is currently no way to signal the user externally that
the bootloader is processing/recoverying aside from setting
a LED on.
A solid LED on is not enough and won't actually signal any
kind of progress.
Solution is the good old blinking LED but uboot doesn't
suggest (and support) interrupts and almost all the LED
are usually GPIO LED that doesn't support HW blink.
Additional Kconfg are also introduced to set the LED boot and
activity. Those are referenced by label.
A documentation for old and these new LED API is created.
Expand ofnode options test with new generic helper for bool, int and
string.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add tests for LED boot and activity feature and add required property in
sandbox test DTS.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Simon Glass <sjg@chromium.org> says:
This series includes the patches needed to make make the EFI 'boot' test
work. That test has now been split off into a separate series along with
the EFI patches.
This series fixes these problems:
- sandbox memory-mapping conflict with PCI
- the fix for that causes the mbr test to crash as it sets up pointers
instead of addresses for its 'mmc' commands
- the mmc and read commands which cast addresses to pointers
- a tricky bug to do with USB keyboard and stdio
- a few other minor things
An address may be mapped twice and unmapped twice. Delete the mapping
only when the last user unmaps it.
Fix a missing comment while here.
Signed-off-by: Simon Glass <sjg@chromium.org>
So far unmapping has not been implemented. This means that if one test
maps a pointer to an address with map_sysmem(), then a second test can
use that same pointer, by mapping the address back to a pointer with
map_to_sysmem(). This is not really desirable, even if it doesn't
cause any problems at the moment.
Implement unmapping, to clean this up.
Signed-off-by: Simon Glass <sjg@chromium.org>
Sandbox keeps a table of addresses which map to pointers which are
outside its emulated DRAM. The current range from 10000000 conflicts
with the PCI range, meaning that if PCI mapping is on, that particular
address can be decoded by PCI instead of the table.
Fix this by moving the range up to the top of memory. Update the docs
while we are here.
Signed-off-by: Simon Glass <sjg@chromium.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).
The sandbox iommu driver uses the LMB module to allocate a particular
range of memory for the device virtual address(DVA). This used to work
earlier since the LMB memory map was caller specific and not
global. But with the change to make the LMB allocations global and
persistent, adding this memory range has other side effects. On the
other hand, the sandbox iommu test expects to see this particular
value of the DVA. Use the DVA address directly, instead of mapping it
in the LMB memory map, and then have it allocated.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Initialise the ram bank information for sandbox in SPL. The ram bank
information gets initialised as part of the SPL initialisation
sequence in board_init_r(), which is then used for adding available
memory to the LMB memory map.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The TCG event log buffer is being set at the end of ram memory. This
region of memory is to be reserved as LMB_NOMAP memory in the LMB
memory map. The current location of this buffer overlaps with the
memory region reserved for the U-Boot image, which is at the top of
the usable memory. This worked earlier as the LMB memory map was not
global but caller specific, but fails now because of the overlap.
Move the TCG event log buffer to the start of the ram memory region
instead. Move the location of the early trace buffer and the load
buffer for U-Boot(spl boot) accordingly.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
The sandbox pinmux driver is used in the non-test devicetree as well as
the test one. I didn't realize this when I modified the driver for
tests, and so broke the regular use case (which only resulted in
warnings). First, making the pinmux and the UART group available
pre-relocation to avoid ENODEV errors. Then, convert the pin groups and
functions to the new style, adding onewire group as well.
Fixes: 7f0f1806e3 ("test: pinmux: Add test for pin muxing")
Closes: https://source.denx.de/u-boot/u-boot/-/issues/2
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Rather than having every caller set this up individually, create a
common init function. This allows new fields to be added without the
risk of them being left uninited.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Add support for loading a UPL image from SPL. This uses the simple FIT
implementation, but also loads the full FIT just to permit more testing.
Signed-off-by: Simon Glass <sjg@chromium.org>
UPL significantly alters the boot flow for sandbox. Add a flag to enable
this so that it can be enabled only on tests which need it.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is possible for U-Boot functions such as printf() to be called
within state_init(). This can end up checking gd->flags (e.g. in putc())
before global_data is set up.
Move the setup earlier to avoid this. This fixes the suppression of some
debug output in memory allocation (when enabled).
Signed-off-by: Simon Glass <sjg@chromium.org>
The existing API for these functions is different from the rest of
U-Boot, in that any error code must be obtained from the errno variable
on failure. This variable is part of the C library, so accessing it
outside of the special 'sandbox' shim-functions is not ideal.
Adjust the API to return an error code, to avoid this. Update existing
uses to check for any negative value, rather than just -1.
Signed-off-by: Simon Glass <sjg@chromium.org>
Since the removal of OF_HOSTFILE logic in board_fdt_blob_setup(), the
logic for obtaining the DT is handled in the OF_BOARD option. If a
devicetree comes from a bloblist it is immediately overwritten by this
function.
Fix this by skipping the function if a devicetree is already present.
This is sort-of a fix for e7fb7896 ("sandbox: Remove OF_HOSTFILE") but
it has only come to light since bloblist was added, so I have not added
a Fixes tag.
Unfortunately it is not possible to report the correct FDT source with
the current code. It might be best to use an error-return code for
board_fdt_blob_setup() so that an error can be reported if the board
does not provide the DT.
Signed-off-by: Simon Glass <sjg@chromium.org>
This code is useful for loading an image in sandbox_spl so move it into
a place where it can be called as needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
The argument array is not changed by the callee, so mark it const.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Add a unit test for testing the Android bootmethod.
This requires another mmc image (mmc7) to contain the following partitions:
- misc: contains the Bootloader Control Block (BCB)
- boot_a: contains a fake generic kernel image
- vendor_boot_a: contains a fake vendor_boot image
Also add BOOTMETH_ANDROID as a dependency on sandbox so that we can test
this with:
$ ./test/py/test.py --bd sandbox --build -k test_ut # build the mmc7.img
$ ./test/py/test.py --bd sandbox --build -k bootflow_android
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Julien Masson <jmasson@baylibre.com>
Reviewed-by: Guillaume La Roque <glaroque@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
commit 6e2228fb05 ("Merge patch series "Clean up arm linker scripts"")
was cleaning up linker scripts for armv7 and v8 in a similar fashion.
Several commits in the past -- e.g
commit d0b5d9da5d ("arm: make _end compiler-generated")
was moving symbols to be compiler generated. They were defined as c
variables in its own section to force the compiler emit relative a
reference. However, defining those in the linker script will do the
same thing since [0].
So let's remove the special sections from the linker scripts, the
variable definitions from sections.c, and define them as a symbols.
It's worth noting that the linker was discarding the symbols in the
older binary completely since the symbol definition had an extra _.
- new binary
$~ aarch64-linux-gnu-readelf -sW u-boot | grep efi_runtim
246: 000000000004acbe 13 FUNC LOCAL DEFAULT 14 vbe_req_efi_runtime_rand
3198: 0000000000318690 16 OBJECT LOCAL DEFAULT 29 efi_runtime_mmio
6359: 00000000000dedff 217 FUNC LOCAL DEFAULT 14 efi_runtime_relocate
7942: 00000000003074c0 136 OBJECT GLOBAL HIDDEN 29 efi_runtime_services
8869: 0000000000305e20 0 NOTYPE GLOBAL DEFAULT 27 __efi_runtime_rel_stop
9159: 0000000000305e20 0 NOTYPE GLOBAL DEFAULT 27 __efi_runtime_stop
9410: 0000000000305e20 0 NOTYPE GLOBAL DEFAULT 27 __efi_runtime_start
10137: 00000000005981bd 0 NOTYPE WEAK HIDDEN 33 efi_runtime.c.de5bed54
10470: 0000000000305e20 0 NOTYPE GLOBAL DEFAULT 27 __efi_runtime_rel_start
- old binary
$~ aarch64-linux-gnu-readelf -sW u-boot.old | grep efi_runtim
246: 000000000004acbe 13 FUNC LOCAL DEFAULT 14 vbe_req_efi_runtime_rand
3198: 0000000000318690 16 OBJECT LOCAL DEFAULT 29 efi_runtime_mmio
6359: 00000000000dedff 221 FUNC LOCAL DEFAULT 14 efi_runtime_relocate
7942: 00000000003074c0 136 OBJECT GLOBAL HIDDEN 29 efi_runtime_services
10135: 0000000000598320 0 NOTYPE WEAK HIDDEN 33 efi_runtime.c.de5bed54
$~ bloat-o-meter u-bool.old u-boot
add/remove: 0/0 grow/shrink: 1/1 up/down: 7/-4 (3)
Function old new delta
efi_memory_init 343 350 +7
efi_runtime_relocate 221 217 -4
Total: Before=2009902, After=2009905, chg +0.00%
[0] binutils commit 6b3b0ab89663 ("Make linker assigned symbol dynamic only for shared object")
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> # sandbox_defconfig on amd64, arm64, riscv64
Reviewed-by: Simon Glass <sjg@chromium.org>
Fixes: commit aac53d3d96 ("sandbox: Rename EFI runtime sections")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
When writing an executable, allowing other users to modify it introduces
a security issue.
Generally we should avoid giving other users write access to our files by
default.
Replace chmod(777) by chmod(755) and chmod(644).
Fixes: 47f5fcfb41 ("sandbox: Add os_jump_to_image() to run another executable")
Fixes: d9165153ca ("sandbox: add flags for open() call")
Fixes: 5c2859cdc3 ("sandbox: Allow reading/writing of RAM buffer")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Sean Anderson <seanga2@gmail.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>
This follows the example of RISC-V where <asm/global_data.h> includes
<asm/u-boot.h> directly as "gd" includes a reference to bd_info already
and so the first must include the second anyhow. We then remove
<asm/u-boot.h> from all of the places which include references to "gd"
an so have <asm/global_data.h> already.
Signed-off-by: Tom Rini <trini@konsulko.com>
If open() fails it returns -1. Calling close() with this value
makes no sense. Return -EIO instead.
Addresses-Coverity-ID: 185828 Improper use of negative value
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Fixes: 566bf3a869 ("sandbox: Add a function to read a host file")
Reviewed-by: Sean Anderson <seanga2@gmail.com>
Mentions that command line option --signal is needed to make use of this
configuration option.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Instead of checking a configuration setting in booti_start() adjust the
sandbox implementation of booti_setup().
Write a console message when trying to run the booti command on the sandbox
indicating that it is not supported.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
We should check the return value of fcntl().
Addresses-Coverity-ID: 131108 ("Unchecked return value from library")
Addresses-Coverity-ID: 131109 ("Unchecked return value from library")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Simon Glass <sjg@chromium.org> says:
This series is the culmanation of the current line of refactoring
series. It adjusts pxe to call the booting functionality directly
rather than going through the command-line interface.
With this is is possible to boot using the extlinux bootmeth without
the command line enabled.
It also updates fastboot to do a similar thing.
Allow these functions to be compiled in when CONFIG_BOOTM is enabled,
even if CONFIG_CMD_BOOTM is not.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Angelo Dureghello <angelo@kernel-space.org>
efi_default_filename.h requires HOST_ARCH to be defined. Up to now we
defined it via a CFLAGS. This does not scale. Add the symbol to
version_autogenerated.h instead.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Currently, all the capsules for the sandbox platform are generated at
the time of running the capsule tests. To showcase generation of
capsules through binman, generate all raw(non FIT payload) capsules
needed for the sandbox platform as part of the build. This acts as an
illustrative example for generating capsules as part of a platform's
build.
Make corresponding change in the capsule test's configuration to get
these capsules from the build directory.
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
