SPL FIT configuration signature verification
Hi there, Is it possible to make SPL U-Boot to verify signature located in configuration section of FIT image, and do not continue in case the signature is missing or doesn't match? Asking because I couldn't find any configuration option for that, and I have FIT image with signature but SPL U-boot doesn't check it at all, it only checks signatures for images if present. Thanks Cheers, Andy
Ways to copy FIT image from the flash to RAM
Hi there, What are the ways of copying whole FIT image form NOR flash to RAM by specifying flash offset without any extra bytes. I've seen quite a lot of times when kernel image size has a fixed value (as an uboot environment variable), which is greater than the actual kernel size. Problem with that that we copy from flash whatever is after kernel which is not required, and there is a potential problem when kernel gets bigger at some point than the fixed size specified in the variable mentioned above. As FIT file has all required info about size, is there a command to copy it to RAM from flash? Thank you Cheers, Andy
U-Boot FIT Signature Verification
Hi there, Does U-boot take into account certificate expiration date when verifying signed images in FIT? In other words, is date stored along with the public key in DTB file? Cheers, Andy
RE: SPL FIT configuration signature verification
Hi Reuben,
Thanks for your reply.
So, in your 'its' file for second stage u-boot, do you define signature in
images section as follows:
images {
uboot {
description = "U-Boot Secondary";
signature {
};
};
configurations {
};
};
or in configuration section (signed configuration feature), as follows?:
images {
uboot {
description = "U-Boot Secondary";
};
config-1 {
description = "";
loadables = "uboot";
signature {
algo = "";
key-name-hint = "";
sign-images = "loadables";
};
};
When I define signatures in images section, SPL U-Boot checks signatures of the
second stage u-boot as expected, on the other hand, when configuration is
signed it doesn't check it.
Microsoft added their own patch a couple of years ago to fix this
(https://github.com/neilsh-msft/u-boot.ms-iot/commit/6ea7fab742eadddf4982695f3cbafeda079e4134),
but it is not
in the mainline. I am wondering if this has been fixed in the mainline since
then, or I need to patch u-boot similar way Microsoft did?
Cheers,
Andy
On Mon, 14 Sep 2020 01:01:46 +0300 Reuben Dowle
wrote
>
> Yes, it is possible to do this. The SPL will check its own DTB to check
> which signatures are required.
>
> When the FIT that the SPL will load is created with mkimage, you also pass
> the SPL's dtb file, which will be patched to include the required signatures.
>
> I am not sure if the config system has ability to specify this. My build
> process separates the signing from the normal uboot build (so that I can
> keep the private keys more secure), so I am manually calling mkimage. The
> command I am using to generate my second stage signed u-boot FIT file which
> is loaded by SPL:
>
> mkimage -f uboot.its -K u-boot-spl.dtb -k keys -r u-boot.fit
>
> The updated u-boot-spl.dtb needs to be available for the SPL to load at
> startup - often by appending this dtb to the end of the SPL binary. In my
> case I do this:
> cat u-boot-spl-nodtb.bin u-boot-spl-pad.bin u-boot-spl.dtb > u-boot-spl.bin
>
>
> Reuben Dowle
> Software Architect
> Phone:
>
> Fax:
> E-Mail:
> Website:
> +64 4 499 6000
>
> +64 4 473 4447
> reuben.do...@4rf.com
> Https://www.4rf.com
>
>
>
>
>
>
> -Original Message-
> From: U-Boot On Behalf Of Andrii Voloshyn
> Sent: Saturday, 12 September 2020 12:18 am
> To: u-boot
> Subject: SPL FIT configuration signature verification
>
> Hi there,
>
> Is it possible to make SPL U-Boot to verify signature located in
> configuration section of FIT image, and do not continue in case the
> signature is missing or doesn't match?
> Asking because I couldn't find any configuration option for that, and I
> have FIT image with signature but SPL U-boot doesn't check it at all, it
> only checks signatures for images if present.
>
> Thanks
>
> Cheers,
> Andy
>
>
> The information in this email communication (inclusive of attachments) is
> confidential to 4RF Limited and the intended recipient(s). If you are not
> the intended recipient(s), please note that any use, disclosure,
> distribution or copying of this information or any part thereof is strictly
> prohibited and that the author accepts no liability for the consequences of
> any action taken on the basis of the information provided. If you have
> received this email in error, please notify the sender immediately by return
> email and then delete all instances of this email from your system. 4RF
> Limited will not accept responsibility for any consequences associated with
> the use of this email (including, but not limited to, damages sustained as a
> result of any viruses and/or any action or lack of action taken in reliance
> on it).
reset command doesn't work on MT7628 (CPU: MediaTek MT7628A ver:1 eco:2)
Hi there, There is one issue, I experience with (U-Boot 2020.07) on MT7628DAN, "reset" command issued in hush prompt causes board to hang, until I do a power cycle. On the other hand there is no such issue on mt7688 board. What's interesting, is that "reboot" issued in Linux shell makes board reboot as expected on mt7628 board. It seems like some sort of configuration issue, but I couldn't find anything specific in the datasheet. Maybe you have some idea what could cause it? One more thing, when running the following version of bootloader (https://github.com/gnubee-git/GnuBee-MT76x8-uboot) "reset" command works as expected. Thank you for your help Cheers, Andrew
Re: reset command doesn't work on MT7628 (CPU: MediaTek MT7628A ver:1 eco:2)
Hi Stefan, > Hi Andrew, > > (added Weijie to Cc) > > On 12.08.20 09:18, Andrii Voloshyn wrote: > >Hi there, > > > >There is one issue, I experience with (U-Boot 2020.07) on MT7628DAN, > > "reset" command issued in hush prompt > >causes board to hang, until I do a power cycle. On the other hand there > > is no such issue on mt7688 board. > > Do you see no further output? Or is it perhaps stuck at the DDR init > code in SPL? Can you please post the log (complete boot log with reset > command)? There is only "resetting..." printed, once the reset command is executed. By the way, I am not using SPL loader. Console output below: U-Boot 2020.07 CPU: MediaTek MT7628A ver:1 eco:2 Boot: DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz Model: test DRAM: 64 MiB Loading Environment from SPI Flash... SF: Detected w25q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB OK Net: Warning: eth@1011 (eth0) using random MAC address - ba:f6:29:35:59:b5 eth0: eth@1011 Hit any key to stop autoboot: 0 => reset resetting ... > > >What's interesting, is that "reboot" issued in Linux shell makes board > > reboot as expected on mt7628 board. > > > >It seems like some sort of configuration issue, but I couldn't find > > anything specific in the datasheet. Maybe > >you have some idea what could cause it? > > > >One more thing, when running the following version of bootloader > > (https://github.com/gnubee-git/GnuBee-MT76x8-uboot) > >"reset" command works as expected. > > I do not have a MT7628 based board, so I can't test. Perhaps Weijie has > an idea? > > Thanks, > Stefan > Thanks, Andrew
Re: reset command doesn't work on MT7628 (CPU: MediaTek MT7628A ver:1 eco:2)
Hi Stefan, On Wed, 12 Aug 2020 15:08:41 +0300 Stefan Roese wrote > Hi Andrew, > > On 12.08.20 14:04, Andrii Voloshyn wrote: > > Hi Stefan, > > > > > Hi Andrew, > > > > > > (added Weijie to Cc) > > > > > > On 12.08.20 09:18, Andrii Voloshyn wrote: > > > >Hi there, > > > > > > > >There is one issue, I experience with (U-Boot 2020.07) on > > MT7628DAN, "reset" command issued in hush prompt > > > >causes board to hang, until I do a power cycle. On the other hand > > there is no such issue on mt7688 board. > > > > > > Do you see no further output? Or is it perhaps stuck at the DDR init > > > code in SPL? Can you please post the log (complete boot log with reset > > > command)? > > > > There is only "resetting..." printed, once the reset command is executed. > > I see. Thanks. > > > By the way, I am not using SPL loader. > > Why not? Did you give the version with SPL a try? Here most of the > lowlevel init stuff is executed. Something might be missing in the > general HW setup if its not used. Then I will need to flash two binaries, spl + uboot, right? In any case SPL is optional, at least it should be. :) on this hw. > > How are you running the non-SPL (main) U-Boot on your board? Do you > load it via an old U-Boot? Or is it configured for SPI flash usage > without SPL instead? I am running the way it was done prior to recent SPL changes. SPI NOR flash is mapped to 0x9c00 address, and that's what the text base address is set to when SPL is disabled: arch/mips/mach-mtmips/Konfig config SYS_TEXT_BASE >---default 0x9c00 if !SPL >---default 0x8020 if SPL Also, I'd like to note that all other functionality in the u-boot works fine, booting of FIT images, other commands I use, the only problem is with the reset command. When I trigger reset manually (writing to RSTCTL register), I get the same behavior: mw 0x1034 0x1 > > > Console output below: > > > > U-Boot 2020.07 > > > > CPU: MediaTek MT7628A ver:1 eco:2 > > Boot: DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL > > Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz > > Model: test > > DRAM: 64 MiB > > Loading Environment from SPI Flash... SF: Detected w25q256 with page size > > 256 Bytes, erase size 4 KiB, total 32 MiB > > OK > > Net: > > Warning: eth@1011 (eth0) using random MAC address - ba:f6:29:35:59:b5 > > eth0: eth@1011 > > Hit any key to stop autoboot: 0 > > => reset > > resetting ... > > Thanks, > Stefan > Thanks. Andrii
Re: reset command doesn't work on MT7628 (CPU: MediaTek MT7628A ver:1 eco:2)
Hi Stefan, On Wed, 12 Aug 2020 15:57:31 +0300 Stefan Roese wrote > Hi Andrew, > > On 12.08.20 14:48, Andrii Voloshyn wrote: > > Hi Stefan, > > > > On Wed, 12 Aug 2020 15:08:41 +0300 Stefan Roese wrote > > > > > > > Hi Andrew, > > > > > > On 12.08.20 14:04, Andrii Voloshyn wrote: > > > > Hi Stefan, > > > > > > > > > Hi Andrew, > > > > > > > > > > (added Weijie to Cc) > > > > > > > > > > On 12.08.20 09:18, Andrii Voloshyn wrote: > > > > > >Hi there, > > > > > > > > > > > >There is one issue, I experience with (U-Boot 2020.07) on > > MT7628DAN, "reset" command issued in hush prompt > > > > > >causes board to hang, until I do a power cycle. On the > > other hand there is no such issue on mt7688 board. > > > > > > > > > > Do you see no further output? Or is it perhaps stuck at the DDR > > init > > > > > code in SPL? Can you please post the log (complete boot log with > > reset > > > > > command)? > > > > > > > > There is only "resetting..." printed, once the reset command is > > executed. > > > > > > I see. Thanks. > > > > > > > By the way, I am not using SPL loader. > > > > > > Why not? Did you give the version with SPL a try? Here most of the > > > lowlevel init stuff is executed. Something might be missing in the > > > general HW setup if its not used. > > > > Then I will need to flash two binaries, spl + uboot, right? > > Not really. The 2 images are generated automatically and combined into > one image (u-boot-with-spl.bin) that needs to be flashed instead. The > main pro of this SPL + U-Boot proper is that the resulting image is > *much* smaller (because of the compression of the U-Boot proper) and > therefore, booting is usually faster as well compared to the "old" > non-SPL only image. > > In my case its ~250kByte (combined image) compared to ~600kByte. > > > In any case SPL is optional, at least it should be. :) on this hw. > > Yes, correct. But frankly, I have not tested without SPL for a few > months now. Mainly because of the reasons I mentioned above. > Just tried u-boot-with-spl.bin image, the result is the same reset command doesn't work :( > > > > > > How are you running the non-SPL (main) U-Boot on your board? Do you > > > load it via an old U-Boot? Or is it configured for SPI flash usage > > > without SPL instead? > > > > I am running the way it was done prior to recent SPL changes. > > SPI NOR flash is mapped to 0x9c00 address, and that's what the text > > base address is set to when SPL is disabled: > > arch/mips/mach-mtmips/Konfig > > Okay. So you are flashing a non-SPL only image into SPI NOR and you are > not loading it via some other bootloader. That is what I wanted to make > sure of. > > > config SYS_TEXT_BASE > >> ---default 0x9c00 if !SPL > >> ---default 0x8020 if SPL > > > > Also, I'd like to note that all other functionality in the u-boot works > > fine, booting of FIT images, other commands I use, > > the only problem is with the reset command. > > > > When I trigger reset manually (writing to RSTCTL register), I get the same > > behavior: > > mw 0x1034 0x1 > > I see. Again, I have no real clue, sorry. Thank you for your help in any case. I've seen that Weijie made a lot of work for the chip, may be he will have some clue. > > Thanks, > Stefan > Thanks, Andrii
Re: reset command doesn't work on MT7628 (CPU: MediaTek MT7628A ver:1 eco:2)
Hi Weijie, I set (with a flash programmer) ADP bit in non-volatile register of W25Q256 to 1. To configure it upon power up to 4-Byte Address Mode. I also used bootstrapping pins of mt7628 (CHIP_MODE[2:0]) to make it boot from SPI 4-Byte Addr as well. During boot could see the following line (confirming that 4-Byte Address Mode is used): Boot: DDR2, SPI-NOR 4-Byte Addr, CPU clock from XTAL But "reset" command still didn't work. :( I tried different things, but nothing worked until I removed 1K pull-down resistor connected to UART_RXD0 pin (31). Once the resistor is removed reset command works as expected. What's boggling me is that according to a reference design 1K pull-down resistor is a must for this pin, it is even written like that on the schematic. I am puzzled :). Do you by any chance know why the resistor is required and why would it prevent reset happening? Maybe I missed something else with the configuration? Thank you so much Weijie for your wisdom Cheers, Andrew On Thu, 13 Aug 2020 04:33:14 +0300 Weijie Gao wrote > Hi Andrew, > > According to my past experience, I believe this is caused by the > W25Q256 NOR flash. > > Your bootlog shows that it's booted with SPI-NOR 3-Byte Addr, and your > board is using W25Q256 which requires 4-byte address access when > accessing the higher 16MB memory array. > > According to the datasheet of W25Q256, there are three ways to use the > 4-byte address mode: > > 1. By using the dedicate opcodes which always require 4-byte address > 2. By using "Enter 4-Byte Address Mode" opcode, to convert all opcodes > to use 4-byte address > 3. By using the Extended Address Register to specify the 4th address > byte for opcodes which require 3-byte address > > The spi-nor driver in u-boot uses combined 2 & 3 for W25Q256. > For details please refer to set_4byte() in > drivers/mtd/spi/spi-nor-core.c > > However, u-boot only enables 4-byte mode and never disables it. So after > you reset the board, the flash will remain in 4-byte mode, and the CPU > tries to access the flash with 3-byte address mode. In this situation > the flash will return unexpected data to the CPU, and the CPU will > apparently fail to boot. > > The solution is simple, just set the flash to 3-byte mode before > resetting the board by calling set_4byte() with enable=0. But you can > never 100% fix this because the watchdog reset won't give you a chance > to call set_4byte() before resetting the board. > > Best Regards, > Weijie > > > On Wed, 2020-08-12 at 16:14 +0300, Andrii Voloshyn wrote: > > Hi Stefan, > > > > On Wed, 12 Aug 2020 15:57:31 +0300 Stefan Roese wrote > > > > > > > Hi Andrew, > > > > > > On 12.08.20 14:48, Andrii Voloshyn wrote: > > > > Hi Stefan, > > > > > > > > On Wed, 12 Aug 2020 15:08:41 +0300 Stefan Roese > > wrote > > > > > > > > > Hi Andrew, > > > > > > > > > > On 12.08.20 14:04, Andrii Voloshyn wrote: > > > > > > Hi Stefan, > > > > > > > > > > > > > Hi Andrew, > > > > > > > > > > > > > > (added Weijie to Cc) > > > > > > > > > > > > > > On 12.08.20 09:18, Andrii Voloshyn wrote: > > > > > > > >Hi there, > > > > > > > > > > > > > > > >There is one issue, I experience with (U-Boot 2020.07) > > on MT7628DAN, "reset" command issued in hush prompt > > > > > > > >causes board to hang, until I do a power cycle. On the > > other hand there is no such issue on mt7688 board. > > > > > > > > > > > > > > Do you see no further output? Or is it perhaps stuck at the > > DDR init > > > > > > > code in SPL? Can you please post the log (complete boot log > > with reset > > > > > > > command)? > > > > > > > > > > > > There is only "resetting..." printed, once the reset command is > > executed. > > > > > > > > > > I see. Thanks. > > > > > > > > > > > By the way, I am not using SPL loader. > > > > > > > > > > Why not? Did you give the version with SPL a try?
How to make u-boot verify script signature in FIT image
Hi there,
I have a script in FIT image, I want to verify its signature before
running it.
When I run "source" command, it doesn't check the signature, only hash@1.
images {
...
script {
description = "Script";
data = /incbin/("script.txt");
type = "script";
compression = "none";
hash@1 {
algo = "crc32";
};
signature {
algo = "sha256,rsa4096";
};
};
}
How to make u-boot verify the script before running it? Is it possible to
auto run the script when boot a configuration from a FIT image?
Thank you
Cheers,
Andy
mt7628-eth: phy link up detection takes too long
Hi there, I enabled (Automatic software update from a TFTP server [CONFIG_UPDATE_TFTP]), and noticed that it takes around 7 seconds to detect link up on the PHY. Is there a way to make this detection faster? I tried to advertise only 10MBit full duplex mode with auto negotiation disabled, but somehow host connected on the other end does not seem to recognize this. Could not find any documents on mt7628 Ethernet PHY, registers, timings, etc. Any ideas on how to speed up this link detection would be helpful. Cheers, Andrew
