The current cmd_ut_sub[] array was fine when there were only a few test
suites. But is quite unwieldy now:
- it requires a separate do_ut_xxx for each suite, even though the code
for most is almost identical
- running more than one suite requires running multiple commands, and
there is no record of which suites passed or failed
- 'ut all' runs all suites but reports their results individually
- we need lots of #ifdefs in the array, mirroring those in the makefile
but maintained in a separate place
In fact the tests are all in the same linker list. The suites are
grouped, so it is possible to access the information without a command.
Introduce a 'suite' array, which holds the cmd_ut_...() function to
call, but can also support running a suite without that function. This
means that the array of struct cmd_tbl is transformed into an array of
'struct suite'.
This will allow removal of many of the functions, particularly those
without test-specific init.
Signed-off-by: Simon Glass <sjg@chromium.org>
Most test suites have a _test suffix. This is not necessary as there is
also a ut_ prefix.
Drop the suffix so that (with future work) the suite name can be used as
the linker-list name.
Remove the suffix from the pytest regex as well, moving it to the top of
the file, as it is a constant.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some suites have a different name from that used in the linker list.
That makes it hard to programmatically match the name printed when the
suite runs to the linker-list name it has.
Update the names so they are the same.
Signed-off-by: Simon Glass <sjg@chromium.org>
A limitation of most linker_list macros is that they cannot easily be
used in data structures. This is because they include code inside their
expressions.
Provide a way to support this, with new ll_start_decl() and
ll_end_decl() macros.
Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass <sjg@chromium.org> says:
This series provides a way to keep track of the images used in bootstd,
including the type of each image.
At present this is sort-of handled by struct bootflow but in quite an
ad-hoc way. The structure has become quite large and is hard to query.
Future work will be able to reduce its size.
Ultimately the 'bootflow info' command may change to also show images as
a list, but that is left for later, as this series is already fairly
long. So for now, just introduce the concept and adjust bootstd to use
it, with a simple command to list the images.
This series includes various alist enhancements, to make use of this new
data structure a little easier.
[trini: Drop patch 18 and 19 for now due to size considerations]
Link: https://lore.kernel.org/r/20241115231926.211999-1-sjg@chromium.org
Add a new 'bootstd images' command, which lists the images which have
been loaded.
Update some existing tests to use it. Provide some documentation about
images in general and this command in particular.
Use a more realistic kernel command-line to make the test easier to
follow.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a file-type parameter to this function and update all users. Add a
proper comment to the function which we are here.
This will allow tracking of the file types loaded by the extlinux
bootmeth.
Signed-off-by: Simon Glass <sjg@chromium.org>
We want to record the type of each file which is loaded. Add an new
parameter for this, to the read_file() method. Update all users.
Make bootmeth_common_read_file() store information about the image that
is read.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
As a first step to recording images and where they came from, update
this function to do so, since it is used by two bootmeths
Create a helper function in the bootflow system, since recorded
images are always associated with bootflows.
Signed-off-by: Simon Glass <sjg@chromium.org>
We want to keep track of images which are loaded, or those which could
perhaps be loaded. This will make it easier to manage memory allocation,
as well as permit removal of the EFI set_efi_bootdev() feature.
Add a list of these, attached to the bootflow. For now the list is
empty.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use an alist for this data structure as it is somewhat simpler to
manage. This means that bootstd holds a simple list of bootflow structs
and can drop it at will, without chasing down lists.
Signed-off-by: Simon Glass <sjg@chromium.org>
This list is only used by two functions, which can be updated to iterate
through the global list. Take this approach, which allows the bootdev
list to be dropped.
Overall this makes the code slightly more complicated, but will allow
moving the bootflow list into an alist
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide a function which is safe to call in the 'unbind' path, which
returns the bootstd priv data if available.
Signed-off-by: Simon Glass <sjg@chromium.org>
This relates to more than just the bootdev, since there is a global list
of bootflows. Move the function to the bootstd file and rename it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
This relates to more than just the bootdev, since there is a global list
of bootflows. Move the function to the bootstd file and rename it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Dmitry Rokosov <ddrokosov@salutedevices.com> says:
This series consists of three patches.
The first patch modifies the function documentation style in the
include/fdt_support.h file to comply with kernel-doc requirements.
The second patch modifies the board_fdt_chosen_bootargs() function to
return a const char* type. This change clarifies to the caller that the
returned string should neither be freed nor modified. It aligns with the
existing fdt_setprop() function, which already utilizes a const char*
parameter. This promotes consistency within the codebase and enhances
code safety by preventing unintended modifications to the returned
string.
The third patch addresses the need for flexibility in providing kernel
command line arguments (bootargs) for different kernel images within the
same U-Boot environment. It introduces a read-only (RO) fdt_property
argument to the board_fdt_chosen_bootargs() function, allowing access to
the original chosen/bootargs data. This is crucial for scenarios where
different kernel versions require distinct console setups (e.g., ttyS0
for vendor kernels and ttyAML0 for upstream kernels). By enabling board
developers to either merge or replace the original bootargs, this
patch enhances the configurability of U-Boot for various kernel
images without relying on outdated configurations like CMDLINE_EXTEND.
CI/CD results: https://github.com/u-boot/u-boot/pull/716/checks
Link: https://lore.kernel.org/r/20241220-board_fdt_chosen_bootargs_improvements-v1-0-f6a7181787c5@salutedevices.com
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>
Raymond Mao <raymond.mao@linaro.org> says:
Motivations for changes:
Current SMBIOS library and command-line tool is not fully matching with
the requirements:
1. Missing support for other mandatory types (#7, #9, #16, #17, #19).
2. Only a few platforms support SMBIOS node from the device tree.
3. Values of some fields are hardcoded in the library other than fetching
from the device hardware.
4. Embedded data with dynamic length is not supported (E.g. Contained
Object Handles in Type #2 and Contained Elements in Type #3)
Changes:
1. Refactor the SMBIOS library and command-line tool to better align with
the SMBIOS spec.
2. Create an arch-specific driver for all aarch64-based platforms to fetch
SMBIOS private data from the device hardware (processor and cache).
3. Create a sysinfo driver to poppulate platform SMBIOS private data.
4. Add generic SMBIOS DTS file for arm64 platforms for those common strings
and values which cannot be retrieved from the system registers.
Vendors can create their own SMBIOS node using this as an example.
For those boards without SMBIOS nodes, this DTS file can be included to
have a generic SMBIOS information of the system.
5. Add support for Type #7 (Cache Information) and link its handles to
Type #4.
6. To minimize size-growth for those platforms which have not sufficient
ROM spaces or the platforms which don't need detailed SMBIOS
information, new added fields are only being built when kconfig
GENERATE_SMBIOS_TABLE_VERBOSE is selected.
Once this patch is acceptted, subsequent patch sets will add other missing
types (#9, #16, #17, #19).
Tests:
To test this with QEMU arm64, please follow the guide on dt_qemu.rst to
get a merged DT to run with.
```
qemu-system-aarch64 -machine virt -machine dumpdtb=qemu.dtb
cat <(dtc -I dtb qemu.dtb) <(dtc -I dtb ./dts/dt.dtb | grep -v /dts-v1/) \
| dtc - -o merged.dtb
qemu-system-aarch64 -machine virt -nographic -bios u-boot.bin \
-dtb merged.dtb
```
Link: https://lore.kernel.org/r/20241206225438.13866-1-raymond.mao@linaro.org
Update the cmd according to the changes of the smbios library:
1. Refactor smbios cmd print functions to match the content defined
by the specification.
2. Add new print functions for Type 3, 4 and 7.
3. Remove the fallback string "Not specified" from smbios_get_string,
as the spec requires a NULL output for those undefined strings.
4. Update the test_cmd_smbios_sandbox pytest expected result to
align with the smbios library changes and add new pytest
test_cmd_smbios_sysinfo_verbose to test the verbose smbios
output.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Current smbios library does not fully match to the specification.
It hardcodes values instead of exposing values from the device.
It does not reserve the space to support dynamic length for
contained object handles or elements and misses the handling of
a few of fields.
The refactoring of this patch includes:
1. Expose values from device via sysinfo interface.
2. Replace smbios_add_prop with smbios_add_prop_si to allow getting
string values from sysinfo.
3. Add smbios_get_val_si to get values from sysinfo or device tree.
4. Use sysinfo_get_data to get data area.
5. Reserve the space of contained object handles and elements.
6. Miscellaneous fixes in smbios.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
