| Age | Commit message (Collapse) | Author |
|---|
|
https://source.denx.de/u-boot/custodians/u-boot-amlogic into next
- Add u-boot SPL support for GX SoCs
- meson_gx_mmc: reduce maximum frequency
- Add support for EFI capsule updates on all Amlogic boards
|
|
constants"
Quentin Schulz <[email protected]> says:
This does a bit of "cleanup" by reusing constants for some FIT
properties instead of having the same string in multiple places.
Additionally, this adds a new constant for the compatible property in
FIT configuration nodes[1] which is useful for FIT images with multiple
FIT configuration nodes to support multiple devices in the same blob.
U-Boot will try to figure out which node to select based on that
compatible[2].
However, if this property is missing (and the first blob in the fdt
property of the configuration node is uncompressed), the compatible from
the root node of the associated kernel FDT will be used for the
autoselection mechanism. For now, I only print the property if it
exists, but maybe it'd make sense to expose the fallback one if it's
missing. I guess we can implement that later on if desired.
[1] https://fitspec.osfw.foundation/#optional-properties compatible paragraph
[2] https://fitspec.osfw.foundation/#select-a-configuration-to-boot
Link: https://lore.kernel.org/r/[email protected]
|
|
Fit conf node may have a compatible property[1] which stores the root
compatible of the first blob in the fdt property of the node. This can
be used to automatically select the proper conf node based on the
compatible from the running U-Boot (matching the former's compatible
with the latter)[2].
This adds (and uses) this constant for FIT node parsing.
Note that this property may also appear in fpga image nodes[3] but that
isn't done in this commit.
[1] https://fitspec.osfw.foundation/#optional-properties compatible paragraph
[2] https://fitspec.osfw.foundation/#select-a-configuration-to-boot
[3] https://fitspec.osfw.foundation/#images-node 2.3.2 Conditionally mandatory property
Signed-off-by: Quentin Schulz <[email protected]>
|
|
Add support for creating an Amlogic Boot Image that pass CHK in BL1 on
Amlogic AArch64 SoCs.
Images can optionally be signed for secure boot scenario, however
creation of signed images has not been implemented.
Example of how to use it:
# Create an amlogic boot image
tools/mkimage -T amlimage -n gxbb -d u-boot-spl.bin u-boot-amlogic.bin
# List boot image header information
tools/mkimage -l u-boot-amlogic.bin
# Extract amlogic boot image payload
tools/dumpimage -T amlimage -o bl2-payload.bin u-boot-amlogic.bin
Or with binman using something like:
binman {
u-boot-amlogic {
filename = "u-boot-amlogic.bin";
pad-byte = <0xff>;
mkimage {
filename = "bl2.bin";
args = "-n", "gxbb", "-T", "amlimage";
u-boot-spl {
};
};
};
};
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Jonas Karlman <[email protected]>
[Ferass: check digest type in _print_header, version in _verify_image]
Signed-off-by: Ferass El Hafidi <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
|
|
Introduce two new parameters to be used with mkimage -f auto to bundle
TEE image into fitImage, using auto-generated fitImage. Add -z to specify
TEE file name and -Z to specify TEE load and entry point address. This is
meant to be used with systems which boot all of TEE, Linux and its DT from
a single fitImage, all booted by U-Boot.
Example invocation:
"
$ mkimage -E -A arm -C none -e 0xc0008000 -a 0xc0008000 -f auto \
-d arch/arm/boot/zImage \
-b arch/arm/boot/dts/st/stm32mp135f-dhcor-dhsbc.dtb \
-z ../optee_os/out/arm-plat-stm32mp1/core/tee-raw.bin \
-Z 0xde000000 \
/path/to/output/fitImage
"
Documentation update and test are also included, the test validates
both positive and negative test cases, where fitImage does not include
TEE and does include TEE blobs.
Acked-by: Quentin Schulz <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
|
|
Fix some typos in include/image.h.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Wolfgang Wallner <[email protected]>
|
|
Introduce two new parameters to be used with mkimage -f auto to bundle
TFA BL31 image into fitImage, using auto-generated fitImage. Add -y to
specify TFA BL31 file name and -Y to specify TFA BL31 load and entry
point address. This is meant to be used with systems which boot all of
TFA BL31, Linux and its DT from a single fitImage, all booted by U-Boot.
Example invocation:
"
$ mkimage -E -A arm64 -C none -e 0x50200000 -a 0x50200000 -f auto \
-d arch/arm64/boot/Image \
-b arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dtb \
-y ../tfa/build/rcar_gen4/release/bl31.bin -Y 0x46400000 \
/path/to/output/fitImage
"
Documentation update and test are also included, the test validates
both positive and negative test cases, where fitImage does not include
TFA BL31 and does include TFA BL31 blobs.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Prepare v2025.07-rc5
With this merge, tighten up the LTO_FLAGS removal we added to not
trigger on ARMv7 (which is Thumb-2 and should be fine).
|
|
The symbol TOOLS_IMAGE_PRE_LOAD doesn't depend on TOOLS_LIBCRYPTO.
If we choose to build tools without openssl, rsa_verify_openssl()
will attempt to call the unavailable openssl library functions.
Fixes: 942c8c8e6697 ("rsa: Add rsa_verify_openssl() to use openssl for host builds")
Signed-off-by: Shiji Yang <[email protected]>
|
|
Add support for generating STM32 Image V2.0, which is used by STM32MP13xx.
The image header layout is similar to STM32MP15xx STM32 Image V1.0, but is
different enough to justify duplicate functions to generate the v2 image.
This code at least attempts to align the V1 and V2 image handling where
possible.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Prepare v2025.07-rc4
|
|
This reverts commit 14a4792a71db3561bea065415ac1f2ac69ef32b5 as
discussed in [1].
[1] https://lists.denx.de/pipermail/u-boot/2025-May/590841.html
Signed-off-by: Mayuresh Chitale <[email protected]>
Reviewed-by: Leo Yu-Chi Liang <[email protected]>
|
|
The original commit always generated linker list entries with the same
entry variable name, because _function passed to ll_entry_declare() is
not a variable and therefore was interpreted as fixed string. Change it
to _type which is a variable and which does allow generation of multiple
unique linker list entries, one for each U_BOOT_FIT_LOADABLE_HANDLER().
Fixes: d7be50921ed3 ("image: Add FIT image loadable section custom processing")
Signed-off-by: Marek Vasut <[email protected]>
|
|
Similar to ARM and X86, introduce a new image type which allows u-boot
to distinguish between images built for 32-bit vs 64-bit Risc-V CPUs.
Signed-off-by: Mayuresh Chitale <[email protected]>
Reviewed-by: Maxim Moskalets <[email protected]>
|
|
in extlinux / PXE""
This reverts commit 8bc3542384e3a1219e5ffb62b79d16dddc1b1fb9, reversing
changes made to 698edd63eca090a2e299cd3facf90a0b97bed677.
There are still problems with this series to work out.
Link: https://lore.kernel.org/u-boot/CAFLszTjw_MJbK9tpzVYi3XKGazcv55auBAdgVzcAVUta7dRqcg@mail.gmail.com/
Signed-off-by: Tom Rini <[email protected]>
|
|
A compressed booti image relies on the compression-format's header at
the start to indicate which compression algorithm is used.
We don't support this elsewhere in U-Boot, so assume that a compressed
file is always a booti file. Once it is compressed, a check is made to
make sure that it actually is.
Simplify the implementation by adding a new function which returns the
booti image-type if compression is detected.
Signed-off-by: Simon Glass <[email protected]>
|
|
At present the booti format is handled separately, in its own command.
Provide a way to boot uncompressed booti images within the bootm code,
so that eventually we can boot these images without CONFIG_CMDLINE
Update bootm_init() to attach the images for all formats which use them.
Add some debugging while we are here.
Signed-off-by: Simon Glass <[email protected]>
|
|
Arm invented a new format for arm64 and something similar is also used
with RISC-V. Add this to the list of supported formats and provide a way
for the format to be detected on both architectures.
Update the genimg_get_format() function to support this.
Fix up switch() statements which don't currently mention this format.
Booti does not support a ramdisk, so this can be ignored.
Signed-off-by: Simon Glass <[email protected]>
|
|
Use an enum so it is clearer that these options are related. Update
genimg_get_format(), tidy up the function comment and move it to the
header file, since it is exported.
Signed-off-by: Simon Glass <[email protected]>
|
|
rsa_verify_openssl() is used in lib/rsa/rsa-verify.c to authenticate data
when building host tools.
Signed-off-by: Paul HENRYS <[email protected]>
|
|
Add support for starting TFA from U-Boot running in EL3 as part of
fitImage boot, so the user can start U-Boot in the highest privilege
level on the platform, bundle TFA, Linux, DT into a single fitImage
and boot such a bundle as a whole.
There are two main benefits of this approach. First is the ability
to run U-Boot in EL3, where it has unrestricted access to the entire
system and can act as a useful debug tool, as it was always intended
to be used. Second is the ability to easily and safely update of any
component in the fitImage, be it TFA, Linux or DT.
The boot process is similar to regular Linux with DT fitImage boot
process, except the TFA has to be bundled into the fitImage. For the
bundling instructions, see below. The TFA is started as a 'loadables'
with custom U_BOOT_FIT_LOADABLE_HANDLER and armv8_switch_to_el2_prep()
handling implemented in board code, and performing the handoff and
boot in case the TFA was loaded.
The loadables handler is optional and meant to set up any sort of
handoff structures used by the TFA BL31 or perform any other setup
that is needed by the blob. The custom armv8_switch_to_el2_prep()
has to implement the jump to TFA BL31 with return to U-Boot just
before booting the Linux kernel.
Example fitImage image and configuration section:
/dts-v1/;
/ {
description = "Linux kernel with FDT blob and TFA BL31";
images {
kernel-1 { ... };
fdt-1 { ... };
atf-1 { /* This is the TFA BL31 image */
description = "TFA BL31";
data = /incbin/("../build/plat/release/bl31.bin");
type = "tfa-bl31";
arch = "arm64";
os = "arm-trusted-firmware";
compression = "none";
load = <0x46400000>;
entry = <0x46400000>;
};
};
configurations {
default = "conf-1";
conf-1 {
description = "Boot Linux";
kernel = "kernel-1";
fdt = "fdt-1";
loadables = "atf-1"; /* This is the TFA BL31 loadable */
};
};
};
Reviewed-by: Tom Rini <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
|
|
Simon Glass <[email protected]> says:
The current UPL spec[1] has been tidied up and improved over the last
year, since U-Boot's original UPL support was written.
This series includes some prerequisite patches needed for the real UPL
patches. It is split from [2]
[1] https://github.com/UniversalPayload/spec/tree/3f1450d
[2] https://patchwork.ozlabs.org/project/uboot/list/?series=438574&state=*
Link: https://lore.kernel.org/r/[email protected]
|
|
This function is really just getting the data. The size comes along for
the ride. In fact this function is only reliable way to obtain the data
for an image in a FIT, since the FIT may use external data.
Rename it to fit_image_get_data()
Signed-off-by: Simon Glass <[email protected]>
|
|
This function can only be used with FITs that use embedded data. Rename
it so this is clear.
Signed-off-by: Simon Glass <[email protected]>
Acked-by: Heinrich Schuchardt <[email protected]>
|
|
Simon Glass <[email protected]> says:
This includes various patches towards implementing the VBE abrec
bootmeth in U-Boot. It mostly focuses on SPL tweaks and adjusting what
fatures are available in VPL.
Link: https://lore.kernel.org/r/[email protected]
|
|
When the best-match feature fails to find something, use the provided
config name as a fallback. The allows SPL to select a suitable config
when best-match is enabled.
Signed-off-by: Simon Glass <[email protected]>
|
|
This function exists but is not exported. Add a prototype so it can be
used elsewhere.
Signed-off-by: Simon Glass <[email protected]>
|
|
When the initialisation vector is randomly generated, its value shall be
stored in the FIT together with the encrypted data. The changes allow to
store the IV in the FIT also in the case where the key is not stored in
the DTB but retrieved somewhere else at runtime.
Signed-off-by: Paul HENRYS <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
This reverts commit 1fdf53ace13f745fe8ad4d2d4e79eed98088d555, reversing
changes made to e5aef1bbf11412eebd4c242b46adff5301353c30.
I had missed that this caused too much size growth on rcar3_salvator-x.
Signed-off-by: Tom Rini <[email protected]>
|
|
When the best-match feature fails to find something, use the provided
config name as a fallback. The allows SPL to select a suitable config
when best-match is enabled.
Signed-off-by: Simon Glass <[email protected]>
|
|
This function exists but is not exported. Add a prototype so it can be
used elsewhere.
Signed-off-by: Simon Glass <[email protected]>
|
|
The current implementation is reading the whole partition for boot and
vendor_boot image which can be long following the size of the
partition or the time to read blocks (driver/SoC specific).
For example with mediatek mt8365 EVK board, we have a 64MiB boot
partition and the boot image flashed in this partition is only 42MiB.
It takes ~8-9 secs to read the boot partition.
Instead we can retrieved the boot image and vendor boot image size
with these new functions:
- android_image_get_bootimg_size
- android_image_get_vendor_bootimg_size
Use these information and read only the necessary.
By doing this with mt8365 EVK board, we read boot image in ~5 secs.
Signed-off-by: Julien Masson <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Link: https://lore.kernel.org/r/20241121-bootmeth-android-part-sizes-v1-1-25760bbd0f08@baylibre.com
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
Sughosh Ganu <[email protected]> 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/[email protected]/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 current LMB API's for allocating and reserving memory use a
per-caller based memory view. Memory allocated by a caller can then be
overwritten by another caller. Make these allocations and reservations
persistent using the alloced list data structure.
Two alloced lists are declared -- one for the available(free) memory,
and one for the used memory. Once full, the list can then be extended
at runtime.
[sjg: Use a stack to store pointer of lmb struct when running lmb tests]
Signed-off-by: Sughosh Ganu <[email protected]>
Signed-off-by: Simon Glass <[email protected]>
[sjg: Optimise the logic to add a region in lmb_add_region_flags()]
|
|
android_image_get_ramdisk() will return an error if there is no ramdisk.
Using the android image without a ramdisk worked until commit
1ce8e10f3b4b ("image: Fix up ANDROID_BOOT_IMAGE ramdisk code") because
the return code wasn't checked until then. Return -ENOENT in case
there is no ramdisk and translate that into -ENOPKG in the calling
code, which will then indicate "no ramdisk" to its caller
(boot_get_ramdisk()).
This way, we can get rid of the "*rd_data = *rd_len = 0;" in the error
path, too.
With this, I'm able to boot a linux kernel using fastboot again:
fastboot --base 0x41000000 --header-version 2 --dtb /path/to/dtb \
--cmdline "root=/dev/mmcblk0p1 rootwait" boot path/to/Image
Signed-off-by: Michael Walle <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
The only way to configure the load addresses for both bootimg and
vendor_bootimg is by using the "abootimg" command.
If we want to use the C API, there is no equivalent.
Add set_abootimg_addr() and set_avendor_bootimg_addr() so that we can
specify the load address from C.
This can be useful for implementing an Android bootmethod.
Reviewed-by: Igor Opaniuk <[email protected]>
Reviewed-by: Julien Masson <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Reviewed-by: Guillaume La Roque <[email protected]>
Tested-by: Guillaume La Roque <[email protected]>
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
Some operating systems (e.g. seL4) and embedded applications are ELF
images. It is convenient to use FIT-images to implement trusted boot.
Added "elf" image type for booting using bootm command.
Signed-off-by: Maxim Moskalets <[email protected]>
|
|
Quote from [1]:
"For devices launching with Android 13, the generic ramdisk is removed
from the boot image and placed in a separate init_boot image.
This change leaves the boot image with only the GKI kernel."
While at it, update wrong error handling message when vendor_boot
cannot be loaded.
[1]: https://source.android.com/docs/core/architecture/partitions/generic-boot
Signed-off-by: Roman Stratiienko <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
|
|
Change type of ulong env_get_bootm_low() to phys_addr_t env_get_bootm_low().
The PPC/LS systems already treat env_get_bootm_low() result as phys_addr_t,
while the function itself still returns ulong. This is potentially dangerous
on 64bit systems, where ulong might not be large enough to hold the content
of "bootm_low" environment variable. Fix it by using phys_addr_t, similar to
what env_get_bootm_size() does, which returns phys_size_t .
Reviewed-by: Laurent Pinchart <[email protected]>
Reported-by: Laurent Pinchart <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
|
|
Commit cb9faa6f98ae ("tools: Use a single target-independent config to
enable OpenSSL") introduced a target-independent configuration to build
crypto features in host tools.
But since commit 2c21256b27d7 ("hash: Use Kconfig to enable hashing in
host tools and SPL") the build without OpenSSL is broken, due to FIT
signature/encryption features. Add missing conditional compilation
tokens to fix this.
Signed-off-by: Paul-Erwan Rio <[email protected]>
Tested-by: Alexander Dahl <[email protected]>
Cc: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
To quote the author:
This little series corrects a problem I noticed with arm64 images,
where the kernel is not recognised if compression is used:
U-Boot> tftp image.fit
Using ethernet@7d580000 device
TFTP from server 192.168.4.7; our IP address is 192.168.4.147
Filename 'image.fit'.
Load address: 0x1000000
Loading: ################################################## 23 MiB
20.5 MiB/s
done
Bytes transferred = 24118272 (1700400 hex)
U-Boot> bootm
## Loading kernel from FIT Image at 01000000 ...
Using 'conf-768' configuration
Trying 'kernel' kernel subimage
Description: Linux
Type: Kernel Image (no loading done)
Compression: gzip compressed
Data Start: 0x01000120
Data Size: 13662338 Bytes = 13 MiB
Verifying Hash Integrity ... OK
Bad Linux ARM64 Image magic!
With this series:
U-Boot> tftp 20000000 image.fit
Using ethernet@7d580000 device
TFTP from server 192.168.4.7; our IP address is 192.168.4.147
Filename 'image.fit'.
Load address: 0x20000000
Loading: ################################################## 23.5 MiB
20.8 MiB/s
done
Bytes transferred = 24642560 (1780400 hex)
U-Boot> bootm 0x20000000
## Loading kernel from FIT Image at 20000000 ...
Using 'conf-768' configuration
Trying 'kernel' kernel subimage
Description: Linux
Type: Kernel Image (no loading done)
Compression: zstd compressed
Data Start: 0x20000120
Data Size: 14333475 Bytes = 13.7 MiB
Verifying Hash Integrity ... OK
Using kernel load address 80000
## Loading fdt from FIT Image at 20000000 ...
Using 'conf-768' configuration
Trying 'fdt-768' fdt subimage
Description: Raspberry Pi 4 Model B
Type: Flat Device Tree
Compression: zstd compressed
Data Start: 0x215f820c
Data Size: 9137 Bytes = 8.9 KiB
Architecture: AArch64
Verifying Hash Integrity ... OK
Uncompressing Flat Device Tree to 3aff3010
Booting using the fdt blob at 0x3aff3010
Working FDT set to 3aff3010
Uncompressing Kernel Image (no loading done) to 80000
Moving Image from 0x80000 to 0x200000, end=2b00000
Using Device Tree in place at 000000003aff3010, end 000000003afff4c4
Working FDT set to 3aff3010
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd083]
The problem is that the arm64 magic is checked before the image is
decompressed. However this is only part of it. The kernel_noload image
type doesn't work with compression, since the kernel is not loaded. So
this series deals with that by using an lmb-allocated buffer for the
uncompressed kernel.
Another issue is that the arm64 handling is done too early, before the
image is loaded. This series moves it to after loading, so that
compression can be handled.
A patch is included to show the kernel load-address, so it is easy to
see what is going on.
One annoying feature of arm64 is that the image is often copied to
another address. It might be possible for U-Boot to figure that out
earlier and decompress it to the right place, but perhaps not.
With all of this it should be possible to boot a compressed kernel on
any of the 990 arm64 boards supported by Linux, although I have only
tested two.
|
|
Correct a typo in the function comment for image_decomp().
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
The of_size parameter is not used, so remove it.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
This function only uses two arguments. The 'arch' always has a constant
value, so drop it. This simplifies the function call.
Tidy up the function comment while we are here.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
This function only uses two arguments. The 'arch' always has a constant
value, so drop it. This simplifies the function call.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
This function only uses one argument from bootm (argv[2]) so pass it in
directly.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Rather than having boot_get_fdt() calculate this, move the calculation
into the caller. This removes the access to argv[0] in this function,
so we can later refactor it to just accept argv[2] instead of the whole
argv[].
Move the function comment to the header file and fix the u8 argument,
while we are here.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
This function normally only uses one argument so pass it in directly.
Move comments to the header file so could one day include these
functions in API docs. Fix up the u8 argument while here, since it
avoids the compiler having to mask the value on some machines.
The Android case here is bit strange, since it can use argv[0], so deal
with that in the caller.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Put a list of these in the function documentation so it is easier to
decode what went wrong.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
This function does not modify its first argument, so mark it const. Also
move the comments to the header file and expand them to provide more
useful information.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
