Documentation:
* replace MD5 and SHA1 by SHA256 in examples
UEFI:
* Refactor boot manager and bootefi command to let the EFI boot method work
without shell.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEK7wKXt3/btL6/yA+hO4vgnE3U0sFAmV++kAACgkQhO4vgnE3
U0ufFBAAp05Dxh/f7/lHh5YB6SX6IVyxw69G+PZxY6w4stsm8OaS8YX0bgGptC/B
Wz3xh42PTUN8sc9mQeUV+Scl+hAiURibhk8RVxtL+zV+j+zPrRBNIGiz8Kel7iNi
6F4k+5grw9NncD9MPpTpthfHP7lTKL9RE+YRscGDyaWd4COn8JJfw8Phluv7dvFj
XgkHZ96yhKnxzRQcBZTNV5nujptID608yqgp/k22AxKr+8GjdJZ6VbS2jKXN1vV4
kOQJTP/naezmOaU53sF5Nj2WtU+PzaKGA1mD+mIKSjzbQ0VH0PvJ7z67nB1e1d4+
eYkyTz6HJQi/vtx1f1wJIj5D2c5ti/FxHOtLwdwoudzlOSd8cvAMGrnle1mXzgqZ
juH/aLxdLqNyXu3mnWH+bo8Jy1nFDDBg+V77pdcUr9LXd+doTAye+oZz+iYaN3DW
7E+8Cw+hViOcs/5x5Hs4nqJOyZhvZpdN1fsyLurPyA6hemgESRZKVWimBMejYuwl
yUZA+6nDopwm2DInrIS10WgO9ob0jjUx/mgiEtYIPp/zYsg+Sz8npiQnAOvo9qA2
DY0EIewBaSwW5krgBC3G1OV6Q1FehRhEqW2XsC5AuqwU1l7O5I1e86WUMMP/2dzM
BEMuTuZcfOY2bB/2az/9MIAiNrQDbAs+GHWsh41cE2eZFzYYxT8=
=hvkt
-----END PGP SIGNATURE-----
Merge tag 'efi-next-20231217' of https://source.denx.de/u-boot/custodians/u-boot-efi into next
Pull request for efi-next-20231217
Documentation:
* replace MD5 and SHA1 by SHA256 in examples
UEFI:
* Refactor boot manager and bootefi command to let the EFI boot method work
without shell.
Both SHA1 and (especially) MD5 are no longer as safe as they once were for
cryptographic use. Replaces examples which use them with examples using
SHA256 instead. This will provide more-secure defaults for users who use
documentation examples as a base for their own use. This is not too
necessary for non-verified-boot scenarios (since someone could just replace
the checksum), but I wanted to be complete.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Now that efi_loader subsystem provides interfaces that are equivalent
with bootefi command, we can replace command invocations with APIs.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Now it is clear that the command actually depends on interfaces,
not "bootefi bootmgr" command.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
In the prior commits, interfaces for executing EFI binary and boot manager
were carved out. Move them under efi_loader directory so that they can
be called from other places without depending on bootefi command.
Only efi_selftest-related code will be left in bootefi.c.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Device paths allocated in bootefi_test_prepare() will be immediately
consumed by do_efi_selftest() and there is no need to keep them for later
use. Introduce test-specific varialbles to make it easier to move other
bootmgr functions into library directory in the next commit.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Carve binary execution code out of do_bootefi_image() in order to move
binary-execution specific code into library directory in the later
commit.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Carve EFI boot manager related code out of do_bootefi_image() in order
to move boot manager specific code into library directory in the later
commit.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Replicate some code and re-organize do_bootefi() into three cases, which
will be carved out as independent functions in the next two commits.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Unfold do_bootefi_image() into do_bootefi() in order to make it easier
to re-organize do_bootefi() in the next commit.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
After talking with the author off-list I was reminded that this part of
the series was not supposed to be merged, only parts 1-3 upon further
review.
This reverts commit 58a277c207.
Signed-off-by: Tom Rini <trini@konsulko.com>
The main thing in here is Igor's conversion of soc_clk_dump to a clk_ops
member. There's also a write-protect feature for nuvoton clocks.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
-----BEGIN PGP SIGNATURE-----
iQGTBAABCgB9FiEEkGEdW86NSNID6GAoPuiP7LShEG4FAmV8uvhfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDkw
NjExRDVCQ0U4RDQ4RDIwM0U4NjAyODNFRTg4RkVDQjRBMTEwNkUACgkQPuiP7LSh
EG5TtQf+N5BIVCRDFgFT7rM1lGYVtJEOm+oj58zQfM4MUAp2LKCHbHv7c8ZMUmdu
SJPJiDW4I2xQqAaawxcSub4L5d0G22SopotIVOcQXXTFFeW8rdpcRjhPhyIuHN8w
6dOo8T9U+BMjoNgtY48nNAhkzDGUDVJRZ/uBt8F1U6hKjk5OisSFyBfPZMtuvr/D
EBG8QqzXOMujrm9HGSVipvnSbgGX+QqtST4mVoatvQJ3DWYXxq8O5BPJFer1DL3F
BcI9yNaOG/L6MXAA3wkjh3nYLXoiRUgo2DRag++XMHnXYQ/xFzekraNAFHGDQslQ
Gnjz+5xp/z4ywOEkHSuI3mZIICBJ1Q==
=z+Sl
-----END PGP SIGNATURE-----
Merge tag 'clk-2024.01-next' of https://source.denx.de/u-boot/custodians/u-boot-clk into next
clock patches for u-boot/next
The main thing in here is Igor's conversion of soc_clk_dump to a clk_ops
member. There's also a write-protect feature for nuvoton clocks.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
This has some clock fixes which should go in before the release. It's a bit
late in the cycle, but most of these have tests to go along with them.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
-----BEGIN PGP SIGNATURE-----
iQGTBAABCgB9FiEEkGEdW86NSNID6GAoPuiP7LShEG4FAmV8vqdfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDkw
NjExRDVCQ0U4RDQ4RDIwM0U4NjAyODNFRTg4RkVDQjRBMTEwNkUACgkQPuiP7LSh
EG46JAf8CxGlFJG+z9cN9ID+3lXSz2pyDKVGPd4Lf1L9UobpTHgIAMvC+jOlI5wK
XCcx1IJ2LrIvWwRCNX5cJevYFee34yrAe3B1d6lJj+PHiw32oFXwx8P6YZ8G/aFa
vae4OTRJMz9/OIQI6Yy8jplEIManfZQFQCfoI3idU6ihtmqaZjlK1zLxVq8o38pv
Z5cLSPfP+0l6IwjXSgtHO/mHfEKiz7xaYxbj2uSzB4OYUSawGe3KDA7FBQjgmosA
/0UKAojJ0LsPtRNfI/s1hfzGnY10h5/NASWFOjPu9RHKKwIHH7zo+3D/rNs/rPui
8pbaXRiE4o3lrovL112iN5YJIqxcwA==
=9PNJ
-----END PGP SIGNATURE-----
Merge tag 'clk-2024.01-rc5' of https://source.denx.de/u-boot/custodians/u-boot-clk
clock changes for u-boot/master
This has some clock fixes which should go in before the release. It's a bit
late in the cycle, but most of these have tests to go along with them.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
The base address of extended DDR does not change across the K3 family.
Setting this per SoC is not needed. Remove this definition to help
remove the last bits from K3 include/configs/*.h files.
Signed-off-by: Andrew Davis <afd@ti.com>
Updates as a result of TIFS core now reserving a virtual interrupt
for enabling interrupts between DM to TIFS core. Because of this
change other virtual interrupt counts decrease by one.
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
Share the MCU GPIO interrupts between A53 core and DM R5 core. Allocating
2 instances each to A53 and DM R5.
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
Update am62ax rm-cfg with allocation entries for C7x core. Following
updates are added for C7x:
- Share split BCDMA tx and rx channels between DM R5 and C7x
- Share rings for split BCDMA tx and rx channels between DM R5 and C7x
- Add Global events and Virtual interrupts for C7x
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
The Device vs Normal memory map is the same for all K3 SoCs. Merge
the SoC specific maps into one.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
All normal memory areas should be mapped as such.
We added these un-cached holes in our memory map to hack around the
remoteproc driver missing the proper cache maintenance operations.
The problem is having these non-cached memory map areas causes stability
issues later in system operation due to the nature of the K3 coherency
architecture. Plus these are board specific carveouts and instead
should have been added at the board level, not here in the SoC common
code area.
Remove these non-cached memory map areas.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
ATF and OPTEE regions may be firewalled from non-secure entities. To
prevent access to this area we leave a hole there in the MMU map. This
is the same idea as [0] but we complete that patch by adding the same
for AM65, J721e, J7200, and J721s2 here.
[0] commit 0688ff3ae2 ("arm: mach-k3: arm64-mmu: do not map ATF and OPTEE regions in A53 MMU")
Signed-off-by: Andrew Davis <afd@ti.com>
NR_MMU_REGIONS is a copy/paste from another platform that extends
this list later. We do not do that, so let the list be the size
of the initializer list.
Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
This file is common for all K3, move it out of board/ directory and
into mach-k3. As we need to change the path in k3-binman.dtsi let's
take this opportunity to switch to absolute paths which makes adding
non-TI boards (like Toradex Verdin) not need to override these paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Assign ccf_clk_ops to .ops of clk_ccf driver so that it can act as an
clk provider. Also add "#clock-cells=<1>" to its device tree node.
Add "i2c_root" to clk_test in the device tree and driver for testing.
Get "i2c_root" clock in CCF unit tests and add tests for it.
Signed-off-by: Yang Xiwen <forbidden405@outlook.com>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
Link: https://lore.kernel.org/r/20231111-enable_count-v3-2-08a821892fa9@outlook.com
Add a flag to set ahb/apb/fiu/spi clock divider as read-only
The spi clock setting is related to booting flash, it is setup by early
bootloader.
It just protects the clock source and can't modify it in uboot.
Signed-off-by: Jim Liu <JJLIU0@nuvoton.com>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
Link: https://lore.kernel.org/r/20231114090004.3746024-1-JJLIU0@nuvoton.com
After introducing dump to clk_ops there is no need to override or expose
this symbol anymore.
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
Signed-off-by: Igor Prusov <ivprusov@sberdevices.ru>
Link: https://lore.kernel.org/r/20231109105516.24892-9-ivprusov@sberdevices.ru
Switch to using new dump operation in clock provider drivers instead of
overriding soc_clk_dump.
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
Signed-off-by: Igor Prusov <ivprusov@sberdevices.ru>
Link: https://lore.kernel.org/r/20231109105516.24892-8-ivprusov@sberdevices.ru
Add another loop to dump additional info from clock providers that
implement dump operation.
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
Signed-off-by: Igor Prusov <ivprusov@sberdevices.ru>
Link: https://lore.kernel.org/r/20231109105516.24892-7-ivprusov@sberdevices.ru
This adds dump function to struct clk_ops which should replace
soc_clk_dump. It allows clock drivers to provide custom dump
implementation without overriding generic CCF dump function.
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
Signed-off-by: Igor Prusov <ivprusov@sberdevices.ru>
[ Fixed parameter name in documentation ]
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Link: https://lore.kernel.org/r/20231109105516.24892-6-ivprusov@sberdevices.ru
It's possible for composite clocks to have a divider that does not
implement set_rate() operation. For example, sandbox_clk_composite()
registers composite clock with a divider that only has get_rate().
Currently clk_composite_set_rate() only checks thate rate_ops are
present, so for sandbox it will cause NULL dereference during
clk_set_rate().
This patch adds rate_ops->set_rate check tp clk_composite_set_rate().
Signed-off-by: Igor Prusov <ivprusov@salutedevices.com>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
Link: https://lore.kernel.org/r/20231205232334.2931-2-ivprusov@salutedevices.com
For some gate clocks and fixed clocks without a parent, calling
clk_register will print an useless error message indicating that parent
is missing. Fix that by gaurding log_xxx() with an if-statement.
Signed-off-by: Yang Xiwen <forbidden405@outlook.com>
Suggested-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Sean Anderson <seanga2@gmail.com>
Link: https://lore.kernel.org/r/20230807-clk-fix-v2-1-0b688e21fb4e@outlook.com
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.
It is not currently possible to execute the kernel in-place without
loading it. Use lmb to allocate memory for it.
Co-developed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
If the image is compressed, then the existing check fails, since the
header is wrong.
Move the check later in the boot process, after the kernel is
decompressed. This allows use of bootm with compressed kernels, while
still permitting an uncompressed kernel to be used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
The destination address for decompression (or copying) is useful
information. Show this to the user while booting, e.g.:
Uncompressing Kernel Image (no loading done) to 2080000
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Simplify the way all MTD devices are parsed.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Since MTD devices are partioned, we got the following
error when command "dfu 0" is executed:
DFU alt info setting: done
ERROR: Too many arguments for nor0
ERROR: DFU entities configuration failed!
ERROR: (partition table does not match dfu_alt_info?)
Fixes: 31325e1b8b ("stm32mp1: dynamically build DFU_ALT_INFO")
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
