Add a new event that is triggered in main_loop() before
autoboot_command(). This allows platform code to provide a custom
bootcmd string via the event system.
The event uses struct event_bootcmd which provides a buffer for the
bootcmd string and its size. Platform event handlers can write their
custom bootcmd to this buffer.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add support for pressing 'Q' to put the pager into bypass mode,disabling
further paging for the current session.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
The pager should be bypassed if the terminal was not detected. Fix the
condition which actually says the opposite.
Also fix a long line in pager_post()
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a new mark_start() method for the console, which indicates that the
CLI prompt has been written to the display and any following characters
will be user input.
There are two cases to consider, tracked by an indent flag in
struct vidconsole_cursor:
- normal CLI entry where new lines start at the left of the console
- expo entry where new lines start at the same position as the previous
line (indent=true)
Record this position in the uclass info, so it is available to console
drivers.
Signed-off-by: Simon Glass <sjg@chromium.org>
When using a debugger it is common to single step through functions. If
one of those functions happens to be called from a cyclic function, then
a warning messages is shown. When debugging the console itself, this can
mess up the session.
Add a Kconfig to control whether the message is shown. Disable it by
default if CONFIG_CC_OPTIMIZE_FOR_DEBUG is enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
In the case of the shared/static libraries, the _end and _init symbols
are not necessarily provided since the linker script is provided by the
program which links against the U-Boot library.
In some cases the memory size can show up as less than available memory,
but enough that there is insufficient memory for U-Boot to start.
It seems better to just set the mon_len to 0 for the library.
Series-to: concept
Series-cc: heinrich
Signed-off-by: Simon Glass <sjg@chromium.org>
This fix turns out to be insufficient in the corner case where mon_len
is smaller than available, emulated RAM but large enough that there
isn't enough left.
This reverts commit 88b810e241.
The application may not wish to use networking, so avoid setting it up
and the associated console output.
Signed-off-by: Simon Glass <sjg@chromium.org>
By default U-Boot shows the console settings on startup, e.g.:
In: serial,vidconsole
Out: serial,vidconsole
Err: serial,vidconsole
These messages are useful for the user but not for an application using
U-Boot as a library. Disable them.
Signed-off-by: Simon Glass <sjg@chromium.org>
The API is not very useful these days, since it doesn't support driver
model. It is laborious to add new functions to the API as there are so
many needed.
A better approach would be to create a library containing all of U-Boot,
then have the API be generated by a script containing a list of
functions, perhaps with wildcards. Then a stub could be created, with
a list of entry points, which links with and calls through into the
library.
In preparation for heading in this direction, rename some of the
existing files and directories:
- examples/api -> examples/legacy_api
- include/api*.h -> include/legacy_api*.h
- API_BUILD to LEGACY_API_BUILD
Co-developed-by: Claude <noreply@anthropic.com>
When using the library it should start up silently. Drop the
driver model message about the number of devices, etc.
Series-to: concept
Series-cc: heinrich
Cover-letter:
ulib: Introduce building U-Boot as a shared library
U-Boot is currently built as a monolithic binary. While there is an API
of sorts, allowing U-Boot to be called from another program, it is not
widely used.
In some cases it is useful to write a separate program which is in
control of the boot process, but uses U-Boot to implement some of the
functionality.
Some examples are:
- Creating a main program written in a different language, such as Rust
or Python
- For Python specifically, an interface on top of U-Boot would permit
direct execution of sandbox tests
- For Rust specifically, it could make it feasible to progressively
rewrite U-Boot in Rust, if that were desirable
- For testing, it would permit tests to be in control of execution,
rather than being embedded within U-Boot itself
This series begins the progress of supporting U-Boot as a shared
library. At this point the functionality is very limited:
- it targets sandbox only
- the test program simply starts U-Boot and boots to a prompt
Future work will build on this meagre foundation.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
Series-links: 1:23
This should be handled by driver model now. Some tests rely on this
happening early, so just disable it for the shared library.
Signed-off-by: Simon Glass <sjg@chromium.org>
We don't want any initial console output from the library, so check the
ULIB flag and skip any output related to DRAM.
Note that debug output is unaffected, but this is only visible if debug
is enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
With the shared library the size can be quite large. Normally sandbox
pretends that its code is mapped into emulated RAM, even though it
actually isn't.
This is fine in most cases, but when mon_len exceeds the RAM size the
reservation top starts off at a negative address (i.e. very near the top
of the address space), which immediately segfaults.
Add a special case for this, for sandbox only.
We might consider dropping this mapping altogether, as is down with
RISC-V, but that is left for further discussion.
With this, the test app boots to a prompt.
Signed-off-by: Simon Glass <sjg@chromium.org>
This should be handled by driver model now. In any case there is nothing
special about MMC which indicates that it should be inited and
announced at startup.
Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add tests for checking:
- environment variable override with hex values
- invalid environment variable handling
- Kconfig-default behavior with device detection
- precedence rules (environment overrides device detection)
- serial terminal detection by manipulating sandbox state
Also expose calc_check_console_lines() in console.h for testing
and update pager functionality to use bypass mode when serial
is not connected to a terminal.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
It is annoying to have the pager use the line count from the display
when console output is actually using serial. Check this when stdio
changes and recaculate as needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
If there is a serial console, use that to set the number of lines for the
pager.
This is controlled by CONFIG_SERIAL_TERM_PRESENT
Enable SERIAL_TERM_PRESENT by default if the pager is being used, since
people generally have a serial console enabled.
Make the serial a lower priority than the vidconsole.
We don't want to use the pager when the output of sandbox is being
redirected. So in that case, put the pager in bypass mode.
Series-changes: 2
- Only use the vidconsole if we believe it is visible
Signed-off-by: Simon Glass <sjg@chromium.org>
If there is a video console, use that to set the number of lines for the
pager.
For sandbox, only do this if the -l flag was provided, i.e. the emulated
LCD is visible.
Series-changes: 2
- Only use the vidconsole if we believe it is visible
Signed-off-by: Simon Glass <sjg@chromium.org>
The 'pager' environment variable can be used to set the number of lines
on the display. Provide a callback for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
We don't want the pager appearing when entering commands, so add a way
to bypass it. Reset the line count to zero before executing the command.
Signed-off-by: Simon Glass <sjg@chromium.org>
A single character may result in a stall waiting for user input, which
means that it may request that a string be output. So when the pager is
active we never actually use the devices' putc() methods. Add a special
case so they don't go to wrack and ruin.
As before, the pager is only supported with CONFIG_CONSOLE_MUX enabled.
Series-changes: 2
- Drop unnecessary '!= NULL'
Signed-off-by: Simon Glass <sjg@chromium.org>
We generally don't want the pager to be active when running tests,
since U-Boot appears to hang forever. Perhaps we could detect when the
tests are being run interactively and use the pager in that case. But
for now, just bypass it.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Send all console output via the pager. If it is disabled, it will do
nothing.
The pager is only supported if CONSOLE_MUX and SYS_CONSOLE_IS_IN_ENV are
enabled. This is the common case for more richly featured boards, i.e.
those that can cope with the extra code size of this feature.
Series-changes: 2
- Drop an unnecessary direct call to the pager
- Repeat the old code in console_puts_pager() to avoid 16-byte growth
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Rename console_puts() to console_puts_pager() and console_putc() to
console_putc_pager() to prepare for implementing a console-pager
feature.
All normal output goes through the pager.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Sometimes output should be sent ignoring the pager, such as when it is
a message related to paging. Add a parameter to support this.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add an implementation of the pager. It has quite a simple API:
- call pager_post() to send some output, which returns what should
actually be sent to the console devices
- then call pager_next() repeatedly, outputting what it returns,
until it returns NULL
There is one special case: pager_next() returns PAGER_WAITING if it is
waiting for the user to press a key. In that case, the caller should
read a key and then pass it to the next pager_next() call.
Internally, there is a simple state machine to cope with hitting the
limit (and outputing a prompt), waiting for the user and the clearing
the prompt, before continuing in the normal PAGEST_OK state.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function has lots of return statements in a switch statement. Move
them out so we can (later) do something else in this function.
Series-changes: 2
- Add new patch to refactor handling of the result in on_console()
Signed-off-by: Simon Glass <sjg@chromium.org>
Move the environment callbacks lower so that we can call functions
elsewhere in common/console.c
Series-changes: 2
- Add new patch to move environment handling lower in the file
Signed-off-by: Simon Glass <sjg@chromium.org>
Detect if there is no terminal present (this only works on sandbox) and
skip sending ANSI characters when the CLI starts up. This avoids having
them in logs, for example.
Signed-off-by: Simon Glass <sjg@chromium.org>
The C runtime calls malloc() before starting main(), e.g. to get some
memory to use for dynamic linking.
If CONFIG_TPL_SYS_MALLOC_SIMPLE is enabled, the calloc() symbol is
defined within U-Boot. The C runtime may call that too.
Use the same #define technique as for malloc_simple(), to fix a crash
on my machine when running:
/tmp/b/sandbox_vpl/tpl/u-boot-tpl -D
This does not happen in CI, perhaps because the C runtime uses malloc()
instead of calloc().
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>
This file provide common functions related to QFW, so move it into
driver/qfw with the other code.
Series-to: concept
Cover-letter:
emulation: Restructure the Kconfig
At present ARM and x86 use differently named symbols to mean similar
things. For x86, board/emulation/Kconfig contains the targets, but ARM
has them in a different file. While ARM uses ARCH_QEMU to mean QEMU,
x86 uses VENDOR_EMULATION.
This series adjusts the Kconfig for emulation targets on x86 and ARM, to
improve consistency.
A new arch-neutral MACH_QEMU is introduced. This is enabled for all
ARM/x86 emulation targets. Furture work could add this for other archs
too.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
This existing function does not have any context associated with it.
Rename it so that fs_read() can be used for the new FS uclass.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a new SPL_FS_LEGACY which mirrors the recently added FS_LEGACY
option.
Select this new option when filesystems are required, either due to
SPL_FS_LOADER or one of the filesystems.
Signed-off-by: Simon Glass <sjg@chromium.org>
QEMU provides a SETUP_ADDR value which should be honoured when placing
the setup block, since that block can include pointers into other parts
of itself.
Instead of putting the setup block immediately before the kernel, put it
where QEMU requests.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a new qemu_fwcfg_read_files() function which reads files into the
provided location. Use this from qemu_fwcfg_setup_kernel()
Signed-off-by: Simon Glass <sjg@chromium.org>
The qemu_fwcfg_setup_kernel() function checks whether a kernel exists
and also reads it. With bootstd we want to do those two steps
separately.
Add a new qemu_fwcfg_read_info() function which gets all the values and
returns then, including the full cmdline. Use that from the outer
function.
The new function also reads the setup address, although this it not used
by the code at present.
Use an abuf for the cmdline since we don't want the read_info function
to alter unallocated memory.
Signed-off-by: Simon Glass <sjg@chromium.org>
Instead of worrying about endianness in each expression, move the
conversion into the function.
Use ulong for values, since this is the normal type for addresses in
U-Boot
Signed-off-by: Simon Glass <sjg@chromium.org>
Move the selector reading into a separate function so we can simplify
qemu_fwcfg_setup_kernel().
Read all sizes at the start and add an enum for the selector.
Signed-off-by: Simon Glass <sjg@chromium.org>
Where the bloblist is located in internal memory and TF-A's BL31 blob
removes access to this memory, the best option seems to be to relocate
the bloblist just before running TF-A.
We can do the relocation in board-specific code, but need an option to
pick up the correct address within U-Boot proper.
Series-changes: 2
- Move the actual relocation code to a previous board-specific patch
Series-to: u-boot
Series-links: 3:443538 2:443538 1:442878
Series-version: 6
Cover-letter:
VBE serial part H: Implement VBE on Rockchip RK3399
This series completes the work to enable VBE on a suitable board. Most
of it is rockchip-specific patches to support the VPL phase, i.e. the
one which decides which boot patch to take (A, B or recovery).
A good chunk of this series is adding an image for VBE, by creating a
new Binman image. Future work in Binman may make this more automated /
easier, but for now it is written out in full. The work is undertaken
piecemeal so it is easier to review the steps.
VBE allows similar boards to share firmware images, with perhaps just
TPL (around 75K) being different for each board. Using a common image
for VPL, SPL and U-Boot saves a lot of space in the image and makes
builds easier. Of course, each board still needs a separate devicetree.
Here is the layout of the image:
Name Image-pos Size Entry-type Offset Uncomp-size
----------------------------------------------------------------------------------------------
image 0 1b960cf section 0
alternates-fdt 8000 31000 alternates-fdt 8000
mkimage 8000 31000 mkimage 0
u-boot-tpl 8048 12a11 u-boot-tpl 48
vpl 208000 16200 fit 208000
image-vpl 209400 a5a3 section 1400
section 209400 a5a3 section 0
u-boot-vpl-nodtb 10348 u-boot-vpl-nodtb 0
u-boot-vpl-bss-pad 20 u-boot-vpl-bss-pad 10348
@fdt-SEQ 0 0 section 0
vbe-a 800000 39b200 section 800000
spl-a 800000 100000 fit 0
spl 801400 10c97 section 1400
section 801400 10c97 section 0
u-boot-spl-nodtb 1a908 u-boot-spl-nodtb 0
u-boot-spl-bss-pad 1b0 u-boot-spl-bss-pad 1a908
@fdt-SEQ 0 0 section 0
u-boot-a 900000 29b200 fit 100000
spl 902400 10c97 section 2400
section 902400 10c97 section 0
u-boot-spl-nodtb 1a908 u-boot-spl-nodtb 0
u-boot-spl-bss-pad 1b0 u-boot-spl-bss-pad 1a908
u-boot 913200 e4250 section 13200
u-boot-nodtb 913200 e4250 u-boot-nodtb 0
@atf-SEQ 0 0 section 0
atf-bl31 0 0 atf-bl31 0
@tee-SEQ 0 0 section 0
tee-os 0 0 tee-os 0
@fdt-SEQ 0 0 section 0
vbe-b 1000000 39b200 section 1000000
spl-b 1000000 100000 fit 0
spl 1001400 10c97 section 1400
section 1001400 10c97 section 0
u-boot-spl-nodtb 1a908 u-boot-spl-nodtb 0
u-boot-spl-bss-pad 1b0 u-boot-spl-bss-pad 1a908
@fdt-SEQ 0 0 section 0
u-boot-b 1100000 29b200 fit 100000
spl 1102400 10c97 section 2400
section 1102400 10c97 section 0
u-boot-spl-nodtb 1a908 u-boot-spl-nodtb 0
u-boot-spl-bss-pad 1b0 u-boot-spl-bss-pad 1a908
u-boot 1113200 e4250 section 13200
u-boot-nodtb 1113200 e4250 u-boot-nodtb 0
@atf-SEQ 0 0 section 0
atf-bl31 0 0 atf-bl31 0
@tee-SEQ 0 0 section 0
tee-os 0 0 tee-os 0
@fdt-SEQ 0 0 section 0
vbe-recovery 1800000 39b200 section 1800000
spl-recovery 1800000 100000 fit 0
spl 1801400 10c97 section 1400
section 1801400 10c97 section 0
u-boot-spl-nodtb 1a908 u-boot-spl-nodtb 0
u-boot-spl-bss-pad 1b0 u-boot-spl-bss-pad 1a908
@fdt-SEQ 0 0 section 0
u-boot-recovery 1900000 29b200 fit 100000
spl 1902400 10c97 section 2400
section 1902400 10c97 section 0
u-boot-spl-nodtb 1a908 u-boot-spl-nodtb 0
u-boot-spl-bss-pad 1b0 u-boot-spl-bss-pad 1a908
u-boot 1913200 e4250 section 13200
u-boot-nodtb 1913200 e4250 u-boot-nodtb 0
@atf-SEQ 0 0 section 0
atf-bl31 0 0 atf-bl31 0
@tee-SEQ 0 0 section 0
tee-os 0 0 tee-os 0
@fdt-SEQ 0 0 section 0
fdtmap 1b9b200 2ecf fdtmap 1b9b200
This series still includes the bloblist reverts, at the end, just so
that the board doesn't have on boot, but I have a series locally which
should improve things, so I will send that when complete.
This is (mostly) the final VBE series, but there are a few loose ends to
tidy up:
- cache is disabled in SPL, which slows the boot a little
- pinctrl init needs to be tidied up to avoid warnings
- bloblist logic as above
- bloblist-relocation is partly in board-specific code, partly generic
Other things may become apparently after more usage / testing.
END
Signed-off-by: Simon Glass <sjg@chromium.org>
