| Age | Commit message (Collapse) | Author |
|---|
|
Move differences in DT files between upstream Linux DT and U-Boot DT to
mt7629-rfb-u-boot.dtsi.
Remove old copies of mt7629-related clock bindings, .dts, and .dtsi files.
Update defconfig to switch the whole mt7629 SoC to use OF_UPSTREAM.
Signed-off-by: Sam Shih <[email protected]>
Signed-off-by: Weijie Gao <[email protected]>
|
|
Philippe Reynes <[email protected]> says:
This serie adds the support of sha256_hmac and sha256_hkdf.
A first version was sent several months ago just before the
integration of mbedtls. This new version is based on mbedtls.
The first patch of this serie add the support of hkdf
using mbedtls.
Link: https://lore.kernel.org/r/[email protected]
|
|
Adds the support of key derivation using the scheme hkdf.
This scheme is defined in rfc5869.
Signed-off-by: Philippe Reynes <[email protected]>
Reviewed-by: Raymond Mao <[email protected]>
|
|
Adds the support of the hmac based on sha256.
This implementation is based on rfc2104.
Signed-off-by: Philippe Reynes <[email protected]>
Reviewed-by: Raymond Mao <[email protected]>
|
|
Move env to imx8mq_evk.env
Switch to support BOOTSTD with a bsp bootcmd as fallback.
Signed-off-by: Peng Fan <[email protected]>
|
|
Move env to imx8mm_evk.env
Switch to support BOOTSTD with a bsp bootcmd as fallback.
Signed-off-by: Peng Fan <[email protected]>
|
|
Move env to imx8mn_evk.env
Switch to support BOOTSTD with a bsp bootcmd as fallback.
Signed-off-by: Peng Fan <[email protected]>
|
|
Move env to imx8mp_evk.env.
Switch to support BOOTSTD with a bsp bootcmd as fallback.
Signed-off-by: Peng Fan <[email protected]>
|
|
Switch to support BOOTSTD with a bsp bootcmd as fallback.
Move the env to imx93_evk.env
Signed-off-by: Peng Fan <[email protected]>
|
|
Simon Glass <[email protected]> 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/[email protected]
|
|
Export this function so it can be used from other files.
Signed-off-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
|
|
Update this function to add the image to the list.
Signed-off-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Acked-by: Heinrich Schuchardt <[email protected]>
|
|
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 <[email protected]>
|
|
flexibility"
Dmitry Rokosov <[email protected]> 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 <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
No errors from kernel-doc with this patch applied:
$ ./scripts/kernel-doc -v -none include/fdt_support.h
include/fdt_support.h:17: info: Scanning doc for arch_fixup_fdt
include/fdt_support.h:37: info: Scanning doc for fdt_root
include/fdt_support.h:48: info: Scanning doc for fdt_chosen
include/fdt_support.h:59: info: Scanning doc for fdt_initrd
include/fdt_support.h:100: info: Scanning doc for fdt_fixup_memory
include/fdt_support.h:115: info: Scanning doc for fdt_fixup_memory_banks
include/fdt_support.h:148: info: Scanning doc for fdt_fixup_display
include/fdt_support.h:176: info: Scanning doc for fdt_record_loadable
include/fdt_support.h:205: info: Scanning doc for ft_board_setup
include/fdt_support.h:218: info: Scanning doc for board_rng_seed
include/fdt_support.h:231: info: Scanning doc for board_fdt_chosen_bootargs
include/fdt_support.h:251: info: Scanning doc for ft_system_setup
include/fdt_support.h:266: info: Scanning doc for fdt_shrink_to_minimum
include/fdt_support.h:301: info: Scanning doc for fdt_copy_fixed_partitions
include/fdt_support.h:314: info: Scanning doc for fdt_translate_address
include/fdt_support.h:327: info: Scanning doc for fdt_translate_dma_address
include/fdt_support.h:342: info: Scanning doc for fdt_get_dma_range
include/fdt_support.h:464: info: Scanning doc for fdt_get_cells_len
include/fdt_support.h:480: info: Scanning doc for fdtdec_get_child_count
include/fdt_support.h:500: info: Scanning doc for fdt_kaslrseed
Signed-off-by: Dmitry Rokosov <[email protected]>
Acked-by: Heinrich Schuchardt <[email protected]>
|
|
Raymond Mao <[email protected]> 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/[email protected]
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
Add sysinfo driver to retrieve smbios information (Type 4 and 7).
So that the smbios library can use it for getting values from the
hardware platform instead of device tree.
Signed-off-by: Raymond Mao <[email protected]>
|
|
Add interface for sysinfo to access a data area from the platform.
This is useful to save/read a memory region of platform-specific
data.
Signed-off-by: Raymond Mao <[email protected]>
|
|
Move the smbios field definitions to a separated simple headfile,
which is a prerequisite to be included by dts files.
Add new definitions for cache information.
This patch also includes a few of code optimizations in smbios.
Signed-off-by: Raymond Mao <[email protected]>
Acked-by: Heinrich Schuchardt <[email protected]>
|
|
Rather than doing autoprobe within the driver model code, move it out to
the board-init code. This makes it clear that it is a separate step from
binding devices.
For now this is always done twice, before and after relocation, but we
should discuss whether it might be possible to drop the post-relocation
probe.
For boards with SPL, the autoprobe is still done there as well.
Note that with this change, autoprobe happens after the
EVT_DM_POST_INIT_R/F events are sent, rather than before.
Link: https://lore.kernel.org/u-boot/[email protected]/
Signed-off-by: Simon Glass <[email protected]>
|
|
Replace magic numbers in buckval2votl() & buckvolt2val() with macros to
help with clarity and correlate what the numbers correspond to in the
TPS65219 datasheet.
Signed-off-by: Shree Ramamoorthy <[email protected]>
Reviewed-by: Jaehoon Chung <[email protected]>
|
|
fix following error by using same ENV_MEM_LAYOUT_SETTINGS with rk35xx:
U-Boot 2025.01-rc3-00001-g1527c7dcdb01 (Dec 02 2024 - 22:57:18 +0000)
:
Retrieving file: /boot/extlinux/../nixos/dhqjsnprmzjxncil3m0g9l09a479crn3-linux-6.12.1-Image
Retrieving file: /boot/extlinux/../nixos/6fq8fmmab31yxdwcs7zw44p78fq9fy1s-initrd-linux-6.12.1-initrd
append: init=/nix/store/yjbxgzf1vkwbw6ab738bf4kxazhyypa1-nixos-system-rock-5b-25.05.20241201.ac35b10/init console=ttyS2,1500000n8 console=ttyAMA0,115200n8 console=tty0 loglevel=7
Retrieving file: /boot/extlinux/../nixos/dhqjsnprmzjxncil3m0g9l09a479crn3-linux-6.12.1-dtbs/rockchip/rk3399-rock-4se.dtb
Moving Image from 0x2080000 to 0x2200000, end=0x60d0000
ERROR: RD image overlaps OS image (OS=2200000..60d0000)
Boot failed (err=-14)
$ ls -lh boot/nixos/
total 84M
-r--r--r-- 1 root root 24M Jan 1 1970 6fq8fmmab31yxdwcs7zw44p78fq9fy1s-initrd-linux-6.12.1-initrd
-r--r--r-- 1 root root 62M Jan 1 1970 dhqjsnprmzjxncil3m0g9l09a479crn3-linux-6.12.1-Image
dr-xr-xr-x 36 root root 4.0K Jan 1 1970 dhqjsnprmzjxncil3m0g9l09a479crn3-linux-6.12.1-dtbs
similar problem was fixed for rk35xx by:
commit 69b73877f02c ("rockchip: rk35xx: expand space for decompressed kernel")
Signed-off-by: FUKAUMI Naoki <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
The clock and power DT includes for rk3066a and rk3188 are now
available in the dts/upstream directory, so remove the ones that
are now redundant.
Signed-off-by: Johan Jonker <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
Radxa ROCK 5C[1] is a Rockchip RK3588S2 based single board computer.
[1] https://radxa.com/products/rock5/5c
Signed-off-by: FUKAUMI Naoki <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
Khadas Edge2 is a Rockchip RK3588S based SBC (Single Board Computer)
by Khadas.
There are tree variants depending on the DRAM size : 8G and 16G.
Specification:
Rockchip RK3588S SoC
4x ARM Cortex-A76, 4x ARM Cortex-A55
8/16GB memory LPDDR4x
Mali G610MP4 GPU
3x MIPI CSI 4x lanes
2x MIPI-DSI DPHY 4x lanes
32/64GB eMMC
1x USB 2.0, 1x USB 3.0, 2x USB-Type-C
1x HDMI 2.1 output, 1x DP 1.4 output
USB PD over USB Type-C
Kernel commit:
04d552993522 ("arm64: dts: rockchip: Add Khadas edge2 board")
Signed-off-by: Jacobe Zang <[email protected]>
|
|
power/rk3288-power.h in include/dt-bindings is identical to the version
in dts/upstream, remove the copy from include/dt-bindings to only use
the version from dts/upstream.
No functional change to board DTs is intended with this removal.
Signed-off-by: Jonas Karlman <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-tpm
A few changes for the TPM subsystem wrt to EventLong creation and measurements.
Generally speaking it's insecure for a TPM to not cap all the active PCRs
when performing measurements.
Up to now we had code querying the active PCR banks on the fly and reason
whether it should perform a measurement or not. Since a TPM requires a reset
to change the active PCR banks, it's easier and faster to store them in an
array in the device private data and check against that.
This relates to an interesting feature some bootloaders have. For example
TF-A can't extend a PCR since it has no TPM drivers, but can produce an
EventLog that U-Boot can replay on the hardware once that comes up.
The supported hash algorithms of the TF-A generated Eventlog are generated
at compile time. When trying to replay an EventLog the TPM active PCR banks
and the created EventLog algorithms must agree. We used to report an error
but that changed in commit 97707f12fdab ("tpm: Support boot measurements").
This PR also brings up the old behavior and an error is reported now while
printing a human readable list of the mismatched algorithms.
|
|
* Provide a link to 'TPM 2.0 Library Specification'
* Remove outdated comment for TPM2_NUM_PCR_BANKS.
The value 16 can be found in the current standard
TCG TSS 2.0 Overview and Common Structures Specification 1.0, rev 10
* Describe some of the structures in Sphinx style.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Reviewed-by: Miquel Raynal <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
We have a lot of code trying to reason about the active TPM PCRs
when creating an EventLog. Since changing the active banks can't
be done on the fly and requires a TPM reset, let's store them
in the chip private data instead.
Upcoming patches will use this during the EventLog creation.
Signed-off-by: Raymond Mao <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
We already check the active banks vs what U-Boot was compiled with when
trying to extend a PCR and we refuse to do so if the TPM active ones
don't match the ones U-Boot supports.
Do the same thing for the EventLog creation since extending will fail
anyway and print a message so the user can figure out the missing
algorithms.
Co-developed-by: Raymond Mao <[email protected]>
Signed-off-by: Raymond Mao <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
Add a bool var into hash_algo_list to indicate whether the algorithm
is supported or not and move the IS_ENABLED to only cover this var.
So that we can have the name, hash, mask and size no matter the
digest kconfigs are enabled or not.
In before, tpm2_algorithm_to_len() and tcg2_algorithm_to_mask() are used to
identify an unsupported algorithm when they return 0.
It is not the case now when hash_algo_list always provides algorithm size
and mask, thus a new API is introduced to check if an algorithm is
supported by U-Boot.
Suggested-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Raymond Mao <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
Rename the arguments of tcg2_get_pcr_info() to clarify
they are bank masks, not PCR mask.
Remove the unused local variable.
Signed-off-by: Raymond Mao <[email protected]>
Reviewed-by: Ilias Apalodimas <[email protected]>
|
|
When that function was introduced we were only using it to check if
extending a PCR was allowed, so the name made sense. A few patches ago
we used that function to reason about the EventLog creation and general
usage of PCRs , so let's rename it to something more generic that makes
more sense in all contexts.
Signed-off-by: Raymond Mao <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
This function is checking for active PCR banks, so rename it
to something that's easier to read and closer to what the function
does.
Signed-off-by: Raymond Mao <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>
|
|
Refer to UEFI specification 2.10:
#define EFI_CONFORMANCE_PROFILES_TABLE_GUID \
{ 0x36122546, 0xf7e7, 0x4c8f, \
{ 0xbd, 0x9b, 0xeb, 0x85, 0x25, 0xb5, 0x0c, 0x0b }}
Signed-off-by: Yang Gang <[email protected]>
Fixes: 6b92c1735205 ("efi: Create ECPT table")
Reviewed-by: Heinrich Schuchardt <[email protected]>
|
|
* add EFI_MEMORY_CPU_CRYPTO, EFI_MEMORY_HOT_PLUGGABLE
* correct output for EFI_MEMORY_XP
* remove duplicate list entry for EFI_MEMORY_UC
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
|
UEFI specification 2.11 has been published.
There are no changes relevant for the U-Boot scope.
So let us update the supported specification version.
Change the comment for the constant to Sphinx style.
Reviewed-by: Ilias Apalodimas <[email protected]>
Signed-off-by: Heinrich Schuchardt <[email protected]>
|
