[PATCH] riscv: sifive: fu740: reduce DDR speed from 1866MT/s to 1600MT/s
From: Thomas Perrot It appears that there is some timing marginality either in the board layout or the SoC that results in occasional data corruption on some boards. We observed this issue on some of the new HiFive Unmatched RevB boards during volume production as well as some of the original HiFive Unmatched boards from 2021 in our possession. This means that there are other boards out there that might have the issue too. We have done some limited testing with DDR4 at 1600MT/s and faulty boards (failing at 1866MT/s) passed. We plan further testing after we procure a temperature chamber. Signed-off-by: Thomas Perrot --- arch/riscv/dts/fu740-c000-u-boot.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/dts/fu740-c000-u-boot.dtsi b/arch/riscv/dts/fu740-c000-u-boot.dtsi index 706224b384d2..956237c3218e 100644 --- a/arch/riscv/dts/fu740-c000-u-boot.dtsi +++ b/arch/riscv/dts/fu740-c000-u-boot.dtsi @@ -77,7 +77,7 @@ 0x0 0x100b2000 0x0 0x2000 0x0 0x100b8000 0x0 0x1000>; clocks = < FU740_PRCI_CLK_DDRPLL>; - clock-frequency = <93324>; + clock-frequency = <80004>; bootph-pre-ram; }; }; -- 2.43.2
[PATCH] ARM: at91: armv7: don't initialize clocks if scmi clock driver is enabled
From: Clément Léger
Because clock devices are initialized by the SCMI server, if
CONFIG_CLK_SCMI is defined.
Signed-off-by: Clément Léger
Signed-off-by: Thomas Perrot
---
arch/arm/mach-at91/armv7/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-at91/armv7/cpu.c b/arch/arm/mach-at91/armv7/cpu.c
index 616621a1f9de..5ea7e2609f59 100644
--- a/arch/arm/mach-at91/armv7/cpu.c
+++ b/arch/arm/mach-at91/armv7/cpu.c
@@ -24,7 +24,7 @@
int arch_cpu_init(void)
{
-#if defined(CONFIG_CLK_CCF)
+#if defined(CONFIG_CLK_CCF) || defined(CONFIG_CLK_SCMI)
return 0;
#else
return at91_clock_init(CFG_SYS_AT91_MAIN_CLOCK);
--
2.40.1
[PATCH] rtc: m41t62: implements read8/write8 operations
From: Thomas Perrot
These operations are required by dm_rtc_read and
dm_bootcount_get helpers.
Signed-off-by: Thomas Perrot
---
drivers/rtc/m41t62.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/rtc/m41t62.c b/drivers/rtc/m41t62.c
index 66a0faa0ecff..891fe09d311b 100644
--- a/drivers/rtc/m41t62.c
+++ b/drivers/rtc/m41t62.c
@@ -283,6 +283,16 @@ static int m41t62_rtc_reset(struct udevice *dev)
return m41t62_sqw_enable(dev, true);
}
+static int m41t62_rtc_read8(struct udevice *dev, unsigned int reg)
+{
+ return dm_i2c_reg_read(dev, reg);
+}
+
+static int m41t62_rtc_write8(struct udevice *dev, unsigned int reg, int val)
+{
+ return dm_i2c_reg_write(dev, reg, val);
+}
+
/*
* Make sure HT bit is cleared. This bit is set on entering battery backup
* mode, so do this before the first read access.
@@ -296,6 +306,8 @@ static const struct rtc_ops m41t62_rtc_ops = {
.get = m41t62_rtc_get,
.set = m41t62_rtc_set,
.reset = m41t62_rtc_reset,
+ .read8 = m41t62_rtc_read8,
+ .write8 = m41t62_rtc_write8,
};
static const struct udevice_id m41t62_rtc_ids[] = {
--
2.39.2
Re: U-boot
Hi Roman, On Sat, 2021-07-31 at 03:34 +, Roman Kopytin wrote: > Thanks, Michael. > Can we sign in the separate state on special server for example? Yes, it possible, there is a step to build and another one to sign, that can be separated. For example, the following command, that build and sign the itb: # build and sign mkimage -D "-I dts -O dtb -p 4096" -f ./foo.its -k ./keys -K ./u- boot.dtb -r ./foo.itb Can be spitted in two: # build uboot-mkimage \ -D "-I dts -O dtb -p 4096" \ -f ./foo.its \ ./foo.itb # sign uboot-mkimage \ -D "-I dts -O dtb -p 4096" -F -k ./keys \ -K ./u-boot.dtb \ -r \ ./foo.itb Then the u-boot*.dtb should contains the pubkey node(s) in the signature node and it can be shared and concatenated to the U-Boot binary: make EXT_DTB="./u-boot.dtb" > Looks like we can work with public key only in this step. The dtb containing the public key(s) is useful to verify the signature at the target boot, or with the tool fit_check_sign to perform an offload checking, for example: fit_check_sign -f ./foo.itb -k ./u-boot.dtb Best regards, Thomas Perrot > > From: Michael Nazzareno Trimarchi > Sent: Friday, July 30, 2021 8:50 PM > To: Roman Kopytin > Cc: U-Boot-Denx ; Simon Glass > Subject: Re: U-boot > > Caution: This is an external email. Be cautious while opening links or > attachments. > > > Hi Román > > > On Fri, Jul 30, 2021, 7:44 PM Roman Kopytin < > roman.kopy...@kaspersky.com<mailto:roman.kopy...@kaspersky.com>> wrote: > Hello, dear U-boot team > > I have question about your old feature: U-boot patch for adding of the > public key to dtb file. > > https://patchwork.ozlabs.org/project/uboot/patch/1363650725-30459-37-git-send-email-sjg%40chromium.org/ > > I can’t understand, can we work only with public key? Why do we need to > have private key for adding step? > In documentation it is not very clear for me. > > You need to sign with private key and keep it secret and local and > verify it during booting with public key. Private key is not > distributed with the image > > Michael > > > Thanks a lot. > -- Thomas Perrot, Bootlin Embedded Linux and kernel engineering https://bootlin.com signature.asc Description: This is a digitally signed message part
[PATCH] lib: rsa: rsa-verify: Fix a typo in a debug message
Signed-off-by: Thomas Perrot
---
lib/rsa/rsa-verify.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
index bb8cc61d94b5..3840764e420e 100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -556,7 +556,7 @@ int rsa_verify(struct image_sign_info *info,
*/
if (info->checksum->checksum_len >
info->crypto->key_len) {
- debug("%s: invlaid checksum-algorithm %s for %s\n",
+ debug("%s: invalid checksum-algorithm %s for %s\n",
__func__, info->checksum->name, info->crypto->name);
return -EINVAL;
}
--
2.31.1
Some questions about the U-Boot verified boot
Hello everyone, I have a question about the verified boot, is it possible to sign both images and configurations in the same fitimage? I ask the question because when I try to do that then the image signature checking always fails, when calling the source command, without preventing the loading of the bootscr. I would like that the loading is strictly interrupted, in case of failure of an image signature checking or a configuration signature checking. Moreover, when configurations aren’t signed or with an invalid key then an error is well raised and loading interrupted. In addition, from the dtb, the property “required” of the signature node is set to config. Then it doesn’t seem possible to sign images and configurations with the same key, even using different fitimage. Could using two keys solve my issue? Is there a way to make the verified boot strict, to prohibit the use of fitimage which does not contain any signature, and ensure that either the images or the configurations are always signed? In my case, setting the variable verify=yes seems doesn’t work correctly. NB. I’m using the version 2020.04. Best regards, Thomas Perrot -- Thomas Perrot, Bootlin Embedded Linux and kernel engineering https://bootlin.com signature.asc Description: This is a digitally signed message part
[PATCH] doc: fix typo in signature.txt
Fix value fields in signature nodes.
Signed-off-by: Thomas Perrot
---
doc/uImage.FIT/signature.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt
index d9a912119032..7cb1c15e5e15 100644
--- a/doc/uImage.FIT/signature.txt
+++ b/doc/uImage.FIT/signature.txt
@@ -266,14 +266,14 @@ As an example, consider this FIT:
data = ;
signature-1 {
algo = "sha1,rsa2048";
- vaue = <...fdt signature 1...>
+ value = <...fdt signature 1...>
};
};
fdt-2 {
data = ;
signature-1 {
algo = "sha1,rsa2048";
- vaue = <...fdt signature 2...>
+ value = <...fdt signature 2...>
};
};
};
--
2.31.1
