December 2023 - U-Boot

[PATCH v2 0/4] clk: ccf: fix enable_count mismatch
by Yang Xiwen via B4 Relay 15 Dec '23

15 Dec '23

As described in [1], enable_count is incremented by 2 when ccf_clk_enable() is called. This series of patch fixed this issue and added a testcase for that. [1]: https://lore.kernel.org/all/SEZPR06MB695927A6DEEEF8489A06897396A7A@SEZPR06M… Signed-off-by: Yang Xiwen <forbidden405(a)outlook.com> --- Changes in v2: - add missing SoB in patch 1/4, no functional change - Link to v1: https://lore.kernel.org/r/20231111-enable_count-v1-0-509f400a99cb@outlook.c… --- Yang Xiwen (4): clk: clk_sandbox_ccf: assign ccf_clk_ops to .ops of the driver clk: get correct ops for clk_enable() and clk_disable() clk: clk_sandbox: get devm clock i2c_root test: dm: clk_ccf: get "i2c_root" clock from &clk_ccf arch/sandbox/dts/test.dts | 6 ++++-- arch/sandbox/include/asm/clk.h | 1 + drivers/clk/clk-uclass.c | 2 ++ drivers/clk/clk_sandbox_ccf.c | 1 + drivers/clk/clk_sandbox_test.c | 5 +++++ test/dm/clk_ccf.c | 14 +++++++++++--- 6 files changed, 24 insertions(+), 5 deletions(-) --- base-commit: 3b913c148249a2b9d12ff25517ec311646e83bee change-id: 20231111-enable_count-ad5001326815 Best regards, -- Yang Xiwen <forbidden405(a)outlook.com>

2 7

[PATCH v3 0/4] bootm: Handle compressed arm64 images with bootm
by Simon Glass 15 Dec '23

15 Dec '23

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. Changes in v3: - Rebase on to bootm-refactoring series - Support compression with an lmb-allocated region - Drop patch to disallow kernel_noload with compression - Drop patch 'bootm: Allow omitting the load address' Changes in v2: - Rework the patch based on a better understanding of events - Add a 'success' case to the cover letter - Redo how the arm64 support is implemented Simon Glass (4): image: Correct load_bug typo image: Show the load address when decompressing bootm: Move arm64-image processing later bootm: Support kernel_noload with compression boot/bootm.c | 63 +++++++++++++++++++++++++++++++++++-------------- boot/image.c | 13 ++++++---- include/image.h | 2 +- 3 files changed, 55 insertions(+), 23 deletions(-) -- 2.43.0.rc0.421.g78406f8d94-goog

2 6

Re: whitelist commands
by Simon Glass 15 Dec '23

15 Dec '23

Hi Thomas, On Fri, 15 Dec 2023 at 02:12, Thomas McCann <Tmccann(a)drumgrange.com> wrote: > > Hello Simon, > > Firstly my apologies I very new to U-Boot and just trying to make sense of it all. My chip currently does not boot because the commands "bootelf" commend is not whitelisted. > My question was two-fold really, it the whitelisting done by u-boot or is specified in the device tree? > How does one modify the u-boot boot.scr so that I can boot my device to not use bootelf? Please can you keep the ML copied with replies? (and BTW we try to add posts to the bottom) To find this: - look up do_bootelf() (~all commands start with do_ and end with the command name) - this is in cmd/elf.c - then look up cmd/Makefile to see where elf.o is enabled: obj-$(CONFIG_CMD_ELF) += elf.o - then look up cmd/Kconfig to see 'config CMD_ELF' So probably your board has CMD_ELF disabled. It is enabled by default, so perhaps you have '# CONFIG_CMD_ELF is not set' in the config_xxx_defconfig for your board? If you remove that, then the command should be enabled. You can check using 'make menuconfig' or by using grep on the .config file produced. Regards, Simon > > > Yours sincerely, > > Thomas McCann | Software Engineer > > -----Original Message----- > From: Simon Glass <sjg(a)chromium.org> > Sent: Wednesday, December 13, 2023 7:50 PM > To: Thomas McCann <Tmccann(a)drumgrange.com> > Cc: u-boot(a)lists.denx.de > Subject: Re: whitelist commands > > CAUTION: This email originated from outside the organisation, do not click links or open attachments unless you recognise the sender and know the content is safe. Forward this email to it(a)drumgrange.com<mailto:IT@drumgrange.com> if you believe it is suspicious. > > Hi Thomas, > > On Wed, 13 Dec 2023 at 07:29, Thomas McCann <Tmccann(a)drumgrange.com> wrote: > > > > How do I add commands to the whitelist. > > Which whitelist are you referring to? I am not aware of one for commands. > > Regards, > Simon > > > > > > > > Yours sincerely, > > > > [cid:image001.png@01DA2DCD.383194D0]<http://www.drumgrange.com/> > > > > Thomas McCann > > Software Engineer > > 📧 Tmccann(a)drumgrange.com > > > > [cid:image002.png@01DA2DCD.383194D0]<https://linkedin.com/company/drum > > grange-ltd>[cid:image003.png@01DA2DCD.383194D0]<https://www.adsgroup.o > > rg.uk/about/>. [cid:image004.png@01DA2DCD.383194D0] > > <https://hellios.com/joscar/> . [cid:image005.png@01DA2DCD.383194D0] > > <https://www.cyberaware.gov.uk/cyberessentials/> > > ..[cid:image006.jpg@01DA2DCD.383194D0]<https://www.drumgrange.com/abou > > t-us/armed-forces-corporate-covenant/> > > > > . > > Drumgrange is recruiting! For more information, click > > here.<https://www.drumgrange.com/careers/> > > . > > > > 🌲 Please consider the environment before printing this e-mail This > > communication may contain information which is subject to UK Export Control Law, commercial-in-confidence and/or legally privileged and is intended only for the addressee named above. If you are not the named addressee, the communication has been sent to you in error. Any copying, distribution or other use of the information is strictly prohibited. Please note we do not accept liability for any viruses which may be transmitted in or with this message. > > > > Drumgrange Ltd. is a company registered in England and Wales with company registration number 1460044 Registered office address. Drumgrange Ltd. Unit A, The Forum, Hanworth Lane, Chertsey, Surrey, KT16 9JX. > >

1 0

Re: [PATCH v4 1/8] binman: ti-secure: Add support for firewalling entities
by Jon Cormier 15 Dec '23

15 Dec '23

Hi Manorit, This commit added a possibly unintentional dependency on python 3.9+. I ran into this while trying to build the soon-to-be-released 09.01.00.008. Build failure on ubuntu 20.04 which uses python 3.8: "binman: 'type' object is not subscriptable" This can be fixed by: diff --git a/tools/binman/etype/ti_secure.py b/tools/binman/etype/ti_secure.py index f80eb542c956..872c6d38ff46 100644 --- a/tools/binman/etype/ti_secure.py +++ b/tools/binman/etype/ti_secure.py @@ -16,7 +16,7 @@ class Firewall(): id: int region: int control : int - permissions: list[hex] + permissions: list start_address: str end_address: str > Hi Manorit, > > On Wed, 11 Oct 2023 at 23:02, Manorit Chawdhry <m-chawd...(a)ti.com> wrote: > > > > Hi Simon, > > > > On 11:54-20231011, Manorit Chawdhry wrote: > > > We can now firewall entities while loading them through our secure > > > entity TIFS, the required information should be present in the > > > certificate that is being parsed by TIFS. > > > > > > The following commit adds the support to enable the certificates to be > > > generated if the firewall configurations are present in the binman dtsi > > > nodes. > > > > > > Signed-off-by: Manorit Chawdhry <m-chawd...(a)ti.com> > > > --- > > [..] > > > tools/binman/btool/openssl.py | 16 +++++++- > > > tools/binman/etype/ti_secure.py | 90 > > > +++++++++++++++++++++++++++++++++++++++++ > > > tools/binman/etype/x509_cert.py | 3 +- > > > 3 files changed, 106 insertions(+), 3 deletions(-) > > > > > > from binman.entry import EntryArg > > > from binman.etype.x509_cert import Entry_x509_cert > > > +from dataclasses import dataclass > > > > What all python versions do we support in u-boot? I see that dataclasses > > are in-built from python3.7 but for older versions we would need to > > install them separately, do I need to add this in buildman requirements > > for those versions? > > I would prefer not to worry about Python 3.6 if possible. There are a > few workarounds in buildman for it, though. > > Regards, > Simon

2 1

[PATCH v2] doc: Replace examples of MD5 and SHA1 with SHA256
by Sean Anderson 15 Dec '23

15 Dec '23

Both SHA1 and (especially) MD5 are no longer as safe as they once were for cryptographic use. Replace examples that 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. All the new hashes were generated like echo fake kernel hash | sha256sum which should be fine, since the actual values are just for example anyway. Signed-off-by: Sean Anderson <seanga2(a)gmail.com> Reviewed-by: Simon Glass <sjg(a)chromium.org> Reviewed-by: Peter Robinson <pbrobinson(a)gmail.com> Reviewed-by: Tom Rini <trini(a)konsulko.com> --- Changes in v2: - Mention CONFIG_SHA256/512 in doc/usage/fit/signature.rst - Describe how the hashes were generated in the commit message doc/chromium/files/chromebook_jerry.its | 4 +- doc/chromium/files/nyan-big.its | 4 +- doc/usage/cmd/imxtract.rst | 6 +- doc/usage/fit/beaglebone_vboot.rst | 74 ++++++++++++------------ doc/usage/fit/howto.rst | 40 ++++++------- doc/usage/fit/kernel.rst | 6 +- doc/usage/fit/kernel_fdt.rst | 4 +- doc/usage/fit/kernel_fdts_compressed.rst | 6 +- doc/usage/fit/multi-with-fpga.rst | 6 +- doc/usage/fit/multi-with-loadables.rst | 8 +-- doc/usage/fit/multi.rst | 12 ++-- doc/usage/fit/sign-configs.rst | 6 +- doc/usage/fit/sign-images.rst | 4 +- doc/usage/fit/signature.rst | 28 +++++---- doc/usage/fit/update3.rst | 6 +- doc/usage/fit/update_uboot.rst | 2 +- doc/usage/fit/x86-fit-boot.rst | 8 +-- 17 files changed, 115 insertions(+), 109 deletions(-) diff --git a/doc/chromium/files/chromebook_jerry.its b/doc/chromium/files/chromebook_jerry.its index 7505a20535b..02e5e1340f3 100644 --- a/doc/chromium/files/chromebook_jerry.its +++ b/doc/chromium/files/chromebook_jerry.its @@ -15,7 +15,7 @@ load = <0>; entry = <0>; hash-2 { - algo = "sha1"; + algo = "sha256"; }; }; @@ -26,7 +26,7 @@ arch = "arm"; compression = "none"; hash-1{ - algo = "sha1"; + algo = "sha256"; }; }; }; diff --git a/doc/chromium/files/nyan-big.its b/doc/chromium/files/nyan-big.its index bd412915e95..60bdffbb829 100644 --- a/doc/chromium/files/nyan-big.its +++ b/doc/chromium/files/nyan-big.its @@ -15,7 +15,7 @@ load = <0>; entry = <0>; hash-2 { - algo = "sha1"; + algo = "sha256"; }; }; @@ -26,7 +26,7 @@ arch = "arm"; compression = "none"; hash-1{ - algo = "sha1"; + algo = "sha256"; }; }; }; diff --git a/doc/usage/cmd/imxtract.rst b/doc/usage/cmd/imxtract.rst index eb64b1cefab..16be60b4aab 100644 --- a/doc/usage/cmd/imxtract.rst +++ b/doc/usage/cmd/imxtract.rst @@ -45,14 +45,14 @@ Examples With verify=no incorrect hashes, signatures, or check sums don't stop the extraction. But correct hashes are still indicated in the output -(here: md5, sha1). +(here: sha256, sha512). .. code-block:: console => setenv verify no => imxtract $loadaddr kernel-1 $kernel_addr_r ## Copying 'kernel-1' subimage from FIT image at 40200000 ... - md5+ sha1+ Loading part 0 ... OK + sha256+ sha512+ Loading part 0 ... OK => With verify=yes incorrect hashes, signatures, or check sums stop the extraction. @@ -62,7 +62,7 @@ With verify=yes incorrect hashes, signatures, or check sums stop the extraction. => setenv verify yes => imxtract $loadaddr kernel-1 $kernel_addr_r ## Copying 'kernel-1' subimage from FIT image at 40200000 ... - md5 error! + sha256 error! Bad hash value for 'hash-1' hash node in 'kernel-1' image node Bad Data Hash => diff --git a/doc/usage/fit/beaglebone_vboot.rst b/doc/usage/fit/beaglebone_vboot.rst index a102be187bd..cd6bb141910 100644 --- a/doc/usage/fit/beaglebone_vboot.rst +++ b/doc/usage/fit/beaglebone_vboot.rst @@ -145,7 +145,7 @@ Put this into a file in that directory called sign.its:: load = <0x80008000>; entry = <0x80008000>; hash-1 { - algo = "sha1"; + algo = "sha256"; }; }; fdt-1 { @@ -155,7 +155,7 @@ Put this into a file in that directory called sign.its:: arch = "arm"; compression = "none"; hash-1 { - algo = "sha1"; + algo = "sha256"; }; }; }; @@ -165,7 +165,7 @@ Put this into a file in that directory called sign.its:: kernel = "kernel"; fdt = "fdt-1"; signature-1 { - algo = "sha1,rsa2048"; + algo = "sha256,rsa2048"; key-name-hint = "dev"; sign-images = "fdt", "kernel"; }; @@ -227,8 +227,8 @@ You should see something like this:: OS: Linux Load Address: 0x80008000 Entry Point: 0x80008000 - Hash algo: sha1 - Hash value: c94364646427e10f423837e559898ef02c97b988 + Hash algo: sha256 + Hash value: 51b2adf9c1016ed46f424d85dcc6c34c46a20b9bee7227e06a6b6320ca5d35c1 Image 1 (fdt-1) Description: beaglebone-black Created: Sun Jun 1 12:50:30 2014 @@ -236,8 +236,8 @@ You should see something like this:: Compression: uncompressed Data Size: 31547 Bytes = 30.81 kB = 0.03 MB Architecture: ARM - Hash algo: sha1 - Hash value: cb09202f889d824f23b8e4404b781be5ad38a68d + Hash algo: sha256 + Hash value: 807d5842a04132261ba092373bd40c78991bc7ce173d1175cd976ec37858e7cd Default Configuration: 'conf-1' Configuration 0 (conf-1) Description: unavailable @@ -255,11 +255,11 @@ You can also run fit_check_sign to check it:: which results in:: - Verifying Hash Integrity ... sha1,rsa2048:dev+ + Verifying Hash Integrity ... sha256,rsa2048:dev+ ## Loading kernel from FIT Image at 7fc6ee469000 ... Using 'conf-1' configuration Verifying Hash Integrity ... - sha1,rsa2048:dev+ + sha256,rsa2048:dev+ OK Trying 'kernel' kernel subimage @@ -272,10 +272,10 @@ which results in:: OS: Linux Load Address: 0x80008000 Entry Point: 0x80008000 - Hash algo: sha1 - Hash value: c94364646427e10f423837e559898ef02c97b988 + Hash algo: sha256 + Hash value: 51b2adf9c1016ed46f424d85dcc6c34c46a20b9bee7227e06a6b6320ca5d35c1 Verifying Hash Integrity ... - sha1+ + sha256+ OK Unimplemented compression type 4 @@ -288,10 +288,10 @@ which results in:: Compression: uncompressed Data Size: 31547 Bytes = 30.81 kB = 0.03 MB Architecture: ARM - Hash algo: sha1 - Hash value: cb09202f889d824f23b8e4404b781be5ad38a68d + Hash algo: sha256 + Hash value: 807d5842a04132261ba092373bd40c78991bc7ce173d1175cd976ec37858e7cd Verifying Hash Integrity ... - sha1+ + sha256+ OK Loading Flat Device Tree ... OK @@ -303,14 +303,14 @@ which results in:: Signature check OK -At the top, you see "sha1,rsa2048:dev+". This means that it checked an RSA key -of size 2048 bits using SHA1 as the hash algorithm. The key name checked was +At the top, you see "sha256,rsa2048:dev+". This means that it checked an RSA key +of size 2048 bits using SHA256 as the hash algorithm. The key name checked was 'dev' and the '+' means that it verified. If it showed '-' that would be bad. Once the configuration is verified it is then possible to rely on the hashes in each image referenced by that configuration. So fit_check_sign goes on to load each of the images. We have a kernel and an FDT but no ramkdisk. In each -case fit_check_sign checks the hash and prints sha1+ meaning that the SHA1 +case fit_check_sign checks the hash and prints sha256+ meaning that the SHA256 hash verified. This means that none of the images has been tampered with. There is a test in test/vboot which uses U-Boot's sandbox build to verify that @@ -328,11 +328,11 @@ This tells us that the kernel starts at byte offset 168 (decimal) in image.fit and extends for about 7MB. Try changing a byte at 0x2000 (say) and run fit_check_sign again. You should see something like:: - Verifying Hash Integrity ... sha1,rsa2048:dev+ + Verifying Hash Integrity ... sha256,rsa2048:dev+ ## Loading kernel from FIT Image at 7f5a39571000 ... Using 'conf-1' configuration Verifying Hash Integrity ... - sha1,rsa2048:dev+ + sha256,rsa2048:dev+ OK Trying 'kernel' kernel subimage @@ -345,10 +345,10 @@ fit_check_sign again. You should see something like:: OS: Linux Load Address: 0x80008000 Entry Point: 0x80008000 - Hash algo: sha1 - Hash value: c94364646427e10f423837e559898ef02c97b988 + Hash algo: sha256 + Hash value: 51b2adf9c1016ed46f424d85dcc6c34c46a20b9bee7227e06a6b6320ca5d35c1 Verifying Hash Integrity ... - sha1 error + sha256 error Bad hash value for 'hash-1' hash node in 'kernel' image node Bad Data Hash @@ -361,10 +361,10 @@ fit_check_sign again. You should see something like:: Compression: uncompressed Data Size: 31547 Bytes = 30.81 kB = 0.03 MB Architecture: ARM - Hash algo: sha1 - Hash value: cb09202f889d824f23b8e4404b781be5ad38a68d + Hash algo: sha256 + Hash value: 807d5842a04132261ba092373bd40c78991bc7ce173d1175cd976ec37858e7cd Verifying Hash Integrity ... - sha1+ + sha256+ OK Loading Flat Device Tree ... OK @@ -419,13 +419,13 @@ need to change the hash to match. Let's simulate that by changing a byte of the hash:: fdtget -tx image.fit /images/kernel/hash-1 value - c9436464 6427e10f 423837e5 59898ef0 2c97b988 - fdtput -tx image.fit /images/kernel/hash-1 value c9436464 6427e10f 423837e5 59898ef0 2c97b981 + 51b2adf9 c1016ed4 6f424d85 dcc6c34c 46a20b9b ee7227e0 6a6b6320 ca5d35c1 + fdtput -tx image.fit /images/kernel/hash-1 value 51b2adf9 c1016ed4 6f424d85 dcc6c34c 46a20b9b ee7227e0 6a6b6320 ca5d35c8 Now check it again:: $UOUT/tools/fit_check_sign -f image.fit -k am335x-boneblack-pubkey.dtb - Verifying Hash Integrity ... sha1,rsa2048:devrsa_verify_with_keynode: RSA failed to verify: -13 + Verifying Hash Integrity ... sha256,rsa2048:devrsa_verify_with_keynode: RSA failed to verify: -13 rsa_verify_with_keynode: RSA failed to verify: -13 - Failed to verify required signature 'key-dev' @@ -446,7 +446,7 @@ running the mkimage link again. Then:: fdtput -p image.fit /configurations/conf-1/signature-1 value fred $UOUT/tools/fit_check_sign -f image.fit -k am335x-boneblack-pubkey.dtb Verifying Hash Integrity ... - - sha1,rsa2048:devrsa_verify_with_keynode: RSA failed to verify: -13 + sha256,rsa2048:devrsa_verify_with_keynode: RSA failed to verify: -13 rsa_verify_with_keynode: RSA failed to verify: -13 - Failed to verify required signature 'key-dev' @@ -528,7 +528,7 @@ You should then see something like this:: U-Boot# bootm 82000000 ## Loading kernel from FIT Image at 82000000 ... Using 'conf-1' configuration - Verifying Hash Integrity ... sha1,rsa2048:dev+ OK + Verifying Hash Integrity ... sha256,rsa2048:dev+ OK Trying 'kernel' kernel subimage Description: unavailable Created: 2014-06-01 19:32:54 UTC @@ -540,9 +540,9 @@ You should then see something like this:: OS: Linux Load Address: 0x80008000 Entry Point: 0x80008000 - Hash algo: sha1 - Hash value: c94364646427e10f423837e559898ef02c97b988 - Verifying Hash Integrity ... sha1+ OK + Hash algo: sha256 + Hash value: 51b2adf9c1016ed46f424d85dcc6c34c46a20b9bee7227e06a6b6320ca5d35c1 + Verifying Hash Integrity ... sha256+ OK ## Loading fdt from FIT Image at 82000000 ... Using 'conf-1' configuration Trying 'fdt-1' fdt subimage @@ -553,9 +553,9 @@ You should then see something like this:: Data Start: 0x8276e2ec Data Size: 31547 Bytes = 30.8 KiB Architecture: ARM - Hash algo: sha1 - Hash value: cb09202f889d824f23b8e4404b781be5ad38a68d - Verifying Hash Integrity ... sha1+ OK + Hash algo: sha256 + Hash value: 807d5842a04132261ba092373bd40c78991bc7ce173d1175cd976ec37858e7cd + Verifying Hash Integrity ... sha256+ OK Booting using the fdt blob at 0x8276e2ec Uncompressing Kernel Image ... OK Loading Device Tree to 8fff5000, end 8ffffb3a ... OK diff --git a/doc/usage/fit/howto.rst b/doc/usage/fit/howto.rst index def12a70f7b..b5097d4460b 100644 --- a/doc/usage/fit/howto.rst +++ b/doc/usage/fit/howto.rst @@ -8,7 +8,7 @@ Overview The new uImage format allows more flexibility in handling images of various types (kernel, ramdisk, etc.), it also enhances integrity protection of images -with sha1 and md5 checksums. +with cryptographic checksums. Two auxiliary tools are needed on the development host system in order to create an uImage in the new format: mkimage and dtc, although only one @@ -99,7 +99,7 @@ started by ATF where SPL is loading U-Boot (as loadables) and ATF (as firmware). load = <0x8 0x8000000>; entry = <0x8 0x8000000>; hash { - algo = "md5"; + algo = "sha256"; }; }; atf { @@ -112,7 +112,7 @@ started by ATF where SPL is loading U-Boot (as loadables) and ATF (as firmware). load = <0xfffea000>; entry = <0xfffea000>; hash { - algo = "md5"; + algo = "sha256"; }; }; fdt_1 { @@ -123,7 +123,7 @@ started by ATF where SPL is loading U-Boot (as loadables) and ATF (as firmware). compression = "none"; load = <0x100000>; hash { - algo = "md5"; + algo = "sha256"; }; }; }; @@ -190,8 +190,8 @@ its contents: Entry Point: 0x00000000 Hash algo: crc32 Hash value: 2ae2bb40 - Hash algo: sha1 - Hash value: 3c200f34e2c226ddc789240cca0c59fc54a67cf4 + Hash algo: sha256 + Hash value: c22f6bb5a3f96942507a37e7d6a9333ebdc7da57971bc4c082113fe082fdc40f Default Configuration: 'config-1' Configuration 0 (config-1) Description: Boot Linux kernel @@ -236,8 +236,8 @@ specific to the new image format). Entry Point: 0x00000000 Hash algo: crc32 Hash value: 2ae2bb40 - Hash algo: sha1 - Hash value: 3c200f34e2c226ddc789240cca0c59fc54a67cf4 + Hash algo: sha256 + Hash value: c22f6bb5a3f96942507a37e7d6a9333ebdc7da57971bc4c082113fe082fdc40f Default Configuration: 'config-1' Configuration 0 (config-1) Description: Boot Linux kernel @@ -258,8 +258,8 @@ specific to the new image format). Entry Point: 0x00000000 Hash algo: crc32 Hash value: 2ae2bb40 - Hash algo: sha1 - Hash value: 3c200f34e2c226ddc789240cca0c59fc54a67cf4 + Hash algo: sha256 + Hash value: c22f6bb5a3f96942507a37e7d6a9333ebdc7da57971bc4c082113fe082fdc40f Verifying Hash Integrity ... crc32+ sha1+ OK Uncompressing Kernel Image ... OK Memory BAT mapping: BAT2=256Mb, BAT3=0Mb, residual: 0Mb @@ -302,8 +302,8 @@ modified to take the files from some other location if needed): Entry Point: 0x00000000 Hash algo: crc32 Hash value: 2c0cc807 - Hash algo: sha1 - Hash value: 264b59935470e42c418744f83935d44cdf59a3bb + Hash algo: sha256 + Hash value: a3e9e18b793873827d27c97edfbca67c404a1972d9f36cf48e73ff85d69a422c Image 1 (fdt-1) Description: Flattened Device Tree blob Type: Flat Device Tree @@ -312,8 +312,8 @@ modified to take the files from some other location if needed): Architecture: PowerPC Hash algo: crc32 Hash value: 0d655d71 - Hash algo: sha1 - Hash value: 25ab4e15cd4b8a5144610394560d9c318ce52def + Hash algo: sha256 + Hash value: e9b9a40c5e2e12213ac819e7ccad7271ef43eb5edf9b421f0fa0b4b51bfdb214 Default Configuration: 'conf-1' Configuration 0 (conf-1) Description: Boot Linux kernel with FDT blob @@ -353,8 +353,8 @@ inspected and booted: Entry Point: 0x00000000 Hash algo: crc32 Hash value: 2c0cc807 - Hash algo: sha1 - Hash value: 264b59935470e42c418744f83935d44cdf59a3bb + Hash algo: sha256 + Hash value: a3e9e18b793873827d27c97edfbca67c404a1972d9f36cf48e73ff85d69a422c Image 1 (fdt-1) Description: Flattened Device Tree blob Type: Flat Device Tree @@ -364,8 +364,8 @@ inspected and booted: Architecture: PowerPC Hash algo: crc32 Hash value: 0d655d71 - Hash algo: sha1 - Hash value: 25ab4e15cd4b8a5144610394560d9c318ce52def + Hash algo: sha256 + Hash value: e9b9a40c5e2e12213ac819e7ccad7271ef43eb5edf9b421f0fa0b4b51bfdb214 Default Configuration: 'conf-1' Configuration 0 (conf-1) Description: Boot Linux kernel with FDT blob @@ -387,7 +387,7 @@ inspected and booted: Hash algo: crc32 Hash value: 2c0cc807 Hash algo: sha1 - Hash value: 264b59935470e42c418744f83935d44cdf59a3bb + Hash value: a3e9e18b793873827d27c97edfbca67c404a1972d9f36cf48e73ff85d69a422c Verifying Hash Integrity ... crc32+ sha1+ OK Uncompressing Kernel Image ... OK ## Flattened Device Tree from FIT Image at 00900000 @@ -402,7 +402,7 @@ inspected and booted: Hash algo: crc32 Hash value: 0d655d71 Hash algo: sha1 - Hash value: 25ab4e15cd4b8a5144610394560d9c318ce52def + Hash value: e9b9a40c5e2e12213ac819e7ccad7271ef43eb5edf9b421f0fa0b4b51bfdb214 Verifying Hash Integrity ... crc32+ sha1+ OK Booting using the fdt blob at 0xa0abdc Loading Device Tree to 007fc000, end 007fffff ... OK diff --git a/doc/usage/fit/kernel.rst b/doc/usage/fit/kernel.rst index 012a81efead..e56017985b2 100644 --- a/doc/usage/fit/kernel.rst +++ b/doc/usage/fit/kernel.rst @@ -25,7 +25,7 @@ Single kernel algo = "crc32"; }; hash-2 { - algo = "sha1"; + algo = "sha256"; }; }; }; @@ -59,7 +59,7 @@ For x86 a setup node is also required: see x86-fit-boot:: load = <0x01000000>; entry = <0x00000000>; hash-2 { - algo = "sha1"; + algo = "sha256"; }; }; @@ -73,7 +73,7 @@ For x86 a setup node is also required: see x86-fit-boot:: load = <0x00090000>; entry = <0x00090000>; hash-2 { - algo = "sha1"; + algo = "sha256"; }; }; }; diff --git a/doc/usage/fit/kernel_fdt.rst b/doc/usage/fit/kernel_fdt.rst index 8eee13af780..9cc26fb7831 100644 --- a/doc/usage/fit/kernel_fdt.rst +++ b/doc/usage/fit/kernel_fdt.rst @@ -25,7 +25,7 @@ Single kernel and FDT blob algo = "crc32"; }; hash-2 { - algo = "sha1"; + algo = "sha256"; }; }; fdt-1 { @@ -38,7 +38,7 @@ Single kernel and FDT blob algo = "crc32"; }; hash-2 { - algo = "sha1"; + algo = "sha256"; }; }; }; diff --git a/doc/usage/fit/kernel_fdts_compressed.rst b/doc/usage/fit/kernel_fdts_compressed.rst index 0b169c7c27c..b57871da58b 100644 --- a/doc/usage/fit/kernel_fdts_compressed.rst +++ b/doc/usage/fit/kernel_fdts_compressed.rst @@ -28,7 +28,7 @@ string to match directly. algo = "crc32"; }; hash-2 { - algo = "sha1"; + algo = "sha256"; }; }; fdt@1 { @@ -41,7 +41,7 @@ string to match directly. algo = "crc32"; }; hash-2 { - algo = "sha1"; + algo = "sha256"; }; }; fdt@2 { @@ -54,7 +54,7 @@ string to match directly. algo = "crc32"; }; hash-2 { - algo = "sha1"; + algo = "sha256"; }; }; }; diff --git a/doc/usage/fit/multi-with-fpga.rst b/doc/usage/fit/multi-with-fpga.rst index 28d7d5d2626..4c7f1bebd5a 100644 --- a/doc/usage/fit/multi-with-fpga.rst +++ b/doc/usage/fit/multi-with-fpga.rst @@ -20,7 +20,7 @@ This example makes use of the 'loadables' field:: compression = "none"; load = <0x10000000>; hash-1 { - algo = "md5"; + algo = "sha256"; }; }; @@ -33,7 +33,7 @@ This example makes use of the 'loadables' field:: load = <0x30000000>; compatible = "u-boot,fpga-legacy" hash-1 { - algo = "md5"; + algo = "sha256"; }; }; @@ -47,7 +47,7 @@ This example makes use of the 'loadables' field:: load = <0x8000>; entry = <0x8000>; hash-1 { - algo = "md5"; + algo = "sha256"; }; }; }; diff --git a/doc/usage/fit/multi-with-loadables.rst b/doc/usage/fit/multi-with-loadables.rst index a0241df96ca..7849cb544f1 100644 --- a/doc/usage/fit/multi-with-loadables.rst +++ b/doc/usage/fit/multi-with-loadables.rst @@ -22,7 +22,7 @@ This example makes use of the 'loadables' field:: load = <0xa0000000>; entry = <0xa0000000>; hash-1 { - algo = "md5"; + algo = "sha256"; }; }; @@ -34,7 +34,7 @@ This example makes use of the 'loadables' field:: compression = "none"; load = <0xb0000000>; hash-1 { - algo = "md5"; + algo = "sha256"; }; }; @@ -46,7 +46,7 @@ This example makes use of the 'loadables' field:: compression = "none"; load = <0xb0400000>; hash-1 { - algo = "md5"; + algo = "sha256"; }; }; @@ -60,7 +60,7 @@ This example makes use of the 'loadables' field:: load = <0xa0000000>; entry = <0xa0000000>; hash-1 { - algo = "md5"; + algo = "sha256"; }; }; }; diff --git a/doc/usage/fit/multi.rst b/doc/usage/fit/multi.rst index 2e6ae58c409..e68752b2ad0 100644 --- a/doc/usage/fit/multi.rst +++ b/doc/usage/fit/multi.rst @@ -22,10 +22,10 @@ Multiple kernels, ramdisks and FDT blobs load = <00000000>; entry = <00000000>; hash-1 { - algo = "md5"; + algo = "sha256"; }; hash-2 { - algo = "sha1"; + algo = "sha512"; }; }; @@ -39,7 +39,7 @@ Multiple kernels, ramdisks and FDT blobs load = <00000000>; entry = <00000000>; hash-1 { - algo = "sha1"; + algo = "sha256"; }; }; @@ -53,7 +53,7 @@ Multiple kernels, ramdisks and FDT blobs load = <00000000>; entry = <00000000>; hash-1 { - algo = "md5"; + algo = "sha256"; }; }; @@ -67,7 +67,7 @@ Multiple kernels, ramdisks and FDT blobs load = <00000000>; entry = <00000000>; hash-1 { - algo = "sha1"; + algo = "sha256"; }; }; @@ -104,7 +104,7 @@ Multiple kernels, ramdisks and FDT blobs compression = "none"; load = <00700000>; hash-1 { - algo = "sha1"; + algo = "sha256"; }; }; diff --git a/doc/usage/fit/sign-configs.rst b/doc/usage/fit/sign-configs.rst index 6a3df8f2c5b..6d98d44430c 100644 --- a/doc/usage/fit/sign-configs.rst +++ b/doc/usage/fit/sign-configs.rst @@ -22,7 +22,7 @@ Signed configurations entry = <0x8>; kernel-version = <1>; hash-1 { - algo = "sha1"; + algo = "sha256"; }; }; fdt-1 { @@ -33,7 +33,7 @@ Signed configurations compression = "none"; fdt-version = <1>; hash-1 { - algo = "sha1"; + algo = "sha256"; }; }; }; @@ -43,7 +43,7 @@ Signed configurations kernel = "kernel"; fdt = "fdt-1"; signature { - algo = "sha1,rsa2048"; + algo = "sha256,rsa2048"; key-name-hint = "dev"; sign-images = "fdt", "kernel"; }; diff --git a/doc/usage/fit/sign-images.rst b/doc/usage/fit/sign-images.rst index 7d54d702c97..ca7d10fab83 100644 --- a/doc/usage/fit/sign-images.rst +++ b/doc/usage/fit/sign-images.rst @@ -22,7 +22,7 @@ Signed Images entry = <0x8>; kernel-version = <1>; signature { - algo = "sha1,rsa2048"; + algo = "sha256,rsa2048"; key-name-hint = "dev"; }; }; @@ -34,7 +34,7 @@ Signed Images compression = "none"; fdt-version = <1>; signature { - algo = "sha1,rsa2048"; + algo = "sha256,rsa2048"; key-name-hint = "dev"; }; }; diff --git a/doc/usage/fit/signature.rst b/doc/usage/fit/signature.rst index 0804bffd1ed..fe59f7839c3 100644 --- a/doc/usage/fit/signature.rst +++ b/doc/usage/fit/signature.rst @@ -93,7 +93,7 @@ Public keys should be stored as sub-nodes in a /signature node. Required properties are: algo - Algorithm name (e.g. "sha1,rsa2048" or "sha256,ecdsa256") + Algorithm name (e.g. "sha256,rsa2048" or "sha512,ecdsa256") Optional properties are: @@ -219,28 +219,28 @@ As an example, consider this FIT:: kernel-1 { data = <data for kernel1> signature-1 { - algo = "sha1,rsa2048"; + algo = "sha256,rsa2048"; value = <...kernel signature 1...> }; }; kernel-2 { data = <data for kernel2> signature-1 { - algo = "sha1,rsa2048"; + algo = "sha256,rsa2048"; value = <...kernel signature 2...> }; }; fdt-1 { data = <data for fdt1>; signature-1 { - algo = "sha1,rsa2048"; + algo = "sha256,rsa2048"; value = <...fdt signature 1...> }; }; fdt-2 { data = <data for fdt2>; signature-1 { - algo = "sha1,rsa2048"; + algo = "sha256,rsa2048"; value = <...fdt signature 2...> }; }; @@ -291,28 +291,28 @@ So the above example is adjusted to look like this:: kernel-1 { data = <data for kernel1> hash-1 { - algo = "sha1"; + algo = "sha256"; value = <...kernel hash 1...> }; }; kernel-2 { data = <data for kernel2> hash-1 { - algo = "sha1"; + algo = "sha256"; value = <...kernel hash 2...> }; }; fdt-1 { data = <data for fdt1>; hash-1 { - algo = "sha1"; + algo = "sha256"; value = <...fdt hash 1...> }; }; fdt-2 { data = <data for fdt2>; hash-1 { - algo = "sha1"; + algo = "sha256"; value = <...fdt hash 2...> }; }; @@ -323,7 +323,7 @@ So the above example is adjusted to look like this:: kernel = "kernel-1"; fdt = "fdt-1"; signature-1 { - algo = "sha1,rsa2048"; + algo = "sha256,rsa2048"; value = <...conf 1 signature...>; }; }; @@ -331,7 +331,7 @@ So the above example is adjusted to look like this:: kernel = "kernel-2"; fdt = "fdt-2"; signature-1 { - algo = "sha1,rsa2048"; + algo = "sha256,rsa2048"; value = <...conf 1 signature...>; }; }; @@ -419,6 +419,12 @@ be enabled: CONFIG_FIT_SIGNATURE enable signing and verification in FITs +CONFIG_SHA256 + enable SHA-256 algorithm for hashing + +CONFIG_SHA512 + enable SHA-512 algorithm for hashing + CONFIG_RSA enable RSA algorithm for signing diff --git a/doc/usage/fit/update3.rst b/doc/usage/fit/update3.rst index 4ff3950c01e..24235801470 100644 --- a/doc/usage/fit/update3.rst +++ b/doc/usage/fit/update3.rst @@ -19,7 +19,7 @@ Automatic software update: multiple files type = "firmware"; load = <FF700000>; hash-1 { - algo = "sha1"; + algo = "sha256"; }; }; update-2 { @@ -29,7 +29,7 @@ Automatic software update: multiple files type = "firmware"; load = <FF8E0000>; hash-1 { - algo = "sha1"; + algo = "sha256"; }; }; @@ -40,7 +40,7 @@ Automatic software update: multiple files type = "firmware"; load = <FFAC0000>; hash-1 { - algo = "sha1"; + algo = "sha256"; }; }; }; diff --git a/doc/usage/fit/update_uboot.rst b/doc/usage/fit/update_uboot.rst index a9288ee6367..811d008d13d 100644 --- a/doc/usage/fit/update_uboot.rst +++ b/doc/usage/fit/update_uboot.rst @@ -21,7 +21,7 @@ Make sure the flashing addresses ('load' prop) is correct for your board! type = "firmware"; load = <0xFFFC0000>; hash-1 { - algo = "sha1"; + algo = "sha256"; }; }; }; diff --git a/doc/usage/fit/x86-fit-boot.rst b/doc/usage/fit/x86-fit-boot.rst index 93b73bb9019..9e3e32204d5 100644 --- a/doc/usage/fit/x86-fit-boot.rst +++ b/doc/usage/fit/x86-fit-boot.rst @@ -207,16 +207,16 @@ You can take a look at the resulting fit file if you like:: OS: Linux Load Address: 0x01000000 Entry Point: 0x00000000 - Hash algo: sha1 - Hash value: 446b5163ebfe0fb6ee20cbb7a8501b263cd92392 + Hash algo: sha256 + Hash value: 4bbf49981ade163ed089f8525236fedfe44508e9b02a21a48294a96a1518107b Image 1 (setup) Description: Linux setup.bin Created: Tue Oct 7 10:57:24 2014 Type: x86 setup.bin Compression: uncompressed Data Size: 12912 Bytes = 12.61 kB = 0.01 MB - Hash algo: sha1 - Hash value: a1f2099cf47ff9816236cd534c77af86e713faad + Hash algo: sha256 + Hash value: 6aa50c2e0392cb119cdf0971dce8339f100608ed3757c8200b0e39e889e432d2 Default Configuration: 'config-1' Configuration 0 (config-1) Description: Boot Linux kernel -- 2.37.1

1 0

[PATCH] doc: Replace examples of MD5 and SHA1 with SHA256
by Sean Anderson 15 Dec '23

15 Dec '23

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(a)gmail.com> --- doc/chromium/files/chromebook_jerry.its | 4 +- doc/chromium/files/nyan-big.its | 4 +- doc/usage/cmd/imxtract.rst | 6 +- doc/usage/fit/beaglebone_vboot.rst | 74 ++++++++++++------------ doc/usage/fit/howto.rst | 40 ++++++------- doc/usage/fit/kernel.rst | 6 +- doc/usage/fit/kernel_fdt.rst | 4 +- doc/usage/fit/kernel_fdts_compressed.rst | 6 +- doc/usage/fit/multi-with-fpga.rst | 6 +- doc/usage/fit/multi-with-loadables.rst | 8 +-- doc/usage/fit/multi.rst | 12 ++-- doc/usage/fit/sign-configs.rst | 6 +- doc/usage/fit/sign-images.rst | 4 +- doc/usage/fit/signature.rst | 22 +++---- doc/usage/fit/update3.rst | 6 +- doc/usage/fit/update_uboot.rst | 2 +- doc/usage/fit/x86-fit-boot.rst | 8 +-- 17 files changed, 109 insertions(+), 109 deletions(-) diff --git a/doc/chromium/files/chromebook_jerry.its b/doc/chromium/files/chromebook_jerry.its index 7505a20535b..02e5e1340f3 100644 --- a/doc/chromium/files/chromebook_jerry.its +++ b/doc/chromium/files/chromebook_jerry.its @@ -15,7 +15,7 @@ load = <0>; entry = <0>; hash-2 { - algo = "sha1"; + algo = "sha256"; }; }; @@ -26,7 +26,7 @@ arch = "arm"; compression = "none"; hash-1{ - algo = "sha1"; + algo = "sha256"; }; }; }; diff --git a/doc/chromium/files/nyan-big.its b/doc/chromium/files/nyan-big.its index bd412915e95..60bdffbb829 100644 --- a/doc/chromium/files/nyan-big.its +++ b/doc/chromium/files/nyan-big.its @@ -15,7 +15,7 @@ load = <0>; entry = <0>; hash-2 { - algo = "sha1"; + algo = "sha256"; }; }; @@ -26,7 +26,7 @@ arch = "arm"; compression = "none"; hash-1{ - algo = "sha1"; + algo = "sha256"; }; }; }; diff --git a/doc/usage/cmd/imxtract.rst b/doc/usage/cmd/imxtract.rst index eb64b1cefab..16be60b4aab 100644 --- a/doc/usage/cmd/imxtract.rst +++ b/doc/usage/cmd/imxtract.rst @@ -45,14 +45,14 @@ Examples With verify=no incorrect hashes, signatures, or check sums don't stop the extraction. But correct hashes are still indicated in the output -(here: md5, sha1). +(here: sha256, sha512). .. code-block:: console => setenv verify no => imxtract $loadaddr kernel-1 $kernel_addr_r ## Copying 'kernel-1' subimage from FIT image at 40200000 ... - md5+ sha1+ Loading part 0 ... OK + sha256+ sha512+ Loading part 0 ... OK => With verify=yes incorrect hashes, signatures, or check sums stop the extraction. @@ -62,7 +62,7 @@ With verify=yes incorrect hashes, signatures, or check sums stop the extraction. => setenv verify yes => imxtract $loadaddr kernel-1 $kernel_addr_r ## Copying 'kernel-1' subimage from FIT image at 40200000 ... - md5 error! + sha256 error! Bad hash value for 'hash-1' hash node in 'kernel-1' image node Bad Data Hash => diff --git a/doc/usage/fit/beaglebone_vboot.rst b/doc/usage/fit/beaglebone_vboot.rst index a102be187bd..cd6bb141910 100644 --- a/doc/usage/fit/beaglebone_vboot.rst +++ b/doc/usage/fit/beaglebone_vboot.rst @@ -145,7 +145,7 @@ Put this into a file in that directory called sign.its:: load = <0x80008000>; entry = <0x80008000>; hash-1 { - algo = "sha1"; + algo = "sha256"; }; }; fdt-1 { @@ -155,7 +155,7 @@ Put this into a file in that directory called sign.its:: arch = "arm"; compression = "none"; hash-1 { - algo = "sha1"; + algo = "sha256"; }; }; }; @@ -165,7 +165,7 @@ Put this into a file in that directory called sign.its:: kernel = "kernel"; fdt = "fdt-1"; signature-1 { - algo = "sha1,rsa2048"; + algo = "sha256,rsa2048"; key-name-hint = "dev"; sign-images = "fdt", "kernel"; }; @@ -227,8 +227,8 @@ You should see something like this:: OS: Linux Load Address: 0x80008000 Entry Point: 0x80008000 - Hash algo: sha1 - Hash value: c94364646427e10f423837e559898ef02c97b988 + Hash algo: sha256 + Hash value: 51b2adf9c1016ed46f424d85dcc6c34c46a20b9bee7227e06a6b6320ca5d35c1 Image 1 (fdt-1) Description: beaglebone-black Created: Sun Jun 1 12:50:30 2014 @@ -236,8 +236,8 @@ You should see something like this:: Compression: uncompressed Data Size: 31547 Bytes = 30.81 kB = 0.03 MB Architecture: ARM - Hash algo: sha1 - Hash value: cb09202f889d824f23b8e4404b781be5ad38a68d + Hash algo: sha256 + Hash value: 807d5842a04132261ba092373bd40c78991bc7ce173d1175cd976ec37858e7cd Default Configuration: 'conf-1' Configuration 0 (conf-1) Description: unavailable @@ -255,11 +255,11 @@ You can also run fit_check_sign to check it:: which results in:: - Verifying Hash Integrity ... sha1,rsa2048:dev+ + Verifying Hash Integrity ... sha256,rsa2048:dev+ ## Loading kernel from FIT Image at 7fc6ee469000 ... Using 'conf-1' configuration Verifying Hash Integrity ... - sha1,rsa2048:dev+ + sha256,rsa2048:dev+ OK Trying 'kernel' kernel subimage @@ -272,10 +272,10 @@ which results in:: OS: Linux Load Address: 0x80008000 Entry Point: 0x80008000 - Hash algo: sha1 - Hash value: c94364646427e10f423837e559898ef02c97b988 + Hash algo: sha256 + Hash value: 51b2adf9c1016ed46f424d85dcc6c34c46a20b9bee7227e06a6b6320ca5d35c1 Verifying Hash Integrity ... - sha1+ + sha256+ OK Unimplemented compression type 4 @@ -288,10 +288,10 @@ which results in:: Compression: uncompressed Data Size: 31547 Bytes = 30.81 kB = 0.03 MB Architecture: ARM - Hash algo: sha1 - Hash value: cb09202f889d824f23b8e4404b781be5ad38a68d + Hash algo: sha256 + Hash value: 807d5842a04132261ba092373bd40c78991bc7ce173d1175cd976ec37858e7cd Verifying Hash Integrity ... - sha1+ + sha256+ OK Loading Flat Device Tree ... OK @@ -303,14 +303,14 @@ which results in:: Signature check OK -At the top, you see "sha1,rsa2048:dev+". This means that it checked an RSA key -of size 2048 bits using SHA1 as the hash algorithm. The key name checked was +At the top, you see "sha256,rsa2048:dev+". This means that it checked an RSA key +of size 2048 bits using SHA256 as the hash algorithm. The key name checked was 'dev' and the '+' means that it verified. If it showed '-' that would be bad. Once the configuration is verified it is then possible to rely on the hashes in each image referenced by that configuration. So fit_check_sign goes on to load each of the images. We have a kernel and an FDT but no ramkdisk. In each -case fit_check_sign checks the hash and prints sha1+ meaning that the SHA1 +case fit_check_sign checks the hash and prints sha256+ meaning that the SHA256 hash verified. This means that none of the images has been tampered with. There is a test in test/vboot which uses U-Boot's sandbox build to verify that @@ -328,11 +328,11 @@ This tells us that the kernel starts at byte offset 168 (decimal) in image.fit and extends for about 7MB. Try changing a byte at 0x2000 (say) and run fit_check_sign again. You should see something like:: - Verifying Hash Integrity ... sha1,rsa2048:dev+ + Verifying Hash Integrity ... sha256,rsa2048:dev+ ## Loading kernel from FIT Image at 7f5a39571000 ... Using 'conf-1' configuration Verifying Hash Integrity ... - sha1,rsa2048:dev+ + sha256,rsa2048:dev+ OK Trying 'kernel' kernel subimage @@ -345,10 +345,10 @@ fit_check_sign again. You should see something like:: OS: Linux Load Address: 0x80008000 Entry Point: 0x80008000 - Hash algo: sha1 - Hash value: c94364646427e10f423837e559898ef02c97b988 + Hash algo: sha256 + Hash value: 51b2adf9c1016ed46f424d85dcc6c34c46a20b9bee7227e06a6b6320ca5d35c1 Verifying Hash Integrity ... - sha1 error + sha256 error Bad hash value for 'hash-1' hash node in 'kernel' image node Bad Data Hash @@ -361,10 +361,10 @@ fit_check_sign again. You should see something like:: Compression: uncompressed Data Size: 31547 Bytes = 30.81 kB = 0.03 MB Architecture: ARM - Hash algo: sha1 - Hash value: cb09202f889d824f23b8e4404b781be5ad38a68d + Hash algo: sha256 + Hash value: 807d5842a04132261ba092373bd40c78991bc7ce173d1175cd976ec37858e7cd Verifying Hash Integrity ... - sha1+ + sha256+ OK Loading Flat Device Tree ... OK @@ -419,13 +419,13 @@ need to change the hash to match. Let's simulate that by changing a byte of the hash:: fdtget -tx image.fit /images/kernel/hash-1 value - c9436464 6427e10f 423837e5 59898ef0 2c97b988 - fdtput -tx image.fit /images/kernel/hash-1 value c9436464 6427e10f 423837e5 59898ef0 2c97b981 + 51b2adf9 c1016ed4 6f424d85 dcc6c34c 46a20b9b ee7227e0 6a6b6320 ca5d35c1 + fdtput -tx image.fit /images/kernel/hash-1 value 51b2adf9 c1016ed4 6f424d85 dcc6c34c 46a20b9b ee7227e0 6a6b6320 ca5d35c8 Now check it again:: $UOUT/tools/fit_check_sign -f image.fit -k am335x-boneblack-pubkey.dtb - Verifying Hash Integrity ... sha1,rsa2048:devrsa_verify_with_keynode: RSA failed to verify: -13 + Verifying Hash Integrity ... sha256,rsa2048:devrsa_verify_with_keynode: RSA failed to verify: -13 rsa_verify_with_keynode: RSA failed to verify: -13 - Failed to verify required signature 'key-dev' @@ -446,7 +446,7 @@ running the mkimage link again. Then:: fdtput -p image.fit /configurations/conf-1/signature-1 value fred $UOUT/tools/fit_check_sign -f image.fit -k am335x-boneblack-pubkey.dtb Verifying Hash Integrity ... - - sha1,rsa2048:devrsa_verify_with_keynode: RSA failed to verify: -13 + sha256,rsa2048:devrsa_verify_with_keynode: RSA failed to verify: -13 rsa_verify_with_keynode: RSA failed to verify: -13 - Failed to verify required signature 'key-dev' @@ -528,7 +528,7 @@ You should then see something like this:: U-Boot# bootm 82000000 ## Loading kernel from FIT Image at 82000000 ... Using 'conf-1' configuration - Verifying Hash Integrity ... sha1,rsa2048:dev+ OK + Verifying Hash Integrity ... sha256,rsa2048:dev+ OK Trying 'kernel' kernel subimage Description: unavailable Created: 2014-06-01 19:32:54 UTC @@ -540,9 +540,9 @@ You should then see something like this:: OS: Linux Load Address: 0x80008000 Entry Point: 0x80008000 - Hash algo: sha1 - Hash value: c94364646427e10f423837e559898ef02c97b988 - Verifying Hash Integrity ... sha1+ OK + Hash algo: sha256 + Hash value: 51b2adf9c1016ed46f424d85dcc6c34c46a20b9bee7227e06a6b6320ca5d35c1 + Verifying Hash Integrity ... sha256+ OK ## Loading fdt from FIT Image at 82000000 ... Using 'conf-1' configuration Trying 'fdt-1' fdt subimage @@ -553,9 +553,9 @@ You should then see something like this:: Data Start: 0x8276e2ec Data Size: 31547 Bytes = 30.8 KiB Architecture: ARM - Hash algo: sha1 - Hash value: cb09202f889d824f23b8e4404b781be5ad38a68d - Verifying Hash Integrity ... sha1+ OK + Hash algo: sha256 + Hash value: 807d5842a04132261ba092373bd40c78991bc7ce173d1175cd976ec37858e7cd + Verifying Hash Integrity ... sha256+ OK Booting using the fdt blob at 0x8276e2ec Uncompressing Kernel Image ... OK Loading Device Tree to 8fff5000, end 8ffffb3a ... OK diff --git a/doc/usage/fit/howto.rst b/doc/usage/fit/howto.rst index def12a70f7b..b5097d4460b 100644 --- a/doc/usage/fit/howto.rst +++ b/doc/usage/fit/howto.rst @@ -8,7 +8,7 @@ Overview The new uImage format allows more flexibility in handling images of various types (kernel, ramdisk, etc.), it also enhances integrity protection of images -with sha1 and md5 checksums. +with cryptographic checksums. Two auxiliary tools are needed on the development host system in order to create an uImage in the new format: mkimage and dtc, although only one @@ -99,7 +99,7 @@ started by ATF where SPL is loading U-Boot (as loadables) and ATF (as firmware). load = <0x8 0x8000000>; entry = <0x8 0x8000000>; hash { - algo = "md5"; + algo = "sha256"; }; }; atf { @@ -112,7 +112,7 @@ started by ATF where SPL is loading U-Boot (as loadables) and ATF (as firmware). load = <0xfffea000>; entry = <0xfffea000>; hash { - algo = "md5"; + algo = "sha256"; }; }; fdt_1 { @@ -123,7 +123,7 @@ started by ATF where SPL is loading U-Boot (as loadables) and ATF (as firmware). compression = "none"; load = <0x100000>; hash { - algo = "md5"; + algo = "sha256"; }; }; }; @@ -190,8 +190,8 @@ its contents: Entry Point: 0x00000000 Hash algo: crc32 Hash value: 2ae2bb40 - Hash algo: sha1 - Hash value: 3c200f34e2c226ddc789240cca0c59fc54a67cf4 + Hash algo: sha256 + Hash value: c22f6bb5a3f96942507a37e7d6a9333ebdc7da57971bc4c082113fe082fdc40f Default Configuration: 'config-1' Configuration 0 (config-1) Description: Boot Linux kernel @@ -236,8 +236,8 @@ specific to the new image format). Entry Point: 0x00000000 Hash algo: crc32 Hash value: 2ae2bb40 - Hash algo: sha1 - Hash value: 3c200f34e2c226ddc789240cca0c59fc54a67cf4 + Hash algo: sha256 + Hash value: c22f6bb5a3f96942507a37e7d6a9333ebdc7da57971bc4c082113fe082fdc40f Default Configuration: 'config-1' Configuration 0 (config-1) Description: Boot Linux kernel @@ -258,8 +258,8 @@ specific to the new image format). Entry Point: 0x00000000 Hash algo: crc32 Hash value: 2ae2bb40 - Hash algo: sha1 - Hash value: 3c200f34e2c226ddc789240cca0c59fc54a67cf4 + Hash algo: sha256 + Hash value: c22f6bb5a3f96942507a37e7d6a9333ebdc7da57971bc4c082113fe082fdc40f Verifying Hash Integrity ... crc32+ sha1+ OK Uncompressing Kernel Image ... OK Memory BAT mapping: BAT2=256Mb, BAT3=0Mb, residual: 0Mb @@ -302,8 +302,8 @@ modified to take the files from some other location if needed): Entry Point: 0x00000000 Hash algo: crc32 Hash value: 2c0cc807 - Hash algo: sha1 - Hash value: 264b59935470e42c418744f83935d44cdf59a3bb + Hash algo: sha256 + Hash value: a3e9e18b793873827d27c97edfbca67c404a1972d9f36cf48e73ff85d69a422c Image 1 (fdt-1) Description: Flattened Device Tree blob Type: Flat Device Tree @@ -312,8 +312,8 @@ modified to take the files from some other location if needed): Architecture: PowerPC Hash algo: crc32 Hash value: 0d655d71 - Hash algo: sha1 - Hash value: 25ab4e15cd4b8a5144610394560d9c318ce52def + Hash algo: sha256 + Hash value: e9b9a40c5e2e12213ac819e7ccad7271ef43eb5edf9b421f0fa0b4b51bfdb214 Default Configuration: 'conf-1' Configuration 0 (conf-1) Description: Boot Linux kernel with FDT blob @@ -353,8 +353,8 @@ inspected and booted: Entry Point: 0x00000000 Hash algo: crc32 Hash value: 2c0cc807 - Hash algo: sha1 - Hash value: 264b59935470e42c418744f83935d44cdf59a3bb + Hash algo: sha256 + Hash value: a3e9e18b793873827d27c97edfbca67c404a1972d9f36cf48e73ff85d69a422c Image 1 (fdt-1) Description: Flattened Device Tree blob Type: Flat Device Tree @@ -364,8 +364,8 @@ inspected and booted: Architecture: PowerPC Hash algo: crc32 Hash value: 0d655d71 - Hash algo: sha1 - Hash value: 25ab4e15cd4b8a5144610394560d9c318ce52def + Hash algo: sha256 + Hash value: e9b9a40c5e2e12213ac819e7ccad7271ef43eb5edf9b421f0fa0b4b51bfdb214 Default Configuration: 'conf-1' Configuration 0 (conf-1) Description: Boot Linux kernel with FDT blob @@ -387,7 +387,7 @@ inspected and booted: Hash algo: crc32 Hash value: 2c0cc807 Hash algo: sha1 - Hash value: 264b59935470e42c418744f83935d44cdf59a3bb + Hash value: a3e9e18b793873827d27c97edfbca67c404a1972d9f36cf48e73ff85d69a422c Verifying Hash Integrity ... crc32+ sha1+ OK Uncompressing Kernel Image ... OK ## Flattened Device Tree from FIT Image at 00900000 @@ -402,7 +402,7 @@ inspected and booted: Hash algo: crc32 Hash value: 0d655d71 Hash algo: sha1 - Hash value: 25ab4e15cd4b8a5144610394560d9c318ce52def + Hash value: e9b9a40c5e2e12213ac819e7ccad7271ef43eb5edf9b421f0fa0b4b51bfdb214 Verifying Hash Integrity ... crc32+ sha1+ OK Booting using the fdt blob at 0xa0abdc Loading Device Tree to 007fc000, end 007fffff ... OK diff --git a/doc/usage/fit/kernel.rst b/doc/usage/fit/kernel.rst index 012a81efead..e56017985b2 100644 --- a/doc/usage/fit/kernel.rst +++ b/doc/usage/fit/kernel.rst @@ -25,7 +25,7 @@ Single kernel algo = "crc32"; }; hash-2 { - algo = "sha1"; + algo = "sha256"; }; }; }; @@ -59,7 +59,7 @@ For x86 a setup node is also required: see x86-fit-boot:: load = <0x01000000>; entry = <0x00000000>; hash-2 { - algo = "sha1"; + algo = "sha256"; }; }; @@ -73,7 +73,7 @@ For x86 a setup node is also required: see x86-fit-boot:: load = <0x00090000>; entry = <0x00090000>; hash-2 { - algo = "sha1"; + algo = "sha256"; }; }; }; diff --git a/doc/usage/fit/kernel_fdt.rst b/doc/usage/fit/kernel_fdt.rst index 8eee13af780..9cc26fb7831 100644 --- a/doc/usage/fit/kernel_fdt.rst +++ b/doc/usage/fit/kernel_fdt.rst @@ -25,7 +25,7 @@ Single kernel and FDT blob algo = "crc32"; }; hash-2 { - algo = "sha1"; + algo = "sha256"; }; }; fdt-1 { @@ -38,7 +38,7 @@ Single kernel and FDT blob algo = "crc32"; }; hash-2 { - algo = "sha1"; + algo = "sha256"; }; }; }; diff --git a/doc/usage/fit/kernel_fdts_compressed.rst b/doc/usage/fit/kernel_fdts_compressed.rst index 0b169c7c27c..b57871da58b 100644 --- a/doc/usage/fit/kernel_fdts_compressed.rst +++ b/doc/usage/fit/kernel_fdts_compressed.rst @@ -28,7 +28,7 @@ string to match directly. algo = "crc32"; }; hash-2 { - algo = "sha1"; + algo = "sha256"; }; }; fdt@1 { @@ -41,7 +41,7 @@ string to match directly. algo = "crc32"; }; hash-2 { - algo = "sha1"; + algo = "sha256"; }; }; fdt@2 { @@ -54,7 +54,7 @@ string to match directly. algo = "crc32"; }; hash-2 { - algo = "sha1"; + algo = "sha256"; }; }; }; diff --git a/doc/usage/fit/multi-with-fpga.rst b/doc/usage/fit/multi-with-fpga.rst index 28d7d5d2626..4c7f1bebd5a 100644 --- a/doc/usage/fit/multi-with-fpga.rst +++ b/doc/usage/fit/multi-with-fpga.rst @@ -20,7 +20,7 @@ This example makes use of the 'loadables' field:: compression = "none"; load = <0x10000000>; hash-1 { - algo = "md5"; + algo = "sha256"; }; }; @@ -33,7 +33,7 @@ This example makes use of the 'loadables' field:: load = <0x30000000>; compatible = "u-boot,fpga-legacy" hash-1 { - algo = "md5"; + algo = "sha256"; }; }; @@ -47,7 +47,7 @@ This example makes use of the 'loadables' field:: load = <0x8000>; entry = <0x8000>; hash-1 { - algo = "md5"; + algo = "sha256"; }; }; }; diff --git a/doc/usage/fit/multi-with-loadables.rst b/doc/usage/fit/multi-with-loadables.rst index a0241df96ca..7849cb544f1 100644 --- a/doc/usage/fit/multi-with-loadables.rst +++ b/doc/usage/fit/multi-with-loadables.rst @@ -22,7 +22,7 @@ This example makes use of the 'loadables' field:: load = <0xa0000000>; entry = <0xa0000000>; hash-1 { - algo = "md5"; + algo = "sha256"; }; }; @@ -34,7 +34,7 @@ This example makes use of the 'loadables' field:: compression = "none"; load = <0xb0000000>; hash-1 { - algo = "md5"; + algo = "sha256"; }; }; @@ -46,7 +46,7 @@ This example makes use of the 'loadables' field:: compression = "none"; load = <0xb0400000>; hash-1 { - algo = "md5"; + algo = "sha256"; }; }; @@ -60,7 +60,7 @@ This example makes use of the 'loadables' field:: load = <0xa0000000>; entry = <0xa0000000>; hash-1 { - algo = "md5"; + algo = "sha256"; }; }; }; diff --git a/doc/usage/fit/multi.rst b/doc/usage/fit/multi.rst index 2e6ae58c409..e68752b2ad0 100644 --- a/doc/usage/fit/multi.rst +++ b/doc/usage/fit/multi.rst @@ -22,10 +22,10 @@ Multiple kernels, ramdisks and FDT blobs load = <00000000>; entry = <00000000>; hash-1 { - algo = "md5"; + algo = "sha256"; }; hash-2 { - algo = "sha1"; + algo = "sha512"; }; }; @@ -39,7 +39,7 @@ Multiple kernels, ramdisks and FDT blobs load = <00000000>; entry = <00000000>; hash-1 { - algo = "sha1"; + algo = "sha256"; }; }; @@ -53,7 +53,7 @@ Multiple kernels, ramdisks and FDT blobs load = <00000000>; entry = <00000000>; hash-1 { - algo = "md5"; + algo = "sha256"; }; }; @@ -67,7 +67,7 @@ Multiple kernels, ramdisks and FDT blobs load = <00000000>; entry = <00000000>; hash-1 { - algo = "sha1"; + algo = "sha256"; }; }; @@ -104,7 +104,7 @@ Multiple kernels, ramdisks and FDT blobs compression = "none"; load = <00700000>; hash-1 { - algo = "sha1"; + algo = "sha256"; }; }; diff --git a/doc/usage/fit/sign-configs.rst b/doc/usage/fit/sign-configs.rst index 6a3df8f2c5b..6d98d44430c 100644 --- a/doc/usage/fit/sign-configs.rst +++ b/doc/usage/fit/sign-configs.rst @@ -22,7 +22,7 @@ Signed configurations entry = <0x8>; kernel-version = <1>; hash-1 { - algo = "sha1"; + algo = "sha256"; }; }; fdt-1 { @@ -33,7 +33,7 @@ Signed configurations compression = "none"; fdt-version = <1>; hash-1 { - algo = "sha1"; + algo = "sha256"; }; }; }; @@ -43,7 +43,7 @@ Signed configurations kernel = "kernel"; fdt = "fdt-1"; signature { - algo = "sha1,rsa2048"; + algo = "sha256,rsa2048"; key-name-hint = "dev"; sign-images = "fdt", "kernel"; }; diff --git a/doc/usage/fit/sign-images.rst b/doc/usage/fit/sign-images.rst index 7d54d702c97..ca7d10fab83 100644 --- a/doc/usage/fit/sign-images.rst +++ b/doc/usage/fit/sign-images.rst @@ -22,7 +22,7 @@ Signed Images entry = <0x8>; kernel-version = <1>; signature { - algo = "sha1,rsa2048"; + algo = "sha256,rsa2048"; key-name-hint = "dev"; }; }; @@ -34,7 +34,7 @@ Signed Images compression = "none"; fdt-version = <1>; signature { - algo = "sha1,rsa2048"; + algo = "sha256,rsa2048"; key-name-hint = "dev"; }; }; diff --git a/doc/usage/fit/signature.rst b/doc/usage/fit/signature.rst index 0804bffd1ed..39edba14630 100644 --- a/doc/usage/fit/signature.rst +++ b/doc/usage/fit/signature.rst @@ -93,7 +93,7 @@ Public keys should be stored as sub-nodes in a /signature node. Required properties are: algo - Algorithm name (e.g. "sha1,rsa2048" or "sha256,ecdsa256") + Algorithm name (e.g. "sha256,rsa2048" or "sha512,ecdsa256") Optional properties are: @@ -219,28 +219,28 @@ As an example, consider this FIT:: kernel-1 { data = <data for kernel1> signature-1 { - algo = "sha1,rsa2048"; + algo = "sha256,rsa2048"; value = <...kernel signature 1...> }; }; kernel-2 { data = <data for kernel2> signature-1 { - algo = "sha1,rsa2048"; + algo = "sha256,rsa2048"; value = <...kernel signature 2...> }; }; fdt-1 { data = <data for fdt1>; signature-1 { - algo = "sha1,rsa2048"; + algo = "sha256,rsa2048"; value = <...fdt signature 1...> }; }; fdt-2 { data = <data for fdt2>; signature-1 { - algo = "sha1,rsa2048"; + algo = "sha256,rsa2048"; value = <...fdt signature 2...> }; }; @@ -291,28 +291,28 @@ So the above example is adjusted to look like this:: kernel-1 { data = <data for kernel1> hash-1 { - algo = "sha1"; + algo = "sha256"; value = <...kernel hash 1...> }; }; kernel-2 { data = <data for kernel2> hash-1 { - algo = "sha1"; + algo = "sha256"; value = <...kernel hash 2...> }; }; fdt-1 { data = <data for fdt1>; hash-1 { - algo = "sha1"; + algo = "sha256"; value = <...fdt hash 1...> }; }; fdt-2 { data = <data for fdt2>; hash-1 { - algo = "sha1"; + algo = "sha256"; value = <...fdt hash 2...> }; }; @@ -323,7 +323,7 @@ So the above example is adjusted to look like this:: kernel = "kernel-1"; fdt = "fdt-1"; signature-1 { - algo = "sha1,rsa2048"; + algo = "sha256,rsa2048"; value = <...conf 1 signature...>; }; }; @@ -331,7 +331,7 @@ So the above example is adjusted to look like this:: kernel = "kernel-2"; fdt = "fdt-2"; signature-1 { - algo = "sha1,rsa2048"; + algo = "sha256,rsa2048"; value = <...conf 1 signature...>; }; }; diff --git a/doc/usage/fit/update3.rst b/doc/usage/fit/update3.rst index 4ff3950c01e..24235801470 100644 --- a/doc/usage/fit/update3.rst +++ b/doc/usage/fit/update3.rst @@ -19,7 +19,7 @@ Automatic software update: multiple files type = "firmware"; load = <FF700000>; hash-1 { - algo = "sha1"; + algo = "sha256"; }; }; update-2 { @@ -29,7 +29,7 @@ Automatic software update: multiple files type = "firmware"; load = <FF8E0000>; hash-1 { - algo = "sha1"; + algo = "sha256"; }; }; @@ -40,7 +40,7 @@ Automatic software update: multiple files type = "firmware"; load = <FFAC0000>; hash-1 { - algo = "sha1"; + algo = "sha256"; }; }; }; diff --git a/doc/usage/fit/update_uboot.rst b/doc/usage/fit/update_uboot.rst index a9288ee6367..811d008d13d 100644 --- a/doc/usage/fit/update_uboot.rst +++ b/doc/usage/fit/update_uboot.rst @@ -21,7 +21,7 @@ Make sure the flashing addresses ('load' prop) is correct for your board! type = "firmware"; load = <0xFFFC0000>; hash-1 { - algo = "sha1"; + algo = "sha256"; }; }; }; diff --git a/doc/usage/fit/x86-fit-boot.rst b/doc/usage/fit/x86-fit-boot.rst index 93b73bb9019..9e3e32204d5 100644 --- a/doc/usage/fit/x86-fit-boot.rst +++ b/doc/usage/fit/x86-fit-boot.rst @@ -207,16 +207,16 @@ You can take a look at the resulting fit file if you like:: OS: Linux Load Address: 0x01000000 Entry Point: 0x00000000 - Hash algo: sha1 - Hash value: 446b5163ebfe0fb6ee20cbb7a8501b263cd92392 + Hash algo: sha256 + Hash value: 4bbf49981ade163ed089f8525236fedfe44508e9b02a21a48294a96a1518107b Image 1 (setup) Description: Linux setup.bin Created: Tue Oct 7 10:57:24 2014 Type: x86 setup.bin Compression: uncompressed Data Size: 12912 Bytes = 12.61 kB = 0.01 MB - Hash algo: sha1 - Hash value: a1f2099cf47ff9816236cd534c77af86e713faad + Hash algo: sha256 + Hash value: 6aa50c2e0392cb119cdf0971dce8339f100608ed3757c8200b0e39e889e432d2 Default Configuration: 'config-1' Configuration 0 (config-1) Description: Boot Linux kernel -- 2.37.1

4 5

[PATCH v3 0/6] Support display on stm32f469-disco board
by Dario Binacchi 15 Dec '23

15 Dec '23

The series adds support for the Orise Tech OTM8009A display on the stm32f469-disco board. Substantial differences in the drivers for clock management, LTDC and DSI compared to Linux, made it necessary to modify the device tree. These changes were made in stm32f469-disco-uboot.dtsi to avoid altering the Linux device tree. It is therefore desirable, as soon as possible, to add these drivers the functionalities so that they do not require device tree properties that deviate from those present in the Linux version. Changes in v3: - Add Patrice Chotard's Reviewed-by tag. - Remove RFC tag - Split "[4/5] ARM: dts: stm32: support display on stm32f469-disco board" patch in 2 parts: - DTS ([4/6] ARM: dts: stm32: support MIPI DSI on stm32f469-disco board) - config and LTDC driver update ([5/6] board: stm32f469-disco: add support to display) Changes in v2: - Add Patrice Chotard's Reviewed-by tag to patches 1, 2 and 3 of the series. - Fix frame buffer allocation for stm32f469 discovery board. Dario Binacchi (6): ARM: dts: stm32f469-disco: sync with Linux 6.5 ARM: dts: stm32: make the LTDC clock usable by the clock driver ARM: dts: stm32: make the DSI clock usable by the clock driver ARM: dts: stm32: support MIPI DSI on stm32f469-disco board board: stm32f469-disco: add support to display board: stm32f469-disco: add splash screen with stmicroelectronics logo arch/arm/dts/stm32f469-disco-u-boot.dtsi | 13 ++++++++++ arch/arm/dts/stm32f469-disco.dts | 4 +-- configs/stm32f469-discovery_defconfig | 16 ++++++++++++ drivers/video/stm32/stm32_ltdc.c | 31 +++++++++++++++++++++++ include/configs/stm32f469-discovery.h | 2 ++ tools/logos/stm32f469-discovery.bmp | Bin 0 -> 18532 bytes 6 files changed, 64 insertions(+), 2 deletions(-) create mode 100644 tools/logos/stm32f469-discovery.bmp -- 2.43.0

2 14

Pull request: Please pull u-boot-imx-20231214
by Fabio Estevam 15 Dec '23

15 Dec '23

Hi Tom, Please pull these fixes from u-boot-imx, thanks. The following changes since commit 27089f1e4d11fd7e0619097b59258d0428cde2ac: Merge branch '2023-12-13-assorted-minor-fixes' (2023-12-13 09:57:28 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git tags/u-boot-imx-20231214 for you to fetch changes up to 4f7122ca1580602399afc30f94f4b37f79e4d662: imx8mp-venice: update DRAM config for 2000MHz (2023-12-14 15:34:12 -0300) u-boot-imx-20231214 ------------------- CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/18937 - Fix for i.MX8M Plus eDM SBC DDR timings with inlinc ECC - Switch to FPWM mode on Data Modul i.MX8M Plus eDM SBC so that DRAM EDAC detects more correctable errors - Fix for imx8mp-venice board DDR initialization ---------------------------------------------------------------- Marek Vasut (7): arm64: imx8mp: Inhibit DTC warning on DH i.MX8MP DHCOM rev.100 DTO ddr: imx: Handle 3734 in addition to 3733 and 3732 MTps rates ddr: imx: Add 3600 MTps rate support ARM: imx: Enable CAAM on Data Modul i.MX8M Mini/Plus eDM SBC ARM: imx: Enable CAAM on DH i.MX8M Plus DHCOM ARM: imx: Force DRAM regulators into FPWM mode on Data Modul i.MX8M Plus eDM SBC ARM: imx: Update DRAM timings with inline ECC on Data Modul i.MX8M Plus eDM SBC Tim Harvey (3): board: gateworks: venice: remove extra file imx8mp-venice: fix DRAM bus configuration imx8mp-venice: update DRAM config for 2000MHz arch/arm/dts/Makefile | 2 + arch/arm/mach-imx/imx8m/clock_imx8mm.c | 1 + board/data_modul/common/common.c | 18 +- .../imx8mp_edm_sbc/lpddr4_timing_4G_32.c | 175 +- board/data_modul/imx8mp_edm_sbc/spl.c | 5 + .../gateworks/venice/lpddr4_timing_imx8mm_512mb.c | 1849 -------------------- board/gateworks/venice/lpddr4_timing_imx8mp.c | 327 ++-- configs/imx8mm_data_modul_edm_sbc_defconfig | 1 + configs/imx8mp_data_modul_edm_sbc_defconfig | 2 + configs/imx8mp_dhcom_pdk2_defconfig | 1 + configs/imx8mp_dhcom_pdk3_defconfig | 1 + drivers/ddr/imx/phy/ddrphy_utils.c | 5 + 12 files changed, 301 insertions(+), 2086 deletions(-) delete mode 100644 board/gateworks/venice/lpddr4_timing_imx8mm_512mb.c

2 1

[PATCH 1/1] Makefile: pass -ansi option to cmd_gen_envp
by Sébastien Szymanski 15 Dec '23

15 Dec '23

Without the '-ansi' option, the 'linux' string in env. files is replaced with the string '1 '. For example, in the board/armadeus/opos6uldev/opos6uldev.env file, kernelimg=opos6ul-linux.bin becomes kernelimg=opos6ul-1 .bin in the include/generated/env.in. That's because 'linux' is a System-specific Predefined Macros. [1] Pass the '-ansi' option as suggested by the GCC documentation. [1] Fix the two .env files using C++ comment style for their SPDX licence. [1] https://gcc.gnu.org/onlinedocs/gcc-13.2.0/cpp/System-specific-Predefined-Ma… Signed-off-by: Sébastien Szymanski <sebastien.szymanski(a)armadeus.com> --- Makefile | 3 ++- board/siemens/iot2050/iot2050.env | 2 +- board/storopack/smegw01/smegw01.env | 2 +- 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 750bbdb1b713..5fc7a20df7f0 100644 --- a/Makefile +++ b/Makefile @@ -1803,7 +1803,8 @@ ENV_FILE := $(if $(ENV_SOURCE_FILE),$(ENV_FILE_CFG),$(wildcard $(ENV_FILE_BOARD) quiet_cmd_gen_envp = ENVP $@ cmd_gen_envp = \ if [ -s "$(ENV_FILE)" ]; then \ - $(CPP) -P $(CFLAGS) -x assembler-with-cpp -D__ASSEMBLY__ \ + $(CPP) -P $(CFLAGS) -x assembler-with-cpp -ansi \ + -D__ASSEMBLY__ \ -D__UBOOT_CONFIG__ \ -I . -I include -I $(srctree)/include \ -include linux/kconfig.h -include include/config.h \ diff --git a/board/siemens/iot2050/iot2050.env b/board/siemens/iot2050/iot2050.env index 8bbd7abe98f0..a3bdbf4f6998 100644 --- a/board/siemens/iot2050/iot2050.env +++ b/board/siemens/iot2050/iot2050.env @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: GPL-2.0+ +/* SPDX-License-Identifier: GPL-2.0+ */ /* * Copyright (c) Siemens AG, 2023 * diff --git a/board/storopack/smegw01/smegw01.env b/board/storopack/smegw01/smegw01.env index 93de8669109d..6807ada71887 100644 --- a/board/storopack/smegw01/smegw01.env +++ b/board/storopack/smegw01/smegw01.env @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: GPL-2.0+ +/* SPDX-License-Identifier: GPL-2.0+ */ #ifdef CONFIG_SYS_BOOT_LOCKED #define SETUP_BOOT_MENU setup_boot_menu=setenv bootmenu_0 eMMC=run bootcmd #else -- 2.41.0

2 3

[PATCH 1/2] board: st: common: Fix board_get_alt_info_mtd()
by Patrice Chotard 15 Dec '23

15 Dec '23

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: 31325e1b8b9c ("stm32mp1: dynamically build DFU_ALT_INFO") Signed-off-by: Patrice Chotard <patrice.chotard(a)foss.st.com> --- board/st/common/stm32mp_dfu.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/board/st/common/stm32mp_dfu.c b/board/st/common/stm32mp_dfu.c index a8eb8d5cae2..ded3bf81961 100644 --- a/board/st/common/stm32mp_dfu.c +++ b/board/st/common/stm32mp_dfu.c @@ -73,7 +73,6 @@ static void board_get_alt_info_mmc(struct udevice *dev, char *buf) static void board_get_alt_info_mtd(struct mtd_info *mtd, char *buf) { struct mtd_info *part; - bool first = true; const char *name; int len, partnum = 0; @@ -86,17 +85,13 @@ static void board_get_alt_info_mtd(struct mtd_info *mtd, char *buf) "mtd %s=", name); len += snprintf(buf + len, DFU_ALT_BUF_LEN - len, - "%s raw 0x0 0x%llx ", + "%s raw 0x0 0x%llx", name, mtd->size); list_for_each_entry(part, &mtd->partitions, node) { partnum++; - if (!first) - len += snprintf(buf + len, DFU_ALT_BUF_LEN - len, ";"); - first = false; - len += snprintf(buf + len, DFU_ALT_BUF_LEN - len, - "%s_%s part %d", + ";%s_%s part %d", name, part->name, partnum); } } -- 2.25.1

3 5