[PATCH 1/1] fs/squashfs: avoid superfluous messages
Output like the following is quite irritating:
=> bootefi hello
Scanning disk mmc2.blk...
No valid Btrfs found
Bad magic number for SquashFS image.
** Unrecognized filesystem type **
Scanning disk mmc1.blk...
No valid Btrfs found
Bad magic number for SquashFS image.
** Unrecognized filesystem type **
Scanning disk mmc0.blk...
No valid Btrfs found
Bad magic number for SquashFS image.
** Unrecognized filesystem type **
It is expected that most partitions don't contain a SquashFS. This is only
worth a debug message.
When adding log.h put the other includes into the correct order according
to our code style guide.
Signed-off-by: Heinrich Schuchardt
---
fs/squashfs/sqfs.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
index 92ab8ac631..3923e7c996 100644
--- a/fs/squashfs/sqfs.c
+++ b/fs/squashfs/sqfs.c
@@ -10,14 +10,15 @@
#include
#include
#include
-#include
-#include
-#include
+#include
#include
#include
#include
#include
#include
+#include
+#include
+#include
#include "sqfs_decompressor.h"
#include "sqfs_filesystem.h"
@@ -1090,7 +1091,7 @@ int sqfs_probe(struct blk_desc *fs_dev_desc, struct
disk_partition *fs_partition
/* Make sure it has a valid SquashFS magic number*/
if (get_unaligned_le32(>s_magic) != SQFS_MAGIC_NUMBER) {
- printf("Bad magic number for SquashFS image.\n");
+ log_debug("Bad magic number for SquashFS image.\n");
ret = -EINVAL;
goto error;
}
--
2.32.0
Re: RFC: exclude partitions from efi_selftest
On Thu, Sep 16, 2021 at 09:48:07AM +0200, Michael Lawnick wrote: > Am 16.09.2021 um 09:15 schrieb Michael Lawnick: > > Am 16.09.2021 um 09:12 schrieb AKASHI Takahiro: > > > Please, as Heinrich suggested, add CONFIG_FS_FAT, in your U-Boot > > > configuration. > > > > > Hmm, I didn't understand that as a suggestion, but as a question for his > > understanding. Of course I'll give it a try. > > > Sometimes live is such easy. This fixed my issue, THX. > > For the after-math / my understanding: > - Do I understand correctly that the problem was that 'efi_selftest > block device' requires FAT support? So shouldn't there be a dependency > in CONFIG? Strictly speaking, CONFIG_EFI_LOADER requires FAT per UEFI specification, and actually it has 'imply FAT'. I don't know why Heinrich uses 'imply' instead of 'select'. > - What is the reason/use to iterate through the recognized partitions > even twice (in .setup and .execute) if they aren't needed/used? What line of code do you exactly mean by 'in .setup' (and in .execute)? -Takahiro Akashi > > -- > KR > Michael
[PATCH next v4 00/11] aspeed: Support secure boot chain with FIT image verification
This patch series intends to provide a secure boot chain from SPL to Linux kernel based on the hash and signature verification of FIT image paradigm. To improve the performance and save code size (SPL is limited to 64KB due to HW-RoT), the drviers of two HW crypto engine HACE and ACRY are also added for AST26xx SoCs. As HACE and ACRY can only access to DRAM space, additional configuration and boot command are also updated according to move each FIT image before its booting. In addition, the common code of FIT image hash algorithm lookup is also revised to leverage the HW accelerated calculation. v4: - add new DM_HASH based driver for Aspeed HACE - remove SPL board init, which was originally used to probe non-DM HACE driver - fix typo of ARCY to ACRY - refactor defconfig based on the new Kconfig of U-Boot next branch v3: - add SW work around for HACE HW DMA issue by resetting HACE - add reset control for HACE device tree node - sync all of the HACE error message to use debug() v2: - update commit authors Chia-Wei Wang (8): aspeed: ast2600: Enlarge SRAM size clk: ast2600: Add RSACLK control for ACRY crypto: aspeed: Add AST2600 ACRY support ARM: dts: ast2600: Add ACRY to device tree ast2600: spl: Locate load buffer in DRAM space configs: ast2600-evb: Enable SPL FIT support configs: aspeed: Make EXTRA_ENV_SETTINGS board specific configs: ast2600: Boot kernel FIT in DRAM Joel Stanley (2): clk: ast2600: Add YCLK control for HACE ARM: dts: ast2600: Add HACE to device tree Johnny Huang (1): crypto: aspeed: Add AST2600 HACE support arch/arm/dts/ast2600-evb.dts | 10 + arch/arm/dts/ast2600.dtsi | 17 + arch/arm/include/asm/arch-aspeed/platform.h | 2 +- .../arm/include/asm/arch-aspeed/scu_ast2600.h | 6 +- arch/arm/mach-aspeed/ast2600/spl.c| 9 +- configs/evb-ast2600_defconfig | 22 +- drivers/clk/aspeed/clk_ast2600.c | 38 ++ drivers/crypto/Kconfig| 2 + drivers/crypto/Makefile | 1 + drivers/crypto/aspeed/Kconfig | 20 + drivers/crypto/aspeed/Makefile| 2 + drivers/crypto/aspeed/aspeed_acry.c | 182 + drivers/crypto/aspeed/aspeed_hace.c | 381 ++ drivers/crypto/hash/Kconfig | 8 + include/configs/aspeed-common.h | 9 - include/configs/evb_ast2500.h | 9 + include/configs/evb_ast2600.h | 16 + lib/rsa/Kconfig | 10 +- 18 files changed, 719 insertions(+), 25 deletions(-) create mode 100644 drivers/crypto/aspeed/Kconfig create mode 100644 drivers/crypto/aspeed/Makefile create mode 100644 drivers/crypto/aspeed/aspeed_acry.c create mode 100644 drivers/crypto/aspeed/aspeed_hace.c -- 2.17.1
[PATCH next v4 03/11] crypto: aspeed: Add AST2600 HACE support
From: Johnny Huang
Hash and Crypto Engine (HACE) is designed to accelerate the
throughput of hash data digest, and symmetric-key encryption.
Signed-off-by: Johnny Huang
Signed-off-by: Chia-Wei Wang
---
drivers/crypto/Kconfig | 2 +
drivers/crypto/Makefile | 1 +
drivers/crypto/aspeed/Kconfig | 10 +
drivers/crypto/aspeed/Makefile | 1 +
drivers/crypto/aspeed/aspeed_hace.c | 381
drivers/crypto/hash/Kconfig | 8 +
6 files changed, 403 insertions(+)
create mode 100644 drivers/crypto/aspeed/Kconfig
create mode 100644 drivers/crypto/aspeed/Makefile
create mode 100644 drivers/crypto/aspeed/aspeed_hace.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 0082177c21..675081ecd3 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -4,4 +4,6 @@ source drivers/crypto/hash/Kconfig
source drivers/crypto/fsl/Kconfig
+source drivers/crypto/aspeed/Kconfig
+
endmenu
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 4a12b56be6..584715b4c9 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_EXYNOS_ACE_SHA)+= ace_sha.o
obj-y += rsa_mod_exp/
obj-y += fsl/
obj-y += hash/
+obj-y += aspeed/
diff --git a/drivers/crypto/aspeed/Kconfig b/drivers/crypto/aspeed/Kconfig
new file mode 100644
index 00..471c06f986
--- /dev/null
+++ b/drivers/crypto/aspeed/Kconfig
@@ -0,0 +1,10 @@
+config ASPEED_HACE
+ bool "ASPEED Hash and Crypto Engine"
+ depends on DM_HASH
+ help
+ Select this option to enable a driver for using the SHA engine in
+ the ASPEED BMC SoCs.
+
+ Enabling this allows the use of SHA operations in hardware without
+ requiring the SHA software implementations. It also improves
performance
+ and saves code size.
diff --git a/drivers/crypto/aspeed/Makefile b/drivers/crypto/aspeed/Makefile
new file mode 100644
index 00..84e6bfe82a
--- /dev/null
+++ b/drivers/crypto/aspeed/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_ASPEED_HACE) += aspeed_hace.o
diff --git a/drivers/crypto/aspeed/aspeed_hace.c
b/drivers/crypto/aspeed/aspeed_hace.c
new file mode 100644
index 00..1178cc6a76
--- /dev/null
+++ b/drivers/crypto/aspeed/aspeed_hace.c
@@ -0,0 +1,381 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright 2021 ASPEED Technology Inc.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* register offsets*/
+#define HACE_STS 0x1C
+#define HACE_HASH_DATA_OVF BIT(23)
+#define HACE_HASH_INTBIT(9)
+#define HACE_HASH_BUSY BIT(0)
+#define HACE_HASH_DATA 0x20
+#define HACE_HASH_DIGEST 0x24
+#define HACE_HASH_HMAC_KEY 0x28
+#define HACE_HASH_DATA_LEN 0x2C
+#define HACE_HASH_CMD 0x30
+#define HACE_HASH_MODE_ACCUM BIT(8)
+#define HACE_HASH_ALGO_SHA1 BIT(5)
+#define HACE_HASH_ALGO_SHA256(BIT(6) | BIT(4))
+#define HACE_HASH_ALGO_SHA384(BIT(10) | BIT(6) | BIT(5))
+#define HACE_HASH_ALGO_SHA512(BIT(6) | BIT(5))
+#define HACE_HASH_SHA_BE_EN BIT(3)
+
+/* buffer size based on SHA-512 need*/
+#define HASH_BLOCK_BUFSZ 128
+#define HASH_DIGEST_BUFSZ 64
+
+struct aspeed_hace_ctx {
+ uint8_t digest[HASH_DIGEST_BUFSZ];
+
+ uint32_t cmd;
+ enum HASH_ALGO algo;
+
+ uint32_t blk_size;
+ uint32_t pad_size;
+ uint64_t total[2];
+
+ uint8_t buf[HASH_BLOCK_BUFSZ];
+ uint32_t buf_cnt;
+} __aligned((8));
+
+struct aspeed_hace {
+ phys_addr_t base;
+ struct clk clk;
+};
+
+static const uint32_t iv_sha1[8] = {
+ 0x01234567, 0x89abcdef, 0xfedcba98, 0x76543210,
+ 0xf0e1d2c3, 0, 0, 0
+};
+
+static const uint32_t iv_sha256[8] = {
+ 0x67e6096a, 0x85ae67bb, 0x72f36e3c, 0x3af54fa5,
+ 0x7f520e51, 0x8c68059b, 0xabd9831f, 0x19cde05bUL
+};
+
+static const uint32_t iv_sha384[16] = {
+ 0x5d9dbbcb, 0xd89e05c1, 0x2a299a62, 0x07d57c36,
+ 0x5a015991, 0x17dd7030, 0xd8ec2f15, 0x39590ef7,
+ 0x67263367, 0x310bc0ff, 0x874ab48e, 0x11155868,
+ 0x0d2e0cdb, 0xa78ff964, 0x1d48b547, 0xa44ffabeUL
+};
+
+static const uint32_t iv_sha512[16] = {
+ 0x67e6096a, 0x08c9bcf3, 0x85ae67bb, 0x3ba7ca84,
+ 0x72f36e3c, 0x2bf894fe, 0x3af54fa5, 0xf1361d5f,
+ 0x7f520e51, 0xd182e6ad, 0x8c68059b, 0x1f6c3e2b,
+ 0xabd9831f, 0x6bbd41fb, 0x19cde05b, 0x79217e13UL
+};
+
+static int aspeed_hace_wait_completion(uint32_t reg, uint32_t flag, int
timeout_us)
+{
+ uint32_t val;
+
+ return readl_poll_timeout(reg, val, (val & flag) == flag, timeout_us);
+}
+
+static int aspeed_hace_process(struct udevice *dev, void *ctx, const void
*ibuf, uint32_t ilen)
+{
+ struct aspeed_hace *hace = dev_get_priv(dev);
+
[PATCH next v4 01/11] aspeed: ast2600: Enlarge SRAM size
The AST2600 SRAM has been extended to 88KB since A1 chip revision. This patch updates the SRAM size to offer more space for early stack/heap use. Signed-off-by: Chia-Wei Wang --- arch/arm/include/asm/arch-aspeed/platform.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/include/asm/arch-aspeed/platform.h b/arch/arm/include/asm/arch-aspeed/platform.h index d50ec5f8a9..589abd4a3f 100644 --- a/arch/arm/include/asm/arch-aspeed/platform.h +++ b/arch/arm/include/asm/arch-aspeed/platform.h @@ -17,7 +17,7 @@ #define ASPEED_MAC_COUNT 4 #define ASPEED_DRAM_BASE 0x8000 #define ASPEED_SRAM_BASE 0x1000 -#define ASPEED_SRAM_SIZE 0x1 +#define ASPEED_SRAM_SIZE 0x16000 #else #err "Unrecognized Aspeed platform." #endif -- 2.17.1
[PATCH next v4 05/11] clk: ast2600: Add RSACLK control for ACRY
Add RSACLK enable for ACRY, the HW RSA/ECC crypto engine
of ASPEED AST2600 SoCs.
As ACRY and HACE share the same reset control bit, we do not
perform the reset-hold-n-release operation during their clock
ungating process. Instead, only reset release is conducted to
prevent mutual interference.
Signed-off-by: Chia-Wei Wang
---
.../arm/include/asm/arch-aspeed/scu_ast2600.h | 1 +
drivers/clk/aspeed/clk_ast2600.c | 22 +--
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-aspeed/scu_ast2600.h
b/arch/arm/include/asm/arch-aspeed/scu_ast2600.h
index d7b500f656..7c5aab98b6 100644
--- a/arch/arm/include/asm/arch-aspeed/scu_ast2600.h
+++ b/arch/arm/include/asm/arch-aspeed/scu_ast2600.h
@@ -8,6 +8,7 @@
#define SCU_UNLOCK_KEY 0x1688a8a8
#define SCU_CLKGATE1_EMMC BIT(27)
+#define SCU_CLKGATE1_ACRY BIT(24)
#define SCU_CLKGATE1_MAC2 BIT(21)
#define SCU_CLKGATE1_MAC1 BIT(20)
#define SCU_CLKGATE1_USB_HUB BIT(14)
diff --git a/drivers/clk/aspeed/clk_ast2600.c b/drivers/clk/aspeed/clk_ast2600.c
index 69128fd3c4..f6ebf824aa 100644
--- a/drivers/clk/aspeed/clk_ast2600.c
+++ b/drivers/clk/aspeed/clk_ast2600.c
@@ -1018,11 +1018,26 @@ static ulong ast2600_enable_haceclk(struct ast2600_scu
*scu)
uint32_t reset_bit;
uint32_t clkgate_bit;
+ /* share the same reset control bit with ACRY */
reset_bit = BIT(ASPEED_RESET_HACE);
clkgate_bit = SCU_CLKGATE1_HACE;
- writel(reset_bit, >modrst_ctrl1);
- udelay(100);
+ writel(clkgate_bit, >clkgate_clr1);
+ mdelay(20);
+ writel(reset_bit, >modrst_clr1);
+
+ return 0;
+}
+
+static ulong ast2600_enable_rsaclk(struct ast2600_scu *scu)
+{
+ uint32_t reset_bit;
+ uint32_t clkgate_bit;
+
+ /* share the same reset control bit with HACE */
+ reset_bit = BIT(ASPEED_RESET_HACE);
+ clkgate_bit = SCU_CLKGATE1_ACRY;
+
writel(clkgate_bit, >clkgate_clr1);
mdelay(20);
writel(reset_bit, >modrst_clr1);
@@ -1071,6 +1086,9 @@ static int ast2600_clk_enable(struct clk *clk)
case ASPEED_CLK_GATE_YCLK:
ast2600_enable_haceclk(priv->scu);
break;
+ case ASPEED_CLK_GATE_RSACLK:
+ ast2600_enable_rsaclk(priv->scu);
+ break;
default:
pr_err("can't enable clk\n");
return -ENOENT;
--
2.17.1
[PATCH next v4 04/11] ARM: dts: ast2600: Add HACE to device tree
From: Joel Stanley
Add HACE DTS node and enable it for AST2600 EVB.
Signed-off-by: Joel Stanley
Signed-off-by: Chia-Wei Wang
---
arch/arm/dts/ast2600-evb.dts | 5 +
arch/arm/dts/ast2600.dtsi| 8
2 files changed, 13 insertions(+)
diff --git a/arch/arm/dts/ast2600-evb.dts b/arch/arm/dts/ast2600-evb.dts
index 2abd31341c..adb80a30ef 100644
--- a/arch/arm/dts/ast2600-evb.dts
+++ b/arch/arm/dts/ast2600-evb.dts
@@ -177,3 +177,8 @@
0x08 0x04
0x08 0x04>;
};
+
+ {
+ u-boot,dm-pre-reloc;
+ status = "okay";
+};
diff --git a/arch/arm/dts/ast2600.dtsi b/arch/arm/dts/ast2600.dtsi
index ac0f08b7ea..642206fb77 100644
--- a/arch/arm/dts/ast2600.dtsi
+++ b/arch/arm/dts/ast2600.dtsi
@@ -187,6 +187,14 @@
};
};
+ hace: hace@1e6d {
+ compatible = "aspeed,ast2600-hace";
+ reg = <0x1e6d 0x200>;
+ interrupts = ;
+ clocks = < ASPEED_CLK_GATE_YCLK>;
+ status = "disabled";
+ };
+
edac: sdram@1e6e {
compatible = "aspeed,ast2600-sdram-edac";
reg = <0x1e6e 0x174>;
--
2.17.1
[PATCH 1/1] scripts/mailmapper: enable running with Python 3
Our mailmapper script required Python 2 which is no longer maintained.
A main difference when converting to Python 3 is that byte strings are not
character strings. So add conversion and skip over conversion errors.
Signed-off-by: Heinrich Schuchardt
---
scripts/mailmapper | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/scripts/mailmapper b/scripts/mailmapper
index 2e2d7faff5..0e744ec1a0 100755
--- a/scripts/mailmapper
+++ b/scripts/mailmapper
@@ -1,4 +1,4 @@
-#!/usr/bin/env python2
+#!/usr/bin/env python3
# SPDX-License-Identifier: GPL-2.0+
#
# Copyright (C) 2014, Masahiro Yamada
@@ -89,9 +89,10 @@ output = {}
for line in shortlog.splitlines():
# tmp, mail = line.rsplit(None, 1) is not safe
# because weird email addresses might include whitespaces
-tmp, mail = line.split('<')
-mail = '<' + mail.rstrip()
try:
+line = line.decode("utf-8")
+tmp, mail = line.split('<')
+mail = '<' + mail.rstrip()
_, name = tmp.rstrip().split(None, 1)
except ValueError:
# author name is empty
@@ -100,8 +101,11 @@ for line in shortlog.splitlines():
# another name for the same email address
prev_name = mail_vs_name[mail]
# Take the name with more commits
-major_name = sorted([prev_name, name],
-key=lambda x: commits_per_name[x] if x else 0)[1]
+try:
+major_name = sorted([prev_name, name],
+key=lambda x: commits_per_name[x] if x else
0)[1]
+except:
+continue
mail_vs_name[mail] = major_name
if commits_per_name[major_name] > MIN_COMMITS:
output[mail] = major_name
--
2.32.0
[PATCH 1/3] efi_selftest: Use EFI_SIMPLE_NETWORK_PROTOCOL::GetStatus() for media check
According to the UEF specification v2.9, the main purpose of the
EFI_SIMPLE_NETWORK_PROTOCOL::GetStatus() is for checking the link
status via EFI_SIMPLE_NETWORK_MODE::MediaPresent.
So this uses net->get_status() for checking the link status before
running network test.
Signed-off-by: Masami Hiramatsu
---
lib/efi_selftest/efi_selftest_snp.c | 12
1 file changed, 12 insertions(+)
diff --git a/lib/efi_selftest/efi_selftest_snp.c
b/lib/efi_selftest/efi_selftest_snp.c
index 79f0467803..cb0db7eea2 100644
--- a/lib/efi_selftest/efi_selftest_snp.c
+++ b/lib/efi_selftest/efi_selftest_snp.c
@@ -309,6 +309,18 @@ static int execute(void)
return EFI_ST_FAILURE;
}
+ /* Check media connected */
+ ret = net->get_status(net, NULL, NULL);
+ if (ret != EFI_SUCCESS) {
+ efi_st_error("Failed to get status");
+ return EFI_ST_FAILURE;
+ }
+ if (net->mode && net->mode->media_present_supported &&
+ !net->mode->media_present) {
+ efi_st_error("Network media is not connected");
+ return EFI_ST_FAILURE;
+ }
+
/*
* Send DHCP discover message
*/
[PATCH next v4 02/11] clk: ast2600: Add YCLK control for HACE
From: Joel Stanley
Add YCLK enable for HACE, the HW hash engine of
ASPEED AST2600 SoCs.
Signed-off-by: Joel Stanley
Signed-off-by: Chia-Wei Wang
---
.../arm/include/asm/arch-aspeed/scu_ast2600.h | 5 +++--
drivers/clk/aspeed/clk_ast2600.c | 20 +++
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-aspeed/scu_ast2600.h
b/arch/arm/include/asm/arch-aspeed/scu_ast2600.h
index a205fb1f76..d7b500f656 100644
--- a/arch/arm/include/asm/arch-aspeed/scu_ast2600.h
+++ b/arch/arm/include/asm/arch-aspeed/scu_ast2600.h
@@ -10,8 +10,9 @@
#define SCU_CLKGATE1_EMMC BIT(27)
#define SCU_CLKGATE1_MAC2 BIT(21)
#define SCU_CLKGATE1_MAC1 BIT(20)
-#define SCU_CLKGATE1_USB_HUB BIT(14)
-#define SCU_CLKGATE1_USB_HOST2 BIT(7)
+#define SCU_CLKGATE1_USB_HUB BIT(14)
+#define SCU_CLKGATE1_HACE BIT(13)
+#define SCU_CLKGATE1_USB_HOST2 BIT(7)
#define SCU_CLKGATE2_FSI BIT(30)
#define SCU_CLKGATE2_MAC4 BIT(21)
diff --git a/drivers/clk/aspeed/clk_ast2600.c b/drivers/clk/aspeed/clk_ast2600.c
index 3a92739f5c..69128fd3c4 100644
--- a/drivers/clk/aspeed/clk_ast2600.c
+++ b/drivers/clk/aspeed/clk_ast2600.c
@@ -1013,6 +1013,23 @@ static ulong ast2600_enable_usbbhclk(struct ast2600_scu
*scu)
return 0;
}
+static ulong ast2600_enable_haceclk(struct ast2600_scu *scu)
+{
+ uint32_t reset_bit;
+ uint32_t clkgate_bit;
+
+ reset_bit = BIT(ASPEED_RESET_HACE);
+ clkgate_bit = SCU_CLKGATE1_HACE;
+
+ writel(reset_bit, >modrst_ctrl1);
+ udelay(100);
+ writel(clkgate_bit, >clkgate_clr1);
+ mdelay(20);
+ writel(reset_bit, >modrst_clr1);
+
+ return 0;
+}
+
static int ast2600_clk_enable(struct clk *clk)
{
struct ast2600_clk_priv *priv = dev_get_priv(clk->dev);
@@ -1051,6 +1068,9 @@ static int ast2600_clk_enable(struct clk *clk)
case ASPEED_CLK_GATE_USBPORT2CLK:
ast2600_enable_usbbhclk(priv->scu);
break;
+ case ASPEED_CLK_GATE_YCLK:
+ ast2600_enable_haceclk(priv->scu);
+ break;
default:
pr_err("can't enable clk\n");
return -ENOENT;
--
2.17.1
Re: [PATCH] apalis/colibri_imx6: move setting bootcmd to defconfig
Hi Marcel, On Wed, Sep 15, 2021 at 11:12 PM Marcel Ziswiler wrote: > > Hi Oleksandr > > Thanks, just one minor nit-pick below. > > On Sun, 2021-09-12 at 22:39 +0300, Oleksandr Suvorov wrote: > > Move setting the default boot command to the > > apalis/colibri_imx6_defconfig. It allows replacing the command > > without code modification. > > > > Signed-off-by: Oleksandr Suvorov > > --- > > > > configs/apalis_imx6_defconfig | 1 + > > configs/colibri_imx6_defconfig | 1 + > > include/configs/apalis_imx6.h | 4 > > include/configs/colibri_imx6.h | 4 > > 4 files changed, 2 insertions(+), 8 deletions(-) > > > > diff --git a/configs/apalis_imx6_defconfig b/configs/apalis_imx6_defconfig > > index a0e85ba23a4..a2e0f8e3936 100644 > > --- a/configs/apalis_imx6_defconfig > > +++ b/configs/apalis_imx6_defconfig > > @@ -23,6 +23,7 @@ CONFIG_DISTRO_DEFAULTS=y > > CONFIG_FIT=y > > CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" > > CONFIG_BOOTDELAY=1 > > +CONFIG_BOOTCOMMAND="run distro_bootcmd;usb start;setenv stdout > > serial,vidconsole;setenv stdin serial,usbkbd" > > I believe, usually we had a space after those semicolons, not? Thanks! Fixed. > > > # CONFIG_DISPLAY_BOARDINFO is not set > > CONFIG_DISPLAY_BOARDINFO_LATE=y > > CONFIG_BOARD_EARLY_INIT_F=y > > diff --git a/configs/colibri_imx6_defconfig b/configs/colibri_imx6_defconfig > > index 47b1cfb1917..bee4e7edd63 100644 > > --- a/configs/colibri_imx6_defconfig > > +++ b/configs/colibri_imx6_defconfig > > @@ -22,6 +22,7 @@ CONFIG_DISTRO_DEFAULTS=y > > CONFIG_FIT=y > > CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" > > CONFIG_BOOTDELAY=1 > > +CONFIG_BOOTCOMMAND="run distro_bootcmd;usb start;setenv stdout > > serial,vidconsole;setenv stdin serial,usbkbd" > > Ditto. > > > # CONFIG_DISPLAY_BOARDINFO is not set > > CONFIG_DISPLAY_BOARDINFO_LATE=y > > CONFIG_BOARD_EARLY_INIT_F=y > > diff --git a/include/configs/apalis_imx6.h b/include/configs/apalis_imx6.h > > index 12de0105c6c..ade479cb943 100644 > > --- a/include/configs/apalis_imx6.h > > +++ b/include/configs/apalis_imx6.h > > @@ -133,10 +133,6 @@ > > #endif > > #define CONFIG_EXTRA_ENV_SETTINGS \ > > BOOTENV \ > > - "bootcmd=run distro_bootcmd ; " \ > > - "usb start ; " \ > > - "setenv stdout serial,vidconsole; " \ > > - "setenv stdin serial,usbkbd\0" \ > > At least here we definitely did have them (;-p). > > > "boot_file=zImage\0" \ > > "console=ttymxc0\0" \ > > "defargs=enable_wait_mode=off vmalloc=400M\0" \ > > diff --git a/include/configs/colibri_imx6.h b/include/configs/colibri_imx6.h > > index 804a144a03e..f91d6b49ea8 100644 > > --- a/include/configs/colibri_imx6.h > > +++ b/include/configs/colibri_imx6.h > > @@ -115,10 +115,6 @@ > > #define FDT_FILE "imx6dl-colibri-eval-v3.dtb" > > #define CONFIG_EXTRA_ENV_SETTINGS \ > > BOOTENV \ > > - "bootcmd=run distro_bootcmd; " \ > > - "usb start ; " \ > > - "setenv stdout serial,vidconsole; " \ > > - "setenv stdin serial,usbkbd\0" \ > > "boot_file=zImage\0" \ > > "console=ttymxc0\0" \ > > "defargs=enable_wait_mode=off galcore.contiguousSize=50331648\0" \ > > Cheers > > Marcel -- Best regards Oleksandr Oleksandr Suvorov cryo...@gmail.com
Re: RFC: exclude partitions from efi_selftest
Am 16.09.2021 um 10:02 schrieb AKASHI Takahiro: On Thu, Sep 16, 2021 at 09:48:07AM +0200, Michael Lawnick wrote: Am 16.09.2021 um 09:15 schrieb Michael Lawnick: Am 16.09.2021 um 09:12 schrieb AKASHI Takahiro: Please, as Heinrich suggested, add CONFIG_FS_FAT, in your U-Boot configuration. Hmm, I didn't understand that as a suggestion, but as a question for his understanding. Of course I'll give it a try. Sometimes live is such easy. This fixed my issue, THX. For the after-math / my understanding: - Do I understand correctly that the problem was that 'efi_selftest block device' requires FAT support? So shouldn't there be a dependency in CONFIG? Strictly speaking, CONFIG_EFI_LOADER requires FAT per UEFI specification, and actually it has 'imply FAT'. I don't know why Heinrich uses 'imply' instead of 'select'. - What is the reason/use to iterate through the recognized partitions even twice (in .setup and .execute) if they aren't needed/used? What line of code do you exactly mean by 'in .setup' (and in .execute)? My understanding: efi_selftests register their methods separated by setup/execute/teardown. The central test control is taking tests from list and executes the three methods, unaware of which exact test is executed: lib/efi_selftest/efi_selftest.c lib/efi_selftest/efi_selftest_block_device.c
Re: [PATCH v2] apalis/colibri_imx6: move setting bootcmd to defconfig
On Thu, 2021-09-16 at 11:54 +0300, Oleksandr Suvorov wrote: > Move setting the default boot command to the > apalis/colibri_imx6_defconfig. It allows replacing the command > without code modification. > > Signed-off-by: Oleksandr Suvorov > Reviewed-by: Peng Fan > Reviewed-by: Igor Opaniuk Acked-by: Marcel Ziswiler > --- > > Changes in v2: > - fix spaces after semicolon. > - add reviewed-by records. > > configs/apalis_imx6_defconfig | 1 + > configs/colibri_imx6_defconfig | 1 + > include/configs/apalis_imx6.h | 4 > include/configs/colibri_imx6.h | 4 > 4 files changed, 2 insertions(+), 8 deletions(-) > > diff --git a/configs/apalis_imx6_defconfig b/configs/apalis_imx6_defconfig > index a0e85ba23a4..f64b1ca4378 100644 > --- a/configs/apalis_imx6_defconfig > +++ b/configs/apalis_imx6_defconfig > @@ -23,6 +23,7 @@ CONFIG_DISTRO_DEFAULTS=y > CONFIG_FIT=y > CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" > CONFIG_BOOTDELAY=1 > +CONFIG_BOOTCOMMAND="run distro_bootcmd; usb start; setenv stdout > serial,vidconsole; setenv stdin > serial,usbkbd" > # CONFIG_DISPLAY_BOARDINFO is not set > CONFIG_DISPLAY_BOARDINFO_LATE=y > CONFIG_BOARD_EARLY_INIT_F=y > diff --git a/configs/colibri_imx6_defconfig b/configs/colibri_imx6_defconfig > index 47b1cfb1917..373d6476ddc 100644 > --- a/configs/colibri_imx6_defconfig > +++ b/configs/colibri_imx6_defconfig > @@ -22,6 +22,7 @@ CONFIG_DISTRO_DEFAULTS=y > CONFIG_FIT=y > CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" > CONFIG_BOOTDELAY=1 > +CONFIG_BOOTCOMMAND="run distro_bootcmd; usb start; setenv stdout > serial,vidconsole; setenv stdin > serial,usbkbd" > # CONFIG_DISPLAY_BOARDINFO is not set > CONFIG_DISPLAY_BOARDINFO_LATE=y > CONFIG_BOARD_EARLY_INIT_F=y > diff --git a/include/configs/apalis_imx6.h b/include/configs/apalis_imx6.h > index 12de0105c6c..ade479cb943 100644 > --- a/include/configs/apalis_imx6.h > +++ b/include/configs/apalis_imx6.h > @@ -133,10 +133,6 @@ > #endif > #define CONFIG_EXTRA_ENV_SETTINGS \ > BOOTENV \ > - "bootcmd=run distro_bootcmd ; " \ > - "usb start ; " \ > - "setenv stdout serial,vidconsole; " \ > - "setenv stdin serial,usbkbd\0" \ > "boot_file=zImage\0" \ > "console=ttymxc0\0" \ > "defargs=enable_wait_mode=off vmalloc=400M\0" \ > diff --git a/include/configs/colibri_imx6.h b/include/configs/colibri_imx6.h > index 804a144a03e..f91d6b49ea8 100644 > --- a/include/configs/colibri_imx6.h > +++ b/include/configs/colibri_imx6.h > @@ -115,10 +115,6 @@ > #define FDT_FILE "imx6dl-colibri-eval-v3.dtb" > #define CONFIG_EXTRA_ENV_SETTINGS \ > BOOTENV \ > - "bootcmd=run distro_bootcmd; " \ > - "usb start ; " \ > - "setenv stdout serial,vidconsole; " \ > - "setenv stdin serial,usbkbd\0" \ > "boot_file=zImage\0" \ > "console=ttymxc0\0" \ > "defargs=enable_wait_mode=off galcore.contiguousSize=50331648\0" \
[PATCH 1/1] fs: btrfs: avoid superfluous messages
Output like the following is quite irritating:
=> bootefi hello
Scanning disk mmc2.blk...
No valid Btrfs found
Bad magic number for SquashFS image.
** Unrecognized filesystem type **
Scanning disk mmc1.blk...
No valid Btrfs found
Bad magic number for SquashFS image.
** Unrecognized filesystem type **
Scanning disk mmc0.blk...
No valid Btrfs found
Bad magic number for SquashFS image.
** Unrecognized filesystem type **
It is expected that most partitions don't contain a Btrfs. This is only
worth a debug message.
Signed-off-by: Heinrich Schuchardt
---
fs/btrfs/disk-io.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 12f9579fcf..7a4fb0d259 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
#include
#include
+#include
#include
#include
#include "kernel-shared/btrfs_tree.h"
@@ -918,7 +919,7 @@ static int btrfs_scan_fs_devices(struct blk_desc *desc,
ret = btrfs_scan_one_device(desc, part, fs_devices, _devs);
if (ret) {
- fprintf(stderr, "No valid Btrfs found\n");
+ log_debug("No valid Btrfs found\n");
return ret;
}
return 0;
--
2.32.0
[PATCH 1/1] fs: avoid superfluous messages
Output like the following is quite irritating:
=> bootefi hello
Scanning disk mmc2.blk...
No valid Btrfs found
Bad magic number for SquashFS image.
** Unrecognized filesystem type **
Scanning disk mmc1.blk...
No valid Btrfs found
Bad magic number for SquashFS image.
** Unrecognized filesystem type **
Scanning disk mmc0.blk...
No valid Btrfs found
Bad magic number for SquashFS image.
** Unrecognized filesystem type **
It is expected that a whole disk (partition number 0) doesn't contain a
filesystem. Partitions may only contain a blob. This situation is only
worth a debug message.
Signed-off-by: Heinrich Schuchardt
---
fs/fs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/fs.c b/fs/fs.c
index 7c682582c8..023f89cafe 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -37,7 +37,7 @@ static int fs_type = FS_TYPE_ANY;
static inline int fs_probe_unsupported(struct blk_desc *fs_dev_desc,
struct disk_partition *fs_partition)
{
- log_err("** Unrecognized filesystem type **\n");
+ log_debug("Unrecognized filesystem type\n");
return -1;
}
--
2.32.0
Re: [PATCH 2/3] efi_loader: add UEFI GPT measurement
On Thu, 16 Sept 2021 at 16:29, Heinrich Schuchardt wrote:
>
>
>
> On 9/15/21 7:15 AM, Masahisa Kojima wrote:
> > This commit adds the UEFI GPT disk partition topology
> > measurement required in TCG PC Client PFP Spec.
>
> Thanks for looking into the missing parts of TCG measurement in U-Boot.
>
> The requirements in the TCG PC Client PFP Spec are strange. It does not
> explicitly say how to handle multiple block devices. Did the authors
> never enjoy the pleasure of a second disk drive?
Yes, I had same question of this GPT measurement required in TCG spec.
I refer EDK2 implementation, GPT is measured only once[*1].
[*1]
https://github.com/tianocore/edk2/blob/master/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c#L46
>
> With your implementation you would measure the GPT table of the SD-card
> from which you load Shim or GRUB but would not care about the GPT of the
> NVMe drive with your OS.
>
> A clarification by the TCG standards committee would be helpful.
We need to find the right person to access.
>
> After this series "10.2.7 DEVICE_SECURITY_EVENT_DATA Structure" still
> needs to be covered.
I'm trying to cover all "MUST" and non-platform specific requirement,
and this is completed with this patch series.
DEVICE_SECURITY_EVENT_DATA is "should" requirement.
In addition, DEVICE_SECURITY_EVENT_DATA is not implemented
in EDK2(but it is not the reason u-boot will not support this event anyway).
Thanks,
Masahisa Kojima
>
> Best regards
>
> Heinrich
>
> >
> > Signed-off-by: Masahisa Kojima
> > ---
> > include/blk.h | 3 +
> > include/efi_loader.h | 2 +-
> > include/efi_tcg2.h| 12 +++
> > lib/efi_loader/efi_boottime.c | 2 +-
> > lib/efi_loader/efi_tcg2.c | 175 +-
> > 5 files changed, 191 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/blk.h b/include/blk.h
> > index 19bab081c2..f0cc7ca1a2 100644
> > --- a/include/blk.h
> > +++ b/include/blk.h
> > @@ -45,6 +45,9 @@ enum if_type {
> > #define BLK_PRD_SIZE20
> > #define BLK_REV_SIZE8
> >
> > +#define PART_FORMAT_PCAT 0x1
> > +#define PART_FORMAT_GPT 0x2
> > +
> > /*
> >* Identifies the partition table type (ie. MBR vs GPT GUID) signature
> >*/
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index 13f0c24058..dbcc296e01 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -503,7 +503,7 @@ efi_status_t efi_init_variables(void);
> > void efi_variables_boot_exit_notify(void);
> > efi_status_t efi_tcg2_notify_exit_boot_services_failed(void);
> > /* Measure efi application invocation */
> > -efi_status_t efi_tcg2_measure_efi_app_invocation(void);
> > +efi_status_t efi_tcg2_measure_efi_app_invocation(struct
> > efi_loaded_image_obj *handle);
> > /* Measure efi application exit */
> > efi_status_t efi_tcg2_measure_efi_app_exit(void);
> > /* Called by bootefi to initialize root node */
> > diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
> > index da33f8a1d0..33257fa96b 100644
> > --- a/include/efi_tcg2.h
> > +++ b/include/efi_tcg2.h
> > @@ -230,6 +230,18 @@ struct smbios_handoff_table_pointers2 {
> > struct efi_configuration_table table_entry[1];
> > } __packed;
> >
> > +/**
> > + * struct tdUEFI_GPT_DATA - event log structure of industry standard tables
> > + * @uefi_partition_header: gpt partition header
> > + * @number_of_partitions:the number of partition
> > + * @partitions: partition entries
> > + */
> > +struct efi_gpt_data {
> > + gpt_header uefi_partition_header;
> > + u64 number_of_partitions;
> > + gpt_entry partitions[];
> > +} __packed;
> > +
> > struct efi_tcg2_protocol {
> > efi_status_t (EFIAPI * get_capability)(struct efi_tcg2_protocol *this,
> > struct
> > efi_tcg2_boot_service_capability *capability);
> > diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> > index 701e2212c8..bf5661e1ee 100644
> > --- a/lib/efi_loader/efi_boottime.c
> > +++ b/lib/efi_loader/efi_boottime.c
> > @@ -3003,7 +3003,7 @@ efi_status_t EFIAPI efi_start_image(efi_handle_t
> > image_handle,
> >
> > if (IS_ENABLED(CONFIG_EFI_TCG2_PROTOCOL)) {
> > if (image_obj->image_type == IMAGE_SUBSYSTEM_EFI_APPLICATION)
> > {
> > - ret = efi_tcg2_measure_efi_app_invocation();
> > + ret = efi_tcg2_measure_efi_app_invocation(image_obj);
> > if (ret != EFI_SUCCESS) {
> > log_warning("tcg2 measurement fails(0x%lx)\n",
> > ret);
> > diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
> > index 7f47998a55..35810615ed 100644
> > --- a/lib/efi_loader/efi_tcg2.c
> > +++ b/lib/efi_loader/efi_tcg2.c
> > @@ -1525,12 +1525,181 @@ static void
Re: [PATCH v3 1/2] GPIO: fxl6408: Add support for FXL6408 GPIO expander
i Michal,
On Thu, Sep 16, 2021 at 10:05 AM Michal Simek wrote:
>
>
>
> On 9/15/21 8:35 PM, Oleksandr Suvorov wrote:
> > Hi Michal,
> >
> > On Fri, Sep 10, 2021 at 9:35 AM Michal Simek
> > wrote:
> >>
> >>
> >>
> >> On 9/9/21 10:44 PM, Oleksandr Suvorov wrote:
> >>> From: Oleksandr Suvorov
> >>>
> >>> Initial support for Fairchild's 8 bit I2C gpio expander FXL6408.
> >>> The CONFIG_FXL6408_GPIO define enables support for such devices.
> >>>
> >>> Based on: https://patchwork.kernel.org/patch/9148419/
> >>>
> >>> Signed-off-by: Oleksandr Suvorov
> >>> Reviewed-by: Simon Glass
> >>> Tested-by: Marcel Ziswiler
> >>> Signed-off-by: Oleksandr Suvorov
> >>> Signed-off-by: Oleksandr Suvorov
> >>
> >> 3 emails for you. Would be the best to choose only one.
> >
> > Thanks, fixed. That habit to always add '-s' when committing changes :)
> >>
> >>> ---
> >>>
> >>> Changes in v3:
> >>> - fix a warning:
> >>> ...drivers/gpio/gpio-fxl6408.c:348:15: warning: format ‘%ld’
> >>> expects argument of type ‘long int’, but argument 3 has
> >>> type ‘int’ [-Wformat=]...
> >>> - add Tested-by record.
> >>>
> >>> drivers/gpio/Kconfig| 7 +
> >>> drivers/gpio/Makefile | 1 +
> >>> drivers/gpio/gpio-fxl6408.c | 366
> >>> 3 files changed, 374 insertions(+)
> >>> create mode 100644 drivers/gpio/gpio-fxl6408.c
> >>>
> >>> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> >>> index 4a89c1a62b..f56e4cc261 100644
> >>> --- a/drivers/gpio/Kconfig
> >>> +++ b/drivers/gpio/Kconfig
> >>> @@ -123,6 +123,13 @@ config DA8XX_GPIO
> >>> help
> >>> This driver supports the DA8xx GPIO controller
> >>>
> >>> +config FXL6408_GPIO
> >>> + bool "FXL6408 I2C GPIO expander driver"
> >>> + depends on DM_GPIO && DM_I2C
> >>> + help
> >>> + This driver supports the Fairchild FXL6408 device. FXL6408 is a
> >>> + fully configurable 8-bit I2C-controlled GPIO expander.
> >>> +
> >>> config INTEL_BROADWELL_GPIO
> >>> bool "Intel Broadwell GPIO driver"
> >>> depends on DM
> >>> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> >>> index 58f4704f6b..83d8b5c9d8 100644
> >>> --- a/drivers/gpio/Makefile
> >>> +++ b/drivers/gpio/Makefile
> >>> @@ -16,6 +16,7 @@ obj-$(CONFIG_AT91_GPIO) += at91_gpio.o
> >>> obj-$(CONFIG_ATMEL_PIO4) += atmel_pio4.o
> >>> obj-$(CONFIG_BCM6345_GPIO) += bcm6345_gpio.o
> >>> obj-$(CONFIG_CORTINA_GPIO) += cortina_gpio.o
> >>> +obj-$(CONFIG_FXL6408_GPIO) += gpio-fxl6408.o
> >>> obj-$(CONFIG_INTEL_GPIO) += intel_gpio.o
> >>> obj-$(CONFIG_INTEL_ICH6_GPIO)+= intel_ich6_gpio.o
> >>> obj-$(CONFIG_INTEL_BROADWELL_GPIO) += intel_broadwell_gpio.o
> >>> diff --git a/drivers/gpio/gpio-fxl6408.c b/drivers/gpio/gpio-fxl6408.c
> >>> new file mode 100644
> >>> index 00..dbc68618f9
> >>> --- /dev/null
> >>> +++ b/drivers/gpio/gpio-fxl6408.c
> >>> @@ -0,0 +1,366 @@
> >>> +// SPDX-License-Identifier: GPL-2.0
> >>> +/*
> >>> + * Copyright (C) 2021 Toradex
> >>> + * Copyright (C) 2016 Broadcom
> >>> + */
> >>> +
> >>> +/**
> >>
> >> Below is not kernel-doc format
> >
> > I don't think so. And without formatting comments of this block as a
> > kernel-doc, the kernel-doc tool shows the warning:
> > drivers/gpio/gpio-fxl6408.c:1: warning: no structured comments found
>
> Because script only checks format starting with /**.
Sure, missed that "little" thing :) Thanks!
>
>
>
> >>> +};
> >>> +
> >>> +/*
> >>
> >> /** this should be kernel doc.
> >>
> >> Run this
> >> ./scripts/kernel-doc -man -v 1>/dev/null *.c
> >>
> >> to check that all values are right.
> >
> > The kernel-doc doesn't found errors.
>
> Because it doesn't find any structure to check. Add here /** and run
> that script again.
>
> >
> >>> + * struct fxl6408_info - Data for fxl6408
> >>> + *
> >>> + * @dev: udevice structure for the device
> >>> + * @addr: i2c slave address
> >>> + * @reg_io_dir: hold the value of direction register
> >>> + * @reg_output: hold the value of output register
> >>> + */
> >>> +struct fxl6408_info {
> >>> + struct udevice *dev;
> >>> + int addr;
> >>> + u8 device_id;
> >>> + u8 reg_io_dir;
> >>> + u8 reg_output;
> >>> +};
> >>> +
> >>> +static inline int fxl6408_write(struct udevice *dev, int reg, u8 val)
> >>> +{
> >>> + return dm_i2c_write(dev, reg, , 1);
> >>> +}
> >>> +
> >>> +static int fxl6408_read(struct udevice *dev, int reg)
> >>> +{
> >>> + int ret;
> >>> + u8 tmp;
> >>> +
> >>> + ret = dm_i2c_read(dev, reg, , 1);
> >>> + if (!ret)
> >>> + ret = tmp;
> >>
> >> This looks completely wrong. What value are you returning in case of error.
> >
> > Nope. In case of error, I return an error value stored in "ret".
> >
> >> If ops->xfer is not defined dm_i2c_read returns -ENOSYS. tmp is not
> >> initialized and can have random value that's why here in case or error
> >> you will return ramdom value.
> >
> > !(-ENOSYS) == false,
[PATCH next v4 08/11] ast2600: spl: Locate load buffer in DRAM space
Return CONFIG_SYS_LOAD_ADDR pointing to DRAM space for
spl_get_load_buffer() to allow generic SPL image loading
code (e.g. FIT and Ymodem) to store data in DRAM.
Signed-off-by: Chia-Wei Wang
---
arch/arm/mach-aspeed/ast2600/spl.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/arm/mach-aspeed/ast2600/spl.c
b/arch/arm/mach-aspeed/ast2600/spl.c
index 0d8cb29678..6c49d6aede 100644
--- a/arch/arm/mach-aspeed/ast2600/spl.c
+++ b/arch/arm/mach-aspeed/ast2600/spl.c
@@ -28,14 +28,7 @@ u32 spl_boot_device(void)
struct image_header *spl_get_load_buffer(ssize_t offset, size_t size)
{
- /*
-* When boot from SPI, AST2600 already remap 0x ~ 0x0fff
-* to BMC SPI memory space 0x2000 ~ 0x2fff. The next stage BL
-* has been located in SPI for XIP. In this case, the load buffer for
-* SPL image loading will be set to the remapped address of the next
-* BL instead of the DRAM space CONFIG_SYS_LOAD_ADDR
-*/
- return (struct image_header *)(CONFIG_SYS_TEXT_BASE);
+ return (struct image_header *)(CONFIG_SYS_LOAD_ADDR);
}
#ifdef CONFIG_SPL_OS_BOOT
--
2.17.1
[PATCH next v4 07/11] ARM: dts: ast2600: Add ACRY to device tree
Add ACRY DTS node and enable it for AST2600 EVB.
Signed-off-by: Chia-Wei Wang
---
arch/arm/dts/ast2600-evb.dts | 5 +
arch/arm/dts/ast2600.dtsi| 9 +
2 files changed, 14 insertions(+)
diff --git a/arch/arm/dts/ast2600-evb.dts b/arch/arm/dts/ast2600-evb.dts
index adb80a30ef..05362d19bd 100644
--- a/arch/arm/dts/ast2600-evb.dts
+++ b/arch/arm/dts/ast2600-evb.dts
@@ -182,3 +182,8 @@
u-boot,dm-pre-reloc;
status = "okay";
};
+
+ {
+ u-boot,dm-pre-reloc;
+ status = "okay";
+};
diff --git a/arch/arm/dts/ast2600.dtsi b/arch/arm/dts/ast2600.dtsi
index 642206fb77..0103e93573 100644
--- a/arch/arm/dts/ast2600.dtsi
+++ b/arch/arm/dts/ast2600.dtsi
@@ -195,6 +195,15 @@
status = "disabled";
};
+ acry: acry@1e6fa000 {
+ compatible = "aspeed,ast2600-acry";
+ reg = <0x1e6fa000 0x1000>,
+ <0x1e71 0x1>;
+ interrupts = ;
+ clocks = < ASPEED_CLK_GATE_RSACLK>;
+ status = "disabled";
+ };
+
edac: sdram@1e6e {
compatible = "aspeed,ast2600-sdram-edac";
reg = <0x1e6e 0x174>;
--
2.17.1
[PATCH next v4 06/11] crypto: aspeed: Add AST2600 ACRY support
ACRY is deisnged to accerlerate ECC/RSA digital signature
generation and verification.
Signed-off-by: Chia-Wei Wang
---
drivers/crypto/aspeed/Kconfig | 10 ++
drivers/crypto/aspeed/Makefile | 1 +
drivers/crypto/aspeed/aspeed_acry.c | 182
lib/rsa/Kconfig | 10 +-
4 files changed, 202 insertions(+), 1 deletion(-)
create mode 100644 drivers/crypto/aspeed/aspeed_acry.c
diff --git a/drivers/crypto/aspeed/Kconfig b/drivers/crypto/aspeed/Kconfig
index 471c06f986..9bf317177a 100644
--- a/drivers/crypto/aspeed/Kconfig
+++ b/drivers/crypto/aspeed/Kconfig
@@ -8,3 +8,13 @@ config ASPEED_HACE
Enabling this allows the use of SHA operations in hardware without
requiring the SHA software implementations. It also improves
performance
and saves code size.
+
+config ASPEED_ACRY
+ bool "ASPEED RSA and ECC Engine"
+ depends on ASPEED_AST2600
+ help
+Select this option to enable a driver for using the RSA/ECC engine in
+the ASPEED BMC SoCs.
+
+Enabling this allows the use of RSA/ECC operations in hardware without
requiring the
+software implementations. It also improves performance and saves code
size.
diff --git a/drivers/crypto/aspeed/Makefile b/drivers/crypto/aspeed/Makefile
index 84e6bfe82a..58b55fc46e 100644
--- a/drivers/crypto/aspeed/Makefile
+++ b/drivers/crypto/aspeed/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_ASPEED_HACE) += aspeed_hace.o
+obj-$(CONFIG_ASPEED_ACRY) += aspeed_acry.o
diff --git a/drivers/crypto/aspeed/aspeed_acry.c
b/drivers/crypto/aspeed/aspeed_acry.c
new file mode 100644
index 00..0b948f828a
--- /dev/null
+++ b/drivers/crypto/aspeed/aspeed_acry.c
@@ -0,0 +1,182 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright 2021 ASPEED Technology Inc.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* ACRY register offsets */
+#define ACRY_CTRL1 0x00
+#define ACRY_CTRL1_RSA_DMA BIT(1)
+#define ACRY_CTRL1_RSA_START BIT(0)
+#define ACRY_CTRL2 0x44
+#define ACRY_CTRL3 0x48
+#define ACRY_CTRL3_SRAM_AHB_ACCESS BIT(8)
+#define ACRY_CTRL3_ECC_RSA_MODE_MASK GENMASK(5, 4)
+#define ACRY_CTRL3_ECC_RSA_MODE_SHIFT4
+#define ACRY_DMA_DRAM_SADDR0x4c
+#define ACRY_DMA_DMEM_TADDR0x50
+#define ACRY_DMA_DMEM_TADDR_LEN_MASK GENMASK(15, 0)
+#define ACRY_DMA_DMEM_TADDR_LEN_SHIFT0
+#define ACRY_RSA_PARAM 0x58
+#define ACRY_RSA_PARAM_EXP_MASK GENMASK(31, 16)
+#define ACRY_RSA_PARAM_EXP_SHIFT 16
+#define ACRY_RSA_PARAM_MOD_MASK GENMASK(15, 0)
+#define ACRY_RSA_PARAM_MOD_SHIFT 0
+#define ACRY_RSA_INT_EN0x3f8
+#define ACRY_RSA_INT_EN_RSA_READYBIT(2)
+#define ACRY_RSA_INT_EN_RSA_CMPLTBIT(1)
+#define ACRY_RSA_INT_STS 0x3fc
+#define ACRY_RSA_INT_STS_RSA_READY BIT(2)
+#define ACRY_RSA_INT_STS_RSA_CMPLT BIT(1)
+
+/* misc. constant */
+#define ACRY_ECC_MODE 2
+#define ACRY_RSA_MODE 3
+#define ACRY_CTX_BUFSZ 0x600
+
+struct aspeed_acry {
+ phys_addr_t base;
+ phys_addr_t sram_base; /* internal sram */
+ struct clk clk;
+};
+
+static int aspeed_acry_mod_exp(struct udevice *dev, const uint8_t *sig,
uint32_t sig_len,
+ struct key_prop *prop, uint8_t *out)
+{
+ int i, j;
+ u8 *ctx;
+ u8 *ptr;
+ u32 reg;
+ struct aspeed_acry *acry = dev_get_priv(dev);
+
+ ctx = memalign(16, ACRY_CTX_BUFSZ);
+ if (!ctx)
+ return -ENOMEM;
+
+ memset(ctx, 0, ACRY_CTX_BUFSZ);
+
+ ptr = (u8 *)prop->public_exponent;
+ for (i = prop->exp_len - 1, j = 0; i >= 0; --i) {
+ ctx[j] = ptr[i];
+ j++;
+ j = (j % 16) ? j : j + 32;
+ }
+
+ ptr = (u8 *)prop->modulus;
+ for (i = (prop->num_bits >> 3) - 1, j = 0; i >= 0; --i) {
+ ctx[j + 16] = ptr[i];
+ j++;
+ j = (j % 16) ? j : j + 32;
+ }
+
+ ptr = (u8 *)sig;
+ for (i = sig_len - 1, j = 0; i >= 0; --i) {
+ ctx[j + 32] = ptr[i];
+ j++;
+ j = (j % 16) ? j : j + 32;
+ }
+
+ writel((u32)ctx, acry->base + ACRY_DMA_DRAM_SADDR);
+
+ reg = (((prop->exp_len << 3) << ACRY_RSA_PARAM_EXP_SHIFT) &
ACRY_RSA_PARAM_EXP_MASK) |
+ ((prop->num_bits << ACRY_RSA_PARAM_MOD_SHIFT) &
ACRY_RSA_PARAM_MOD_MASK);
+ writel(reg, acry->base + ACRY_RSA_PARAM);
+
+ reg = (ACRY_CTX_BUFSZ << ACRY_DMA_DMEM_TADDR_LEN_SHIFT) &
ACRY_DMA_DMEM_TADDR_LEN_MASK;
+ writel(reg, acry->base + ACRY_DMA_DMEM_TADDR);
+
+ reg = (ACRY_RSA_MODE << ACRY_CTRL3_ECC_RSA_MODE_SHIFT) &
ACRY_CTRL3_ECC_RSA_MODE_MASK;
+ writel(reg, acry->base + ACRY_CTRL3);
+
+ writel(ACRY_CTRL1_RSA_DMA | ACRY_CTRL1_RSA_START, acry->base +
ACRY_CTRL1);
+
[PATCH next v4 11/11] configs: ast2600: Boot kernel FIT in DRAM
AST2600 leverages the FIT hash/signature verification to fulfill
secure boot trust chain. To improve the performance and save SW
code size for those crypto operations, the two HW crypto engine,
HACE and ACRY, are enabled.
However, both of the engines can only access to data stored in
DRAM space. Therefore, we need to move the FIT image into DRAM
before the booting.
This patch update the CONFIG_BOOTCOMMAND to execute the pre-defined
ENV variable which consists of FIT image copy to memory and booting.
Signed-off-by: Chia-Wei Wang
---
configs/evb-ast2600_defconfig | 2 +-
include/configs/evb_ast2600.h | 7 +++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
index eba6940ec1..abb156f13e 100644
--- a/configs/evb-ast2600_defconfig
+++ b/configs/evb-ast2600_defconfig
@@ -27,7 +27,7 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x1
CONFIG_USE_BOOTARGS=y
CONFIG_BOOTARGS="console=ttyS4,115200n8 root=/dev/ram rw"
CONFIG_USE_BOOTCOMMAND=y
-CONFIG_BOOTCOMMAND="bootm 2010"
+CONFIG_BOOTCOMMAND="run bootspi"
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y
CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y
diff --git a/include/configs/evb_ast2600.h b/include/configs/evb_ast2600.h
index d2aceb6663..83002db317 100644
--- a/include/configs/evb_ast2600.h
+++ b/include/configs/evb_ast2600.h
@@ -14,7 +14,14 @@
#define CONFIG_SYS_LOAD_ADDR 0x8300
/* Misc */
+#define STR_HELPER(s) #s
+#define STR(s) STR_HELPER(s)
+
#define CONFIG_EXTRA_ENV_SETTINGS \
+ "loadaddr=" STR(CONFIG_SYS_LOAD_ADDR) "\0" \
+ "bootspi=fdt addr 2010 && fdt header get fitsize totalsize && " \
+ "cp.b 2010 ${loadaddr} ${fitsize} && bootm; " \
+ "echo Error loading kernel FIT image\0" \
"verify=yes\0" \
"spi_dma=yes\0" \
""
--
2.17.1
[PATCH next v4 09/11] configs: ast2600-evb: Enable SPL FIT support
Enable SPL FIT image load and verification support. The HW accelerated SHA is also available with the newly added support of the HACE HW hash engine. The SPL thumb build is also enabled to keep the binary less than 64KB to fit into the Aspeed secure boot design. Signed-off-by: Chia-Wei Wang --- configs/evb-ast2600_defconfig | 20 +--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig index 56ab885d9b..eba6940ec1 100644 --- a/configs/evb-ast2600_defconfig +++ b/configs/evb-ast2600_defconfig @@ -1,7 +1,8 @@ CONFIG_ARM=y CONFIG_SYS_DCACHE_OFF=y +CONFIG_SPL_SYS_THUMB_BUILD=y CONFIG_ARCH_ASPEED=y -CONFIG_SYS_TEXT_BASE=0x1 +CONFIG_SYS_TEXT_BASE=0x8000 CONFIG_ASPEED_AST2600=y CONFIG_TARGET_EVB_AST2600=y CONFIG_SPL_LIBCOMMON_SUPPORT=y @@ -12,13 +13,17 @@ CONFIG_ENV_SIZE=0x1 CONFIG_SYS_MALLOC_LEN=0x200 CONFIG_DEFAULT_DEVICE_TREE="ast2600-evb" CONFIG_SPL_SERIAL=y +CONFIG_SPL_STACK_R_ADDR=0x8300 CONFIG_SPL_SIZE_LIMIT=0x1 CONFIG_SPL=y # CONFIG_ARMV7_NONSEC is not set # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_SYS_LOAD_ADDR=0x8300 CONFIG_FIT=y -# CONFIG_LEGACY_IMAGE_FORMAT is not set +CONFIG_SPL_FIT_SIGNATURE=y +CONFIG_SPL_LOAD_FIT=y +CONFIG_SPL_LOAD_FIT_ADDRESS=0x1 +# CONFIG_USE_SPL_FIT_GENERATOR is not set CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyS4,115200n8 root=/dev/ram rw" CONFIG_USE_BOOTCOMMAND=y @@ -26,8 +31,10 @@ CONFIG_BOOTCOMMAND="bootm 2010" # CONFIG_DISPLAY_CPUINFO is not set CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y -# CONFIG_SPL_LEGACY_IMAGE_SUPPORT is not set CONFIG_SPL_SYS_MALLOC_SIMPLE=y +CONFIG_SPL_STACK_R=y +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x200 +CONFIG_SPL_FIT_IMAGE_TINY=y CONFIG_SPL_DM_RESET=y CONFIG_SPL_RAM_SUPPORT=y CONFIG_SPL_RAM_DEVICE=y @@ -47,6 +54,9 @@ CONFIG_REGMAP=y CONFIG_SPL_OF_TRANSLATE=y CONFIG_CLK=y CONFIG_SPL_CLK=y +CONFIG_DM_HASH=y +CONFIG_HASH_ASPEED=y +CONFIG_ASPEED_ACRY=y CONFIG_DM_I2C=y CONFIG_MISC=y CONFIG_SPL_MISC=y @@ -65,5 +75,9 @@ CONFIG_SYS_NS16550=y CONFIG_SYSRESET=y CONFIG_SPL_SYSRESET=y CONFIG_WDT=y +CONFIG_SHA512_ALGO=y +CONFIG_SHA512=y +CONFIG_SHA384=y CONFIG_HEXDUMP=y # CONFIG_EFI_LOADER is not set +CONFIG_PHANDLE_CHECK_SEQ=y -- 2.17.1
[PATCH v2] apalis/colibri_imx6: move setting bootcmd to defconfig
Move setting the default boot command to the apalis/colibri_imx6_defconfig. It allows replacing the command without code modification. Signed-off-by: Oleksandr Suvorov Reviewed-by: Peng Fan Reviewed-by: Igor Opaniuk --- Changes in v2: - fix spaces after semicolon. - add reviewed-by records. configs/apalis_imx6_defconfig | 1 + configs/colibri_imx6_defconfig | 1 + include/configs/apalis_imx6.h | 4 include/configs/colibri_imx6.h | 4 4 files changed, 2 insertions(+), 8 deletions(-) diff --git a/configs/apalis_imx6_defconfig b/configs/apalis_imx6_defconfig index a0e85ba23a4..f64b1ca4378 100644 --- a/configs/apalis_imx6_defconfig +++ b/configs/apalis_imx6_defconfig @@ -23,6 +23,7 @@ CONFIG_DISTRO_DEFAULTS=y CONFIG_FIT=y CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" CONFIG_BOOTDELAY=1 +CONFIG_BOOTCOMMAND="run distro_bootcmd; usb start; setenv stdout serial,vidconsole; setenv stdin serial,usbkbd" # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_BOARD_EARLY_INIT_F=y diff --git a/configs/colibri_imx6_defconfig b/configs/colibri_imx6_defconfig index 47b1cfb1917..373d6476ddc 100644 --- a/configs/colibri_imx6_defconfig +++ b/configs/colibri_imx6_defconfig @@ -22,6 +22,7 @@ CONFIG_DISTRO_DEFAULTS=y CONFIG_FIT=y CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" CONFIG_BOOTDELAY=1 +CONFIG_BOOTCOMMAND="run distro_bootcmd; usb start; setenv stdout serial,vidconsole; setenv stdin serial,usbkbd" # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_BOARD_EARLY_INIT_F=y diff --git a/include/configs/apalis_imx6.h b/include/configs/apalis_imx6.h index 12de0105c6c..ade479cb943 100644 --- a/include/configs/apalis_imx6.h +++ b/include/configs/apalis_imx6.h @@ -133,10 +133,6 @@ #endif #define CONFIG_EXTRA_ENV_SETTINGS \ BOOTENV \ - "bootcmd=run distro_bootcmd ; " \ - "usb start ; " \ - "setenv stdout serial,vidconsole; " \ - "setenv stdin serial,usbkbd\0" \ "boot_file=zImage\0" \ "console=ttymxc0\0" \ "defargs=enable_wait_mode=off vmalloc=400M\0" \ diff --git a/include/configs/colibri_imx6.h b/include/configs/colibri_imx6.h index 804a144a03e..f91d6b49ea8 100644 --- a/include/configs/colibri_imx6.h +++ b/include/configs/colibri_imx6.h @@ -115,10 +115,6 @@ #define FDT_FILE "imx6dl-colibri-eval-v3.dtb" #define CONFIG_EXTRA_ENV_SETTINGS \ BOOTENV \ - "bootcmd=run distro_bootcmd; " \ - "usb start ; " \ - "setenv stdout serial,vidconsole; " \ - "setenv stdin serial,usbkbd\0" \ "boot_file=zImage\0" \ "console=ttymxc0\0" \ "defargs=enable_wait_mode=off galcore.contiguousSize=50331648\0" \ -- 2.31.1
[PATCH next v4 10/11] configs: aspeed: Make EXTRA_ENV_SETTINGS board specific
Move CONFIG_EXTRA_ENV_SETTINGS to board-specific configuration headers. Signed-off-by: Chia-Wei Wang --- include/configs/aspeed-common.h | 9 - include/configs/evb_ast2500.h | 9 + include/configs/evb_ast2600.h | 9 + 3 files changed, 18 insertions(+), 9 deletions(-) diff --git a/include/configs/aspeed-common.h b/include/configs/aspeed-common.h index 5177bf20fa..96526e1a75 100644 --- a/include/configs/aspeed-common.h +++ b/include/configs/aspeed-common.h @@ -38,13 +38,4 @@ */ #define CONFIG_BOOTP_BOOTFILESIZE -/* - * Miscellaneous configurable options - */ - -#define CONFIG_EXTRA_ENV_SETTINGS \ - "verify=yes\0" \ - "spi_dma=yes\0" \ - "" - #endif /* __AST_COMMON_CONFIG_H */ diff --git a/include/configs/evb_ast2500.h b/include/configs/evb_ast2500.h index dc032c1a41..a886fd941e 100644 --- a/include/configs/evb_ast2500.h +++ b/include/configs/evb_ast2500.h @@ -13,4 +13,13 @@ #define CONFIG_SYS_UBOOT_BASE CONFIG_SYS_TEXT_BASE +/* Memory Info */ +#define CONFIG_SYS_LOAD_ADDR 0x8300 + +/* Misc */ +#define CONFIG_EXTRA_ENV_SETTINGS \ + "verify=yes\0" \ + "spi_dma=yes\0" \ + "" + #endif /* __CONFIG_H */ diff --git a/include/configs/evb_ast2600.h b/include/configs/evb_ast2600.h index 177a52eb91..d2aceb6663 100644 --- a/include/configs/evb_ast2600.h +++ b/include/configs/evb_ast2600.h @@ -10,4 +10,13 @@ #define CONFIG_SYS_UBOOT_BASE CONFIG_SYS_TEXT_BASE +/* Memory Info */ +#define CONFIG_SYS_LOAD_ADDR 0x8300 + +/* Misc */ +#define CONFIG_EXTRA_ENV_SETTINGS \ + "verify=yes\0" \ + "spi_dma=yes\0" \ + "" + #endif /* __CONFIG_H */ -- 2.17.1
[PATCH 3/3] efi_selftest: Recieve the packets until the receive buffer is empty
Repeatedly receive the packets until the receive buffer is empty.
If the buffer is empty, EFI_SIMPLE_NETWORK_PROTOCOL::Receive()
returns EFI_NOT_READY. We don't need to use the wait_for_event()
every time.
Signed-off-by: Masami Hiramatsu
---
lib/efi_selftest/efi_selftest_snp.c | 67 +++
1 file changed, 37 insertions(+), 30 deletions(-)
diff --git a/lib/efi_selftest/efi_selftest_snp.c
b/lib/efi_selftest/efi_selftest_snp.c
index c5366c872c..818cbfcacd 100644
--- a/lib/efi_selftest/efi_selftest_snp.c
+++ b/lib/efi_selftest/efi_selftest_snp.c
@@ -362,39 +362,46 @@ static int execute(void)
continue;
}
/*
-* Receive packet
+* Receive packets until buffer is empty
*/
- buffer_size = sizeof(buffer);
- ret = net->receive(net, NULL, _size, ,
- , , NULL);
- if (ret != EFI_SUCCESS) {
- efi_st_error("Failed to receive packet");
- return EFI_ST_FAILURE;
+ for (;;) {
+ buffer_size = sizeof(buffer);
+ ret = net->receive(net, NULL, _size, ,
+ , , NULL);
+ if (ret == EFI_NOT_READY) {
+ /* The received buffer is empty. */
+ break;
+ }
+
+ if (ret != EFI_SUCCESS) {
+ efi_st_error("Failed to receive packet");
+ return EFI_ST_FAILURE;
+ }
+ /*
+* Check the packet is meant for this system.
+* Unfortunately QEMU ignores the broadcast flag.
+* So we have to check for broadcasts too.
+*/
+ if (memcmp(, >mode->current_address,
ARP_HLEN) &&
+ memcmp(, BROADCAST_MAC, ARP_HLEN))
+ continue;
+ /*
+* Check this is a DHCP reply
+*/
+ if (buffer.p.eth_hdr.et_protlen != ntohs(PROT_IP) ||
+ buffer.p.ip_udp.ip_hl_v != 0x45 ||
+ buffer.p.ip_udp.ip_p != IPPROTO_UDP ||
+ buffer.p.ip_udp.udp_src != ntohs(67) ||
+ buffer.p.ip_udp.udp_dst != ntohs(68) ||
+ buffer.p.dhcp_hdr.op != BOOTREPLY)
+ continue;
+ /*
+* We successfully received a DHCP reply.
+*/
+ goto received;
}
- /*
-* Check the packet is meant for this system.
-* Unfortunately QEMU ignores the broadcast flag.
-* So we have to check for broadcasts too.
-*/
- if (memcmp(, >mode->current_address, ARP_HLEN) &&
- memcmp(, BROADCAST_MAC, ARP_HLEN))
- continue;
- /*
-* Check this is a DHCP reply
-*/
- if (buffer.p.eth_hdr.et_protlen != ntohs(PROT_IP) ||
- buffer.p.ip_udp.ip_hl_v != 0x45 ||
- buffer.p.ip_udp.ip_p != IPPROTO_UDP ||
- buffer.p.ip_udp.udp_src != ntohs(67) ||
- buffer.p.ip_udp.udp_dst != ntohs(68) ||
- buffer.p.dhcp_hdr.op != BOOTREPLY)
- continue;
- /*
-* We successfully received a DHCP reply.
-*/
- break;
}
-
+received:
/*
* Write a log message.
*/
[PATCH 0/3] efi_selftest: Update SIMPLE_NETWORK_PROTOCOL selftest
Hello Heinrich,
Here is a series of patches to update the SIMPLE_NETWORK_PROTOCOL
according to the explanation in the previous thread [1].
[1] https://lists.denx.de/pipermail/u-boot/2021-September/460711.html
So basically this seires modifies the SNP testcase as I said
in the previous mail [1].
net->get_status();
if (!net->mode.MediaPresent) {
error(no link up!)
return;
}
submit_dhcp_discover()
for (;;) {
wait_for_event(net)
while (net->receive() != EFI_NOT_READY) {
// check dhcp reply
}
}
I removed EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT check because
that is just expectation what the received packet avaiability
is meaning that the EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT flag
bit is set. Of course U-Boot EFI SNP implementation does it,
but that is not ensured in the UEFI spec. The spec said that
the get_status() should update the MediaPresent flag (which
means the network link up or down). So I added the get_status()
test case before starting the network test so that it can
test the link status.
BTW, actually the mode->media_present is not supported yet.
Is there any way to get the network link status?
Thank you,
---
Masami Hiramatsu (3):
efi_selftest: Use EFI_SIMPLE_NETWORK_PROTOCOL::GetStatus() for media check
efi_selftest: Do not check EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT
efi_selftest: Recieve the packets until the receive buffer is empty
lib/efi_selftest/efi_selftest_snp.c | 90 +++
1 file changed, 49 insertions(+), 41 deletions(-)
--
Masami Hiramatsu
[PATCH 2/3] efi_selftest: Do not check EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT
Do not check EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT in packet
receiving loop. This depends on the implementation and not
related to whether the packet can be received or not.
Whether the received packets are available or not is ensured
by wait_for_packet, and that is already done in the loop.
Signed-off-by: Masami Hiramatsu
---
lib/efi_selftest/efi_selftest_snp.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/lib/efi_selftest/efi_selftest_snp.c
b/lib/efi_selftest/efi_selftest_snp.c
index cb0db7eea2..c5366c872c 100644
--- a/lib/efi_selftest/efi_selftest_snp.c
+++ b/lib/efi_selftest/efi_selftest_snp.c
@@ -340,8 +340,6 @@ static int execute(void)
events[0] = timer;
events[1] = net->wait_for_packet;
for (;;) {
- u32 int_status;
-
/*
* Wait for packet to be received or timer event.
*/
@@ -367,15 +365,6 @@ static int execute(void)
* Receive packet
*/
buffer_size = sizeof(buffer);
- ret = net->get_status(net, _status, NULL);
- if (ret != EFI_SUCCESS) {
- efi_st_error("Failed to get status");
- return EFI_ST_FAILURE;
- }
- if (!(int_status & EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT)) {
- efi_st_error("RX interrupt not set");
- return EFI_ST_FAILURE;
- }
ret = net->receive(net, NULL, _size, ,
, , NULL);
if (ret != EFI_SUCCESS) {
Re: [PATCH 3/3] efi_loader: add DeployedMode and AuditMode variable measurement
On 9/15/21 7:15 AM, Masahisa Kojima wrote:
This commit adds the DeployedMode and AuditMode variable
measurement required in TCG PC Client PFP Spec.
Signed-off-by: Masahisa Kojima
---
lib/efi_loader/efi_tcg2.c | 47 +++
1 file changed, 47 insertions(+)
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 35810615ed..427d6e22b1 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1828,6 +1829,50 @@ out:
return ret;
}
+/**
+ * tcg2_measure_deployed_audit_mode() - measure deployedmode and auditmode
+ *
+ * @dev: TPM device
+ *
+ * Return: status code
+ */
+static efi_status_t tcg2_measure_deployed_audit_mode(struct udevice *dev)
+{
+ u8 deployed_mode;
+ u8 audit_mode;
+ efi_uintn_t size;
+ efi_status_t ret;
+ u32 pcr_index;
+
+ size = sizeof(deployed_mode);
+ ret = efi_get_variable_int(L"DeployedMode", _global_variable_guid,
+ NULL, , _mode, NULL);
+ if (ret != EFI_SUCCESS)
+ return ret;
Why should AuditMode not be measured if DeployedMode does not exist?
Could we handle these variables in a loop over an array containing dbt
and dbr reduce code duplication?
Best regards
Heinrich
+
+ pcr_index = (deployed_mode ? 1 : 7);
+
+ ret = tcg2_measure_variable(dev, pcr_index,
+ EV_EFI_VARIABLE_DRIVER_CONFIG,
+ L"DeployedMode",
+ _global_variable_guid,
+ size, _mode);
+
+ size = sizeof(audit_mode);
+ ret = efi_get_variable_int(L"AuditMode", _global_variable_guid,
+ NULL, , _mode, NULL);
+ if (ret != EFI_SUCCESS)
+ return ret;
+
+ ret = tcg2_measure_variable(dev, pcr_index,
+ EV_EFI_VARIABLE_DRIVER_CONFIG,
+ L"AuditMode",
+ _global_variable_guid,
+ size, _mode);
+
+ return ret;
+}
+
/**
* tcg2_measure_secure_boot_variable() - measure secure boot variables
*
@@ -1891,6 +1936,8 @@ static efi_status_t
tcg2_measure_secure_boot_variable(struct udevice *dev)
free(data);
}
+ ret = tcg2_measure_deployed_audit_mode(dev);
+
error:
return ret;
}
Re: RFC: exclude partitions from efi_selftest
On Wed, Sep 15, 2021 at 02:00:31PM +0200, Mark Kettenis wrote: > > Date: Wed, 15 Sep 2021 12:42:16 +0200 > > From: Heinrich Schuchardt > > > > Am 15. September 2021 11:56:07 MESZ schrieb Michael Lawnick > > : > > >Am 14.09.2021 um 17:57 schrieb Heinrich Schuchardt: > > >> On 9/14/21 4:56 PM, Michael Lawnick wrote: > > >>> Hi, > > >>> > > >>> in our environment we get error on efi_selftest if one of several SSD > > >>> partitions isn't properly initialized (due to some other error, but > > >>> that's a different topic). I tried to track down to where the partitions > > >>> get registered for test but got a bit lost so I request advice from you. > > >> > > >> When the UEFI sub-system is intialized we call efi_disk_register(). If > > >> it fails, we don't enter the UEFI sub-system. > > >> > > >> Are you able to identify where efi_disk_register() fails? > > > > > >The system starts up properly. > > >This is what I see: > > >ASIM-CN10KAS> efiload $loadaddr > > >Loaded EFI App image at 0x4008 with 0x216000 bytes > > >ASIM-CN10KAS> bootefi $loadaddr $fdtaddr > > >Scanning disk sd...@8240.blk... > > >** Unrecognized filesystem type ** > > >** Unrecognized filesystem type ** > > >** Unrecognized filesystem type ** > > > > This is not an error. Just an info. > > It is somewhat annoying though. The way disks are partitioned on the > Apple M1 systems, there are several Apple native partition types that > need to be retained and that U-Boot doesn't support. So you see a lot > of these warnings. > > Or maybe we should have a whitelist of partition types not to warn > about? This message is not UEFI specific, but generic filesystem code generates it. So you could 1) At fs_probe_unsupported() in fs/fs.c, change log_err() to log_warning() [or log_info()] 2) Set CONFIG_DEFAULT_LOG_LEVEL to 3(error) [or 4(warning)] to suppress the message. Or you may simply want to modify _log() so as to add a preamble, like "WARN:", in front of the message. -Takahiro Akashi
Re: [PATCH v3 1/2] GPIO: fxl6408: Add support for FXL6408 GPIO expander
On 9/15/21 8:35 PM, Oleksandr Suvorov wrote:
> Hi Michal,
>
> On Fri, Sep 10, 2021 at 9:35 AM Michal Simek wrote:
>>
>>
>>
>> On 9/9/21 10:44 PM, Oleksandr Suvorov wrote:
>>> From: Oleksandr Suvorov
>>>
>>> Initial support for Fairchild's 8 bit I2C gpio expander FXL6408.
>>> The CONFIG_FXL6408_GPIO define enables support for such devices.
>>>
>>> Based on: https://patchwork.kernel.org/patch/9148419/
>>>
>>> Signed-off-by: Oleksandr Suvorov
>>> Reviewed-by: Simon Glass
>>> Tested-by: Marcel Ziswiler
>>> Signed-off-by: Oleksandr Suvorov
>>> Signed-off-by: Oleksandr Suvorov
>>
>> 3 emails for you. Would be the best to choose only one.
>
> Thanks, fixed. That habit to always add '-s' when committing changes :)
>>
>>> ---
>>>
>>> Changes in v3:
>>> - fix a warning:
>>> ...drivers/gpio/gpio-fxl6408.c:348:15: warning: format ‘%ld’
>>> expects argument of type ‘long int’, but argument 3 has
>>> type ‘int’ [-Wformat=]...
>>> - add Tested-by record.
>>>
>>> drivers/gpio/Kconfig| 7 +
>>> drivers/gpio/Makefile | 1 +
>>> drivers/gpio/gpio-fxl6408.c | 366
>>> 3 files changed, 374 insertions(+)
>>> create mode 100644 drivers/gpio/gpio-fxl6408.c
>>>
>>> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
>>> index 4a89c1a62b..f56e4cc261 100644
>>> --- a/drivers/gpio/Kconfig
>>> +++ b/drivers/gpio/Kconfig
>>> @@ -123,6 +123,13 @@ config DA8XX_GPIO
>>> help
>>> This driver supports the DA8xx GPIO controller
>>>
>>> +config FXL6408_GPIO
>>> + bool "FXL6408 I2C GPIO expander driver"
>>> + depends on DM_GPIO && DM_I2C
>>> + help
>>> + This driver supports the Fairchild FXL6408 device. FXL6408 is a
>>> + fully configurable 8-bit I2C-controlled GPIO expander.
>>> +
>>> config INTEL_BROADWELL_GPIO
>>> bool "Intel Broadwell GPIO driver"
>>> depends on DM
>>> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
>>> index 58f4704f6b..83d8b5c9d8 100644
>>> --- a/drivers/gpio/Makefile
>>> +++ b/drivers/gpio/Makefile
>>> @@ -16,6 +16,7 @@ obj-$(CONFIG_AT91_GPIO) += at91_gpio.o
>>> obj-$(CONFIG_ATMEL_PIO4) += atmel_pio4.o
>>> obj-$(CONFIG_BCM6345_GPIO) += bcm6345_gpio.o
>>> obj-$(CONFIG_CORTINA_GPIO) += cortina_gpio.o
>>> +obj-$(CONFIG_FXL6408_GPIO) += gpio-fxl6408.o
>>> obj-$(CONFIG_INTEL_GPIO) += intel_gpio.o
>>> obj-$(CONFIG_INTEL_ICH6_GPIO)+= intel_ich6_gpio.o
>>> obj-$(CONFIG_INTEL_BROADWELL_GPIO) += intel_broadwell_gpio.o
>>> diff --git a/drivers/gpio/gpio-fxl6408.c b/drivers/gpio/gpio-fxl6408.c
>>> new file mode 100644
>>> index 00..dbc68618f9
>>> --- /dev/null
>>> +++ b/drivers/gpio/gpio-fxl6408.c
>>> @@ -0,0 +1,366 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Copyright (C) 2021 Toradex
>>> + * Copyright (C) 2016 Broadcom
>>> + */
>>> +
>>> +/**
>>
>> Below is not kernel-doc format
>
> I don't think so. And without formatting comments of this block as a
> kernel-doc, the kernel-doc tool shows the warning:
> drivers/gpio/gpio-fxl6408.c:1: warning: no structured comments found
Because script only checks format starting with /**.
>>> +};
>>> +
>>> +/*
>>
>> /** this should be kernel doc.
>>
>> Run this
>> ./scripts/kernel-doc -man -v 1>/dev/null *.c
>>
>> to check that all values are right.
>
> The kernel-doc doesn't found errors.
Because it doesn't find any structure to check. Add here /** and run
that script again.
>
>>> + * struct fxl6408_info - Data for fxl6408
>>> + *
>>> + * @dev: udevice structure for the device
>>> + * @addr: i2c slave address
>>> + * @reg_io_dir: hold the value of direction register
>>> + * @reg_output: hold the value of output register
>>> + */
>>> +struct fxl6408_info {
>>> + struct udevice *dev;
>>> + int addr;
>>> + u8 device_id;
>>> + u8 reg_io_dir;
>>> + u8 reg_output;
>>> +};
>>> +
>>> +static inline int fxl6408_write(struct udevice *dev, int reg, u8 val)
>>> +{
>>> + return dm_i2c_write(dev, reg, , 1);
>>> +}
>>> +
>>> +static int fxl6408_read(struct udevice *dev, int reg)
>>> +{
>>> + int ret;
>>> + u8 tmp;
>>> +
>>> + ret = dm_i2c_read(dev, reg, , 1);
>>> + if (!ret)
>>> + ret = tmp;
>>
>> This looks completely wrong. What value are you returning in case of error.
>
> Nope. In case of error, I return an error value stored in "ret".
>
>> If ops->xfer is not defined dm_i2c_read returns -ENOSYS. tmp is not
>> initialized and can have random value that's why here in case or error
>> you will return ramdom value.
>
> !(-ENOSYS) == false, thus "if" op fails and doesn't perform "ret = tmp".
> I don't see any errors here.
You are right. I read it incorrectly.
>>> + /*
>>> + * If configured, set initial output state and direction,
>>> + * otherwise read them from the chip.
>>> + */
>>> + if (dev_read_u32(dev, "initial_io_dir", )) {
>>
>> Where do you have dt binding document for this chip? I can't see
>>
Re: [PATCH 2/3] efi_loader: add UEFI GPT measurement
On 9/15/21 7:15 AM, Masahisa Kojima wrote:
This commit adds the UEFI GPT disk partition topology
measurement required in TCG PC Client PFP Spec.
Thanks for looking into the missing parts of TCG measurement in U-Boot.
The requirements in the TCG PC Client PFP Spec are strange. It does not
explicitly say how to handle multiple block devices. Did the authors
never enjoy the pleasure of a second disk drive?
With your implementation you would measure the GPT table of the SD-card
from which you load Shim or GRUB but would not care about the GPT of the
NVMe drive with your OS.
A clarification by the TCG standards committee would be helpful.
After this series "10.2.7 DEVICE_SECURITY_EVENT_DATA Structure" still
needs to be covered.
Best regards
Heinrich
Signed-off-by: Masahisa Kojima
---
include/blk.h | 3 +
include/efi_loader.h | 2 +-
include/efi_tcg2.h| 12 +++
lib/efi_loader/efi_boottime.c | 2 +-
lib/efi_loader/efi_tcg2.c | 175 +-
5 files changed, 191 insertions(+), 3 deletions(-)
diff --git a/include/blk.h b/include/blk.h
index 19bab081c2..f0cc7ca1a2 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -45,6 +45,9 @@ enum if_type {
#define BLK_PRD_SIZE 20
#define BLK_REV_SIZE 8
+#define PART_FORMAT_PCAT 0x1
+#define PART_FORMAT_GPT0x2
+
/*
* Identifies the partition table type (ie. MBR vs GPT GUID) signature
*/
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 13f0c24058..dbcc296e01 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -503,7 +503,7 @@ efi_status_t efi_init_variables(void);
void efi_variables_boot_exit_notify(void);
efi_status_t efi_tcg2_notify_exit_boot_services_failed(void);
/* Measure efi application invocation */
-efi_status_t efi_tcg2_measure_efi_app_invocation(void);
+efi_status_t efi_tcg2_measure_efi_app_invocation(struct efi_loaded_image_obj
*handle);
/* Measure efi application exit */
efi_status_t efi_tcg2_measure_efi_app_exit(void);
/* Called by bootefi to initialize root node */
diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
index da33f8a1d0..33257fa96b 100644
--- a/include/efi_tcg2.h
+++ b/include/efi_tcg2.h
@@ -230,6 +230,18 @@ struct smbios_handoff_table_pointers2 {
struct efi_configuration_table table_entry[1];
} __packed;
+/**
+ * struct tdUEFI_GPT_DATA - event log structure of industry standard tables
+ * @uefi_partition_header: gpt partition header
+ * @number_of_partitions: the number of partition
+ * @partitions:partition entries
+ */
+struct efi_gpt_data {
+ gpt_header uefi_partition_header;
+ u64 number_of_partitions;
+ gpt_entry partitions[];
+} __packed;
+
struct efi_tcg2_protocol {
efi_status_t (EFIAPI * get_capability)(struct efi_tcg2_protocol *this,
struct
efi_tcg2_boot_service_capability *capability);
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 701e2212c8..bf5661e1ee 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -3003,7 +3003,7 @@ efi_status_t EFIAPI efi_start_image(efi_handle_t
image_handle,
if (IS_ENABLED(CONFIG_EFI_TCG2_PROTOCOL)) {
if (image_obj->image_type == IMAGE_SUBSYSTEM_EFI_APPLICATION) {
- ret = efi_tcg2_measure_efi_app_invocation();
+ ret = efi_tcg2_measure_efi_app_invocation(image_obj);
if (ret != EFI_SUCCESS) {
log_warning("tcg2 measurement fails(0x%lx)\n",
ret);
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 7f47998a55..35810615ed 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -1525,12 +1525,181 @@ static void *search_smbios_table(void)
return NULL;
}
+/**
+ * search_gpt_dp_node() - search gpt device path node
+ *
+ * @device_path: device path
+ *
+ * Return: pointer to the gpt device path node
+ */
+static struct
+efi_device_path *search_gpt_dp_node(struct efi_device_path *device_path)
+{
+ struct efi_device_path *dp = device_path;
+
+ while (dp) {
+ if (dp->type == DEVICE_PATH_TYPE_MEDIA_DEVICE &&
+ dp->sub_type == DEVICE_PATH_SUB_TYPE_HARD_DRIVE_PATH) {
+ struct efi_device_path_hard_drive_path *hd_dp =
+ (struct efi_device_path_hard_drive_path *)dp;
+
+ if (hd_dp->partmap_type == PART_FORMAT_GPT &&
+ hd_dp->signature_type == SIG_TYPE_GUID)
+ return dp;
+ }
+ dp = efi_dp_next(dp);
+ }
+
+ return NULL;
+}
+
+/**
+ * tcg2_measure_gpt_table() - measure gpt table
+ *
+ * @dev: TPM device
+ *
Re: RFC: exclude partitions from efi_selftest
On Wed, Sep 15, 2021 at 05:06:09PM +0200, Michael Lawnick wrote: > Am 15.09.2021 um 13:36 schrieb Michael Lawnick: > > Am 15.09.2021 um 13:22 schrieb Heinrich Schuchardt: > > > > > > > > > Am 15. September 2021 12:54:06 MESZ schrieb Michael Lawnick > > > : > > > > Am 15.09.2021 um 12:42 schrieb Heinrich Schuchardt: > > > > > > > > > Could you, please send the complete output starting with 'bootefi > > > > > selftest'. > > > > > > > > ASIM-CN10KAS> setenv efi_selftest block device > > > > ASIM-CN10KAS> bootefi selftest > > > > > > > > Testing EFI API implementation > > > > > > > > Selected test: 'block device' > > > > > > > > Setting up 'block device' > > > > Setting up 'block device' succeeded > > > > > > > > Executing 'block device' > > > > ** Unrecognized filesystem type ** > > > > > > Is the FAT file system enabled in the configuration? > > > > No > > > > > > > > > lib/efi_selftest/efi_selftest_block_device.c(362): > > > > ERROR: Failed to open simple file system protocol > > > > lib/efi_selftest/efi_selftest.c(111): > > > > ERROR: Executing 'block device' failed > > > > > > > > Tearing down 'block device' > > > > Tearing down 'block device' succeeded > > > > > > > > Boot services terminated > > > > > > > > Summary: 1 failures > > > > Sorry Heinrich, I managed to send below part to only you, so I repeat > > for the group: > > What might be worth to be noted: > > We are working on U-Boot provided by Marvell for upcoming SoC based on > > ThunderX. It is rather up to main branch but not the latest version. > > Latest change from main: > > Author: Patrick Wildt > > Date: Wed Oct 7 11:04:33 2020 +0200 > > efi_loader: fix use after free in receive path > > Signed-off-by: Heinrich Schuchardt > > > > If you can give a list of relevant modules I can make comparison, but > > just updating everything to latest or comparing full source tree won't > > be possible. > > > > We have 8 partitions of which no. 5 isn't initialized. > I have put a bunch of printf to the code and see that the execute() is > done exactly on the partition which is unknown, no other gets touched !? Just in case, "block device" selftest doesn't touch you disk at all. Instead, it sets up some memory region as a pseudo block device (i.e. block_io_protocol) with fat filesystem, and utilizes it for the test execution. Please, as Heinrich suggested, add CONFIG_FS_FAT, in your U-Boot configuration. -Takahiro Akashi > -- > KR > Michael
RE: [PATCH] ARM: dts: ast2600: Make WDT by default disabled
> -Original Message-
> From: ChiaWei Wang
> Sent: Thursday, September 16, 2021 2:10 PM
> To: u-boot@lists.denx.de
> Cc: Ryan Chen
> Subject: [PATCH] ARM: dts: ast2600: Make WDT by default disabled
>
> The WDT devices described in the general .dtsi file should be marked as
> "disabled" by default.
>
> A WDT should be then enabled in the board specific .dts file on demands.
>
> Signed-off-by: Chia-Wei Wang
Reviewed-by: Ryan Chen
> ---
> arch/arm/dts/ast2600.dtsi | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/dts/ast2600.dtsi b/arch/arm/dts/ast2600.dtsi index
> ac0f08b7ea..f121f547e6 100644
> --- a/arch/arm/dts/ast2600.dtsi
> +++ b/arch/arm/dts/ast2600.dtsi
> @@ -474,21 +474,25 @@
> wdt1: watchdog@1e785000 {
> compatible = "aspeed,ast2600-wdt";
> reg = <0x1e785000 0x40>;
> + status = "disabled";
> };
>
> wdt2: watchdog@1e785040 {
> compatible = "aspeed,ast2600-wdt";
> reg = <0x1e785040 0x40>;
> + status = "disabled";
> };
>
> wdt3: watchdog@1e785080 {
> compatible = "aspeed,ast2600-wdt";
> reg = <0x1e785080 0x40>;
> + status = "disabled";
> };
>
> wdt4: watchdog@1e7850C0 {
> compatible = "aspeed,ast2600-wdt";
> reg = <0x1e7850C0 0x40>;
> + status = "disabled";
> };
>
> lpc: lpc@1e789000 {
> --
> 2.17.1
Re: [PATCH 3/3] efi_loader: add DeployedMode and AuditMode variable measurement
Hi Heinrich,
On Thu, 16 Sept 2021 at 16:02, Heinrich Schuchardt wrote:
>
>
>
> On 9/15/21 7:15 AM, Masahisa Kojima wrote:
> > This commit adds the DeployedMode and AuditMode variable
> > measurement required in TCG PC Client PFP Spec.
> >
> > Signed-off-by: Masahisa Kojima
> > ---
> > lib/efi_loader/efi_tcg2.c | 47 +++
> > 1 file changed, 47 insertions(+)
> >
> > diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
> > index 35810615ed..427d6e22b1 100644
> > --- a/lib/efi_loader/efi_tcg2.c
> > +++ b/lib/efi_loader/efi_tcg2.c
> > @@ -12,6 +12,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -1828,6 +1829,50 @@ out:
> > return ret;
> > }
> >
> > +/**
> > + * tcg2_measure_deployed_audit_mode() - measure deployedmode and auditmode
> > + *
> > + * @dev: TPM device
> > + *
> > + * Return: status code
> > + */
> > +static efi_status_t tcg2_measure_deployed_audit_mode(struct udevice *dev)
> > +{
> > + u8 deployed_mode;
> > + u8 audit_mode;
> > + efi_uintn_t size;
> > + efi_status_t ret;
> > + u32 pcr_index;
> > +
> > + size = sizeof(deployed_mode);
> > + ret = efi_get_variable_int(L"DeployedMode", _global_variable_guid,
> > +NULL, , _mode, NULL);
> > + if (ret != EFI_SUCCESS)
> > + return ret;
>
> Why should AuditMode not be measured if DeployedMode does not exist?
TCG spec says that PCR index is different depending on the DeployedMode value.
--- PCR[1]
If the system supports UEFI 2.5 or later and DeployedMode is enabled,
the following additional variables MUST
be measured into PCR[1]:
a. The DeployedMode variable value. The Event Type SHALL be
EV_EFI_VARIABLE_DRIVER_CONFIG and
the Event value shall be the value of the UEFI_VARIABLE data structure.
b. The AuditMode variable value. The Event Type SHALL be
EV_EFI_VARIABLE_DRIVER_CONFIG and the
Event value shall be the value of the UEFI_VARIABLE data structure.
---
--- PCR[7]
If the system supports UEFI 2.5 or later and DeployedMode is NOT
enabled, the following additional
variables MUST be measured into PCR[7]:
a. The contents of the AuditMode variable
b. The contents of the DeployedMode variable
---
If DeployedMode does not exist, we can not decide which PCR to be extended.
Thanks,
Masahisa Kojima
>
> Could we handle these variables in a loop over an array containing dbt
> and dbr reduce code duplication?
>
> Best regards
>
> Heinrich
>
> > +
> > + pcr_index = (deployed_mode ? 1 : 7);
> > +
> > + ret = tcg2_measure_variable(dev, pcr_index,
> > + EV_EFI_VARIABLE_DRIVER_CONFIG,
> > + L"DeployedMode",
> > + _global_variable_guid,
> > + size, _mode);
> > +
> > + size = sizeof(audit_mode);
> > + ret = efi_get_variable_int(L"AuditMode", _global_variable_guid,
> > +NULL, , _mode, NULL);
> > + if (ret != EFI_SUCCESS)
> > + return ret;
> > +
> > + ret = tcg2_measure_variable(dev, pcr_index,
> > + EV_EFI_VARIABLE_DRIVER_CONFIG,
> > + L"AuditMode",
> > + _global_variable_guid,
> > + size, _mode);
> > +
> > + return ret;
> > +}
> > +
> > /**
> >* tcg2_measure_secure_boot_variable() - measure secure boot variables
> >*
> > @@ -1891,6 +1936,8 @@ static efi_status_t
> > tcg2_measure_secure_boot_variable(struct udevice *dev)
> > free(data);
> > }
> >
> > + ret = tcg2_measure_deployed_audit_mode(dev);
> > +
> > error:
> > return ret;
> > }
> >
Re: RFC: exclude partitions from efi_selftest
Am 16.09.2021 um 09:15 schrieb Michael Lawnick: Am 16.09.2021 um 09:12 schrieb AKASHI Takahiro: Please, as Heinrich suggested, add CONFIG_FS_FAT, in your U-Boot configuration. Hmm, I didn't understand that as a suggestion, but as a question for his understanding. Of course I'll give it a try. Sometimes live is such easy. This fixed my issue, THX. For the after-math / my understanding: - Do I understand correctly that the problem was that 'efi_selftest block device' requires FAT support? So shouldn't there be a dependency in CONFIG? - What is the reason/use to iterate through the recognized partitions even twice (in .setup and .execute) if they aren't needed/used? -- KR Michael
Re: [PATCH] mtd: spi-nor: Fix SF MTDIDS when registering multiple MTDs with DM enabled
Hi,
On 9/15/21 2:10 PM, Marek Vasut wrote:
On 9/15/21 2:00 PM, Patrick DELAUNAY wrote:
Hi,
On 9/15/21 10:57 AM, Marek Vasut wrote:
On 9/15/21 10:53 AM, Patrice CHOTARD wrote:
Hi All
On 9/15/21 7:59 AM, Marek Vasut wrote:
On 9/15/21 6:23 AM, Heiko Schocher wrote:
Hi Marek,
On 15.09.21 01:06, Marek Vasut wrote:
The flash->mtd.name used to be nor%d before, now it is the
type of the
SPI NOR like e.g. mt25ql02g. It is possible to find plenty of
examples
of the former in U-Boot configs by searching for
MTDIDS.*nor.*spi, while
the later is ambiguous if there are multiple flashes of the
same type in
the system and breaks existing environments.
This does no longer get recognized when running 'mtdparts' for
example:
CONFIG_MTDIDS_DEFAULT="nor0=4704.spi.0"
Fix this by setting the correct mtd.name to nor%d.
Fixes: b7f060565e3 ("mtd: spi-nor: allow registering multiple
MTDs when DM is enabled")
Signed-off-by: Marek Vasut
Cc: Heiko Schocher
Cc: Jagan Teki
Cc: Marek Behún
Cc: Miquel Raynal
Cc: Pali Rohár
Cc: Patrice Chotard
Cc: Patrick Delaunay
Cc: Priyanka Jain
Cc: Simon Glass
---
drivers/mtd/spi/sf_mtd.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Seem fixes the same problem as Patrick already posted here:
https://patchwork.ozlabs.org/project/uboot/patch/20210913095742.v2.1.I73dae4b93f0587dc130e512e95a1f4794e0b0233@changeid/
I find your approach cleaner, so:
Acked-by: Heiko Schocher
@Patrick: Could you test this patch please?
The option from Patrick does look more predictable, but looking
at the old implementation of spi_flash_mtd_number(), that one
handled even cases of parallel-nor and spi-nor (both using the
nor%d) present on the same system. This:
static int spi_flash_mtd_number(void)
{
#ifdef CONFIG_SYS_MAX_FLASH_BANKS
return CONFIG_SYS_MAX_FLASH_BANKS;
#else
return 0;
#endif
}
...
sprintf(sf_mtd_name, "nor%d", spi_flash_mtd_number());
The patch from Patrick does not, it does per-spi-nor-only
counting using the dev_seq() there, which is more predictable,
but local to spi-nor.
The MTD core has its own IDR counting, which is used by this
patch and is global to the MTD core. That has two issues, one is
that it is possibly too global and counts both nor%d and nand%d,
which means it would fail on systems with both SPI NOR and
regular NAND. The other is it is likely less predictable (what
happens if the SPI NOR and parallel NOR gets probed in the
reverse order ? I know it is unlikely, but it can happen in the
future).
So I think we need a third option which I would suggest be based
on the patch from Patrick, but which would take into account the
other nor%d devices like parallel NOR flashes.
That would likely have to happen in the mtd core using some
modified IDR counting. I think you might need to modify it such
that you would pass in the prefix of the device (like 'nor') and
then do per-prefix counting, with the special case that parallel
NORs are counted first. Also, that would also have to consider
probing of multiple SPI NORs in either order (say you have two,
if you do 'sf probe 0:0 ; sf probe 0:1' vs. 'sf probe 0:1 ; sf
probe 0:0'), and make sure they get enumerated with the same
nor%d value either way, that might be where the dev_seq() would
come in.
I just got a try with this patch and unfortunately, it doesn't
solve the issue.
I tested it on STM32MP1-ev1 board which embedds 1 NAND and 2
SPI-NORs.
Here is the output of mtd list command:
U-Boot 2021.10-rc4-1-g1923b5a21d (Sep 15 2021 - 10:48:48 +0200)
CPU: STM32MP157AAA Rev.B
Model: STMicroelectronics STM32MP157C eval daughter on eval mother
Board: stm32mp1 in basic mode (st,stm32mp157c-ev1)
Board: MB1263 Var1.0 Rev.C-01
DRAM: 1 GiB
Clocks:
- MPU : 650 MHz
- MCU : 208.878 MHz
- AXI : 266.500 MHz
- PER : 24 MHz
- DDR : 533 MHz
WDT: Started with servicing (32s timeout)
NAND: 1024 MiB
MMC: STM32 SD/MMC: 0, STM32 SD/MMC: 1
Loading Environment from MMC... *** Warning - bad CRC, using
default environment
In: serial
Out: serial
Err: serial
Net: eth0: ethernet@5800a000
Hit any key to stop autoboot: 0
STM32MP> mtd list
SF: Detected mx66l51235l with page size 256 Bytes, erase size 64
KiB, total 64 MiB
SF: Detected nor1 with page size 256 Bytes, erase size 64 KiB,
total 64 MiB
List of MTD devices:
* nand0
- type: NAND flash
- block size: 0x4 bytes
- min I/O: 0x1000 bytes
- OOB size: 224 bytes
- OOB available: 118 bytes
- ECC strength: 8 bits
- ECC step size: 512 bytes
- bitflip threshold: 6 bits
- 0x-0x4000 : "nand0"
* nor2
- device: mx66l51235l@0
- parent: spi@58003000
- driver: jedec_spi_nor
- path: /soc/spi@58003000/mx66l51235l@0
- type: NOR flash
- block size: 0x1 bytes
- min I/O: 0x1 bytes
- 0x-0x0400 : "nor2"
* nor2
- device: mx66l51235l@1
- parent:
[PATCH] ARM: dts: ast2600: Make WDT by default disabled
The WDT devices described in the general .dtsi file
should be marked as "disabled" by default.
A WDT should be then enabled in the board specific
.dts file on demands.
Signed-off-by: Chia-Wei Wang
---
arch/arm/dts/ast2600.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/ast2600.dtsi b/arch/arm/dts/ast2600.dtsi
index ac0f08b7ea..f121f547e6 100644
--- a/arch/arm/dts/ast2600.dtsi
+++ b/arch/arm/dts/ast2600.dtsi
@@ -474,21 +474,25 @@
wdt1: watchdog@1e785000 {
compatible = "aspeed,ast2600-wdt";
reg = <0x1e785000 0x40>;
+ status = "disabled";
};
wdt2: watchdog@1e785040 {
compatible = "aspeed,ast2600-wdt";
reg = <0x1e785040 0x40>;
+ status = "disabled";
};
wdt3: watchdog@1e785080 {
compatible = "aspeed,ast2600-wdt";
reg = <0x1e785080 0x40>;
+ status = "disabled";
};
wdt4: watchdog@1e7850C0 {
compatible = "aspeed,ast2600-wdt";
reg = <0x1e7850C0 0x40>;
+ status = "disabled";
};
lpc: lpc@1e789000 {
--
2.17.1
[PATCH next] lib: hash-checksum: Use DM_HASH if supported
Use DM_HASH to perform hashing operations if supported.
Thus either SW or HW-assisted hashing could be leveraged.
Signed-off-by: Chia-Wei Wang
---
lib/hash-checksum.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/lib/hash-checksum.c b/lib/hash-checksum.c
index d732ecc38f..f30873db38 100644
--- a/lib/hash-checksum.c
+++ b/lib/hash-checksum.c
@@ -10,6 +10,10 @@
#include
#include
#include
+#if defined(CONFIG_DM_HASH)
+#include
+#include
+#endif
#else
#include "fdt_host.h"
#endif
@@ -20,6 +24,38 @@ int hash_calculate(const char *name,
const struct image_region region[],
int region_count, uint8_t *checksum)
{
+#if !defined(USE_HOSTCC) && defined(CONFIG_DM_HASH)
+ int i, rc;
+ enum HASH_ALGO hash_algo;
+ struct udevice *dev;
+ void *ctx;
+
+ rc = uclass_get_device(UCLASS_HASH, 0, );
+ if (rc) {
+ debug("failed to get hash device, rc=%d\n", rc);
+ return -1;
+ }
+
+ hash_algo = hash_algo_lookup_by_name(name);
+ if (hash_algo == HASH_ALGO_INVALID) {
+ debug("Unsupported hash algorithm\n");
+ return -1;
+ };
+
+ rc = hash_init(dev, hash_algo, );
+ if (rc)
+ return rc;
+
+ for (i = 0; i < region_count; i++) {
+ rc = hash_update(dev, ctx, region[i].data, region[i].size);
+ if (rc)
+ return rc;
+ }
+
+ rc = hash_finish(dev, ctx, checksum);
+ if (rc)
+ return rc;
+#else
struct hash_algo *algo;
int ret = 0;
void *ctx;
@@ -47,6 +83,7 @@ int hash_calculate(const char *name,
ret = algo->hash_finish(algo, ctx, checksum, algo->digest_size);
if (ret)
return ret;
+#endif
return 0;
}
--
2.17.1
[PATCH] driver: gadget: fastboot: Link endpoint and descriptors
From: qianfan Zhao
If the downloading file size is equal to the partition size, "fastboot
flash" can't work, at least in sunxi platform, because used an
uninitalized point: ep->desc.
Reproduce: fastboot flash loader1 spl/sunxi-spl.bin.
Fix it.
Signed-off-by: qianfan Zhao
---
drivers/usb/gadget/f_fastboot.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 8ba55aab9f..45bb3aba66 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -319,13 +319,13 @@ static int fastboot_set_alt(struct usb_function *f,
struct usb_composite_dev *cdev = f->config->cdev;
struct usb_gadget *gadget = cdev->gadget;
struct f_fastboot *f_fb = func_to_fastboot(f);
- const struct usb_endpoint_descriptor *d;
debug("%s: func: %s intf: %d alt: %d\n",
__func__, f->name, interface, alt);
- d = fb_ep_desc(gadget, _ep_out, _ep_out, _ep_out);
- ret = usb_ep_enable(f_fb->out_ep, d);
+ f_fb->out_ep->desc = fb_ep_desc(gadget, _ep_out, _ep_out,
+ _ep_out);
+ ret = usb_ep_enable(f_fb->out_ep, f_fb->out_ep->desc);
if (ret) {
puts("failed to enable out ep\n");
return ret;
@@ -339,8 +339,8 @@ static int fastboot_set_alt(struct usb_function *f,
}
f_fb->out_req->complete = rx_handler_command;
- d = fb_ep_desc(gadget, _ep_in, _ep_in, _ep_in);
- ret = usb_ep_enable(f_fb->in_ep, d);
+ f_fb->in_ep->desc = fb_ep_desc(gadget, _ep_in, _ep_in, _ep_in);
+ ret = usb_ep_enable(f_fb->in_ep, f_fb->in_ep->desc);
if (ret) {
puts("failed to enable in ep\n");
goto err;
--
2.17.1
Re: RFC: exclude partitions from efi_selftest
Am 16.09.2021 um 09:12 schrieb AKASHI Takahiro: On Wed, Sep 15, 2021 at 05:06:09PM +0200, Michael Lawnick wrote: Am 15.09.2021 um 13:36 schrieb Michael Lawnick: Am 15.09.2021 um 13:22 schrieb Heinrich Schuchardt: Am 15. September 2021 12:54:06 MESZ schrieb Michael Lawnick : Am 15.09.2021 um 12:42 schrieb Heinrich Schuchardt: Could you, please send the complete output starting with 'bootefi selftest'. ASIM-CN10KAS> setenv efi_selftest block device ASIM-CN10KAS> bootefi selftest Testing EFI API implementation Selected test: 'block device' Setting up 'block device' Setting up 'block device' succeeded Executing 'block device' ** Unrecognized filesystem type ** Is the FAT file system enabled in the configuration? No lib/efi_selftest/efi_selftest_block_device.c(362): ERROR: Failed to open simple file system protocol lib/efi_selftest/efi_selftest.c(111): ERROR: Executing 'block device' failed Tearing down 'block device' Tearing down 'block device' succeeded Boot services terminated Summary: 1 failures Sorry Heinrich, I managed to send below part to only you, so I repeat for the group: What might be worth to be noted: We are working on U-Boot provided by Marvell for upcoming SoC based on ThunderX. It is rather up to main branch but not the latest version. Latest change from main: Author: Patrick Wildt Date: Wed Oct 7 11:04:33 2020 +0200 efi_loader: fix use after free in receive path Signed-off-by: Heinrich Schuchardt If you can give a list of relevant modules I can make comparison, but just updating everything to latest or comparing full source tree won't be possible. We have 8 partitions of which no. 5 isn't initialized. I have put a bunch of printf to the code and see that the execute() is done exactly on the partition which is unknown, no other gets touched !? Just in case, "block device" selftest doesn't touch you disk at all. Instead, it sets up some memory region as a pseudo block device (i.e. block_io_protocol) with fat filesystem, and utilizes it for the test execution. Please, as Heinrich suggested, add CONFIG_FS_FAT, in your U-Boot configuration. Hmm, I didn't understand that as a suggestion, but as a question for his understanding. Of course I'll give it a try. KR Michael
[PATCH 0/2] Enable strict signature verification for FIT
FIT load checks the signature on loadable images, but just continues in the case of a failure. This is undesirable behavior because the boot process depends on the authenticity of every loadable part. Add a check that verifies the FIT's configuration block, and fails if it's not present or the signature doesn't match. Henry Beberman (1): spl: Add CONFIG_SPL_FIT_SIGNATURE_STRICT Ricardo Salveti (1): cmd: Add CONFIG_FIT_SIGNATURE_STRICT cmd/fpga.c | 14 ++ cmd/source.c | 14 ++ cmd/ximg.c | 14 ++ common/Kconfig.boot | 11 +++ common/spl/spl_fit.c | 21 - 5 files changed, 73 insertions(+), 1 deletion(-) -- 2.31.1
[PATCH 1/2] spl: Add CONFIG_SPL_FIT_SIGNATURE_STRICT
From: Henry Beberman
SPL FIT load checks the signature on loadable images but just continues
in the case of a failure. This is undesirable behavior because the boot
process depends on the authenticity of each loadable part.
Adding CONFIG_SPL_FIT_SIGNATURE_STRICT to halt the platform when any
image fails its signature check, including loadable parts.
SPL already supports image signature verification but had no mechanism
to check that the FIT's configuration block was signed correctly.
Add a check near the start of spl_load_simple_fit that verifies the
FIT's configuration block, and fails if it's not present or the
signature doesn't match what's stored in the SPL DTB.
Signed-off-by: Henry Beberman
Signed-off-by: Ricardo Salveti
Co-developed-by: Oleksandr Suvorov
Signed-off-by: Oleksandr Suvorov
---
common/Kconfig.boot | 7 +++
common/spl/spl_fit.c | 21 -
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index 902a5b8fbea..6f95d009dfa 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -166,6 +166,13 @@ config SPL_FIT_SIGNATURE
select SPL_IMAGE_SIGN_INFO
select SPL_FIT_FULL_CHECK
+config SPL_FIT_SIGNATURE_STRICT
+ bool "Halt if loadables or firmware don't pass FIT signature
verification"
+ select SPL_FIT_SIGNATURE
+ help
+ Strictly requires each loadable or firmware in a FIT image to be
+ passed verification. Halt if any loadable fails to be verified.
+
config SPL_LOAD_FIT
bool "Enable SPL loading U-Boot as a FIT (basic fitImage features)"
select SPL_FIT
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index f41abca0ccb..e7eaaa4cb9e 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -315,7 +315,12 @@ static int spl_load_fit_image(struct spl_load_info *info,
ulong sector,
printf("## Checking hash(es) for Image %s ... ",
fit_get_name(fit, node, NULL));
if (!fit_image_verify_with_data(fit, node, src, length))
- return -EPERM;
+ if (CONFIG_IS_ENABLED(FIT_SIGNATURE_STRICT)) {
+ puts("Invalid FIT signature found in a required
image.\n");
+ hang();
+ } else {
+ return -EPERM;
+ }
puts("OK\n");
}
@@ -681,6 +686,20 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
if (ret < 0)
return ret;
+ if (CONFIG_IS_ENABLED(FIT_SIGNATURE_STRICT)) {
+ int cfg_noffset = fit_conf_get_node(fit, NULL);
+
+ if (cfg_noffset >= 0) {
+ if (fit_config_verify(fit, cfg_noffset)) {
+ puts("Unable to verify the required FIT
config.\n");
+ hang();
+ }
+ } else {
+ puts("SPL_FIT_SIGNATURE_STRICT needs a config node in
FIT\n");
+ hang();
+ }
+ }
+
/* skip further processing if requested to enable load-only use cases */
if (spl_load_simple_fit_skip_processing())
return 0;
--
2.31.1
[PATCH 2/2] cmd: Add CONFIG_FIT_SIGNATURE_STRICT
From: Ricardo Salveti
Add CONFIG_FIT_SIGNATURE_STRICT to require a valid FIT configuration
signature for each command that is able to manipulate FIT images.
Signed-off-by: Ricardo Salveti
Co-developed-by: Oleksandr Suvorov
Signed-off-by: Oleksandr Suvorov
---
cmd/fpga.c | 14 ++
cmd/source.c| 14 ++
cmd/ximg.c | 14 ++
common/Kconfig.boot | 4
4 files changed, 46 insertions(+)
diff --git a/cmd/fpga.c b/cmd/fpga.c
index 3fdd0b35e80..16d329590fa 100644
--- a/cmd/fpga.c
+++ b/cmd/fpga.c
@@ -335,6 +335,20 @@ static int do_fpga_loadmk(struct cmd_tbl *cmdtp, int flag,
int argc,
return CMD_RET_FAILURE;
}
+ if (CONFIG_IS_ENABLED(FIT_SIGNATURE_STRICT)) {
+ /* validate required fit config entry */
+ noffset = fit_conf_get_node(fit_hdr, NULL);
+ if (noffset >= 0) {
+ if (fit_config_verify(fit_hdr, noffset)) {
+ puts("Cannot verify FIT config node\n");
+ return CMD_RET_FAILURE;
+ }
+ } else {
+ puts("FIT_SIGNATURE_STRICT requires a config
node\n");
+ return CMD_RET_FAILURE;
+ }
+ }
+
/* get fpga component image node offset */
noffset = fit_image_get_node(fit_hdr, fit_uname);
if (noffset < 0) {
diff --git a/cmd/source.c b/cmd/source.c
index 81e015b64ef..b08406dfcbf 100644
--- a/cmd/source.c
+++ b/cmd/source.c
@@ -112,6 +112,20 @@ int image_source_script(ulong addr, const char *fit_uname)
return 1;
}
+ if (CONFIG_IS_ENABLED(FIT_SIGNATURE_STRICT)) {
+ /* validate required fit config entry */
+ noffset = fit_conf_get_node(fit_hdr, NULL);
+ if (noffset >= 0) {
+ if (fit_config_verify(fit_hdr, noffset)) {
+ puts("Cannot verify FIT config node\n");
+ return 1;
+ }
+ } else {
+ puts("FIT_SIGNATURE_STRICT requires a config
node\n");
+ return 1;
+ }
+ }
+
if (!fit_uname)
fit_uname = get_default_image(fit_hdr);
diff --git a/cmd/ximg.c b/cmd/ximg.c
index 65ba41320a0..39fccd8179c 100644
--- a/cmd/ximg.c
+++ b/cmd/ximg.c
@@ -141,6 +141,20 @@ do_imgextract(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
return 1;
}
+ if (CONFIG_IS_ENABLED(FIT_SIGNATURE_STRICT)) {
+ /* validate required fit config entry */
+ noffset = fit_conf_get_node(fit_hdr, NULL);
+ if (noffset >= 0) {
+ if (fit_config_verify(fit_hdr, noffset)) {
+ puts("Cannot verify FIT config node\n");
+ return 1;
+ }
+ } else {
+ puts("FIT_SIGNATURE_STRICT requires a config
node\n");
+ return 1;
+ }
+ }
+
/* get subimage node offset */
noffset = fit_image_get_node(fit_hdr, uname);
if (noffset < 0) {
diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index 6f95d009dfa..ca7d9a8d971 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -77,6 +77,10 @@ config FIT_SIGNATURE_MAX_SIZE
device memory. Assure this size does not extend past expected storage
space.
+config FIT_SIGNATURE_STRICT
+ bool "Requires a valid FIT configuration signature for every image"
+ select FIT_SIGNATURE
+
config FIT_RSASSA_PSS
bool "Support rsassa-pss signature scheme of FIT image contents"
depends on FIT_SIGNATURE
--
2.31.1
Re: [PATCH 1/1] fs: btrfs: avoid superfluous messages
On Thu, Sep 16, 2021 at 02:01:28PM +0200, Marek Behún wrote: > On Thu, 16 Sep 2021 10:02:45 +0200 > Heinrich Schuchardt wrote: > > Heinrich, Simon already sent patch > https://lore.kernel.org/u-boot/20210818214022.4.I3eb71025472bbb050bcf9a0a192dde1b6c07fa7f@changeid/ > > Tom, could you apply Simon's version? Yes, I should probably do another round of -next patches today and I'll grab that series. -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] cmd: Add CONFIG_FIT_SIGNATURE_STRICT
Hi Oleksandr,
On Thu, Sep 16, 2021 at 4:10 PM Oleksandr Suvorov
wrote:
>
> From: Ricardo Salveti
>
> Add CONFIG_FIT_SIGNATURE_STRICT to require a valid FIT configuration
> signature for each command that is able to manipulate FIT images.
>
> Signed-off-by: Ricardo Salveti
> Co-developed-by: Oleksandr Suvorov
> Signed-off-by: Oleksandr Suvorov
> ---
>
> cmd/fpga.c | 14 ++
> cmd/source.c| 14 ++
> cmd/ximg.c | 14 ++
> common/Kconfig.boot | 4
> 4 files changed, 46 insertions(+)
>
> diff --git a/cmd/fpga.c b/cmd/fpga.c
> index 3fdd0b35e80..16d329590fa 100644
> --- a/cmd/fpga.c
> +++ b/cmd/fpga.c
> @@ -335,6 +335,20 @@ static int do_fpga_loadmk(struct cmd_tbl *cmdtp, int
> flag, int argc,
> return CMD_RET_FAILURE;
> }
>
> + if (CONFIG_IS_ENABLED(FIT_SIGNATURE_STRICT)) {
> + /* validate required fit config entry */
> + noffset = fit_conf_get_node(fit_hdr, NULL);
> + if (noffset >= 0) {
> + if (fit_config_verify(fit_hdr, noffset)) {
> + puts("Cannot verify FIT config
> node\n");
> + return CMD_RET_FAILURE;
> + }
> + } else {
> + puts("FIT_SIGNATURE_STRICT requires a config
> node\n");
> + return CMD_RET_FAILURE;
> + }
> + }
> +
> /* get fpga component image node offset */
> noffset = fit_image_get_node(fit_hdr, fit_uname);
> if (noffset < 0) {
> diff --git a/cmd/source.c b/cmd/source.c
> index 81e015b64ef..b08406dfcbf 100644
> --- a/cmd/source.c
> +++ b/cmd/source.c
> @@ -112,6 +112,20 @@ int image_source_script(ulong addr, const char
> *fit_uname)
> return 1;
> }
>
> + if (CONFIG_IS_ENABLED(FIT_SIGNATURE_STRICT)) {
> + /* validate required fit config entry */
> + noffset = fit_conf_get_node(fit_hdr, NULL);
> + if (noffset >= 0) {
> + if (fit_config_verify(fit_hdr, noffset)) {
> + puts("Cannot verify FIT config
> node\n");
> + return 1;
> + }
> + } else {
> + puts("FIT_SIGNATURE_STRICT requires a config
> node\n");
> + return 1;
> + }
> + }
> +
> if (!fit_uname)
> fit_uname = get_default_image(fit_hdr);
>
> diff --git a/cmd/ximg.c b/cmd/ximg.c
> index 65ba41320a0..39fccd8179c 100644
> --- a/cmd/ximg.c
> +++ b/cmd/ximg.c
> @@ -141,6 +141,20 @@ do_imgextract(struct cmd_tbl *cmdtp, int flag, int argc,
> char *const argv[])
> return 1;
> }
>
> + if (CONFIG_IS_ENABLED(FIT_SIGNATURE_STRICT)) {
> + /* validate required fit config entry */
> + noffset = fit_conf_get_node(fit_hdr, NULL);
> + if (noffset >= 0) {
> + if (fit_config_verify(fit_hdr, noffset)) {
> + puts("Cannot verify FIT config
> node\n");
> + return 1;
> + }
> + } else {
> + puts("FIT_SIGNATURE_STRICT requires a config
> node\n");
> + return 1;
> + }
> + }
> +
> /* get subimage node offset */
> noffset = fit_image_get_node(fit_hdr, uname);
> if (noffset < 0) {
> diff --git a/common/Kconfig.boot b/common/Kconfig.boot
> index 6f95d009dfa..ca7d9a8d971 100644
> --- a/common/Kconfig.boot
> +++ b/common/Kconfig.boot
> @@ -77,6 +77,10 @@ config FIT_SIGNATURE_MAX_SIZE
> device memory. Assure this size does not extend past expected
> storage
> space.
>
> +config FIT_SIGNATURE_STRICT
> + bool "Requires a valid FIT configuration signature for every image"
> + select FIT_SIGNATURE
> +
> config FIT_RSASSA_PSS
> bool "Support rsassa-pss signature scheme of FIT image contents"
> depends on FIT_SIGNATURE
> --
> 2.31.1
>
There is duplication of the same piece of code in 3 different files,
maybe you could rework
that and move to some common function?
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
Embedded Software Engineer
T: +380 938364067
E: igor.opan...@foundries.io
W: www.foundries.io
RISC-V MC schedule is out
The official schedule RISC-V MC at Plumbers is available now. https://linuxplumbersconf.org/event/11/sessions/114/#20210921 We have many interesting topics that will be discussed including the following draft specifications. [1] RISC-V Platform specification (https://github.com/riscv/riscv-platform-specs) [2] Advanced Interrupt Architecture (AIA) (https://github.com/riscv/riscv-aia) [3] Advanced CLINT (ACLINT) (https://github.com/riscv/riscv-aclint/) [4] ACPI for RISC-V (https://github.com/riscv-non-isa/riscv-acpi) All of these specifications will be moved to a wider public review phase in a few months as well. We look forward to your feedback on these specifications. Hope to have a great session next week. FYI: The registration for plumbers is still open if you have not already done so [1]. [1] https://linuxplumbersconf.org/event/11/page/112-attend -- Regards, Atish
Re: [PATCH 1/1] fs: btrfs: avoid superfluous messages
On Thu, 16 Sep 2021 10:02:45 +0200 Heinrich Schuchardt wrote: Heinrich, Simon already sent patch https://lore.kernel.org/u-boot/20210818214022.4.I3eb71025472bbb050bcf9a0a192dde1b6c07fa7f@changeid/ Tom, could you apply Simon's version? Marek
Re: [PATCH 3/4] crypto: hash: Add software hash DM driver
On 7/29/21 8:08 PM, Chia-Wei Wang wrote:
Add purely software-implmented drivers to support multiple
hash operations including CRC, MD5, and SHA family.
This driver is based on the new hash uclass.
Signed-off-by: Chia-Wei Wang
---
drivers/crypto/hash/Kconfig | 11 ++
drivers/crypto/hash/Makefile | 1 +
drivers/crypto/hash/hash_sw.c | 301 ++
3 files changed, 313 insertions(+)
create mode 100644 drivers/crypto/hash/hash_sw.c
diff --git a/drivers/crypto/hash/Kconfig b/drivers/crypto/hash/Kconfig
index e226144b9b..cd29a5c6a4 100644
--- a/drivers/crypto/hash/Kconfig
+++ b/drivers/crypto/hash/Kconfig
@@ -3,3 +3,14 @@ config DM_HASH
depends on DM
help
If you want to use driver model for Hash, say Y.
+
+config HASH_SOFTWARE
+ bool "Enable driver for Hash in software"
+ depends on DM_HASH
+ depends on MD5
+ depends on SHA1
+ depends on SHA256
+ depends on SHA512_ALGO
I would have expected a U_BOOT_DRIVER() for each hash algo, rather than
a U_BOOT_DRIVER() wich encompassess all possible algos. If I'm trying to
use SHA256 in SPL, I might not have the room too add SHA1 and MD5, so
I'd have issues using HASH_SOFTWARE, as designed.
diff --git a/drivers/crypto/hash/hash_sw.c b/drivers/crypto/hash/hash_sw.c
new file mode 100644
index 00..fea9d12609
--- /dev/null
+++ b/drivers/crypto/hash/hash_sw.c
@@ -0,0 +1,301 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2021 ASPEED Technology Inc.
+ * Author: ChiaWei Wang
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* CRC16-CCITT */
+static void hash_init_crc16_ccitt(void *ctx)
+{
+ *((uint16_t *)ctx) = 0;
Undefined behavior: Pointer aliased type-punning. I would suggest using
memset(). Might not be necessarrym as expleined in the next comment.
+static void hash_update_crc16_ccitt(void *ctx, const void *ibuf, uint32_t ilen)
+static void hash_finish_crc16_ccitt(void *ctx, void *obuf)
+/* CRC32 */
+static void hash_init_crc32(void *ctx)
+static void hash_update_crc32(void *ctx, const void *ibuf, uint32_t ilen)
+static void hash_finish_crc32(void *ctx, void *obuf)
+/* SHA1 */
+static void hash_init_sha1(void *ctx)
+/* SHA256 */
+/* SHA384 */
+/* SHA512 */
This logic already exists in common/hash.c for hash_Lookup_algo() and
hash_progressive_algo().
Alex
Re: [PATCH 4/4] fit: Use DM hash driver if supported
On 7/29/21 8:08 PM, Chia-Wei Wang wrote:
Calculate hash using DM driver if supported.
For backward compatibility, the call to legacy
hash functions is reserved.
Signed-off-by: Chia-Wei Wang
---
common/image-fit.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/common/image-fit.c b/common/image-fit.c
index d6b2c3c7ec..ec2e526356 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -25,6 +25,10 @@
#include
#include
#include
+#ifdef CONFIG_DM_HASH
+#include
+#include
+#endif
DECLARE_GLOBAL_DATA_PTR;
#endif /* !USE_HOSTCC*/
@@ -1214,6 +1218,31 @@ int fit_set_timestamp(void *fit, int noffset, time_t timestamp)
int calculate_hash(const void *data, int data_len, const char *algo,
uint8_t *value, int *value_len)
{
+#if !defined(USE_HOSTCC) && defined(CONFIG_DM_HASH)
This file is shared in its entirety with host tools. There isn't a huge
opportunity for using a DM-type approach here without #ifndef USE_HOSTCC.
Alex
+ int rc;
+ enum HASH_ALGO hash_algo;
+ struct udevice *dev;
+
+ rc = uclass_get_device(UCLASS_HASH, 0, );
+ if (rc) {
+ debug("failed to get hash device, rc=%d\n", rc);
+ return -1;
+ }
+
+ hash_algo = hash_algo_lookup_by_name(algo);
+ if (hash_algo == HASH_ALGO_INVALID) {
+ debug("Unsupported hash algorithm\n");
+ return -1;
+ };
+
+ rc = hash_digest_wd(dev, hash_algo, data, data_len, value, CHUNKSZ);
+ if (rc) {
+ debug("failed to get hash value, rc=%d\n", rc);
+ return -1;
+ }
+
+ *value_len = hash_algo_digest_size(hash_algo);
+#else
if (IMAGE_ENABLE_CRC32 && strcmp(algo, "crc32") == 0) {
*((uint32_t *)value) = crc32_wd(0, data, data_len,
CHUNKSZ_CRC32);
@@ -1242,6 +1271,7 @@ int calculate_hash(const void *data, int data_len, const
char *algo,
debug("Unsupported hash alogrithm\n");
return -1;
}
+#endif
return 0;
}
[PATCH] lib: rsa: fix dependency for SPL_RSA_VERIFY
SPL_RSA_VERIFY requires SPL_RSA to be enabled. Add correct dependency. Signed-off-by: Oleksandr Suvorov --- lib/rsa/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig index a90d67e5a87..cf802a6d40a 100644 --- a/lib/rsa/Kconfig +++ b/lib/rsa/Kconfig @@ -20,6 +20,7 @@ config SPL_RSA config SPL_RSA_VERIFY bool + depends on SPL_RSA help Add RSA signature verification support in SPL. -- 2.31.1
[PATCH 0/3] 30bpp framebuffer support
Apple M1 machines come up with a framebuffer that in 30bpp mode. This series adds basic support for this mode. Mark Kettenis (3): video: Add 30bpp support efi_loader: GOP: Add 30bpp support video: simplefb: Add 30bpp support drivers/video/console_normal.c| 2 ++ drivers/video/console_rotate.c| 6 ++ drivers/video/console_truetype.c | 3 +++ drivers/video/simplefb.c | 3 +++ drivers/video/vidconsole-uclass.c | 7 +++ drivers/video/video-uclass.c | 1 + include/video.h | 1 + lib/efi_loader/efi_gop.c | 10 ++ 8 files changed, 33 insertions(+) -- 2.33.0
Re: [PATCH] mtd: spi-nor: Fix SF MTDIDS when registering multiple MTDs with DM enabled
Hi,
On 9/16/21 9:50 AM, Patrick DELAUNAY wrote:
Hi,
On 9/15/21 2:10 PM, Marek Vasut wrote:
On 9/15/21 2:00 PM, Patrick DELAUNAY wrote:
Hi,
On 9/15/21 10:57 AM, Marek Vasut wrote:
On 9/15/21 10:53 AM, Patrice CHOTARD wrote:
Hi All
On 9/15/21 7:59 AM, Marek Vasut wrote:
On 9/15/21 6:23 AM, Heiko Schocher wrote:
Hi Marek,
On 15.09.21 01:06, Marek Vasut wrote:
The flash->mtd.name used to be nor%d before, now it is the
type of the
SPI NOR like e.g. mt25ql02g. It is possible to find plenty of
examples
of the former in U-Boot configs by searching for
MTDIDS.*nor.*spi, while
the later is ambiguous if there are multiple flashes of the
same type in
the system and breaks existing environments.
This does no longer get recognized when running 'mtdparts'
for example:
CONFIG_MTDIDS_DEFAULT="nor0=4704.spi.0"
Fix this by setting the correct mtd.name to nor%d.
Fixes: b7f060565e3 ("mtd: spi-nor: allow registering multiple
MTDs when DM is enabled")
Signed-off-by: Marek Vasut
Cc: Heiko Schocher
Cc: Jagan Teki
Cc: Marek Behún
Cc: Miquel Raynal
Cc: Pali Rohár
Cc: Patrice Chotard
Cc: Patrick Delaunay
Cc: Priyanka Jain
Cc: Simon Glass
---
drivers/mtd/spi/sf_mtd.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Seem fixes the same problem as Patrick already posted here:
https://patchwork.ozlabs.org/project/uboot/patch/20210913095742.v2.1.I73dae4b93f0587dc130e512e95a1f4794e0b0233@changeid/
I find your approach cleaner, so:
Acked-by: Heiko Schocher
@Patrick: Could you test this patch please?
The option from Patrick does look more predictable, but looking
at the old implementation of spi_flash_mtd_number(), that one
handled even cases of parallel-nor and spi-nor (both using the
nor%d) present on the same system. This:
static int spi_flash_mtd_number(void)
{
#ifdef CONFIG_SYS_MAX_FLASH_BANKS
return CONFIG_SYS_MAX_FLASH_BANKS;
#else
return 0;
#endif
}
...
sprintf(sf_mtd_name, "nor%d", spi_flash_mtd_number());
The patch from Patrick does not, it does per-spi-nor-only
counting using the dev_seq() there, which is more predictable,
but local to spi-nor.
The MTD core has its own IDR counting, which is used by this
patch and is global to the MTD core. That has two issues, one
is that it is possibly too global and counts both nor%d and
nand%d, which means it would fail on systems with both SPI NOR
and regular NAND. The other is it is likely less predictable
(what happens if the SPI NOR and parallel NOR gets probed in
the reverse order ? I know it is unlikely, but it can happen in
the future).
So I think we need a third option which I would suggest be
based on the patch from Patrick, but which would take into
account the other nor%d devices like parallel NOR flashes.
That would likely have to happen in the mtd core using some
modified IDR counting. I think you might need to modify it such
that you would pass in the prefix of the device (like 'nor')
and then do per-prefix counting, with the special case that
parallel NORs are counted first. Also, that would also have to
consider probing of multiple SPI NORs in either order (say you
have two, if you do 'sf probe 0:0 ; sf probe 0:1' vs. 'sf probe
0:1 ; sf probe 0:0'), and make sure they get enumerated with
the same nor%d value either way, that might be where the
dev_seq() would come in.
I just got a try with this patch and unfortunately, it doesn't
solve the issue.
I tested it on STM32MP1-ev1 board which embedds 1 NAND and 2
SPI-NORs.
Here is the output of mtd list command:
U-Boot 2021.10-rc4-1-g1923b5a21d (Sep 15 2021 - 10:48:48 +0200)
CPU: STM32MP157AAA Rev.B
Model: STMicroelectronics STM32MP157C eval daughter on eval mother
Board: stm32mp1 in basic mode (st,stm32mp157c-ev1)
Board: MB1263 Var1.0 Rev.C-01
DRAM: 1 GiB
Clocks:
- MPU : 650 MHz
- MCU : 208.878 MHz
- AXI : 266.500 MHz
- PER : 24 MHz
- DDR : 533 MHz
WDT: Started with servicing (32s timeout)
NAND: 1024 MiB
MMC: STM32 SD/MMC: 0, STM32 SD/MMC: 1
Loading Environment from MMC... *** Warning - bad CRC, using
default environment
In: serial
Out: serial
Err: serial
Net: eth0: ethernet@5800a000
Hit any key to stop autoboot: 0
STM32MP> mtd list
SF: Detected mx66l51235l with page size 256 Bytes, erase size 64
KiB, total 64 MiB
SF: Detected nor1 with page size 256 Bytes, erase size 64 KiB,
total 64 MiB
List of MTD devices:
* nand0
- type: NAND flash
- block size: 0x4 bytes
- min I/O: 0x1000 bytes
- OOB size: 224 bytes
- OOB available: 118 bytes
- ECC strength: 8 bits
- ECC step size: 512 bytes
- bitflip threshold: 6 bits
- 0x-0x4000 : "nand0"
* nor2
- device: mx66l51235l@0
- parent: spi@58003000
- driver: jedec_spi_nor
- path: /soc/spi@58003000/mx66l51235l@0
- type: NOR flash
- block size: 0x1 bytes
- min I/O: 0x1 bytes
- 0x-0x0400 : "nor2"
* nor2
Re: [PATCH v3 2/2] mtd: spi: nor: force mtd name to "nor%d"
Hi Marek, Patrick, the patches that made this change also include patch https://source.denx.de/u-boot/u-boot/-/commit/dcb9a80359d699cf659c95b9b6e6604e2d68adb9 This patch was added so that when there are multiple identical SPI-NOR chips on the board, you can still select between them in the `mtd` command via the OF path. That's why the `mtd list` command lists OF path. In the discussion with Tom, we also were talking about backwards compatibility with mtdparts, and if I remember correctly, the conclusion was that mtdparts is deprecated: - many configs with MTDPARTS can now be converted to define the partitions via OF - the remaining which can't need their mtd driver updated Afterwards there will be no need for mtdpart. I think this is the correct solution here. Not the one where we are returning back to the "norN" names. Marek
Re: [PATCH] mtd: spi: nor: force mtd name to "nor%d"
On Mon, 13 Sep 2021 09:40:50 +0200 Patrick Delaunay wrote: You can select by of path, i.e. mtd /soc/spi@58003000/mx66l51235l@0 see patch https://source.denx.de/u-boot/u-boot/-/commit/dcb9a80359d699cf659c95b9b6e6604e2d68adb9 Tom said that mtdparts is deprecated and all instances should be converted to OF. Marek
Re: [PATCH 2/4] dm: hash: Add new UCLASS_HASH support
Hi,
On 7/29/21 8:08 PM, Chia-Wei Wang wrote:
Add UCLASS_HASH for hash driver development. Thus the
hash drivers (SW or HW-accelerated) can be developed
in the DM-based fashion.
Software hashing implementations are shared tightly with host tools.
With DM, there's no opportunity for code sharing with host tools. The
design question that I have is "do we want to DM hashes, or do we want
to DM hardware accelerators for hashes?"
I did some parallel work expose remaining hash algos via
hash_lookup_algo() and hash_progressive_lookup_algo().
Signed-off-by: Chia-Wei Wang
---
drivers/crypto/Kconfig| 2 +
drivers/crypto/Makefile | 1 +
drivers/crypto/hash/Kconfig | 5 ++
drivers/crypto/hash/Makefile | 5 ++
drivers/crypto/hash/hash-uclass.c | 121 ++
include/dm/uclass-id.h| 1 +
include/u-boot/hash.h | 61 +++
7 files changed, 196 insertions(+)
create mode 100644 drivers/crypto/hash/Kconfig
create mode 100644 drivers/crypto/hash/Makefile
create mode 100644 drivers/crypto/hash/hash-uclass.c
create mode 100644 include/u-boot/hash.h
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 1ea116be75..0082177c21 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -1,5 +1,7 @@
menu "Hardware crypto devices"
+source drivers/crypto/hash/Kconfig
+
Hashes are useful outside of cryptographic functions, so it seems odd to
merge them in crypto. For example, CRC32 is not a hash useful in crypto,
but otherwise widely used in u-boot.
[snip]
diff --git a/drivers/crypto/hash/hash-uclass.c
b/drivers/crypto/hash/hash-uclass.c
new file mode 100644
index 00..446eb9e56a
--- /dev/null
+++ b/drivers/crypto/hash/hash-uclass.c
@@ -0,0 +1,121 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2021 ASPEED Technology Inc.
+ * Author: ChiaWei Wang
+ */
+
+#define LOG_CATEGORY UCLASS_HASH
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct hash_info {
+ char *name;
+ uint32_t digest_size;
+};
+
+static const struct hash_info hash_info[HASH_ALGO_NUM] = {
+ [HASH_ALGO_CRC16_CCITT] = { "crc16-ccitt", 2 },
+ [HASH_ALGO_CRC32] = { "crc32", 4 },
+ [HASH_ALGO_MD5] = { "md5", 16 },
+ [HASH_ALGO_SHA1] = { "sha1", 20 },
+ [HASH_ALGO_SHA256] = { "sha256", 32 },
+ [HASH_ALGO_SHA384] = { "sha384", 48 },
+ [HASH_ALGO_SHA512] = { "sha512", 64},
+};
It seems a step backwards to have to enum {} our hash algos, since we
already identify them by their strings (e.g. "sha256"). and then
associated ops structure. The
+
+enum HASH_ALGO hash_algo_lookup_by_name(const char *name)
string -> hash_lookup_algo() -> ops struct
Is the current way to do things. hash_algo_lookup_by_name() does the
roundabout through an enum. That doesn't make sense to me.
Alex
[PATCH v3 2/2] mtd: spi: nor: force mtd name to "nor%d"
Force the mtd name of spi-nor to "nor" + the driver sequence number:
"nor0", "nor1"... beginning after the existing nor devices.
This patch is coherent with existing "nand" and "spi-nand"
mtd device names.
When CFI MTD NOR device are supported, the spi-nor index is chosen after
the last CFI device defined by CONFIG_SYS_MAX_FLASH_BANKS.
When CONFIG_SYS_MAX_FLASH_BANKS_DETECT is activated, this config
is replaced by to cfi_flash_num_flash_banks in the include file
mtd/cfi_flash.h.
This generic name "nor%d" can be use to identify the mtd spi-nor device
without knowing the real device name or the DT path of the device,
used with API get_mtd_device_nm() and is used in mtdparts command.
This patch also avoids issue when the same NOR device is present 2 times,
for example on STM32MP15F-EV1:
STM32MP> mtd list
SF: Detected mx66l51235l with page size 256 Bytes, erase size 64 KiB, \
total 64 MiB
List of MTD devices:
* nand0
- type: NAND flash
- block size: 0x4 bytes
- min I/O: 0x1000 bytes
- OOB size: 224 bytes
- OOB available: 118 bytes
- ECC strength: 8 bits
- ECC step size: 512 bytes
- bitflip threshold: 6 bits
- 0x-0x4000 : "nand0"
* mx66l51235l
- device: mx66l51235l@0
- parent: spi@58003000
- driver: jedec_spi_nor
- path: /soc/spi@58003000/mx66l51235l@0
- type: NOR flash
- block size: 0x1 bytes
- min I/O: 0x1 bytes
- 0x-0x0400 : "mx66l51235l"
* mx66l51235l
- device: mx66l51235l@1
- parent: spi@58003000
- driver: jedec_spi_nor
- path: /soc/spi@58003000/mx66l51235l@1
- type: NOR flash
- block size: 0x1 bytes
- min I/O: 0x1 bytes
- 0x-0x0400 : "mx66l51235l"
The same mtd name "mx66l51235l" identify the 2 instances
mx66l51235l@0 and mx66l51235l@1.
This patch fixes a ST32CubeProgrammer / stm32prog command issue
with nor0 target on STM32MP157C-EV1 board introduced by
commit b7f060565e31 ("mtd: spi-nor: allow registering multiple MTDs when
DM is enabled").
Fixes: b7f060565e31 ("mtd: spi-nor: allow registering multiple MTDs when DM is
enabled")
Signed-off-by: Patrick Delaunay
---
For other device, the mtd name are hardcoded in each MTD driver:
drivers/mtd/nand/spi/core.c:1169:
sprintf(mtd->name, "spi-nand%d", spi_nand_idx++);
drivers/mtd/nand/raw/nand.c:59:
sprintf(dev_name[devnum], "nand%d", devnum);
And the nor device name "nor%d" is also used for CFI in
./drivers/mtd/cfi_mtd.c with i=0 to CONFIG_SYS_MAX_FLASH_BANKS - 1
sprintf(cfi_mtd_names[i], "nor%d", i);
mtd->name = cfi_mtd_names[i];
Today the number of CFI device is hardcoded by this config.
Changes in v3:
- start index after the last CFI device, use CONFIG_SYS_MAX_FLASH_BANKS
Changes in v2:
- correct commit message
drivers/mtd/spi/spi-nor-core.c | 15 ---
include/linux/mtd/spi-nor.h| 1 +
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index d5d905fa5a..7da5ca6285 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -10,6 +10,7 @@
*/
#include
+#include
#include
#include
#include
@@ -26,6 +27,7 @@
#include
#include
+#include
#include
#include
@@ -3664,6 +3666,11 @@ int spi_nor_scan(struct spi_nor *nor)
struct mtd_info *mtd = >mtd;
struct spi_slave *spi = nor->spi;
int ret;
+ int cfi_mtd_nb = 0;
+
+#ifdef CONFIG_SYS_MAX_FLASH_BANKS
+ cfi_mtd_nb = CONFIG_SYS_MAX_FLASH_BANKS;
+#endif
/* Reset SPI protocol for all commands. */
nor->reg_proto = SNOR_PROTO_1_1_1;
@@ -3715,8 +3722,10 @@ int spi_nor_scan(struct spi_nor *nor)
if (ret)
return ret;
- if (!mtd->name)
- mtd->name = info->name;
+ if (!mtd->name) {
+ sprintf(nor->mtd_name, "nor%d", cfi_mtd_nb +
dev_seq(nor->dev));
+ mtd->name = nor->mtd_name;
+ }
mtd->dev = nor->dev;
mtd->priv = nor;
mtd->type = MTD_NORFLASH;
@@ -3821,7 +3830,7 @@ int spi_nor_scan(struct spi_nor *nor)
nor->rdsr_dummy = params.rdsr_dummy;
nor->rdsr_addr_nbytes = params.rdsr_addr_nbytes;
- nor->name = mtd->name;
+ nor->name = info->name;
nor->size = mtd->size;
nor->erase_size = mtd->erasesize;
nor->sector_size = mtd->erasesize;
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 7ddc4ba2bf..8c3d5032e3 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -561,6 +561,7 @@ struct spi_nor {
int (*ready)(struct spi_nor *nor);
void *priv;
+ char mtd_name[10];
/* Compatibility for spi_flash, remove once sf layer is merged with mtd */
const char *name;
u32 size;
--
2.25.1
Re: [PATCH] mtd: spi-nor: Fix SF MTDIDS when registering multiple MTDs with DM enabled
On Wed, 15 Sep 2021 01:06:22 +0200 Marek Vasut wrote: > The flash->mtd.name used to be nor%d before, now it is the type of the > SPI NOR like e.g. mt25ql02g. It is possible to find plenty of examples > of the former in U-Boot configs by searching for MTDIDS.*nor.*spi, while > the later is ambiguous if there are multiple flashes of the same type in > the system and breaks existing environments. > > This does no longer get recognized when running 'mtdparts' for example: > CONFIG_MTDIDS_DEFAULT="nor0=4704.spi.0" > > Fix this by setting the correct mtd.name to nor%d. CONFIG_MTDIDS_DEFAULT="nor0=4704.spi.0" is defined for configs/am65x_evm_a53_defconfig and configs/am65x_hs_evm_a53_defconfig both using device tree arch/arm/dts/k3-am654-base-board.dts where you have defined DT node flash@0. Just add partition subnodes, and then you won't need mtdparts. This can be done for most users of mtdparts, and we won't to convert mtdpart to OF and get rid of it. Marek
[PATCH 3/3] video: simplefb: Add 30bpp support
Recognize the canonical format strings for framebuffers in
30bpp mode.
Signed-off-by: Mark Kettenis
---
drivers/video/simplefb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
index fd58426cf5..7e1cc4560f 100644
--- a/drivers/video/simplefb.c
+++ b/drivers/video/simplefb.c
@@ -52,6 +52,9 @@ static int simple_video_probe(struct udevice *dev)
uc_priv->bpix = VIDEO_BPP16;
} else if (strcmp(format, "a8b8g8r8") == 0) {
uc_priv->bpix = VIDEO_BPP32;
+ } else if (strcmp(format, "a2r10g10b10") == 0 ||
+ strcmp(format, "x2r10g10b10") == 0) {
+ uc_priv->bpix = VIDEO_BPP30;
} else {
printf("%s: invalid format: %s\n", __func__, format);
return -EINVAL;
--
2.33.0
[PATCH 1/3] video: Add 30bpp support
Add support for 30bpp mode where pixels are picked in 32-bit
integers but use 10 bits instead of 8 bits for each component.
Signed-off-by: Mark Kettenis
---
drivers/video/console_normal.c| 2 ++
drivers/video/console_rotate.c| 6 ++
drivers/video/console_truetype.c | 3 +++
drivers/video/vidconsole-uclass.c | 7 +++
drivers/video/video-uclass.c | 1 +
include/video.h | 1 +
6 files changed, 20 insertions(+)
diff --git a/drivers/video/console_normal.c b/drivers/video/console_normal.c
index 04f022491e..e0b89cbb93 100644
--- a/drivers/video/console_normal.c
+++ b/drivers/video/console_normal.c
@@ -41,6 +41,7 @@ static int console_normal_set_row(struct udevice *dev, uint
row, int clr)
end = dst;
break;
}
+ case VIDEO_BPP30:
case VIDEO_BPP32:
if (IS_ENABLED(CONFIG_VIDEO_BPP32)) {
uint32_t *dst = line;
@@ -126,6 +127,7 @@ static int console_normal_putc_xy(struct udevice *dev, uint
x_frac, uint y,
}
break;
}
+ case VIDEO_BPP30:
case VIDEO_BPP32:
if (IS_ENABLED(CONFIG_VIDEO_BPP32)) {
uint32_t *dst = line;
diff --git a/drivers/video/console_rotate.c b/drivers/video/console_rotate.c
index 36c8d0609d..bf81b80a39 100644
--- a/drivers/video/console_rotate.c
+++ b/drivers/video/console_rotate.c
@@ -40,6 +40,7 @@ static int console_set_row_1(struct udevice *dev, uint row,
int clr)
*dst++ = clr;
break;
}
+ case VIDEO_BPP30:
case VIDEO_BPP32:
if (IS_ENABLED(CONFIG_VIDEO_BPP32)) {
uint32_t *dst = line;
@@ -128,6 +129,7 @@ static int console_putc_xy_1(struct udevice *dev, uint
x_frac, uint y, char ch)
}
break;
}
+ case VIDEO_BPP30:
case VIDEO_BPP32:
if (IS_ENABLED(CONFIG_VIDEO_BPP32)) {
uint32_t *dst = line;
@@ -183,6 +185,7 @@ static int console_set_row_2(struct udevice *dev, uint row,
int clr)
end = dst;
break;
}
+ case VIDEO_BPP30:
case VIDEO_BPP32:
if (IS_ENABLED(CONFIG_VIDEO_BPP32)) {
uint32_t *dst = line;
@@ -266,6 +269,7 @@ static int console_putc_xy_2(struct udevice *dev, uint
x_frac, uint y, char ch)
}
break;
}
+ case VIDEO_BPP30:
case VIDEO_BPP32:
if (IS_ENABLED(CONFIG_VIDEO_BPP32)) {
uint32_t *dst = line;
@@ -318,6 +322,7 @@ static int console_set_row_3(struct udevice *dev, uint row,
int clr)
*dst++ = clr;
break;
}
+ case VIDEO_BPP30:
case VIDEO_BPP32:
if (IS_ENABLED(CONFIG_VIDEO_BPP32)) {
uint32_t *dst = line;
@@ -402,6 +407,7 @@ static int console_putc_xy_3(struct udevice *dev, uint
x_frac, uint y, char ch)
}
break;
}
+ case VIDEO_BPP30:
case VIDEO_BPP32:
if (IS_ENABLED(CONFIG_VIDEO_BPP32)) {
uint32_t *dst = line;
diff --git a/drivers/video/console_truetype.c b/drivers/video/console_truetype.c
index 98427f4c61..0195d996de 100644
--- a/drivers/video/console_truetype.c
+++ b/drivers/video/console_truetype.c
@@ -153,6 +153,7 @@ static int console_truetype_set_row(struct udevice *dev,
uint row, int clr)
}
#endif
#ifdef CONFIG_VIDEO_BPP32
+ case VIDEO_BPP30:
case VIDEO_BPP32: {
u32 *dst = line;
@@ -299,6 +300,7 @@ static int console_truetype_putc_xy(struct udevice *dev,
uint x, uint y,
}
#endif
#ifdef CONFIG_VIDEO_BPP32
+ case VIDEO_BPP30:
case VIDEO_BPP32: {
u32 *dst = (u32 *)line + xoff;
int i;
@@ -381,6 +383,7 @@ static int console_truetype_erase(struct udevice *dev, int
xstart, int ystart,
}
#endif
#ifdef CONFIG_VIDEO_BPP32
+ case VIDEO_BPP30:
case VIDEO_BPP32: {
uint32_t *dst = line;
diff --git a/drivers/video/vidconsole-uclass.c
b/drivers/video/vidconsole-uclass.c
index 8132efa55a..cc274b45fe 100644
--- a/drivers/video/vidconsole-uclass.c
+++
[PATCH 2/3] efi_loader: GOP: Add 30bpp support
Provide correct framebuffer information for 30bpp modes.
Signed-off-by: Mark Kettenis
---
lib/efi_loader/efi_gop.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c
index 1206b2d7a2..42bf49b184 100644
--- a/lib/efi_loader/efi_gop.c
+++ b/lib/efi_loader/efi_gop.c
@@ -227,6 +227,7 @@ static efi_uintn_t gop_get_bpp(struct efi_gop *this)
switch (gopobj->bpix) {
#ifdef CONFIG_DM_VIDEO
+ case VIDEO_BPP30:
case VIDEO_BPP32:
#else
case LCD_COLOR32:
@@ -468,6 +469,7 @@ efi_status_t efi_gop_register(void)
switch (bpix) {
#ifdef CONFIG_DM_VIDEO
case VIDEO_BPP16:
+ case VIDEO_BPP30:
case VIDEO_BPP32:
#else
case LCD_COLOR32:
@@ -518,6 +520,14 @@ efi_status_t efi_gop_register(void)
#endif
{
gopobj->info.pixel_format = EFI_GOT_BGRA8;
+#ifdef CONFIG_DM_VIDEO
+ } else if (bpix == VIDEO_BPP30) {
+ gopobj->info.pixel_format = EFI_GOT_BITMASK;
+ gopobj->info.pixel_bitmask[0] = 0x3ff0; /* red */
+ gopobj->info.pixel_bitmask[1] = 0x000ffc00; /* green */
+ gopobj->info.pixel_bitmask[2] = 0x03ff; /* blue */
+ gopobj->info.pixel_bitmask[3] = 0xc000; /* reserved */
+#endif
} else {
gopobj->info.pixel_format = EFI_GOT_BITMASK;
gopobj->info.pixel_bitmask[0] = 0xf800; /* red */
--
2.33.0
[PATCH v3 0/2] mtd: spi: nor: force mtd name to "nor%d"
This serie is a V3 for http://patchwork.ozlabs.org/project/uboot/list/?series=262017=* http://patchwork.ozlabs.org/project/uboot/list/?series=262013=* Now the SPI nor are named "norN" with N after the CFI nor device: "nor0" to "norM" => N= M+1. See also an other proposal from Marek (not working after test) "mtd: spi-nor: Fix SF MTDIDS when registering multiple MTDs with DM enabled" http://patchwork.ozlabs.org/project/uboot/list/?series=262362 The first patch of the serie fixed the compilation issues around 'cfi_flash_num_flash_banks' found in CI: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/9138 Patrick Changes in v3: - NEW: solve compilation issue when CONFIG_SYS_MAX_FLASH_BANKS is used - start index after the last CFI device, use CONFIG_SYS_MAX_FLASH_BANKS Changes in v2: - correct commit message Patrick Delaunay (2): mtd: cfi_flash: use cfi_flash_num_flash_banks only when supported mtd: spi: nor: force mtd name to "nor%d" drivers/mtd/spi/spi-nor-core.c | 15 --- include/linux/mtd/spi-nor.h| 1 + include/mtd/cfi_flash.h| 8 +++- 3 files changed, 20 insertions(+), 4 deletions(-) -- 2.25.1
[PATCH v3 1/2] mtd: cfi_flash: use cfi_flash_num_flash_banks only when supported
When CONFIG_SYS_MAX_FLASH_BANKS_DETECT is activated,
CONFIG_SYS_MAX_FLASH_BANKS is replaced by cfi_flash_num_flash_banks,
but this variable is defined in drivers/mtd/cfi_flash.c, which is
compiled only when CONFIG_FLASH_CFI_DRIVER is activated, in U-Boot
or in SPL when CONFIG_SPL_MTD_SUPPORT is activated.
This patch deactivates this feature CONFIG_SYS_MAX_FLASH_BANKS_DETECT
when flash cfi driver is not activated to avoid compilation issue in
the next patch, when CONFIG_SYS_MAX_FLASH_BANKS is used in spi_nor_scan().
Signed-off-by: Patrick Delaunay
---
see error in
https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/9138
drivers/mtd/spi/spi-nor-core.o: in function `spi_nor_scan':
drivers/mtd/spi/spi-nor-core.c:3672:
undefined reference to `cfi_flash_num_flash_banks'
compilation issue for the boards:
- j721e_hs_evm_r5
- j721e_evm_r5j
- j721e_hs_evm_a72
- j721e_evm_a72
- sagem_f@st1704_ram
Changes in v3:
- NEW: solve compilation issue when CONFIG_SYS_MAX_FLASH_BANKS is used
include/mtd/cfi_flash.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/mtd/cfi_flash.h b/include/mtd/cfi_flash.h
index 4963c89642..a1af6fc200 100644
--- a/include/mtd/cfi_flash.h
+++ b/include/mtd/cfi_flash.h
@@ -157,11 +157,17 @@ struct cfi_pri_hdr {
* Use CONFIG_SYS_MAX_FLASH_BANKS_DETECT if defined
*/
#if defined(CONFIG_SYS_MAX_FLASH_BANKS_DETECT)
-#define CONFIG_SYS_MAX_FLASH_BANKS (cfi_flash_num_flash_banks)
#define CFI_MAX_FLASH_BANKSCONFIG_SYS_MAX_FLASH_BANKS_DETECT
+/* map to cfi_flash_num_flash_banks only when supported */
+#if IS_ENABLED(CONFIG_FLASH_CFI_DRIVER) && \
+(!IS_ENABLED(CONFIG_SPL_BUILD) || IS_ENABLED(CONFIG_SPL_MTD_SUPPORT))
+#define CONFIG_SYS_MAX_FLASH_BANKS (cfi_flash_num_flash_banks)
/* board code can update this variable before CFI detection */
extern int cfi_flash_num_flash_banks;
#else
+#define CONFIG_SYS_MAX_FLASH_BANKS CONFIG_SYS_MAX_FLASH_BANKS_DETECT
+#endif
+#else
#define CFI_MAX_FLASH_BANKSCONFIG_SYS_MAX_FLASH_BANKS
#endif
--
2.25.1
[PATCH] usb: xhci-dwc3: Add support for USB 3.1 controllers
This adds support for the DWC_sub31 controllers such as those
found on Apple's M1 SoC. This version of the controller
seems to work fine with the existing driver.
Signed-off-by: Mark Kettenis
---
drivers/usb/host/xhci-dwc3.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-dwc3.c b/drivers/usb/host/xhci-dwc3.c
index 3e0ae80cec..a2ea40bae0 100644
--- a/drivers/usb/host/xhci-dwc3.c
+++ b/drivers/usb/host/xhci-dwc3.c
@@ -70,7 +70,8 @@ int dwc3_core_init(struct dwc3 *dwc3_reg)
revision = readl(_reg->g_snpsid);
/* This should read as U3 followed by revision number */
- if ((revision & DWC3_GSNPSID_MASK) != 0x5533) {
+ if ((revision & DWC3_GSNPSID_MASK) != 0x5533 &&
+ (revision & DWC3_GSNPSID_MASK) != 0x3331) {
puts("this is not a DesignWare USB3 DRD Core\n");
return -1;
}
--
2.33.0
Re: [PATCH] usb: xhci-dwc3: Add support for USB 3.1 controllers
On Thu, Sep 16, 2021 at 10:00 PM Mark Kettenis wrote: > > This adds support for the DWC_sub31 controllers such as those > found on Apple's M1 SoC. This version of the controller > seems to work fine with the existing driver. > > Signed-off-by: Mark Kettenis > --- > drivers/usb/host/xhci-dwc3.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > Reviewed-by: Bin Meng
[PATCH] fs: fat: check for buffer size before reading blocks
From: Ricardo Salveti
This patch optimizes the commit mentioned below by avoiding running
a set of commands which useless in the case when
size < mydata->sect_size and idx would be 0.
Fixes: 5b3ddb17ba ("fs/fat/fat.c: Do not perform zero block reads if there are
no blocks left")
Signed-off-by: Ricardo Salveti
Co-developed-by: Oleksandr Suvorov
Signed-off-by: Oleksandr Suvorov
---
fs/fat/fat.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 7021138b987..4a509755442 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -275,14 +275,10 @@ get_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer,
unsigned long size)
buffer += mydata->sect_size;
size -= mydata->sect_size;
}
- } else {
+ } else if (size >= mydata->sect_size) {
__u32 idx;
-
idx = size / mydata->sect_size;
- if (idx == 0)
- ret = 0;
- else
- ret = disk_read(startsect, idx, buffer);
+ ret = disk_read(startsect, idx, buffer);
if (ret != idx) {
debug("Error reading data (got %d)\n", ret);
return -1;
--
2.31.1
Re: [PATCH] imx: imx7d-sdb: fix ethernet, sync .dts with linux
Hi Rasmus, On Thu, Sep 16, 2021 at 11:53 AM Rasmus Villemoes wrote: > > Commit 0d52bab46 (mx7dsabre: Enable DM_ETH) changed these flags from 0 > (aka GPIO_ACTIVE_HIGH) to GPIO_ACTIVE_LOW. It claimed to "Also sync > device tree with v5.5-rc1", but in the linux tree, these gpios have > always been GPIO_ACTIVE_HIGH ever since this node was introduced > around v4.13 (linux commit 184f39b5). > > I'm guessing that the reason for the GPIO_ACTIVE_LOW was to work > around the behaviour of the soft-spi driver back then, which > effectively defaulted to spi-mode 3 and not 0. That was arguably a bug > in the soft-spi driver, which then got fixed in 0e146993bb3 (spi: add > support for all spi modes with soft spi), but that commit then broke > ethernet on this board. > > Fix it by setting the gpios as active high, which as a bonus actually > brings us in sync with the .dts in the linux source tree. > > Without this, one gets > > Net: Could not get PHY for FEC0: addr 0 > No ethernet found. > > With this, ethernet (at least ping and tftp) works as expected from > the U-Boot shell. > > Cc: Fabio Estevam > Cc: Joris Offouga > Cc: "Christian Bräuner Sørensen" > Signed-off-by: Rasmus Villemoes Thanks for the fix: Reviewed-by: Fabio Estevam
Re: [PATCH] xtensa: Put U-Boot version string at correct place by linker script
On Thu, Sep 16, 2021 at 01:30:21PM -0400, Tom Rini wrote: > *(.literal .text) \ > + *(.literal .text_version_string)\ Isn't ".litteral" a duplication? Even if I'm pretty sure it will not cause any difference in the generated binary I would remove it. Francesco
Re: [PATCH 2/2] cmd: Add CONFIG_FIT_SIGNATURE_STRICT
Hi Igor,
On Thu, Sep 16, 2021 at 6:09 PM Igor Opaniuk wrote:
>
> Hi Oleksandr,
>
> On Thu, Sep 16, 2021 at 4:10 PM Oleksandr Suvorov
> wrote:
> >
> > From: Ricardo Salveti
> >
> > Add CONFIG_FIT_SIGNATURE_STRICT to require a valid FIT configuration
> > signature for each command that is able to manipulate FIT images.
> >
> > Signed-off-by: Ricardo Salveti
> > Co-developed-by: Oleksandr Suvorov
> > Signed-off-by: Oleksandr Suvorov
> > ---
> >
> > cmd/fpga.c | 14 ++
> > cmd/source.c| 14 ++
> > cmd/ximg.c | 14 ++
> > common/Kconfig.boot | 4
> > 4 files changed, 46 insertions(+)
> >
> > diff --git a/cmd/fpga.c b/cmd/fpga.c
> > index 3fdd0b35e80..16d329590fa 100644
> > --- a/cmd/fpga.c
> > +++ b/cmd/fpga.c
> > @@ -335,6 +335,20 @@ static int do_fpga_loadmk(struct cmd_tbl *cmdtp, int
> > flag, int argc,
> > return CMD_RET_FAILURE;
> > }
> >
> > + if (CONFIG_IS_ENABLED(FIT_SIGNATURE_STRICT)) {
> > + /* validate required fit config entry */
> > + noffset = fit_conf_get_node(fit_hdr, NULL);
> > + if (noffset >= 0) {
> > + if (fit_config_verify(fit_hdr, noffset)) {
> > + puts("Cannot verify FIT config
> > node\n");
> > + return CMD_RET_FAILURE;
> > + }
> > + } else {
> > + puts("FIT_SIGNATURE_STRICT requires a
> > config node\n");
> > + return CMD_RET_FAILURE;
> > + }
> > + }
> > +
> > /* get fpga component image node offset */
> > noffset = fit_image_get_node(fit_hdr, fit_uname);
> > if (noffset < 0) {
> > diff --git a/cmd/source.c b/cmd/source.c
> > index 81e015b64ef..b08406dfcbf 100644
> > --- a/cmd/source.c
> > +++ b/cmd/source.c
> > @@ -112,6 +112,20 @@ int image_source_script(ulong addr, const char
> > *fit_uname)
> > return 1;
> > }
> >
> > + if (CONFIG_IS_ENABLED(FIT_SIGNATURE_STRICT)) {
> > + /* validate required fit config entry */
> > + noffset = fit_conf_get_node(fit_hdr, NULL);
> > + if (noffset >= 0) {
> > + if (fit_config_verify(fit_hdr, noffset)) {
> > + puts("Cannot verify FIT config
> > node\n");
> > + return 1;
> > + }
> > + } else {
> > + puts("FIT_SIGNATURE_STRICT requires a
> > config node\n");
> > + return 1;
> > + }
> > + }
> > +
> > if (!fit_uname)
> > fit_uname = get_default_image(fit_hdr);
> >
> > diff --git a/cmd/ximg.c b/cmd/ximg.c
> > index 65ba41320a0..39fccd8179c 100644
> > --- a/cmd/ximg.c
> > +++ b/cmd/ximg.c
> > @@ -141,6 +141,20 @@ do_imgextract(struct cmd_tbl *cmdtp, int flag, int
> > argc, char *const argv[])
> > return 1;
> > }
> >
> > + if (CONFIG_IS_ENABLED(FIT_SIGNATURE_STRICT)) {
> > + /* validate required fit config entry */
> > + noffset = fit_conf_get_node(fit_hdr, NULL);
> > + if (noffset >= 0) {
> > + if (fit_config_verify(fit_hdr, noffset)) {
> > + puts("Cannot verify FIT config
> > node\n");
> > + return 1;
> > + }
> > + } else {
> > + puts("FIT_SIGNATURE_STRICT requires a
> > config node\n");
> > + return 1;
> > + }
> > + }
> > +
> > /* get subimage node offset */
> > noffset = fit_image_get_node(fit_hdr, uname);
> > if (noffset < 0) {
> > diff --git a/common/Kconfig.boot b/common/Kconfig.boot
> > index 6f95d009dfa..ca7d9a8d971 100644
> > --- a/common/Kconfig.boot
> > +++ b/common/Kconfig.boot
> > @@ -77,6 +77,10 @@ config FIT_SIGNATURE_MAX_SIZE
> > device memory. Assure this size does not extend past expected
> > storage
> > space.
> >
> > +config FIT_SIGNATURE_STRICT
> > + bool "Requires a valid FIT configuration signature for every image"
> > + select FIT_SIGNATURE
> > +
> > config FIT_RSASSA_PSS
> > bool "Support rsassa-pss signature scheme of FIT image contents"
> > depends on FIT_SIGNATURE
> > --
> > 2.31.1
> >
>
> There is duplication of the same piece of code in 3 different files,
>
Re: [PATCH v2 3/3] mx7ulp_com: add support for SPL
Hi Oleksandr, On Thu, Sep 16, 2021 at 3:50 PM Oleksandr Suvorov wrote: > The SPL for this board is built with prepended DCD which includes DDR > training data (defined in imximage.cfg). So that the bootrom initializes > DDR using DCD before jumping to SPL. > Is it mandatory to move DDR init in C code for SPL-enabled setups? > We wouldn't be changing it for now :( If the SPL is currently not doing its minimum task of configuring DDR, why do we need SPL in the first place?
Re: [PATCH] xtensa: Put U-Boot version string at correct place by linker script
On Thu, Sep 16, 2021 at 09:38:19PM +0200, Francesco Dolcini wrote: > On Thu, Sep 16, 2021 at 01:30:21PM -0400, Tom Rini wrote: > > *(.literal .text) \ > > + *(.literal .text_version_string)\ > > Isn't ".litteral" a duplication? Even if I'm pretty sure it will not cause > any difference > in the generated binary I would remove it. Honestly, I don't know xtensa. We also don't have qemu support for it currently, and I'm a bit worried in general about the state of the platform (it's on my TODO list to poke some people now). So, I hesitate to make any change that's not basically copy/paste of the existing lines. -- Tom signature.asc Description: PGP signature
Re: [PATCH] xtensa: Put U-Boot version string at correct place by linker script
On Thu, Sep 16, 2021 at 09:50:35PM +0200, Francesco Dolcini wrote:
> On Thu, Sep 16, 2021 at 03:42:20PM -0400, Tom Rini wrote:
> > On Thu, Sep 16, 2021 at 09:38:19PM +0200, Francesco Dolcini wrote:
> > > On Thu, Sep 16, 2021 at 01:30:21PM -0400, Tom Rini wrote:
> > > > *(.literal .text)
> > > > \
> > > > + *(.literal .text_version_string)
> > > > \
> > >
> > > Isn't ".litteral" a duplication? Even if I'm pretty sure it will not
> > > cause any difference
> > > in the generated binary I would remove it.
> >
> > Honestly, I don't know xtensa. We also don't have qemu support for it
> > currently, and I'm a bit worried in general about the state of the
> > platform (it's on my TODO list to poke some people now). So, I hesitate
> > to make any change that's not basically copy/paste of the existing
> > lines.
>
> I have no experience on xtensa either, but this is just the section
> name, and you are just telling to put ".literal" there 2 times.
I don't know. Looking at the resulting linker script (and with your
suggestion):
.text (((0x2000 - 0x2000) + ((128 << 20))) - 0x0004) :
AT(((LOADADDR(.DoubleExceptionVector.text) +
SIZEOF(.DoubleExceptionVector.text) + 4 -1)) & ~(4 -1)) { _text_start =
ABSOLUTE(.); *(.literal .text) *(.text_version_string) *(.literal.* .text.*
.stub) *(.gnu.warning .gnu.linkonce.literal.*) *(.gnu.linkonce.t.*.literal
.gnu.linkonce.t.*)
*(.fini.literal) *(.fini) *(.gnu.version) _text_end = ABSOLUTE(.); }
So there's "literal" scattered everywhere. If it doesn't matter, it
reads more consistently to me to toss literal in one more time. But I
emailed around and we'll see if xtensa stays around, it's also our
oldest toolchain and virtually untouched since submission :(
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] xtensa: Put U-Boot version string at correct place by linker script
On Thu, Sep 16, 2021 at 04:13:31PM -0400, Tom Rini wrote:
> On Thu, Sep 16, 2021 at 09:50:35PM +0200, Francesco Dolcini wrote:
> > On Thu, Sep 16, 2021 at 03:42:20PM -0400, Tom Rini wrote:
> > > On Thu, Sep 16, 2021 at 09:38:19PM +0200, Francesco Dolcini wrote:
> > > > On Thu, Sep 16, 2021 at 01:30:21PM -0400, Tom Rini wrote:
> > > > > *(.literal .text)
> > > > > \
> > > > > + *(.literal .text_version_string)
> > > > > \
> > > >
> > > > Isn't ".litteral" a duplication? Even if I'm pretty sure it will not
> > > > cause any difference
> > > > in the generated binary I would remove it.
> > >
> > > Honestly, I don't know xtensa. We also don't have qemu support for it
> > > currently, and I'm a bit worried in general about the state of the
> > > platform (it's on my TODO list to poke some people now). So, I hesitate
> > > to make any change that's not basically copy/paste of the existing
> > > lines.
> >
> > I have no experience on xtensa either, but this is just the section
> > name, and you are just telling to put ".literal" there 2 times.
>
> I don't know. Looking at the resulting linker script (and with your
> suggestion):
> .text (((0x2000 - 0x2000) + ((128 << 20))) - 0x0004) :
> AT(((LOADADDR(.DoubleExceptionVector.text) +
> SIZEOF(.DoubleExceptionVector.text) + 4 -1)) & ~(4 -1)) { _text_start =
> ABSOLUTE(.); *(.literal .text) *(.text_version_string) *(.literal.* .text.*
> .stub) *(.gnu.warning .gnu.linkonce.literal.*) *(.gnu.linkonce.t.*.literal
> .gnu.linkonce.t.*)
> *(.fini.literal) *(.fini) *(.gnu.version) _text_end = ABSOLUTE(.); }
>
> So there's "literal" scattered everywhere. If it doesn't matter, it
> reads more consistently to me to toss literal in one more time.
Heheh, ".literal" is present only once here, ".literal.*" is matching something
else, likewise all the others that are scathered all around. This looks fine to
me.
> But I emailed around and we'll see if xtensa stays around, it's also our
> oldest toolchain and virtually untouched since submission :(
My small comment is just about the linker script format, I guess some other
folk should be able to confirm what I wrote. Unfortunately it will not solve
the general problem with xtensa ...
Francesco
Re: [PATCH v3 2/2] mtd: spi: nor: force mtd name to "nor%d"
On 9/16/21 4:01 PM, Patrick Delaunay wrote:
[...]
@@ -3664,6 +3666,11 @@ int spi_nor_scan(struct spi_nor *nor)
struct mtd_info *mtd = >mtd;
struct spi_slave *spi = nor->spi;
int ret;
+ int cfi_mtd_nb = 0;
+
+#ifdef CONFIG_SYS_MAX_FLASH_BANKS
+ cfi_mtd_nb = CONFIG_SYS_MAX_FLASH_BANKS;
+#endif
Are we covering all the NORs (HF and co.) with this ?
/* Reset SPI protocol for all commands. */
nor->reg_proto = SNOR_PROTO_1_1_1;
@@ -3715,8 +3722,10 @@ int spi_nor_scan(struct spi_nor *nor)
if (ret)
return ret;
- if (!mtd->name)
- mtd->name = info->name;
+ if (!mtd->name) {
+ sprintf(nor->mtd_name, "nor%d", cfi_mtd_nb +
dev_seq(nor->dev));
+ mtd->name = nor->mtd_name;
+ }
mtd->dev = nor->dev;
mtd->priv = nor;
mtd->type = MTD_NORFLASH;
@@ -3821,7 +3830,7 @@ int spi_nor_scan(struct spi_nor *nor)
nor->rdsr_dummy = params.rdsr_dummy;
nor->rdsr_addr_nbytes = params.rdsr_addr_nbytes;
- nor->name = mtd->name;
+ nor->name = info->name;
nor->size = mtd->size;
nor->erase_size = mtd->erasesize;
nor->sector_size = mtd->erasesize;
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 7ddc4ba2bf..8c3d5032e3 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -561,6 +561,7 @@ struct spi_nor {
int (*ready)(struct spi_nor *nor);
void *priv;
+ char mtd_name[10];
should be 14, because nor%d\0 can be up to 14 bytes long.
Re: [PATCH v3 1/2] mtd: cfi_flash: use cfi_flash_num_flash_banks only when supported
On 9/16/21 4:01 PM, Patrick Delaunay wrote: When CONFIG_SYS_MAX_FLASH_BANKS_DETECT is activated, CONFIG_SYS_MAX_FLASH_BANKS is replaced by cfi_flash_num_flash_banks, but this variable is defined in drivers/mtd/cfi_flash.c, which is compiled only when CONFIG_FLASH_CFI_DRIVER is activated, in U-Boot or in SPL when CONFIG_SPL_MTD_SUPPORT is activated. This patch deactivates this feature CONFIG_SYS_MAX_FLASH_BANKS_DETECT when flash cfi driver is not activated to avoid compilation issue in the next patch, when CONFIG_SYS_MAX_FLASH_BANKS is used in spi_nor_scan(). Maybe just migrate this config option to Kconfig and let Kconfig handle the macro magic ?
Re: [PATCH v3 0/2] mtd: spi: nor: force mtd name to "nor%d"
On 9/16/21 4:01 PM, Patrick Delaunay wrote: This serie is a V3 for http://patchwork.ozlabs.org/project/uboot/list/?series=262017=* http://patchwork.ozlabs.org/project/uboot/list/?series=262013=* Now the SPI nor are named "norN" with N after the CFI nor device: "nor0" to "norM" => N= M+1. See also an other proposal from Marek (not working after test) "mtd: spi-nor: Fix SF MTDIDS when registering multiple MTDs with DM enabled" http://patchwork.ozlabs.org/project/uboot/list/?series=262362 The first patch of the serie fixed the compilation issues around 'cfi_flash_num_flash_banks' found in CI: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/9138 Patrick This looks good to me, except for a few nits.
Re: [PATCH] mtd: spi-nor: Fix SF MTDIDS when registering multiple MTDs with DM enabled
On 9/16/21 5:16 PM, Marek Behún wrote: On Wed, 15 Sep 2021 01:06:22 +0200 Marek Vasut wrote: The flash->mtd.name used to be nor%d before, now it is the type of the SPI NOR like e.g. mt25ql02g. It is possible to find plenty of examples of the former in U-Boot configs by searching for MTDIDS.*nor.*spi, while the later is ambiguous if there are multiple flashes of the same type in the system and breaks existing environments. This does no longer get recognized when running 'mtdparts' for example: CONFIG_MTDIDS_DEFAULT="nor0=4704.spi.0" Fix this by setting the correct mtd.name to nor%d. CONFIG_MTDIDS_DEFAULT="nor0=4704.spi.0" is defined for configs/am65x_evm_a53_defconfig and configs/am65x_hs_evm_a53_defconfig both using device tree arch/arm/dts/k3-am654-base-board.dts where you have defined DT node flash@0. Just add partition subnodes, and then you won't need mtdparts. This can be done for most users of mtdparts, and we won't to convert mtdpart to OF and get rid of it. You are assuming that every system is capable of updating either DT or env, that is not always the case.
Re: [PATCH 1/2] spl: Add CONFIG_SPL_FIT_SIGNATURE_STRICT
Hi Oleksandr
On 9/16/21 8:09 AM, Oleksandr Suvorov wrote:
From: Henry Beberman
SPL FIT load checks the signature on loadable images but just continues
in the case of a failure. This is undesirable behavior because the boot
process depends on the authenticity of each loadable part.
Adding CONFIG_SPL_FIT_SIGNATURE_STRICT to halt the platform when any
image fails its signature check, including loadable parts.
This sounds very similar to what FIT config verification already does,
so I don't understand the motivation behind this patch.
SPL already supports image signature verification but had no mechanism
to check that the FIT's configuration block was signed correctly.
This statement is incorrect. This is exactly what required = "conf";
in u-boot's devicetree is intended to do.
NAK
Add a check near the start of spl_load_simple_fit that verifies the
FIT's configuration block, and fails if it's not present or the
signature doesn't match what's stored in the SPL DTB.
Signed-off-by: Henry Beberman
Signed-off-by: Ricardo Salveti
Co-developed-by: Oleksandr Suvorov
Signed-off-by: Oleksandr Suvorov
---
common/Kconfig.boot | 7 +++
common/spl/spl_fit.c | 21 -
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/common/Kconfig.boot b/common/Kconfig.boot
index 902a5b8fbea..6f95d009dfa 100644
--- a/common/Kconfig.boot
+++ b/common/Kconfig.boot
@@ -166,6 +166,13 @@ config SPL_FIT_SIGNATURE
select SPL_IMAGE_SIGN_INFO
select SPL_FIT_FULL_CHECK
+config SPL_FIT_SIGNATURE_STRICT
+ bool "Halt if loadables or firmware don't pass FIT signature
verification"
+ select SPL_FIT_SIGNATURE
+ help
+ Strictly requires each loadable or firmware in a FIT image to be
+ passed verification. Halt if any loadable fails to be verified.
+
config SPL_LOAD_FIT
bool "Enable SPL loading U-Boot as a FIT (basic fitImage features)"
select SPL_FIT
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index f41abca0ccb..e7eaaa4cb9e 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -315,7 +315,12 @@ static int spl_load_fit_image(struct spl_load_info *info,
ulong sector,
printf("## Checking hash(es) for Image %s ... ",
fit_get_name(fit, node, NULL));
if (!fit_image_verify_with_data(fit, node, src, length))
- return -EPERM;
+ if (CONFIG_IS_ENABLED(FIT_SIGNATURE_STRICT)) {
+ puts("Invalid FIT signature found in a required
image.\n");
+ hang();
hang() is rarely the appropriate thing to do. Once you get -EPERM you
could choose to either
a) drop to a lower privilege level
b) enter some sort of recovery mode
c) outright hang.
spl_load_fit_image() isn't the right place to decide (a) or (b), so by
extension, it's the wrong place to decide (c).
+ } else {
+ return -EPERM;
+ }
puts("OK\n");
}
@@ -681,6 +686,20 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
if (ret < 0)
return ret;
+ if (CONFIG_IS_ENABLED(FIT_SIGNATURE_STRICT)) {
+ int cfg_noffset = fit_conf_get_node(fit, NULL);
+
+ if (cfg_noffset >= 0) {
+ if (fit_config_verify(fit, cfg_noffset)) {
+ puts("Unable to verify the required FIT
config.\n");
+ hang();
+ }
+ } else {
+ puts("SPL_FIT_SIGNATURE_STRICT needs a config node in
FIT\n");
+ hang();
+ }
+ }
+
/* skip further processing if requested to enable load-only use cases */
if (spl_load_simple_fit_skip_processing())
return 0;
Re: [PATCH 10/11] sandbox: mmc: Support a backing file
On Wed, Aug 18, 2021 at 09:40:32PM -0600, Simon Glass wrote: > Provide a way for sandbox MMC to present data from a backing file. This > allows a filesystem to be created on the host and easily served via an > emulated mmc device. > > Signed-off-by: Simon Glass > Reviewed-by: Jaehoon Chung > --- > > doc/device-tree-bindings/mmc/sandbox,mmc.txt | 18 > drivers/mmc/sandbox_mmc.c| 46 > 2 files changed, 55 insertions(+), 9 deletions(-) > create mode 100644 doc/device-tree-bindings/mmc/sandbox,mmc.txt As is, this breaks how I've always run pytests on sandbox. -- Tom signature.asc Description: PGP signature
Re: [PATCH] xtensa: Put U-Boot version string at correct place by linker script
On Thu, Sep 16, 2021 at 03:42:20PM -0400, Tom Rini wrote: > On Thu, Sep 16, 2021 at 09:38:19PM +0200, Francesco Dolcini wrote: > > On Thu, Sep 16, 2021 at 01:30:21PM -0400, Tom Rini wrote: > > > *(.literal .text) \ > > > + *(.literal .text_version_string)\ > > > > Isn't ".litteral" a duplication? Even if I'm pretty sure it will not cause > > any difference > > in the generated binary I would remove it. > > Honestly, I don't know xtensa. We also don't have qemu support for it > currently, and I'm a bit worried in general about the state of the > platform (it's on my TODO list to poke some people now). So, I hesitate > to make any change that's not basically copy/paste of the existing > lines. I have no experience on xtensa either, but this is just the section name, and you are just telling to put ".literal" there 2 times. Francesco
[PATCH] xtensa: Put U-Boot version string at correct place by linker script
Update the linker script macros to know that we need to include the
.text_version_string section now as well.
Signed-off-by: Tom Rini
---
arch/xtensa/include/asm/ldscript.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/xtensa/include/asm/ldscript.h
b/arch/xtensa/include/asm/ldscript.h
index 08f5d0135ed0..84c496e09f1b 100644
--- a/arch/xtensa/include/asm/ldscript.h
+++ b/arch/xtensa/include/asm/ldscript.h
@@ -72,6 +72,7 @@
{ \
_text_start = ABSOLUTE(.); \
*(.literal .text) \
+ *(.literal .text_version_string)\
*(.literal.* .text.* .stub) \
*(.gnu.warning .gnu.linkonce.literal.*) \
*(.gnu.linkonce.t.*.literal .gnu.linkonce.t.*) \
--
2.17.1
Re: [PATCH v2 3/3] mx7ulp_com: add support for SPL
Hi Fabio, On Wed, Sep 15, 2021 at 9:21 PM Fabio Estevam wrote: > > Hi Igor, > > On Wed, Sep 15, 2021 at 1:04 PM Igor Opaniuk > wrote: > > > Maybe I misunderstood your question, > > but it's already in board/ea/mx7ulp_com/mx7ulp_com.c, no? > > The DDR initialization is currently at board/ea/mx7ulp_com/imximage.cfg. > > If the board supports SPL, I was expecting to see the DDR > initialization happen in C code instead. The SPL for this board is built with prepended DCD which includes DDR training data (defined in imximage.cfg). So that the bootrom initializes DDR using DCD before jumping to SPL. Is it mandatory to move DDR init in C code for SPL-enabled setups? We wouldn't be changing it for now :( > Regards, > > Fabio Estevam -- Best regards Oleksandr Oleksandr Suvorov cryo...@gmail.com
Re: [PATCH v2] powerpc: mpc: Put U-Boot version string at correct place by linker script
On Sun, Aug 08, 2021 at 01:20:38PM +0200, Pali Rohár wrote: > It is unknown why version string is placed at specific position on these > powerpc mpc platforms. But there is no need to overload version_string > symbol. Just use common definition of version_string and modify linker > script to put it at "correct place". > > Signed-off-by: Pali Rohár > --- > Changes in v2: > * Put explicit ".section" keyword before declaring ".text_pre" section as > some gcc versions cannot recognize specifying custom section without it. > * Tested compilation for: > $ make CROSS_COMPILE=powerpc-linux-gnu- MCR3000_defconfig u-boot.bin > and checked that u-boot.bin header is same with and without this patch Please note that qemu-ppce500 still fails to build, now with a different error: https://source.denx.de/u-boot/u-boot/-/jobs/323027 which I am investigating how to resolve. -- Tom signature.asc Description: PGP signature
[PATCH] mailmap: Update mail address for Nicolas Saenz julienne
From: Nicolas Saenz Julienne The @suse.de address doesn't exist anymore. Update it to something not dependent on my workplace. Signed-off-by: Nicolas Saenz Julienne --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index b76f02283c..b09fc321bd 100644 --- a/.mailmap +++ b/.mailmap @@ -32,6 +32,7 @@ Jagan Teki Igor Opaniuk Igor Opaniuk Markus Klotzbuecher +Nicolas Saenz Julienne Patrice Chotard Patrick Delaunay Paul Burton -- 2.31.1
Re: [PATCH v3 2/2] mtd: spi: nor: force mtd name to "nor%d"
On Thu, 16 Sep 2021 16:01:18 +0200 Patrick Delaunay wrote: > Force the mtd name of spi-nor to "nor" + the driver sequence number: > "nor0", "nor1"... beginning after the existing nor devices. > > This patch is coherent with existing "nand" and "spi-nand" > mtd device names. > > When CFI MTD NOR device are supported, the spi-nor index is chosen after > the last CFI device defined by CONFIG_SYS_MAX_FLASH_BANKS. > > When CONFIG_SYS_MAX_FLASH_BANKS_DETECT is activated, this config > is replaced by to cfi_flash_num_flash_banks in the include file > mtd/cfi_flash.h. > > This generic name "nor%d" can be use to identify the mtd spi-nor device > without knowing the real device name or the DT path of the device, > used with API get_mtd_device_nm() and is used in mtdparts command. > > This patch also avoids issue when the same NOR device is present 2 times, > for example on STM32MP15F-EV1: This is an unfortunate hack :( This is another reason why the whole mtd subsystem should be refactored.
IMX8MM fsl_esdhc_imx UHS/HS200/HS400 not working?
Greetings, Can anyone confirm if IMX8MM UHS/HS200/HS400 is working for them? I had this working in my U-Boot v2021.01 imx8mm-veice branch but it seems to not work in U-Boot master or v2021.07. I know there was a lot of back and forth on this... perhaps I missed something. I haven't been able to bisect yet as I had a lot of patches on top of my v2021.01 branch. Best regards, Tim
Re: [PATCH] fs: fat: check for buffer size before reading blocks
On 9/16/21 4:09 PM, Oleksandr Suvorov wrote:
From: Ricardo Salveti
This patch optimizes the commit mentioned below by avoiding running
a set of commands which useless in the case when
%s/which/which are/
size < mydata->sect_size and idx would be 0.
Thank you for reviewing the FAT coding.
Fixes: 5b3ddb17ba ("fs/fat/fat.c: Do not perform zero block reads if there are no
blocks left")
Signed-off-by: Ricardo Salveti
Co-developed-by: Oleksandr Suvorov
Signed-off-by: Oleksandr Suvorov
---
fs/fat/fat.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 7021138b987..4a509755442 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -275,14 +275,10 @@ get_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer,
unsigned long size)
buffer += mydata->sect_size;
size -= mydata->sect_size;
}
- } else {
+ } else if (size >= mydata->sect_size) {
__u32 idx;
The variable name idx is a misnomer. Can we call it sect_count?
-
idx = size / mydata->sect_size;
- if (idx == 0)
- ret = 0;
size could be 0. In this case we still have to set ret = 0. Both for the
DMA aligned and the unaligned case. You could initialize ret = 0 where
it is defined.
- else
- ret = disk_read(startsect, idx, buffer);
+ ret = disk_read(startsect, idx, buffer);
if (ret != idx) {
debug("Error reading data (got %d)\n", ret);
return -1;
291 idx *= mydata->sect_size;
292 buffer += idx;
293 size -= idx;
These lines should be adjusted, too: size is defined as unsigned long.
We should not use the u32 variable idx but a separate variable of type
unsigned long to hold the number of bytes read.
Best regards
Heinrich
Re: [PATCH 0/3] efi_selftest: Update SIMPLE_NETWORK_PROTOCOL selftest
On 9/16/21 10:53 AM, Masami Hiramatsu wrote:
Hello Heinrich,
Here is a series of patches to update the SIMPLE_NETWORK_PROTOCOL
according to the explanation in the previous thread [1].
[1] https://lists.denx.de/pipermail/u-boot/2021-September/460711.html
So basically this seires modifies the SNP testcase as I said
in the previous mail [1].
net->get_status();
if (!net->mode.MediaPresent) {
error(no link up!)
return;
}
submit_dhcp_discover()
for (;;) {
wait_for_event(net)
while (net->receive() != EFI_NOT_READY) {
// check dhcp reply
}
}
I removed EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT check because
that is just expectation what the received packet avaiability
is meaning that the EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT flag
bit is set. Of course U-Boot EFI SNP implementation does it,
but that is not ensured in the UEFI spec. The spec said that
SN_GetStatus() in edk2-platforms
Drivers/ASIX/Bus/Usb/UsbNetworking/Ax88179/SimpleNetwork.c always
returns *InterruptStatus = 0.
the get_status() should update the MediaPresent flag (which
means the network link up or down). So I added the get_status()
test case before starting the network test so that it can
test the link status.
BTW, actually the mode->media_present is not supported yet.
Is there any way to get the network link status?
The driver interface struct eth_ops has no method for determining media
presence. We have to assume that it is always present.
Best regards
Heinrich
Thank you,
---
Masami Hiramatsu (3):
efi_selftest: Use EFI_SIMPLE_NETWORK_PROTOCOL::GetStatus() for media
check
efi_selftest: Do not check EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT
efi_selftest: Recieve the packets until the receive buffer is empty
lib/efi_selftest/efi_selftest_snp.c | 90 +++
1 file changed, 49 insertions(+), 41 deletions(-)
--
Masami Hiramatsu
[PATCH] imx: imx7d-sdb: fix ethernet, sync .dts with linux
Commit 0d52bab46 (mx7dsabre: Enable DM_ETH) changed these flags from 0 (aka GPIO_ACTIVE_HIGH) to GPIO_ACTIVE_LOW. It claimed to "Also sync device tree with v5.5-rc1", but in the linux tree, these gpios have always been GPIO_ACTIVE_HIGH ever since this node was introduced around v4.13 (linux commit 184f39b5). I'm guessing that the reason for the GPIO_ACTIVE_LOW was to work around the behaviour of the soft-spi driver back then, which effectively defaulted to spi-mode 3 and not 0. That was arguably a bug in the soft-spi driver, which then got fixed in 0e146993bb3 (spi: add support for all spi modes with soft spi), but that commit then broke ethernet on this board. Fix it by setting the gpios as active high, which as a bonus actually brings us in sync with the .dts in the linux source tree. Without this, one gets Net: Could not get PHY for FEC0: addr 0 No ethernet found. With this, ethernet (at least ping and tftp) works as expected from the U-Boot shell. Cc: Fabio Estevam Cc: Joris Offouga Cc: "Christian Bräuner Sørensen" Signed-off-by: Rasmus Villemoes --- arch/arm/dts/imx7d-sdb.dts | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/dts/imx7d-sdb.dts b/arch/arm/dts/imx7d-sdb.dts index 8191ac7c33..ea2e58dd5a 100644 --- a/arch/arm/dts/imx7d-sdb.dts +++ b/arch/arm/dts/imx7d-sdb.dts @@ -44,9 +44,9 @@ compatible = "spi-gpio"; pinctrl-names = "default"; pinctrl-0 = <_spi4>; - gpio-sck = < 13 GPIO_ACTIVE_LOW>; - gpio-mosi = < 9 GPIO_ACTIVE_LOW>; - cs-gpios = < 12 GPIO_ACTIVE_LOW>; + gpio-sck = < 13 GPIO_ACTIVE_HIGH>; + gpio-mosi = < 9 GPIO_ACTIVE_HIGH>; + cs-gpios = < 12 GPIO_ACTIVE_HIGH>; num-chipselects = <1>; #address-cells = <1>; #size-cells = <0>; -- 2.31.1
Re: [PATCH 2/3] efi_loader: GOP: Add 30bpp support
On 9/16/21 3:01 PM, Mark Kettenis wrote:
Provide correct framebuffer information for 30bpp modes.
This is not enough to get a correct GOP implementation for the 30bpp mode.
Have a look at efi_gop_pixel efi_vid16_to_blt_col() and
efi_blt_col_to_vid16() and where they are used.
Signed-off-by: Mark Kettenis
---
lib/efi_loader/efi_gop.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/lib/efi_loader/efi_gop.c b/lib/efi_loader/efi_gop.c
index 1206b2d7a2..42bf49b184 100644
--- a/lib/efi_loader/efi_gop.c
+++ b/lib/efi_loader/efi_gop.c
@@ -227,6 +227,7 @@ static efi_uintn_t gop_get_bpp(struct efi_gop *this)
switch (gopobj->bpix) {
#ifdef CONFIG_DM_VIDEO
+ case VIDEO_BPP30:
case VIDEO_BPP32:
#else
case LCD_COLOR32:
@@ -468,6 +469,7 @@ efi_status_t efi_gop_register(void)
switch (bpix) {
#ifdef CONFIG_DM_VIDEO
case VIDEO_BPP16:
+ case VIDEO_BPP30:
case VIDEO_BPP32:
#else
case LCD_COLOR32:
@@ -518,6 +520,14 @@ efi_status_t efi_gop_register(void)
#endif
{
gopobj->info.pixel_format = EFI_GOT_BGRA8;
+#ifdef CONFIG_DM_VIDEO
This symbol is not 30bpp specific. Is there a Kconfig variable that we
can use to hide 30bpp support where it is not needed?
Which modes does the M1 support?
Best regards
Heinrich
+ } else if (bpix == VIDEO_BPP30) {
+ gopobj->info.pixel_format = EFI_GOT_BITMASK;
+ gopobj->info.pixel_bitmask[0] = 0x3ff0; /* red */
+ gopobj->info.pixel_bitmask[1] = 0x000ffc00; /* green */
+ gopobj->info.pixel_bitmask[2] = 0x03ff; /* blue */
+ gopobj->info.pixel_bitmask[3] = 0xc000; /* reserved */
+#endif
} else {
gopobj->info.pixel_format = EFI_GOT_BITMASK;
gopobj->info.pixel_bitmask[0] = 0xf800; /* red */
[PATCH 1/1] powerpc: Drop version_string placement optimization
As explained by Wolfgang, historically PowerPC would do a number of things to hand-optimize placement of the binary on NOR flash in order to maximize utilization of very scarce resources. These days, we simply aren't optimizing our binary layout for NOR flash placement and it's quite likely this wasn't working as intended. Furthermore, this level of optimization makes it difficult to have version_string be a global, instead of a weak and overridden value, and so make more progress on reproducible builds, which is a current concern. Move to having PowerPC no longer store version_string in the early part of text so that it might be part of the first page of NOR and instead use the same declaration everyone else does. Link: https://lore.kernel.org/r/96716.1629798...@gemini.denx.de/ Signed-off-by: Tom Rini --- arch/powerpc/cpu/mpc83xx/start.S | 7 --- arch/powerpc/cpu/mpc85xx/start.S | 5 - arch/powerpc/cpu/mpc8xx/start.S | 4 3 files changed, 16 deletions(-) diff --git a/arch/powerpc/cpu/mpc83xx/start.S b/arch/powerpc/cpu/mpc83xx/start.S index 9da22ce486a9..c4953df4a271 100644 --- a/arch/powerpc/cpu/mpc83xx/start.S +++ b/arch/powerpc/cpu/mpc83xx/start.S @@ -13,7 +13,6 @@ #include #include #include -#include #define CONFIG_83XX1 /* needed for Linux kernel header files*/ @@ -92,12 +91,6 @@ */ .long 0x27051956 /* U-Boot Magic Number */ - .globl version_string -version_string: - .ascii U_BOOT_VERSION_STRING, "\0" - - .align 2 - .globl enable_addr_trans enable_addr_trans: /* enable address translation */ diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S index f41e82ad189f..aca31b24c079 100644 --- a/arch/powerpc/cpu/mpc85xx/start.S +++ b/arch/powerpc/cpu/mpc85xx/start.S @@ -14,7 +14,6 @@ #include #include #include -#include #include #include @@ -1138,11 +1137,7 @@ switch_as: .globl _start _start: .long 0x27051956 /* U-BOOT Magic Number */ - .globl version_string -version_string: - .ascii U_BOOT_VERSION_STRING, "\0" - .align 4 .globl _start_cont _start_cont: /* Setup the stack in initial RAM,could be L2-as-SRAM or L1 dcache*/ diff --git a/arch/powerpc/cpu/mpc8xx/start.S b/arch/powerpc/cpu/mpc8xx/start.S index ed735cdee005..0ebb7b33a8bc 100644 --- a/arch/powerpc/cpu/mpc8xx/start.S +++ b/arch/powerpc/cpu/mpc8xx/start.S @@ -23,7 +23,6 @@ #include #include #include -#include #include #include @@ -62,9 +61,6 @@ */ .text .long 0x27051956 /* U-Boot Magic Number */ - .globl version_string -version_string: - .ascii U_BOOT_VERSION_STRING, "\0" . = EXC_OFF_SYS_RESET .globl _start -- 2.17.1
Re: [PATCH] xtensa: Put U-Boot version string at correct place by linker script
On Thu, Sep 16, 2021 at 12:42 PM Tom Rini wrote: > We also don't have qemu support for it I'm curious what happened to it and what I should do to update it? xtensa is still supported in the QEMU and AFAIK nothing has changed about it: neither building nor invocation. -- Thanks. -- Max
Re: [PATCH 0/3] efi_selftest: Update SIMPLE_NETWORK_PROTOCOL selftest
Hi Heinrich,
2021年9月17日(金) 12:54 Heinrich Schuchardt :
>
> On 9/16/21 10:53 AM, Masami Hiramatsu wrote:
> > Hello Heinrich,
> >
> > Here is a series of patches to update the SIMPLE_NETWORK_PROTOCOL
> > according to the explanation in the previous thread [1].
> >
> > [1] https://lists.denx.de/pipermail/u-boot/2021-September/460711.html
> >
> > So basically this seires modifies the SNP testcase as I said
> > in the previous mail [1].
> >
> >
> > net->get_status();
> > if (!net->mode.MediaPresent) {
> > error(no link up!)
> > return;
> > }
> >
> > submit_dhcp_discover()
> > for (;;) {
> > wait_for_event(net)
> > while (net->receive() != EFI_NOT_READY) {
> >// check dhcp reply
> > }
> > }
> >
> >
> > I removed EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT check because
> > that is just expectation what the received packet avaiability
> > is meaning that the EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT flag
> > bit is set. Of course U-Boot EFI SNP implementation does it,
> > but that is not ensured in the UEFI spec. The spec said that
>
> SN_GetStatus() in edk2-platforms
> Drivers/ASIX/Bus/Usb/UsbNetworking/Ax88179/SimpleNetwork.c always
> returns *InterruptStatus = 0.
Yes, it seems to depend on driver implementation.
>
> > the get_status() should update the MediaPresent flag (which
> > means the network link up or down). So I added the get_status()
> > test case before starting the network test so that it can
> > test the link status.
> >
> > BTW, actually the mode->media_present is not supported yet.
> > Is there any way to get the network link status?
>
> The driver interface struct eth_ops has no method for determining media
> presence. We have to assume that it is always present.
Hmm, OK. So we can not implement it...
Thank you,
>
> Best regards
>
> Heinrich
>
> >
> > Thank you,
> >
> > ---
> >
> > Masami Hiramatsu (3):
> >efi_selftest: Use EFI_SIMPLE_NETWORK_PROTOCOL::GetStatus() for media
> > check
> >efi_selftest: Do not check EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT
> >efi_selftest: Recieve the packets until the receive buffer is empty
> >
> >
> > lib/efi_selftest/efi_selftest_snp.c | 90
> > +++
> > 1 file changed, 49 insertions(+), 41 deletions(-)
> >
> > --
> > Masami Hiramatsu
> >
>
--
Masami Hiramatsu
Re: [PATCH 1/2] sunxi: Simplify MMC pinmux selection
On 9/16/21 5:42 AM, Andre Przywara wrote:
> On 12/09/2021 16:28, Samuel Holland wrote:
>> Only one board, Yones Toptech BD1078, actually uses a non-default MMC
>> pinmux. All other uses of these symbols select the default value or an
>> invalid value. To simplify things, remove support for the unused pinmux
>> options, and convert the remaining option to a Boolean.
>>
>> This allows the pinmux to be chosen by the preprocessor, instead of
>> having the code parse a string at runtime (for a build-time option!).
>> Not only does this reduce code size, but it also allows this Kconfig
>> option to be used in a table-driven DM pinctrl driver.
>
> That's a very nice cleanup, and I like the diffstat, so thanks very much.
>
> Actually it made me wonder if we can't go a step further, and replace
> all the #ifdef's with if (IS_ENABLED()). So I gave this a try and it
> seems to work - see below. I will double check that they are equivalent,
> but would be interested what you think and if that somehow clashes with
> your future plans.
I have no additional patches to this function, so your patch does not
conflict with anything.
My future plan is to require CONFIG_SPL_DM on RISC-V, and let the
mostly-existing #ifdefs take care of leaving out the non-DM setup code.
I also plan to get CONFIG_SPL_DM at least somewhat working on ARM, since
I can test things incrementally there, before I dive into SPL on RISC-V.
Cheers,
Samuel
> But we should take this patch as a step here anyway. I checked that the
> transformations are correct, so:
>
>> Signed-off-by: Samuel Holland
>
> Reviewed-by: Andre Przywara
>
> (on top of your patch)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index f98d370342..45d40d7847 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -411,166 +411,123 @@ void board_nand_init(void)
> #ifdef CONFIG_MMC
> static void mmc_pinmux_setup(int sdc)
> {
> - unsigned int pin;
> + unsigned int pin, start_pin = ~0, mux = ~0, num_pins = 6;
>
> switch (sdc) {
> - case 0:
> - /* SDC0: PF0-PF5 */
> - for (pin = SUNXI_GPF(0); pin <= SUNXI_GPF(5); pin++) {
> - sunxi_gpio_set_cfgpin(pin, SUNXI_GPF_SDC0);
> - sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
> - sunxi_gpio_set_drv(pin, 2);
> - }
> + case 0: /* SDC0: PF0-PF5 */
> + start_pin = SUNXI_GPF(0);
> + mux = SUNXI_GPF_SDC0;
> break;
>
> case 1:
> -#if defined(CONFIG_MACH_SUN4I) || defined(CONFIG_MACH_SUN7I) || \
> - defined(CONFIG_MACH_SUN8I_R40)
> - if (IS_ENABLED(CONFIG_MMC1_PINS_PH)) {
> - /* SDC1: PH22-PH-27 */
> - for (pin = SUNXI_GPH(22); pin <= SUNXI_GPH(27); pin++) {
> - sunxi_gpio_set_cfgpin(pin, SUN4I_GPH_SDC1);
> - sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
> - sunxi_gpio_set_drv(pin, 2);
> + if (IS_ENABLED(CONFIG_MACH_SUN4I) ||
> + IS_ENABLED(CONFIG_MACH_SUN7I) ||
> + IS_ENABLED(CONFIG_MACH_SUN8I_R40)) {
> + if (IS_ENABLED(CONFIG_MMC1_PINS_PH)) {
> + start_pin = SUNXI_GPH(22);
> + mux = SUN4I_GPH_SDC1;
> + } else {
> + start_pin = SUNXI_GPG(0);
> + mux = SUN4I_GPG_SDC1;
> }
> - } else {
> - /* SDC1: PG0-PG5 */
> - for (pin = SUNXI_GPG(0); pin <= SUNXI_GPG(5); pin++) {
> - sunxi_gpio_set_cfgpin(pin, SUN4I_GPG_SDC1);
> - sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
> - sunxi_gpio_set_drv(pin, 2);
> - }
> - }
> -#elif defined(CONFIG_MACH_SUN5I)
> - /* SDC1: PG3-PG8 */
> - for (pin = SUNXI_GPG(3); pin <= SUNXI_GPG(8); pin++) {
> - sunxi_gpio_set_cfgpin(pin, SUN5I_GPG_SDC1);
> - sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
> - sunxi_gpio_set_drv(pin, 2);
> - }
> -#elif defined(CONFIG_MACH_SUN6I)
> - /* SDC1: PG0-PG5 */
> - for (pin = SUNXI_GPG(0); pin <= SUNXI_GPG(5); pin++) {
> - sunxi_gpio_set_cfgpin(pin, SUN6I_GPG_SDC1);
> - sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
> - sunxi_gpio_set_drv(pin, 2);
> + } else if (IS_ENABLED(CONFIG_MACH_SUN5I)) {
> + start_pin = SUNXI_GPG(3);
> + mux = SUN5I_GPG_SDC1;
> + } else if (IS_ENABLED(CONFIG_MACH_SUN6I)) {
> + start_pin = SUNXI_GPG(0);
> + mux = SUN6I_GPG_SDC1;
> + } else if (IS_ENABLED(CONFIG_MACH_SUN8I)) {
> + start_pin = SUNXI_GPG(0);
> + mux = SUN8I_GPG_SDC1;
> }
> -#elif defined(CONFIG_MACH_SUN8I)
> - /* SDC1: PG0-PG5 */
> - for (pin = SUNXI_GPG(0); pin <= SUNXI_GPG(5); pin++) {
> - sunxi_gpio_set_cfgpin(pin, SUN8I_GPG_SDC1);
> - sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
> - sunxi_gpio_set_drv(pin, 2);
> - }
> -#endif
> break;
>
Re: [PATCH] xtensa: Put U-Boot version string at correct place by linker script
On Thu, Sep 16, 2021 at 10:30 AM Tom Rini wrote:
>
> Update the linker script macros to know that we need to include the
> .text_version_string section now as well.
>
> Signed-off-by: Tom Rini
> ---
> arch/xtensa/include/asm/ldscript.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/xtensa/include/asm/ldscript.h
> b/arch/xtensa/include/asm/ldscript.h
> index 08f5d0135ed0..84c496e09f1b 100644
> --- a/arch/xtensa/include/asm/ldscript.h
> +++ b/arch/xtensa/include/asm/ldscript.h
> @@ -72,6 +72,7 @@
> { \
> _text_start = ABSOLUTE(.); \
> *(.literal .text) \
> + *(.literal .text_version_string)\
This does not belong to .text, as far as I understand it's rodata and so
it should go with rodata, probably like this:
---8<---
diff --git a/arch/xtensa/include/asm/ldscript.h
b/arch/xtensa/include/asm/ldscript.h
index 08f5d0135ed0..e03fcffdd6f1 100644
--- a/arch/xtensa/include/asm/ldscript.h
+++ b/arch/xtensa/include/asm/ldscript.h
@@ -87,6 +87,7 @@
_rodata_start = ABSOLUTE(.);\
*(.rodata) \
*(.rodata.*)\
+ *(.text_version_string) \
*(.dtb.init.rodata) \
*(.gnu.linkonce.r.*)\
*(.rodata1) \
---8<---
--
Thanks.
-- Max
Re: [PATCH 1/1] fs: avoid superfluous messages
On Thu, Sep 16, 2021 at 10:10:20AM +0200, Heinrich Schuchardt wrote:
> Output like the following is quite irritating:
>
> => bootefi hello
> Scanning disk mmc2.blk...
> No valid Btrfs found
> Bad magic number for SquashFS image.
> ** Unrecognized filesystem type **
> Scanning disk mmc1.blk...
> No valid Btrfs found
> Bad magic number for SquashFS image.
> ** Unrecognized filesystem type **
> Scanning disk mmc0.blk...
> No valid Btrfs found
> Bad magic number for SquashFS image.
> ** Unrecognized filesystem type **
>
> It is expected that a whole disk (partition number 0) doesn't contain a
> filesystem.
A whole disk *can* contain a filesystem in general.
Please correct the commit message.
-Takahiro Akashi
> Partitions may only contain a blob. This situation is only
> worth a debug message.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> fs/fs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/fs.c b/fs/fs.c
> index 7c682582c8..023f89cafe 100644
> --- a/fs/fs.c
> +++ b/fs/fs.c
> @@ -37,7 +37,7 @@ static int fs_type = FS_TYPE_ANY;
> static inline int fs_probe_unsupported(struct blk_desc *fs_dev_desc,
> struct disk_partition *fs_partition)
> {
> - log_err("** Unrecognized filesystem type **\n");
> + log_debug("Unrecognized filesystem type\n");
> return -1;
> }
>
> --
> 2.32.0
>
[PATCH v4] apalis/colibri_imx6: move setting bootcmd to defconfig
Move setting the default boot command to the apalis/colibri_imx6_defconfig. It allows replacing the command without code modification. Signed-off-by: Oleksandr Suvorov Reviewed-by: Peng Fan Reviewed-by: Igor Opaniuk Acked-by: Marcel Ziswiler --- Changes in v4: - add an acked-by record. Changes in v3: - fix Peng Fan's e-mail address. Changes in v2: - fix spaces after semicolon. - add reviewed-by records. configs/apalis_imx6_defconfig | 1 + configs/colibri_imx6_defconfig | 1 + include/configs/apalis_imx6.h | 4 include/configs/colibri_imx6.h | 4 4 files changed, 2 insertions(+), 8 deletions(-) diff --git a/configs/apalis_imx6_defconfig b/configs/apalis_imx6_defconfig index a0e85ba23a4..f64b1ca4378 100644 --- a/configs/apalis_imx6_defconfig +++ b/configs/apalis_imx6_defconfig @@ -23,6 +23,7 @@ CONFIG_DISTRO_DEFAULTS=y CONFIG_FIT=y CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" CONFIG_BOOTDELAY=1 +CONFIG_BOOTCOMMAND="run distro_bootcmd; usb start; setenv stdout serial,vidconsole; setenv stdin serial,usbkbd" # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_BOARD_EARLY_INIT_F=y diff --git a/configs/colibri_imx6_defconfig b/configs/colibri_imx6_defconfig index 47b1cfb1917..373d6476ddc 100644 --- a/configs/colibri_imx6_defconfig +++ b/configs/colibri_imx6_defconfig @@ -22,6 +22,7 @@ CONFIG_DISTRO_DEFAULTS=y CONFIG_FIT=y CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg" CONFIG_BOOTDELAY=1 +CONFIG_BOOTCOMMAND="run distro_bootcmd; usb start; setenv stdout serial,vidconsole; setenv stdin serial,usbkbd" # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_BOARD_EARLY_INIT_F=y diff --git a/include/configs/apalis_imx6.h b/include/configs/apalis_imx6.h index 12de0105c6c..ade479cb943 100644 --- a/include/configs/apalis_imx6.h +++ b/include/configs/apalis_imx6.h @@ -133,10 +133,6 @@ #endif #define CONFIG_EXTRA_ENV_SETTINGS \ BOOTENV \ - "bootcmd=run distro_bootcmd ; " \ - "usb start ; " \ - "setenv stdout serial,vidconsole; " \ - "setenv stdin serial,usbkbd\0" \ "boot_file=zImage\0" \ "console=ttymxc0\0" \ "defargs=enable_wait_mode=off vmalloc=400M\0" \ diff --git a/include/configs/colibri_imx6.h b/include/configs/colibri_imx6.h index 804a144a03e..f91d6b49ea8 100644 --- a/include/configs/colibri_imx6.h +++ b/include/configs/colibri_imx6.h @@ -115,10 +115,6 @@ #define FDT_FILE "imx6dl-colibri-eval-v3.dtb" #define CONFIG_EXTRA_ENV_SETTINGS \ BOOTENV \ - "bootcmd=run distro_bootcmd; " \ - "usb start ; " \ - "setenv stdout serial,vidconsole; " \ - "setenv stdin serial,usbkbd\0" \ "boot_file=zImage\0" \ "console=ttymxc0\0" \ "defargs=enable_wait_mode=off galcore.contiguousSize=50331648\0" \ -- 2.31.1
Re: RFC: exclude partitions from efi_selftest
Am 16.09.2021 um 11:37 schrieb AKASHI Takahiro: On Thu, Sep 16, 2021 at 11:14:01AM +0200, Michael Lawnick wrote: Am 16.09.2021 um 10:02 schrieb AKASHI Takahiro: On Thu, Sep 16, 2021 at 09:48:07AM +0200, Michael Lawnick wrote: Am 16.09.2021 um 09:15 schrieb Michael Lawnick: - What is the reason/use to iterate through the recognized partitions even twice (in .setup and .execute) if they aren't needed/used? What line of code do you exactly mean by 'in .setup' (and in .execute)? My understanding: efi_selftests register their methods separated by setup/execute/teardown. The central test control is taking tests from list and executes the three methods, unaware of which exact test is executed: lib/efi_selftest/efi_selftest.c That is exactly what efi_selftest.c does. lib/efi_selftest/efi_selftest_block_device.c And this is a test instance for block device test. So what's your question? Hmm, I think the question is really clear, I don't know how to ask differently. But as the original issue is cleared and this is only for background understanding, let's drop it. THX again to you and Heinrich for fast help. -- KR Michael
Re: [PATCH] mailmap: Update mail address for Nicolas Saenz julienne
On 16/09/2021 11:55, Nicolas Saenz Julienne wrote: From: Nicolas Saenz Julienne The @suse.de address doesn't exist anymore. Update it to something not dependent on my workplace. Signed-off-by: Nicolas Saenz Julienne Thanks for doing this to keep you in the loop on RPi stuff going on. Reviewed-by: Matthias Brugger --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index b76f02283c..b09fc321bd 100644 --- a/.mailmap +++ b/.mailmap @@ -32,6 +32,7 @@ Jagan Teki Igor Opaniuk Igor Opaniuk Markus Klotzbuecher +Nicolas Saenz Julienne Patrice Chotard Patrick Delaunay Paul Burton
Re: [PATCH 3/3] efi_selftest: Recieve the packets until the receive buffer is empty
On 9/16/21 10:53 AM, Masami Hiramatsu wrote:
Repeatedly receive the packets until the receive buffer is empty.
If the buffer is empty, EFI_SIMPLE_NETWORK_PROTOCOL::Receive()
returns EFI_NOT_READY. We don't need to use the wait_for_event()
every time.
Why do you want to make the change?
Was anything not working with the prior version?
Best regards
Heinrich
Signed-off-by: Masami Hiramatsu
---
lib/efi_selftest/efi_selftest_snp.c | 67 +++
1 file changed, 37 insertions(+), 30 deletions(-)
diff --git a/lib/efi_selftest/efi_selftest_snp.c
b/lib/efi_selftest/efi_selftest_snp.c
index c5366c872c..818cbfcacd 100644
--- a/lib/efi_selftest/efi_selftest_snp.c
+++ b/lib/efi_selftest/efi_selftest_snp.c
@@ -362,39 +362,46 @@ static int execute(void)
continue;
}
/*
-* Receive packet
+* Receive packets until buffer is empty
*/
- buffer_size = sizeof(buffer);
- ret = net->receive(net, NULL, _size, ,
- , , NULL);
- if (ret != EFI_SUCCESS) {
- efi_st_error("Failed to receive packet");
- return EFI_ST_FAILURE;
+ for (;;) {
+ buffer_size = sizeof(buffer);
+ ret = net->receive(net, NULL, _size, ,
+ , , NULL);
+ if (ret == EFI_NOT_READY) {
+ /* The received buffer is empty. */
+ break;
+ }
+
+ if (ret != EFI_SUCCESS) {
+ efi_st_error("Failed to receive packet");
+ return EFI_ST_FAILURE;
+ }
+ /*
+* Check the packet is meant for this system.
+* Unfortunately QEMU ignores the broadcast flag.
+* So we have to check for broadcasts too.
+*/
+ if (memcmp(, >mode->current_address, ARP_HLEN)
&&
+ memcmp(, BROADCAST_MAC, ARP_HLEN))
+ continue;
+ /*
+* Check this is a DHCP reply
+*/
+ if (buffer.p.eth_hdr.et_protlen != ntohs(PROT_IP) ||
+ buffer.p.ip_udp.ip_hl_v != 0x45 ||
+ buffer.p.ip_udp.ip_p != IPPROTO_UDP ||
+ buffer.p.ip_udp.udp_src != ntohs(67) ||
+ buffer.p.ip_udp.udp_dst != ntohs(68) ||
+ buffer.p.dhcp_hdr.op != BOOTREPLY)
+ continue;
+ /*
+* We successfully received a DHCP reply.
+*/
+ goto received;
}
- /*
-* Check the packet is meant for this system.
-* Unfortunately QEMU ignores the broadcast flag.
-* So we have to check for broadcasts too.
-*/
- if (memcmp(, >mode->current_address, ARP_HLEN) &&
- memcmp(, BROADCAST_MAC, ARP_HLEN))
- continue;
- /*
-* Check this is a DHCP reply
-*/
- if (buffer.p.eth_hdr.et_protlen != ntohs(PROT_IP) ||
- buffer.p.ip_udp.ip_hl_v != 0x45 ||
- buffer.p.ip_udp.ip_p != IPPROTO_UDP ||
- buffer.p.ip_udp.udp_src != ntohs(67) ||
- buffer.p.ip_udp.udp_dst != ntohs(68) ||
- buffer.p.dhcp_hdr.op != BOOTREPLY)
- continue;
- /*
-* We successfully received a DHCP reply.
-*/
- break;
}
-
+received:
/*
* Write a log message.
*/
Re: RFC: exclude partitions from efi_selftest
On Thu, Sep 16, 2021 at 11:14:01AM +0200, Michael Lawnick wrote: > Am 16.09.2021 um 10:02 schrieb AKASHI Takahiro: > > On Thu, Sep 16, 2021 at 09:48:07AM +0200, Michael Lawnick wrote: > > > Am 16.09.2021 um 09:15 schrieb Michael Lawnick: > > > > Am 16.09.2021 um 09:12 schrieb AKASHI Takahiro: > > > > > Please, as Heinrich suggested, add CONFIG_FS_FAT, in your U-Boot > > > > > configuration. > > > > > > > > > Hmm, I didn't understand that as a suggestion, but as a question for his > > > > understanding. Of course I'll give it a try. > > > > > > > Sometimes live is such easy. This fixed my issue, THX. > > > > > > For the after-math / my understanding: > > > - Do I understand correctly that the problem was that 'efi_selftest > > > block device' requires FAT support? So shouldn't there be a dependency > > > in CONFIG? > > > > Strictly speaking, CONFIG_EFI_LOADER requires FAT per UEFI specification, > > and actually it has 'imply FAT'. I don't know why Heinrich uses 'imply' > > instead of 'select'. > > > > > - What is the reason/use to iterate through the recognized partitions > > > even twice (in .setup and .execute) if they aren't needed/used? > > > > What line of code do you exactly mean by 'in .setup' (and in .execute)? > > My understanding: > efi_selftests register their methods separated by setup/execute/teardown. > The central test control is taking tests from list and executes the > three methods, unaware of which exact test is executed: > lib/efi_selftest/efi_selftest.c That is exactly what efi_selftest.c does. > lib/efi_selftest/efi_selftest_block_device.c And this is a test instance for block device test. So what's your question? -Takahiro Akashi
