[PATCH] ARM: imx: Select 2 DRAM banks on Data Modul i.MX8M Mini eDM SBC
U-Boot splits DRAM bank spanning addresses below and above the 32bit boundary into two DRAM banks. Since this platform may come with 4GiB of DRAM, increase the DRAM bank count to 2. Signed-off-by: Marek Vasut --- Cc: "NXP i.MX U-Boot Team" Cc: Fabio Estevam Cc: Stefano Babic --- configs/imx8mm_data_modul_edm_sbc_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/imx8mm_data_modul_edm_sbc_defconfig b/configs/imx8mm_data_modul_edm_sbc_defconfig index f63eb4fd64c..8df6b4c6af1 100644 --- a/configs/imx8mm_data_modul_edm_sbc_defconfig +++ b/configs/imx8mm_data_modul_edm_sbc_defconfig @@ -5,7 +5,7 @@ CONFIG_SYS_MALLOC_LEN=0x100 CONFIG_SPL_GPIO=y CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y -CONFIG_NR_DRAM_BANKS=1 +CONFIG_NR_DRAM_BANKS=2 CONFIG_SF_DEFAULT_SPEED=5000 CONFIG_ENV_SIZE=0x4 CONFIG_ENV_OFFSET=0xFFFC -- 2.40.1
[PATCH] net: phy: broadcom: add support for BCM54210E
It's Broadcom PHY simply described as single-port
RGMII 10/100/1000BASE-T PHY. It requires disabling
delay skew and GTXCLK bits.
Ported from Linux kernel commit
0fc9ae1076697 ("net: phy: broadcom: add support for BCM54210E")
Signed-off-by: Marek Vasut
---
Cc: Joe Hershberger
Cc: Marek Vasut
Cc: Michal Simek
Cc: Ramon Fried
Cc: Rasmus Villemoes
---
drivers/net/phy/broadcom.c | 66 +-
1 file changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 36c70da181a..0967363b3bc 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -30,10 +30,47 @@
#define MIIM_BCM54XX_EXP_SEL_ER0x0f00 /* Expansion register
select */
#define MIIM_BCM_AUXCNTL_SHDWSEL_MISC 0x0007
-#define MIIM_BCM_AUXCNTL_ACTL_SMDSP_EN 0x0800
+#define MIIM_BCM_AUXCNTL_SHDWSEL_MISC_WIRESPEED_EN 0x0010
+#define MIIM_BCM_AUXCNTL_SHDWSEL_MISC_RGMII_EN 0x0080
+#define MIIM_BCM_AUXCNTL_SHDWSEL_MISC_RGMII_SKEW_EN0x0100
+#define MIIM_BCM_AUXCNTL_MISC_FORCE_AMDIX 0x0200
+#define MIIM_BCM_AUXCNTL_ACTL_SMDSP_EN 0x0800
+#define MIIM_BCM_AUXCNTL_MISC_WREN 0x8000
#define MIIM_BCM_CHANNEL_WIDTH0x2000
+#define BCM54810_SHD_CLK_CTL 0x3
+#define BCM54810_SHD_CLK_CTL_GTXCLK_EN BIT(9)
+
+static int bcm54xx_auxctl_read(struct phy_device *phydev, u16 regnum)
+{
+ /* The register must be written to both the Shadow Register Select and
+* the Shadow Read Register Selector
+*/
+ phy_write(phydev, MDIO_DEVAD_NONE, MIIM_BCM54xx_AUXCNTL,
+ MIIM_BCM54xx_AUXCNTL_ENCODE(regnum));
+ return phy_read(phydev, MDIO_DEVAD_NONE, MIIM_BCM54xx_AUXCNTL);
+}
+
+static int bcm54xx_auxctl_write(struct phy_device *phydev, u16 regnum, u16 val)
+{
+ return phy_write(phydev, MDIO_DEVAD_NONE, MIIM_BCM54xx_AUXCNTL, regnum
| val);
+}
+
+static int bcm_phy_read_shadow(struct phy_device *phydev, u16 shadow)
+{
+ phy_write(phydev, MDIO_DEVAD_NONE, MIIM_BCM54XX_SHD,
+ MIIM_BCM54XX_SHD_VAL(shadow));
+ return MIIM_BCM54XX_SHD_DATA(phy_read(phydev, MDIO_DEVAD_NONE,
+ MIIM_BCM54XX_SHD));
+}
+
+static int bcm_phy_write_shadow(struct phy_device *phydev, u16 shadow, u16 val)
+{
+ return phy_write(phydev, MDIO_DEVAD_NONE, MIIM_BCM54XX_SHD,
+MIIM_BCM54XX_SHD_WR_ENCODE(shadow, val));
+}
+
static void bcm_phy_write_misc(struct phy_device *phydev,
u16 reg, u16 chl, u16 value)
{
@@ -62,6 +99,23 @@ static int bcm5461_config(struct phy_device *phydev)
return 0;
}
+/* Broadcom BCM54210E */
+static int bcm54210e_config(struct phy_device *phydev)
+{
+ int val;
+
+ val = bcm54xx_auxctl_read(phydev, MIIM_BCM_AUXCNTL_SHDWSEL_MISC);
+ val &= ~MIIM_BCM_AUXCNTL_SHDWSEL_MISC_RGMII_SKEW_EN;
+ val |= MIIM_BCM_AUXCNTL_MISC_WREN;
+ bcm54xx_auxctl_write(phydev, MIIM_BCM_AUXCNTL_SHDWSEL_MISC, val);
+
+ val = bcm_phy_read_shadow(phydev, BCM54810_SHD_CLK_CTL);
+ val &= ~BCM54810_SHD_CLK_CTL_GTXCLK_EN;
+ bcm_phy_write_shadow(phydev, BCM54810_SHD_CLK_CTL, val);
+
+ return bcm5461_config(phydev);
+}
+
static int bcm54xx_parse_status(struct phy_device *phydev)
{
unsigned int mii_reg;
@@ -311,6 +365,16 @@ static int bcm5482_startup(struct phy_device *phydev)
return bcm54xx_parse_status(phydev);
}
+U_BOOT_PHY_DRIVER(bcm54210e) = {
+ .name = "Broadcom BCM54210E",
+ .uid = 0x600d84a0,
+ .mask = 0xfff0,
+ .features = PHY_GBIT_FEATURES,
+ .config = _config,
+ .startup = _startup,
+ .shutdown = _shutdown,
+};
+
U_BOOT_PHY_DRIVER(bcm5461s) = {
.name = "Broadcom BCM5461S",
.uid = 0x2060c0,
--
2.40.1
[PATCH 2/3] fdt: kaslr seed from tpm entropy
From: Dhananjay Phadke
Add support for KASLR seed from TPM device. Invokes tpm_get_random()
API to read 8-bytes of random bytes for KASLR.
Signed-off-by: Dhananjay Phadke
Signed-off-by: Drew Kluemke
Signed-off-by: Sean Edmond
---
boot/image-fdt.c | 3 +++
common/fdt_support.c | 39 ++-
include/fdt_support.h | 1 +
lib/Kconfig | 9 +
4 files changed, 51 insertions(+), 1 deletion(-)
diff --git a/boot/image-fdt.c b/boot/image-fdt.c
index f10200f647..127443963e 100644
--- a/boot/image-fdt.c
+++ b/boot/image-fdt.c
@@ -624,6 +624,9 @@ int image_setup_libfdt(struct bootm_headers *images, void
*blob,
goto err;
}
+ if (IS_ENABLED(CONFIG_KASLR_TPM_SEED))
+ fdt_tpm_kaslr_seed(blob);
+
fdt_ret = optee_copy_fdt_nodes(blob);
if (fdt_ret) {
printf("ERROR: transfer of optee nodes to new fdt failed: %s\n",
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 35d4f26dbd..1ac33355a0 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -13,6 +13,10 @@
#include
#include
#include
+#include
+#include
+#include
+#include
#include
#include
#include
@@ -632,7 +636,7 @@ void fdt_fixup_ethernet(void *fdt)
}
/*
- * fdt_fix_kaslr_seed - Add kalsr-seed node in Device tree
+ * fdt_fixup_kaslr_seed - Add kaslr-seed node in Device tree
* @fdt: Device tree
* @eret: 0 for success
*/
@@ -662,6 +666,39 @@ int fdt_fixup_kaslr_seed(void *fdt, const u8 *seed, int
len)
return 0;
}
+/*
+ * fdt_add_tpm_kaslr_seed - Add kalsr-seed node in Device tree with random
+ * bytes from TPM device
+ * @fdt: Device tree
+ * @eret: 0 for success
+ */
+int fdt_tpm_kaslr_seed(void *fdt)
+{
+ u8 rand[8] = {0};
+ struct udevice *dev;
+ int ret;
+
+ ret = uclass_get_device(UCLASS_TPM, 0, );
+ if (ret) {
+ printf("ERROR: Failed to find TPM device\n");
+ return ret;
+ }
+
+ ret = tpm_get_random(dev, rand, sizeof(rand));
+ if (ret) {
+ printf("ERROR: TPM GetRandom failed, ret=%d\n", ret);
+ return ret;
+ }
+
+ ret = fdt_fixup_kaslr_seed(fdt, rand, sizeof(rand));
+ if (ret) {
+ printf("ERROR: failed to add kaslr-seed to fdt\n");
+ return ret;
+ }
+
+ return 0;
+}
+
int fdt_record_loadable(void *blob, u32 index, const char *name,
uintptr_t load_addr, u32 size, uintptr_t entry_point,
const char *type, const char *os, const char *arch)
diff --git a/include/fdt_support.h b/include/fdt_support.h
index d74ef4e0a7..9e50db1b96 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -123,6 +123,7 @@ static inline int fdt_fixup_memory_banks(void *blob, u64
start[], u64 size[],
void fdt_fixup_ethernet(void *fdt);
int fdt_fixup_kaslr_seed(void *fdt, const u8 *seed, int len);
+int fdt_tpm_kaslr_seed(void *fdt);
int fdt_find_and_setprop(void *fdt, const char *node, const char *prop,
const void *val, int len, int create);
diff --git a/lib/Kconfig b/lib/Kconfig
index 3926652db6..1530ef7c86 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -465,6 +465,15 @@ config VPL_TPM
for the low-level TPM interface, but only one TPM is supported at
a time by the TPM library.
+config KASLR_TPM_SEED
+ bool "Use TPM for KASLR random seed"
+ depends on TPM_V1 || TPM_V2
+ help
+ This enables support for using TPMs as entropy source for KASLR seed
+ populated in kernel's device tree. Both TPMv1 and TPMv2 are supported
+ for the low-level TPM interface, but only one TPM is supported at
+ a time by the library.
+
endmenu
menu "Android Verified Boot"
--
2.40.0
[PATCH 0/3] Populate kaslr seed with TPM
From: Sean Edmond This patch series creates a common API (fdt_fixup_kaslr_seed()) for populating the kaslr seed in the DTB. Existing users (kaslrseed, and ARMv8 sec firmware) have been updated to use this common API. New functionality has been introduced to populate the kaslr using the TPM interface. This can be enabled with CONFIG_KASLR_TPM_SEED. Dhananjay Phadke (2): fdt: common API to populate kaslr seed fdt: kaslr seed from tpm entropy Sean Edmond (1): cmd: kaslrseed: Use common API to fixup FDT arch/arm/cpu/armv8/sec_firmware.c | 32 --- boot/image-fdt.c | 3 ++ cmd/kaslrseed.c | 18 ++-- common/fdt_support.c | 68 +++ include/fdt_support.h | 4 ++ lib/Kconfig | 9 6 files changed, 94 insertions(+), 40 deletions(-) -- 2.40.0
[PATCH 1/3] fdt: common API to populate kaslr seed
From: Dhananjay Phadke
fdt_fixup_kaslr_seed() will update given FDT with random seed value.
Source for random seed can be TPM or RNG driver in u-boot or sec
firmware (ARM).
Signed-off-by: Dhananjay Phadke
---
arch/arm/cpu/armv8/sec_firmware.c | 32 +++
common/fdt_support.c | 31 ++
include/fdt_support.h | 3 +++
3 files changed, 41 insertions(+), 25 deletions(-)
diff --git a/arch/arm/cpu/armv8/sec_firmware.c
b/arch/arm/cpu/armv8/sec_firmware.c
index c0e8726346..84ba49924e 100644
--- a/arch/arm/cpu/armv8/sec_firmware.c
+++ b/arch/arm/cpu/armv8/sec_firmware.c
@@ -411,46 +411,28 @@ int sec_firmware_init(const void *sec_firmware_img,
/*
* fdt_fix_kaslr - Add kalsr-seed node in Device tree
* @fdt: Device tree
- * @eret: 0 in case of error, 1 for success
+ * @eret: 0 for success
*/
int fdt_fixup_kaslr(void *fdt)
{
- int nodeoffset;
- int err, ret = 0;
- u8 rand[8];
+ int ret = 0;
#if defined(CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT)
+ u8 rand[8];
+
/* Check if random seed generation is supported */
if (sec_firmware_support_hwrng() == false) {
printf("WARNING: SEC firmware not running, no kaslr-seed\n");
- return 0;
+ return -EOPNOTSUPP;
}
err = sec_firmware_get_random(rand, 8);
if (err < 0) {
printf("WARNING: No random number to set kaslr-seed\n");
- return 0;
- }
-
- err = fdt_check_header(fdt);
- if (err < 0) {
- printf("fdt_chosen: %s\n", fdt_strerror(err));
- return 0;
+ return ret;
}
- /* find or create "/chosen" node. */
- nodeoffset = fdt_find_or_add_subnode(fdt, 0, "chosen");
- if (nodeoffset < 0)
- return 0;
-
- err = fdt_setprop(fdt, nodeoffset, "kaslr-seed", rand,
- sizeof(rand));
- if (err < 0) {
- printf("WARNING: can't set kaslr-seed %s.\n",
- fdt_strerror(err));
- return 0;
- }
- ret = 1;
+ ret = fdt_fixup_kaslr_seed(fdt, rand, sizeof(rand));
#endif
return ret;
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 5e49078f8c..35d4f26dbd 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -631,6 +631,37 @@ void fdt_fixup_ethernet(void *fdt)
}
}
+/*
+ * fdt_fix_kaslr_seed - Add kalsr-seed node in Device tree
+ * @fdt: Device tree
+ * @eret: 0 for success
+ */
+int fdt_fixup_kaslr_seed(void *fdt, const u8 *seed, int len)
+{
+ int nodeoffset;
+ int err;
+
+ err = fdt_check_header(fdt);
+ if (err < 0) {
+ printf("fdt_chosen: %s\n", fdt_strerror(err));
+ return err;
+ }
+
+ /* find or create "/chosen" node. */
+ nodeoffset = fdt_find_or_add_subnode(fdt, 0, "chosen");
+ if (nodeoffset < 0)
+ return -ENOENT;
+
+ err = fdt_setprop(fdt, nodeoffset, "kaslr-seed", seed, len);
+ if (err < 0) {
+ printf("WARNING: can't set kaslr-seed %s.\n",
+ fdt_strerror(err));
+ return err;
+ }
+
+ return 0;
+}
+
int fdt_record_loadable(void *blob, u32 index, const char *name,
uintptr_t load_addr, u32 size, uintptr_t entry_point,
const char *type, const char *os, const char *arch)
diff --git a/include/fdt_support.h b/include/fdt_support.h
index 2cd8366898..d74ef4e0a7 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -121,6 +121,9 @@ static inline int fdt_fixup_memory_banks(void *blob, u64
start[], u64 size[],
#endif
void fdt_fixup_ethernet(void *fdt);
+
+int fdt_fixup_kaslr_seed(void *fdt, const u8 *seed, int len);
+
int fdt_find_and_setprop(void *fdt, const char *node, const char *prop,
const void *val, int len, int create);
void fdt_fixup_qe_firmware(void *fdt);
--
2.40.0
[PATCH 3/3] cmd: kaslrseed: Use common API to fixup FDT
From: Sean Edmond
Use the newly introduced common API fdt_fixup_kaslr_seed() in the
kaslrseed command.
Signed-off-by: Sean Edmond
---
cmd/kaslrseed.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/cmd/kaslrseed.c b/cmd/kaslrseed.c
index 8a1d8120cd..82117bc484 100644
--- a/cmd/kaslrseed.c
+++ b/cmd/kaslrseed.c
@@ -45,21 +45,9 @@ static int do_kaslr_seed(struct cmd_tbl *cmdtp, int flag,
int argc, char *const
return CMD_RET_FAILURE;
}
- ret = fdt_check_header(working_fdt);
- if (ret < 0) {
- printf("fdt_chosen: %s\n", fdt_strerror(ret));
- return CMD_RET_FAILURE;
- }
-
- nodeoffset = fdt_find_or_add_subnode(working_fdt, 0, "chosen");
- if (nodeoffset < 0) {
- printf("Reading chosen node failed\n");
- return CMD_RET_FAILURE;
- }
-
- ret = fdt_setprop(working_fdt, nodeoffset, "kaslr-seed", buf,
sizeof(buf));
- if (ret < 0) {
- printf("Unable to set kaslr-seed on chosen node: %s\n",
fdt_strerror(ret));
+ ret = fdt_fixup_kaslr_seed(working_fdt, buf, sizeof(buf));
+ if (ret) {
+ printf("ERROR: failed to add kaslr-seed to fdt\n");
return CMD_RET_FAILURE;
}
--
2.40.0
[PATCH] drivers: mtd: Add MT25QU128AB params
From: Godfrey Mwangi
Add Micron MT25QU128AB flash.
Signed-off-by: Godfrey Mwangi
---
drivers/mtd/spi/spi-nor-ids.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 4587215984..a99bb6125b 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -299,6 +299,7 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("n25q256a",0x20ba19, 0, 64 * 1024, 512, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | USE_FSR) },
{ INFO6("mt25qu256a", 0x20bb19, 0x104400, 64 * 1024, 512, SECT_4K |
SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES | USE_FSR) },
{ INFO("n25q256ax1", 0x20bb19, 0, 64 * 1024, 512, SECT_4K |
SPI_NOR_QUAD_READ | USE_FSR) },
+ { INFO("mt25qu128ab", 0x20bb18, 0, 64 * 1024, 256, SECT_4K | USE_FSR |
SPI_NOR_QUAD_READ) },
{ INFO6("mt25qu512a", 0x20bb20, 0x104400, 64 * 1024, 1024,
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
SPI_NOR_4B_OPCODES |
USE_FSR) },
--
2.40.0
Re: [PATCH v5 3/3] usb: gadget: ether: Handle gadget driver registration in probe and remove
On Fri, Aug 04, 2023 at 05:41:11PM +0200, Marek Vasut wrote: > Move the ethernet gadget driver registration and removal from ethernet > bind and unbind callbacks into driver DM probe and remove callbacks. > This way, when the driver is bound, which is triggered deliberately > using 'bind' command, the USB ethernet gadget driver is instantiated > and bound to the matching UDC. In reverse, when the driver is unbound, > which is again triggered deliberately using 'unbind' command, the USB > ethernet gadget driver instance is removed. > > Effectively, this now behaves like running either 'ums' or 'dfu' or > any other commands utilizing USB gadget functionality. > > This also drops use of usb_gadget_release() and moves the use of > usb_gadget_initialize() into usb_ether_init() used only by legacy > platforms that do not use 'bind' command properly yet. Those have > no place in drivers. > > Signed-off-by: Marek Vasut > Tested-by: Tom Rini Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 2/3] usb: gadget: ether: Move probe function above driver structure
On Fri, Aug 04, 2023 at 05:41:10PM +0200, Marek Vasut wrote: > Move the driver probe function above the driver structure, so it > can be placed alongside other related functions, like upcoming > remove function. No functional change. > > Signed-off-by: Marek Vasut > Tested-by: Tom Rini > Tested-by: Miquel Raynal > Tested-by: Miquel Raynal Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 1/3] usb: gadget: ether: Inline functions used once
On Fri, Aug 04, 2023 at 05:41:09PM +0200, Marek Vasut wrote: > These functions here are only ever called once since drop of non-DM > networking code. Inline them. No functional change. > > Signed-off-by: Marek Vasut > Tested-by: Tom Rini > Tested-by: Miquel Raynal Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 1/4] toradex: tdx-cfg-block: add verdin am62 skus
On Fri, Aug 04, 2023 at 12:08:05PM +0200, Marcel Ziswiler wrote: > From: Marcel Ziswiler > > Add initial Verdin AM62 Quad 1GB WB IT prototype and launch > configuration SKUs to ConfigBlock handling. > > 0069: Verdin AM62 Quad 1GB WB IT > 0071: Verdin AM62 Solo 512MB > 0072: Verdin AM62 Solo 512MB WB IT > 0073: Verdin AM62 Dual 1GB ET > 0074: Verdin AM62 Dual 1GB IT > 0075: Verdin AM62 Dual 1GB WB IT > 0076: Verdin AM62 Quad 2GB WB IT > > Signed-off-by: Marcel Ziswiler > Signed-off-by: Emanuele Ghidoli For the series, applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 1/3] toradex: tdx-cfg-block: add yavia carrier cfg block info
On Tue, Jul 18, 2023 at 11:07:32AM +0200, Andrejs Cainikovs wrote: > From: Max Krummenacher > > Add the Yavia Carrier board name string to the known carrier > board list. > > Signed-off-by: Max Krummenacher > Signed-off-by: Andrejs Cainikovs For the series, applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 2/3] usb: gadget: ether: Move probe function above driver structure
Hi Marek, ma...@denx.de wrote on Fri, 4 Aug 2023 17:41:10 +0200: > Move the driver probe function above the driver structure, so it > can be placed alongside other related functions, like upcoming > remove function. No functional change. > > Signed-off-by: Marek Vasut > --- > Cc: Kevin Hilman > Cc: Lukasz Majewski > Cc: Miquel Raynal > Cc: Simon Glass > --- Tested-by: Miquel Raynal Thanks, Miquèl
Re: [PATCH v5 2/3] usb: gadget: ether: Move probe function above driver structure
Hi Marek, ma...@denx.de wrote on Fri, 4 Aug 2023 17:41:10 +0200: > Move the driver probe function above the driver structure, so it > can be placed alongside other related functions, like upcoming > remove function. No functional change. > > Signed-off-by: Marek Vasut > --- > Cc: Kevin Hilman > Cc: Lukasz Majewski > Cc: Miquel Raynal > Cc: Simon Glass > --- Tested-by: Miquel Raynal Thanks, Miquèl
Re: [PATCH v5 1/3] usb: gadget: ether: Inline functions used once
Hi Marek, ma...@denx.de wrote on Fri, 4 Aug 2023 17:41:09 +0200: > These functions here are only ever called once since drop of non-DM > networking code. Inline them. No functional change. > > Signed-off-by: Marek Vasut > --- > Cc: Kevin Hilman > Cc: Lukasz Majewski > Cc: Miquel Raynal > Cc: Simon Glass > --- Tested-by: Miquel Raynal Thanks, Miquèl
Re: [PATCH v4 1/4] cmd: bind: Add unbind command with driver filter
Hi Tom, tr...@konsulko.com wrote on Fri, 4 Aug 2023 14:51:07 -0400: > On Fri, Aug 04, 2023 at 08:01:56PM +0200, Miquel Raynal wrote: > > Hi Tom, > > > > tr...@konsulko.com wrote on Fri, 4 Aug 2023 13:20:29 -0400: > > > > > On Fri, Aug 04, 2023 at 07:01:46PM +0200, Miquel Raynal wrote: > > > > Hi Tom, > > > > > > > > > > > >>> Well, what's needed / is it possible to get to the point > > > > > > > >>> where we don't > > > > > > > >>> _need_ to call bind/unbind for each of these cases? Is there > > > > > > > >>> something > > > > > > > >>> we're supposed to be setting in the DT that we aren't? > > > > > > > >> > > > > > > > >> You do need to unbind the ethernet before using fastboot, > > > > > > > >> always, with the 'unbind ethernet 0', you dont need the > > > > > > > >> peripheral unbind/rebind part, so it should behave like > > > > > > > >> before. > > > > > > > > > > > > > > > > And for my own understanding, why don't we need to bind a > > > > > > > > fastboot > > > > > > > > gadget? > > > > > > > > > > > > > > The fastboot command does that internally . > > > > > > > > > > > > This is not visible with dm tree and I did not find how to bind the > > > > > > fastboot gadget manually. > > > > > > > > > > > > This makes the CLI clearly uneven and the internal code badly > > > > > > different > > > > > > between gadgets/commands. Why can't we have them both > > > > > > autoloaded/unloaded like before? I think I missed something which > > > > > > explains the rationale behind this series. > > > > > > > > > > They aren't both auto-loaded currently. We have a legacy call, > > > > > usb_ether_init(), in a few cases, so that gadget mode ethernet starts. > > > > > But this leads to the ref counting problems you encountered and > > > > > re-posted the rejected series for. > > > > > > > > Ok, thanks for the additional details. > > > > > > > > I don't understand why fastboot autoloads the correct gadget driver if > > > > there is none bound, while all network commands just fail to do that if > > > > we don't make the usb_ether_init() call manually. > > > > > > Because "fastboot" or "dfu" are both being told (as part of their call) > > > "find usb gadget controller number X". That's doing the bind. Calling > > > usb_ether_init just takes the first controller and that's that (and so > > > could be / is wrong depending on the platform). > > > > This makes total sense, thanks for pointing it out. > > > > > > I also don't understand why I need to unbind the ethernet gadget but I > > > > cannot bind the fastboot gadget. > > > > > > You can't bind fastboot while ethernet is still configured. > > > > I guess "before this series", the ethernet would not be kept > > configured, because I could use both fastboot and ethernet without > > caring about which driver had to be bound. And that's maybe what lead to > > the bug reports also. So you want to get rid of this. Do I get the > > situation right now? > > We're getting rid of this path because it leads to failures, yes. > > > > It's in > > > use. And we aren't a full blown operating system with the logic to have > > > multiple end points and devices configured and exposed. I mean heck, we > > > don't keep the gadget interface up between network calls so on the host > > > side you need to re-configure the interface (or have something that's > > > bringing it up there again each time). Which is why DFU or fastboot or > > > other "treat USB like USB" options tend to be more popular than "treat > > > USB like ethernet" work flows. > > > > Yes of course. > > > > > > My underlying question is: can we have a single approach for all > > > > drivers, or is it too complex today? Could it be possible, when we > > > > perform these autoloads, to look up the registered gadget and > > > > potentially unbind the one already in place before? > > > > > > I would invite you to look in to this, yes. > > > > Sounds reasonably complex now, with the reasoning you made above. > > > > > No one objects to enhancing > > > the code, but the "functionality" you see on am33xx is as you've also > > > seen very broken in other ways, which is why it's not used virtually > > > anywhere else and instead the "bind" command is. For example, if you > > > wanted to do this workflow on the new beagle devices, that's DWC3 and > > > where the "bind" command came from :) > > > > Again to be very clear, while I felt misunderstood at the beginning and > > did not accept Marek's series because it was replacing a data abort > > with a non-functional setup, I now get a better understanding of the > > problem (I believe) and, as said before, I am always in favor of > > writing better code, easier to maintain, clearer to review. I am in > > favor of such change. I just want the user life to be eased when this > > happens if we break the CLI. So if you think the right approach is to > > get rid of the
[PATCH] doc: ti: Explain how the various gadget devices can be used
Describe the current situation wrt the handling of USB devices on AM33xx
based boards, taking the example of a common board (the Beagle Bone
Black) and explaining how the different USB gadgets can be used.
Signed-off-by: Miquel Raynal
---
I've tried to be as transparent and honnest as I could with my limited
knowledge of the situation and the USB world, based on our latest
dicussions. I am fully open to suggestions, changes, rephrasing...
---
doc/board/ti/am335x_evm.rst | 61 +
1 file changed, 61 insertions(+)
diff --git a/doc/board/ti/am335x_evm.rst b/doc/board/ti/am335x_evm.rst
index ee4faec37c2..0587b506ee2 100644
--- a/doc/board/ti/am335x_evm.rst
+++ b/doc/board/ti/am335x_evm.rst
@@ -201,3 +201,64 @@ booting and mtdparts have been configured correctly for
the board:
U-Boot # spl export fdt ${loadaddr} - ${fdtaddr}
U-Boot # nand erase.part u-boot-spl-os
U-Boot # nand write ${fdtaddr} u-boot-spl-os
+
+USB device
+--
+
+The platform code for am33xx based designs is legacy in the sense that
+it is not fully compliant with the device model in its management of the
+various resources. This is particularly true for the USB Ethernet gadget
+which will automatically be bound to the first USB Device Controller
+(UDC). This make the USB Ethernet gadget work out of the box on common
+boards like the Beagle Bone Blacks and by default will prevents other
+gadgets to be used.
+
+The output of the 'dm tree' command should be rather explicit in that
+sense, showing exactly what driver is bound to what device, so the user
+can easily configure its platform differently from the command line:
+
+.. code-block:: text
+
+ => dm tree
+Class Index Probed DriverName
+ ---
+ [...]
+ misc 0 [ + ] ti-musb-wrapper | |-- usb@4740
+ usb 0 [ + ] ti-musb-peripheral| | |-- usb@47401000
+ ethernet 1 [ + ] usb_ether | | | `-- usb_ether
+ bootdev 3 [ ] eth_bootdev | | | `--
usb_ether.bootdev
+ usb 0 [ ] ti-musb-host | | `-- usb@47401800
+
+Typically here any network command performed using the usb_ether
+interface would work, while using other gadgets would fail:
+
+.. code-block:: text
+
+ => fastboot usb 0
+ All UDC in use (1 available), use the unbind command
+ g_dnl_register: failed!, error: -19
+ exit not allowed from main input shell.
+
+As hinted by the primary error message, the only controller available
+(usb@47401000) is currently bound to the usb_ether driver, which makes
+it impossible to the fastboot command to bind with this device (at least
+from a Bootloader point of view). The solution here would be to use the
+unbind command using the class and index parameters (as shown above in
+the 'dm tree' output) to target the driver to unbind:
+
+.. code-block:: text
+
+ => unbind ethernet 1
+
+Checking the output of the 'dm tree' command now shows full availability
+for the fastboot gadget to bind with UDC 0:
+
+.. code-block:: text
+
+ => dm tree
+Class Index Probed DriverName
+ ---
+ [...]
+ misc 0 [ + ] ti-musb-wrapper | |-- usb@4740
+ usb 0 [ ] ti-musb-peripheral| | |-- usb@47401000
+ usb 0 [ ] ti-musb-host | | `-- usb@47401800
--
2.34.1
[PATCH 2/2] usb: udc: Try to clarify an error message
At some point when trying to use USB gadgets, two situations may arise
and lead to a failure. Either the UDC (USB Device Controller) is not
available at all (not described or not probed) or the UDC is already in
use. For instance, as the USB Ethernet gadget remains bound to the UDC,
the use of any other USB gadget (fastboot, dfu, etc) *after* will always
fail with the "couldn't find an available UDC" error.
Let's give a more helpful message by making a difference between the two
cases. Let's also hint people who would get this error and grep it into
the sources a better explanation of what's wrong with their workflow.
Signed-off-by: Miquel Raynal
---
While doing this I really wanted to add "much more" error comments but I
faced another reality: often the messages are there but use
pr_err/log_err which is actually silenced by default with LOGLEVEL=3, so
I consider this unnecessary, as decreasing the loglevel will make these
messages appear. I would have expected errors to be displayed, but I
understand it makes the binaries even bigger.
---
drivers/usb/gadget/udc/udc-core.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index 7f73926cb3e..30f6d73f36e 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -323,6 +323,7 @@ err1:
int usb_gadget_probe_driver(struct usb_gadget_driver *driver)
{
struct usb_udc *udc = NULL;
+ unsigned intudc_count = 0;
int ret;
if (!driver || !driver->bind || !driver->setup)
@@ -330,12 +331,22 @@ int usb_gadget_probe_driver(struct usb_gadget_driver
*driver)
mutex_lock(_lock);
list_for_each_entry(udc, _list, list) {
+ udc_count++;
+
/* For now we take the first one */
if (!udc->driver)
goto found;
}
- printf("couldn't find an available UDC\n");
+ if (!udc_count)
+ printf("No UDC available in the system\n");
+ else
+ /* When this happens, users should 'unbind '
+* using the output of 'dm tree' and looking at the line right
+* after the USB peripheral/device controller.
+*/
+ printf("All UDC in use (%d available), use the unbind
command\n",
+ udc_count);
mutex_unlock(_lock);
return -ENODEV;
found:
--
2.34.1
[PATCH 1/2] cmd: bind: Try to improve the (un)bind help
While it may sound totally obvious for the regular U-Boot developer to get the parameters of the bind/unbind commands from the output of 'dm tree', it did not felt straightforward to me until I was explicitly told to look there. And even when I knew the command, I did not make a direct link between the arguments of this command and the columns returned by 'dm tree'. Several of us lost a lot of time because of that, I would like to kindly help other users by slightly improving this textual line. Unfortunately, because of how this string is used (like within the 'help' command) I cannot detail much more, but at least the pointer is there. Signed-off-by: Miquel Raynal --- cmd/bind.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cmd/bind.c b/cmd/bind.c index 4d1b7885e60..8d29a42899e 100644 --- a/cmd/bind.c +++ b/cmd/bind.c @@ -243,14 +243,14 @@ static int do_bind_unbind(struct cmd_tbl *cmdtp, int flag, int argc, U_BOOT_CMD( bind, 4, 0, do_bind_unbind, - "Bind a device to a driver", + "Bind a device to a driver, see 'dm tree' for the parameters\n", " \n" "bind \n" ); U_BOOT_CMD( unbind, 4, 0, do_bind_unbind, - "Unbind a device from a driver", + "Unbind a device from a driver, see 'dm tree' for the parameters\n", "\n" "unbind \n" "unbind \n" -- 2.34.1
Re: [PATCH] usb: xhci: pet watchdog during transfers
On 8/4/23 21:00, seanedm...@linux.microsoft.com wrote: From: Godfrey Mwangi On some platforms with low USB throughput, tranfers of huge files take a long time and watchdog timer can expire resulting in hardware reset. Avoid this by petting the watchdog as long as we have pending transfers. Signed-off-by: Godfrey Mwangi --- drivers/usb/host/xhci-ring.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index c8260cbdf9..de954314bc 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -18,6 +18,7 @@ #include #include #include +#include #include #include #include @@ -758,6 +759,8 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe, /* Calculate length for next transfer */ addr += trb_buff_len; trb_buff_len = min((length - running_total), TRB_MAX_BUFF_SIZE); + + schedule(); } while (running_total < length); giveback_first_trb(udev, ep_index, start_cycle, start_trb); s@pet@ping@ or trigger . With that fixed: Reviewed-by: Marek Vasut Thanks !
Re: [PATCH v6 3/9] capsule: authenticate: Add capsule public key in platform's dtb
On Thu, Aug 03, 2023 at 06:18:24PM -0600, Simon Glass wrote:
> Hi Sughosh,
>
> On Thu, 3 Aug 2023 at 05:12, Sughosh Ganu wrote:
> >
> > hi Simon,
> >
> > On Wed, 2 Aug 2023 at 19:04, Simon Glass wrote:
> > >
> > > Hi Sughosh,
> > >
> > > On Wed, 2 Aug 2023 at 06:52, Simon Glass wrote:
> > > >
> > > > Hi Sughosh,
> > > >
> > > > On Tue, 1 Aug 2023 at 11:40, Sughosh Ganu
> > > > wrote:
> > > > >
> > > > > The EFI capsule authentication logic in u-boot expects the public key
> > > > > in the form of an EFI Signature List(ESL) to be provided as part of
> > > > > the platform's dtb. Currently, the embedding of the ESL file into the
> > > > > dtb needs to be done manually.
> > > > >
> > > > > Add a signature node in the u-boot dtsi file and include the public
> > > > > key through the capsule-key property. This file is per architecture,
> > > > > and is currently being added for sandbox and arm architectures. It
> > > > > will have to be added for other architectures which need to enable
> > > > > capsule authentication support.
> > > > >
> > > > > The path to the ESL file is specified through the
> > > > > CONFIG_EFI_CAPSULE_ESL_FILE symbol.
> > > > >
> > > > > Signed-off-by: Sughosh Ganu
> > > > > ---
> > > > > Changes since V5:
> > > > > * None
> > > > >
> > > > > arch/arm/dts/u-boot.dtsi | 14 ++
> > > > > arch/sandbox/dts/u-boot.dtsi | 17 +
> > > > > lib/efi_loader/Kconfig | 9 +
> > > > > 3 files changed, 40 insertions(+)
> > > > > create mode 100644 arch/arm/dts/u-boot.dtsi
> > > > > create mode 100644 arch/sandbox/dts/u-boot.dtsi
> > > > >
> > > > > diff --git a/arch/arm/dts/u-boot.dtsi b/arch/arm/dts/u-boot.dtsi
> > > > > new file mode 100644
> > > > > index 00..4f31da4521
> > > > > --- /dev/null
> > > > > +++ b/arch/arm/dts/u-boot.dtsi
> > > > > @@ -0,0 +1,14 @@
> > > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > > +/**
> > > > > + * Devicetree file with miscellaneous nodes that will be included
> > > > > + * at build time into the DTB. Currently being used for including
> > > > > + * capsule related information.
> > > > > + */
> > > > > +
> > > > > +#ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
> > > > > +/ {
> > > > > + signature {
> > > > > + capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
> > > > > + };
> > > > > +};
> > > > > +#endif /* CONFIG_EFI_CAPSULE_AUTHENTICATE */
> > >
> > > Ilias mentioned that this binding can cause problems if it not
> > > upstream, causing the platform to fail validation. So we need to agree
> > > a binding for it in dt-schema. Can you send a patch to we can discuss
> > > it there?
> >
> > There was an effort from Jassi earlier [1] to upstream one such
> > binding for the FWU node. But Rob had asked to remove this in u-boot
> > before the DT was passed over to the kernel.
>
> I don't like that idea...U-Boot's DT needs to pass validation too, of course!
We're about 30 steps away from being able to just validate our trees
too. We shouldn't make things intentionally harder but we will need to
have some local schemas or something for cases where they've already
been intentionally submitted and rejected by dt-schema for being a
purely internal need.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 0/7] rockchip: rk3568: Fix use of PCIe bifurcation
1) Tested rk3568 NanpPi-R5s with Samsung 980 NVMe using linux 6.4.7 device tree. MMC boot media. 2) Tested rk3588 ROCK 5B with Samsung 980 and Samsung 970 EVO Plus NVMe using Sebastian Reichel's rk3588 device tree: https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-misc.git/log/?h=rk3588 Both MMC and SPI boot media were tested. Tested-by: John Clark On 8/3/23 2:29 AM, FUKAUMI Naoki wrote: hi, On 8/3/23 04:22, Jonas Karlman wrote: This series add support for use of PCIe bifurcation on RK3568, and as a bonus support for the RK3588 PHY is also included. With PCIe bifurcation supported it is possible to enable PCIe on more RK3568 boards, e.g. on NanoPi R5C and NanoPi R5S. This series only include fixing the mini PCIe slot on Radxa E25. Most parts of this series was imported almost 1:1 from mainline linux. Patch 1 fixes configuration of number of lanes in pcie_dw_rockchip. Patch 2-3 refactor the snps-pcie3 phy driver. Patch 4 add bifurcation support for RK3568. Patch 5 add support for RK3588 to snps-pcie3 driver. Patch 6 fixes use of pcie2x1l0 on ROCK 5B. Patch 7 enables the mini PCIe slot on Radxa E25. Changes in v2: - Fix use of signal from comb PHY on RK3588 - Add fixes tag The RK3588 PHY part was tested on a ROCK 5B together with device tree files picked from Sebastian Reichel's rk3588 branch at [1]. Patches in this series is also aviliable at [2]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-misc.git/tree/?h=rk3588 [2] https://github.com/Kwiboo/u-boot-rockchip/commits/rk35xx-pcie-bifurcation-v2 Jonas Karlman (7): pci: pcie_dw_rockchip: Configure number of lanes and link width speed phy: rockchip: snps-pcie3: Refactor to use clk_bulk API phy: rockchip: snps-pcie3: Refactor to use a phy_init ops phy: rockchip: snps-pcie3: Add bifurcation support for RK3568 phy: rockchip: snps-pcie3: Add support for RK3588 phy: rockchip: naneng-combphy: Use signal from comb PHY on RK3588 rockchip: rk3568-radxa-e25: Enable pcie3x1 node arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 11 +- configs/radxa-e25-rk3568_defconfig | 1 - drivers/pci/pcie_dw_rockchip.c | 58 - .../rockchip/phy-rockchip-naneng-combphy.c | 6 + .../phy/rockchip/phy-rockchip-snps-pcie3.c | 230 ++ 5 files changed, 241 insertions(+), 65 deletions(-) for the whole series, Tested-by: FUKAUMI Naoki on ROCK 5B with NVMe and linux-next 20230802 device tree.
[PATCH] usb: xhci: pet watchdog during transfers
From: Godfrey Mwangi On some platforms with low USB throughput, tranfers of huge files take a long time and watchdog timer can expire resulting in hardware reset. Avoid this by petting the watchdog as long as we have pending transfers. Signed-off-by: Godfrey Mwangi --- drivers/usb/host/xhci-ring.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index c8260cbdf9..de954314bc 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -18,6 +18,7 @@ #include #include #include +#include #include #include #include @@ -758,6 +759,8 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe, /* Calculate length for next transfer */ addr += trb_buff_len; trb_buff_len = min((length - running_total), TRB_MAX_BUFF_SIZE); + + schedule(); } while (running_total < length); giveback_first_trb(udev, ep_index, start_cycle, start_trb); -- 2.40.0
Re: [PATCH v4 1/4] cmd: bind: Add unbind command with driver filter
On Fri, Aug 04, 2023 at 08:01:56PM +0200, Miquel Raynal wrote: > Hi Tom, > > tr...@konsulko.com wrote on Fri, 4 Aug 2023 13:20:29 -0400: > > > On Fri, Aug 04, 2023 at 07:01:46PM +0200, Miquel Raynal wrote: > > > Hi Tom, > > > > > > > > > >>> Well, what's needed / is it possible to get to the point where > > > > > > >>> we don't > > > > > > >>> _need_ to call bind/unbind for each of these cases? Is there > > > > > > >>> something > > > > > > >>> we're supposed to be setting in the DT that we aren't? > > > > > > >> > > > > > > >> You do need to unbind the ethernet before using fastboot, > > > > > > >> always, with the 'unbind ethernet 0', you dont need the > > > > > > >> peripheral unbind/rebind part, so it should behave like before. > > > > > > >> > > > > > > > > > > > > > > And for my own understanding, why don't we need to bind a fastboot > > > > > > > gadget? > > > > > > > > > > > > The fastboot command does that internally . > > > > > > > > > > This is not visible with dm tree and I did not find how to bind the > > > > > fastboot gadget manually. > > > > > > > > > > This makes the CLI clearly uneven and the internal code badly > > > > > different > > > > > between gadgets/commands. Why can't we have them both > > > > > autoloaded/unloaded like before? I think I missed something which > > > > > explains the rationale behind this series. > > > > > > > > They aren't both auto-loaded currently. We have a legacy call, > > > > usb_ether_init(), in a few cases, so that gadget mode ethernet starts. > > > > But this leads to the ref counting problems you encountered and > > > > re-posted the rejected series for. > > > > > > Ok, thanks for the additional details. > > > > > > I don't understand why fastboot autoloads the correct gadget driver if > > > there is none bound, while all network commands just fail to do that if > > > we don't make the usb_ether_init() call manually. > > > > Because "fastboot" or "dfu" are both being told (as part of their call) > > "find usb gadget controller number X". That's doing the bind. Calling > > usb_ether_init just takes the first controller and that's that (and so > > could be / is wrong depending on the platform). > > This makes total sense, thanks for pointing it out. > > > > I also don't understand why I need to unbind the ethernet gadget but I > > > cannot bind the fastboot gadget. > > > > You can't bind fastboot while ethernet is still configured. > > I guess "before this series", the ethernet would not be kept > configured, because I could use both fastboot and ethernet without > caring about which driver had to be bound. And that's maybe what lead to > the bug reports also. So you want to get rid of this. Do I get the > situation right now? We're getting rid of this path because it leads to failures, yes. > > It's in > > use. And we aren't a full blown operating system with the logic to have > > multiple end points and devices configured and exposed. I mean heck, we > > don't keep the gadget interface up between network calls so on the host > > side you need to re-configure the interface (or have something that's > > bringing it up there again each time). Which is why DFU or fastboot or > > other "treat USB like USB" options tend to be more popular than "treat > > USB like ethernet" work flows. > > Yes of course. > > > > My underlying question is: can we have a single approach for all > > > drivers, or is it too complex today? Could it be possible, when we > > > perform these autoloads, to look up the registered gadget and > > > potentially unbind the one already in place before? > > > > I would invite you to look in to this, yes. > > Sounds reasonably complex now, with the reasoning you made above. > > > No one objects to enhancing > > the code, but the "functionality" you see on am33xx is as you've also > > seen very broken in other ways, which is why it's not used virtually > > anywhere else and instead the "bind" command is. For example, if you > > wanted to do this workflow on the new beagle devices, that's DWC3 and > > where the "bind" command came from :) > > Again to be very clear, while I felt misunderstood at the beginning and > did not accept Marek's series because it was replacing a data abort > with a non-functional setup, I now get a better understanding of the > problem (I believe) and, as said before, I am always in favor of > writing better code, easier to maintain, clearer to review. I am in > favor of such change. I just want the user life to be eased when this > happens if we break the CLI. So if you think the right approach is to > get rid of the usb_ether_init() call, alright, let's drop it off. But > we should not let the users in the dark by providing proper doc or > error messages which should compensate the extra step now required. I think it would be good if you posted a patch to update doc/board/ti/am335x_evm.rst to explain how to use the various gadget device cases.
Re: [PATCH v6 4/4] board: toradex: add verdin am62 support
On August 4, 2023 8:43:13 PM GMT+02:00, Nishanth Menon wrote: >On 14:35-20230804, Tom Rini wrote: >[..] >> > > +Output: >> > > + >> > > +.. code-block:: bash >> [snip] >> > I think you missed adding white space here. >> > >> > It renders as this: >> > https://usercontent.irccloud-cdn.com/file/625Dsdcq/image.png >> >> This is how all of the verdin boot logs render, and are all wrong. It >> should instead be: >> >> Output:: >> >> U-Boot SPL 2023.10-rc1-00210-gb678170a34c (Aug 03 2023 - 00:09:14 +0200) >> ... >> >> And I think we can take both of these as a follow-up patch that Heinrich >> will take and pass along before v2023.10 is out. > >yup, I am good with that (Marcel, I assume you will send a follow on >fix up patch). Thanks. > >-- >Regards, >Nishanth Menon >Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 >849D 1736 249D Yes, don't worry and thanks for all the valuable feedback. Cheers Marcel
Re: [PATCH v6 4/4] board: toradex: add verdin am62 support
On 14:35-20230804, Tom Rini wrote: [..] > > > +Output: > > > + > > > +.. code-block:: bash > [snip] > > I think you missed adding white space here. > > > > It renders as this: > > https://usercontent.irccloud-cdn.com/file/625Dsdcq/image.png > > This is how all of the verdin boot logs render, and are all wrong. It > should instead be: > > Output:: > > U-Boot SPL 2023.10-rc1-00210-gb678170a34c (Aug 03 2023 - 00:09:14 +0200) > ... > > And I think we can take both of these as a follow-up patch that Heinrich > will take and pass along before v2023.10 is out. yup, I am good with that (Marcel, I assume you will send a follow on fix up patch). Thanks. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v19 0/9] introduce Arm FF-A support
On Fri, Aug 04, 2023 at 02:33:36PM +0100, Abdellatif El Khlifi wrote: > Adding support for Arm FF-A v1.0 (Arm Firmware Framework for Armv8-A) [A]. > > FF-A specifies interfaces that enable a pair of software execution > environments aka partitions to > communicate with each other. A partition could be a VM in the Normal or > Secure world, an > application in S-EL0, or a Trusted OS in S-EL1. > > FF-A is a discoverable bus and similar to architecture features. > FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed > by the PSCI driver. > >=> dm tree > > Class Index Probed DriverName >--- >... > firmware 0 [ + ] psci |-- psci > ffa 0 [ ] arm_ffa | `-- arm_ffa >... > > Clients are able to probe then use the FF-A bus by calling the DM class > searching APIs (e.g: uclass_first_device). > > This implementation of the specification provides support for Aarch64. > > The FF-A driver uses the SMC ABIs defined by the FF-A specification to: > > - Discover the presence of secure partitions (SPs) of interest > - Access an SP's service through communication protocols > (e.g: EFI MM communication protocol) > > The FF-A support provides the following features: > > - Being generic by design and can be used by any Arm 64-bit platform > - FF-A support can be compiled and used without EFI > - Support for SMCCCv1.2 x0-x17 registers > - Support for SMC32 calling convention > - Support for 32-bit and 64-bit FF-A direct messaging > - Support for FF-A MM communication (compatible with EFI boot time) > - Enabling FF-A and MM communication in Corstone1000 platform as a use > case > - A Uclass driver providing generic FF-A methods. > - An Arm FF-A device driver providing Arm-specific methods and reusing > the Uclass methods. > - A sandbox emulator for Arm FF-A, emulates the FF-A side of the Secure > World and provides > FF-A ABIs inspection methods. > - An FF-A sandbox device driver for FF-A communication with the emulated > Secure World. > The driver leverages the FF-A Uclass to establish FF-A communication. > - Sandbox FF-A test cases. > - A new command called armffa is provided as an example of how to access > the > FF-A bus > > For more details about the FF-A support please refer to [B] and refer to [C] > for > how to use the armffa command. > > Please find at [D] an example of the expected boot logs when enabling > FF-A support for a platform. In this example the platform is > Corstone1000. But it can be any Arm 64-bit platform. Depending on further feedback, I will pick this up but likely just after -rc2. Given how long this has been going I will take it for v2023.10 all the same, thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH v19 8/9] arm_ffa: efi: introduce FF-A MM communication
On Fri, Aug 04, 2023 at 02:33:44PM +0100, Abdellatif El Khlifi wrote: > Add MM communication support using FF-A transport > > This feature allows accessing MM partitions services through > EFI MM communication protocol. MM partitions such as StandAlonneMM > or smm-gateway secure partitions which reside in secure world. > > An MM shared buffer and a door bell event are used to exchange > the data. > > The data is used by EFI services such as GetVariable()/SetVariable() > and copied from the communication buffer to the MM shared buffer. > > The secure partition is notified about availability of data in the > MM shared buffer by an FF-A message (door bell). > > On such event, MM SP can read the data and updates the MM shared > buffer with the response data. > > The response data is copied back to the communication buffer and > consumed by the EFI subsystem. > > MM communication protocol supports FF-A 64-bit direct messaging. > > We tested the FF-A MM communication on the Corstone-1000 platform. > > We ran the UEFI SCT test suite containing EFI setVariable, getVariable and > getNextVariable tests which involve FF-A MM communication and all tests > are passing with the current changes. > > We made the SCT test reports (part of the ACS results) public following the > latest Corstone-1000 platform software release. Please find the test > reports at [1]. > > [1]: > https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-test-report/-/tree/master/embedded-a/corstone1000/CORSTONE1000-2023.06/acs_results_fpga.zip > > Signed-off-by: Abdellatif El Khlifi > Tested-by: Gowtham Suresh Kumar > Reviewed-by: Simon Glass > Cc: Tom Rini > Cc: Ilias Apalodimas > Cc: Jens Wiklander Thanks for re-working things again. Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 4/4] board: toradex: add verdin am62 support
On Fri, Aug 04, 2023 at 01:20:03PM -0500, Nishanth Menon wrote: > On 12:08-20230804, Marcel Ziswiler wrote: > > From: Marcel Ziswiler > > > > This adds initial support for the Toradex Verdin AM62 Quad 1GB WB IT > > V1.0A module and subsequent V1.1 launch configuration SKUs. They are > > strapped to boot from their on-module eMMC. U-Boot supports booting > > from the on-module eMMC only, DFU support is disabled for now due to > > missing AM62x USB support. > > > > The device trees were taken straight from Linux v6.5-rc1. > > > > Boot sequence is: > > SYSFW ---> R5 SPL (both in tiboot3.bin) ---> ATF (TF-A) ---> OP-TEE > > ---> A53 SPL (part of tispl.bin) ---> U-boot proper (u-boot.img) > > > > Signed-off-by: Marcel Ziswiler > > > > --- > > [...] > > > diff --git a/doc/board/toradex/verdin-am62.rst > > b/doc/board/toradex/verdin-am62.rst > > new file mode 100644 > > index 000..ac0e86b3001 > > --- /dev/null > > +++ b/doc/board/toradex/verdin-am62.rst > > @@ -0,0 +1,130 @@ > > +.. SPDX-License-Identifier: GPL-2.0-or-later > > +.. sectionauthor:: Marcel Ziswiler > > + > > +Verdin AM62 Module > > +== > > + > > +Quick Start > > +--- > > I'd leave a product link here: > > Something like > `SoM <https://www.toradex.com/computer-on-modules/verdin-arm-family/ti-am62>`_ > `Dev board > <https://www.toradex.com/products/carrier-board/verdin-development-board-kit>` > > or something like that. > > > +Output: > > + > > +.. code-block:: bash [snip] > I think you missed adding white space here. > > It renders as this: > https://usercontent.irccloud-cdn.com/file/625Dsdcq/image.png This is how all of the verdin boot logs render, and are all wrong. It should instead be: Output:: U-Boot SPL 2023.10-rc1-00210-gb678170a34c (Aug 03 2023 - 00:09:14 +0200) ... And I think we can take both of these as a follow-up patch that Heinrich will take and pass along before v2023.10 is out. -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 4/4] board: toradex: add verdin am62 support
On 12:08-20230804, Marcel Ziswiler wrote: > From: Marcel Ziswiler > > This adds initial support for the Toradex Verdin AM62 Quad 1GB WB IT > V1.0A module and subsequent V1.1 launch configuration SKUs. They are > strapped to boot from their on-module eMMC. U-Boot supports booting > from the on-module eMMC only, DFU support is disabled for now due to > missing AM62x USB support. > > The device trees were taken straight from Linux v6.5-rc1. > > Boot sequence is: > SYSFW ---> R5 SPL (both in tiboot3.bin) ---> ATF (TF-A) ---> OP-TEE > ---> A53 SPL (part of tispl.bin) ---> U-boot proper (u-boot.img) > > Signed-off-by: Marcel Ziswiler > > --- [...] > diff --git a/doc/board/toradex/verdin-am62.rst > b/doc/board/toradex/verdin-am62.rst > new file mode 100644 > index 000..ac0e86b3001 > --- /dev/null > +++ b/doc/board/toradex/verdin-am62.rst > @@ -0,0 +1,130 @@ > +.. SPDX-License-Identifier: GPL-2.0-or-later > +.. sectionauthor:: Marcel Ziswiler > + > +Verdin AM62 Module > +== > + > +Quick Start > +--- I'd leave a product link here: Something like `SoM <https://www.toradex.com/computer-on-modules/verdin-arm-family/ti-am62>`_ `Dev board <https://www.toradex.com/products/carrier-board/verdin-development-board-kit>` or something like that. > +Output: > + > +.. code-block:: bash > + > +U-Boot SPL 2023.10-rc1-00210-gb678170a34c (Aug 03 2023 - 00:09:14 +0200) > +SYSFW ABI: 3.1 (firmware rev 0x0009 '9.0.1--v09.00.01 (Kool Koala)') > +SPL initial stack usage: 13368 bytes > +Trying to boot from MMC1 > +Authentication passed > +Authentication passed > +Authentication passed > +Authentication passed > +Authentication passed > +Starting ATF on ARM64 core... > + > +NOTICE: BL31: v2.9(release):v2.9.0-73-g463655cc8 > +NOTICE: BL31: Built : 14:51:42, Jun 5 2023 > +I/TC: > +I/TC: OP-TEE version: 3.21.0-168-g322cf9e33 (gcc version 12.2.1 20221205 > (Arm GNU Toolchain 12.2.Rel1 (Build arm-12.24))) #2 Mon Jun 5 13:04:15 UTC > 2023 aarch64 > +I/TC: WARNING: This OP-TEE configuration might be insecure! > +I/TC: WARNING: Please check > https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html > +I/TC: Primary CPU initializing > +I/TC: SYSFW ABI: 3.1 (firmware rev 0x0009 '9.0.1--v09.00.01 (Kool Koala)') > +I/TC: HUK Initialized > +I/TC: Primary CPU switching to normal world boot > + > +U-Boot SPL 2023.10-rc1-00210-gb678170a34c (Aug 03 2023 - 00:09:41 +0200) > +SYSFW ABI: 3.1 (firmware rev 0x0009 '9.0.1--v09.00.01 (Kool Koala)') > +SPL initial stack usage: 1840 bytes > +Trying to boot from MMC1 > +Authentication passed > +Authentication passed > + > + > +U-Boot 2023.10-rc1-00210-gb678170a34c (Aug 03 2023 - 00:09:41 +0200) > + > +SoC: AM62X SR1.0 HS-FS > +DRAM: 2 GiB > +Core: 136 devices, 28 uclasses, devicetree: separate > +MMC: mmc@fa1: 0, mmc@fa0: 1 > +Loading Environment from MMC... OK > +In:serial@280 > +Out: serial@280 > +Err: serial@280 > +Model: Toradex 0076 Verdin AM62 Quad 2GB WB IT V1.0A > +Serial#: 15037380 > +Carrier: Toradex Verdin Development Board V1.1A, Serial# 10754333 > +am65_cpsw_nuss ethernet@800: K3 CPSW: nuss_ver: 0x6BA01103 cpsw_ver: > 0x6BA81103 ale_ver: 0x00290105 Ports:2 mdio_freq:100 > +Setting variant to wifi > +Net: > +Warning: ethernet@800port@1 MAC addresses don't match: > +Address in ROM is1c:63:49:22:5f:f9 > +Address in environment is00:14:2d:e5:73:c4 > +eth0: ethernet@800port@1 [PRIME], eth1: ethernet@800port@2 > +Hit any key to stop autoboot: 0 > +Verdin AM62 # I think you missed adding white space here. It renders as this: https://usercontent.irccloud-cdn.com/file/625Dsdcq/image.png With that fixed, please feel free to add: Reviewed-by: Nishanth Menon -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH] common: board_f: Move relocation address after framebuffer
On Fri, Aug 04, 2023 at 01:10:10PM +0530, Devarsh Thakkar wrote:
> Hi Simon, Tom, Bin,
>
> Thanks for the quick feedback.
>
> On 04/08/23 04:58, Simon Glass wrote:
> > Hi Devarsh,
> >
> > On Thu, 3 Aug 2023 at 08:28, Devarsh Thakkar wrote:
> >>
> >> Hi Simon,
> >>
> >> On 03/08/23 19:32, Simon Glass wrote:
> >>> +Bin Meng
> >>>
> >>> Hi Devarsh,
> >>>
> >>> On Tue, 1 Aug 2023 at 08:04, Devarsh Thakkar wrote:
>
> When passing framebuffer address using bloblist, check
> that passed address is overlapping with current relocation
> address, if so move the relocation address after the framebuffer
> region to avoid overlap.
>
> Fixes: 5bc610a7d9d ("common: board_f: Pass frame buffer info from
> SPL to u-boot")
> Signed-off-by: Devarsh Thakkar
> ---
> common/board_f.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/common/board_f.c b/common/board_f.c
> index 7d2c380e91..20fa17207a 100644
> --- a/common/board_f.c
> +++ b/common/board_f.c
> @@ -419,7 +419,10 @@ static int reserve_video(void)
> if (!ho)
> return log_msg_ret("blf", -ENOENT);
> video_reserve_from_bloblist(ho);
> - gd->relocaddr = ho->fb;
> + /* Relocate after framebuffer area to avoid overlap */
> + if (gd->relocaddr > (unsigned long)ho->fb)
> + gd->relocaddr = ho->fb;
> +
> } else if (CONFIG_IS_ENABLED(VIDEO)) {
> ulong addr;
> int ret;
> --
> 2.34.1
>
> >>>
> >>> Yes this happens to work with qemu-x86_64. However it depends on the
> >>> SPL frame buffer being below the current allocation area. Why would it
> >>> be below, in general? This seems like a land mine for others to trip
> >>> up on.
> >>>
> >>
> >> Basically to avoid overlap, the thing we are enforcing here is that
> >> relocaddr should always be below framebuffer so that further areas
> >> reserved do not overlap with framebuffer since we decrement relocaddr to
> >> resereve them. If relocaddr is already below framebuffer then there is no
> >> need to update relocaddr as in your case otherwise we have to do it, hence
> >> working for both scenarios.
> >
> > That's not true in general. Say the frame buffer is at 1GB and
> > U-Boot's top of memory is at 2GB, then this will create a gap in the
> > reservations, so some things are just below 2GB and some others are
> > just below 1GB. There will be no indication of this...
> >
>
> Thanks Simon, I understand your point here but I think this problem is still
> there even with other approaches like separate Kconfig or SPL blob passing to
> indicate relocaddr update, as though even in that case SPL will need some base
> to take a decision on whether u-boot proper will require to move relocaddr or
> not.
>
> For e.g. in this case there is a gap of ~1Gb between relocaddr and framebuffer
> and so we don't want to move relocaddr here since we assume that most likely
> ~1Gb is enough for u-boot to carry out and complete it's reservations without
> touching the framebuffer area, but this assumption may not hold true if the
> gap is in Mb's or Kb's.
>
> To resolve this, the maximum value required for u-boot to carry out
> reservations need to be estimated and then we can make this condition more
> intelligent :
>
> if (gd->relocaddr - gd->video_top < UBOOT_MAX_RESERVE_SIZE)
> gd->relocaddr = ho->fb;
>
>
> If above looks good then, is it possible to estimate worst case common value
> for UBOOT_MAX_RESERVE_SIZE ? Or we want vendors to choose it say using a
> separate Kconfig say CONFIG_UBOOT_MAX_RESERVE_SIZE ?
>
> Kindly let me know your feedback on above approach, I can send a V2 based on
> it.
>
> Also to add, I think different vendors may choose to use different addresses
> for reserving framebuffer at SPL stage and I am not sure if one approach be
> labelled as more general above other. For e.g. Some vendors may follow same
> scheme as u-boot proper by calling reserve_video at SPL too and keep it near
> ram_top, some may keep it little away from it and some may keep it even
> farther.
My main comment right now is that by "vendors" I hope you mean "SoC
vendors" and not "platform vendors". Within a given SoC family the
address picked should be right, and if it needs adjusting (say larger
display resolution) then it must be well documented how to calculate and
in what direction it is safe to change it towards.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v6 3/4] arm: dts: k3-binman: fix rcfg_yaml and pcfg_yaml labels
On 12:08-20230804, Marcel Ziswiler wrote: > From: Marcel Ziswiler > > Fix rcfg_yaml to really point to rm-cfg.yaml and pcfg_yaml to really > point to pm-cfg.yaml which likely is the intention. > > While at it also add labels for the remaining items like custmpk_pem, > dkey_pem, bcfg_yaml_sysfw, scfg_yaml_sysfw, pcfg_yaml_sysfw and > rcfg_yaml_sysfw. > > Signed-off-by: Marcel Ziswiler Reviewed-by: Nishanth Menon -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v6 2/4] arm: mach-k3: am62: fix 2nd mux option of clkout0
On 12:08-20230804, Marcel Ziswiler wrote: > From: Marcel Ziswiler > > Fix second mux option of clkout0 which should really be > DEV_BOARD0_CLKOUT0_IN_PARENT_HSDIV4_16FFT_MAIN_2_HSDIVOUT1_CLK10 > rather than twice the same according to [1]. > > [1] > https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am62x/clocks.html#clocks-for-board0-device > > Signed-off-by: Marcel Ziswiler > Reviewed-by: Bryan Brattlof Reviewed-by: Nishanth Menon -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v6 1/4] toradex: tdx-cfg-block: add verdin am62 skus
On 12:08-20230804, Marcel Ziswiler wrote: > From: Marcel Ziswiler > > Add initial Verdin AM62 Quad 1GB WB IT prototype and launch > configuration SKUs to ConfigBlock handling. > > 0069: Verdin AM62 Quad 1GB WB IT > 0071: Verdin AM62 Solo 512MB > 0072: Verdin AM62 Solo 512MB WB IT > 0073: Verdin AM62 Dual 1GB ET > 0074: Verdin AM62 Dual 1GB IT > 0075: Verdin AM62 Dual 1GB WB IT > 0076: Verdin AM62 Quad 2GB WB IT > > Signed-off-by: Marcel Ziswiler > Signed-off-by: Emanuele Ghidoli > > --- Briefly reviewed for sanity: Reviewed-by: Nishanth Menon -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v9 4/6] bootm: Support boot measurement
On 2023-03-08 1:25 p.m., Eddie James wrote:
Add a configuration option to measure the boot through the bootm
function. Add the measurement state to the booti and bootz paths
as well.
Signed-off-by: Eddie James
Reviewed-by: Simon Glass
---
Changes since v8:
- Added a configuration option to select to ignore any existing
event log. This would only be selected for systems that know
that U-Boot is the first stage bootloader. This is necessary
because the reserved memory region may persist through resets
and so U-Boot attempts to append to the previous boot's log.
Changes since v6:
- Added comment for bootm_measure
- Fixed line length in bootm_measure
boot/Kconfig| 32 +
boot/bootm.c| 74 +
cmd/booti.c | 1 +
cmd/bootm.c | 2 ++
cmd/bootz.c | 1 +
include/bootm.h | 11
include/image.h | 1 +
7 files changed, 122 insertions(+)
diff --git a/boot/Kconfig b/boot/Kconfig
index 5f491625c8..8119519c9f 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -629,6 +629,38 @@ config LEGACY_IMAGE_FORMAT
loaded. If a board needs the legacy image format support in this
case, enable it here.
+config MEASURED_BOOT
+ bool "Measure boot images and configuration to TPM and event log"
+ depends on HASH && TPM_V2
+ help
+ This option enables measurement of the boot process. Measurement
+ involves creating cryptographic hashes of the binary images that
+ are booting and storing them in the TPM. In addition, a log of
+ these hashes is stored in memory for the OS to verify the booted
+ images and configuration. Enable this if the OS has configured
+ some memory area for the event log and you intend to use some
+ attestation tools on your system.
+
+if MEASURED_BOOT
+ config MEASURE_DEVICETREE
+ bool "Measure the devicetree image"
+ default y if MEASURED_BOOT
+ help
+ On some platforms, the devicetree is not static as it may contain
+ random MAC addresses or other such data that changes each boot.
+ Therefore, it should not be measured into the TPM. In that case,
+ disable the measurement here.
+
+ config MEASURE_IGNORE_LOG
+ bool "Ignore the existing event log"
+ default n
+ help
+ On platforms that use an event log memory region that persists
+ through system resets and are the first stage bootloader, then
+ this option should be enabled to ignore any existing data in the
+ event log memory region.
+endif # MEASURED_BOOT
+
config SUPPORT_RAW_INITRD
bool "Enable raw initrd images"
help
diff --git a/boot/bootm.c b/boot/bootm.c
index 2eec60ec7b..2685bdbd74 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#if defined(CONFIG_CMD_USB)
#include
#endif
@@ -659,6 +660,75 @@ int bootm_process_cmdline_env(int flags)
return 0;
}
+int bootm_measure(struct bootm_headers *images)
+{
+ int ret = 0;
+
+ /* Skip measurement if EFI is going to do it */
+ if (images->os.os == IH_OS_EFI &&
+ IS_ENABLED(CONFIG_EFI_TCG2_PROTOCOL) &&
+ IS_ENABLED(CONFIG_BOOTM_EFI))
+ return ret;
+
it looks like your measured boot implementation is hardcoding the
following PCR indexes:
PCR #8 - kernel image measurement
PCR #9 - initrd measurement
PCR #0 - kernel DTB measurement
PCR #1 - bootargs measurement
I wasn't able to find any specificaton on this measured boot "profile".
Are you able to provide a reference?
We've implemented our own version of measured boot, which maps
measurements to different PCR indexes. In many cases, the data we're
measuring is also different.
To make this feature more usable by others it would be nice to see a
more generic interface that would allow the user to specify the PCR
indexes, and the data to hash into these indexes. This would allow
everyone to create their own custom measured boot "profile". This
request is probably beyond the scope of your current efforts, but I
except this implementation to evolve significantly if/when it's accepted.
+ if (IS_ENABLED(CONFIG_MEASURED_BOOT)) {
+ struct tcg2_event_log elog;
+ struct udevice *dev;
+ void *initrd_buf;
+ void *image_buf;
+ const char *s;
+ u32 rd_len;
+ bool ign;
+
+ elog.log_size = 0;
+ ign = IS_ENABLED(CONFIG_MEASURE_IGNORE_LOG);
+ ret = tcg2_measurement_init(, , ign);
+ if (ret)
+ return ret;
+
+ image_buf = map_sysmem(images->os.image_start,
+ images->os.image_len);
+ ret = tcg2_measure_data(dev, , 8, images->os.image_len,
+
Re: [PATCH v4 1/4] cmd: bind: Add unbind command with driver filter
Hi Tom, tr...@konsulko.com wrote on Fri, 4 Aug 2023 13:20:29 -0400: > On Fri, Aug 04, 2023 at 07:01:46PM +0200, Miquel Raynal wrote: > > Hi Tom, > > > > > > > >>> Well, what's needed / is it possible to get to the point where we > > > > > >>> don't > > > > > >>> _need_ to call bind/unbind for each of these cases? Is there > > > > > >>> something > > > > > >>> we're supposed to be setting in the DT that we aren't? > > > > > >> > > > > > >> You do need to unbind the ethernet before using fastboot, always, > > > > > >> with the 'unbind ethernet 0', you dont need the peripheral > > > > > >> unbind/rebind part, so it should behave like before. > > > > > > > > > > > > And for my own understanding, why don't we need to bind a fastboot > > > > > > gadget? > > > > > > > > > > The fastboot command does that internally . > > > > > > > > This is not visible with dm tree and I did not find how to bind the > > > > fastboot gadget manually. > > > > > > > > This makes the CLI clearly uneven and the internal code badly different > > > > between gadgets/commands. Why can't we have them both > > > > autoloaded/unloaded like before? I think I missed something which > > > > explains the rationale behind this series. > > > > > > They aren't both auto-loaded currently. We have a legacy call, > > > usb_ether_init(), in a few cases, so that gadget mode ethernet starts. > > > But this leads to the ref counting problems you encountered and > > > re-posted the rejected series for. > > > > Ok, thanks for the additional details. > > > > I don't understand why fastboot autoloads the correct gadget driver if > > there is none bound, while all network commands just fail to do that if > > we don't make the usb_ether_init() call manually. > > Because "fastboot" or "dfu" are both being told (as part of their call) > "find usb gadget controller number X". That's doing the bind. Calling > usb_ether_init just takes the first controller and that's that (and so > could be / is wrong depending on the platform). This makes total sense, thanks for pointing it out. > > I also don't understand why I need to unbind the ethernet gadget but I > > cannot bind the fastboot gadget. > > You can't bind fastboot while ethernet is still configured. I guess "before this series", the ethernet would not be kept configured, because I could use both fastboot and ethernet without caring about which driver had to be bound. And that's maybe what lead to the bug reports also. So you want to get rid of this. Do I get the situation right now? > It's in > use. And we aren't a full blown operating system with the logic to have > multiple end points and devices configured and exposed. I mean heck, we > don't keep the gadget interface up between network calls so on the host > side you need to re-configure the interface (or have something that's > bringing it up there again each time). Which is why DFU or fastboot or > other "treat USB like USB" options tend to be more popular than "treat > USB like ethernet" work flows. Yes of course. > > My underlying question is: can we have a single approach for all > > drivers, or is it too complex today? Could it be possible, when we > > perform these autoloads, to look up the registered gadget and > > potentially unbind the one already in place before? > > I would invite you to look in to this, yes. Sounds reasonably complex now, with the reasoning you made above. > No one objects to enhancing > the code, but the "functionality" you see on am33xx is as you've also > seen very broken in other ways, which is why it's not used virtually > anywhere else and instead the "bind" command is. For example, if you > wanted to do this workflow on the new beagle devices, that's DWC3 and > where the "bind" command came from :) Again to be very clear, while I felt misunderstood at the beginning and did not accept Marek's series because it was replacing a data abort with a non-functional setup, I now get a better understanding of the problem (I believe) and, as said before, I am always in favor of writing better code, easier to maintain, clearer to review. I am in favor of such change. I just want the user life to be eased when this happens if we break the CLI. So if you think the right approach is to get rid of the usb_ether_init() call, alright, let's drop it off. But we should not let the users in the dark by providing proper doc or error messages which should compensate the extra step now required. Thanks, Miquèl
Re: [PATCH v4 1/4] cmd: bind: Add unbind command with driver filter
On 8/4/23 19:46, Miquel Raynal wrote: Hi Marek, ma...@denx.de wrote on Fri, 4 Aug 2023 19:31:50 +0200: On 8/4/23 19:24, Miquel Raynal wrote: Hi, exit not allowed from main input shell. => unbind /ocp/usb@4740/usb@47401000 usb_ether Does => unbind ethernet 0 work ? If so, 1/4 in this series can be skipped altogether. You likely won't even need the rebinding of ti-musb-peripheral anymore. Did you test this yet ? Unfortunately it does not work. Indeed it would be much simpler than using the node path. Any idea why? Since you provided literally zero information, no. Console log would be a good starting point. Here it is, the unbind command itself does not complain has it seems to catch the regular Ethernet controller (there is one in the SoC, but it is not wired on the board). So the first time it does nothing, but the second time it works as the USB gadget get dropped! And after the second call, fastboot works without the bind call. => dm tree misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 usb 0 [ + ] ti-musb-peripheral| | |-- usb@47401000 ethernet 1 [ + ] usb_ether | | | `-- usb_ether ^ unbind ethernet 1
Re: [PATCH v4 1/4] cmd: bind: Add unbind command with driver filter
Hi Marek, ma...@denx.de wrote on Fri, 4 Aug 2023 19:31:50 +0200: > On 8/4/23 19:24, Miquel Raynal wrote: > > Hi, > > >>> exit not allowed from main input shell. > >>> => unbind /ocp/usb@4740/usb@47401000 usb_ether > >> > >> Does > >> => unbind ethernet 0 > >> > >> work ? > >> > >> If so, 1/4 in this series can be skipped altogether. > >> > >> You likely won't even need the rebinding of ti-musb-peripheral > >> anymore. > >> > >> Did you test this yet ? > > > > Unfortunately it does not work. Indeed it would be much simpler than > > using the node path. Any idea why? > > Since you provided literally zero information, no. > > Console log would be a good starting point. Here it is, the unbind command itself does not complain has it seems to catch the regular Ethernet controller (there is one in the SoC, but it is not wired on the board). So the first time it does nothing, but the second time it works as the USB gadget get dropped! And after the second call, fastboot works without the bind call. => dm tree misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 usb 0 [ + ] ti-musb-peripheral| | |-- usb@47401000 ethernet 1 [ + ] usb_ether | | | `-- usb_ether bootdev 3 [ ] eth_bootdev | | | `-- usb_ether.bootdev usb 0 [ ] ti-musb-host | | `-- usb@47401800 ethernet 0 [ + ] eth_cpsw | |-- ethernet@4a10 bootdev 2 [ ] eth_bootdev | | `-- ethernet@4a10.bootdev => unbind ethernet 0 => dm tree misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 usb 0 [ + ] ti-musb-peripheral| | |-- usb@47401000 ethernet 0 [ + ] usb_ether | | | `-- usb_ether bootdev 2 [ ] eth_bootdev | | | `-- usb_ether.bootdev usb 0 [ ] ti-musb-host | | `-- usb@47401800 => unbind ethernet 0 => dm tree misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 usb 0 [ ] ti-musb-peripheral| | |-- usb@47401000 usb 0 [ ] ti-musb-host | | `-- usb@47401800 So actually the unbind works, but was not targeting the right controller, because it's listed as the second Ethernet controller on this board. Hence this actually works: => unbind ethernet 1 => fastboot usb 0 \o/ Thanks, Miquèl
Re: [PATCH v4 1/4] cmd: bind: Add unbind command with driver filter
On 8/4/23 19:24, Miquel Raynal wrote:
Hi,
exit not allowed from main input shell.
=> unbind /ocp/usb@4740/usb@47401000 usb_ether
Does
=> unbind ethernet 0
work ?
If so, 1/4 in this series can be skipped altogether.
You likely won't even need the rebinding of ti-musb-peripheral anymore.
Did you test this yet ?
Unfortunately it does not work. Indeed it would be much simpler than
using the node path. Any idea why?
Since you provided literally zero information, no.
Console log would be a good starting point.
Re: [PATCH v4 1/4] cmd: bind: Add unbind command with driver filter
Hi Marek, ma...@denx.de wrote on Fri, 4 Aug 2023 17:40:07 +0200: > On 8/4/23 17:12, Miquel Raynal wrote: > > Hi, > > > > ma...@denx.de wrote on Fri, 4 Aug 2023 17:05:01 +0200: > > > >> On 8/4/23 17:01, Tom Rini wrote: > >>> On Fri, Aug 04, 2023 at 04:42:13PM +0200, Marek Vasut wrote: > On 8/4/23 09:00, Miquel Raynal wrote: > > Hi Marek, > > > > ma...@denx.de wrote on Wed, 2 Aug 2023 14:46:54 +0200: > > >> Extend the driver core to perform lookup by both OF node and > > driver > >> bound to the node. Use this to look up specific device instances to > >> unbind from nodes in the unbind command. One example where this is > >> needed is USB peripheral controller, which may have multiple gadget > >> drivers bound to it. The unbind command has to select that specific > >> gadget driver instance to unbind from the controller, not unbind the > >> controller driver itself from the controller. > >> > >> USB ethernet gadget usage looks as follows with this change. Notice > >> the extra 'usb_ether' addition in the 'unbind' command at the end. > >> " > >> bind /soc/usb-otg@4900 usb_ether > >> setenv ethact usb_ether > >> setenv loadaddr 0xc200 > >> setenv ipaddr 10.0.0.2 > >> setenv serverip 10.0.0.1 > >> setenv netmask 255.255.255.0 > >> tftpboot 0xc200 10.0.0.1:test.file > >> unbind /soc/usb-otg@4900 usb_ether > > > > This extra parameter does not seem to work on the BBBW. I cannot select > > the "usb_ether" driver like you do. > > > > Good news though, I am now able to use fastboot, but it is not > > straightforward: > > > > Here is my sequence right after the boot (reducing the dm tree output > > to the usb nodes for clarity): > > > => dm tree > > misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 > > usb 0 [ + ] ti-musb-peripheral| | |-- > > usb@47401000 > > ethernet 1 [ + ] usb_ether | | | `-- > > usb_ether > > bootdev 3 [ ] eth_bootdev | | | `-- > > usb_ether.bootdev > > usb 0 [ ] ti-musb-host | | `-- > > usb@47401800 > > => fastboot usb 0 > > couldn't find an available UDC > > g_dnl_register: failed!, error: -19 > > That is expected and not a bug, since the beagle explicitly binds USB > ethernet to MUSB gadget in board file, which is legacy deprecated way. > >>> > >>> So, we should do away with, probably all of arch_misc_init() in > >>> arch/arm/mach-omap2/am33xx/board.c for the non-SPL case. > >> > >> Yes > >> > > exit not allowed from main input shell. > > => unbind /ocp/usb@4740/usb@47401000 usb_ether > > Does > => unbind ethernet 0 > > work ? > > If so, 1/4 in this series can be skipped altogether. > > You likely won't even need the rebinding of ti-musb-peripheral anymore. > > Did you test this yet ? Unfortunately it does not work. Indeed it would be much simpler than using the node path. Any idea why? Thanks, Miquèl
Re: [PATCH v4 1/4] cmd: bind: Add unbind command with driver filter
On Fri, Aug 04, 2023 at 07:04:31PM +0200, Miquel Raynal wrote: > Hi Tom, > > > > > > Cannot find a device with path /ocp/usb@4740/usb@47401000 > > > > > => unbind /ocp/usb@4740/usb@47401000 > > > > > => dm tree > > > > > misc 0 [ + ] ti-musb-wrapper | |-- > > > > > usb@4740 > > > > > usb 0 [ ] ti-musb-host | | `-- > > > > > usb@47401800 > > > > > => fastboot usb 0 > > > > > => bind /ocp/usb@4740/usb@47401000 ti-musb-peripheral > > > > > => dm tree > > > > > misc 0 [ + ] ti-musb-wrapper | |-- > > > > > usb@4740 > > > > > usb 0 [ ] ti-musb-host | | |-- > > > > > usb@47401800 > > > > > usb 0 [ ] ti-musb-peripheral| | `-- > > > > > usb@47401000 > > > > > => fastboot usb 0 > > > > > musb-hdrc: peripheral reset irq lost! > > > > > # works! (the irq-related line above as always been there) > > > > > > > > > > So now, how do we make this process easy/understandable? > > > > > > > > What would be your proposal ? > > > > > > > > > > At least I would appreciate: > > > > > - to select CMD_BIND "by default" when relevant > > > > > - to make the fastboot error more readable for the regular user > > > > > > > > Since with this 'unbind ethernet 0' this is orthogonal to this series, > > > > send separate patches, thanks. > > > > > > This is not orthogonal, I am sorry. > > > > > > version X: > > > - tftp works "out of the box" > > > - fastboot works "out of the box" > > > version X+1: > > > - tftp works "out of the box" > > > - fastboot returns an obscure error > > > > > > 1/ If we now *need* the bind/unbind commands, the series must take care > > >of it. > > > 2/ Without proper error message you just break fastboot for most > > >regular users (basically everyone but few U-Boot devs). > > > > You're missing the class of users that will be impacted here. In order > > for there to be a change here, you have to already be in the case where > > you have CONFIG_USB_ETHER=y and gadget ethernet device isn't just > > enabled but also initialized by default by calling usb_ether_init(). > > That's a very small list. It's basically am33xx, two mediatek reference > > platforms and xilinx_zynqmp_virt. Given that am33xx defconfigs also > > setup DFU, I'm not really sure just how many people use gadget ethernet. > > The normal flow on modern devices is to be calling bind/unbind here > > already. > > Can we make this behavior explicit to the user? I am sorry, maybe it is > the normal flow for you, but I am a regular U-Boot user and I totally > missed that requirement. > > Typical situation: one needs to use but none is bound > to the UDC (or another is bound), could we make the error messages more > explicit if we decide not to unbind/bind the right one automatically > because it is too "costly"? If you would like to improve this, yes, please do. The uncommon case is where gadget ethernet and fastboot/dfu/etc are also being used one after the other. The typical case is you just fastboot or dfu or whatever, and that command requires you to say what usb controller you're binding to and so works. -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 1/4] cmd: bind: Add unbind command with driver filter
On Fri, Aug 04, 2023 at 07:01:46PM +0200, Miquel Raynal wrote: > Hi Tom, > > > > > >>> Well, what's needed / is it possible to get to the point where we > > > > >>> don't > > > > >>> _need_ to call bind/unbind for each of these cases? Is there > > > > >>> something > > > > >>> we're supposed to be setting in the DT that we aren't? > > > > >> > > > > >> You do need to unbind the ethernet before using fastboot, always, > > > > >> with the 'unbind ethernet 0', you dont need the peripheral > > > > >> unbind/rebind part, so it should behave like before. > > > > > > > > > > And for my own understanding, why don't we need to bind a fastboot > > > > > gadget? > > > > > > > > The fastboot command does that internally . > > > > > > This is not visible with dm tree and I did not find how to bind the > > > fastboot gadget manually. > > > > > > This makes the CLI clearly uneven and the internal code badly different > > > between gadgets/commands. Why can't we have them both > > > autoloaded/unloaded like before? I think I missed something which > > > explains the rationale behind this series. > > > > They aren't both auto-loaded currently. We have a legacy call, > > usb_ether_init(), in a few cases, so that gadget mode ethernet starts. > > But this leads to the ref counting problems you encountered and > > re-posted the rejected series for. > > Ok, thanks for the additional details. > > I don't understand why fastboot autoloads the correct gadget driver if > there is none bound, while all network commands just fail to do that if > we don't make the usb_ether_init() call manually. Because "fastboot" or "dfu" are both being told (as part of their call) "find usb gadget controller number X". That's doing the bind. Calling usb_ether_init just takes the first controller and that's that (and so could be / is wrong depending on the platform). > I also don't understand why I need to unbind the ethernet gadget but I > cannot bind the fastboot gadget. You can't bind fastboot while ethernet is still configured. It's in use. And we aren't a full blown operating system with the logic to have multiple end points and devices configured and exposed. I mean heck, we don't keep the gadget interface up between network calls so on the host side you need to re-configure the interface (or have something that's bringing it up there again each time). Which is why DFU or fastboot or other "treat USB like USB" options tend to be more popular than "treat USB like ethernet" work flows. > My underlying question is: can we have a single approach for all > drivers, or is it too complex today? Could it be possible, when we > perform these autoloads, to look up the registered gadget and > potentially unbind the one already in place before? I would invite you to look in to this, yes. No one objects to enhancing the code, but the "functionality" you see on am33xx is as you've also seen very broken in other ways, which is why it's not used virtually anywhere else and instead the "bind" command is. For example, if you wanted to do this workflow on the new beagle devices, that's DWC3 and where the "bind" command came from :) -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 1/4] cmd: bind: Add unbind command with driver filter
On 8/4/23 19:04, Miquel Raynal wrote: Hi Tom, Cannot find a device with path /ocp/usb@4740/usb@47401000 => unbind /ocp/usb@4740/usb@47401000 => dm tree misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 usb 0 [ ] ti-musb-host | | `-- usb@47401800 => fastboot usb 0 => bind /ocp/usb@4740/usb@47401000 ti-musb-peripheral => dm tree misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 usb 0 [ ] ti-musb-host | | |-- usb@47401800 usb 0 [ ] ti-musb-peripheral| | `-- usb@47401000 => fastboot usb 0 musb-hdrc: peripheral reset irq lost! # works! (the irq-related line above as always been there) So now, how do we make this process easy/understandable? What would be your proposal ? At least I would appreciate: - to select CMD_BIND "by default" when relevant - to make the fastboot error more readable for the regular user Since with this 'unbind ethernet 0' this is orthogonal to this series, send separate patches, thanks. This is not orthogonal, I am sorry. version X: - tftp works "out of the box" - fastboot works "out of the box" version X+1: - tftp works "out of the box" - fastboot returns an obscure error 1/ If we now *need* the bind/unbind commands, the series must take care of it. 2/ Without proper error message you just break fastboot for most regular users (basically everyone but few U-Boot devs). You're missing the class of users that will be impacted here. In order for there to be a change here, you have to already be in the case where you have CONFIG_USB_ETHER=y and gadget ethernet device isn't just enabled but also initialized by default by calling usb_ether_init(). That's a very small list. It's basically am33xx, two mediatek reference platforms and xilinx_zynqmp_virt. Given that am33xx defconfigs also setup DFU, I'm not really sure just how many people use gadget ethernet. The normal flow on modern devices is to be calling bind/unbind here already. Can we make this behavior explicit to the user? I am sorry, maybe it is the normal flow for you, but I am a regular U-Boot user and I totally missed that requirement. Typical situation: one needs to use but none is bound to the UDC (or another is bound), could we make the error messages more explicit if we decide not to unbind/bind the right one automatically because it is too "costly"? Maybe you could implement a documentation patch, since you are not yet tainted by all the "I work on in day in day out, so it is obvious to me" thing ?
Re: [PATCH v4 1/4] cmd: bind: Add unbind command with driver filter
On 8/4/23 19:01, Miquel Raynal wrote: Hi Tom, Well, what's needed / is it possible to get to the point where we don't _need_ to call bind/unbind for each of these cases? Is there something we're supposed to be setting in the DT that we aren't? You do need to unbind the ethernet before using fastboot, always, with the 'unbind ethernet 0', you dont need the peripheral unbind/rebind part, so it should behave like before. And for my own understanding, why don't we need to bind a fastboot gadget? The fastboot command does that internally . This is not visible with dm tree and I did not find how to bind the fastboot gadget manually. This makes the CLI clearly uneven and the internal code badly different between gadgets/commands. Why can't we have them both autoloaded/unloaded like before? I think I missed something which explains the rationale behind this series. They aren't both auto-loaded currently. We have a legacy call, usb_ether_init(), in a few cases, so that gadget mode ethernet starts. But this leads to the ref counting problems you encountered and re-posted the rejected series for. Ok, thanks for the additional details. I don't understand why fastboot autoloads the correct gadget driver if there is none bound, while all network commands just fail to do that if we don't make the usb_ether_init() call manually. Look into cmd/fastboot.c , it does usb_gadget_initialize(0) , just like usb_ether_init() does. I also don't understand why I need to unbind the ethernet gadget but I cannot bind the fastboot gadget. Look into cmd/fastboot.c , it does usb_gadget_release() at the end of its operation, just like usb_eth_unbind() which is triggered by the bind/unbind commands. My underlying question is: can we have a single approach for all drivers, or is it too complex today? Could it be possible, when we perform these autoloads, to look up the registered gadget and potentially unbind the one already in place before? The usb ethernet is special as there is no "ethernet" command like the "fastboot" command , which is why it has to be special handled by the bind/unbind commands.
Re: [PATCH] cmd: Enable BIND by default if we have USB_ETHER
Hi Tom, tr...@konsulko.com wrote on Fri, 4 Aug 2023 12:06:21 -0400: > The nature of the network stack means that if we are going to use the > gadget mode USB network driver there's no easy path to implicitly > bind/unbind the driver. Enable the "bind" command by default here so > that we can bind/unbind this as needed. > > Signed-off-by: Tom Rini > --- > Cc: Marek Vasut > Cc: Miquel Raynal Reviewed-by: Miquel Raynal Thanks, Miquèl
Re: [PATCH v4 1/4] cmd: bind: Add unbind command with driver filter
Hi Tom, > > > > Cannot find a device with path /ocp/usb@4740/usb@47401000 > > > > => unbind /ocp/usb@4740/usb@47401000 > > > > => dm tree > > > > misc 0 [ + ] ti-musb-wrapper | |-- > > > > usb@4740 > > > > usb 0 [ ] ti-musb-host | | `-- > > > > usb@47401800 > > > > => fastboot usb 0 > > > > => bind /ocp/usb@4740/usb@47401000 ti-musb-peripheral > > > > => dm tree > > > > misc 0 [ + ] ti-musb-wrapper | |-- > > > > usb@4740 > > > > usb 0 [ ] ti-musb-host | | |-- > > > > usb@47401800 > > > > usb 0 [ ] ti-musb-peripheral| | `-- > > > > usb@47401000 > > > > => fastboot usb 0 > > > > musb-hdrc: peripheral reset irq lost! > > > > # works! (the irq-related line above as always been there) > > > > > > > > So now, how do we make this process easy/understandable? > > > > > > What would be your proposal ? > > > > > > > > At least I would appreciate: > > > > - to select CMD_BIND "by default" when relevant > > > > - to make the fastboot error more readable for the regular user > > > > > > Since with this 'unbind ethernet 0' this is orthogonal to this series, > > > send separate patches, thanks. > > > > This is not orthogonal, I am sorry. > > > > version X: > > - tftp works "out of the box" > > - fastboot works "out of the box" > > version X+1: > > - tftp works "out of the box" > > - fastboot returns an obscure error > > > > 1/ If we now *need* the bind/unbind commands, the series must take care > >of it. > > 2/ Without proper error message you just break fastboot for most > >regular users (basically everyone but few U-Boot devs). > > You're missing the class of users that will be impacted here. In order > for there to be a change here, you have to already be in the case where > you have CONFIG_USB_ETHER=y and gadget ethernet device isn't just > enabled but also initialized by default by calling usb_ether_init(). > That's a very small list. It's basically am33xx, two mediatek reference > platforms and xilinx_zynqmp_virt. Given that am33xx defconfigs also > setup DFU, I'm not really sure just how many people use gadget ethernet. > The normal flow on modern devices is to be calling bind/unbind here > already. Can we make this behavior explicit to the user? I am sorry, maybe it is the normal flow for you, but I am a regular U-Boot user and I totally missed that requirement. Typical situation: one needs to use but none is bound to the UDC (or another is bound), could we make the error messages more explicit if we decide not to unbind/bind the right one automatically because it is too "costly"? Thanks, Miquèl
Re: [PATCH v4 1/4] cmd: bind: Add unbind command with driver filter
Hi Tom, > > > >>> Well, what's needed / is it possible to get to the point where we > > > >>> don't > > > >>> _need_ to call bind/unbind for each of these cases? Is there something > > > >>> we're supposed to be setting in the DT that we aren't? > > > >> > > > >> You do need to unbind the ethernet before using fastboot, always, with > > > >> the 'unbind ethernet 0', you dont need the peripheral unbind/rebind > > > >> part, so it should behave like before. > > > > > > > > And for my own understanding, why don't we need to bind a fastboot > > > > gadget? > > > > > > The fastboot command does that internally . > > > > This is not visible with dm tree and I did not find how to bind the > > fastboot gadget manually. > > > > This makes the CLI clearly uneven and the internal code badly different > > between gadgets/commands. Why can't we have them both > > autoloaded/unloaded like before? I think I missed something which > > explains the rationale behind this series. > > They aren't both auto-loaded currently. We have a legacy call, > usb_ether_init(), in a few cases, so that gadget mode ethernet starts. > But this leads to the ref counting problems you encountered and > re-posted the rejected series for. Ok, thanks for the additional details. I don't understand why fastboot autoloads the correct gadget driver if there is none bound, while all network commands just fail to do that if we don't make the usb_ether_init() call manually. I also don't understand why I need to unbind the ethernet gadget but I cannot bind the fastboot gadget. My underlying question is: can we have a single approach for all drivers, or is it too complex today? Could it be possible, when we perform these autoloads, to look up the registered gadget and potentially unbind the one already in place before? Thanks, Miquèl
Re: [PATCH v4 1/4] cmd: bind: Add unbind command with driver filter
On Fri, Aug 04, 2023 at 06:00:12PM +0200, Miquel Raynal wrote: > Hi Marek, > > ma...@denx.de wrote on Fri, 4 Aug 2023 17:40:07 +0200: > > > On 8/4/23 17:12, Miquel Raynal wrote: > > > Hi, > > > > > > ma...@denx.de wrote on Fri, 4 Aug 2023 17:05:01 +0200: > > > > > >> On 8/4/23 17:01, Tom Rini wrote: > > >>> On Fri, Aug 04, 2023 at 04:42:13PM +0200, Marek Vasut wrote: > > On 8/4/23 09:00, Miquel Raynal wrote: > > > Hi Marek, > > > > > > ma...@denx.de wrote on Wed, 2 Aug 2023 14:46:54 +0200: > > > >> Extend the driver core to perform lookup by both OF node and > > > driver > > >> bound to the node. Use this to look up specific device instances to > > >> unbind from nodes in the unbind command. One example where this is > > >> needed is USB peripheral controller, which may have multiple gadget > > >> drivers bound to it. The unbind command has to select that specific > > >> gadget driver instance to unbind from the controller, not unbind the > > >> controller driver itself from the controller. > > >> > > >> USB ethernet gadget usage looks as follows with this change. Notice > > >> the extra 'usb_ether' addition in the 'unbind' command at the end. > > >> " > > >> bind /soc/usb-otg@4900 usb_ether > > >> setenv ethact usb_ether > > >> setenv loadaddr 0xc200 > > >> setenv ipaddr 10.0.0.2 > > >> setenv serverip 10.0.0.1 > > >> setenv netmask 255.255.255.0 > > >> tftpboot 0xc200 10.0.0.1:test.file > > >> unbind /soc/usb-otg@4900 usb_ether > > > > > > This extra parameter does not seem to work on the BBBW. I cannot > > > select > > > the "usb_ether" driver like you do. > > > > > > Good news though, I am now able to use fastboot, but it is not > > > straightforward: > > > > > > Here is my sequence right after the boot (reducing the dm tree output > > > to the usb nodes for clarity): > > > > => dm tree > > > misc 0 [ + ] ti-musb-wrapper | |-- > > > usb@4740 > > > usb 0 [ + ] ti-musb-peripheral| | |-- > > > usb@47401000 > > > ethernet 1 [ + ] usb_ether | | | `-- > > > usb_ether > > > bootdev 3 [ ] eth_bootdev | | | > > > `-- usb_ether.bootdev > > > usb 0 [ ] ti-musb-host | | `-- > > > usb@47401800 > > > => fastboot usb 0 > > > couldn't find an available UDC > > > g_dnl_register: failed!, error: -19 > > > > That is expected and not a bug, since the beagle explicitly binds USB > > ethernet to MUSB gadget in board file, which is legacy deprecated way. > > > > >>> > > >>> So, we should do away with, probably all of arch_misc_init() in > > >>> arch/arm/mach-omap2/am33xx/board.c for the non-SPL case. > > >> > > >> Yes > > >> > > > exit not allowed from main input shell. > > > => unbind /ocp/usb@4740/usb@47401000 usb_ether > > > > Does > > => unbind ethernet 0 > > > > work ? > > > > If so, 1/4 in this series can be skipped altogether. > > > > You likely won't even need the rebinding of ti-musb-peripheral > > anymore. > > > > Did you test this yet ? > > Not yet, I'll send you the feedback once done. > > > > Cannot find a device with path /ocp/usb@4740/usb@47401000 > > > => unbind /ocp/usb@4740/usb@47401000 > > > => dm tree > > > misc 0 [ + ] ti-musb-wrapper | |-- > > > usb@4740 > > > usb 0 [ ] ti-musb-host | | `-- > > > usb@47401800 > > > => fastboot usb 0 > > > => bind /ocp/usb@4740/usb@47401000 ti-musb-peripheral > > > => dm tree > > > misc 0 [ + ] ti-musb-wrapper | |-- > > > usb@4740 > > > usb 0 [ ] ti-musb-host | | |-- > > > usb@47401800 > > > usb 0 [ ] ti-musb-peripheral| | `-- > > > usb@47401000 > > > => fastboot usb 0 > > > musb-hdrc: peripheral reset irq lost! > > > # works! (the irq-related line above as always been there) > > > > > > So now, how do we make this process easy/understandable? > > > > What would be your proposal ? > > > > > > At least I would appreciate: > > > - to select CMD_BIND "by default" when relevant > > > - to make the fastboot error more readable for the regular user > > > > Since with this 'unbind ethernet 0' this is orthogonal to this series, send > > separate patches, thanks. > > This is not orthogonal, I am sorry. > > version X: > - tftp works "out of the box" > - fastboot works "out of the box" > version X+1: > - tftp works "out of the box" > - fastboot returns an obscure error > > 1/ If we now *need* the
Re: [PATCH v4 1/4] cmd: bind: Add unbind command with driver filter
On Fri, Aug 04, 2023 at 06:00:12PM +0200, Miquel Raynal wrote: > Hi Marek, > > ma...@denx.de wrote on Fri, 4 Aug 2023 17:40:07 +0200: > > > On 8/4/23 17:12, Miquel Raynal wrote: > > > Hi, > > > > > > ma...@denx.de wrote on Fri, 4 Aug 2023 17:05:01 +0200: > > > > > >> On 8/4/23 17:01, Tom Rini wrote: > > >>> On Fri, Aug 04, 2023 at 04:42:13PM +0200, Marek Vasut wrote: > > On 8/4/23 09:00, Miquel Raynal wrote: > > > Hi Marek, > > > > > > ma...@denx.de wrote on Wed, 2 Aug 2023 14:46:54 +0200: > > > >> Extend the driver core to perform lookup by both OF node and > > > driver > > >> bound to the node. Use this to look up specific device instances to > > >> unbind from nodes in the unbind command. One example where this is > > >> needed is USB peripheral controller, which may have multiple gadget > > >> drivers bound to it. The unbind command has to select that specific > > >> gadget driver instance to unbind from the controller, not unbind the > > >> controller driver itself from the controller. > > >> > > >> USB ethernet gadget usage looks as follows with this change. Notice > > >> the extra 'usb_ether' addition in the 'unbind' command at the end. > > >> " > > >> bind /soc/usb-otg@4900 usb_ether > > >> setenv ethact usb_ether > > >> setenv loadaddr 0xc200 > > >> setenv ipaddr 10.0.0.2 > > >> setenv serverip 10.0.0.1 > > >> setenv netmask 255.255.255.0 > > >> tftpboot 0xc200 10.0.0.1:test.file > > >> unbind /soc/usb-otg@4900 usb_ether > > > > > > This extra parameter does not seem to work on the BBBW. I cannot > > > select > > > the "usb_ether" driver like you do. > > > > > > Good news though, I am now able to use fastboot, but it is not > > > straightforward: > > > > > > Here is my sequence right after the boot (reducing the dm tree output > > > to the usb nodes for clarity): > > > > => dm tree > > > misc 0 [ + ] ti-musb-wrapper | |-- > > > usb@4740 > > > usb 0 [ + ] ti-musb-peripheral| | |-- > > > usb@47401000 > > > ethernet 1 [ + ] usb_ether | | | `-- > > > usb_ether > > > bootdev 3 [ ] eth_bootdev | | | > > > `-- usb_ether.bootdev > > > usb 0 [ ] ti-musb-host | | `-- > > > usb@47401800 > > > => fastboot usb 0 > > > couldn't find an available UDC > > > g_dnl_register: failed!, error: -19 > > > > That is expected and not a bug, since the beagle explicitly binds USB > > ethernet to MUSB gadget in board file, which is legacy deprecated way. > > > > >>> > > >>> So, we should do away with, probably all of arch_misc_init() in > > >>> arch/arm/mach-omap2/am33xx/board.c for the non-SPL case. > > >> > > >> Yes > > >> > > > exit not allowed from main input shell. > > > => unbind /ocp/usb@4740/usb@47401000 usb_ether > > > > Does > > => unbind ethernet 0 > > > > work ? > > > > If so, 1/4 in this series can be skipped altogether. > > > > You likely won't even need the rebinding of ti-musb-peripheral > > anymore. > > > > Did you test this yet ? > > Not yet, I'll send you the feedback once done. > > > > Cannot find a device with path /ocp/usb@4740/usb@47401000 > > > => unbind /ocp/usb@4740/usb@47401000 > > > => dm tree > > > misc 0 [ + ] ti-musb-wrapper | |-- > > > usb@4740 > > > usb 0 [ ] ti-musb-host | | `-- > > > usb@47401800 > > > => fastboot usb 0 > > > => bind /ocp/usb@4740/usb@47401000 ti-musb-peripheral > > > => dm tree > > > misc 0 [ + ] ti-musb-wrapper | |-- > > > usb@4740 > > > usb 0 [ ] ti-musb-host | | |-- > > > usb@47401800 > > > usb 0 [ ] ti-musb-peripheral| | `-- > > > usb@47401000 > > > => fastboot usb 0 > > > musb-hdrc: peripheral reset irq lost! > > > # works! (the irq-related line above as always been there) > > > > > > So now, how do we make this process easy/understandable? > > > > What would be your proposal ? > > > > > > At least I would appreciate: > > > - to select CMD_BIND "by default" when relevant > > > - to make the fastboot error more readable for the regular user > > > > Since with this 'unbind ethernet 0' this is orthogonal to this series, send > > separate patches, thanks. > > This is not orthogonal, I am sorry. > > version X: > - tftp works "out of the box" > - fastboot works "out of the box" > version X+1: > - tftp works "out of the box" > - fastboot returns an obscure error > > 1/ If we now *need* the
Re: [PATCH v5 3/3] usb: gadget: ether: Handle gadget driver registration in probe and remove
On Fri, Aug 04, 2023 at 05:41:11PM +0200, Marek Vasut wrote: > Move the ethernet gadget driver registration and removal from ethernet > bind and unbind callbacks into driver DM probe and remove callbacks. > This way, when the driver is bound, which is triggered deliberately > using 'bind' command, the USB ethernet gadget driver is instantiated > and bound to the matching UDC. In reverse, when the driver is unbound, > which is again triggered deliberately using 'unbind' command, the USB > ethernet gadget driver instance is removed. > > Effectively, this now behaves like running either 'ums' or 'dfu' or > any other commands utilizing USB gadget functionality. > > This also drops use of usb_gadget_release() and moves the use of > usb_gadget_initialize() into usb_ether_init() used only by legacy > platforms that do not use 'bind' command properly yet. Those have > no place in drivers. > > Signed-off-by: Marek Vasut Tested-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 2/3] usb: gadget: ether: Move probe function above driver structure
On Fri, Aug 04, 2023 at 05:41:10PM +0200, Marek Vasut wrote: > Move the driver probe function above the driver structure, so it > can be placed alongside other related functions, like upcoming > remove function. No functional change. > > Signed-off-by: Marek Vasut Tested-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 1/3] usb: gadget: ether: Inline functions used once
On Fri, Aug 04, 2023 at 05:41:09PM +0200, Marek Vasut wrote: > These functions here are only ever called once since drop of non-DM > networking code. Inline them. No functional change. > > Signed-off-by: Marek Vasut Tested-by: Tom Rini -- Tom signature.asc Description: PGP signature
[PATCH] cmd: Enable BIND by default if we have USB_ETHER
The nature of the network stack means that if we are going to use the gadget mode USB network driver there's no easy path to implicitly bind/unbind the driver. Enable the "bind" command by default here so that we can bind/unbind this as needed. Signed-off-by: Tom Rini --- Cc: Marek Vasut Cc: Miquel Raynal --- cmd/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/cmd/Kconfig b/cmd/Kconfig index 2d6e5f993f04..7f65e3187a66 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -986,6 +986,7 @@ config CMD_BCB config CMD_BIND bool "bind/unbind - Bind or unbind a device to/from a driver" depends on DM + default y if USB_ETHER help Bind or unbind a device to/from a driver from the command line. This is useful in situations where a device may be handled by several -- 2.34.1
Re: [PATCH v2] ARM: dts: stm32: Switch DWMAC RMII clock to MCO2 on DHCOM
On 7/27/23 01:58, Marek Vasut wrote:
> The DHCOM SoM has two options for supplying ETHRX clock to the DWMAC
> block and PHY. Either (1) ETHCK_K generates 50 MHz clock on ETH_CLK
> pad for the PHY and the same 50 MHz clock are fed back to ETHRX via
> internal eth_clk_fb clock connection OR (2) ETH_CLK is not used at
> all, MCO2 generates 50 MHz clock on MCO2 output pad for the PHY and
> the same MCO2 clock are fed back into ETHRX via ETH_RX_CLK input pad
> using external pad-to-pad connection.
>
> Option (1) has two downsides. ETHCK_K is supplied directly from either
> PLL3_Q or PLL4_P, hence the PLL output is limited to exactly 50 MHz and
> since the same PLL output is also used to supply SDMMC blocks, the
> performance of SD and eMMC access is affected. The second downside is
> that using this option, the EMI of the SoM is higher.
>
> Option (2) solves both of those problems, so implement it here. In this
> case, the PLL4_P is no longer limited and can be operated faster, at
> 100 MHz, which improves SDMMC performance (read performance is improved
> from ~41 MiB/s to ~57 MiB/s with dd if=/dev/mmcblk1 of=/dev/null bs=64M
> count=1). The EMI interference also decreases.
>
> Ported from Linux kernel commit
> 73ab99aad50cd ("ARM: dts: stm32: Switch DWMAC RMII clock to MCO2 on DHCOM")
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: u-b...@dh-electronics.com
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> V2: Add U-Boot specifics to cater also for clock and clock-names in
> stm32mp151.dtsi
> ---
> arch/arm/dts/stm32mp15xx-dhcom-som.dtsi| 22 ++
> arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 14 ++
> 2 files changed, 32 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp15xx-dhcom-som.dtsi
> b/arch/arm/dts/stm32mp15xx-dhcom-som.dtsi
> index 83e2c87713f..238a611192e 100644
> --- a/arch/arm/dts/stm32mp15xx-dhcom-som.dtsi
> +++ b/arch/arm/dts/stm32mp15xx-dhcom-som.dtsi
> @@ -118,13 +118,12 @@
>
> {
> status = "okay";
> - pinctrl-0 = <_rmii_pins_a>;
> - pinctrl-1 = <_rmii_sleep_pins_a>;
> + pinctrl-0 = <_rmii_pins_c _pins_a>;
> + pinctrl-1 = <_rmii_sleep_pins_c _sleep_pins_a>;
> pinctrl-names = "default", "sleep";
> phy-mode = "rmii";
> max-speed = <100>;
> phy-handle = <>;
> - st,eth-ref-clk-sel;
>
> mdio0 {
> #address-cells = <1>;
> @@ -136,7 +135,7 @@
> /* LAN8710Ai */
> compatible = "ethernet-phy-id0007.c0f0",
>"ethernet-phy-ieee802.3-c22";
> - clocks = < ETHCK_K>;
> + clocks = < CK_MCO2>;
> reset-gpios = < 3 GPIO_ACTIVE_LOW>;
> reset-assert-us = <500>;
> reset-deassert-us = <500>;
> @@ -446,6 +445,21 @@
> };
> };
>
> + {
> + /* Connect MCO2 output to ETH_RX_CLK input via pad-pad connection */
> + clocks = < CK_MCO2>;
> + clock-names = "ETH_RX_CLK/ETH_REF_CLK";
> +
> + /*
> + * Set PLL4P output to 100 MHz to supply SDMMC with faster clock,
> + * set MCO2 output to 50 MHz to supply ETHRX clock with PLL4P/2,
> + * so that MCO2 behaves as a divider for the ETHRX clock here.
> + */
> + assigned-clocks = < CK_MCO2>, < PLL4_P>;
> + assigned-clock-parents = < PLL4_P>;
> + assigned-clock-rates = <5000>, <1>;
> +};
> +
> {
> status = "okay";
> };
> diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> index bc0730cf2bd..ff5e9034951 100644
> --- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> @@ -126,6 +126,20 @@
> };
>
> {
> + /*
> + * Reinstate clock names from stm32mp151.dtsi, the MCO2 trick
> + * used in stm32mp15xx-dhcom-som.dtsi is not supported by the
> + * U-Boot clock framework.
> + */
> + clock-names = "hse", "hsi", "csi", "lse", "lsi";
> + clocks = <_hse>, <_hsi>, <_csi>,
> + <_lse>, <_lsi>;
> +
> + /* The MCO2 is already configured correctly, remove those. */
> + /delete-property/ assigned-clocks;
> + /delete-property/ assigned-clock-parents;
> + /delete-property/ assigned-clock-rates;
> +
> st,clksrc = <
> CLK_MPU_PLL1P
> CLK_AXI_PLL2P
Reviewed-by: Patrice Chotard
Thanks
Patrice
Re: [PATCH 2/2] ARM: dts: sm32mp13: remove shmem for scmi-optee
On 7/10/23 10:44, Patrick Delaunay wrote:
> CFG_STM32MP1_SCMI_SHM_SYSRAM will be disabled by default for STM32MP13x
> SoCs in next OP-TEE version and the OP-TEE SMCI server uses the OP-TEE
> native shared memory registered by clients.
>
> To be compatible by default with this configuration this patch removes
> the shared memory in the SCMI configuration and the associated reserved
> memory in SRAM.
>
> Signed-off-by: Patrick Delaunay
> ---
>
> arch/arm/dts/stm32mp13-u-boot.dtsi | 8
> arch/arm/dts/stm32mp131.dtsi | 14 --
> 2 files changed, 22 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp13-u-boot.dtsi
> b/arch/arm/dts/stm32mp13-u-boot.dtsi
> index 726cd1a7e479..aa5cfc6e41d5 100644
> --- a/arch/arm/dts/stm32mp13-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp13-u-boot.dtsi
> @@ -108,14 +108,6 @@
> bootph-all;
> };
>
> -_shm {
> - bootph-all;
> -};
> -
> -_sram {
> - bootph-all;
> -};
> -
> {
> bootph-all;
> };
> diff --git a/arch/arm/dts/stm32mp131.dtsi b/arch/arm/dts/stm32mp131.dtsi
> index d94ba2547267..f1810c9eb704 100644
> --- a/arch/arm/dts/stm32mp131.dtsi
> +++ b/arch/arm/dts/stm32mp131.dtsi
> @@ -40,7 +40,6 @@
> #address-cells = <1>;
> #size-cells = <0>;
> linaro,optee-channel-id = <0>;
> - shmem = <_shm>;
>
> scmi_clk: protocol@14 {
> reg = <0x14>;
> @@ -106,19 +105,6 @@
> interrupt-parent = <>;
> ranges;
>
> - scmi_sram: sram@2000 {
> - compatible = "mmio-sram";
> - reg = <0x2000 0x1000>;
> - #address-cells = <1>;
> - #size-cells = <1>;
> - ranges = <0 0x2000 0x1000>;
> -
> - scmi_shm: scmi-sram@0 {
> - compatible = "arm,scmi-shmem";
> - reg = <0 0x80>;
> - };
> - };
> -
> timers2: timer@4000 {
> #address-cells = <1>;
> #size-cells = <0>;
Reviewed-by: Patrice Chotard
Thanks
Patrice
Re: [PATCH 1/2] ARM: dts: sm32mp15: remove shmem for scmi-optee
On 7/10/23 10:44, Patrick Delaunay wrote:
> Since OP-TEE commit 89ba3422ee80 ("plat-stm32mp1: scmi_server: default
> use OP-TEE shared memory"), integrated in OP-TEE 3.22.0-rc1
> the default configuration for STM32MP15x SoCs changes,
> CFG_STM32MP1_SCMI_SHM_SYSRAM is disabled by default and the OP-TEE SMCI
> server uses ithe OP-TEE native shared memory registered by clients.
>
> To be compatible by default with this configuration and the next OP-TEE
> version, this patch removes the SHMEM in the SCMI configuration and the
> associated reserved memory in the last 4KByte page of SRAM,
> in the STM32MP15 device tree.
>
> Signed-off-by: Patrick Delaunay
> ---
>
> arch/arm/dts/stm32mp15-scmi.dtsi | 16
> 1 file changed, 16 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp15-scmi.dtsi
> b/arch/arm/dts/stm32mp15-scmi.dtsi
> index 543f24c2f4f6..ad2584213d99 100644
> --- a/arch/arm/dts/stm32mp15-scmi.dtsi
> +++ b/arch/arm/dts/stm32mp15-scmi.dtsi
> @@ -16,7 +16,6 @@
> #address-cells = <1>;
> #size-cells = <0>;
> linaro,optee-channel-id = <0>;
> - shmem = <_shm>;
>
> scmi_clk: protocol@14 {
> reg = <0x14>;
> @@ -60,21 +59,6 @@
> };
> };
> };
> -
> - soc {
> - scmi_sram: sram@2000 {
> - compatible = "mmio-sram";
> - reg = <0x2000 0x1000>;
> - #address-cells = <1>;
> - #size-cells = <1>;
> - ranges = <0 0x2000 0x1000>;
> -
> - scmi_shm: scmi-sram@0 {
> - compatible = "arm,scmi-shmem";
> - reg = <0 0x80>;
> - };
> - };
> - };
> };
>
> {
Reviewed-by: Patrice Chotard
Thanks
Patrice
Re: [PATCH] ARM: dts: stm32mp: alignment with v6.4
On 7/10/23 10:38, Patrick Delaunay wrote:
> Device tree alignment with Linux kernel v6.4.
>
> Signed-off-by: Patrick Delaunay
> ---
>
> arch/arm/dts/stm32mp13-pinctrl.dtsi | 129
> arch/arm/dts/stm32mp131.dtsi| 99 -
> arch/arm/dts/stm32mp135f-dk.dts | 42 -
> arch/arm/dts/stm32mp15-pinctrl.dtsi | 34
> arch/arm/dts/stm32mp151.dtsi| 4 +-
> arch/arm/dts/stm32mp157a-dk1.dts| 3 -
> arch/arm/dts/stm32mp157c-dk2.dts| 3 -
> arch/arm/dts/stm32mp157c-ed1.dts| 17 +---
> arch/arm/dts/stm32mp157c-ev1.dts| 9 +-
> arch/arm/dts/stm32mp15xx-dkx.dtsi | 15 ++--
> 10 files changed, 299 insertions(+), 56 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp13-pinctrl.dtsi
> b/arch/arm/dts/stm32mp13-pinctrl.dtsi
> index b2dce3a29f39..27e0c3826789 100644
> --- a/arch/arm/dts/stm32mp13-pinctrl.dtsi
> +++ b/arch/arm/dts/stm32mp13-pinctrl.dtsi
> @@ -258,4 +258,133 @@
> bias-disable;
> };
> };
> +
> + uart4_idle_pins_a: uart4-idle-0 {
> + pins1 {
> + pinmux = ; /* UART4_TX */
> + };
> + pins2 {
> + pinmux = ; /* UART4_RX */
> + bias-disable;
> + };
> + };
> +
> + uart4_sleep_pins_a: uart4-sleep-0 {
> + pins {
> + pinmux = , /* UART4_TX */
> + ; /* UART4_RX */
> + };
> + };
> +
> + uart8_pins_a: uart8-0 {
> + pins1 {
> + pinmux = ; /* UART8_TX */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <0>;
> + };
> + pins2 {
> + pinmux = ; /* UART8_RX */
> + bias-pull-up;
> + };
> + };
> +
> + uart8_idle_pins_a: uart8-idle-0 {
> + pins1 {
> + pinmux = ; /* UART8_TX */
> + };
> + pins2 {
> + pinmux = ; /* UART8_RX */
> + bias-pull-up;
> + };
> + };
> +
> + uart8_sleep_pins_a: uart8-sleep-0 {
> + pins {
> + pinmux = , /* UART8_TX */
> + ; /* UART8_RX */
> + };
> + };
> +
> + usart1_pins_a: usart1-0 {
> + pins1 {
> + pinmux = , /* USART1_TX */
> + ; /* USART1_RTS */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <0>;
> + };
> + pins2 {
> + pinmux = , /* USART1_RX */
> + ; /* USART1_CTS_NSS
> */
> + bias-pull-up;
> + };
> + };
> +
> + usart1_idle_pins_a: usart1-idle-0 {
> + pins1 {
> + pinmux = , /* USART1_TX */
> + ; /*
> USART1_CTS_NSS */
> + };
> + pins2 {
> + pinmux = ; /* USART1_RTS */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <0>;
> + };
> + pins3 {
> + pinmux = ; /* USART1_RX */
> + bias-pull-up;
> + };
> + };
> +
> + usart1_sleep_pins_a: usart1-sleep-0 {
> + pins {
> + pinmux = , /* USART1_TX */
> + , /* USART1_RTS
> */
> + , /*
> USART1_CTS_NSS */
> + ; /* USART1_RX */
> + };
> + };
> +
> + usart2_pins_a: usart2-0 {
> + pins1 {
> + pinmux = , /* USART2_TX */
> + ; /* USART2_RTS */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <0>;
> + };
> + pins2 {
> + pinmux = , /* USART2_RX */
> + ; /*
> USART2_CTS_NSS */
> + bias-disable;
> + };
> + };
> +
> + usart2_idle_pins_a: usart2-idle-0 {
> + pins1 {
> + pinmux = , /* USART2_TX
> */
> + ; /*
> USART2_CTS_NSS */
> + };
> + pins2 {
> + pinmux = ; /* USART2_RTS */
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <0>;
> + };
> + pins3 {
> + pinmux = ; /* USART2_RX */
> + bias-disable;
> + };
> + };
> +
> + usart2_sleep_pins_a: usart2-sleep-0 {
> + pins {
> + pinmux = , /* USART2_TX
> */
> +
Re: [PATCH v4 1/4] cmd: bind: Add unbind command with driver filter
Hi Marek, ma...@denx.de wrote on Fri, 4 Aug 2023 17:40:07 +0200: > On 8/4/23 17:12, Miquel Raynal wrote: > > Hi, > > > > ma...@denx.de wrote on Fri, 4 Aug 2023 17:05:01 +0200: > > > >> On 8/4/23 17:01, Tom Rini wrote: > >>> On Fri, Aug 04, 2023 at 04:42:13PM +0200, Marek Vasut wrote: > On 8/4/23 09:00, Miquel Raynal wrote: > > Hi Marek, > > > > ma...@denx.de wrote on Wed, 2 Aug 2023 14:46:54 +0200: > > >> Extend the driver core to perform lookup by both OF node and > > driver > >> bound to the node. Use this to look up specific device instances to > >> unbind from nodes in the unbind command. One example where this is > >> needed is USB peripheral controller, which may have multiple gadget > >> drivers bound to it. The unbind command has to select that specific > >> gadget driver instance to unbind from the controller, not unbind the > >> controller driver itself from the controller. > >> > >> USB ethernet gadget usage looks as follows with this change. Notice > >> the extra 'usb_ether' addition in the 'unbind' command at the end. > >> " > >> bind /soc/usb-otg@4900 usb_ether > >> setenv ethact usb_ether > >> setenv loadaddr 0xc200 > >> setenv ipaddr 10.0.0.2 > >> setenv serverip 10.0.0.1 > >> setenv netmask 255.255.255.0 > >> tftpboot 0xc200 10.0.0.1:test.file > >> unbind /soc/usb-otg@4900 usb_ether > > > > This extra parameter does not seem to work on the BBBW. I cannot select > > the "usb_ether" driver like you do. > > > > Good news though, I am now able to use fastboot, but it is not > > straightforward: > > > > Here is my sequence right after the boot (reducing the dm tree output > > to the usb nodes for clarity): > > > => dm tree > > misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 > > usb 0 [ + ] ti-musb-peripheral| | |-- > > usb@47401000 > > ethernet 1 [ + ] usb_ether | | | `-- > > usb_ether > > bootdev 3 [ ] eth_bootdev | | | `-- > > usb_ether.bootdev > > usb 0 [ ] ti-musb-host | | `-- > > usb@47401800 > > => fastboot usb 0 > > couldn't find an available UDC > > g_dnl_register: failed!, error: -19 > > That is expected and not a bug, since the beagle explicitly binds USB > ethernet to MUSB gadget in board file, which is legacy deprecated way. > >>> > >>> So, we should do away with, probably all of arch_misc_init() in > >>> arch/arm/mach-omap2/am33xx/board.c for the non-SPL case. > >> > >> Yes > >> > > exit not allowed from main input shell. > > => unbind /ocp/usb@4740/usb@47401000 usb_ether > > Does > => unbind ethernet 0 > > work ? > > If so, 1/4 in this series can be skipped altogether. > > You likely won't even need the rebinding of ti-musb-peripheral anymore. > > Did you test this yet ? Not yet, I'll send you the feedback once done. > > Cannot find a device with path /ocp/usb@4740/usb@47401000 > > => unbind /ocp/usb@4740/usb@47401000 > > => dm tree > > misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 > > usb 0 [ ] ti-musb-host | | `-- > > usb@47401800 > > => fastboot usb 0 > > => bind /ocp/usb@4740/usb@47401000 ti-musb-peripheral > > => dm tree > > misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 > > usb 0 [ ] ti-musb-host | | |-- > > usb@47401800 > > usb 0 [ ] ti-musb-peripheral| | `-- > > usb@47401000 > > => fastboot usb 0 > > musb-hdrc: peripheral reset irq lost! > > # works! (the irq-related line above as always been there) > > > > So now, how do we make this process easy/understandable? > > What would be your proposal ? > > > > At least I would appreciate: > > - to select CMD_BIND "by default" when relevant > > - to make the fastboot error more readable for the regular user > > Since with this 'unbind ethernet 0' this is orthogonal to this series, send > separate patches, thanks. This is not orthogonal, I am sorry. version X: - tftp works "out of the box" - fastboot works "out of the box" version X+1: - tftp works "out of the box" - fastboot returns an obscure error 1/ If we now *need* the bind/unbind commands, the series must take care of it. 2/ Without proper error message you just break fastboot for most regular users (basically everyone but few U-Boot devs). > > If you want to get rid of all the legacy code, I am not opposed, > > really, but that must not be the user who is responsible for > > understanding what changed in the "core". It
[PATCH] cmd: cyclic: Remove duplicate command name in help text
Function 'cmd_usage()' already prints one command in usage before printing out the help text given to the U_BOOT_CMD_WITH_SUBCMDS macro. Wrong previous output: Usage: cyclic cyclic demo - register cyclic demo function cyclic list - list cyclic functions Signed-off-by: Alexander Dahl --- cmd/cyclic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmd/cyclic.c b/cmd/cyclic.c index 97324d8240..946f1d7818 100644 --- a/cmd/cyclic.c +++ b/cmd/cyclic.c @@ -77,7 +77,7 @@ static int do_cyclic_list(struct cmd_tbl *cmdtp, int flag, int argc, } static char cyclic_help_text[] = - "cyclic demo - register cyclic demo function\n" + "demo - register cyclic demo function\n" "cyclic list - list cyclic functions\n"; U_BOOT_CMD_WITH_SUBCMDS(cyclic, "Cyclic", cyclic_help_text, base-commit: 989892f5805dc205033c4723bc8e024472564d16 -- 2.30.2
Re: [PATCH] clk: stm32mp1: remove error for disabled clock in stm32mp1_clk_get_parent
On 6/23/23 15:05, Patrick Delaunay wrote:
> To disabled a clock in clock tree initialization for a mux of STM32MP15,
> the selected clock source index is set with the latest possible index for
> the number of bit used. Today this valid configuration cause a error
> in U-Boot messages, for example with CLK_ETH_DISABLED, when this clock
> is not needed for the used ETH PHY without crystal:
>
>no parents defined for clk id 123
>
> This patch change the level of this message to avoid this trace for
> valid clock tree.
>
> Signed-off-by: Patrick Delaunay
> ---
>
> drivers/clk/stm32/clk-stm32mp1.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/stm32/clk-stm32mp1.c
> b/drivers/clk/stm32/clk-stm32mp1.c
> index 4f4524fcb2c6..615028769495 100644
> --- a/drivers/clk/stm32/clk-stm32mp1.c
> +++ b/drivers/clk/stm32/clk-stm32mp1.c
> @@ -881,7 +881,8 @@ static int stm32mp1_clk_get_parent(struct
> stm32mp1_clk_priv *priv,
> return sel[s].parent[p];
> }
>
> - log_err("no parents defined for clk id %d\n", (u32)id);
> + /* clock is DISABLED when the clock src is not in clk_parent[] range */
> + log_debug("no parents defined for clk id %d\n", (u32)id);
>
> return -EINVAL;
> }
Reviewed-by: Patrice Chotard
Thanks
Patrice
[PATCH v5 3/3] usb: gadget: ether: Handle gadget driver registration in probe and remove
Move the ethernet gadget driver registration and removal from ethernet
bind and unbind callbacks into driver DM probe and remove callbacks.
This way, when the driver is bound, which is triggered deliberately
using 'bind' command, the USB ethernet gadget driver is instantiated
and bound to the matching UDC. In reverse, when the driver is unbound,
which is again triggered deliberately using 'unbind' command, the USB
ethernet gadget driver instance is removed.
Effectively, this now behaves like running either 'ums' or 'dfu' or
any other commands utilizing USB gadget functionality.
This also drops use of usb_gadget_release() and moves the use of
usb_gadget_initialize() into usb_ether_init() used only by legacy
platforms that do not use 'bind' command properly yet. Those have
no place in drivers.
Signed-off-by: Marek Vasut
---
NOTE: This must be thoroughly tested.
---
Cc: Kevin Hilman
Cc: Lukasz Majewski
Cc: Miquel Raynal
Cc: Simon Glass
---
V2: Fix up return value handling in probe
V3: Reinstate usb_gadget_initialize() in usb_ether_init() to retain
this obscure workaround for legacy platforms that fail to use
bind command
V4: Call usb_gadget_release() in unbind callback to further help
legacy platforms
V5: No change
---
drivers/usb/gadget/ether.c | 97 --
1 file changed, 52 insertions(+), 45 deletions(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 2040b5b5081..5ff06d3814b 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -2281,49 +2281,8 @@ static int usb_eth_start(struct udevice *udev)
struct eth_dev *dev = >ethdev;
struct usb_gadget *gadget;
unsigned long ts;
- int ret;
unsigned long timeout = USB_CONNECT_TIMEOUT;
- ret = usb_gadget_initialize(0);
- if (ret)
- return ret;
-
- /* Configure default mac-addresses for the USB ethernet device */
-#ifdef CONFIG_USBNET_DEV_ADDR
- strlcpy(dev_addr, CONFIG_USBNET_DEV_ADDR, sizeof(dev_addr));
-#endif
-#ifdef CONFIG_USBNET_HOST_ADDR
- strlcpy(host_addr, CONFIG_USBNET_HOST_ADDR, sizeof(host_addr));
-#endif
- /* Check if the user overruled the MAC addresses */
- if (env_get("usbnet_devaddr"))
- strlcpy(dev_addr, env_get("usbnet_devaddr"),
- sizeof(dev_addr));
-
- if (env_get("usbnet_hostaddr"))
- strlcpy(host_addr, env_get("usbnet_hostaddr"),
- sizeof(host_addr));
-
- if (!is_eth_addr_valid(dev_addr)) {
- pr_err("Need valid 'usbnet_devaddr' to be set");
- goto fail;
- }
- if (!is_eth_addr_valid(host_addr)) {
- pr_err("Need valid 'usbnet_hostaddr' to be set");
- goto fail;
- }
-
- priv->eth_driver.speed = DEVSPEED;
- priv->eth_driver.bind = eth_bind;
- priv->eth_driver.unbind = eth_unbind;
- priv->eth_driver.setup = eth_setup;
- priv->eth_driver.reset = eth_disconnect;
- priv->eth_driver.disconnect = eth_disconnect;
- priv->eth_driver.suspend= eth_suspend;
- priv->eth_driver.resume = eth_resume;
- if (usb_gadget_register_driver(>eth_driver) < 0)
- goto fail;
-
dev->network_started = 0;
packet_received = 0;
@@ -2450,9 +2409,6 @@ static void usb_eth_stop(struct udevice *udev)
usb_gadget_handle_interrupts(0);
dev->network_started = 0;
}
-
- usb_gadget_unregister_driver(>eth_driver);
- usb_gadget_release(0);
}
static int usb_eth_recv(struct udevice *dev, int flags, uchar **packetp)
@@ -2511,7 +2467,7 @@ int usb_ether_init(void)
return ret;
}
- return 0;
+ return usb_gadget_initialize(0);
}
static int usb_eth_probe(struct udevice *dev)
@@ -2525,6 +2481,55 @@ static int usb_eth_probe(struct udevice *dev)
get_ether_addr(CONFIG_USBNET_DEV_ADDR, pdata->enetaddr);
eth_env_set_enetaddr("usbnet_devaddr", pdata->enetaddr);
+ /* Configure default mac-addresses for the USB ethernet device */
+#ifdef CONFIG_USBNET_DEV_ADDR
+ strlcpy(dev_addr, CONFIG_USBNET_DEV_ADDR, sizeof(dev_addr));
+#endif
+#ifdef CONFIG_USBNET_HOST_ADDR
+ strlcpy(host_addr, CONFIG_USBNET_HOST_ADDR, sizeof(host_addr));
+#endif
+ /* Check if the user overruled the MAC addresses */
+ if (env_get("usbnet_devaddr"))
+ strlcpy(dev_addr, env_get("usbnet_devaddr"),
+ sizeof(dev_addr));
+
+ if (env_get("usbnet_hostaddr"))
+ strlcpy(host_addr, env_get("usbnet_hostaddr"),
+ sizeof(host_addr));
+
+ if (!is_eth_addr_valid(dev_addr)) {
+ pr_err("Need valid 'usbnet_devaddr' to be set");
+ return -EINVAL;
+ }
+ if (!is_eth_addr_valid(host_addr)) {
+
[PATCH v5 2/3] usb: gadget: ether: Move probe function above driver structure
Move the driver probe function above the driver structure, so it
can be placed alongside other related functions, like upcoming
remove function. No functional change.
Signed-off-by: Marek Vasut
---
Cc: Kevin Hilman
Cc: Lukasz Majewski
Cc: Miquel Raynal
Cc: Simon Glass
---
V2: No change
V3: No change
V4: No change
V5: No change
---
drivers/usb/gadget/ether.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 88c656c4dc0..2040b5b5081 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -2486,20 +2486,6 @@ static int usb_eth_free_pkt(struct udevice *dev, uchar
*packet,
return rx_submit(ethdev, ethdev->rx_req, 0);
}
-static int usb_eth_probe(struct udevice *dev)
-{
- struct ether_priv *priv = dev_get_priv(dev);
- struct eth_pdata *pdata = dev_get_plat(dev);
-
- priv->netdev = dev;
- l_priv = priv;
-
- get_ether_addr(CONFIG_USBNET_DEV_ADDR, pdata->enetaddr);
- eth_env_set_enetaddr("usbnet_devaddr", pdata->enetaddr);
-
- return 0;
-}
-
static const struct eth_ops usb_eth_ops = {
.start = usb_eth_start,
.send = usb_eth_send,
@@ -2528,6 +2514,20 @@ int usb_ether_init(void)
return 0;
}
+static int usb_eth_probe(struct udevice *dev)
+{
+ struct ether_priv *priv = dev_get_priv(dev);
+ struct eth_pdata *pdata = dev_get_plat(dev);
+
+ priv->netdev = dev;
+ l_priv = priv;
+
+ get_ether_addr(CONFIG_USBNET_DEV_ADDR, pdata->enetaddr);
+ eth_env_set_enetaddr("usbnet_devaddr", pdata->enetaddr);
+
+ return 0;
+}
+
U_BOOT_DRIVER(eth_usb) = {
.name = "usb_ether",
.id = UCLASS_ETH,
--
2.40.1
[PATCH v5 1/3] usb: gadget: ether: Inline functions used once
These functions here are only ever called once since drop of non-DM
networking code. Inline them. No functional change.
Signed-off-by: Marek Vasut
---
Cc: Kevin Hilman
Cc: Lukasz Majewski
Cc: Miquel Raynal
Cc: Simon Glass
---
V2: No change
V3: No change
V4: No change
V5: No change
---
drivers/usb/gadget/ether.c | 48 +++---
1 file changed, 9 insertions(+), 39 deletions(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 85c971e4c43..88c656c4dc0 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -2273,10 +2273,11 @@ fail:
}
/*-*/
-static void _usb_eth_halt(struct ether_priv *priv);
+static void usb_eth_stop(struct udevice *dev);
-static int _usb_eth_init(struct ether_priv *priv)
+static int usb_eth_start(struct udevice *udev)
{
+ struct ether_priv *priv = dev_get_priv(udev);
struct eth_dev *dev = >ethdev;
struct usb_gadget *gadget;
unsigned long ts;
@@ -2347,12 +2348,13 @@ static int _usb_eth_init(struct ether_priv *priv)
rx_submit(dev, dev->rx_req, 0);
return 0;
fail:
- _usb_eth_halt(priv);
+ usb_eth_stop(udev);
return -1;
}
-static int _usb_eth_send(struct ether_priv *priv, void *packet, int length)
+static int usb_eth_send(struct udevice *udev, void *packet, int length)
{
+ struct ether_priv *priv = dev_get_priv(udev);
int retval;
void*rndis_pkt = NULL;
struct eth_dev *dev = >ethdev;
@@ -2419,15 +2421,9 @@ drop:
return -ENOMEM;
}
-static int _usb_eth_recv(struct ether_priv *priv)
-{
- usb_gadget_handle_interrupts(0);
-
- return 0;
-}
-
-static void _usb_eth_halt(struct ether_priv *priv)
+static void usb_eth_stop(struct udevice *udev)
{
+ struct ether_priv *priv = dev_get_priv(udev);
struct eth_dev *dev = >ethdev;
/* If the gadget not registered, simple return */
@@ -2459,31 +2455,12 @@ static void _usb_eth_halt(struct ether_priv *priv)
usb_gadget_release(0);
}
-static int usb_eth_start(struct udevice *dev)
-{
- struct ether_priv *priv = dev_get_priv(dev);
-
- return _usb_eth_init(priv);
-}
-
-static int usb_eth_send(struct udevice *dev, void *packet, int length)
-{
- struct ether_priv *priv = dev_get_priv(dev);
-
- return _usb_eth_send(priv, packet, length);
-}
-
static int usb_eth_recv(struct udevice *dev, int flags, uchar **packetp)
{
struct ether_priv *priv = dev_get_priv(dev);
struct eth_dev *ethdev = >ethdev;
- int ret;
- ret = _usb_eth_recv(priv);
- if (ret) {
- pr_err("error packet receive\n");
- return ret;
- }
+ usb_gadget_handle_interrupts(0);
if (packet_received) {
if (ethdev->rx_req) {
@@ -2509,13 +2486,6 @@ static int usb_eth_free_pkt(struct udevice *dev, uchar
*packet,
return rx_submit(ethdev, ethdev->rx_req, 0);
}
-static void usb_eth_stop(struct udevice *dev)
-{
- struct ether_priv *priv = dev_get_priv(dev);
-
- _usb_eth_halt(priv);
-}
-
static int usb_eth_probe(struct udevice *dev)
{
struct ether_priv *priv = dev_get_priv(dev);
--
2.40.1
Re: [PATCH v4 1/4] cmd: bind: Add unbind command with driver filter
On 8/4/23 17:12, Miquel Raynal wrote: Hi, ma...@denx.de wrote on Fri, 4 Aug 2023 17:05:01 +0200: On 8/4/23 17:01, Tom Rini wrote: On Fri, Aug 04, 2023 at 04:42:13PM +0200, Marek Vasut wrote: On 8/4/23 09:00, Miquel Raynal wrote: Hi Marek, ma...@denx.de wrote on Wed, 2 Aug 2023 14:46:54 +0200: Extend the driver core to perform lookup by both OF node and driver bound to the node. Use this to look up specific device instances to unbind from nodes in the unbind command. One example where this is needed is USB peripheral controller, which may have multiple gadget drivers bound to it. The unbind command has to select that specific gadget driver instance to unbind from the controller, not unbind the controller driver itself from the controller. USB ethernet gadget usage looks as follows with this change. Notice the extra 'usb_ether' addition in the 'unbind' command at the end. " bind /soc/usb-otg@4900 usb_ether setenv ethact usb_ether setenv loadaddr 0xc200 setenv ipaddr 10.0.0.2 setenv serverip 10.0.0.1 setenv netmask 255.255.255.0 tftpboot 0xc200 10.0.0.1:test.file unbind /soc/usb-otg@4900 usb_ether This extra parameter does not seem to work on the BBBW. I cannot select the "usb_ether" driver like you do. Good news though, I am now able to use fastboot, but it is not straightforward: Here is my sequence right after the boot (reducing the dm tree output to the usb nodes for clarity): => dm tree misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 usb 0 [ + ] ti-musb-peripheral| | |-- usb@47401000 ethernet 1 [ + ] usb_ether | | | `-- usb_ether bootdev 3 [ ] eth_bootdev | | | `-- usb_ether.bootdev usb 0 [ ] ti-musb-host | | `-- usb@47401800 => fastboot usb 0 couldn't find an available UDC g_dnl_register: failed!, error: -19 That is expected and not a bug, since the beagle explicitly binds USB ethernet to MUSB gadget in board file, which is legacy deprecated way. So, we should do away with, probably all of arch_misc_init() in arch/arm/mach-omap2/am33xx/board.c for the non-SPL case. Yes exit not allowed from main input shell. => unbind /ocp/usb@4740/usb@47401000 usb_ether Does => unbind ethernet 0 work ? If so, 1/4 in this series can be skipped altogether. You likely won't even need the rebinding of ti-musb-peripheral anymore. Did you test this yet ? Cannot find a device with path /ocp/usb@4740/usb@47401000 => unbind /ocp/usb@4740/usb@47401000 => dm tree misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 usb 0 [ ] ti-musb-host | | `-- usb@47401800 => fastboot usb 0 => bind /ocp/usb@4740/usb@47401000 ti-musb-peripheral => dm tree misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 usb 0 [ ] ti-musb-host | | |-- usb@47401800 usb 0 [ ] ti-musb-peripheral| | `-- usb@47401000 => fastboot usb 0 musb-hdrc: peripheral reset irq lost! # works! (the irq-related line above as always been there) So now, how do we make this process easy/understandable? What would be your proposal ? At least I would appreciate: - to select CMD_BIND "by default" when relevant - to make the fastboot error more readable for the regular user Since with this 'unbind ethernet 0' this is orthogonal to this series, send separate patches, thanks. If you want to get rid of all the legacy code, I am not opposed, really, but that must not be the user who is responsible for understanding what changed in the "core". It must be very easily accessible to understand that now: - manual binding/unbinding is needed - which driver must be used when When my spare time permits. Well, what's needed / is it possible to get to the point where we don't _need_ to call bind/unbind for each of these cases? Is there something we're supposed to be setting in the DT that we aren't? You do need to unbind the ethernet before using fastboot, always, with the 'unbind ethernet 0', you dont need the peripheral unbind/rebind part, so it should behave like before. And for my own understanding, why don't we need to bind a fastboot gadget? The fastboot command does that internally .
Re: [PATCH v4 1/4] cmd: bind: Add unbind command with driver filter
Hi, ma...@denx.de wrote on Fri, 4 Aug 2023 17:05:01 +0200: > On 8/4/23 17:01, Tom Rini wrote: > > On Fri, Aug 04, 2023 at 04:42:13PM +0200, Marek Vasut wrote: > >> On 8/4/23 09:00, Miquel Raynal wrote: > >>> Hi Marek, > >>> > >>> ma...@denx.de wrote on Wed, 2 Aug 2023 14:46:54 +0200: > >>> > Extend the driver core to perform lookup by both OF node and driver > bound to the node. Use this to look up specific device instances to > unbind from nodes in the unbind command. One example where this is > needed is USB peripheral controller, which may have multiple gadget > drivers bound to it. The unbind command has to select that specific > gadget driver instance to unbind from the controller, not unbind the > controller driver itself from the controller. > > USB ethernet gadget usage looks as follows with this change. Notice > the extra 'usb_ether' addition in the 'unbind' command at the end. > " > bind /soc/usb-otg@4900 usb_ether > setenv ethact usb_ether > setenv loadaddr 0xc200 > setenv ipaddr 10.0.0.2 > setenv serverip 10.0.0.1 > setenv netmask 255.255.255.0 > tftpboot 0xc200 10.0.0.1:test.file > unbind /soc/usb-otg@4900 usb_ether > >>> > >>> This extra parameter does not seem to work on the BBBW. I cannot select > >>> the "usb_ether" driver like you do. > >>> > >>> Good news though, I am now able to use fastboot, but it is not > >>> straightforward: > >>> > >>> Here is my sequence right after the boot (reducing the dm tree output > >>> to the usb nodes for clarity): > >>> > >>> => dm tree > >>>misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 > >>>usb 0 [ + ] ti-musb-peripheral| | |-- usb@47401000 > >>>ethernet 1 [ + ] usb_ether | | | `-- > >>> usb_ether > >>>bootdev 3 [ ] eth_bootdev | | | `-- > >>> usb_ether.bootdev > >>>usb 0 [ ] ti-musb-host | | `-- > >>> usb@47401800 > >>> => fastboot usb 0 > >>> couldn't find an available UDC > >>> g_dnl_register: failed!, error: -19 > >> > >> That is expected and not a bug, since the beagle explicitly binds USB > >> ethernet to MUSB gadget in board file, which is legacy deprecated way. > > > > So, we should do away with, probably all of arch_misc_init() in > > arch/arm/mach-omap2/am33xx/board.c for the non-SPL case. > > Yes > > >>> exit not allowed from main input shell. > >>> => unbind /ocp/usb@4740/usb@47401000 usb_ether > >> > >> Does > >> > >> => unbind ethernet 0 > >> > >> work ? > >> > >> If so, 1/4 in this series can be skipped altogether. > >> > >> You likely won't even need the rebinding of ti-musb-peripheral anymore. > >> > >>> Cannot find a device with path /ocp/usb@4740/usb@47401000 > >>> => unbind /ocp/usb@4740/usb@47401000 > >>> => dm tree > >>>misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 > >>>usb 0 [ ] ti-musb-host | | `-- > >>> usb@47401800 > >>> => fastboot usb 0 > >>> => bind /ocp/usb@4740/usb@47401000 ti-musb-peripheral > >>> => dm tree > >>>misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 > >>>usb 0 [ ] ti-musb-host | | |-- usb@47401800 > >>>usb 0 [ ] ti-musb-peripheral| | `-- > >>> usb@47401000 > >>> => fastboot usb 0 > >>> musb-hdrc: peripheral reset irq lost! > >>> # works! (the irq-related line above as always been there) > >>> > >>> So now, how do we make this process easy/understandable? > >> > >> What would be your proposal ? At least I would appreciate: - to select CMD_BIND "by default" when relevant - to make the fastboot error more readable for the regular user If you want to get rid of all the legacy code, I am not opposed, really, but that must not be the user who is responsible for understanding what changed in the "core". It must be very easily accessible to understand that now: - manual binding/unbinding is needed - which driver must be used when > > Well, what's needed / is it possible to get to the point where we don't > > _need_ to call bind/unbind for each of these cases? Is there something > > we're supposed to be setting in the DT that we aren't? > > You do need to unbind the ethernet before using fastboot, always, with the > 'unbind ethernet 0', you dont need the peripheral unbind/rebind part, so it > should behave like before. And for my own understanding, why don't we need to bind a fastboot gadget? Thanks, Miquèl
Re: [PATCH v4 1/4] cmd: bind: Add unbind command with driver filter
On 8/4/23 17:01, Tom Rini wrote: On Fri, Aug 04, 2023 at 04:42:13PM +0200, Marek Vasut wrote: On 8/4/23 09:00, Miquel Raynal wrote: Hi Marek, ma...@denx.de wrote on Wed, 2 Aug 2023 14:46:54 +0200: Extend the driver core to perform lookup by both OF node and driver bound to the node. Use this to look up specific device instances to unbind from nodes in the unbind command. One example where this is needed is USB peripheral controller, which may have multiple gadget drivers bound to it. The unbind command has to select that specific gadget driver instance to unbind from the controller, not unbind the controller driver itself from the controller. USB ethernet gadget usage looks as follows with this change. Notice the extra 'usb_ether' addition in the 'unbind' command at the end. " bind /soc/usb-otg@4900 usb_ether setenv ethact usb_ether setenv loadaddr 0xc200 setenv ipaddr 10.0.0.2 setenv serverip 10.0.0.1 setenv netmask 255.255.255.0 tftpboot 0xc200 10.0.0.1:test.file unbind /soc/usb-otg@4900 usb_ether This extra parameter does not seem to work on the BBBW. I cannot select the "usb_ether" driver like you do. Good news though, I am now able to use fastboot, but it is not straightforward: Here is my sequence right after the boot (reducing the dm tree output to the usb nodes for clarity): => dm tree misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 usb 0 [ + ] ti-musb-peripheral| | |-- usb@47401000 ethernet 1 [ + ] usb_ether | | | `-- usb_ether bootdev 3 [ ] eth_bootdev | | | `-- usb_ether.bootdev usb 0 [ ] ti-musb-host | | `-- usb@47401800 => fastboot usb 0 couldn't find an available UDC g_dnl_register: failed!, error: -19 That is expected and not a bug, since the beagle explicitly binds USB ethernet to MUSB gadget in board file, which is legacy deprecated way. So, we should do away with, probably all of arch_misc_init() in arch/arm/mach-omap2/am33xx/board.c for the non-SPL case. Yes exit not allowed from main input shell. => unbind /ocp/usb@4740/usb@47401000 usb_ether Does => unbind ethernet 0 work ? If so, 1/4 in this series can be skipped altogether. You likely won't even need the rebinding of ti-musb-peripheral anymore. Cannot find a device with path /ocp/usb@4740/usb@47401000 => unbind /ocp/usb@4740/usb@47401000 => dm tree misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 usb 0 [ ] ti-musb-host | | `-- usb@47401800 => fastboot usb 0 => bind /ocp/usb@4740/usb@47401000 ti-musb-peripheral => dm tree misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 usb 0 [ ] ti-musb-host | | |-- usb@47401800 usb 0 [ ] ti-musb-peripheral| | `-- usb@47401000 => fastboot usb 0 musb-hdrc: peripheral reset irq lost! # works! (the irq-related line above as always been there) So now, how do we make this process easy/understandable? What would be your proposal ? Well, what's needed / is it possible to get to the point where we don't _need_ to call bind/unbind for each of these cases? Is there something we're supposed to be setting in the DT that we aren't? You do need to unbind the ethernet before using fastboot, always, with the 'unbind ethernet 0', you dont need the peripheral unbind/rebind part, so it should behave like before.
Re: [PATCH v4 1/4] cmd: bind: Add unbind command with driver filter
On Fri, Aug 04, 2023 at 04:42:13PM +0200, Marek Vasut wrote: > On 8/4/23 09:00, Miquel Raynal wrote: > > Hi Marek, > > > > ma...@denx.de wrote on Wed, 2 Aug 2023 14:46:54 +0200: > > > > > Extend the driver core to perform lookup by both OF node and driver > > > bound to the node. Use this to look up specific device instances to > > > unbind from nodes in the unbind command. One example where this is > > > needed is USB peripheral controller, which may have multiple gadget > > > drivers bound to it. The unbind command has to select that specific > > > gadget driver instance to unbind from the controller, not unbind the > > > controller driver itself from the controller. > > > > > > USB ethernet gadget usage looks as follows with this change. Notice > > > the extra 'usb_ether' addition in the 'unbind' command at the end. > > > " > > > bind /soc/usb-otg@4900 usb_ether > > > setenv ethact usb_ether > > > setenv loadaddr 0xc200 > > > setenv ipaddr 10.0.0.2 > > > setenv serverip 10.0.0.1 > > > setenv netmask 255.255.255.0 > > > tftpboot 0xc200 10.0.0.1:test.file > > > unbind /soc/usb-otg@4900 usb_ether > > > > This extra parameter does not seem to work on the BBBW. I cannot select > > the "usb_ether" driver like you do. > > > > Good news though, I am now able to use fastboot, but it is not > > straightforward: > > > > Here is my sequence right after the boot (reducing the dm tree output > > to the usb nodes for clarity): > > > > => dm tree > > misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 > > usb 0 [ + ] ti-musb-peripheral| | |-- usb@47401000 > > ethernet 1 [ + ] usb_ether | | | `-- usb_ether > > bootdev 3 [ ] eth_bootdev | | | `-- > > usb_ether.bootdev > > usb 0 [ ] ti-musb-host | | `-- usb@47401800 > > => fastboot usb 0 > > couldn't find an available UDC > > g_dnl_register: failed!, error: -19 > > That is expected and not a bug, since the beagle explicitly binds USB > ethernet to MUSB gadget in board file, which is legacy deprecated way. So, we should do away with, probably all of arch_misc_init() in arch/arm/mach-omap2/am33xx/board.c for the non-SPL case. > > exit not allowed from main input shell. > > => unbind /ocp/usb@4740/usb@47401000 usb_ether > > Does > > => unbind ethernet 0 > > work ? > > If so, 1/4 in this series can be skipped altogether. > > You likely won't even need the rebinding of ti-musb-peripheral anymore. > > > Cannot find a device with path /ocp/usb@4740/usb@47401000 > > => unbind /ocp/usb@4740/usb@47401000 > > => dm tree > > misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 > > usb 0 [ ] ti-musb-host | | `-- usb@47401800 > > => fastboot usb 0 > > => bind /ocp/usb@4740/usb@47401000 ti-musb-peripheral > > => dm tree > > misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 > > usb 0 [ ] ti-musb-host | | |-- usb@47401800 > > usb 0 [ ] ti-musb-peripheral| | `-- usb@47401000 > > => fastboot usb 0 > > musb-hdrc: peripheral reset irq lost! > > # works! (the irq-related line above as always been there) > > > > So now, how do we make this process easy/understandable? > > What would be your proposal ? Well, what's needed / is it possible to get to the point where we don't _need_ to call bind/unbind for each of these cases? Is there something we're supposed to be setting in the DT that we aren't? -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 1/4] cmd: bind: Add unbind command with driver filter
On 8/4/23 09:00, Miquel Raynal wrote: Hi Marek, ma...@denx.de wrote on Wed, 2 Aug 2023 14:46:54 +0200: Extend the driver core to perform lookup by both OF node and driver bound to the node. Use this to look up specific device instances to unbind from nodes in the unbind command. One example where this is needed is USB peripheral controller, which may have multiple gadget drivers bound to it. The unbind command has to select that specific gadget driver instance to unbind from the controller, not unbind the controller driver itself from the controller. USB ethernet gadget usage looks as follows with this change. Notice the extra 'usb_ether' addition in the 'unbind' command at the end. " bind /soc/usb-otg@4900 usb_ether setenv ethact usb_ether setenv loadaddr 0xc200 setenv ipaddr 10.0.0.2 setenv serverip 10.0.0.1 setenv netmask 255.255.255.0 tftpboot 0xc200 10.0.0.1:test.file unbind /soc/usb-otg@4900 usb_ether This extra parameter does not seem to work on the BBBW. I cannot select the "usb_ether" driver like you do. Good news though, I am now able to use fastboot, but it is not straightforward: Here is my sequence right after the boot (reducing the dm tree output to the usb nodes for clarity): => dm tree misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 usb 0 [ + ] ti-musb-peripheral| | |-- usb@47401000 ethernet 1 [ + ] usb_ether | | | `-- usb_ether bootdev 3 [ ] eth_bootdev | | | `-- usb_ether.bootdev usb 0 [ ] ti-musb-host | | `-- usb@47401800 => fastboot usb 0 couldn't find an available UDC g_dnl_register: failed!, error: -19 That is expected and not a bug, since the beagle explicitly binds USB ethernet to MUSB gadget in board file, which is legacy deprecated way. exit not allowed from main input shell. => unbind /ocp/usb@4740/usb@47401000 usb_ether Does => unbind ethernet 0 work ? If so, 1/4 in this series can be skipped altogether. You likely won't even need the rebinding of ti-musb-peripheral anymore. Cannot find a device with path /ocp/usb@4740/usb@47401000 => unbind /ocp/usb@4740/usb@47401000 => dm tree misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 usb 0 [ ] ti-musb-host | | `-- usb@47401800 => fastboot usb 0 => bind /ocp/usb@4740/usb@47401000 ti-musb-peripheral => dm tree misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 usb 0 [ ] ti-musb-host | | |-- usb@47401800 usb 0 [ ] ti-musb-peripheral| | `-- usb@47401000 => fastboot usb 0 musb-hdrc: peripheral reset irq lost! # works! (the irq-related line above as always been there) So now, how do we make this process easy/understandable? What would be your proposal ?
Re: [PATCH v6 6/9] binman: capsule: Add support for generating EFI capsules
Hi Sughosh,
On Fri, 4 Aug 2023 at 00:44, Sughosh Ganu wrote:
>
> hi Simon,
>
> On Fri, 4 Aug 2023 at 08:32, Simon Glass wrote:
> >
> > Hi Sughosh,
> >
> > On Thu, 3 Aug 2023 at 05:08, Sughosh Ganu wrote:
> > >
> > > hi Simon,
> > >
> > > On Wed, 2 Aug 2023 at 18:23, Simon Glass wrote:
> > > >
> > > > Hi Sughosh,
> > > >
> > > > On Tue, 1 Aug 2023 at 11:41, Sughosh Ganu
> > > > wrote:
> > > > >
> > > > > Add support in binman for generating EFI capsules. The capsule
> > > > > parameters can be specified through the capsule binman entry. Also add
> > > > > test cases in binman for testing capsule generation.
> > > > >
> > > > > Signed-off-by: Sughosh Ganu
> > > > > ---
> > > > > Changes since V5:
> > > > > * Add support for the oemflag parameter used in FWU A/B updates. This
> > > > > was missed in the earlier version.
> > > > > * Use a single function, generate_capsule in the mkeficapsule bintool,
> > > > > instead of the multiple functions in earlier version.
> > > > > * Remove the logic for generating capsules from config file as
> > > > > suggested by Simon.
> > > > > * Use required_props for image index and GUID parameters.
> > > > > * Use a subnode for the capsule payload instead of using a filename
> > > > > for the payload, as suggested by Simon.
> > > > > * Add a capsule generation test with oemflag parameter being passed.
> > > > >
> > > > >
> > > > > configs/sandbox_spl_defconfig | 1 +
> > > >
[..]
> > [..]
> >
> > > > > +def ReadEntries(self):
> > > > > +"""Read the subnode to get the payload for this capsule"""
> > > > > +# We can have a single payload per capsule
> > > > > +if len(self._node.subnodes) != 1:
> > > > > +self.Raise('The capsule entry expects a single subnode
> > > > > for payload')
> > > >
> > > > No, we mustn't restruit this. Why would we?
> > >
> > > The mkeficapsule tool that generates the capsule expects a single
> > > image as it's input payload. Why do you see the need to support
> > > multiple entries as payload?
> >
> > That's how binman works...it isn't the entry type's job to decide how
> > the image is laid out. The user could add a section in any cases and
> > get around any restriction you put here. But the restriction isn't
> > necessary and is just strange.
>
> The idea here is that if a user puts two entries, there is no clarity
> on how that is to be handled, since the mkeficapsule tool expects a
> single input image(binary in binman jargon). I am aware of the user
There is a single input, since binman collects everything together.
> using section type to club multiple images, and I think that is
> absolutely fine, since we are then left with one final binary to
> present to the mkeficapsule tool. In fact, I think if the user wants a
> combination of multiple binaries, they can use a section entry. In
> fact a user can even use the recently added templates in binman to add
> stuff to the input binary, but the final binary to be passed to the
> mkeficapsule tool should be one.
Is there some strange magic in the tool? What does it matter where the
data come from?
I really don't understand what breaks if the user adds two entries
here. We should not have this limitation.
[..]
> >
> > [..]
> >
> > > > > +payload_data = EFI_CAPSULE_DATA
> > > > > +
> > > > > +# Firmware Management Protocol(FMP) GUID - offset(0 - 32)
> > > > > +self.assertEqual(FW_MGMT_GUID, data.hex()[:32])
> > > > > +# Image GUID - offset(96 - 128)
> > > > > +self.assertEqual(CAPSULE_IMAGE_GUID, data.hex()[96:128])
> > > > > +
> > > > > +if capoemflags:
> > > > > +# OEM Flags - offset(40 - 44)
> > > > > +self.assertEqual(oemflag, data.hex()[40:44])
> > > > > +if signed_capsule and version_check:
> > > > > +# FMP header signature - offset(4770 - 4778)
> > > > > +self.assertEqual(fmp_signature, data.hex()[4770:4778])
> > > > > +# FMP header size - offset(4778 - 4780)
> > > >
> > > > Can you mention where these values came from and how you created them?
> > > > This all seems very brittle. Is there a tool that prints them out,
> > > > or..?
> > >
> > > Like I mentioned earlier as well, the contents of a capsule are
> > > dependent on the input parameters specified in it's generation. For
> > > e.g. the capsule generated would be different when opting for passing
> > > the version param. Similarly when generating a signed capsule -- even
> > > with a signed capsule, the contents would depend on the keys. The
> > > offsets therefore are not fixed but depend on the inputs specified. I
> > > have added comments here for better understanding. Not sure what can
> > > be done to improve this.
> > >
> > > This is also one reason why the testing of the EFI capsule update
> > > feature should use capsules generated as part of the sandbox platform
> > > build. That makes the testing that much more robust.
> >
> > We
Re: [PATCH v6 9/9] sandbox: capsule: Generate capsule related files through binman
Hi Sughosh, On Fri, 4 Aug 2023 at 01:03, Sughosh Ganu wrote: > > hi Simon, > > On Fri, 4 Aug 2023 at 08:32, Simon Glass wrote: > > > > Hi Sughosh, > > > > On Thu, 3 Aug 2023 at 05:18, Sughosh Ganu wrote: > > > > > > hi Simon, > > > > > > On Wed, 2 Aug 2023 at 18:23, Simon Glass wrote: > > > > > > > > Hi Sughosh, > > > > > > > > On Tue, 1 Aug 2023 at 11:41, Sughosh Ganu > > > > wrote: > > > > > > > > > > The EFI capsule files can now be generated as part of u-boot > > > > > build. This is done through binman. Add capsule entry nodes in the > > > > > u-boot.dtsi for the sandbox architecture for generating the > > > > > capsules. Remove the corresponding generation of capsules from the > > > > > capsule update conftest file. > > > > > > > > > > The capsules are generated through the config file for the sandbox > > > > > variant, and through explicit parameters for the sandbox_flattree > > > > > variant. > > > > > > > > > > Also generate the FIT image used for testing the capsule update > > > > > feature on the sandbox_flattree variant through binman. Remove the now > > > > > superfluous its file which was used for generating this FIT image. > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > --- > > > > > Changes since V5: > > > > > * Use the public key ESL file and other input files from the tree > > > > > instead of the /tmp/capsules/ directory being used in previous > > > > > version. > > > > > * Use macros for other input files and certs. > > > > > > > > > > arch/sandbox/dts/u-boot.dtsi | 347 > > > > > ++ > > > > > test/py/tests/test_efi_capsule/conftest.py| 128 +-- > > > > > .../tests/test_efi_capsule/uboot_bin_env.its | 36 -- > > > > > 3 files changed, 348 insertions(+), 163 deletions(-) > > > > > delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its > > > > > > > > > > > > > I want to get the binman stuff right before diving into this, but the > > > > binman stuff seems fairly close, so I'll just mention...do you really > > > > need all these combinations of tests? It seems to me that one test is > > > > enough. You know that the binman tests will protect the code there, so > > > > why test it all over again here? > > > > > > These are capsules that are needed for testing the EFI capsule update > > > functionality. Currently, the capsules used for testing the feature > > > are generated after u-boot has been built. Same for embedding the > > > public key in the dtb. I think it is better to have the same flow of > > > generating capsules and the associated logic(public key embedding) > > > that is being supported in u-boot rather than having two divergent > > > flows. This also serves as an example for potential users who would > > > want to generate capsules as part of the build flow. > > > > But my question was why you need more than one test here? Are you > > testing that U-Boot can decode a capsule file of various types? That > > should be done in unit tests. > > The tests are the same. They are not being changed. What is changed is > the stage at which the capsules are being generated. Currently, the > capsules get generated only when the tests are invoked, as part of the > test setup. Same for embedding of the public key cert EFI Signature > List(ESL) file. This patch results in the capsules getting generated > as part of the u-boot build. Same for embedding of the public key ESL. > If we don't follow this flow, we would have support for generating > capsules as part of the u-boot build, but that flow would not be used > at all. I understand that binman tests the generation of capsules, but > we would then have this divergence between the flow that is supported, > and what is actually used in the tests. OK let's discuss the tests later. > > One alternative, which I think is a middle ground for this would be to > add a Kconfig symbol and use that for generating capsules. We can then > use that symbol in CI. This is similar to how the trace testing > happens in CI on the sandbox platform. In that scenario, we would not > have the capsules getting generated during normal builds. Here's what I suggest: - rely on binman tests for capsule generation - once you have a dump_capsule tool you can use that to check that things look OK - rely on unit tests for testing decoding capsules in U-Boot - have a few functional tests as a sanity check for overall behaviour > > > > > Now I see the tests you are referring to in > > test_capsule_firmware_signed_raw.py (please shorten the name!) > > > > These tests all have the reboot problem we need to fix, but anyway, at > > least I understand it. > > > > It looks like you are writing the test files into the source tree? > > They should be written to the output tree. > > If we are to generate the capsules, and embed the key as part of the > u-boot build, these input files are needed. Btw, I do see a few places > which have input files in the source, including inside binman. What
[PATCH] serial: stm32: extend TC timeout
From: Valentin Caron
Waiting 150us TC bit couldn't be enough.
If TFA lets 16 bits in USART fifo, we has to wait 16 times 87 us (time
of 10 bits (1 byte in most use cases) at a baud rate of 115200).
Fixes: b4dbc5d65a67 ("serial: stm32: Wait TC bit before performing
initialization")
Signed-off-by: Valentin Caron
Signed-off-by: Patrice Chotard
---
drivers/serial/serial_stm32.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/serial/serial_stm32.c b/drivers/serial/serial_stm32.c
index 0085113f674..23d476fba28 100644
--- a/drivers/serial/serial_stm32.c
+++ b/drivers/serial/serial_stm32.c
@@ -22,6 +22,14 @@
#include "serial_stm32.h"
#include
+/*
+ * At 115200 bits/s
+ * 1 bit = 1 / 115200 = 8,68 us
+ * 8 bits = 69,444 us
+ * 10 bits are needed for worst case (8 bits + 1 start + 1 stop) = 86.806 us
+ */
+#define ONE_BYTE_B115200_US87
+
static void _stm32_serial_setbrg(fdt_addr_t base,
struct stm32_uart_info *uart_info,
u32 clock_rate,
@@ -209,12 +217,10 @@ static int stm32_serial_probe(struct udevice *dev)
* before uart initialization, wait for TC bit (Transmission Complete)
* in case there is still chars from previous bootstage to transmit
*/
- ret = read_poll_timeout(readl, isr, isr & USART_ISR_TC, 10, 150,
- plat->base + ISR_OFFSET(stm32f4));
- if (ret) {
- clk_disable();
- return ret;
- }
+ ret = read_poll_timeout(readl, isr, isr & USART_ISR_TC, 50,
+ 16 * ONE_BYTE_B115200_US, plat->base +
ISR_OFFSET(stm32f4));
+ if (ret)
+ dev_dbg(dev, "FIFO not empty, some character can be lost
(%d)\n", ret);
ret = reset_get_by_index(dev, 0, );
if (!ret) {
--
2.25.1
Re: [PATCH 1/1] video: avoid build failure on veyron board
Hello Simon,
El vie, 4 ago 2023 a la(s) 00:02, Simon Glass (s...@google.com) escribió:
> Hi,
>
> On Thu, 3 Aug 2023 at 18:37, Alvaro Fernando García
> wrote:
> >
> > 533ad9dc avoided an overflow but causes compilation
> > failure on 32bit boards (eg. veyron speedy)
> >
> > this commit uses div_u64 which has a fallback codepath
> > for 32bit platforms
> >
> > Signed-off-by: Alvaro Fernando García
> > ---
> >
> > drivers/video/pwm_backlight.c | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
>
> Tested-by: Simon Glass # chromebook_jerry
>
> Can you please advise which toolchain you are using and what the
> warning actually says? I don't see this on my board.
>
> >
> > diff --git a/drivers/video/pwm_backlight.c
> b/drivers/video/pwm_backlight.c
> > index 46c16a8f44..aa0e292866 100644
> > --- a/drivers/video/pwm_backlight.c
> > +++ b/drivers/video/pwm_backlight.c
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > /**
> > @@ -59,12 +60,14 @@ struct pwm_backlight_priv {
> >
> > static int set_pwm(struct pwm_backlight_priv *priv)
> > {
> > + u64 width;
> > uint duty_cycle;
> > int ret;
> >
> > if (priv->period_ns) {
> > - duty_cycle = (u64)priv->period_ns * (priv->cur_level -
> priv->min_level) /
> > - (priv->max_level - priv->min_level);
> > + width = priv->period_ns * (priv->cur_level -
> priv->min_level);
> > + duty_cycle = div_u64(width,
> > +(priv->max_level -
> priv->min_level));
> > ret = pwm_set_config(priv->pwm, priv->channel,
> priv->period_ns,
> > duty_cycle);
> > } else {
> > --
> > 2.41.0
> >
>
> Regards,
> Simon
>
I built U-Boot on a Debian Bookworm container following these steps:
make distclean
> make chromebook_speedy_defconfig
> make -j8
Container is using these gcc and linker versions:
# gcc --version
> gcc (Debian 12.2.0-14) 12.2.0
# ld --version
> GNU ld (GNU Binutils for Debian) 2.40
The error I was getting before the patch is this one:
ld.bfd: error: /usr/lib/gcc/arm-linux-gnueabihf/12/libgcc.a(_udivmoddi4.o)
> uses VFP register arguments, u-boot does not
> ld.bfd: warning:
> /usr/lib/gcc/arm-linux-gnueabihf/12/libgcc.a(_udivmoddi4.o) uses 4-byte
> wchar_t yet the output is to use 2-byte wchar_t; use of wchar_t values
> across objects may fail
> ld.bfd: failed to merge target specific data of file
> /usr/lib/gcc/arm-linux-gnueabihf/12/libgcc.a(_udivmoddi4.o)
> make: *** [Makefile:1764: u-boot] Error 1
Please do tell me if there is any other information I can provide.
--
Alvaro F. García
Functional-oriented Software Architect
Re: [PATCH] arm: dts: medaitek: convert gmac link mode to 2500base-x for mt7986a-bpi-r3-sd
On Fri, Aug 04, 2023 at 09:01:55AM +0800, Weijie Gao wrote:
> The mt7531 of bpi-r3 is connected to mt7986 with 2.5Gbps HSGMII, not the
> regular 1Gbps SGMII.
>
> Signed-off-by: Weijie Gao
Reviewed-by: Daniel Golle
> ---
> This is a supplement to commit:
> aef54ea1 (arm: dts: medaitek: convert gmac link mode to 2500base-x)
> ---
> arch/arm/dts/mt7986a-bpi-r3-sd.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/mt7986a-bpi-r3-sd.dts
> b/arch/arm/dts/mt7986a-bpi-r3-sd.dts
> index 15256302b8..c156a81363 100644
> --- a/arch/arm/dts/mt7986a-bpi-r3-sd.dts
> +++ b/arch/arm/dts/mt7986a-bpi-r3-sd.dts
> @@ -76,12 +76,12 @@
> {
> status = "okay";
> mediatek,gmac-id = <0>;
> - phy-mode = "sgmii";
> + phy-mode = "2500base-x";
> mediatek,switch = "mt7531";
> reset-gpios = < 5 GPIO_ACTIVE_HIGH>;
>
> fixed-link {
> - speed = <1000>;
> + speed = <2500>;
> full-duplex;
> };
> };
> --
> 2.17.1
>
Re: [PATCH v5 2/2] board: mediatek: add mt8195 demo board
On Fri, Aug 04, 2023 at 07:04:48PM +0800, Macpaul Lin wrote: > From: Fabien Parent > > Add mt8195-demo board support. > This demo purpose board uses MediaTek's MT8195 SoC. > > Signed-off-by: Fabien Parent > Signed-off-by: Amjad Ouled-Ameur > Signed-off-by: Macpaul Lin [snip] > diff --git a/board/mediatek/mt8195/MAINTAINERS > b/board/mediatek/mt8195/MAINTAINERS > new file mode 100644 > index 00..01fa25115d > --- /dev/null > +++ b/board/mediatek/mt8195/MAINTAINERS > @@ -0,0 +1,6 @@ > +MT8195 Demo > +M: Macpaul Lin > +S: Maintained > +F: board/mediatek/mt8195 > +F: include/configs/mt8195.h > +F: configs/mt8195_demo_defconfig Please list the dts files here too, and these are being synced with Linux, yes? [snip] > diff --git a/include/configs/mt8195.h b/include/configs/mt8195.h > new file mode 100644 > index 00..7af06da6ea > --- /dev/null > +++ b/include/configs/mt8195.h > @@ -0,0 +1,46 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > +/* > + * Configuration for MT8195 based boards > + * > + * Copyright (C) 2023 MediaTek Inc. > + * Copyright (C) 2023 BayLibre, SAS > + * Author: Macpaul Lin > + * Author: Fabien Parent > + */ > + > +#ifndef __MT8195_H > +#define __MT8195_H > + > +#include Drop this, especially as there was just some time spent fixing "need in a generic header" mediatek code. > +/* Environment settings */ > +#include > + > +#if IS_ENABLED(CONFIG_CMD_MMC) > +#define BOOT_TARGET_MMC(func) func(MMC, mmc, 0) > +#else > +#define BOOT_TARGET_MMC(func) > +#endif > + > +#if IS_ENABLED(CONFIG_CMD_USB) > +#define BOOT_TARGET_USB(func) func(USB, usb, 0) > +#else > +#define BOOT_TARGET_USB(func) > +#endif > + > +#define BOOT_TARGET_DEVICES(func) \ > + BOOT_TARGET_MMC(func) \ > + BOOT_TARGET_USB(func) > + > +#if !defined(CFG_EXTRA_ENV_SETTINGS) > +#define CFG_EXTRA_ENV_SETTINGS \ > + "scriptaddr=0x4000\0" \ > + "fdt_addr_r=0x4400\0" \ > + "fdtoverlay_addr_r=0x44c0\0" \ > + "kernel_addr_r=0x4500\0" \ > + "ramdisk_addr_r=0x4600\0" \ > + "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \ > + BOOTENV > +#endif Please look at moving to plain text environment, thanks. -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH] env: Export environment config to OS devicetree
Hi Simon,
On 04.08.23 05:42, Simon Glass wrote:
Hi,
On Thu, 3 Aug 2023 at 07:21, Stefano Babic wrote:
Hi Frieder,
On 03.08.23 14:51, Frieder Schrempf wrote:
Hi Stefano,
On 03.08.23 10:14, Stefano Babic wrote:
Hi Frieder,
On 01.08.23 16:46, Frieder Schrempf wrote:
From: Frieder Schrempf
There are plenty of cases where the OS wants to know where the
persistent environment is stored in order to print or manipulate it.
In most cases a userspace tool like libubootenv [1] is used to handle
the environment. It uses hardcoded settings in a config file in the
rootfs to determine the exact location of the environment.
...or the configuration file is generated, or it is located on a rw
(overlayfs) partition.
In order to make systems more flexible and let userspace tools
detect the location of the environment currently in use, let's
add an option to export the runtime configuration to the FDT passed
to the OS.
This is especially useful when your device is able to use multiple
locations for the environment and the rootfs containing the
fw_env.config file should be kept universal.
Ok
One possible issue is there is a hard dependency between the properties
set in DT and the user space tool. The tool in user space is bound to
the list of properties, and changes / extensions for the user tool
requires changes in DT semantics (which properties, their path, etc).
The same hard dependency is set by fw_env.config with its strong
hardcoded and position dependent syntax. This one of the reason I
introduced YAML support in libubootenv, so that the user tool is
independent and can add own properties.
I am just asking if this use case requires a new interface, or it is
already available in some way. I mean, the configuration is YAML instead
of fw_env.config and contains multiple setup ("namespaces"), like:
mmc:
size : 0x10
lockfile : /var/lock/fw_printenv.lock
devices:
- path : /dev/mmcblk0boot0
offset : 0x1E
sectorsize : 0x10
- path : /dev/mmcblk0boot0
offset : 0x1E
sectorsize : 0x10
spi:
size : 0x10
lockfile : /var/lock/fw_printenv.lock
devices:
- path : /dev/mtd0
offset : 0x1E
sectorsize : 0x10
- path : /dev/mtd0
offset : 0x1F
sectorsize : 0x10
This configuration file can safely stored in your common rootfs and
covers all possible storage for environment. It does not cover "runtime"
changes, but well, I do not think this is a use case.
An advantage here is that new options, useful for the User Space tool,
can be simply introduced for the tool without the need to synchronize
with DT spec and U-Boot.
A mapping between location index and device path is not required. What
is still required is a selector, and this can be implemented in DT or as
kernel parameter.
Does this already cover your use case or do we need the introduction of
this new interface ?
Thanks for the feedback! I've seen the YAML configuration feature in
libubootenv but I missed the fact, that it already supports something
like the namespace parameter for selecting different configurations.
Indeed this would solve one part of the issue. And yes, I think we could
use the DT or a kernel parameter to pass a selector from U-Boot to
userspace.
Exactly.
Do you think we could add something to libubootenv to automatically
select the default namespace based on some DT property or kernel parameter?
Yes, we just need to add a way to set up a default "namespace". There is
currently a default "uboot" namespace, and we just need a way to pass
the information to the library. Maybe with an env ?
If yes, I think this would be a viable solution for me.
Fine !
Currently the general information like location/type, size, offset
and redundancy are exported. Userspace tools might already be able
to guess the correct device to access based on this information.
For further device-specific information two additional properties
'id1' and 'id2' are used. The current implementation uses them for
MMC and SPI FLASH like this:
| Type | id1| id2|
| -- | -- | -- |
| MMC| MMC device index in U-Boot | MMC hwpart index in U-Boot |
| SPI FLASH | SPI bus index in U-Boot| SPI CS index in U-Boot |
Further extensions for other environment devices are possible.
We add the necessary information to the '/chosen' node. The following
shows two examples:
Redundant environment in MMC:
/chosen {
u-boot,env-config {
location = <5>; # according to 'enum env_location'
offset = <0x1E>;
size = <0x10>;
sect_size = <0x10>;
id1 = <1>; # MMC device index
id2 = <0>; # MMC HW partition index
};
u-boot,env-redund-config {
offset = <0x1F>;
[PATCH v19 9/9] arm_ffa: efi: corstone1000: enable MM communication
turn on EFI MM communication On Corstone-1000 platform MM communication between u-boot and the secure world (Optee) is done using the FF-A bus. Changes made are generated using savedefconfig. Signed-off-by: Abdellatif El Khlifi Cc: Tom Rini Cc: Simon Glass Cc: Ilias Apalodimas Cc: Jens Wiklander --- Changelog: === v19: Tom: * set CONFIG_FFA_SHARED_MM_BUF_* v18: Ilias, Tom: * drop use of CONFIG_FFA_SHARED_MM_BUF_* v17: * use savedefconfig to generate corstone1000_defconfig with FF-A MM comms enabled v16: * configs/corstone1000_defconfig: enable MM communication by setting the configs: ARM_FFA_TRANSPORT, OPTEE, TEE v15: Simon: * use CONFIG_FFA_SHARED_MM_BUF_* configs in place of FFA_SHARED_MM_BUFFER_* v13: * remove FF-A config in the defconfig (because it's enabled automatically by CONFIG_EFI_MM_COMM_TEE) v9: * update copyright string v8: * drop OP-TEE configs from Corstone-1000 defconfig v7: * improve the definition of FFA_SHARED_MM_BUFFER_ADDR and FFA_SHARED_MM_BUFFER_OFFSET * update FFA_SHARED_MM_BUFFER_ADDR value v6: * corstone-1000: enable optee driver * corstone-1000: remove CONFIG_ARM_FFA_EFI_RUNTIME_MODE from the defconfig v4: * corstone-1000: turn on EFI MM communication configs/corstone1000_defconfig | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/configs/corstone1000_defconfig b/configs/corstone1000_defconfig index a8a79fd105..83109b6a7e 100644 --- a/configs/corstone1000_defconfig +++ b/configs/corstone1000_defconfig @@ -28,12 +28,10 @@ CONFIG_CMD_FWU_METADATA=y CONFIG_CMD_BOOTZ=y CONFIG_SYS_BOOTM_LEN=0x80 # CONFIG_CMD_XIMG is not set -CONFIG_CMD_NVMXIP=y CONFIG_CMD_GPT=y # CONFIG_RANDOM_UUID is not set CONFIG_CMD_LOADM=y # CONFIG_CMD_LOADS is not set -CONFIG_CMD_MMC=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_NFS is not set @@ -45,8 +43,7 @@ CONFIG_OF_CONTROL=y CONFIG_VERSION_VARIABLE=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_REGMAP=y -CONFIG_FWU_MDATA=y -CONFIG_FWU_MDATA_GPT_BLK=y +CONFIG_ARM_FFA_TRANSPORT=y CONFIG_MISC=y # CONFIG_MMC is not set CONFIG_NVMXIP_QSPI=y @@ -59,9 +56,15 @@ CONFIG_DM_RTC=y CONFIG_RTC_EMULATION=y CONFIG_DM_SERIAL=y CONFIG_SYSRESET=y +CONFIG_TEE=y +CONFIG_OPTEE=y CONFIG_USB=y CONFIG_USB_ISP1760=y +CONFIG_ERRNO_STR=y +CONFIG_EFI_MM_COMM_TEE=y +CONFIG_FFA_SHARED_MM_BUF_SIZE=4096 +CONFIG_FFA_SHARED_MM_BUF_OFFSET=0 +CONFIG_FFA_SHARED_MM_BUF_ADDR=0x0200 CONFIG_EFI_CAPSULE_ON_DISK=y CONFIG_EFI_IGNORE_OSINDICATIONS=y CONFIG_FWU_MULTI_BANK_UPDATE=y -CONFIG_ERRNO_STR=y -- 2.25.1
[PATCH v19 8/9] arm_ffa: efi: introduce FF-A MM communication
Add MM communication support using FF-A transport This feature allows accessing MM partitions services through EFI MM communication protocol. MM partitions such as StandAlonneMM or smm-gateway secure partitions which reside in secure world. An MM shared buffer and a door bell event are used to exchange the data. The data is used by EFI services such as GetVariable()/SetVariable() and copied from the communication buffer to the MM shared buffer. The secure partition is notified about availability of data in the MM shared buffer by an FF-A message (door bell). On such event, MM SP can read the data and updates the MM shared buffer with the response data. The response data is copied back to the communication buffer and consumed by the EFI subsystem. MM communication protocol supports FF-A 64-bit direct messaging. We tested the FF-A MM communication on the Corstone-1000 platform. We ran the UEFI SCT test suite containing EFI setVariable, getVariable and getNextVariable tests which involve FF-A MM communication and all tests are passing with the current changes. We made the SCT test reports (part of the ACS results) public following the latest Corstone-1000 platform software release. Please find the test reports at [1]. [1]: https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-test-report/-/tree/master/embedded-a/corstone1000/CORSTONE1000-2023.06/acs_results_fpga.zip Signed-off-by: Abdellatif El Khlifi Tested-by: Gowtham Suresh Kumar Reviewed-by: Simon Glass Cc: Tom Rini Cc: Ilias Apalodimas Cc: Jens Wiklander --- Changelog: === v19: Tom: * use CONFIG_FFA_SHARED_MM_BUF_* in place of macros v18: Ilias, Tom: * drop the use of configs for the shared MM buffer, put back #ifdefs instead * add test information to the commit log v17: * show a debug message rather than an error when FF-A is not detected v16: * lib/efi_loader/Kconfig: rather than automatically selecting OPTEE and ARM_FFA_TRANSPORT configs by EFI_MM_COMM_TEE, set them as dependencies (Otherwise FF-A will be automatically enabled for boards that don't need it). v15: Simon: * replace FFA_SHARED_MM_BUFFER_* defines with configs v14: Ilias: * drop truncating var_payload->size when using FF-A * map the MM SP return codes to errnos v13: * remove FF-A and Optee ifdefs v12: * drop use of calloc when querying SPs * address nits v11: * rename select_ffa_mm_comms() to select_mm_comms() * improve the logic of MM transport selection in mm_communicate() * addressing nits v10: * use the FF-A driver Uclass operations * use uclass_first_device() * addressing nits v9: align how FF-A is used with FF-A discovery through DM v8: * isolate the compilation choices between FF-A and OP-TEE * update partition_info_get() second argument to be an SP count * pass NULL device pointer to the FF-A bus discovery and operations v7: * set the MM door bell event to use 64-bit direct messaging * issue a compile time error when one of these macros are not found : FFA_SHARED_MM_BUFFER_SIZE, FFA_SHARED_MM_BUFFER_OFFSET, FFA_SHARED_MM_BUFFER_ADDR * make mm_sp_svc_uuid static * replace EINVAL with ENOMEM in ffa_discover_mm_sp_id() when calloc() fails * improve use of unmap_sysmem() in ffa_mm_communicate() v6: * add FF-A runtime discovery at MM communication level * drop EFI runtime support for FF-A MM communication * revert the changes in include/mm_communication.h for efi_mm_communicate_header and smm_variable_access structures v4: * use the new FF-A driver interfaces * discover MM partitions at runtime * copy FF-A driver private data to EFI runtime section at ExitBootServices() * drop use of FFA_ERR_STAT_SUCCESS error code * replace EFI_BUFFER_TOO_SMALL with EFI_OUT_OF_RESOURCES in ffa_mm_communicate(). No need for efi_memcpy_runtime() anymore * revert the error log in mm_communicate() in case of failure * remove packed attribute from efi_mm_communicate_header and smm_variable_communicate_header v2: * set default values to 0 for FFA_SHARED_MM_BUFFER_SIZE, FFA_SHARED_MM_BUFFER_ADDR and MM_SP_UUID_DATA and add warnings v1: * introduce FF-A MM communication include/mm_communication.h| 17 ++ lib/efi_loader/Kconfig| 39 - lib/efi_loader/efi_variable_tee.c | 270 +- 3 files changed, 320 insertions(+), 6 deletions(-) diff --git a/include/mm_communication.h b/include/mm_communication.h index e65fbde60d..f38f1a5344 100644 --- a/include/mm_communication.h +++ b/include/mm_communication.h @@ -6,6 +6,9 @@ * Copyright (c) 2017, Intel Corporation. All rights reserved. * Copyright (C) 2020 Linaro Ltd. * Copyright (C) 2020 Linaro Ltd. + * Copyright 2022-2023 Arm Limited and/or its affiliates + *Authors: + * Abdellatif El Khlifi */ #ifndef _MM_COMMUNICATION_H_ @@ -13,6 +16,11 @@ #include +#if CONFIG_IS_ENABLED(ARM_FFA_TRANSPORT) +/* MM service UUID string (big-endian format). This UUID is common across all MM
[PATCH v19 7/9] arm_ffa: introduce armffa command
Provide armffa command showcasing the use of the U-Boot FF-A support
armffa is a command showcasing how to invoke FF-A operations.
This provides a guidance to the client developers on how to
call the FF-A bus interfaces. The command also allows to gather secure
partitions information and ping these partitions. The command is also
helpful in testing the communication with secure partitions.
For more details please refer to the command documentation [1].
A Sandbox test is provided for the armffa command.
[1]: doc/usage/cmd/armffa.rst
Signed-off-by: Abdellatif El Khlifi
Reviewed-by: Simon Glass
Cc: Tom Rini
Cc: Ilias Apalodimas
Cc: Jens Wiklander
Cc: Heinrich Schuchardt
---
Changelog:
===
v18:
Simon:
* Combining the commits of the command and the test case
v15:
Simon:
* armffa.c : integrate PHYS_ADDR_LN
v14:
Ilias:
* address nits
* in do_ffa_ping() reject the SP ID if it's 0
* use PHYS_ADDR_LN in formatting the physical addresses
v12:
* add subcommands argument checks
* usage documentation: update command return codes
* remove calloc when querying SPs
* address nits
v11:
* use U_BOOT_CMD_WITH_SUBCMDS
* address nits
v10:
* use the FF-A driver Uclass operations
* use uclass_first_device()
* address nits
v9:
* remove manual FF-A discovery and use DM
* use DM class APIs to probe and interact with the FF-A bus
* add doc/usage/cmd/armffa.rst
v8:
* update partition_info_get() second argument to be an SP count
* pass NULL device pointer to the FF-A bus discovery and operations
v7:
* adapt do_ffa_dev_list() following the recent update on
uclass_first_device/uclass_next_device functions (they return void now)
* set armffa command to use 64-bit direct messaging
v4:
* remove pattern data in do_ffa_msg_send_direct_req
v3:
* use the new driver interfaces (partition_info_get, sync_send_receive)
in armffa command
v2:
* replace use of ffa_helper_init_device function by
ffa_helper_bus_discover
v1:
* introduce armffa command
MAINTAINERS | 3 +
cmd/Kconfig | 10 ++
cmd/Makefile | 1 +
cmd/armffa.c | 202 +++
doc/arch/arm64.ffa.rst | 9 ++
doc/usage/cmd/armffa.rst | 94 ++
doc/usage/index.rst | 1 +
drivers/firmware/arm-ffa/Kconfig | 1 +
test/cmd/Makefile| 2 +
test/cmd/armffa.c| 33 +
10 files changed, 356 insertions(+)
create mode 100644 cmd/armffa.c
create mode 100644 doc/usage/cmd/armffa.rst
create mode 100644 test/cmd/armffa.c
diff --git a/MAINTAINERS b/MAINTAINERS
index b6d7263010..bd3dba3d95 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -271,9 +271,12 @@ M: Abdellatif El Khlifi
S: Maintained
F: arch/sandbox/include/asm/sandbox_arm_ffa.h
F: arch/sandbox/include/asm/sandbox_arm_ffa_priv.h
+F: cmd/armffa.c
F: doc/arch/arm64.ffa.rst
+F: doc/usage/cmd/armffa.rst
F: drivers/firmware/arm-ffa/
F: include/arm_ffa.h
+F: test/cmd/armffa.c
F: test/dm/ffa.c
ARM FREESCALE IMX
diff --git a/cmd/Kconfig b/cmd/Kconfig
index c1941849f9..da8569b417 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -935,6 +935,16 @@ endmenu
menu "Device access commands"
+config CMD_ARMFFA
+ bool "Arm FF-A test command"
+ depends on ARM_FFA_TRANSPORT
+ help
+ Provides a test command for the FF-A support
+ supported options:
+ - Listing the partition(s) info
+ - Sending a data pattern to the specified partition
+ - Displaying the arm_ffa device info
+
config CMD_ARMFLASH
#depends on FLASH_CFI_DRIVER
bool "armflash"
diff --git a/cmd/Makefile b/cmd/Makefile
index 6c37521b4e..7d20a85a46 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -12,6 +12,7 @@ obj-y += panic.o
obj-y += version.o
# command
+obj-$(CONFIG_CMD_ARMFFA) += armffa.o
obj-$(CONFIG_CMD_2048) += 2048.o
obj-$(CONFIG_CMD_ACPI) += acpi.o
obj-$(CONFIG_CMD_ADDRMAP) += addrmap.o
diff --git a/cmd/armffa.c b/cmd/armffa.c
new file mode 100644
index 00..7e6eafc03a
--- /dev/null
+++ b/cmd/armffa.c
@@ -0,0 +1,202 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2022-2023 Arm Limited and/or its affiliates
+ *
+ * Authors:
+ * Abdellatif El Khlifi
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Select the right physical address formatting according to the platform */
+#ifdef CONFIG_PHYS_64BIT
+#define PhysAddrLength "ll"
+#else
+#define PhysAddrLength ""
+#endif
+#define PHYS_ADDR_LN "%" PhysAddrLength "x"
+
+/**
+ * ffa_get_dev() - Return the FF-A device
+ * @devp: pointer to the FF-A device
+ *
+ * Search for the FF-A device.
+ *
+ * Return:
+ * 0 on success. Otherwise, failure
+ */
+static int ffa_get_dev(struct udevice **devp)
+{
+ int ret;
+
+ ret = uclass_first_device_err(UCLASS_FFA, devp);
+ if (ret) {
+
[PATCH v19 6/9] arm_ffa: introduce sandbox test cases for UCLASS_FFA
Add functional test cases for the FF-A support
These tests rely on the FF-A sandbox emulator and FF-A
sandbox driver which help in inspecting the FF-A communication.
Signed-off-by: Abdellatif El Khlifi
Reviewed-by: Simon Glass
Cc: Tom Rini
Cc: Ilias Apalodimas
Cc: Jens Wiklander
Cc: Heinrich Schuchardt
---
Changelog:
===
v12:
* remove use of dscvry_info
* drop use of calloc when querying SPs
* address nits
v11:
* drop unmapping test (taken care of by the DM when removing the device)
* address nits
v10:
* use the FF-A driver Uclass operations
* use uclass_first_device()
* replace CONFIG_SANDBOX_FFA with CONFIG_ARM_FFA_TRANSPORT
* address nits
v9: align FF-A sandbox tests with FF-A discovery through DM
v8:
* update partition_info_get() second argument to be an SP count
* pass NULL device pointer to the FF-A bus discovery and operations
v7: set the tests to use 64-bit direct messaging
v4: align sandbox tests with the new FF-A driver interfaces
and new way of error handling
v1: introduce sandbox tests
MAINTAINERS| 1 +
doc/arch/arm64.ffa.rst | 1 +
test/dm/Makefile | 3 +-
test/dm/ffa.c | 261 +
4 files changed, 265 insertions(+), 1 deletion(-)
create mode 100644 test/dm/ffa.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 63cf37290c..b6d7263010 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -274,6 +274,7 @@ F: arch/sandbox/include/asm/sandbox_arm_ffa_priv.h
F: doc/arch/arm64.ffa.rst
F: drivers/firmware/arm-ffa/
F: include/arm_ffa.h
+F: test/dm/ffa.c
ARM FREESCALE IMX
M: Stefano Babic
diff --git a/doc/arch/arm64.ffa.rst b/doc/arch/arm64.ffa.rst
index 792898321a..71606373f9 100644
--- a/doc/arch/arm64.ffa.rst
+++ b/doc/arch/arm64.ffa.rst
@@ -37,6 +37,7 @@ The U-Boot FF-A support provides the following parts:
FF-A ABIs inspection methods.
- An FF-A sandbox device driver for FF-A communication with the emulated
Secure World.
The driver leverages the FF-A Uclass to establish FF-A communication.
+- Sandbox FF-A test cases.
FF-A and SMC specifications
---
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 3799b1ae8f..7ed00733c1 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0+
#
# Copyright (c) 2013 Google, Inc
-# Copyright 2023 Arm Limited and/or its affiliates
+# Copyright 2022-2023 Arm Limited and/or its affiliates
obj-$(CONFIG_UT_DM) += test-dm.o
@@ -92,6 +92,7 @@ obj-$(CONFIG_POWER_DOMAIN) += power-domain.o
obj-$(CONFIG_ACPI_PMC) += pmc.o
obj-$(CONFIG_DM_PMIC) += pmic.o
obj-$(CONFIG_DM_PWM) += pwm.o
+obj-$(CONFIG_ARM_FFA_TRANSPORT) += ffa.o
obj-$(CONFIG_QFW) += qfw.o
obj-$(CONFIG_RAM) += ram.o
obj-y += regmap.o
diff --git a/test/dm/ffa.c b/test/dm/ffa.c
new file mode 100644
index 00..6912666bb4
--- /dev/null
+++ b/test/dm/ffa.c
@@ -0,0 +1,261 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Functional tests for UCLASS_FFA class
+ *
+ * Copyright 2022-2023 Arm Limited and/or its affiliates
+ *
+ * Authors:
+ * Abdellatif El Khlifi
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Functional tests for the UCLASS_FFA */
+
+static int check_fwk_version(struct ffa_priv *uc_priv, struct unit_test_state
*uts)
+{
+ struct ffa_sandbox_data func_data;
+ u32 fwk_version = 0;
+
+ func_data.data0 = _version;
+ func_data.data0_size = sizeof(fwk_version);
+ ut_assertok(sandbox_query_ffa_emul_state(FFA_VERSION, _data));
+ ut_asserteq(uc_priv->fwk_version, fwk_version);
+
+ return 0;
+}
+
+static int check_endpoint_id(struct ffa_priv *uc_priv, struct unit_test_state
*uts)
+{
+ ut_asserteq(0, uc_priv->id);
+
+ return 0;
+}
+
+static int check_rxtxbuf(struct ffa_priv *uc_priv, struct unit_test_state *uts)
+{
+ ut_assertnonnull(uc_priv->pair.rxbuf);
+ ut_assertnonnull(uc_priv->pair.txbuf);
+
+ return 0;
+}
+
+static int check_features(struct ffa_priv *uc_priv, struct unit_test_state
*uts)
+{
+ ut_assert(uc_priv->pair.rxtx_min_pages == RXTX_4K ||
+ uc_priv->pair.rxtx_min_pages == RXTX_16K ||
+ uc_priv->pair.rxtx_min_pages == RXTX_64K);
+
+ return 0;
+}
+
+static int check_rxbuf_mapped_flag(u32 queried_func_id,
+ u8 rxbuf_mapped,
+ struct unit_test_state *uts)
+{
+ switch (queried_func_id) {
+ case FFA_RXTX_MAP:
+ ut_asserteq(1, rxbuf_mapped);
+ break;
+ case FFA_RXTX_UNMAP:
+ ut_asserteq(0, rxbuf_mapped);
+ break;
+ default:
+ ut_assert(false);
+ }
+
+ return 0;
+}
+
+static int check_rxbuf_release_flag(u8 rxbuf_owned, struct unit_test_state
*uts)
+{
+ ut_asserteq(0, rxbuf_owned);
+
+ return 0;
+}
+
[PATCH v19 5/9] arm_ffa: introduce sandbox FF-A support
Emulate Secure World's FF-A ABIs and allow testing U-Boot FF-A support
Features of the sandbox FF-A support:
- Introduce an FF-A emulator
- Introduce an FF-A device driver for FF-A comms with emulated Secure World
- Provides test methods allowing to read the status of the inspected ABIs
The sandbox FF-A emulator supports only 64-bit direct messaging.
Signed-off-by: Abdellatif El Khlifi
Reviewed-by: Simon Glass
Cc: Tom Rini
Cc: Ilias Apalodimas
Cc: Jens Wiklander
Cc: Heinrich Schuchardt
---
Changelog:
===
v12:
* remove reparenting by making the emulator parent of the FF-A device in the DT
* add invoke_ffa_fn()
* address nits
v11:
* rename ffa_try_discovery() to sandbox_ffa_discover()
* rename sandbox_ffa_query_core_state() to sandbox_query_ffa_emul_state()
* store the sandbox emulator pointer in the FF-A device uc_priv (struct
ffa_priv)
* set the emulator as parent of the sandbox FF-A device
v10:
* split the FF-A sandbox support into an emulator and a driver
* read FFA_VERSION and FFA_PARTITION_INFO_GET state using
sandbox_ffa_query_core_state()
* drop CONFIG_SANDBOX_FFA config
* address nits
v9: align FF-A sandbox driver with FF-A discovery through DM
v8: update ffa_bus_prvdata_get() to return a pointer rather than
a pointer address
v7: state that sandbox driver supports only 64-bit direct messaging
v4: align sandbox driver with the new FF-A driver interfaces
and new way of error handling
v1: introduce the sandbox driver
MAINTAINERS | 3 +-
arch/sandbox/dts/sandbox.dtsi | 9 +
arch/sandbox/dts/test.dts | 8 +
arch/sandbox/include/asm/sandbox_arm_ffa.h| 72 ++
.../include/asm/sandbox_arm_ffa_priv.h| 121 +++
configs/sandbox64_defconfig | 1 +
configs/sandbox_defconfig | 1 +
doc/arch/arm64.ffa.rst| 19 +-
doc/arch/sandbox/sandbox.rst | 1 +
drivers/firmware/arm-ffa/Kconfig | 13 +-
drivers/firmware/arm-ffa/Makefile | 10 +-
drivers/firmware/arm-ffa/ffa-emul-uclass.c| 720 ++
.../firmware/arm-ffa/sandbox_arm_ffa_priv.h | 14 -
drivers/firmware/arm-ffa/sandbox_ffa.c| 110 +++
include/dm/uclass-id.h| 1 +
15 files changed, 1081 insertions(+), 22 deletions(-)
create mode 100644 arch/sandbox/include/asm/sandbox_arm_ffa.h
create mode 100644 arch/sandbox/include/asm/sandbox_arm_ffa_priv.h
create mode 100644 drivers/firmware/arm-ffa/ffa-emul-uclass.c
delete mode 100644 drivers/firmware/arm-ffa/sandbox_arm_ffa_priv.h
create mode 100644 drivers/firmware/arm-ffa/sandbox_ffa.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 4fd5768de0..63cf37290c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -269,10 +269,11 @@ F:configs/cortina_presidio-asic-pnand_defconfig
ARM FF-A
M: Abdellatif El Khlifi
S: Maintained
+F: arch/sandbox/include/asm/sandbox_arm_ffa.h
+F: arch/sandbox/include/asm/sandbox_arm_ffa_priv.h
F: doc/arch/arm64.ffa.rst
F: drivers/firmware/arm-ffa/
F: include/arm_ffa.h
-F: include/sandbox_arm_ffa.h
ARM FREESCALE IMX
M: Stefano Babic
diff --git a/arch/sandbox/dts/sandbox.dtsi b/arch/sandbox/dts/sandbox.dtsi
index 30a305c4d2..94a08814b8 100644
--- a/arch/sandbox/dts/sandbox.dtsi
+++ b/arch/sandbox/dts/sandbox.dtsi
@@ -445,6 +445,15 @@
thermal {
compatible = "sandbox,thermal";
};
+
+ arm-ffa-emul {
+ compatible = "sandbox,arm-ffa-emul";
+
+ sandbox-arm-ffa {
+ compatible = "sandbox,arm-ffa";
+ };
+ };
+
};
_ec {
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index ff9f9222e6..96b5404991 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -1820,6 +1820,14 @@
extcon {
compatible = "sandbox,extcon";
};
+
+ arm-ffa-emul {
+ compatible = "sandbox,arm-ffa-emul";
+
+ sandbox-arm-ffa {
+ compatible = "sandbox,arm-ffa";
+ };
+ };
};
#include "sandbox_pmic.dtsi"
diff --git a/arch/sandbox/include/asm/sandbox_arm_ffa.h
b/arch/sandbox/include/asm/sandbox_arm_ffa.h
new file mode 100644
index 00..be2790f496
--- /dev/null
+++ b/arch/sandbox/include/asm/sandbox_arm_ffa.h
@@ -0,0 +1,72 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2022-2023 Arm Limited and/or its affiliates
+ *
+ * Authors:
+ * Abdellatif El Khlifi
+ */
+
+#ifndef __SANDBOX_ARM_FFA_H
+#define __SANDBOX_ARM_FFA_H
+
+#include
+
+/*
+ * This header provides public sandbox FF-A emulator declarations
+ * and declarations needed by FF-A sandbox clients
+ */
+
+/* UUIDs strings of the emulated services */
+#define SANDBOX_SERVICE1_UUID "ed32d533-4209-99e6-2d72-cdd998a79cc0"
+#define SANDBOX_SERVICE2_UUID
[PATCH v19 4/9] arm_ffa: introduce Arm FF-A support
Add Arm FF-A support implementing Arm Firmware Framework for Armv8-A v1.0
The Firmware Framework for Arm A-profile processors (FF-A v1.0) [1]
describes interfaces (ABIs) that standardize communication
between the Secure World and Normal World leveraging TrustZone
technology.
This driver uses 64-bit registers as per SMCCCv1.2 spec and comes
on top of the SMCCC layer. The driver provides the FF-A ABIs needed for
querying the FF-A framework from the secure world.
The driver uses SMC32 calling convention which means using the first
32-bit data of the Xn registers.
All supported ABIs come with their 32-bit version except FFA_RXTX_MAP
which has 64-bit version supported.
Both 32-bit and 64-bit direct messaging are supported which allows both
32-bit and 64-bit clients to use the FF-A bus.
FF-A is a discoverable bus and similar to architecture features.
FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed
by the PSCI driver.
Clients are able to probe then use the FF-A bus by calling the DM class
searching APIs (e.g: uclass_first_device).
The Secure World is considered as one entity to communicate with
using the FF-A bus. FF-A communication is handled by one device and
one instance (the bus). This FF-A driver takes care of all the
interactions between Normal world and Secure World.
The driver exports its operations to be used by upper layers.
Exported operations:
- ffa_partition_info_get
- ffa_sync_send_receive
- ffa_rxtx_unmap
Generic FF-A methods are implemented in the Uclass (arm-ffa-uclass.c).
Arm specific methods are implemented in the Arm driver (arm-ffa.c).
For more details please refer to the driver documentation [2].
[1]: https://developer.arm.com/documentation/den0077/latest/
[2]: doc/arch/arm64.ffa.rst
Signed-off-by: Abdellatif El Khlifi
Reviewed-by: Simon Glass
Reviewed-by: Ilias Apalodimas
Cc: Tom Rini
Cc: Jens Wiklander
Cc: Heinrich Schuchardt
---
Changelog:
===
v13:
* doc minor change: specify in the readme that the user
should call ffa_rxtx_unmap() driver operation to unmap
the RX/TX buffers on demand.
v12:
* remove dscvry_info
* replace dscvry_info.invoke_ffa_fn() with a weak invoke_ffa_fn
(user drivers can override it)
* improve FFA_PARTITION_INFO_GET implementation
(clients no longer need to calloc a buffer)
* address nits
v11:
* move ffa_try_discovery() from the uclass to the Arm FF-A driver
* rename ffa_try_discovery() to arm_ffa_discover()
* pass dev as an argument of arm_ffa_discover()
* add arm_ prefix to the Arm FF-A driver functions
* add emul field in struct ffa_discovery_info
* address nits
v10:
* provide the driver operations through the Uclass
* move the generic FF-A methods to the Uclass
* keep Arm specific methods in the Arm driver (arm-ffa.c)
* rename core.c to arm-ffa.c
* address nits
v9:
* integrate the FF-A bus discovery in the DM and use ARM_SMCCC_FEATURES for
binding
v8:
* make ffa_get_partitions_info() second argument to be an SP count in both
modes
* update ffa_bus_prvdata_get() to return a pointer rather than a pointer
address
* remove packing from ffa_partition_info and ffa_send_direct_data structures
* pass the FF-A bus device to the bus operations
v7:
* add support for 32-bit direct messaging
* rename be_uuid_str_to_le_bin() to uuid_str_to_le_bin()
* improve the declaration of error handling mapping
* stating in doc/arch/arm64.ffa.rst that EFI runtime is not supported
v6:
* drop use of EFI runtime support (We decided with Linaro to add this later)
* drop discovery from initcalls (discovery will be on demand by FF-A users)
* set the alignment of the RX/TX buffers to the larger translation granule size
* move FF-A RX/TX buffers unmapping at ExitBootServices() to a separate commit
* update the documentation and move it to doc/arch/arm64.ffa.rst
v4:
* add doc/README.ffa.drv
* moving the FF-A driver work to drivers/firmware/arm-ffa
* use less #ifdefs in lib/efi_loader/efi_boottime.c and replace
#if defined by #if CONFIG_IS_ENABLED
* improving error handling by mapping the FF-A errors to standard errors
and logs
* replacing panics with an error log and returning an error code
* improving features discovery in FFA_FEATURES by introducing
rxtx_min_pages private data field
* add ffa_remove and ffa_unbind functions
* improve how the driver behaves when bus discovery is done more than
once
v3:
* align the interfaces of the U-Boot FF-A driver with those in the linux
FF-A driver
* remove the FF-A helper layer
* make the U-Boot FF-A driver independent from EFI
* provide an optional config that enables copying the driver data to EFI
runtime section at ExitBootServices service
* use 64-bit version of FFA_RXTX_MAP, FFA_MSG_SEND_DIRECT_{REQ, RESP}
v2:
* make FF-A bus discoverable using device_{bind, probe} APIs
* remove device tree support
v1:
* introduce FF-A bus driver with device tree support
MAINTAINERS |8 +
doc/arch/arm64.ffa.rst
[PATCH v19 3/9] lib: uuid: introduce testcase for uuid_str_to_le_bin
provide a test case
Signed-off-by: Abdellatif El Khlifi
Reviewed-by: Simon Glass
Cc: Tom Rini
---
Changelog:
===
v16:
* MAINTAINERS: place the UUID part in an alphabetical order
v11:
* use ut_asserteq_mem()
MAINTAINERS | 5 +
test/lib/Makefile | 1 +
test/lib/uuid.c | 41 +
3 files changed, 47 insertions(+)
create mode 100644 test/lib/uuid.c
diff --git a/MAINTAINERS b/MAINTAINERS
index d724b64673..4324965d26 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1555,6 +1555,11 @@ T: git
https://source.denx.de/u-boot/custodians/u-boot-usb.git topic-xhci
F: drivers/usb/host/xhci*
F: include/usb/xhci.h
+UUID testing
+M: Abdellatif El Khlifi
+S: Maintained
+F: test/lib/uuid.c
+
VIDEO
M: Anatolij Gustschin
S: Maintained
diff --git a/test/lib/Makefile b/test/lib/Makefile
index e0bd9e04e8..e75a263e6a 100644
--- a/test/lib/Makefile
+++ b/test/lib/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_AES) += test_aes.o
obj-$(CONFIG_GETOPT) += getopt.o
obj-$(CONFIG_CRC8) += test_crc8.o
obj-$(CONFIG_UT_LIB_CRYPT) += test_crypt.o
+obj-$(CONFIG_LIB_UUID) += uuid.o
else
obj-$(CONFIG_SANDBOX) += kconfig_spl.o
endif
diff --git a/test/lib/uuid.c b/test/lib/uuid.c
new file mode 100644
index 00..e24331a136
--- /dev/null
+++ b/test/lib/uuid.c
@@ -0,0 +1,41 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Functional tests for UCLASS_FFA class
+ *
+ * Copyright 2022-2023 Arm Limited and/or its affiliates
+ *
+ * Authors:
+ * Abdellatif El Khlifi
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/* test UUID */
+#define TEST_SVC_UUID "ed32d533-4209-99e6-2d72-cdd998a79cc0"
+
+#define UUID_SIZE 16
+
+/* The UUID binary data (little-endian format) */
+static const u8 ref_uuid_bin[UUID_SIZE] = {
+ 0x33, 0xd5, 0x32, 0xed,
+ 0x09, 0x42, 0xe6, 0x99,
+ 0x72, 0x2d, 0xc0, 0x9c,
+ 0xa7, 0x98, 0xd9, 0xcd
+};
+
+static int lib_test_uuid_to_le(struct unit_test_state *uts)
+{
+ const char *uuid_str = TEST_SVC_UUID;
+ u8 ret_uuid_bin[UUID_SIZE] = {0};
+
+ ut_assertok(uuid_str_to_le_bin(uuid_str, ret_uuid_bin));
+ ut_asserteq_mem(ref_uuid_bin, ret_uuid_bin, UUID_SIZE);
+
+ return 0;
+}
+
+LIB_TEST(lib_test_uuid_to_le, 0);
--
2.25.1
[PATCH v19 2/9] lib: uuid: introduce uuid_str_to_le_bin function
convert UUID string to little endian binary data
Signed-off-by: Abdellatif El Khlifi
Reviewed-by: Simon Glass
Cc: Tom Rini
Cc: Ilias Apalodimas
Cc: Jens Wiklander
---
Changelog:
===
v9:
* add a full function prototype description in uuid.h
v8:
* use simple_strtoull() in uuid_str_to_le_bin() to support 32-bit platforms
v7:
* rename be_uuid_str_to_le_bin() to uuid_str_to_le_bin()
* make uuid_str_to_le_bin() implementation similar to uuid_str_to_bin()
by using same APIs
v4:
* rename ffa_uuid_str_to_bin to be_uuid_str_to_le_bin and put in
a standalone commit (the current)
v3:
* introduce ffa_uuid_str_to_bin (provided by
arm_ffa: introduce Arm FF-A low-level driver)
include/uuid.h | 15 +++
lib/uuid.c | 48
2 files changed, 63 insertions(+)
diff --git a/include/uuid.h b/include/uuid.h
index 4a4883d3b5..89b93e642b 100644
--- a/include/uuid.h
+++ b/include/uuid.h
@@ -2,6 +2,10 @@
/*
* Copyright (C) 2014 Samsung Electronics
* Przemyslaw Marczak
+ * Copyright 2022-2023 Arm Limited and/or its affiliates
+ *
+ * Authors:
+ * Abdellatif El Khlifi
*/
#ifndef __UUID_H__
#define __UUID_H__
@@ -44,4 +48,15 @@ int uuid_guid_get_bin(const char *guid_str, unsigned char
*guid_bin);
const char *uuid_guid_get_str(const unsigned char *guid_bin);
void gen_rand_uuid(unsigned char *uuid_bin);
void gen_rand_uuid_str(char *uuid_str, int str_format);
+
+/**
+ * uuid_str_to_le_bin() - Convert string UUID to little endian binary data.
+ * @uuid_str: pointer to UUID string
+ * @uuid_bin: pointer to allocated array for little endian output [16B]
+ * Return:
+ *uuid_bin filled with little endian UUID data
+ *On success 0 is returned. Otherwise, failure code.
+ */
+int uuid_str_to_le_bin(const char *uuid_str, unsigned char *uuid_bin);
+
#endif
diff --git a/lib/uuid.c b/lib/uuid.c
index 96e1af3c8b..45f325d964 100644
--- a/lib/uuid.c
+++ b/lib/uuid.c
@@ -1,6 +1,10 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright 2011 Calxeda, Inc.
+ * Copyright 2022-2023 Arm Limited and/or its affiliates
+ *
+ * Authors:
+ * Abdellatif El Khlifi
*/
#include
@@ -354,6 +358,50 @@ int uuid_str_to_bin(const char *uuid_str, unsigned char
*uuid_bin,
return 0;
}
+/**
+ * uuid_str_to_le_bin() - Convert string UUID to little endian binary data.
+ * @uuid_str: pointer to UUID string
+ * @uuid_bin: pointer to allocated array for little endian output [16B]
+ *
+ * UUID string is 36 characters (36 bytes):
+ *
+ * ----
+ *
+ * where x is a hexadecimal character. Fields are separated by '-'s.
+ * When converting to a little endian binary UUID, the string fields are
reversed.
+ *
+ * Return:
+ *
+ *uuid_bin filled with little endian UUID data
+ *On success 0 is returned. Otherwise, failure code.
+ */
+int uuid_str_to_le_bin(const char *uuid_str, unsigned char *uuid_bin)
+{
+ u16 tmp16;
+ u32 tmp32;
+ u64 tmp64;
+
+ if (!uuid_str_valid(uuid_str) || !uuid_bin)
+ return -EINVAL;
+
+ tmp32 = cpu_to_le32(hextoul(uuid_str, NULL));
+ memcpy(uuid_bin, , 4);
+
+ tmp16 = cpu_to_le16(hextoul(uuid_str + 9, NULL));
+ memcpy(uuid_bin + 4, , 2);
+
+ tmp16 = cpu_to_le16(hextoul(uuid_str + 14, NULL));
+ memcpy(uuid_bin + 6, , 2);
+
+ tmp16 = cpu_to_le16(hextoul(uuid_str + 19, NULL));
+ memcpy(uuid_bin + 8, , 2);
+
+ tmp64 = cpu_to_le64(simple_strtoull(uuid_str + 24, NULL, 16));
+ memcpy(uuid_bin + 10, , 6);
+
+ return 0;
+}
+
/*
* uuid_bin_to_str() - convert big endian binary data to string UUID or GUID.
*
--
2.25.1
[PATCH v19 1/9] arm64: smccc: add support for SMCCCv1.2 x0-x17 registers
add support for x0-x17 registers used by the SMC calls In SMCCC v1.2 [1] arguments are passed in registers x1-x17. Results are returned in x0-x17. This work is inspired from the following kernel commit: arm64: smccc: Add support for SMCCCv1.2 extended input/output registers [1]: https://documentation-service.arm.com/static/5f8edaeff86e16515cdbe4c6?token= Signed-off-by: Abdellatif El Khlifi Reviewed-by: Ilias Apalodimas Reviewed-by: Jens Wiklander Reviewed-by: Simon Glass Cc: Tom Rini --- Changelog: === v9: * update the copyright string v7: * improve indentation of ARM_SMCCC_1_2_REGS_Xn_OFFS v4: * rename the commit title and improve description new commit title: the current v3: * port x0-x17 registers support from linux kernel as defined by SMCCCv1.2 commit title: arm64: smccc: add Xn registers support used by SMC calls arch/arm/cpu/armv8/smccc-call.S | 57 - arch/arm/lib/asm-offsets.c | 16 + include/linux/arm-smccc.h | 45 ++ 3 files changed, 117 insertions(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv8/smccc-call.S b/arch/arm/cpu/armv8/smccc-call.S index dc92b28777..93f66d3366 100644 --- a/arch/arm/cpu/armv8/smccc-call.S +++ b/arch/arm/cpu/armv8/smccc-call.S @@ -1,7 +1,11 @@ /* SPDX-License-Identifier: GPL-2.0 */ /* * Copyright (c) 2015, Linaro Limited - */ + * Copyright 2022-2023 Arm Limited and/or its affiliates + * + * Authors: + * Abdellatif El Khlifi +*/ #include #include #include @@ -45,3 +49,54 @@ ENDPROC(__arm_smccc_smc) ENTRY(__arm_smccc_hvc) SMCCC hvc ENDPROC(__arm_smccc_hvc) + +#ifdef CONFIG_ARM64 + + .macro SMCCC_1_2 instr + /* Save `res` and free a GPR that won't be clobbered */ + stp x1, x19, [sp, #-16]! + + /* Ensure `args` won't be clobbered while loading regs in next step */ + mov x19, x0 + + /* Load the registers x0 - x17 from the struct arm_smccc_1_2_regs */ + ldp x0, x1, [x19, #ARM_SMCCC_1_2_REGS_X0_OFFS] + ldp x2, x3, [x19, #ARM_SMCCC_1_2_REGS_X2_OFFS] + ldp x4, x5, [x19, #ARM_SMCCC_1_2_REGS_X4_OFFS] + ldp x6, x7, [x19, #ARM_SMCCC_1_2_REGS_X6_OFFS] + ldp x8, x9, [x19, #ARM_SMCCC_1_2_REGS_X8_OFFS] + ldp x10, x11, [x19, #ARM_SMCCC_1_2_REGS_X10_OFFS] + ldp x12, x13, [x19, #ARM_SMCCC_1_2_REGS_X12_OFFS] + ldp x14, x15, [x19, #ARM_SMCCC_1_2_REGS_X14_OFFS] + ldp x16, x17, [x19, #ARM_SMCCC_1_2_REGS_X16_OFFS] + + \instr #0 + + /* Load the `res` from the stack */ + ldr x19, [sp] + + /* Store the registers x0 - x17 into the result structure */ + stp x0, x1, [x19, #ARM_SMCCC_1_2_REGS_X0_OFFS] + stp x2, x3, [x19, #ARM_SMCCC_1_2_REGS_X2_OFFS] + stp x4, x5, [x19, #ARM_SMCCC_1_2_REGS_X4_OFFS] + stp x6, x7, [x19, #ARM_SMCCC_1_2_REGS_X6_OFFS] + stp x8, x9, [x19, #ARM_SMCCC_1_2_REGS_X8_OFFS] + stp x10, x11, [x19, #ARM_SMCCC_1_2_REGS_X10_OFFS] + stp x12, x13, [x19, #ARM_SMCCC_1_2_REGS_X12_OFFS] + stp x14, x15, [x19, #ARM_SMCCC_1_2_REGS_X14_OFFS] + stp x16, x17, [x19, #ARM_SMCCC_1_2_REGS_X16_OFFS] + + /* Restore original x19 */ + ldp xzr, x19, [sp], #16 + ret + .endm + +/* + * void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs *args, + * struct arm_smccc_1_2_regs *res); + */ +ENTRY(arm_smccc_1_2_smc) + SMCCC_1_2 smc +ENDPROC(arm_smccc_1_2_smc) + +#endif diff --git a/arch/arm/lib/asm-offsets.c b/arch/arm/lib/asm-offsets.c index 6de0ce9152..181a8ac4c2 100644 --- a/arch/arm/lib/asm-offsets.c +++ b/arch/arm/lib/asm-offsets.c @@ -9,6 +9,11 @@ * generate asm statements containing #defines, * compile this file to assembler, and then extract the * #defines from the assembly-language output. + * + * Copyright 2022-2023 Arm Limited and/or its affiliates + * + * Authors: + * Abdellatif El Khlifi */ #include @@ -90,6 +95,17 @@ int main(void) DEFINE(ARM_SMCCC_RES_X2_OFFS, offsetof(struct arm_smccc_res, a2)); DEFINE(ARM_SMCCC_QUIRK_ID_OFFS, offsetof(struct arm_smccc_quirk, id)); DEFINE(ARM_SMCCC_QUIRK_STATE_OFFS, offsetof(struct arm_smccc_quirk, state)); +#ifdef CONFIG_ARM64 + DEFINE(ARM_SMCCC_1_2_REGS_X0_OFFS, offsetof(struct arm_smccc_1_2_regs, a0)); + DEFINE(ARM_SMCCC_1_2_REGS_X2_OFFS, offsetof(struct arm_smccc_1_2_regs, a2)); + DEFINE(ARM_SMCCC_1_2_REGS_X4_OFFS, offsetof(struct arm_smccc_1_2_regs, a4)); + DEFINE(ARM_SMCCC_1_2_REGS_X6_OFFS, offsetof(struct arm_smccc_1_2_regs, a6)); + DEFINE(ARM_SMCCC_1_2_REGS_X8_OFFS, offsetof(struct arm_smccc_1_2_regs, a8)); + DEFINE(ARM_SMCCC_1_2_REGS_X10_OFFS, offsetof(struct arm_smccc_1_2_regs, a10)); + DEFINE(ARM_SMCCC_1_2_REGS_X12_OFFS, offsetof(struct arm_smccc_1_2_regs, a12)); +
[PATCH v19 0/9] introduce Arm FF-A support
Adding support for Arm FF-A v1.0 (Arm Firmware Framework for Armv8-A) [A]. FF-A specifies interfaces that enable a pair of software execution environments aka partitions to communicate with each other. A partition could be a VM in the Normal or Secure world, an application in S-EL0, or a Trusted OS in S-EL1. FF-A is a discoverable bus and similar to architecture features. FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed by the PSCI driver. => dm tree Class Index Probed DriverName --- ... firmware 0 [ + ] psci |-- psci ffa 0 [ ] arm_ffa | `-- arm_ffa ... Clients are able to probe then use the FF-A bus by calling the DM class searching APIs (e.g: uclass_first_device). This implementation of the specification provides support for Aarch64. The FF-A driver uses the SMC ABIs defined by the FF-A specification to: - Discover the presence of secure partitions (SPs) of interest - Access an SP's service through communication protocols (e.g: EFI MM communication protocol) The FF-A support provides the following features: - Being generic by design and can be used by any Arm 64-bit platform - FF-A support can be compiled and used without EFI - Support for SMCCCv1.2 x0-x17 registers - Support for SMC32 calling convention - Support for 32-bit and 64-bit FF-A direct messaging - Support for FF-A MM communication (compatible with EFI boot time) - Enabling FF-A and MM communication in Corstone1000 platform as a use case - A Uclass driver providing generic FF-A methods. - An Arm FF-A device driver providing Arm-specific methods and reusing the Uclass methods. - A sandbox emulator for Arm FF-A, emulates the FF-A side of the Secure World and provides FF-A ABIs inspection methods. - An FF-A sandbox device driver for FF-A communication with the emulated Secure World. The driver leverages the FF-A Uclass to establish FF-A communication. - Sandbox FF-A test cases. - A new command called armffa is provided as an example of how to access the FF-A bus For more details about the FF-A support please refer to [B] and refer to [C] for how to use the armffa command. Please find at [D] an example of the expected boot logs when enabling FF-A support for a platform. In this example the platform is Corstone1000. But it can be any Arm 64-bit platform. Changelog of changes: === v19: Tom: * use CONFIG_FFA_SHARED_MM_BUF_* in place of macros v18: [18] Ilias, Tom: * drop the use of configs for the shared MM buffer, put back #ifdefs instead * add test information to the MM comms commit message v17: [17] Ilias: * show a debug message rather than an error when FF-A is not detected Tom: * use savedefconfig to generate corstone1000_defconfig with FF-A MM comms enabled v16: [16] Tom: * lib/efi_loader/Kconfig: rather than automatically selecting OPTEE and ARM_FFA_TRANSPORT configs by EFI_MM_COMM_TEE, set them as dependencies (Otherwise FF-A will be automatically enabled for boards that don't need it). * configs/corstone1000_defconfig: enable MM communication by setting the configs: ARM_FFA_TRANSPORT, OPTEE, TEE v15: [15] Simon: * drop commit "log: select physical address formatting in a generic way", this will be sent as a follow-up commit independently from this patchset * armffa.c : integrate PHYS_ADDR_LN * replace FFA_SHARED_MM_BUFFER_* defines with configs v14: [14] Simon: * add to log.h a generic physical address formatting Ilias: * armffa command: in do_ffa_ping() reject the SP ID if it's 0 * MM comms: drop truncating var_payload->size when using FF-A * MM comms: map the MM SP return codes to errnos * address nits v13: [13] Ilias: * remove FF-A and Optee ifdefs in efi_variable_tee.c * doc minor change: specify in the readme that the user should call ffa_rxtx_unmap() driver operation to unmap the RX/TX buffers on demand. v12: [12] * remove the global variable (dscvry_info), use uc_priv instead * replace dscvry_info.invoke_ffa_fn() with a weak invoke_ffa_fn (user drivers can override it) * improve FFA_PARTITION_INFO_GET implementation (clients no longer need to calloc a buffer) * remove reparenting by making the sandbox emulator parent of the FF-A device in the DT * improve argument checks for the armffa command * address nits v11: [11] * move ffa_try_discovery() from the uclass to the Arm FF-A driver * rename ffa_try_discovery() to arm_ffa_discover() * add arm_ prefix to the Arm FF-A driver functions * use U_BOOT_CMD_WITH_SUBCMDS for armffa command * store the sandbox emulator pointer in the FF-A device uc_priv (struct ffa_priv) * set the emulator as parent of the sandbox FF-A device * rename select_ffa_mm_comms() to select_mm_comms() * improve the
Re: [PATCH v6 4/4] board: toradex: add verdin am62 support
Hi Nishanth On Fri, 2023-08-04 at 05:50 -0500, Nishanth Menon wrote: > On 12:08-20230804, Marcel Ziswiler wrote: > > From: Marcel Ziswiler > > > > This adds initial support for the Toradex Verdin AM62 Quad 1GB WB IT > > V1.0A module and subsequent V1.1 launch configuration SKUs. They are > > strapped to boot from their on-module eMMC. U-Boot supports booting > > from the on-module eMMC only, DFU support is disabled for now due to > > missing AM62x USB support. > > > > The device trees were taken straight from Linux v6.5-rc1. > > > > Boot sequence is: > > SYSFW ---> R5 SPL (both in tiboot3.bin) ---> ATF (TF-A) ---> OP-TEE > > ---> A53 SPL (part of tispl.bin) ---> U-boot proper (u-boot.img) > > > > Signed-off-by: Marcel Ziswiler > > > > it looks like this patch is stuck in the mail-size quarantine. Yeah, I guess not much I may do about it. However, just to be on the safe side I did CC it to Tom directly individually just to make sure he has it (;-p). Cheers Marcel
Re: [PATCH] efi_loader: Increase default variable store size to 32K
Hi Ilias,
On 2023-07-28 14:15 +03:00, Ilias Apalodimas wrote:
> On Sat, 8 Jul 2023 at 18:21, Alper Nebi Yasak
> wrote:
>>
>> Debian's arm64 UEFI Secure Boot shim makes the EFI variable store run
>> out of space while mirroring its MOK database to variables. This can be
>> observed in QEMU like so:
>>
>> $ tools/buildman/buildman -o build/qemu_arm64 --boards=qemu_arm64 -w
>> $ cd build/qemu_arm64
>> $ curl -L -o debian.iso \
>>
>> https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/debian-12.0.0-arm64-netinst.iso
>> $ qemu-system-aarch64 \
>> -nographic -bios u-boot.bin \
>> -machine virt -cpu cortex-a53 -m 1G -smp 2 \
>> -drive
>> if=virtio,file=debian.iso,index=0,format=raw,readonly=on,media=cdrom
>> [...]
>> => # interrupt autoboot
>> => env set -e -bs -nv -rt -guid 605dab50-e046-4300-abb6-3dd810dd8b23
>> SHIM_VERBOSE 1
>> => boot
>> [...]
>> mok.c:296:mirror_one_esl() SetVariable("MokListXRT43", ... varsz=0x4C) =
>> Out of Resources
>> mok.c:452:mirror_mok_db() esd:0x7DB92D20 adj:0x30
>> Failed to set MokListXRT: Out of Resources
>> mok.c:767:mirror_one_mok_variable() mirror_mok_db("MokListXRT",
>> datasz=17328) returned Out of Resources
>> mok.c:812:mirror_one_mok_variable() returning Out of Resources
>> Could not create MokListXRT: Out of Resources
>> [...]
>> Welcome to GRUB!
>>
>> This would normally be fine as shim would continue to run grubaa64.efi,
>> but shim's error handling code for this case has a bug [1] that causes a
>> synchronous abort on at least chromebook_kevin (but apparently not on
>> QEMU arm64).
>>
>> Double the default variable store size so the variables fit. There is a
>> note about this value matching PcdFlashNvStorageVariableSize when
>> EFI_MM_COMM_TEE is enabled, so keep the old default in that case.
>
> Thanks for the report. That EFI_MM_COMM_TEE basically means that the
> variables will be stored in an RPMB partition of an eMMC device. This
> has a couple of advantages compared to storing it in a file (mostly
> security related), but I can change that in the future.
I've read your article on it, but haven't really explored this stuff
because one-time-programmable things make me a bit afraid.
Mind that this happens even without any persistence at all, i.e.
ENV_IS_NOWHERE and EFI_VARIABLE_NO_STORE.
> When you use 32kb how much space do you have left after MoK etc have
> been written?
I can press "c" at the GRUB menu and run "exit" to get back to the
U-Boot shell, then I have:
=> efidebug query -bs -rt -nv
Max storage size 65512
Remaining storage size 54968
Max variable size 65480
=> env print -e -n
SecureBoot:
8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID)
BS|RT|RO, DataSize = 0x1
SetupMode:
8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID)
BS|RT|RO, DataSize = 0x1
AuditMode:
8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID)
BS|RT|RO, DataSize = 0x1
DeployedMode:
8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID)
BS|RT|RO, DataSize = 0x1
VendorKeys:
8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID)
BS|RT|RO, DataSize = 0x1
PlatformLangCodes:
8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID)
BS|RT|RO, DataSize = 0x6
PlatformLang:
8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID)
NV|BS|RT, DataSize = 0x6
OsIndicationsSupported:
8be4df61-93ca-11d2-aa0d-00e098032b8c (EFI_GLOBAL_VARIABLE_GUID)
BS|RT|RO, DataSize = 0x8
SbatLevel:
605dab50-e046-4300-abb6-3dd810dd8b23
(605dab50-e046-4300-abb6-3dd810dd8b23)
NV|BS, DataSize = 0x19
MokListRT:
605dab50-e046-4300-abb6-3dd810dd8b23
(605dab50-e046-4300-abb6-3dd810dd8b23)
BS|RT, DataSize = 0x3ce
MokListXRT:
605dab50-e046-4300-abb6-3dd810dd8b23
(605dab50-e046-4300-abb6-3dd810dd8b23)
BS|RT, DataSize = 0x21d8
SbatLevelRT:
605dab50-e046-4300-abb6-3dd810dd8b23
(605dab50-e046-4300-abb6-3dd810dd8b23)
BS|RT, DataSize = 0x19
MokListTrustedRT:
605dab50-e046-4300-abb6-3dd810dd8b23
(605dab50-e046-4300-abb6-3dd810dd8b23)
BS|RT, DataSize = 0x1
It's weird seeing 65512 - 54968 == 10544 < 16K. (Heinrich bumped it to
64K as he applied the patch, based on Windows docs.) But I'm noticing
how MokListXRT DataSize 0x21d8 * 2 == 17328 matches the datasz value in
the error.
If I retry with 16K, I see 43 extra values each with 0x4c size in
addition to the above.
=> efidebug query -bs -rt -nv
Max storage size 16360
Remaining storage size 0
Max variable size 16328
=> env print -e -n
[...]
MokListXRT1:
605dab50-e046-4300-abb6-3dd810dd8b23
(605dab50-e046-4300-abb6-3dd810dd8b23)
BS|RT, DataSize = 0x4c
[..]
MokListXRT43:
605dab50-e046-4300-abb6-3dd810dd8b23
(605dab50-e046-4300-abb6-3dd810dd8b23)
BS|RT, DataSize = 0x4c
Hope that helps, tell me if there's other commands you want me to run.
Re: [PATCH] common: board_f: Move relocation address after framebuffer
Hi,
On 04/08/23 13:10, Devarsh Thakkar wrote:
> Hi Simon, Tom, Bin,
>
> Thanks for the quick feedback.
>
> On 04/08/23 04:58, Simon Glass wrote:
>> Hi Devarsh,
>>
>> On Thu, 3 Aug 2023 at 08:28, Devarsh Thakkar wrote:
>>>
>>> Hi Simon,
>>>
>>> On 03/08/23 19:32, Simon Glass wrote:
+Bin Meng
Hi Devarsh,
On Tue, 1 Aug 2023 at 08:04, Devarsh Thakkar wrote:
>
> When passing framebuffer address using bloblist, check
> that passed address is overlapping with current relocation
> address, if so move the relocation address after the framebuffer
> region to avoid overlap.
>
> Fixes: 5bc610a7d9d ("common: board_f: Pass frame buffer info from
> SPL to u-boot")
> Signed-off-by: Devarsh Thakkar
> ---
> common/board_f.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/common/board_f.c b/common/board_f.c
> index 7d2c380e91..20fa17207a 100644
> --- a/common/board_f.c
> +++ b/common/board_f.c
> @@ -419,7 +419,10 @@ static int reserve_video(void)
> if (!ho)
> return log_msg_ret("blf", -ENOENT);
> video_reserve_from_bloblist(ho);
> - gd->relocaddr = ho->fb;
> + /* Relocate after framebuffer area to avoid overlap */
> + if (gd->relocaddr > (unsigned long)ho->fb)
> + gd->relocaddr = ho->fb;
> +
> } else if (CONFIG_IS_ENABLED(VIDEO)) {
> ulong addr;
> int ret;
> --
> 2.34.1
>
Yes this happens to work with qemu-x86_64. However it depends on the
SPL frame buffer being below the current allocation area. Why would it
be below, in general? This seems like a land mine for others to trip
up on.
>>>
>>> Basically to avoid overlap, the thing we are enforcing here is that
>>> relocaddr should always be below framebuffer so that further areas
>>> reserved do not overlap with framebuffer since we decrement relocaddr to
>>> resereve them. If relocaddr is already below framebuffer then there is no
>>> need to update relocaddr as in your case otherwise we have to do it, hence
>>> working for both scenarios.
>>
>> That's not true in general. Say the frame buffer is at 1GB and
>> U-Boot's top of memory is at 2GB, then this will create a gap in the
>> reservations, so some things are just below 2GB and some others are
>> just below 1GB. There will be no indication of this...
>>
>
> Thanks Simon, I understand your point here but I think this problem is still
> there even with other approaches like separate Kconfig or SPL blob passing to
> indicate relocaddr update, as though even in that case SPL will need some base
> to take a decision on whether u-boot proper will require to move relocaddr or
> not.
>
> For e.g. in this case there is a gap of ~1Gb between relocaddr and framebuffer
> and so we don't want to move relocaddr here since we assume that most likely
> ~1Gb is enough for u-boot to carry out and complete it's reservations without
> touching the framebuffer area, but this assumption may not hold true if the
> gap is in Mb's or Kb's.
>
> To resolve this, the maximum value required for u-boot to carry out
> reservations need to be estimated and then we can make this condition more
> intelligent :
>
> if (gd->relocaddr - gd->video_top < UBOOT_MAX_RESERVE_SIZE)
> gd->relocaddr = ho->fb;
>
Also need to add and consider the relocation aspect here since u-boot
relocates to gd->relocaddr after all reservations so need to make sure it
doesn't touch the framebuffer area after relocation.
To summarize there are different approaches possible here :
Approach 1 :
Have a paradigm that relocaddr should always be below framebuffer so that any
further reservations and also the relocation "never" overlaps with framebuffer
area. If it is not below then it will be moved below framebufer irrespective
of the gap between the two.
This is essentially
https://lore.kernel.org/all/20230801140414.76216-1-devar...@ti.com/ i.e. below
condition :
+ /* Relocate after framebuffer area to avoid overlap */
+ if (gd->relocaddr > (unsigned long)ho->fb)
+ gd->relocaddr = ho->fb;
The advantage is simplicity here but disadvantage of-course is scenario where
although framebuffer is below relocaddr but gap between framebuffer and
relocaddr is already large and relocaddr will be moved below the framebuffer
here too.
Approach 2:
To get over above disadvantage, don't move relocaddr if there is "enough" gap
between framebuffer and relocaddr. The challenge here is how to estimate or
find on what is "enough" gap as it depends on number and size of reserved
areas and also the size of relocation components. For e.g what to keep the
values of UBOOT_MAX_RESERVE_SIZE, UBOOT_MAX_RELOC_SIZE in below condition
do they need to be Kconfig filled by
Re: [PATCH v4 4/4] arm: dts: k3-am64: Sync DT with Linux v6.5-rc1
On 19:06-20230803, Roger Quadros wrote: > Sync all am642-evm/am642-sk related DT files > with Linux v6.5-rc1. > > - drop timer1 in favor of main_timer0 in am64-main.dtsi. > Need to delete clock & power domain properties of > main_timer1 in -r5.dts else won't boot. This is because > timer_init is done during rproc_start to start System Firmware, > but we can't do any clock/power-domain operations before > System Firmware starts. > - same constraint applies to main_uart0 > - drop cpsw3g custom DT property 'mac_efuse' and custom > DT node cpsw-phy-sel as driver picks these from standard > property/node. > - include board dts file in -r5 dts file to avoid duplication > of nodes. Include -u-boot.dtsi on top. > - drop duplicate nodes in -r5 dts and -u-boot.dtsi > > Signed-off-by: Roger Quadros > --- [...] > diff --git a/doc/board/ti/am64x_evm.rst b/doc/board/ti/am64x_evm.rst > index f378cbf12b..8d3795eb32 100644 > --- a/doc/board/ti/am64x_evm.rst > +++ b/doc/board/ti/am64x_evm.rst > @@ -159,7 +159,7 @@ https://www.ti.com/lit/pdf/spruim2 under the `Boot Mode > Pins` section. > - 1110 > - 0100 > > - * - OSPI > + * - xSPI/SFDP (OSPI) This should have been squashed to the documentation patch. > - 11001110 > - 0100 > > -- > 2.34.1 > Other than that, Reviewed-by: Nishanth Menon Tested-by: Nishanth Menon #SK-AM64B -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v4 3/4] doc: board: ti: am64: Add boot flow diagram
$subject: Add documentation for am64-evm On 19:06-20230803, Roger Quadros wrote: > Add boot flow diagram for AM64 SoC. and documentation for AM64-evm > > Suggested-by: Nishanth Menon > Signed-off-by: Roger Quadros Other than that: Reviewed-by: Nishanth Menon -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v4 2/4] Revert "ARM: dts: k3-am642-sk-u-boot: add PMIC node"
On 19:06-20230803, Roger Quadros wrote: > This reverts commit 28a4c3113445d4400639f357fae0def007a41093. > > This node should be in the board DT file and should come from upstream. > Moreover, this PMIC is no present on all variants of am642-sk > and will need a separate board DT file. > > Signed-off-by: Roger Quadros Reviewed-by: Nishanth Menon Tested-by: Nishanth Menon #SK-AM64B -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v4 1/4] board: ti: am64x: Recognize AM64-HSEVM
On 19:06-20230803, Roger Quadros wrote:
> AM64-HSEVM is AM64-GPEVM with High Security Device.
>
> Gets rid of "Unidentified board claims AM64-HSEVM in eeprom header".
>
> Signed-off-by: Roger Quadros
> Acked-by: Andrew Davis
> ---
> board/ti/am64x/evm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
> index 96f4e3013a..a080b2b0d2 100644
> --- a/board/ti/am64x/evm.c
> +++ b/board/ti/am64x/evm.c
> @@ -18,7 +18,8 @@
>
> #include "../common/board_detect.h"
>
> -#define board_is_am64x_gpevm() board_ti_k3_is("AM64-GPEVM")
> +#define board_is_am64x_gpevm() (board_ti_k3_is("AM64-GPEVM") || \
> + board_ti_k3_is("AM64-HSEVM"))
>
> #define board_is_am64x_skevm() (board_ti_k3_is("AM64-SKEVM") || \
> board_ti_k3_is("AM64B-SKEVM"))
> --
> 2.34.1
>
Reviewed-by: Nishanth Menon
Tested-by: Nishanth Menon #SK-AM64B
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
[PATCH v5 2/2] board: mediatek: add mt8195 demo board
From: Fabien Parent
Add mt8195-demo board support.
This demo purpose board uses MediaTek's MT8195 SoC.
Signed-off-by: Fabien Parent
Signed-off-by: Amjad Ouled-Ameur
Signed-off-by: Macpaul Lin
---
MAINTAINERS | 1 +
arch/arm/dts/Makefile | 1 +
arch/arm/dts/mt8195-demo.dts| 122
board/mediatek/mt8195/MAINTAINERS | 6 ++
board/mediatek/mt8195/Makefile | 3 +
board/mediatek/mt8195/README| 65 +++
board/mediatek/mt8195/mt8195_demo.c | 38 +
configs/mt8195_demo_defconfig | 99 ++
include/configs/mt8195.h| 46 +++
9 files changed, 381 insertions(+)
create mode 100644 arch/arm/dts/mt8195-demo.dts
create mode 100644 board/mediatek/mt8195/MAINTAINERS
create mode 100644 board/mediatek/mt8195/Makefile
create mode 100644 board/mediatek/mt8195/README
create mode 100644 board/mediatek/mt8195/mt8195_demo.c
create mode 100644 configs/mt8195_demo_defconfig
create mode 100644 include/configs/mt8195.h
Changes for v2 and v3:
- no change.
Changes for v4:
- Remove CONFIG_SYS_NS16550 related settings in mt8195.h.
Changes for v5:
- Fix Copyright year to 2023.
- Fix build error by adding 'CONFIG_TEXT_BASE' in defconfig.
- Add README for mt8195-demo board includes toolchain setting
'CROSS_COMPILE=aarch64-linux-gnu-'
- Fix 'CONFIG_EXTRA_ENV_SETTINGS' with 'CFG_EXTRA_ENV_SETTINGS'
according to checkpatch error.
- Update dram to 8GB size.
- dts
- Add optee and pcsi support in firmware section.
- mt8195_demo_defconfig
- enable I2C, DFU, GPT, MBR support
- enable some USB ethernet adaptors
- rebase patchset to v2023-10.rc1
diff --git a/MAINTAINERS b/MAINTAINERS
index 4d0f017e7e..454d3615f4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -396,6 +396,7 @@ F: drivers/watchdog/mtk_wdt.c
F: drivers/net/mtk_eth.c
F: drivers/net/mtk_eth.h
F: drivers/reset/reset-mediatek.c
+F: include/configs/mt8195.h
F: tools/mtk_image.c
F: tools/mtk_image.h
F: tools/mtk_nand_headers.c
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e66c32e268..d7104b77bf 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1342,6 +1342,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt7986a-emmc-rfb.dtb \
mt7986b-emmc-rfb.dtb \
mt8183-pumpkin.dtb \
+ mt8195-demo.dtb \
mt8512-bm1-emmc.dtb \
mt8516-pumpkin.dtb \
mt8518-ap1-emmc.dtb
diff --git a/arch/arm/dts/mt8195-demo.dts b/arch/arm/dts/mt8195-demo.dts
new file mode 100644
index 00..e4063cd143
--- /dev/null
+++ b/arch/arm/dts/mt8195-demo.dts
@@ -0,0 +1,122 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2023 MediaTek Inc.
+ * Copyright (C) 2023 BayLibre SAS.
+ * Author: Macpaul Lin
+ * Author: Fabien Parent
+ */
+
+/dts-v1/;
+
+#include
+#include "mt8195.dtsi"
+
+/ {
+ model = "MediaTek MT8195 demo board";
+ compatible = "mediatek,mt8195-demo", "mediatek,mt8195";
+
+ memory@4000 {
+ /* 8GB */
+ device_type = "memory";
+ reg = <0 0x4000 2 0x>;
+ };
+
+ firmware: firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+
+ psci: psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* 2 MiB reserved for ARM Trusted Firmware (BL31) */
+ bl31_secmon_reserved: secmon@5460 {
+ no-map;
+ reg = <0 0x5460 0x0 0x20>;
+ };
+
+ /* 12 MiB reserved for OP-TEE (BL32)
+* +---+ 0x43e0_
+* | SHMEM 2MiB |
+* +---+ 0x43c0_
+* || TA_RAM 8MiB |
+* + TZDRAM +--+ 0x4340_
+* || TEE_RAM 2MiB |
+* +---+ 0x4320_
+*/
+ optee_reserved: optee@4320 {
+ no-map;
+ reg = <0 0x4320 0 0x00c0>;
+ };
+ };
+
+ chosen {
+ stdout-path =
+ };
+
+ reg_1p8v: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+
[PATCH v5 1/2] arm: mediatek: add mt8195 SOC support
From: Fabien Parent
The MediaTek MT8195 is a ARM64-based SoC with a quad-core Cortex-A73 and
a quad-core Cortex-A53. It is including UART, SPI, USB3.0 device and hosts,
SD and MMC cards, UFS, PWM, I2C, I2S, S/PDIF, and several LPDDR3
and LPDDR4 options.
Signed-off-by: Fabien Parent
Signed-off-by: Macpaul Lin
---
MAINTAINERS| 2 +
arch/arm/dts/mt8195.dtsi | 370 +
arch/arm/mach-mediatek/Kconfig | 13 +-
arch/arm/mach-mediatek/Makefile| 1 +
arch/arm/mach-mediatek/mt8195/Kconfig | 13 +
arch/arm/mach-mediatek/mt8195/Makefile | 3 +
arch/arm/mach-mediatek/mt8195/init.c | 97 +++
7 files changed, 498 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/mt8195.dtsi
create mode 100644 arch/arm/mach-mediatek/mt8195/Kconfig
create mode 100644 arch/arm/mach-mediatek/mt8195/Makefile
create mode 100644 arch/arm/mach-mediatek/mt8195/init.c
Changes for v2:
- Correct node name to t-phy for u3phy0.
- Add platform compatible string "mediatek,mt8195-tphy" to all usb phy nodes.
- remove clock nodes that software cannot controlled in phy nodes.
- Test and add back "mac" for HOST only xhci nodes.
Changes for v3:
- Revise device node name from "xhciX: xhciX@" to "xhciX: xhci@".
Changes for v4:
- No change.
Changes for v5:
- Fix Copyright year to 2023.
- Fix memory map in dram_init() to support 8GB onboard memory.
- Add '#if !IS_ENABLED(CONFIG_SYSRESET)' with reset_cpu().
- Correct reset_cpu() function prototype.
- rebase patchset to v2023-10.rc1
- Add missing arch/arm/mach-mediatek/mt8195/Kconfig.
diff --git a/MAINTAINERS b/MAINTAINERS
index 47581cf6fb..4d0f017e7e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -369,8 +369,10 @@ ARM MEDIATEK
M: Ryder Lee
M: Weijie Gao
M: Chunfeng Yun
+M: Macpaul Lin
R: GSS_MTK_Uboot_upstream
S: Maintained
+F: arch/arm/dts/mt8195.dtsi
F: arch/arm/mach-mediatek/
F: arch/arm/include/asm/arch-mediatek/
F: board/mediatek/
diff --git a/arch/arm/dts/mt8195.dtsi b/arch/arm/dts/mt8195.dtsi
new file mode 100644
index 00..14cb28d008
--- /dev/null
+++ b/arch/arm/dts/mt8195.dtsi
@@ -0,0 +1,370 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2023 MediaTek Inc.
+ * Copyright (C) 2023 BayLibre, SAS
+ * Author: Ben Ho
+ * Erin Lo
+ * Fabien Parent
+ * Macpaul Lin
+ */
+
+#include
+#include
+#include
+#include
+
+/ {
+ compatible = "mediatek,mt8195";
+ interrupt-parent = <>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <>;
+ };
+ core1 {
+ cpu = <>;
+ };
+ core2 {
+ cpu = <>;
+ };
+ core3 {
+ cpu = <>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <>;
+ };
+ core1 {
+ cpu = <>;
+ };
+ core2 {
+ cpu = <>;
+ };
+ core3 {
+ cpu = <>;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x000>;
+ enable-method = "psci";
+ capacity-dmips-mhz = <741>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x001>;
+ enable-method = "psci";
+ capacity-dmips-mhz = <741>;
+ };
+
+ cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x002>;
+ enable-method = "psci";
+ capacity-dmips-mhz = <741>;
+ };
+
+ cpu3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x003>;
+ enable-method = "psci";
+
Re: [PATCH v6 4/4] board: toradex: add verdin am62 support
On 12:08-20230804, Marcel Ziswiler wrote: > From: Marcel Ziswiler > > This adds initial support for the Toradex Verdin AM62 Quad 1GB WB IT > V1.0A module and subsequent V1.1 launch configuration SKUs. They are > strapped to boot from their on-module eMMC. U-Boot supports booting > from the on-module eMMC only, DFU support is disabled for now due to > missing AM62x USB support. > > The device trees were taken straight from Linux v6.5-rc1. > > Boot sequence is: > SYSFW ---> R5 SPL (both in tiboot3.bin) ---> ATF (TF-A) ---> OP-TEE > ---> A53 SPL (part of tispl.bin) ---> U-boot proper (u-boot.img) > > Signed-off-by: Marcel Ziswiler > it looks like this patch is stuck in the mail-size quarantine. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v6 4/4] board: toradex: add verdin am62 support
Hi Marcel On 04/08/23 15:38, Marcel Ziswiler wrote: From: Marcel Ziswiler This adds initial support for the Toradex Verdin AM62 Quad 1GB WB IT V1.0A module and subsequent V1.1 launch configuration SKUs. They are strapped to boot from their on-module eMMC. U-Boot supports booting from the on-module eMMC only, DFU support is disabled for now due to missing AM62x USB support. The device trees were taken straight from Linux v6.5-rc1. Boot sequence is: SYSFW ---> R5 SPL (both in tiboot3.bin) ---> ATF (TF-A) ---> OP-TEE ---> A53 SPL (part of tispl.bin) ---> U-boot proper (u-boot.img) Signed-off-by: Marcel Ziswiler Reviewed-by: Neha Malcom Francis -- Thanking You Neha Malcom Francis
Re: [PATCH v6 3/4] arm: dts: k3-binman: fix rcfg_yaml and pcfg_yaml labels
Hi Marcel
On 04/08/23 15:38, Marcel Ziswiler wrote:
From: Marcel Ziswiler
Fix rcfg_yaml to really point to rm-cfg.yaml and pcfg_yaml to really
point to pm-cfg.yaml which likely is the intention.
While at it also add labels for the remaining items like custmpk_pem,
dkey_pem, bcfg_yaml_sysfw, scfg_yaml_sysfw, pcfg_yaml_sysfw and
rcfg_yaml_sysfw.
Signed-off-by: Marcel Ziswiler
---
Changes in v6:
- New commit fixing rcfg_yaml and pcfg_yaml labels actually pointing
at correct yamls and adding labels for the remaining items.
Thanks to Neha for pointing me towards actually making use of those
labels.
arch/arm/dts/k3-binman.dtsi | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
index 2a67cebf94f..2ea2dd18a12 100644
--- a/arch/arm/dts/k3-binman.dtsi
+++ b/arch/arm/dts/k3-binman.dtsi
@@ -12,14 +12,14 @@
{
custMpk {
filename = "custMpk.pem";
- blob-ext {
+ custmpk_pem: blob-ext {
filename = "../keys/custMpk.pem";
};
};
ti-degenerate-key {
filename = "ti-degenerate-key.pem";
- blob-ext {
+ dkey_pem: blob-ext {
filename = "../keys/ti-degenerate-key.pem";
};
};
@@ -37,14 +37,14 @@
};
pm-cfg {
filename = "pm-cfg.bin";
- rcfg_yaml: ti-board-config {
+ pcfg_yaml: ti-board-config {
config = "pm-cfg.yaml";
schema = "../common/schema.yaml";
};
};
rm-cfg {
filename = "rm-cfg.bin";
- pcfg_yaml: ti-board-config {
+ rcfg_yaml: ti-board-config {
config = "rm-cfg.yaml";
schema = "../common/schema.yaml";
};
Thanks for catching these as well!
@@ -93,19 +93,19 @@
combined-sysfw-cfg {
filename = "combined-sysfw-cfg.bin";
ti-board-config {
- board-cfg {
+ bcfg_yaml_sysfw: board-cfg {
config = "board-cfg.yaml";
schema = "../common/schema.yaml";
};
- sec-cfg {
+ scfg_yaml_sysfw: sec-cfg {
config = "sec-cfg.yaml";
schema = "../common/schema.yaml";
};
- pm-cfg {
+ pcfg_yaml_sysfw: pm-cfg {
config = "pm-cfg.yaml";
schema = "../common/schema.yaml";
};
- rm-cfg {
+ rcfg_yaml_sysfw: rm-cfg {
config = "rm-cfg.yaml";
schema = "../common/schema.yaml";
};
Reviewed-by: Neha Malcom Francis
--
Thanking You
Neha Malcom Francis
[PATCH v6 0/4] board: toradex: add verdin am62 support
From: Marcel Ziswiler This series adds initial support for the Toradex Verdin AM62 SoM [1]. The first commit adds resp. PID4s to the ConfigBlock, the second one fixes an early clocking issue confirmed to be a weird bug in TI's scripting, the third one fixes some binman labeling issue. And last but not least support for the Toradex Verdin AM62 is added. Azure CI still running [2]. Thanks! [1] https://www.toradex.com/computer-on-modules/verdin-arm-family/ti-am62 [2] https://dev.azure.com/u-boot/u-boot/_build/results?buildId=6804=results Changes in v6: - New commit fixing rcfg_yaml and pcfg_yaml labels actually pointing at correct yamls and adding labels for the remaining items. - Instead of duplicating the whole binman configuration just use phandles to override relevant properties where feasible. - Fix indentation in include/configs/verdin-am62.h. Thanks to Neha for pointing me towards actually making use of those labels. - Also remove some spurious newlines from our binman configuration file. Changes in v5: - Fix doc/board/toradex/verdin-am62.rst title underline being too short. - Add verdin-am62 to doc/board/toradex/index.rst. Thanks to Emanuele having run this series on the azure CI to find out. - Update U-Boot output in doc/board/toradex/verdin-am62.rst to latest. - State that the device trees were taken straight from Linux v6.5-rc1. - Remove k3-am625-verdin-wifi-dev-binman.dtsi include from r5 dts. - Remove memory@ and reserved-memory nodes. - Simplify sa_secproxy and esm nodes. - Get rid of ifdef zeros around usb stuff in device trees. - Re-work doc/board/toradex/verdin-am62.rst in a more re-usable way. Thanks to Nishanth for pointing those differences out as compared to arch/arm/dts/k3-am625-r5-sk.dts and his suggestions on the rst stuff. Changes in v4: - Re-based on top of master with recent binman integration, mac_efuse, cpsw-phy-sel and mdio clean-up and dtsi bump from linux v6.5-rc1. - Verdin AM62 binman enablement and further clean-up after re-base. - Removed all ifdefs from DTs now with bumped Linux dtsi. - Avoid relocated U-Boot and DT reserved-memory clash. - Enable of_system_setup. Changes in v3: - Add Verdin AM62 launch configuration SKUs as well. - Integrate our recent find of CTRL_SLEEP_MOCI# needing to be driven from A53 SPL as it may be used to control some power-rails on the carrier board. E.g. on the Yavia carrier board it is needed to power the I2C EEPROM on the carrier board. - Improve boot environment in R5 SPL vs. A53. - Integrate launch configuration SKUs to Wi-Fi handling. - Re-sync device trees from Linux kernel v6.5-rc1. - Add warning if memory is less than expected. Changes in v2: - Add Bryan's reviewed-by tag. Thanks! - Use 1.2 GHz rather than 1.25 GHz A53 clock as on the EVM/SK. - Also add power-domain 166 as on the EVM/SK. - Get rid of main_bcdma and main_pktdma as not required in R5 SPL. - Get rid of all bootph-pre-ram in Ethernet and SDHC1 aka SD card related pinctrls as not required in any SPL. - Enable CONFIG_TI_SECURE_DEVICE by default as Non-HS devices will continue to boot due to runtime device type detection. - Disable FAT and SPI support as not required in R5 SPL. - Also enable CONFIG_SPL_MMC_HS200_SUPPORT in R5 SPL. - Enable CONFIG_LEGACY_IMAGE_FORMAT to allow sourcing unsigned script images e.g. like our current boot scripts. - Increase CONFIG_SYS_BOOTM_LEN to 64 MB to allow booting bigger compressed images as e.g. in the Toradex Easy Installer case. - Change memory configurations to operate at temperatures of up to 95 degrees celsius. - Increase CONFIG_SYS_MAXARGS from default 16 to 64. - Enable CONFIG_CMD_REMOTEPROC, CONFIG_SPL_DM_GPIO_LOOKUP_LABEL and CONFIG_SPL_I2C_EEPROM. - For R5 SPL increase CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN to 0x14, enable CONFIG_SPL_I2C, CONFIG_DM_I2C and CONFIG_SYS_I2C_OMAP24XX and savedefconfig got rid of CONFIG_SPL_FIT_IMAGE_POST_PROCESS. Marcel Ziswiler (4): toradex: tdx-cfg-block: add verdin am62 skus arm: mach-k3: am62: fix 2nd mux option of clkout0 arm: dts: k3-binman: fix rcfg_yaml and pcfg_yaml labels board: toradex: add verdin am62 support arch/arm/dts/Makefile |4 +- arch/arm/dts/k3-am62-verdin-dev.dtsi | 190 ++ arch/arm/dts/k3-am62-verdin-wifi.dtsi | 39 + arch/arm/dts/k3-am62-verdin.dtsi | 1401 +++ .../dts/k3-am625-verdin-lpddr4-1600MTs.dtsi | 2190 + arch/arm/dts/k3-am625-verdin-r5.dts | 84 + .../dts/k3-am625-verdin-wifi-dev-binman.dtsi | 532 .../dts/k3-am625-verdin-wifi-dev-u-boot.dtsi | 201 ++ arch/arm/dts/k3-am625-verdin-wifi-dev.dts | 22 + arch/arm/dts/k3-binman.dtsi | 16 +- arch/arm/mach-k3/Kconfig |1 + arch/arm/mach-k3/am62x/clk-data.c |5 +- board/toradex/common/tdx-cfg-block.c |7 + board/toradex/common/tdx-cfg-block.h | 10 +-
[PATCH v6 3/4] arm: dts: k3-binman: fix rcfg_yaml and pcfg_yaml labels
From: Marcel Ziswiler
Fix rcfg_yaml to really point to rm-cfg.yaml and pcfg_yaml to really
point to pm-cfg.yaml which likely is the intention.
While at it also add labels for the remaining items like custmpk_pem,
dkey_pem, bcfg_yaml_sysfw, scfg_yaml_sysfw, pcfg_yaml_sysfw and
rcfg_yaml_sysfw.
Signed-off-by: Marcel Ziswiler
---
Changes in v6:
- New commit fixing rcfg_yaml and pcfg_yaml labels actually pointing
at correct yamls and adding labels for the remaining items.
Thanks to Neha for pointing me towards actually making use of those
labels.
arch/arm/dts/k3-binman.dtsi | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
index 2a67cebf94f..2ea2dd18a12 100644
--- a/arch/arm/dts/k3-binman.dtsi
+++ b/arch/arm/dts/k3-binman.dtsi
@@ -12,14 +12,14 @@
{
custMpk {
filename = "custMpk.pem";
- blob-ext {
+ custmpk_pem: blob-ext {
filename = "../keys/custMpk.pem";
};
};
ti-degenerate-key {
filename = "ti-degenerate-key.pem";
- blob-ext {
+ dkey_pem: blob-ext {
filename = "../keys/ti-degenerate-key.pem";
};
};
@@ -37,14 +37,14 @@
};
pm-cfg {
filename = "pm-cfg.bin";
- rcfg_yaml: ti-board-config {
+ pcfg_yaml: ti-board-config {
config = "pm-cfg.yaml";
schema = "../common/schema.yaml";
};
};
rm-cfg {
filename = "rm-cfg.bin";
- pcfg_yaml: ti-board-config {
+ rcfg_yaml: ti-board-config {
config = "rm-cfg.yaml";
schema = "../common/schema.yaml";
};
@@ -93,19 +93,19 @@
combined-sysfw-cfg {
filename = "combined-sysfw-cfg.bin";
ti-board-config {
- board-cfg {
+ bcfg_yaml_sysfw: board-cfg {
config = "board-cfg.yaml";
schema = "../common/schema.yaml";
};
- sec-cfg {
+ scfg_yaml_sysfw: sec-cfg {
config = "sec-cfg.yaml";
schema = "../common/schema.yaml";
};
- pm-cfg {
+ pcfg_yaml_sysfw: pm-cfg {
config = "pm-cfg.yaml";
schema = "../common/schema.yaml";
};
- rm-cfg {
+ rcfg_yaml_sysfw: rm-cfg {
config = "rm-cfg.yaml";
schema = "../common/schema.yaml";
};
--
2.36.1
[PATCH v6 2/4] arm: mach-k3: am62: fix 2nd mux option of clkout0
From: Marcel Ziswiler
Fix second mux option of clkout0 which should really be
DEV_BOARD0_CLKOUT0_IN_PARENT_HSDIV4_16FFT_MAIN_2_HSDIVOUT1_CLK10
rather than twice the same according to [1].
[1]
https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am62x/clocks.html#clocks-for-board0-device
Signed-off-by: Marcel Ziswiler
Reviewed-by: Bryan Brattlof
---
(no changes since v2)
Changes in v2:
- Add Bryan's reviewed-by tag. Thanks!
arch/arm/mach-k3/am62x/clk-data.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-k3/am62x/clk-data.c
b/arch/arm/mach-k3/am62x/clk-data.c
index c0881778fe7..d7bfed0e031 100644
--- a/arch/arm/mach-k3/am62x/clk-data.c
+++ b/arch/arm/mach-k3/am62x/clk-data.c
@@ -57,7 +57,7 @@ static const char * const
sam62_pll_ctrl_wrap_mcu_0_sysclkout_clk_parents[] = {
static const char * const clkout0_ctrl_out0_parents[] = {
"hsdiv4_16fft_main_2_hsdivout1_clk",
- "hsdiv4_16fft_main_2_hsdivout1_clk",
+ "hsdiv4_16fft_main_2_hsdivout1_clk10",
};
static const char * const clk_32k_rc_sel_out0_parents[] = {
@@ -195,6 +195,7 @@ static const struct clk_data clk_list[] = {
CLK_DIV("hsdiv4_16fft_main_1_hsdivout1_clk",
"pllfracf_ssmod_16fft_main_1_foutvcop_clk", 0x681084, 0, 7, 0, 0),
CLK_DIV("hsdiv4_16fft_main_1_hsdivout2_clk",
"pllfracf_ssmod_16fft_main_1_foutvcop_clk", 0x681088, 0, 7, 0, 0),
CLK_DIV("hsdiv4_16fft_main_2_hsdivout1_clk",
"pllfracf_ssmod_16fft_main_2_foutvcop_clk", 0x682084, 0, 7, 0, 0),
+ CLK_DIV("hsdiv4_16fft_main_2_hsdivout1_clk10",
"pllfracf_ssmod_16fft_main_2_foutvcop_clk", 0x682084, 0, 7, 0, 0),
CLK_DIV("hsdiv4_16fft_main_2_hsdivout2_clk",
"pllfracf_ssmod_16fft_main_2_foutvcop_clk", 0x682088, 0, 7, 0, 0),
CLK_DIV("hsdiv4_16fft_mcu_0_hsdivout0_clk",
"pllfracf_ssmod_16fft_mcu_0_foutvcop_clk", 0x4040080, 0, 7, 0, 0),
CLK_MUX_PLLCTRL("sam62_pll_ctrl_wrap_main_0_sysclkout_clk",
sam62_pll_ctrl_wrap_main_0_sysclkout_clk_parents, 2, 0x41, 0),
@@ -313,7 +314,7 @@ static const struct dev_clk soc_dev_clk_data[] = {
DEV_CLK(146, 5, "sam62_pll_ctrl_wrap_main_0_chip_div1_clk_clk"),
DEV_CLK(157, 20, "clkout0_ctrl_out0"),
DEV_CLK(157, 21, "hsdiv4_16fft_main_2_hsdivout1_clk"),
- DEV_CLK(157, 22, "hsdiv4_16fft_main_2_hsdivout1_clk"),
+ DEV_CLK(157, 22, "hsdiv4_16fft_main_2_hsdivout1_clk10"),
DEV_CLK(157, 24, "sam62_pll_ctrl_wrap_main_0_chip_div1_clk_clk"),
DEV_CLK(157, 25, "board_0_ddr0_ck0_out"),
DEV_CLK(157, 40, "mshsi2c_main_0_porscl"),
--
2.36.1
