The goal here is to obtain the dimensions of the edit field, which does
not change.
Since scene_arrange() now handles setting the bounding-box size based on
the dimensions there is no need to do it here.
Adjust the code to simply set up the dimensions.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is possible that positions, styling or even text have changed since
the scene was initially arranged, so recalculate the dimensions of all
objects before arranging the scene.
Signed-off-by: Simon Glass <sjg@chromium.org>
A menu's dimensions are currently only used for positioning the
component parts of the menu, i.e. the label, key, description and
preview.
Move the logic for this entirely into the scene_menu file and drop the
logic at the top level.
Signed-off-by: Simon Glass <sjg@chromium.org>
Switch the order of these two calls since dims for each object should be
figured out before moving to arranging things.
Signed-off-by: Simon Glass <sjg@chromium.org>
Rather than drawing the poointer with a hard-coded position elsewhere in
the code, add a field to hold this value.
Move the check for the pointer position up so that the ordering of the
tests matches the order that the fields are dealt with in
scene_menu_arrange()
Signed-off-by: Simon Glass <sjg@chromium.org>
Rename the existing expo_apply_theme() to expo_setup_theme() and adjust
the former so that it applies a theme which has already been read into
the struct. This will make it easier for tests to check theme
adjustments, since they won't have to put them in a node.
Add the white-on-black property into the theme struct while we are.
Signed-off-by: Simon Glass <sjg@chromium.org>
We always call this with false first, then true. Drop the parameter and
handle this within the function itself.
Signed-off-by: Simon Glass <sjg@chromium.org>
Moving from one scene to another should not result in the scene being
re-arranged. Drop this, so that tests can have more control of when
scenes are arranged.
Also drop the scene_arrange() call when applying a theme, for the same
reason.
Add the now-required scene_arrange() to cedit and bootmenu
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide a convenient function which arranges the current scene in an
expo. Make use of this in bootflow_menu
Signed-off-by: Simon Glass <sjg@chromium.org>
When testing menu items it is easier to check that the correct preview
is shown if the preview images are different. Make a copy of the image
and modify the palette for the second menu item, so this is obvious.
Signed-off-by: Simon Glass <sjg@chromium.org>
Pass a pointer to a memory mapped initrd and its size to
efi_binary_run. The EFI stack will register an EFI_LOAD_FILE2_PROTOCOL
for the next boot stage to access this initrd.
Signed-off-by: Adriano Cordova <adriano.cordova@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
One of the problems an OS may face, when running in EFI, is that
a mounted ISO, after calling ExitBootServices goes away, if that ISO
is resident in RAM memory as a ramdisk.
ACPI has NFIT and NVDIMM support to provide ramdisks to the OS, but we
don't have anything in place for DTs. Linux and device trees have support
for persistent memory devices. So add a function that can inject a pmem
node in a DT, so we can pass information on the ramdisk the OS.
Signed-off-by: Masahisa Kojima <kojima.masahisa@socionext.com>
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Sometimes, it is necessary to provide an additional bootargs string to
the kernel command line.
We have a real scenario where one U-Boot blob needs to boot several
kernel images: the vendor-patched kernel image and the latest upstream
kernel image. The Amlogic (Meson architecture) tty driver has different
tty suffixes in these kernels: the vendor uses 'ttySx', while the
upstream implementation uses 'ttyAMLx'. The initial console setup is
provided to the kernel using the kernel command line (bootargs). For the
vendor kernel, we should use 'console=ttyS0,115200', while for the
upstream kernel, it must be 'console=ttyAML0,115200'. This means we have
to use different command line strings depending on the kernel version.
To resolve this issue, we cannot use the CMDLINE_EXTEND kernel
configuration because it is considered legacy and is not supported for
the arm64 architecture. CMDLINE_EXTEND is outdated primarily because we
can provide additional command line strings through the
'chosen/bootargs' FDT node. However, U-Boot uses this node to inject the
U-Boot bootargs environment variable content, which results in U-Boot
silently overriding all data in the 'chosen/bootargs' node. While we do
have the board_fdt_chosen_bootargs() board hook to address such issues,
this function lacks any FDT context, such as the original value of the
'chosen/bootargs' node.
This patch introduces a read-only (RO) fdt_property argument to
board_fdt_chosen_bootargs() to share the original 'chosen/bootargs' data
with the board code. Consequently, the board developer can decide how to
handle this information for their board setup: whether to drop it or
merge it with the bootargs environment.
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
It should be structured this way to demonstrate to the caller that
freeing the return value is unnecessary and that the caller cannot
modify it.
The function fdt_setprop() includes a parameter with a const char*
prototype, so it is better to use the const qualifier.
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The expo now has all that is needed to apply a suitable theme, so drop
this unnecessary code. Any further tweaks can be added to the generic
expo code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Apply the theme, calculate dimensions, highlight the menu and arrange
the scene correctly, so that everything is ready to go when the expo
is rendered.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some callers may wish to add items later as they are discovered. Split
the setup code into its own function, to permit this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Rather than returning a bootflow, return the index of the bootflow. This
will allow callers to do their own translation to bootflows or some
other data structure.
Also return a special code when the user tries to move the pointer, so
that the caller can cancel the boot-menu timeout, if this is in use.
Signed-off-by: Simon Glass <sjg@chromium.org>
The menu is currently quite basic. Make use of some recently added
features in expo, to:
- Show proper prompts
- Highlight the current item
- Centre text
- Use multi-line text instead of two independent lines
- Put a box around the items
Signed-off-by: Simon Glass <sjg@chromium.org>
It is often necessary to centre objects within the display area. Add a
special position value to indicate this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Within tests it is useful to be able to control rendering of the expo.
Drop the automatic call to expo_render() within expo_poll() and adjust
its callers to handle this instead.
Signed-off-by: Simon Glass <sjg@chromium.org>
If the user does not quickly provide some input, exit so that other
things can be done, such as searching for the next OS.
Signed-off-by: Simon Glass <sjg@chromium.org>
Expo normally uses a pointer to show the current item. Add support for
highlighting as well, since this makes it easier for the user to see the
current item.
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide some forward declarations for types used in this file, to keep
the LSP happy and avoid errors if the caller happens not to include the
required header.
Signed-off-by: Simon Glass <sjg@chromium.org>
The gap is intended to separate options which are on different bootdevs,
but most of the time there is only one. So drop this gap.
Keep the code around in case it becomes useful to have it in the style,
or based on some other mechanism.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is useful to be able to edit text, e.g. to allow the user to edit the
environment or the command-line arguments for the OS.
Add the beginnings of an implementation. Future work is needed to finish
this: keypress handling and scrolling. For now it just displays the
text.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add support for left, right and centred alignment for text, in the
horizontal dimension.
Also support top, bottom and centred in the vertical dimension, for the
text object as a whole.
Alignment is not yet implemented for images. It has no meaning for
menus. A textline object uses a text object internally, so alignment
is supported there.
Provide some documentation to explain how objects are positioned.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is useful to be able to draw a box around elements in the menu. Add
support for an unfilled box with a selectable thickness.
Note that there is no support for selecting the colour for any expo
objects yet.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the measurement info to write each line of text separately, thus
respecting word-wrapping and newlines.
Fix up the comment for scene_obj_render() while we are here.
Since a lineedit does not support alignment, add a special case to just
display the text if there is no measurement. This happens assuming the
lineedit is initially empty.
Signed-off-by: Simon Glass <sjg@chromium.org>
In some cases dynamic text is needed, e.g. for a menu countdown. Add a
function which handles this, allowing the caller to take control of the
text that is shown on each render.
Signed-off-by: Simon Glass <sjg@chromium.org>
In preparation for adding more text types, refactor the common fields
into a new structure. This will allow common code to be used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a function to allow the size of an object to be set independently
of its position.
Also add a function to permit the object's bounding box to be set
independently of its dimensions.
Signed-off-by: Simon Glass <sjg@chromium.org>
In some cases it is useful to obtain more than just two bounding boxes
from a menu, e.g. to line up all descriptions vertically.
Use an array to obtain bounding-box information and calculate it
separately for each item.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present each object has a width and height and the bounding box is
implicit in that.
This is not flexible enough to handle objects which are larger than
their contents might need. For example, when centring a text object we
might want to have it stretch across the whole width of the display even
if the text itself does not need that much space.
Create a new 'dimensions' field and convert the existing width/height
into x1/y1 coordinates.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is more convenient to put strings in an abuf so they can easily be
resized. Adjust the struct accordingly.
Signed-off-by: Simon Glass <sjg@chromium.org>
These coordinates are the top left values, so rename them to x0 and y0
in preparation for changing the width and height to x1 and y1
Signed-off-by: Simon Glass <sjg@chromium.org>
At present we assume that each object is a simple box and that it fills
the whole box.
This is quite limiting for text objects, which we may want to centre
within the box. We need a position within the box where drawing starts.
Rename the scene_dim struct to indicate that it is a bounding box.
Signed-off-by: Simon Glass <sjg@chromium.org>
Refactor bootflow_menu_add_all() to call a new bootflow_menu_add() to
add each of its bootflows.
Move the last_bootdev value into struct menu_priv to make this work.
Signed-off-by: Simon Glass <sjg@chromium.org>
Split the iteration piece of this function into bootflow_menu_add_all()
so that it is possible for the caller to be in control of adding items
to the menu.
Move the expo_destroy() call into the caller.
Signed-off-by: Simon Glass <sjg@chromium.org>
Split the starting piece of this function into bootflow_menu_start()
and the polling part into bootflow_menu_poll() so that it is possible
for the caller to be in control of the event loop.
Move the expo_destroy() call into the caller.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present when the user moves to a new menu item, the menu code
handles this immediately. This means it is not possible to use an expo
action to effect the same change.
Update this so that EXPOACT_POINT_ITEM is handled in cedit_do_action().
Expand the test to cover this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add functions to allow a caller to find out the current menu item and to
select a different one.
Update the event handling so that an attempt to change the current item
(e.g. by pressing the up-arrow key) is reported to the caller, since
this may be used to cancel an autoboot timeout.
Signed-off-by: Simon Glass <sjg@chromium.org>
