[PATCH v2] efi_loader: add EFI_TCG2_PROTOCOL.SubmitCommand
This commit adds the EFI_TCG2_PROTOCOL.SubmitCommand
required in the TCG PC Client PFP spec.
SubmitCommand enables to send the raw command to the TPM device.
To implement this api, tpm2_submit_command() is added
into tpm-v2.c.
Signed-off-by: Masahisa Kojima
---
Changes in v2:
- return EFI_OUT_OF_RESOURCES if the recv buffer is small
- remove unused argument of tpm2_submit_command()
include/tpm-v2.h | 14 +
lib/efi_loader/efi_tcg2.c | 41 +--
lib/tpm-v2.c | 6 ++
3 files changed, 55 insertions(+), 6 deletions(-)
diff --git a/include/tpm-v2.h b/include/tpm-v2.h
index e6b68769f3..39c8c0897b 100644
--- a/include/tpm-v2.h
+++ b/include/tpm-v2.h
@@ -642,4 +642,18 @@ u32 tpm2_write_lock(struct udevice *dev, u32 index);
*/
u32 tpm2_disable_platform_hierarchy(struct udevice *dev);
+/**
+ * submit user specified data to the TPM and get response
+ *
+ * @devTPM device
+ * @sendbuf: Buffer of the data to send
+ * @recvbuf: Buffer to save the response to
+ * @recv_size: Pointer to the size of the response buffer
+ *
+ * Returns 0 on success (and places the number of response bytes at
+ * recv_size) or -ve on failure.
+ */
+u32 tpm2_submit_command(struct udevice *dev, const u8 *sendbuf,
+ u8 *recvbuf, size_t *recv_size);
+
#endif /* __TPM_V2_H */
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index ec20530b6b..cb67006b14 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -1033,13 +1033,42 @@ out:
* Return: status code
*/
static efi_status_t EFIAPI
-efi_tcg2_submit_command(__maybe_unused struct efi_tcg2_protocol *this,
- u32 __maybe_unused input_param_block_size,
- u8 __maybe_unused *input_param_block,
- u32 __maybe_unused output_param_block_size,
- u8 __maybe_unused *output_param_block)
+efi_tcg2_submit_command(struct efi_tcg2_protocol *this,
+ u32 input_param_block_size,
+ u8 *input_param_block,
+ u32 output_param_block_size,
+ u8 *output_param_block)
{
- return EFI_UNSUPPORTED;
+ struct udevice *dev;
+ efi_status_t ret;
+ u32 rc;
+ size_t resp_buf_size = output_param_block_size;
+
+ EFI_ENTRY("%p, %u, %p, %u, %p", this, input_param_block_size,
+ input_param_block, output_param_block_size,
output_param_block);
+
+ if (!this || !input_param_block || !input_param_block_size) {
+ ret = EFI_INVALID_PARAMETER;
+ goto out;
+ }
+
+ ret = platform_get_tpm2_device();
+ if (ret != EFI_SUCCESS)
+ goto out;
+
+ rc = tpm2_submit_command(dev, input_param_block,
+output_param_block, _buf_size);
+ if (rc) {
+ if (rc == -ENOSPC)
+ ret = EFI_OUT_OF_RESOURCES;
+ else
+ ret = EFI_DEVICE_ERROR;
+
+ goto out;
+ }
+
+out:
+ return EFI_EXIT(ret);
}
/**
diff --git a/lib/tpm-v2.c b/lib/tpm-v2.c
index 235f8c20d4..2e7b27bd6b 100644
--- a/lib/tpm-v2.c
+++ b/lib/tpm-v2.c
@@ -659,3 +659,9 @@ u32 tpm2_disable_platform_hierarchy(struct udevice *dev)
return 0;
}
+
+u32 tpm2_submit_command(struct udevice *dev, const u8 *sendbuf,
+ u8 *recvbuf, size_t *recv_size)
+{
+ return tpm_sendrecv_command(dev, sendbuf, recvbuf, recv_size);
+}
--
2.17.1
[PATCH] drivers: net: add Aspeed MDIO driver
Add a driver for the MDIO interface for Aspeed AST2600 SOC. The driver
only supports clause 22 for now.
Signed-off-by: Dylan Hung
---
drivers/net/Kconfig | 7 +++
drivers/net/Makefile | 1 +
drivers/net/aspeed_mdio.c | 128 ++
3 files changed, 136 insertions(+)
create mode 100644 drivers/net/aspeed_mdio.c
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 6c12959f37..4638180b74 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -826,6 +826,13 @@ config FSL_LS_MDIO
This driver supports the MDIO bus found on the Fman 10G Ethernet MACs
and
on the mEMAC (which supports both Clauses 22 and 45).
+config ASPEED_MDIO
+ bool "Aspeed MDIO interface support"
+ depends on DM_MDIO
+ help
+ This driver supports the MDIO bus of Aspeed AST2600 SOC. The driver
+ currently supports Clause 22.
+
config MDIO_MUX_MMIOREG
bool "MDIO MUX accessed as a MMIO register access"
depends on DM_MDIO_MUX
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index e4078d15a9..fe6c00fa48 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -101,3 +101,4 @@ obj-$(CONFIG_HIGMACV300_ETH) += higmacv300.o
obj-$(CONFIG_MDIO_SANDBOX) += mdio_sandbox.o
obj-$(CONFIG_FSL_ENETC) += fsl_enetc.o fsl_enetc_mdio.o
obj-$(CONFIG_FSL_LS_MDIO) += fsl_ls_mdio.o
+obj-$(CONFIG_ASPEED_MDIO) += aspeed_mdio.o
diff --git a/drivers/net/aspeed_mdio.c b/drivers/net/aspeed_mdio.c
new file mode 100644
index 00..a99715a728
--- /dev/null
+++ b/drivers/net/aspeed_mdio.c
@@ -0,0 +1,128 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Aspeed MDIO driver
+ *
+ * (C) Copyright 2021 Aspeed Technology Inc.
+ *
+ * This file is inspired from the Linux kernel driver
drivers/net/phy/mdio-aspeed.c
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ASPEED_MDIO_CTRL 0x0
+#define ASPEED_MDIO_CTRL_FIREBIT(31)
+#define ASPEED_MDIO_CTRL_ST BIT(28)
+#define ASPEED_MDIO_CTRL_ST_C450
+#define ASPEED_MDIO_CTRL_ST_C221
+#define ASPEED_MDIO_CTRL_OP GENMASK(27, 26)
+#define MDIO_C22_OP_WRITE 0b01
+#define MDIO_C22_OP_READ 0b10
+#define ASPEED_MDIO_CTRL_PHYAD GENMASK(25, 21)
+#define ASPEED_MDIO_CTRL_REGAD GENMASK(20, 16)
+#define ASPEED_MDIO_CTRL_MIIWDATAGENMASK(15, 0)
+
+#define ASPEED_MDIO_DATA 0x4
+#define ASPEED_MDIO_DATA_MDC_THRES GENMASK(31, 24)
+#define ASPEED_MDIO_DATA_MDIO_EDGE BIT(23)
+#define ASPEED_MDIO_DATA_MDIO_LATCH GENMASK(22, 20)
+#define ASPEED_MDIO_DATA_IDLEBIT(16)
+#define ASPEED_MDIO_DATA_MIIRDATAGENMASK(15, 0)
+
+#define ASPEED_MDIO_TIMEOUT_US 1000
+
+struct aspeed_mdio_priv {
+ void *base;
+};
+
+static int aspeed_mdio_read(struct udevice *mdio_dev, int addr, int devad, int
reg)
+{
+ struct aspeed_mdio_priv *priv = dev_get_priv(mdio_dev);
+ u32 ctrl;
+ u32 data;
+ int rc;
+
+ if (devad != MDIO_DEVAD_NONE)
+ return -EOPNOTSUPP;
+
+ ctrl = ASPEED_MDIO_CTRL_FIRE
+ | FIELD_PREP(ASPEED_MDIO_CTRL_ST, ASPEED_MDIO_CTRL_ST_C22)
+ | FIELD_PREP(ASPEED_MDIO_CTRL_OP, MDIO_C22_OP_READ)
+ | FIELD_PREP(ASPEED_MDIO_CTRL_PHYAD, addr)
+ | FIELD_PREP(ASPEED_MDIO_CTRL_REGAD, reg);
+
+ writel(ctrl, priv->base + ASPEED_MDIO_CTRL);
+
+ rc = readl_poll_timeout(priv->base + ASPEED_MDIO_DATA, data,
+ data & ASPEED_MDIO_DATA_IDLE,
+ ASPEED_MDIO_TIMEOUT_US);
+
+ if (rc < 0)
+ return rc;
+
+ return FIELD_GET(ASPEED_MDIO_DATA_MIIRDATA, data);
+}
+
+static int aspeed_mdio_write(struct udevice *mdio_dev, int addr, int devad,
int reg, u16 val)
+{
+ struct aspeed_mdio_priv *priv = dev_get_priv(mdio_dev);
+ u32 ctrl;
+
+ if (devad != MDIO_DEVAD_NONE)
+ return -EOPNOTSUPP;
+
+ ctrl = ASPEED_MDIO_CTRL_FIRE
+ | FIELD_PREP(ASPEED_MDIO_CTRL_ST, ASPEED_MDIO_CTRL_ST_C22)
+ | FIELD_PREP(ASPEED_MDIO_CTRL_OP, MDIO_C22_OP_WRITE)
+ | FIELD_PREP(ASPEED_MDIO_CTRL_PHYAD, addr)
+ | FIELD_PREP(ASPEED_MDIO_CTRL_REGAD, reg)
+ | FIELD_PREP(ASPEED_MDIO_CTRL_MIIWDATA, val);
+
+ writel(ctrl, priv->base + ASPEED_MDIO_CTRL);
+
+ return readl_poll_timeout(priv->base + ASPEED_MDIO_CTRL, ctrl,
+ !(ctrl & ASPEED_MDIO_CTRL_FIRE),
+ ASPEED_MDIO_TIMEOUT_US);
+}
+
+static const struct mdio_ops aspeed_mdio_ops = {
+ .read = aspeed_mdio_read,
+ .write = aspeed_mdio_write,
+};
+
+static int aspeed_mdio_probe(struct udevice *dev)
+{
+ struct aspeed_mdio_priv *priv = dev_get_priv(dev);
+ struct reset_ctl
Re: [PATCH] efi_loader: add EFI_TCG2_PROTOCOL.SubmitCommand
On Fri, 29 Oct 2021 at 18:43, Masahisa Kojima
wrote:
>
> On Fri, 29 Oct 2021 at 15:26, Ilias Apalodimas
> wrote:
> >
> >
> > On Fri, Oct 22, 2021 at 08:20:55PM +0900, Masahisa Kojima wrote:
> > > This commit adds the EFI_TCG2_PROTOCOL.SubmitCommand
> > > required in the TCG PC Client PFP spec.
> > > SubmitCommand enables to send the raw command to the TPM device.
> > >
> > > To implement this api, tpm2_submit_command() is added
> > > into tpm-v2.c.
> > >
> > > Signed-off-by: Masahisa Kojima
> > > ---
> > > include/tpm-v2.h | 15 +++
> > > lib/efi_loader/efi_tcg2.c | 37 +++--
> > > lib/tpm-v2.c | 6 ++
> > > 3 files changed, 52 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/include/tpm-v2.h b/include/tpm-v2.h
> > > index e6b68769f3..6b04a637ca 100644
> > > --- a/include/tpm-v2.h
> > > +++ b/include/tpm-v2.h
> > > @@ -642,4 +642,19 @@ u32 tpm2_write_lock(struct udevice *dev, u32 index);
> > > */
> > > u32 tpm2_disable_platform_hierarchy(struct udevice *dev);
> > >
> > > +/**
> > > + * submit user specified data to the TPM and get response
> > > + *
> > > + * @dev TPM device
> > > + * @sendbuf: Buffer of the data to send
> > > + * @send_size: Size of the data to send
> > > + * @recvbuf: Buffer to save the response to
> > > + * @recv_size: Pointer to the size of the response buffer
> > > + *
> > > + * Returns 0 on success (and places the number of response bytes at
> > > + * recv_size) or -ve on failure.
> > > + */
> > > +u32 tpm2_submit_command(struct udevice *dev, const u8 *sendbuf,
> > > + size_t send_size, u8 *recvbuf, size_t *recv_size);
> > > +
> > > #endif /* __TPM_V2_H */
> > > diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
> > > index da02e281e7..a0728b555e 100644
> > > --- a/lib/efi_loader/efi_tcg2.c
> > > +++ b/lib/efi_loader/efi_tcg2.c
> > > @@ -1033,13 +1033,38 @@ out:
> > > * Return: status code
> > > */
> > > static efi_status_t EFIAPI
> > > -efi_tcg2_submit_command(__maybe_unused struct efi_tcg2_protocol *this,
> > > - u32 __maybe_unused input_param_block_size,
> > > - u8 __maybe_unused *input_param_block,
> > > - u32 __maybe_unused output_param_block_size,
> > > - u8 __maybe_unused *output_param_block)
> > > +efi_tcg2_submit_command(struct efi_tcg2_protocol *this,
> > > + u32 input_param_block_size,
> > > + u8 *input_param_block,
> > > + u32 output_param_block_size,
> > > + u8 *output_param_block)
> > > {
> > > - return EFI_UNSUPPORTED;
> > > + struct udevice *dev;
> > > + efi_status_t ret;
> > > + u32 rc;
> > > + size_t resp_buf_size = output_param_block_size;
> > > +
> > > + EFI_ENTRY("%p, %u, %p, %u, %p", this, input_param_block_size,
> > > + input_param_block, output_param_block_size,
> > > output_param_block);
> > > +
> > > + if (!this || !input_param_block || !input_param_block_size) {
> > > + ret = EFI_INVALID_PARAMETER;
> > > + goto out;
> > > + }
> > > +
> > > + ret = platform_get_tpm2_device();
> > > + if (ret != EFI_SUCCESS)
> > > + goto out;
> > > +
> > > + rc = tpm2_submit_command(dev, input_param_block,
> > > input_param_block_size,
> > > + output_param_block, _buf_size);
> >
> > Shouldn't you check resp_buf_size against output_param_block_size here and
> > return EFI_BUFFER_TOO_SMALL if the output_param_block_size is smaller?
>
> It should be checked, thank you.
tpm_sendrecv_command() does not fill *recv_size with the received size
if the *recv_size is smaller than the actual received size, it just
return -ENOSPC.
So instead of checking resp_buf_size, check return code and
if rc is -ENOSPC then return EFI_BUFFER_TOO_SMALL.
Thanks,
Masahisa Kojima
>
> >
> > > + if (rc) {
> > > + ret = EFI_DEVICE_ERROR;
> > > + goto out;
> > > + }
> > > +
> > > +out:
> > > + return EFI_EXIT(ret);
> > > }
> > >
> > > /**
> > > diff --git a/lib/tpm-v2.c b/lib/tpm-v2.c
> > > index 235f8c20d4..ee08948ec1 100644
> > > --- a/lib/tpm-v2.c
> > > +++ b/lib/tpm-v2.c
> > > @@ -659,3 +659,9 @@ u32 tpm2_disable_platform_hierarchy(struct udevice
> > > *dev)
> > >
> > > return 0;
> > > }
> > > +
> > > +u32 tpm2_submit_command(struct udevice *dev, const u8 *sendbuf,
> > > + size_t send_size, u8 *recvbuf, size_t *recv_size)
> >
> > Why do we keep send_size in the arg list? tpm_sendrecv_command is exported
> > anyway, so we can just use that?
>
> Yes, send_size is not used, should be removed.
>
> tpm_sendrecv_command() is exported, but declared in lib/tpm-utils.h,
> it means this function can only be called under u-boot/lib, can not be
> called from ./lib/efi_loader/*.
> Also the tpm stack seems to be
Re: [PATCH v4] driver: spi: add bcm iproc qspi support.
On Tue, Nov 2, 2021 at 4:57 AM Roman Bacik wrote:
>
> Hi Jagan,
>
> On Mon, Nov 1, 2021 at 12:12 AM Jagan Teki wrote:
> >
> > On Tue, Oct 26, 2021 at 1:07 AM Roman Bacik
> > wrote:
> > >
> > > From: Rayagonda Kokatanur
> > >
> > > IPROC qspi driver supports both BSPI and MSPI modes.
> > >
> > > Signed-off-by: Rayagonda Kokatanur
> > > Signed-off-by: Bharat Gooty
> > > Acked-by: Rayagonda Kokatanur
> > >
> > > Signed-off-by: Roman Bacik
> > > ---
> > >
> > > Changes in v4:
> > > - move iproc_qspi.c from spi to mtd/spi
> > > - remove iproc_qspi.h
> > > - rename IPROC_QSPI to SPI_FLASH_IPROC
> > >
> > > Changes in v3:
> > > - fix warning by including linux/delay.h
> > > - change ofdata_to_platdata to of_to_plat
> > > - change priv_auto_alloc_size to priv_auto
> > >
> > > Changes in v2:
> > > - remove include spi-nor.h
> > > - define and use named BITs for writing register values
> > > - remove bspi_set_4byte_mode() method
> > >
> > > drivers/mtd/spi/Kconfig | 6 +
> > > drivers/mtd/spi/Makefile | 1 +
> > > drivers/mtd/spi/iproc_qspi.c | 718 +++
> > > 3 files changed, 725 insertions(+)
> > > create mode 100644 drivers/mtd/spi/iproc_qspi.c
> >
> > Look like you confused what I've mentioned before, your driver is
> > flash specific so add a driver in UCLASS_SPI_FLASH. drivers with
> > UCLASS_SPI to be in drivers/spi/
> >
> > Jagan.
>
> This is a controller driver and it is currently meant to be used as follows:
>
> qspi: spi@37 {
> compatible = "brcm,iproc-qspi";
> reg = <0x0037 0x100>,
> <0x00370100 0x100>,
> <0x00370200 0x200>;
> reg-names = "bspi", "bspi_raf", "mspi";
> flash-iomap-addr = /bits/ 64 <0x7000>;
> #address-cells = <1>;
> #size-cells = <0>;
> spi_nor_flash: spi_flash@0 {
> compatible = "jedec,spi-nor";
> reg = <0>;
> spi-max-frequency = <1250>;
> spi-cpol;
> spi-cpha;
> spi-tx-bus-width = <1>;
> spi-rx-bus-width = <4>;
> };
> };
Does this binding is from Linux? if yes please share Linux driver.
Jagan.
fastboot: boot: Relocate ramdisk
Hi: The u-boot doesn't relocated ramdisk if we booting linux by using next fastboot command: (FASTBOOT_BUF_ADDR is configed to 0x8200) "fastboot boot arch/arm/boot/zImage ramdisk.cpio arch/arm/boot/dts/imx6ull-myir-mys-6ulx-eval.dtb -c 'console=ttymxc0,115200 root=/dev/ram0 rdinit=/init' -b 0x8100" Next is the log from console: ## Booting Android Image at 0x8200 ... Kernel load addr 0x81008000 size 6601 KiB Kernel command line: console=ttymxc0,115200 root=/dev/ram0 rdinit=/init kernel data at 0x82000800, len = 0x006722d8 (6759128) RAM disk load addr 0x8200 size 3939 KiB Error: header_version must be >= 2 to get dtb second address is 0x82a4c000 Loading Kernel Image kernel loaded at 0x81008000, end = 0x8167a2d8 Using Device Tree in place at 82a4c000, end 82a55483 ## Transferring control to Linux (at address 81008000)... [0.00] OF: fdt: initrd_start=0x82673000 initrd_end=0x82a4ba00 The kernel is relocated to the new address we setted in fastboot command, but u-boot havn't relocate ramdisk. From the kernel's log we know ramdisk in 0x82673000, not the address 0x8200 that u-boot printed.
[PATCH] aspeed: AST2600 Pinctrl Driver
From: Ryan Chen
This driver uses Pinctrl framework and is compatible with the Linux
driver for AST2600.
Signed-off-by: Ryan Chen
Signed-off-by: Dylan Hung
---
drivers/pinctrl/Kconfig | 9 +
drivers/pinctrl/aspeed/Makefile | 1 +
drivers/pinctrl/aspeed/pinctrl_ast2600.c | 459 +++
3 files changed, 469 insertions(+)
create mode 100644 drivers/pinctrl/aspeed/pinctrl_ast2600.c
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 30eaa376c8..42f25e24fb 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -291,6 +291,15 @@ config ASPEED_AST2500_PINCTRL
uses Generic Pinctrl framework and is compatible with the Linux
driver, i.e. it uses the same device tree configuration.
+config ASPEED_AST2600_PINCTRL
+ bool "Aspeed AST2600 pin control driver"
+ depends on DM && PINCTRL_GENERIC && ASPEED_AST2600
+ default y
+ help
+ Support pin multiplexing control on Aspeed ast2600 SoC. The driver
+ uses Generic Pinctrl framework and is compatible with the Linux
+ driver, i.e. it uses the same device tree configuration.
+
config PINCTRL_K210
bool "Kendryte K210 Fully-Programmable Input/Output Array driver"
depends on DM && PINCTRL_GENERIC
diff --git a/drivers/pinctrl/aspeed/Makefile b/drivers/pinctrl/aspeed/Makefile
index 2e6ed604c8..a3e01ed1ca 100644
--- a/drivers/pinctrl/aspeed/Makefile
+++ b/drivers/pinctrl/aspeed/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_ASPEED_AST2500_PINCTRL) += pinctrl_ast2500.o
+obj-$(CONFIG_ASPEED_AST2600_PINCTRL) += pinctrl_ast2600.o
diff --git a/drivers/pinctrl/aspeed/pinctrl_ast2600.c
b/drivers/pinctrl/aspeed/pinctrl_ast2600.c
new file mode 100644
index 00..12cba83f6c
--- /dev/null
+++ b/drivers/pinctrl/aspeed/pinctrl_ast2600.c
@@ -0,0 +1,459 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) ASPEED Technology Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * This driver works with very simple configuration that has the same name
+ * for group and function. This way it is compatible with the Linux Kernel
+ * driver.
+ */
+struct aspeed_sig_desc {
+ u32 offset;
+ u32 reg_set;
+ int clr;
+};
+
+struct aspeed_group_config {
+ char *group_name;
+ int ndescs;
+ struct aspeed_sig_desc *descs;
+};
+
+struct ast2600_pinctrl_priv {
+ struct ast2600_scu *scu;
+};
+
+static int ast2600_pinctrl_probe(struct udevice *dev)
+{
+ struct ast2600_pinctrl_priv *priv = dev_get_priv(dev);
+ struct udevice *clk_dev;
+ int ret = 0;
+
+ /* find SCU base address from clock device */
+ uclass_get_device_by_driver(UCLASS_CLK,
DM_DRIVER_GET(aspeed_ast2600_scu), _dev);
+
+ if (ret)
+ return ret;
+
+ priv->scu = dev_read_addr_ptr(clk_dev);
+ if (IS_ERR(priv->scu))
+ return PTR_ERR(priv->scu);
+
+ return 0;
+}
+
+static struct aspeed_sig_desc i2c1_link[] = {
+ { 0x418, GENMASK(9, 8), 1 },
+ { 0x4B8, GENMASK(9, 8), 0 },
+};
+
+static struct aspeed_sig_desc i2c2_link[] = {
+ { 0x418, GENMASK(11, 10), 1 },
+ { 0x4B8, GENMASK(11, 10), 0 },
+};
+
+static struct aspeed_sig_desc i2c3_link[] = {
+ { 0x418, GENMASK(13, 12), 1 },
+ { 0x4B8, GENMASK(13, 12), 0 },
+};
+
+static struct aspeed_sig_desc i2c4_link[] = {
+ { 0x418, GENMASK(15, 14), 1 },
+ { 0x4B8, GENMASK(15, 14), 0 },
+};
+
+static struct aspeed_sig_desc i2c5_link[] = {
+ { 0x418, GENMASK(17, 16), 0 },
+};
+
+static struct aspeed_sig_desc i2c6_link[] = {
+ { 0x418, GENMASK(19, 18), 0 },
+};
+
+static struct aspeed_sig_desc i2c7_link[] = {
+ { 0x418, GENMASK(21, 20), 0 },
+};
+
+static struct aspeed_sig_desc i2c8_link[] = {
+ { 0x418, GENMASK(23, 22), 0 },
+};
+
+static struct aspeed_sig_desc i2c9_link[] = {
+ { 0x418, GENMASK(25, 24), 0 },
+};
+
+static struct aspeed_sig_desc i2c10_link[] = {
+ { 0x418, GENMASK(27, 26), 0 },
+};
+
+static struct aspeed_sig_desc i2c11_link[] = {
+ { 0x410, GENMASK(1, 0), 1 },
+ { 0x4B0, GENMASK(1, 0), 0 },
+};
+
+static struct aspeed_sig_desc i2c12_link[] = {
+ { 0x410, GENMASK(3, 2), 1 },
+ { 0x4B0, GENMASK(3, 2), 0 },
+};
+
+static struct aspeed_sig_desc i2c13_link[] = {
+ { 0x410, GENMASK(5, 4), 1 },
+ { 0x4B0, GENMASK(5, 4), 0 },
+};
+
+static struct aspeed_sig_desc i2c14_link[] = {
+ { 0x410, GENMASK(7, 6), 1 },
+ { 0x4B0, GENMASK(7, 6), 0 },
+};
+
+static struct aspeed_sig_desc i2c15_link[] = {
+ { 0x414, GENMASK(29, 28), 1 },
+ { 0x4B4, GENMASK(29, 28), 0 },
+};
+
+static struct aspeed_sig_desc i2c16_link[] = {
+ { 0x414, GENMASK(31, 30), 1 },
+ { 0x4B4, GENMASK(31, 30), 0 },
+};
+
+static struct aspeed_sig_desc mac1_link[] = {
+ { 0x410, BIT(4), 0 },
+ { 0x470, BIT(4), 1 },
+};
+
+static
Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION
On Sun, Oct 31, 2021 at 08:14:13PM -0600, Simon Glass wrote: > Hi Takahiro, > > On Sun, 31 Oct 2021 at 19:52, AKASHI Takahiro > wrote: > > > > On Sun, Oct 31, 2021 at 07:15:17PM -0600, Simon Glass wrote: > > > Hi Takahiro, > > > > > > On Sun, 31 Oct 2021 at 18:36, AKASHI Takahiro > > > wrote: > > > > > > > > On Sat, Oct 30, 2021 at 07:45:14AM +0200, Heinrich Schuchardt wrote: > > > > > > > > > > > > > > > Am 29. Oktober 2021 23:17:56 MESZ schrieb Simon Glass > > > > > : > > > > > >Hi, > > > > > > > > > > > >On Fri, 29 Oct 2021 at 13:26, Heinrich Schuchardt > > > > > > wrote: > > > > > >> > > > > > >> > > > > > >> > > > > > >> Am 29. Oktober 2021 08:15:56 MESZ schrieb AKASHI Takahiro > > > > > >> : > > > > > >> >On Fri, Oct 29, 2021 at 06:57:24AM +0200, Heinrich Schuchardt > > > > > >> >wrote: > > > > > >> >> > > > > > >> >> > > > > > >> >> > I agree with Heinrich that we are better to leave BLK as it > > > > > >> >> > is, both > > > > > >> >> > in name and meaning. I think maybe I am missing the gist of > > > > > >> >> > your > > > > > >> >> > argument. > > > > > >> >> > > > > > > >> >> > If we use UCLASS_PART, for example, can we have that refer to > > > > > >> >> > both s/w > > > > > >> >> > and h/w partitions, as Herinch seems to allude to below? What > > > > > >> >> > would > > > > > >> >> > the picture look like the, and would it get us closer to > > > > > >> >> > agreement? > > > > > >> >> > > > > > >> >> In the driver model: > > > > > >> >> > > > > > >> >> A UCLASS is a class of drivers that share the same interface. > > > > > >> >> A UDEVICE is a logical device that belongs to exactly one > > > > > >> >> UCLASS and is > > > > > >> >> accessed through this UCLASS's interface. > > > > > >> > > > > > > >> >Please be careful about "accessed through" which is a quite > > > > > >> >confusing > > > > > >> >expression. I don't always agree with this view. > > > > > >> > > > > > > >> >> A hardware partition is an object that exposes only a single > > > > > >> >> interface > > > > > >> >> for block IO. > > > > > >> >> > > > > > >> >> A software partition is an object that may expose two > > > > > >> >> interfaces: one > > > > > >> >> for block IO, the other for file IO. > > > > > >> > > > > > > >> >Are you talking about UEFI world or U-Boot? > > > > > >> >Definitely, a hw partitions can provide a file system > > > > > >> >if you want. > > > > > >> >It's a matter of usage. > > > > > >> > > > > > > >> >I remember that we had some discussion about whether block devices > > > > > >> >on UEFI system should always have a (sw) partition table or not. > > > > > >> >But it is a different topic. > > > > > >> > > > > > > >> >> The UEFI model does not have a problem with this because on a > > > > > >> >> handle you > > > > > >> >> can install as many different protocols as you wish. But > > > > > >> >> U-Boot's driver > > > > > >> >> model only allows a single interface per device. Up to now > > > > > >> >> U-Boot has > > > > > >> >> overcome this limitation by creating child devices for the > > > > > >> >> extra interfaces. > > > > > >> > > > > > > >> >> We have the following logical levels: > > > > > >> >> > > > > > >> >> Controller | Block device | Software Partition| File system > > > > > >> >> +--+---+ > > > > > >> >> NVMe Drive | Namespace| Partition 1..n| FAT, EXT4 > > > > > >> >> ATA Controller | ATA-Drive| | > > > > > >> >> SCSI Controller | LUN | | > > > > > >> >> MMC Controller | HW-Partition | | > > > > > >> >> MMC Controller | SD-Card | | > > > > > >> >> USB-Node| USB-Drive| | > > > > > >> >> > > > > > >> >> In the device tree this could be modeled as: > > > > > >> >> > > > > > >> >> |-- Controller (UCLASS_CTRL) > > > > > >> >> | |-- Block device / HW Partition (UCLASS_BLK)(A) > > > > > >> >> | | |-- Partition table (UCLASS_PARTITION_TABLE) (B) > > > > > >> >> | | |-- Software Partition (UCLASS_BLK) > > > > > >> >> | | |-- File system (UCLASS_FS) > > > > > >> >> | | > > > > > >> >> | |-- Block device (UCLASS_BLK) > > > > > >> >> | |-- File system (UCLASS_FS) > > > > > >> > > > > > > >> >I don't know why we expect PARTITION_TABLE and FS to appear in DM > > > > > >> >tree. > > > > > >> >What is the benefit? > > > > > >> >(A) and (B) always have 1:1 relationship. > > > > > >> > > > > > >> No. You can have a bare device without a partition table. > > > > > > > > > > > >I can have a DOS partition that covers the whole device, without a > > > > > >partition table. This is supported in U-Boot and Linux. > > > > > > > > > > > >> > > > > > >> We have several partition table drivers: DOS, GPT, OSX, ... . In > > > > > >> future we should also have one for the NOR Flash partitions. All > > > > > >> of these drivers have a common interface. As the partition table > > > > > >> type is
[PATCH v6 12/12] (RFC) efi_loader, dts: add public keys for capsules to device tree
By specifying CONFIG_EFI_CAPSULE_KEY_PATH, the build process will automatically insert the given key into the device tree. Otherwise, users are required to do so manually, possibly, with the utility script, fdtsig.sh. Signed-off-by: AKASHI Takahiro --- doc/develop/uefi/uefi.rst | 4 dts/Makefile | 23 +-- lib/efi_loader/Kconfig| 7 +++ 3 files changed, 32 insertions(+), 2 deletions(-) diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst index 54fefd76f0f5..7f85b9e5a4a6 100644 --- a/doc/develop/uefi/uefi.rst +++ b/doc/develop/uefi/uefi.rst @@ -347,6 +347,7 @@ following config, in addition to the configs listed above for capsule update:: CONFIG_EFI_CAPSULE_AUTHENTICATE=y +CONFIG_EFI_CAPSULE_KEY_PATH= The public and private keys used for the signing process are generated and used by the steps highlighted below. @@ -392,6 +393,9 @@ and used by the steps highlighted below. }; }; + If CONFIG_EFI_CAPSULE_KEY_PATH is specified, the build process will + take care of it for you. + Executing the boot manager ~~ diff --git a/dts/Makefile b/dts/Makefile index cb3111382959..6c5486719ecd 100644 --- a/dts/Makefile +++ b/dts/Makefile @@ -20,11 +20,30 @@ $(obj)/dt-$(SPL_NAME).dtb: dts/dt.dtb $(objtree)/tools/fdtgrep FORCE mkdir -p $(dir $@) $(call if_changed,fdtgrep) +quiet_cmd_fdtsig = FDTSIG $@ + cmd_fdtsig = \ + cat $< > $@; \ + $(srctree)/tools/fdtsig.sh \ + $(patsubst "%",%,$(CONFIG_EFI_CAPSULE_KEY_PATH)) $@ + +ifeq ($(CONFIG_EFI_CAPSULE_AUTHENTICATE),y) +ifneq ($(patsubst "%",%,$(CONFIG_EFI_CAPSULE_KEY_PATH)),) +DTB_ov := $(obj)/dt.dtb_ov + +$(obj)/dt.dtb_ov: $(DTB) FORCE + $(call if_changed,fdtsig) +else +DTB_ov := $(DTB) +endif +else +DTB_ov := $(DTB) +endif + ifeq ($(CONFIG_OF_DTB_PROPS_REMOVE),y) -$(obj)/dt.dtb: $(DTB) $(objtree)/tools/fdtgrep FORCE +$(obj)/dt.dtb: $(DTB_ov) $(objtree)/tools/fdtgrep FORCE $(call if_changed,fdt_rm_props) else -$(obj)/dt.dtb: $(DTB) FORCE +$(obj)/dt.dtb: $(DTB_ov) FORCE $(call if_changed,shipped) endif diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index 52f71c07c991..d12b1e56ae80 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -208,6 +208,13 @@ config EFI_CAPSULE_AUTHENTICATE Select this option if you want to enable capsule authentication +config EFI_CAPSULE_KEY_PATH + string "Path to .esl cert for capsule authentication" + depends on EFI_CAPSULE_AUTHENTICATE + help + Provide the EFI signature list (esl) certificate used for capsule + authentication + config EFI_DEVICE_PATH_TO_TEXT bool "Device path to text protocol" default y -- 2.33.0
[PATCH v6 10/12] test/py: efi_capsule: check the results in case of CAPSULE_AUTHENTICATE
Before the capsule authentication is supported, this test script works
correctly, but with the feature enabled, most tests will fail due to
unsigned capsules.
So check the results depending on CAPSULE_AUTHENTICATE or not.
Signed-off-by: AKASHI Takahiro
---
.../test_efi_capsule/test_capsule_firmware.py | 26 ---
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/test/py/tests/test_efi_capsule/test_capsule_firmware.py
b/test/py/tests/test_efi_capsule/test_capsule_firmware.py
index 9cc973560fa1..6e803f699f2f 100644
--- a/test/py/tests/test_efi_capsule/test_capsule_firmware.py
+++ b/test/py/tests/test_efi_capsule/test_capsule_firmware.py
@@ -148,6 +148,8 @@ class TestEfiCapsuleFirmwareFit(object):
capsule_early = u_boot_config.buildconfig.get(
'config_efi_capsule_on_disk_early')
+capsule_auth = u_boot_config.buildconfig.get(
+'config_efi_capsule_authenticate')
with u_boot_console.log.section('Test Case 2-b, after reboot'):
if not capsule_early:
# make sure that dfu_alt_info exists even persistent variables
@@ -171,12 +173,18 @@ class TestEfiCapsuleFirmwareFit(object):
'sf probe 0:0',
'sf read 400 10 10',
'md.b 400 10'])
-assert 'u-boot:New' in ''.join(output)
+if capsule_auth:
+assert 'u-boot:Old' in ''.join(output)
+else:
+assert 'u-boot:New' in ''.join(output)
output = u_boot_console.run_command_list([
'sf read 400 15 10',
'md.b 400 10'])
-assert 'u-boot-env:New' in ''.join(output)
+if capsule_auth:
+assert 'u-boot-env:Old' in ''.join(output)
+else:
+assert 'u-boot-env:New' in ''.join(output)
def test_efi_capsule_fw3(
self, u_boot_config, u_boot_console, efi_capsule_data):
@@ -215,6 +223,8 @@ class TestEfiCapsuleFirmwareFit(object):
capsule_early = u_boot_config.buildconfig.get(
'config_efi_capsule_on_disk_early')
+capsule_auth = u_boot_config.buildconfig.get(
+'config_efi_capsule_authenticate')
with u_boot_console.log.section('Test Case 3-b, after reboot'):
if not capsule_early:
# make sure that dfu_alt_info exists even persistent variables
@@ -246,7 +256,10 @@ class TestEfiCapsuleFirmwareFit(object):
'sf probe 0:0',
'sf read 400 10 10',
'md.b 400 10'])
-assert 'u-boot:New' in ''.join(output)
+if capsule_auth:
+assert 'u-boot:Old' in ''.join(output)
+else:
+assert 'u-boot:New' in ''.join(output)
def test_efi_capsule_fw4(
self, u_boot_config, u_boot_console, efi_capsule_data):
@@ -285,6 +298,8 @@ class TestEfiCapsuleFirmwareFit(object):
capsule_early = u_boot_config.buildconfig.get(
'config_efi_capsule_on_disk_early')
+capsule_auth = u_boot_config.buildconfig.get(
+'config_efi_capsule_authenticate')
with u_boot_console.log.section('Test Case 4-b, after reboot'):
if not capsule_early:
# make sure that dfu_alt_info exists even persistent variables
@@ -313,4 +328,7 @@ class TestEfiCapsuleFirmwareFit(object):
'sf probe 0:0',
'sf read 400 10 10',
'md.b 400 10'])
-assert 'u-boot:New' in ''.join(output)
+if capsule_auth:
+assert 'u-boot:Old' in ''.join(output)
+else:
+assert 'u-boot:New' in ''.join(output)
--
2.33.0
[PATCH v6 11/12] (RFC) tools: add fdtsig.sh
With this script, a public key is added to a device tree blob
as the default efi_get_public_key_data() expects.
Signed-off-by: AKASHI Takahiro
---
MAINTAINERS | 1 +
tools/fdtsig.sh | 40
2 files changed, 41 insertions(+)
create mode 100755 tools/fdtsig.sh
diff --git a/MAINTAINERS b/MAINTAINERS
index 569332db4719..860f58ef6640 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -738,6 +738,7 @@ F: cmd/bootefi.c
F: cmd/efidebug.c
F: cmd/nvedit_efi.c
F: tools/efivar.py
+F: tools/fdtsig.sh
F: tools/file2include.c
F: tools/mkeficapsule.c
diff --git a/tools/fdtsig.sh b/tools/fdtsig.sh
new file mode 100755
index ..c2b2a6dc5ec8
--- /dev/null
+++ b/tools/fdtsig.sh
@@ -0,0 +1,40 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0+
+#
+# script to add a certificate (efi-signature-list) to dtb blob
+
+usage() {
+ if [ -n "$*" ]; then
+ echo "ERROR: $*"
+ fi
+ echo "Usage: "$(basename $0) " "
+}
+
+if [ "$#" -ne 2 ]; then
+ usage "Arguments missing"
+ exit 1
+fi
+
+ESL=$1
+DTB=$2
+NEW_DTB=$(basename $DTB)_tmp
+SIG=signature
+
+cat << 'EOF' > $SIG.dts
+/dts-v1/;
+/plugin/;
+
+&{/} {
+signature {
+EOF
+echo "capsule-key = /incbin/(\"$ESL\");" >> $SIG.dts
+cat << 'EOF' >> $SIG.dts
+};
+};
+EOF
+
+dtc -@ -I dts -O dtb -o $SIG.dtbo $SIG.dts
+fdtoverlay -i $DTB -o $NEW_DTB $SIG.dtbo
+mv $NEW_DTB $DTB
+
+rm $SIG.dts $SIG.dtsn $SIG.dtbo
--
2.33.0
[PATCH v6 07/12] tools: mkeficapsule: allow for specifying GUID explicitly
The existing options, "--fit" and "--raw," are only used to put a proper
GUID in a capsule header, where GUID identifies a particular FMP (Firmware
Management Protocol) driver which then would handle the firmware binary in
a capsule. In fact, mkeficapsule does the exact same job in creating
a capsule file whatever the firmware binary type is.
To prepare for the future extension, the command syntax will be a bit
modified to allow users to specify arbitrary GUID for their own FMP driver.
OLD:
[--fit | --raw ]
NEW:
[--fit | --raw | --guid ]
Signed-off-by: AKASHI Takahiro
---
doc/develop/uefi/uefi.rst | 4 +-
doc/mkeficapsule.1| 26 +
tools/mkeficapsule.c | 78 ++-
3 files changed, 81 insertions(+), 27 deletions(-)
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index 864d61734bee..54fefd76f0f5 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -367,8 +367,8 @@ and used by the steps highlighted below.
--private-key CRT.key \
--certificate CRT.crt \
--index 1 --instance 0 \
- [--fit | --raw ] \
-
+ [--fit | --raw | --guid
4. Insert the signature list into a device tree in the following format::
diff --git a/doc/mkeficapsule.1 b/doc/mkeficapsule.1
index 837e09ab451e..312e8a8b3188 100644
--- a/doc/mkeficapsule.1
+++ b/doc/mkeficapsule.1
@@ -5,7 +5,7 @@ mkeficapsule \- Generate EFI capsule file for U-Boot
.SH SYNOPSIS
.B mkeficapsule
-.RB [\fIoptions\fP] " \fIcapsule-file\fP"
+.RB [\fIoptions\fP] " \fIimage-blob\fP \fIcapsule-file\fP"
.SH "DESCRIPTION"
The
@@ -21,7 +21,7 @@ Optionally, a capsule file can be signed with a given private
key.
In this case, the update will be authenticated by verifying the signature
before applying.
-\fBmkeficapsule\fP supports two different format of image files:
+\fBmkeficapsule\fP takes any type of image files, including:
.TP
.I raw image
format is a single binary blob of any type of firmware.
@@ -33,16 +33,28 @@ is the same as used in the new \fIuImage\fP format and
allows for
multiple binary blobs in a single capsule file.
This type of image file can be generated by \fBmkimage\fP.
+.PP
+If you want to use other types than above two, you should explicitly
+specify a guid for the FMP driver.
+
.SH "OPTIONS"
-One of \fB--fit\fP or \fB--raw\fP option must be specified.
+One of \fB--fit\fP, \fB--raw\fP or \fB--guid\fP option must be specified.
.TP
-.BI "-f, --fit \fIfit-image-file\fP"
-Specify a FIT image file
+.BI "-f, --fit
+Indicate that the blob is a FIT image file
.TP
-.BI "-r, --raw \fIraw-image-file\fP"
-Specify a raw image file
+.BI "-r, --raw
+Indicate that the blob is a raw image file
+
+.TP
+.BI "-g, --guid \fIguid-string\fP"
+Specify guid for image blob type. The format is:
+----
+
+The first three elements are in little endian, while the rest
+is in big endian.
.TP
.BI "-i, --index \fIindex\fP"
diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
index 086757ee8ad7..94c640bbddce 100644
--- a/tools/mkeficapsule.c
+++ b/tools/mkeficapsule.c
@@ -14,7 +14,7 @@
#include
#include
-
+#include
#include
#ifdef CONFIG_TOOLS_LIBCRYPTO
#include
@@ -51,14 +51,15 @@ efi_guid_t efi_guid_image_type_uboot_raw =
efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;
#ifdef CONFIG_TOOLS_LIBCRYPTO
-static const char *opts_short = "f:r:i:I:v:p:c:m:dh";
+static const char *opts_short = "frg:i:I:v:p:c:m:dh";
#else
-static const char *opts_short = "f:r:i:I:v:h";
+static const char *opts_short = "frg:i:I:v:h";
#endif
static struct option options[] = {
- {"fit", required_argument, NULL, 'f'},
- {"raw", required_argument, NULL, 'r'},
+ {"fit", no_argument, NULL, 'f'},
+ {"raw", no_argument, NULL, 'r'},
+ {"guid", required_argument, NULL, 'g'},
{"index", required_argument, NULL, 'i'},
{"instance", required_argument, NULL, 'I'},
#ifdef CONFIG_TOOLS_LIBCRYPTO
@@ -73,11 +74,12 @@ static struct option options[] = {
static void print_usage(void)
{
- printf("Usage: %s [options] \n"
+ printf("Usage: %s [options] \n"
"Options:\n"
- "\t-f, --fitnew FIT image file\n"
- "\t-r, --rawnew raw image file\n"
+ "\t-f, --fit FIT image type\n"
+ "\t-r, --raw raw image type\n"
+ "\t-g, --guid guid for image blob type\n"
"\t-i, --index update image index\n"
"\t-I, --instanceupdate hardware instance\n"
#ifdef CONFIG_TOOLS_LIBCRYPTO
@@ -572,6 +574,37 @@ err:
return ret;
}
+/**
+ * convert_uuid_to_guid() - convert uuid string to guid string
+ * @buf: String for UUID
+ *
+ * UUID and GUID have the same data structure, but their string
+ * formats are different due to the endianness. See lib/uuid.c.
+ *
[PATCH v6 09/12] test/py: efi_capsule: add a test for "--guid" option
This test scenario tests a new feature of mkeficapsule, "--guid" option,
which allows us to specify FMP driver's guid explicitly at the command
line.
Signed-off-by: AKASHI Takahiro
---
test/py/tests/test_efi_capsule/conftest.py| 3 +
.../test_efi_capsule/test_capsule_firmware.py | 67 +++
2 files changed, 70 insertions(+)
diff --git a/test/py/tests/test_efi_capsule/conftest.py
b/test/py/tests/test_efi_capsule/conftest.py
index a5a25c53dcb4..9076087a12b7 100644
--- a/test/py/tests/test_efi_capsule/conftest.py
+++ b/test/py/tests/test_efi_capsule/conftest.py
@@ -86,6 +86,9 @@ def efi_capsule_data(request, u_boot_config):
check_call('cd %s; %s/tools/mkeficapsule --index 1 --raw
u-boot.bin.new Test02' %
(data_dir, u_boot_config.build_dir),
shell=True)
+check_call('cd %s; %s/tools/mkeficapsule --index 1 --guid
E2BB9C06-70E9-4B14-97A3-5A7913176E3F u-boot.bin.new Test03' %
+ (data_dir, u_boot_config.build_dir),
+ shell=True)
if capsule_auth_enabled:
# firmware signed with proper key
check_call('cd %s; '
diff --git a/test/py/tests/test_efi_capsule/test_capsule_firmware.py
b/test/py/tests/test_efi_capsule/test_capsule_firmware.py
index 9eeaae27d626..9cc973560fa1 100644
--- a/test/py/tests/test_efi_capsule/test_capsule_firmware.py
+++ b/test/py/tests/test_efi_capsule/test_capsule_firmware.py
@@ -247,3 +247,70 @@ class TestEfiCapsuleFirmwareFit(object):
'sf read 400 10 10',
'md.b 400 10'])
assert 'u-boot:New' in ''.join(output)
+
+def test_efi_capsule_fw4(
+self, u_boot_config, u_boot_console, efi_capsule_data):
+"""
+Test Case 4 - Test "--guid" option of mkeficapsule
+ The test scenario is the same as Case 3.
+"""
+disk_img = efi_capsule_data
+with u_boot_console.log.section('Test Case 4-a, before reboot'):
+output = u_boot_console.run_command_list([
+'host bind 0 %s' % disk_img,
+'efidebug boot add -b 1 TEST host 0:1 /helloworld.efi -s ""',
+'efidebug boot order 1',
+'env set -e -nv -bs -rt OsIndications =0x0004',
+'env set dfu_alt_info "sf 0:0=u-boot-bin raw 0x10
0x5;u-boot-env raw 0x15 0x20"',
+'env save'])
+
+# initialize content
+output = u_boot_console.run_command_list([
+'sf probe 0:0',
+'fatload host 0:1 400 %s/u-boot.bin.old' %
CAPSULE_DATA_DIR,
+'sf write 400 10 10',
+'sf read 500 10 10',
+'md.b 500 10'])
+assert 'Old' in ''.join(output)
+
+# place a capsule file
+output = u_boot_console.run_command_list([
+'fatload host 0:1 400 %s/Test03' % CAPSULE_DATA_DIR,
+'fatwrite host 0:1 400 %s/Test03 $filesize' %
CAPSULE_INSTALL_DIR,
+'fatls host 0:1 %s' % CAPSULE_INSTALL_DIR])
+assert 'Test03' in ''.join(output)
+
+# reboot
+u_boot_console.restart_uboot()
+
+capsule_early = u_boot_config.buildconfig.get(
+'config_efi_capsule_on_disk_early')
+with u_boot_console.log.section('Test Case 4-b, after reboot'):
+if not capsule_early:
+# make sure that dfu_alt_info exists even persistent variables
+# are not available.
+output = u_boot_console.run_command_list([
+'env set dfu_alt_info "sf 0:0=u-boot-bin raw 0x10
0x5;u-boot-env raw 0x15 0x20"',
+'host bind 0 %s' % disk_img,
+'fatls host 0:1 %s' % CAPSULE_INSTALL_DIR])
+assert 'Test03' in ''.join(output)
+
+# need to run uefi command to initiate capsule handling
+output = u_boot_console.run_command(
+'env print -e Capsule')
+
+output = u_boot_console.run_command_list(['efidebug capsule esrt'])
+
+# ensure that EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID is in the
ESRT.
+assert 'E2BB9C06-70E9-4B14-97A3-5A7913176E3F' in ''.join(output)
+
+output = u_boot_console.run_command_list([
+'host bind 0 %s' % disk_img,
+'fatls host 0:1 %s' % CAPSULE_INSTALL_DIR])
+assert 'Test03' not in ''.join(output)
+
+output = u_boot_console.run_command_list([
+'sf probe 0:0',
+'sf read 400 10 10',
+'md.b 400 10'])
+assert 'u-boot:New' in ''.join(output)
--
2.33.0
[PATCH v6 08/12] test/py: efi_capsule: align with the syntax change of mkeficapsule
Since the syntax of mkeficapsule was changed in the previous commit,
we need to modify command line arguments in a pytest script.
Signed-off-by: AKASHI Takahiro
---
test/py/tests/test_efi_capsule/conftest.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/test/py/tests/test_efi_capsule/conftest.py
b/test/py/tests/test_efi_capsule/conftest.py
index 27c05971ca32..a5a25c53dcb4 100644
--- a/test/py/tests/test_efi_capsule/conftest.py
+++ b/test/py/tests/test_efi_capsule/conftest.py
@@ -80,10 +80,10 @@ def efi_capsule_data(request, u_boot_config):
check_call('cd %s; %s/tools/mkimage -f uboot_bin_env.its
uboot_bin_env.itb' %
(data_dir, u_boot_config.build_dir),
shell=True)
-check_call('cd %s; %s/tools/mkeficapsule --fit uboot_bin_env.itb
--index 1 Test01' %
+check_call('cd %s; %s/tools/mkeficapsule --index 1 --fit
uboot_bin_env.itb Test01' %
(data_dir, u_boot_config.build_dir),
shell=True)
-check_call('cd %s; %s/tools/mkeficapsule --raw u-boot.bin.new --index
1 Test02' %
+check_call('cd %s; %s/tools/mkeficapsule --index 1 --raw
u-boot.bin.new Test02' %
(data_dir, u_boot_config.build_dir),
shell=True)
if capsule_auth_enabled:
--
2.33.0
[PATCH v6 06/12] test/py: efi_capsule: add image authentication test
Add a couple of test cases against capsule image authentication
for capsule-on-disk, where only a signed capsule file with the verified
signature will be applied to the system.
Due to the difficulty of embedding a public key (esl file) in U-Boot
binary during pytest setup time, all the keys/certificates are pre-created.
Signed-off-by: AKASHI Takahiro
---
.../py/tests/test_efi_capsule/capsule_defs.py | 5 +
test/py/tests/test_efi_capsule/conftest.py| 52 +++-
test/py/tests/test_efi_capsule/signature.dts | 10 +
.../test_capsule_firmware_signed.py | 254 ++
4 files changed, 318 insertions(+), 3 deletions(-)
create mode 100644 test/py/tests/test_efi_capsule/signature.dts
create mode 100644
test/py/tests/test_efi_capsule/test_capsule_firmware_signed.py
diff --git a/test/py/tests/test_efi_capsule/capsule_defs.py
b/test/py/tests/test_efi_capsule/capsule_defs.py
index 4fd6353c2040..aa9bf5eee3aa 100644
--- a/test/py/tests/test_efi_capsule/capsule_defs.py
+++ b/test/py/tests/test_efi_capsule/capsule_defs.py
@@ -3,3 +3,8 @@
# Directories
CAPSULE_DATA_DIR = '/EFI/CapsuleTestData'
CAPSULE_INSTALL_DIR = '/EFI/UpdateCapsule'
+
+# v1.5.1 or earlier of efitools has a bug in sha256 calculation, and
+# you need build a newer version on your own.
+# The path must terminate with '/'.
+EFITOOLS_PATH = ''
diff --git a/test/py/tests/test_efi_capsule/conftest.py
b/test/py/tests/test_efi_capsule/conftest.py
index 6ad5608cd71c..27c05971ca32 100644
--- a/test/py/tests/test_efi_capsule/conftest.py
+++ b/test/py/tests/test_efi_capsule/conftest.py
@@ -10,13 +10,13 @@ import pytest
from capsule_defs import *
#
-# Fixture for UEFI secure boot test
+# Fixture for UEFI capsule test
#
-
@pytest.fixture(scope='session')
def efi_capsule_data(request, u_boot_config):
-"""Set up a file system to be used in UEFI capsule test.
+"""Set up a file system to be used in UEFI capsule and
+ authentication test.
Args:
request: Pytest request object.
@@ -40,6 +40,36 @@ def efi_capsule_data(request, u_boot_config):
check_call('mkdir -p %s' % data_dir, shell=True)
check_call('mkdir -p %s' % install_dir, shell=True)
+capsule_auth_enabled = u_boot_config.buildconfig.get(
+'config_efi_capsule_authenticate')
+if capsule_auth_enabled:
+# Create private key (SIGNER.key) and certificate (SIGNER.crt)
+check_call('cd %s; '
+ 'openssl req -x509 -sha256 -newkey rsa:2048 '
+'-subj /CN=TEST_SIGNER/ -keyout SIGNER.key '
+'-out SIGNER.crt -nodes -days 365'
+ % data_dir, shell=True)
+check_call('cd %s; %scert-to-efi-sig-list SIGNER.crt SIGNER.esl'
+ % (data_dir, EFITOOLS_PATH), shell=True)
+
+# Update dtb adding capsule certificate
+check_call('cd %s; '
+ 'cp %s/test/py/tests/test_efi_capsule/signature.dts .'
+ % (data_dir, u_boot_config.source_dir), shell=True)
+check_call('cd %s; '
+ 'dtc -@ -I dts -O dtb -o signature.dtbo signature.dts; '
+ 'fdtoverlay -i %s/arch/sandbox/dts/test.dtb '
+'-o test_sig.dtb signature.dtbo'
+ % (data_dir, u_boot_config.build_dir), shell=True)
+
+# Create *malicious* private key (SIGNER2.key) and certificate
+# (SIGNER2.crt)
+check_call('cd %s; '
+ 'openssl req -x509 -sha256 -newkey rsa:2048 '
+'-subj /CN=TEST_SIGNER/ -keyout SIGNER2.key '
+'-out SIGNER2.crt -nodes -days 365'
+ % data_dir, shell=True)
+
# Create capsule files
# two regions: one for u-boot.bin and the other for u-boot.env
check_call('cd %s; echo -n u-boot:Old > u-boot.bin.old; echo -n
u-boot:New > u-boot.bin.new; echo -n u-boot-env:Old -> u-boot.env.old; echo -n
u-boot-env:New > u-boot.env.new' % data_dir,
@@ -56,6 +86,22 @@ def efi_capsule_data(request, u_boot_config):
check_call('cd %s; %s/tools/mkeficapsule --raw u-boot.bin.new --index
1 Test02' %
(data_dir, u_boot_config.build_dir),
shell=True)
+if capsule_auth_enabled:
+# firmware signed with proper key
+check_call('cd %s; '
+ '%s/tools/mkeficapsule --index 1 --monotonic-count 1 '
+'--private-key SIGNER.key --certificate SIGNER.crt
'
+'--raw u-boot.bin.new Test11'
+ % (data_dir, u_boot_config.build_dir),
+ shell=True)
+# firmware signed with *mal* key
+check_call('cd %s; '
+ '%s/tools/mkeficapsule --index 1 --monotonic-count 1 '
+
[PATCH v6 03/12] tools: mkeficapsule: add firmwware image signing
With this enhancement, mkeficapsule will be able to sign a capsule
file when it is created. A signature added will be used later
in the verification at FMP's SetImage() call.
To do that, We need specify additional command parameters:
-monotonic-cout : monotonic count
-private-key : private key file
-certificate : certificate file
Only when all of those parameters are given, a signature will be added
to a capsule file.
Users are expected to maintain and increment the monotonic count at
every time of the update for each firmware image.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Simon Glass
---
tools/Kconfig| 8 +
tools/Makefile | 8 +-
tools/mkeficapsule.c | 382 ---
3 files changed, 376 insertions(+), 22 deletions(-)
diff --git a/tools/Kconfig b/tools/Kconfig
index 91ce8ae3e516..117c921da3fe 100644
--- a/tools/Kconfig
+++ b/tools/Kconfig
@@ -90,4 +90,12 @@ config TOOLS_SHA512
help
Enable SHA512 support in the tools builds
+config TOOLS_MKEFICAPSULE
+ bool "Build efimkcapsule command"
+ default y if EFI_CAPSULE_ON_DISK
+ help
+ This command allows users to create a UEFI capsule file and,
+ optionally sign that file. If you want to enable UEFI capsule
+ update feature on your target, you certainly need this.
+
endmenu
diff --git a/tools/Makefile b/tools/Makefile
index b45219e2c30c..5a73cc4b363d 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -238,8 +238,12 @@ hostprogs-$(CONFIG_MIPS) += mips-relocs
hostprogs-$(CONFIG_ASN1_COMPILER) += asn1_compiler
HOSTCFLAGS_asn1_compiler.o = -idirafter $(srctree)/include
-mkeficapsule-objs := mkeficapsule.o $(LIBFDT_OBJS)
-hostprogs-$(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) += mkeficapsule
+HOSTLDLIBS_mkeficapsule += -luuid
+ifeq ($(CONFIG_TOOLS_LIBCRYPTO),y)
+HOSTLDLIBS_mkeficapsule += \
+ $(shell pkg-config --libs libssl libcrypto 2> /dev/null || echo "-lssl
-lcrypto")
+endif
+hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
# We build some files with extra pedantic flags to try to minimize things
# that won't build on some weird host compiler -- though there are lots of
diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
index 8427fedd941c..086757ee8ad7 100644
--- a/tools/mkeficapsule.c
+++ b/tools/mkeficapsule.c
@@ -15,6 +15,16 @@
#include
#include
+#include
+#ifdef CONFIG_TOOLS_LIBCRYPTO
+#include
+#include
+#include
+#include
+#include
+#include
+#endif
+
typedef __u8 u8;
typedef __u16 u16;
typedef __u32 u32;
@@ -38,12 +48,25 @@ efi_guid_t efi_guid_image_type_uboot_fit =
EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID;
efi_guid_t efi_guid_image_type_uboot_raw =
EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID;
+efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;
+
+#ifdef CONFIG_TOOLS_LIBCRYPTO
+static const char *opts_short = "f:r:i:I:v:p:c:m:dh";
+#else
+static const char *opts_short = "f:r:i:I:v:h";
+#endif
static struct option options[] = {
{"fit", required_argument, NULL, 'f'},
{"raw", required_argument, NULL, 'r'},
{"index", required_argument, NULL, 'i'},
{"instance", required_argument, NULL, 'I'},
+#ifdef CONFIG_TOOLS_LIBCRYPTO
+ {"private-key", required_argument, NULL, 'p'},
+ {"certificate", required_argument, NULL, 'c'},
+ {"monotonic-count", required_argument, NULL, 'm'},
+ {"dump-sig", no_argument, NULL, 'd'},
+#endif
{"help", no_argument, NULL, 'h'},
{NULL, 0, NULL, 0},
};
@@ -57,10 +80,252 @@ static void print_usage(void)
"\t-r, --rawnew raw image file\n"
"\t-i, --index update image index\n"
"\t-I, --instanceupdate hardware instance\n"
+#ifdef CONFIG_TOOLS_LIBCRYPTO
+ "\t-p, --private-key private key file\n"
+ "\t-c, --certificate signer's certificate file\n"
+ "\t-m, --monotonic-count monotonic count\n"
+ "\t-d, --dump_sig dump signature (*.p7)\n"
+#endif
"\t-h, --help print a help message\n",
tool_name);
}
+/**
+ * auth_context - authentication context
+ * @key_file: Path to a private key file
+ * @cert_file: Path to a certificate file
+ * @image_data:Pointer to firmware data
+ * @image_size:Size of firmware data
+ * @auth: Authentication header
+ * @sig_data: Signature data
+ * @sig_size: Size of signature data
+ *
+ * Data structure used in create_auth_data(). @key_file through
+ * @image_size are input parameters. @auth, @sig_data and @sig_size
+ * are filled in by create_auth_data().
+ */
+struct auth_context {
+ char *key_file;
+ char *cert_file;
+ u8 *image_data;
+ size_t image_size;
+ struct efi_firmware_image_authentication auth;
+ u8 *sig_data;
+ size_t sig_size;
+};
+
+static int dump_sig;
+
+#ifdef
[PATCH v6 05/12] doc: update UEFI document for usage of mkeficapsule
Now we can use mkeficapsule command instead of EDK-II's script to create a signed capsule file. So update the instruction for capsule authentication. Signed-off-by: AKASHI Takahiro Reviewed-by: Simon Glass --- doc/develop/uefi/uefi.rst | 143 ++ 1 file changed, 67 insertions(+), 76 deletions(-) diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst index f17138f5c765..864d61734bee 100644 --- a/doc/develop/uefi/uefi.rst +++ b/doc/develop/uefi/uefi.rst @@ -284,37 +284,52 @@ Support has been added for the UEFI capsule update feature which enables updating the U-Boot image using the UEFI firmware management protocol (FMP). The capsules are not passed to the firmware through the UpdateCapsule runtime service. Instead, capsule-on-disk -functionality is used for fetching the capsule from the EFI System -Partition (ESP) by placing the capsule file under the -\EFI\UpdateCapsule directory. - -The directory \EFI\UpdateCapsule is checked for capsules only within the -EFI system partition on the device specified in the active boot option -determined by reference to BootNext variable or BootOrder variable processing. -The active Boot Variable is the variable with highest priority BootNext or -within BootOrder that refers to a device found to be present. Boot variables -in BootOrder but referring to devices not present are ignored when determining -active boot variable. -Before starting a capsule update make sure your capsules are installed in the -correct ESP partition or set BootNext. +functionality is used for fetching capsules from the EFI System +Partition (ESP) by placing capsule files under the directory:: + +\EFI\UpdateCapsule + +The directory is checked for capsules only within the +EFI system partition on the device specified in the active boot option, +which is determined by Boot variable in BootNext, or if not, the highest +priority one within BootOrder. Any Boot variables referring to devices +not present are ignored when determining the active boot option. + +Please note that capsules will be applied in the alphabetic order of +capsule file names. + +Creating a capsule file +*** + +A capsule file can be created by using tools/mkeficapsule. +To build this tool, enable:: + +CONFIG_TOOLS_MKEFICAPSULE=y +CONFIG_TOOLS_LIBCRYPTO=y + +Run the following command:: + +$ mkeficapsule \ + --index 1 --instance 0 \ + [--fit | --raw ] \ + Performing the update * -Since U-boot doesn't currently support SetVariable at runtime there's a Kconfig -option (CONFIG_EFI_IGNORE_OSINDICATIONS) to disable the OsIndications variable -check. If that option is enabled just copy your capsule to \EFI\UpdateCapsule. - -If that option is disabled, you'll need to set the OsIndications variable with:: +Put capsule files under the directory mentioned above. +Then, following the UEFI specification, you'll need to set +the EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED +bit in OsIndications variable with:: => setenv -e -nv -bs -rt -v OsIndications =0x04 -Finally, the capsule update can be initiated either by rebooting the board, -which is the preferred method, or by issuing the following command:: +Since U-boot doesn't currently support SetVariable at runtime, its value +won't be taken over across the reboot. If this is the case, you can skip +this feature check with the Kconfig option (CONFIG_EFI_IGNORE_OSINDICATIONS) +set. -=> efidebug capsule disk-update - -**The efidebug command is should only be used during debugging/development.** +Finally, the capsule update can be initiated by rebooting the board. Enabling Capsule Authentication *** @@ -324,82 +339,58 @@ be updated by verifying the capsule signature. The capsule signature is computed and prepended to the capsule payload at the time of capsule generation. This signature is then verified by using the public key stored as part of the X509 certificate. This certificate is -in the form of an efi signature list (esl) file, which is embedded as -part of U-Boot. +in the form of an efi signature list (esl) file, which is embedded in +a device tree. The capsule authentication feature can be enabled through the following config, in addition to the configs listed above for capsule update:: CONFIG_EFI_CAPSULE_AUTHENTICATE=y -CONFIG_EFI_CAPSULE_KEY_PATH= The public and private keys used for the signing process are generated -and used by the steps highlighted below:: +and used by the steps highlighted below. -1. Install utility commands on your host - * OPENSSL +1. Install utility commands on your host + * openssl * efitools -2. Create signing keys and certificate files on your host +2. Create signing keys and certificate files on your host:: $ openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=CRT/ \ -keyout CRT.key -out CRT.crt
[PATCH v6 04/12] tools: mkeficapsule: add man page
Add a man page for mkeficapsule command. Signed-off-by: AKASHI Takahiro Reviewed-by: Simon Glass --- MAINTAINERS| 1 + doc/mkeficapsule.1 | 95 ++ 2 files changed, 96 insertions(+) create mode 100644 doc/mkeficapsule.1 diff --git a/MAINTAINERS b/MAINTAINERS index 9d8cba902800..569332db4719 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -718,6 +718,7 @@ S: Maintained T: git https://source.denx.de/u-boot/custodians/u-boot-efi.git F: doc/api/efi.rst F: doc/develop/uefi/* +F: doc/mkeficapsule.1 F: doc/usage/bootefi.rst F: drivers/rtc/emul_rtc.c F: include/capitalization.h diff --git a/doc/mkeficapsule.1 b/doc/mkeficapsule.1 new file mode 100644 index ..837e09ab451e --- /dev/null +++ b/doc/mkeficapsule.1 @@ -0,0 +1,95 @@ +.TH MAEFICAPSULE 1 "May 2021" + +.SH NAME +mkeficapsule \- Generate EFI capsule file for U-Boot + +.SH SYNOPSIS +.B mkeficapsule +.RB [\fIoptions\fP] " \fIcapsule-file\fP" + +.SH "DESCRIPTION" +The +\fBmkeficapsule\fP +command is used to create an EFI capsule file for use with the U-Boot +EFI capsule update. +A capsule file may contain various type of firmware blobs which +are to be applied to the system and must be placed in the specific +directory on the UEFI system partition. An update will be automatically +executed at next reboot. + +Optionally, a capsule file can be signed with a given private key. +In this case, the update will be authenticated by verifying the signature +before applying. + +\fBmkeficapsule\fP supports two different format of image files: +.TP +.I raw image +format is a single binary blob of any type of firmware. + +.TP +.I FIT (Flattened Image Tree) image +format +is the same as used in the new \fIuImage\fP format and allows for +multiple binary blobs in a single capsule file. +This type of image file can be generated by \fBmkimage\fP. + +.SH "OPTIONS" +One of \fB--fit\fP or \fB--raw\fP option must be specified. + +.TP +.BI "-f, --fit \fIfit-image-file\fP" +Specify a FIT image file + +.TP +.BI "-r, --raw \fIraw-image-file\fP" +Specify a raw image file + +.TP +.BI "-i, --index \fIindex\fP" +Specify an image index + +.TP +.BI "-I, --instance \fIinstance\fP" +Specify a hardware instance + +.TP +.BI "-h, --help" +Print a help message + +.TP 0 +.B With signing: + +\fB--private-key\fP, \fB--certificate\fP and \fB--monotonic-count\fP are +all mandatory. + +.TP +.BI "-p, --private-key \fIprivate-key-file\fP" +Specify signer's private key file in PEM + +.TP +.BI "-c, --certificate \fIcertificate-file\fP" +Specify signer's certificate file in EFI certificate list format + +.TP +.BI "-m, --monotonic-count \fIcount\fP" +Specify a monotonic count which is set to be monotonically incremented +at every firmware update. + +.TP +.BI "-d, --dump_sig" +Dump signature data into *.p7 file + +.PP +.SH FILES +.TP +.BI "\fI/EFI/UpdateCapsule\fP" +The directory in which all capsule files be placed + +.SH SEE ALSO +.B mkimage + +.SH AUTHORS +Written by AKASHI Takahiro + +.SH HOMEPAGE +http://www.denx.de/wiki/U-Boot/WebHome -- 2.33.0
[PATCH v6 02/12] tools: mkeficapsule: rework the code a little bit
Abstract common routines to make the code easily understandable.
No functional change.
Signed-off-by: AKASHI Takahiro
---
tools/mkeficapsule.c | 219 ++-
1 file changed, 155 insertions(+), 64 deletions(-)
diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
index 4995ba4e0c2a..8427fedd941c 100644
--- a/tools/mkeficapsule.c
+++ b/tools/mkeficapsule.c
@@ -61,17 +61,117 @@ static void print_usage(void)
tool_name);
}
+/**
+ * read_bin_file - read a firmware binary file
+ * @bin: Path to a firmware binary file
+ * @data: Pointer to pointer of allocated buffer
+ * @bin_size: Size of allocated buffer
+ *
+ * Read out a content of binary, @bin, into @data.
+ * A caller should free @data.
+ *
+ * Return:
+ * * 0 - on success
+ * * -1 - on failure
+ */
+static int read_bin_file(char *bin, void **data, off_t *bin_size)
+{
+ FILE *g;
+ struct stat bin_stat;
+ void *buf;
+ size_t size;
+ int ret = 0;
+
+ g = fopen(bin, "r");
+ if (!g) {
+ printf("cannot open %s\n", bin);
+ return -1;
+ }
+ if (stat(bin, _stat) < 0) {
+ printf("cannot determine the size of %s\n", bin);
+ ret = -1;
+ goto err;
+ }
+ buf = malloc(bin_stat.st_size);
+ if (!buf) {
+ printf("cannot allocate memory: %zx\n",
+ (size_t)bin_stat.st_size);
+ ret = -1;
+ goto err;
+ }
+
+ size = fread(buf, 1, bin_stat.st_size, g);
+ if (size < bin_stat.st_size) {
+ printf("read failed (%zx)\n", size);
+ ret = -1;
+ goto err;
+ }
+
+ *data = buf;
+ *bin_size = bin_stat.st_size;
+err:
+ fclose(g);
+
+ return ret;
+}
+
+/**
+ * write_capsule_file - write a capsule file
+ * @bin: FILE stream
+ * @data: Pointer to data
+ * @bin_size: Size of data
+ *
+ * Write out data, @data, with the size @bin_size.
+ *
+ * Return:
+ * * 0 - on success
+ * * -1 - on failure
+ */
+static int write_capsule_file(FILE *f, void *data, size_t size, const char
*msg)
+{
+ size_t size_written;
+
+ size_written = fwrite(data, 1, size, f);
+ if (size_written < size) {
+ printf("%s: write failed (%zx != %zx)\n", msg,
+ size_written, size);
+ return -1;
+ }
+
+ return 0;
+}
+
+/**
+ * create_fwbin - create an uefi capsule file
+ * @path: Path to a created capsule file
+ * @bin: Path to a firmware binary to encapsulate
+ * @guid: GUID of related FMP driver
+ * @index: Index number in capsule
+ * @instance: Instance number in capsule
+ * @mcount:Monotonic count in authentication information
+ * @private_file: Path to a private key file
+ * @cert_file: Path to a certificate file
+ *
+ * This function actually does the job of creating an uefi capsule file.
+ * All the arguments must be supplied.
+ * If either @private_file ror @cert_file is NULL, the capsule file
+ * won't be signed.
+ *
+ * Return:
+ * * 0 - on success
+ * * -1 - on failure
+ */
static int create_fwbin(char *path, char *bin, efi_guid_t *guid,
unsigned long index, unsigned long instance)
{
struct efi_capsule_header header;
struct efi_firmware_management_capsule_header capsule;
struct efi_firmware_management_capsule_image_header image;
- FILE *f, *g;
- struct stat bin_stat;
- u8 *data;
- size_t size;
+ FILE *f;
+ void *data;
+ off_t bin_size;
u64 offset;
+ int ret;
#ifdef DEBUG
printf("For output: %s\n", path);
@@ -79,25 +179,28 @@ static int create_fwbin(char *path, char *bin, efi_guid_t
*guid,
printf("\tindex: %ld\n\tinstance: %ld\n", index, instance);
#endif
- g = fopen(bin, "r");
- if (!g) {
- printf("cannot open %s\n", bin);
- return -1;
- }
- if (stat(bin, _stat) < 0) {
- printf("cannot determine the size of %s\n", bin);
- goto err_1;
- }
- data = malloc(bin_stat.st_size);
- if (!data) {
- printf("cannot allocate memory: %zx\n",
(size_t)bin_stat.st_size);
- goto err_1;
- }
+ f = NULL;
+ data = NULL;
+ ret = -1;
+
+ /*
+* read a firmware binary
+*/
+ if (read_bin_file(bin, , _size))
+ goto err;
+
+ /*
+* write a capsule file
+*/
f = fopen(path, "w");
if (!f) {
printf("cannot open %s\n", path);
- goto err_2;
+ goto err;
}
+
+ /*
+* capsule file header
+*/
header.capsule_guid = efi_guid_fm_capsule;
header.header_size = sizeof(header);
/* TODO: The current implementation ignores flags */
@@
[PATCH v6 01/12] efi_loader: capsule: drop __weak from efi_get_public_key_data()
As we discussed in ML, currently a device tree is the only place
to store public keys for capsule authentication. So __weak is not
necessary for now.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Simon Glass
---
lib/efi_loader/efi_capsule.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
index 44f5da61a9be..850937fd120f 100644
--- a/lib/efi_loader/efi_capsule.c
+++ b/lib/efi_loader/efi_capsule.c
@@ -256,7 +256,7 @@ out:
}
#if defined(CONFIG_EFI_CAPSULE_AUTHENTICATE)
-int __weak efi_get_public_key_data(void **pkey, efi_uintn_t *pkey_len)
+int efi_get_public_key_data(void **pkey, efi_uintn_t *pkey_len)
{
const void *fdt_blob = gd->fdt_blob;
const void *blob;
--
2.33.0
[PATCH v6 00/12] efi_loader: capsule: improve capsule authentication support
As I proposed and discussed in [1] and [2], I have made a couple of improvements on the current implementation of capsule update in this patch set. * add signing feature to mkeficapsule * add "--guid" option to mkeficapsule * add man page of mkeficapsule * update uefi document regarding capsule update * revise pytests * (as RFC) add CONFIG_EFI_CAPSULE_KEY_PATH # We have had some discussion about fdtsig.sh. # So RFCs (patch#11,#12) are still included for further discussion # if they are useful or not. # For smooth merge, the rest (patch#1-10) should work without them. [1] https://lists.denx.de/pipermail/u-boot/2021-April/447918.html [2] https://lists.denx.de/pipermail/u-boot/2021-July/455292.html Prerequisite patches None Test * locally passed the pytest which is included in this patch series on sandbox built. (CONFIG_EFI_CAPSULE_AUTHENTICATE should explicitly be turned on in order to exercise the authentication code.) Changes === v6 (Nov 02, 2021) * rebased on pre-v2022.01-rc1 * add patch#2 to rework/refactor the code for better readability (patch#2) * use exit(EXIT_SUCCESS/FAILURE) (patch#3) * truncate >80chars lines in pytest scripts (patch#6) v5 (Oct 27, 2021) * rebased on pre-v2022.01-rc1 (WIP/26Oct2021) * drop already-merged patches * drop __weak from efi_get_public_key_data() (patch#1) * describe the format of public key node in device tree (patch#4) * re-order patches by grouping closely-related patches (patch#6-8) * modify pytest to make the test results correctly verified either with or without CONFIG_EFI_CAPSULE_AUTHENTICATE (patch#9) * add RFCs for embedding public keys during the build process (patch#10,11) v4 (Oct 7, 2021) * rebased on v2021.10 * align with "Revert "efi_capsule: Move signature from DTB to .rodata"" * add more missing *revert* commits (patch#1,#2,#3) * add fdtsig.sh, replacing dtb support in mkeficapsule (patch#4) * update/revise the man/uefi doc (patch#6,#7) * fix a bug in parsing guid string (patch#8) * add a test for "--guid" option (patch#10) * use dtb-based authentication test as done in v1 (patch#11) v3 (Aug 31, 2021) * rebased on v2021.10-rc3 * remove pytest-related patches * add function descriptions in mkeficapsule.c * correct format specifiers in printf() * let main() return 0 or -1 only * update doc/develop/uefi/uefi.rst for syntax change of mkeficapsule v2 (July 28, 2021) * rebased on v2021.10-rc* * removed dependency on target's configuration * removed fdtsig.sh and others * add man page * update the UEFI document * add dedicate defconfig for testing on sandbox * add gitlab CI support * add "--guid" option to mkeficapsule (yet rather RFC) Initial release (May 12, 2021) * based on v2021.07-rc2 AKASHI Takahiro (12): efi_loader: capsule: drop __weak from efi_get_public_key_data() tools: mkeficapsule: rework the code a little bit tools: mkeficapsule: add firmwware image signing tools: mkeficapsule: add man page doc: update UEFI document for usage of mkeficapsule test/py: efi_capsule: add image authentication test tools: mkeficapsule: allow for specifying GUID explicitly test/py: efi_capsule: align with the syntax change of mkeficapsule test/py: efi_capsule: add a test for "--guid" option test/py: efi_capsule: check the results in case of CAPSULE_AUTHENTICATE (RFC) tools: add fdtsig.sh (RFC) efi_loader, dts: add public keys for capsules to device tree MAINTAINERS | 2 + doc/develop/uefi/uefi.rst | 143 ++-- doc/mkeficapsule.1| 107 +++ dts/Makefile | 23 +- lib/efi_loader/Kconfig| 7 + lib/efi_loader/efi_capsule.c | 2 +- .../py/tests/test_efi_capsule/capsule_defs.py | 5 + test/py/tests/test_efi_capsule/conftest.py| 59 +- test/py/tests/test_efi_capsule/signature.dts | 10 + .../test_efi_capsule/test_capsule_firmware.py | 91 ++- .../test_capsule_firmware_signed.py | 254 +++ tools/Kconfig | 8 + tools/Makefile| 8 +- tools/fdtsig.sh | 40 ++ tools/mkeficapsule.c | 657 +++--- 15 files changed, 1238 insertions(+), 178 deletions(-) create mode 100644 doc/mkeficapsule.1 create mode 100644 test/py/tests/test_efi_capsule/signature.dts create mode 100644 test/py/tests/test_efi_capsule/test_capsule_firmware_signed.py create mode 100755 tools/fdtsig.sh -- 2.33.0
Re: [PATCH v4] driver: spi: add bcm iproc qspi support.
Hi Jagan,
On Mon, Nov 1, 2021 at 12:12 AM Jagan Teki wrote:
>
> On Tue, Oct 26, 2021 at 1:07 AM Roman Bacik wrote:
> >
> > From: Rayagonda Kokatanur
> >
> > IPROC qspi driver supports both BSPI and MSPI modes.
> >
> > Signed-off-by: Rayagonda Kokatanur
> > Signed-off-by: Bharat Gooty
> > Acked-by: Rayagonda Kokatanur
> >
> > Signed-off-by: Roman Bacik
> > ---
> >
> > Changes in v4:
> > - move iproc_qspi.c from spi to mtd/spi
> > - remove iproc_qspi.h
> > - rename IPROC_QSPI to SPI_FLASH_IPROC
> >
> > Changes in v3:
> > - fix warning by including linux/delay.h
> > - change ofdata_to_platdata to of_to_plat
> > - change priv_auto_alloc_size to priv_auto
> >
> > Changes in v2:
> > - remove include spi-nor.h
> > - define and use named BITs for writing register values
> > - remove bspi_set_4byte_mode() method
> >
> > drivers/mtd/spi/Kconfig | 6 +
> > drivers/mtd/spi/Makefile | 1 +
> > drivers/mtd/spi/iproc_qspi.c | 718 +++
> > 3 files changed, 725 insertions(+)
> > create mode 100644 drivers/mtd/spi/iproc_qspi.c
>
> Look like you confused what I've mentioned before, your driver is
> flash specific so add a driver in UCLASS_SPI_FLASH. drivers with
> UCLASS_SPI to be in drivers/spi/
>
> Jagan.
This is a controller driver and it is currently meant to be used as follows:
qspi: spi@37 {
compatible = "brcm,iproc-qspi";
reg = <0x0037 0x100>,
<0x00370100 0x100>,
<0x00370200 0x200>;
reg-names = "bspi", "bspi_raf", "mspi";
flash-iomap-addr = /bits/ 64 <0x7000>;
#address-cells = <1>;
#size-cells = <0>;
spi_nor_flash: spi_flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <1250>;
spi-cpol;
spi-cpha;
spi-tx-bus-width = <1>;
spi-rx-bus-width = <4>;
};
};
Can you please provide more details or point us to an example we can
use as a reference when asking us to switch from UCLASS_SPI to
UCLASS_SPI_FLASH? What will the new device tree look like? Do we need
to add read/write/erase methods (likely around our existing xfer
method), which are currently not needed or is there a way around it by
reusing existing code base?
Thanks,
Roman
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
Re: rk3399-gru-kevin: issues on bringup
Hi, I've had some recent success with my gru-kevin and wanted to update you on this. Long story short, I can boot from SPI flash and have the display, keyboard, eMMC, microSD card, USB disks all work (however with some hacks); but can't boot into Linux. Things seem to hang shortly after "Starting kernel..." but I don't know if something fails in U-Boot or if I get a kernel panic. (I still have no serial console). There are three relevant branches on my GitHub repo now, please have a look. The first is for what I intend to send upstream soon enough. The other two include hacks and additional patches that build on top of the first, meant to improve things on a per-board basis: https://github.com/alpernebbi/u-boot/tree/rk3399-gru-chromebooks https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin https://github.com/alpernebbi/u-boot/tree/rk3399-gru-bob I have no idea if the gru-bob versions work. I just thought things I did for gru-kevin are applicable to it as well and decided I should include them in case anyone wants to test. I also want to ask you some things I'm indecisive about, before posting the rk3399-gru-chromebooks branch as patches. Most of the patches are small config and dts changes that I've grouped by whatever effect they have. Should I squash them into one commit each for config/dts? Simon, I've edited some of your patches and kept you as author & sign-off. Are you OK with the edited versions, am I doing things right? See: https://github.com/alpernebbi/u-boot/commit/8c658b7811f4324cd699bd035e802f9339efa8f7 https://github.com/alpernebbi/u-boot/commit/c2c68f23e10a51b8d34c00764a33fc847d785f60 https://github.com/alpernebbi/u-boot/commit/995454193906e04bfb4e0e38f2bf1a18634a1ebf Marty, your (second) chromebook_kevin support patch didn't have your sign-off. Is it OK to add it? See: https://github.com/alpernebbi/u-boot/commit/4cee351e012dc26714640e868069b5cc4b5a8329 I also think I should squash my gru-kevin changes into that commit, add a commit message about board status, and keep Marty as author & sign-off while adding myself as Co-authored-by & sign-off. Any better ideas on how to structure the patches? Do both of you want to be in /board/google/gru/MAINTAINERS? I have three of us listed there right now, but no idea if that's fine with you two. Hope you can spare time on this.
Re: [PATCH 0/3] rockchip: sdhci: Add HS400 Enhanced Strobe support
Hi,
On 11/1/21 9:16 PM, Alper Nebi Yasak wrote:
> On 01/11/2021 14:18, Jack Mitchell wrote:
>> On 01/11/2021 09:07, Alper Nebi Yasak wrote:
>>> I'm trying to make my gru-kevin's eMMC work properly (it times out while
>>> tuning for HS400 and stops working when reinitialized via "mmc dev 0").
>>
>> I'm also experiencing issue with the re-init of emmc on a 3399 platform,
>> did you come to any conclusions on the reason? It works fine to load
>> u-boot proper from SPL but then fails in u-boot proper when attempting
>> to perform any mmc activity.
>
> Not really. But I have a nice hack to keep it in a working state:
>
> diff --git a/cmd/mmc.c b/cmd/mmc.c
> index 96d81ffdf368..83bd18e34609 100644
> --- a/cmd/mmc.c
> +++ b/cmd/mmc.c
> @@ -129,10 +129,13 @@ static struct mmc *__init_mmc_device(...)
> if (!mmc) {
> printf("no mmc device at slot %x\n", dev);
> return NULL;
> }
>
> + if (mmc->cfg->host_caps & MMC_CAP_NONREMOVABLE)
> + force_init = false;
> +
I don't have rockchip board, but this code is working fine.
It seems that needs to implement a reinit callback function to clear the
previous configurations in rockchip_sdhci.c.
Best Regards,
Jaehoon Chung
> if (!mmc_getcd(mmc))
> force_init = true;
>
> if (force_init)
> mmc->has_init = 0;
>
Re: [PATCH 0/3] rockchip: sdhci: Add HS400 Enhanced Strobe support
On 01/11/2021 22:11, Peter Robinson wrote: > On Mon, Nov 1, 2021 at 11:18 AM Jack Mitchell wrote: >> >> On 01/11/2021 09:07, Alper Nebi Yasak wrote: >>> I'm trying to make my gru-kevin's eMMC work properly (it times out while >>> tuning for HS400 and stops working when reinitialized via "mmc dev 0"). >> >> I'm also experiencing issue with the re-init of emmc on a 3399 platform, >> did you come to any conclusions on the reason? It works fine to load >> u-boot proper from SPL but then fails in u-boot proper when attempting >> to perform any mmc activity. > > Does the following patch fix the rk3399 problem? > http://patchwork.ozlabs.org/project/uboot/patch/20211101044347.17822-1-yifeng.z...@rock-chips.com/ > Hi Peter, I have this patch in my tree which fixes the initial init of the emmc, but it then fails later when it is re-initialised. Does everything work fine on your Rock960, can you boot Linux from the emmc when going SPL (emmc) -> Proper (emmc) -> Linux (emmc)? Thanks for the suggestion! Regards, >> Regards, >> Jack. >> >>> While experimenting with what works on my board I ended up implementing >>> HS400ES support. And while I'm at it, I decided to do it for RK3568 as >>> well since it turned out easy enough. Both are ported from relevant >>> Linux drivers. >>> >>> I'm trying this with "load mmc 0:1 0xd000 /bigfile $size" and getting >>> the following speeds; and with "mmc info" the following differences: >>> >>> gru-kevin mmc0 | w/o this series | w/ this series >>> +---+--- >>> Bus Speed | 5200 | 2 >>> Mode| MMC High Speed (52MHz)| HS400ES (200 MHz) >>> 8MiB Load Speed | ~9.5 MiB/s| ~51.5 MiB/s >>> 256MiB Load Speed | ~177.8 MiB/s | ~114.5 MiB/s >>> >>> Listing partitions, listing files, reading files and the loaded bytes >>> all look fine to me, but I'm not sure I haven't missed anything. >>> >>> >>> Alper Nebi Yasak (3): >>> mmc: sdhci: Add HS400 Enhanced Strobe support >>> rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3399 >>> rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3568 >>> >>> drivers/mmc/rockchip_sdhci.c | 51 >>> drivers/mmc/sdhci.c | 18 + >>> include/sdhci.h | 1 + >>> 3 files changed, 70 insertions(+) >>> >> >> -- >> Jack Mitchell, Consultant >> https://www.tuxable.co.uk -- Jack Mitchell, Consultant https://www.tuxable.co.uk
Re: [PATCH 0/3] rockchip: sdhci: Add HS400 Enhanced Strobe support
On Mon, Nov 1, 2021 at 11:18 AM Jack Mitchell wrote: > > On 01/11/2021 09:07, Alper Nebi Yasak wrote: > > I'm trying to make my gru-kevin's eMMC work properly (it times out while > > tuning for HS400 and stops working when reinitialized via "mmc dev 0"). > > I'm also experiencing issue with the re-init of emmc on a 3399 platform, > did you come to any conclusions on the reason? It works fine to load > u-boot proper from SPL but then fails in u-boot proper when attempting > to perform any mmc activity. Does the following patch fix the rk3399 problem? http://patchwork.ozlabs.org/project/uboot/patch/20211101044347.17822-1-yifeng.z...@rock-chips.com/ > Regards, > Jack. > > > While experimenting with what works on my board I ended up implementing > > HS400ES support. And while I'm at it, I decided to do it for RK3568 as > > well since it turned out easy enough. Both are ported from relevant > > Linux drivers. > > > > I'm trying this with "load mmc 0:1 0xd000 /bigfile $size" and getting > > the following speeds; and with "mmc info" the following differences: > > > > gru-kevin mmc0 | w/o this series | w/ this series > > +---+--- > > Bus Speed | 5200 | 2 > > Mode| MMC High Speed (52MHz)| HS400ES (200 MHz) > > 8MiB Load Speed | ~9.5 MiB/s| ~51.5 MiB/s > > 256MiB Load Speed | ~177.8 MiB/s | ~114.5 MiB/s > > > > Listing partitions, listing files, reading files and the loaded bytes > > all look fine to me, but I'm not sure I haven't missed anything. > > > > > > Alper Nebi Yasak (3): > > mmc: sdhci: Add HS400 Enhanced Strobe support > > rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3399 > > rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3568 > > > > drivers/mmc/rockchip_sdhci.c | 51 > > drivers/mmc/sdhci.c | 18 + > > include/sdhci.h | 1 + > > 3 files changed, 70 insertions(+) > > > > -- > Jack Mitchell, Consultant > https://www.tuxable.co.uk
Re: [PATCH v2 02/41] Makefile: Allow LTO to be disabled for a build
On Sun, Oct 31, 2021 at 05:46:43PM -0600, Simon Glass wrote: > Hi Tom, > > On Wed, 27 Oct 2021 at 07:13, Tom Rini wrote: > > > > On Wed, Oct 27, 2021 at 02:21:17PM +0200, Heinrich Schuchardt wrote: > > > > > > > > > On 10/27/21 10:50, Ilias Apalodimas wrote: > > > > Hi Simon > > > > > > > > How does this patch related to the standard boot series? Shouldn't > > > > this be a completely separate patch? > > > > > > > > Thanks > > > > /Ilias > > > > > > > > On Sun, 24 Oct 2021 at 02:26, Simon Glass wrote: > > > > > > > > > > LTO (Link-Time Optimisation) is an very useful feature which can > > > > > significantly reduce the size of U-Boot binaries. So far it has been > > > > > made available for selected ARM boards and sandbox. > > > > > > > > > > However, incremental builds are much slower when LTO is used. For > > > > > example, > > > > > an incremental build of sandbox takes 2.1 seconds on my machine, but > > > > > 6.7 > > > > > seconds with LTO enabled. > > > > > > > > > > Add a LTO_BUILD=n parameter to the build, so it can be disabled during > > > > > development if needed, for faster builds. > > > > > > > > > > Add some documentation about LTO while we are here. > > > > > > > > > > Signed-off-by: Simon Glass > > > > > --- > > > > > > > > > > (no changes since v1) > > > > > > > > > > Makefile | 18 +- > > > > > arch/arm/config.mk | 4 ++-- > > > > > arch/arm/include/asm/global_data.h | 2 +- > > > > > doc/build/gcc.rst | 17 + > > > > > 4 files changed, 33 insertions(+), 8 deletions(-) > > > > > > > > > > diff --git a/Makefile b/Makefile > > > > > index b79b2319ff6..7057723e046 100644 > > > > > --- a/Makefile > > > > > +++ b/Makefile > > > > > @@ -434,6 +434,9 @@ KBUILD_CFLAGS += -fshort-wchar > > > > > -fno-strict-aliasing > > > > > KBUILD_AFLAGS := -D__ASSEMBLY__ > > > > > KBUILD_LDFLAGS := > > > > > > > > > > +# Set this to "n" use of LTO for this build, e.g. LTO_BUILD=n > > > > > +LTO_BUILD ?= y > > > > > > This does not allow LTO_BUILD=y to enable LTO for CONFIG_LTO=n. > > > > I don't understand why we need this patch at all. If you want to > > disable LTO, disable LTO. Yes, LTO makes linking take longer which can > > be annoying on iterative development. I have a few different "HACK: DO > > NOT PUSH: ..." things I git am at the start of a branch, depending on > > needs. You can just do that to drop "imply LTO" from the SANDBOX stanza > > in arch/Kconfig. We do not need a whole thing around a CONFIG option > > that can be disabled in the defconfig, or local .config file even. > > > > Cranky time. > > Of course we don't *need* it. I could just buy a slower build machine > and type with two fingers. There are lots of ways to slow things down > and LTO is one of them. I change branches at least a dozen times a day > and am always trying things out from patchwork. I am sure others do > too. LTO dramatically slows down builds. Having a way to easily do > this from the build system saves time. Maybe the answer is that LTO just isn't appropriate for sandbox. We're not doing any specific tests for LTO anywhere (nor does that seem appropriate), and we do have platforms in CI that run tests other than building, with LTO. -- Tom signature.asc Description: PGP signature
[PATCH] pinctrl: Add Apple pinctrl driver
This driver supports both pin muxing and GPIO support for the
pin control logic found on Apple SoCs.
Signed-off-by: Mark Kettenis
---
MAINTAINERS | 1 +
.../pinctrl/apple,pinctrl.yaml| 106 +
drivers/pinctrl/Kconfig | 11 +
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/pinctrl-apple.c | 207 ++
5 files changed, 326 insertions(+)
create mode 100644 doc/device-tree-bindings/pinctrl/apple,pinctrl.yaml
create mode 100644 drivers/pinctrl/pinctrl-apple.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 9d8cba9028..98eb491f60 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -115,6 +115,7 @@ F: arch/arm/include/asm/arch-m1/
F: arch/arm/mach-apple/
F: configs/apple_m1_defconfig
F: drivers/iommu/apple_dart.c
+F: drivers/pinctrl/pinctrl-apple.c
F: include/configs/apple.h
ARM
diff --git a/doc/device-tree-bindings/pinctrl/apple,pinctrl.yaml
b/doc/device-tree-bindings/pinctrl/apple,pinctrl.yaml
new file mode 100644
index 00..d50571affd
--- /dev/null
+++ b/doc/device-tree-bindings/pinctrl/apple,pinctrl.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/apple,pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Apple GPIO controller
+
+maintainers:
+ - Mark Kettenis
+
+description: |
+ The Apple GPIO controller is a simple combined pin and GPIO
+ controller present on Apple ARM SoC platforms, including various
+ iPhone and iPad devices and the "Apple Silicon" Macs.
+
+properties:
+ compatible:
+items:
+ - const: apple,t8103-pinctrl
+ - const: apple,pinctrl
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+const: 2
+
+ gpio-ranges:
+maxItems: 1
+
+ interrupts:
+description: One interrupt for each of the (up to 7) interrupt
+ groups supported by the controller sorted by interrupt group
+ number in ascending order.
+minItems: 1
+maxItems: 7
+
+ interrupt-controller: true
+
+patternProperties:
+ '-pins$':
+type: object
+$ref: pinmux-node.yaml#
+
+properties:
+ pinmux:
+description:
+ Values are constructed from pin number and alternate function
+ configuration number using the APPLE_PINMUX() helper macro
+ defined in include/dt-bindings/pinctrl/apple.h.
+
+required:
+ - pinmux
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - '#gpio-cells'
+ - gpio-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pinctrl: pinctrl@23c10 {
+compatible = "apple,t8103-pinctrl", "apple,pinctrl";
+reg = <0x2 0x3c10 0x0 0x10>;
+clocks = <_clk>;
+
+gpio-controller;
+#gpio-cells = <2>;
+gpio-ranges = < 0 0 212>;
+
+interrupt-controller;
+interrupt-parent = <>;
+interrupts = ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ;
+
+pcie_pins: pcie-pins {
+ pinmux = ,
+ ,
+ ;
+};
+ };
+};
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 30eaa376c8..cac5f2488d 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -145,6 +145,17 @@ config SPL_PINCONF_RECURSIVE
if PINCTRL || SPL_PINCTRL
+config PINCTRL_APPLE
+ bool "Apple pinctrl driver"
+ depends on DM && PINCTRL_GENERIC && ARCH_APPLE
+ default y
+ help
+ Support pin multiplexing on Apple SoCs.
+
+ The driver is controlled by a device tree node which contains
+ both the GPIO definitions and pin control functions for each
+ available multiplex function.
+
config PINCTRL_AR933X
bool "QCA/Athores ar933x pin control driver"
depends on DM && SOC_AR933X
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 05b71f2f13..fd736a7f64 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -3,6 +3,7 @@
obj-y += pinctrl-uclass.o
obj-$(CONFIG_$(SPL_)PINCTRL_GENERIC) += pinctrl-generic.o
+obj-$(CONFIG_PINCTRL_APPLE)+= pinctrl-apple.o
obj-$(CONFIG_PINCTRL_AT91) += pinctrl-at91.o
obj-$(CONFIG_PINCTRL_AT91PIO4) += pinctrl-at91-pio4.o
obj-y += nxp/
diff --git a/drivers/pinctrl/pinctrl-apple.c b/drivers/pinctrl/pinctrl-apple.c
new file mode 100644
index 00..62476358c3
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-apple.c
@@ -0,0 +1,207 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2021 Mark
Re: [PATCH 00/31] passage: Define a standard for firmware data flow
Hi Mark, Le lun. 1 nov. 2021 à 19:19, Mark Kettenis a écrit : > > From: François Ozog > > Date: Mon, 1 Nov 2021 09:53:40 +0100 > > [...] > > > We could further leverage Passage to pass Operating Systems parameters > that > > could be removed from device tree (migration of /chosen to Passage). > Memory > > inventory would still be in DT but allocations for CMA or GPUs would be > in > > Passage. This idea is to reach a point where device tree is a "pristine" > > hardware description. > > I wanted to react on something you said in an earlier thread, but this > discussion seems to be appropriate as well: > > The notion that device trees only describe the hardware isn't really > correct. Device trees have always been used to configure firmware > options (through the /options node) and between firmware and the OS > (through the /chosen node) and to describe firmware interfaces > (e.g. OpenFirmware calls, PSCI (on ARM), RTAS (on POWER)). This was > the case on the original Open Firmware systems, and is still done on > PowerNV systems that use flattened device trees. > I understand and agree with the above. Yet, PSCI is different from /options and /chosen: those are platform services made available to the OS when the boot firmware code has been unloaded/neutralized. What I (not just myself but let’s simplify) am trying to decouple the supply chain: loosely coupled platform provider (ODM), the firmware provider, OS provider, application provider. So it is not to prevent presence of those existing nodes, it is to be able introduce some rationalization in their use: Platform interfaces such as PSCI: The question is “who” injects them in the DT (build time or runtime). There is no single good answer and you may want the authoritative entity that implements the service to actually inject itself in the DT passed to the OS. I know some platforms are using SMC calls from U-Boot to know what to inject in the DT. I see those as the same nature of DIMM sensing and injection in the DT. /chosen: a must have when you do not have UEFI but not necessary with UEFI. /options: it should be possible for the end customer to make the decision of integration: at build time or at runtime based on a separate flattened device tree file. This decoupling should result for instance, in the long run, in adjustable memory layouts without headaches. changing the secure dram size is simple from hardware perspective but a massive issue from a firmware perspective: multiple firmware projects sources need to be adjusted, making manual calculations on explicit constants or “hidden” ones. It should even be possible to adjust it at runtime on the field (user selected firmware parameter). > I don't see what the benefits are from using Passage instead. It > would only fragment things even more. > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
[PATCH v5 1/2] net: brcm: netXtreme driver
From: Bharat Gooty
Broadcom bnxt L2 driver support. Used by the Broadcom
iproc platforms.
Signed-off-by: Bharat Gooty
Reviewed-by: Ramon Fried
Signed-off-by: Roman Bacik
---
Changes in v5:
- remove bnxt_env_set_ethaddr/bnxt_env_del_ethaddr methods
- add .read_rom_hwaddr = bnxt_read_rom_hwaddr
- move bnxt_bring_pci/bnxt_bring_chip to bnxt_read_rom_hwddr
- move mac copy from priv to plat to bnxt_read_rom_hwaddr
Changes in v4:
- remove static num_cards and use dev_seq(dev) instead
- add .probe
- merged probe/remove methods
- select PCI_INIT_R when BNXT_ETH is selected
Changes in v3:
- change printf to debug in display_banner
- remove get/set/print mac/speed
- remove bnxt_hwrm_set_nvmem
Changes in v2:
- rebase and remove DM_PCI dependency from BNXT_ETH
- remove tautology assignment from debug_resp()
drivers/net/Kconfig |1 +
drivers/net/Makefile|1 +
drivers/net/bnxt/Kconfig|7 +
drivers/net/bnxt/Makefile |5 +
drivers/net/bnxt/bnxt.c | 1748 +++
drivers/net/bnxt/bnxt_dbg.h | 537 +++
drivers/net/bnxt/pci_ids.h | 17 +
include/broadcom/bnxt.h | 395
include/broadcom/bnxt_hsi.h | 889 ++
include/broadcom/bnxt_ver.h | 22 +
10 files changed, 3622 insertions(+)
create mode 100644 drivers/net/bnxt/Kconfig
create mode 100644 drivers/net/bnxt/Makefile
create mode 100644 drivers/net/bnxt/bnxt.c
create mode 100644 drivers/net/bnxt/bnxt_dbg.h
create mode 100644 drivers/net/bnxt/pci_ids.h
create mode 100644 include/broadcom/bnxt.h
create mode 100644 include/broadcom/bnxt_hsi.h
create mode 100644 include/broadcom/bnxt_ver.h
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 6c12959f3794..8dc81a3d6cf9 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1,6 +1,7 @@
source "drivers/net/phy/Kconfig"
source "drivers/net/pfe_eth/Kconfig"
source "drivers/net/fsl-mc/Kconfig"
+source "drivers/net/bnxt/Kconfig"
config ETH
def_bool y
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index e4078d15a99f..1d9fbd6693cc 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -101,3 +101,4 @@ obj-$(CONFIG_HIGMACV300_ETH) += higmacv300.o
obj-$(CONFIG_MDIO_SANDBOX) += mdio_sandbox.o
obj-$(CONFIG_FSL_ENETC) += fsl_enetc.o fsl_enetc_mdio.o
obj-$(CONFIG_FSL_LS_MDIO) += fsl_ls_mdio.o
+obj-$(CONFIG_BNXT_ETH) += bnxt/
diff --git a/drivers/net/bnxt/Kconfig b/drivers/net/bnxt/Kconfig
new file mode 100644
index ..412ecd430335
--- /dev/null
+++ b/drivers/net/bnxt/Kconfig
@@ -0,0 +1,7 @@
+config BNXT_ETH
+ bool "BNXT PCI support"
+ depends on DM_ETH
+ select PCI_INIT_R
+ help
+ This driver implements support for bnxt pci controller
+ driver of ethernet class.
diff --git a/drivers/net/bnxt/Makefile b/drivers/net/bnxt/Makefile
new file mode 100644
index ..a9d6ce00d5e0
--- /dev/null
+++ b/drivers/net/bnxt/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright 2019-2021 Broadcom.
+
+# Broadcom nxe Ethernet driver
+obj-y += bnxt.o
diff --git a/drivers/net/bnxt/bnxt.c b/drivers/net/bnxt/bnxt.c
new file mode 100644
index ..fe0f0833cd99
--- /dev/null
+++ b/drivers/net/bnxt/bnxt.c
@@ -0,0 +1,1748 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019-2021 Broadcom.
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "bnxt_dbg.h"
+#include "pci_ids.h"
+
+#define bnxt_down_chip(bp) bnxt_hwrm_run(down_chip, bp, 0)
+#define bnxt_bring_chip(bp)bnxt_hwrm_run(bring_chip, bp, 1)
+
+static const char banner[] = DRV_MODULE_DESC " v" UBOOT_MODULE_VER ",";
+static const char fw_ver[] = " FW v";
+
+static void display_banner(struct bnxt *bp)
+{
+ int i;
+
+ debug(banner);
+ debug(fw_ver);
+ debug("%d.%d.", bp->fw_maj, bp->fw_min);
+ debug("%d.%d\n", bp->fw_bld, bp->fw_rsvd);
+ debug("ETH MAC: ");
+ for (i = 0; i < ETH_ALEN; i++) {
+ debug("%02x", bp->mac_set[i]);
+ if (i != (ETH_ALEN - 1))
+ debug(":");
+ }
+
+ debug(", Port(%d), PF(%d)\n", bp->port_idx, bp->ordinal_value);
+}
+
+/* Broadcom ethernet driver PCI APIs. */
+static void bnxt_bring_pci(struct bnxt *bp)
+{
+ u16 cmd_reg = 0;
+
+ pci_read_word16(bp->pdev, PCI_VENDOR_ID, >vendor_id);
+ pci_read_word16(bp->pdev, PCI_DEVICE_ID, >device_id);
+ pci_read_word16(bp->pdev,
+ PCI_SUBSYSTEM_VENDOR_ID,
+ >subsystem_vendor);
+ pci_read_word16(bp->pdev, PCI_SUBSYSTEM_ID, >subsystem_device);
+ pci_read_word16(bp->pdev, PCI_COMMAND, >cmd_reg);
+ pci_read_byte(bp->pdev, PCICFG_ME_REGISTER, >pf_num);
+ pci_read_byte(bp->pdev, PCI_INTERRUPT_LINE, >irq);
+ bp->bar0 = pci_map_bar(bp->pdev, PCI_BASE_ADDRESS_0,
Re: [PATCH] net: gem: Reduce timeout of mdio phy idle status check
On Fri, Oct 29, 2021 at 2:16 PM Michal Simek wrote: > > From: Ashok Reddy Soma > > Timeout for checking mdio phy idle status is 20seconds. In case of errors > this timeout will be too much. Reduce it to 100ms. > > Signed-off-by: Ashok Reddy Soma > Signed-off-by: Michal Simek > --- > > drivers/net/zynq_gem.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c > index c309c3c95499..033021f1cbfc 100644 > --- a/drivers/net/zynq_gem.c > +++ b/drivers/net/zynq_gem.c > @@ -110,6 +110,8 @@ > > #define ZYNQ_GEM_DCFG_DBG6_DMA_64B BIT(23) > > +#define MDIO_IDLE_TIMEOUT_MS 100 > + > /* Use MII register 1 (MII status register) to detect PHY */ > #define PHY_DETECT_REG 1 > > @@ -225,7 +227,7 @@ static int phy_setup_op(struct zynq_gem_priv *priv, u32 > phy_addr, u32 regnum, > int err; > > err = wait_for_bit_le32(>nwsr, ZYNQ_GEM_NWSR_MDIOIDLE_MASK, > - true, 2, false); > + true, MDIO_IDLE_TIMEOUT_MS, false); > if (err) > return err; > > @@ -238,7 +240,7 @@ static int phy_setup_op(struct zynq_gem_priv *priv, u32 > phy_addr, u32 regnum, > writel(mgtcr, >phymntnc); > > err = wait_for_bit_le32(>nwsr, ZYNQ_GEM_NWSR_MDIOIDLE_MASK, > - true, 2, false); > + true, MDIO_IDLE_TIMEOUT_MS, false); > if (err) > return err; > > -- > 2.33.1 > Reviewed-by: Ramon Fried
Re: [PATCH] net: uclass: Save ethernet MAC address when generated
On Fri, Oct 29, 2021 at 2:14 PM Michal Simek wrote:
>
> When MAC address is randomly generated it should be also saved to
> variables. This step is there when MAC address is passed via pdata but not
> when it is randomly generated.
>
> Signed-off-by: Michal Simek
> ---
>
> net/eth-uclass.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/eth-uclass.c b/net/eth-uclass.c
> index 0da0e85be031..58c308f33276 100644
> --- a/net/eth-uclass.c
> +++ b/net/eth-uclass.c
> @@ -583,6 +583,8 @@ static int eth_post_probe(struct udevice *dev)
> net_random_ethaddr(pdata->enetaddr);
> printf("\nWarning: %s (eth%d) using random MAC address -
> %pM\n",
>dev->name, dev_seq(dev), pdata->enetaddr);
> + eth_env_set_enetaddr_by_index("eth", dev_seq(dev),
> + pdata->enetaddr);
> #else
> printf("\nError: %s address not set.\n",
>dev->name);
> --
> 2.33.1
>
Reviewed-by: Ramon Fried
[PATCH v5 2/2] board: brcm-ns3: Load netXtreme firmware
From: Bharat Gooty
Load NetXtreme firmware in board_init when BNXT_ETH is selected.
Signed-off-by: Bharat Gooty
Signed-off-by: Roman Bacik
---
(no changes since v4)
Changes in v4:
- remove bnxt commands
- load bnxt firmware in board_init
Changes in v3:
- remove commands set/get mac/speed
- add doc/bnxt.rst
board/broadcom/bcmns3/ns3.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/board/broadcom/bcmns3/ns3.c b/board/broadcom/bcmns3/ns3.c
index 758a358f5425..cc27dfccc57b 100644
--- a/board/broadcom/bcmns3/ns3.c
+++ b/board/broadcom/bcmns3/ns3.c
@@ -150,7 +150,10 @@ int board_init(void)
if (bl33_info->version != BL33_INFO_VERSION)
printf("*** warning: ATF BL31 and U-Boot not in sync! ***\n");
-
+#if CONFIG_IS_ENABLED(BNXT_ETH)
+ if (chimp_fastboot_optee() != 0)
+ printf("*** warning: secure chimp fastboot failed! ***\n");
+#endif
return 0;
}
--
2.17.1
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
smime.p7s
Description: S/MIME Cryptographic Signature
Re: New Defects reported by Coverity Scan for Das U-Boot
Hello Tom,
CID 340849: Uninitialized variables (UNINIT)
is invalid: If efi_allocate_pages fails, addr is not used.
CID 166730: Integer handling issues (SIGN_EXTENSION)
is invalid. u16 is first promoted to u32 (not int) and then shifted and
then promoted to u64.
Best regards
Heinrich
On 11/1/21 20:29, scan-ad...@coverity.com wrote:
Hi,
Please find the latest report on new defect(s) introduced to Das U-Boot found
with Coverity Scan.
10 new defect(s) introduced to Das U-Boot found with Coverity Scan.
10 defect(s), reported by Coverity Scan earlier, were marked fixed in the
recent build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 10 of 10 defect(s)
** CID 340850: Control flow issues (UNREACHABLE)
/test/lib/abuf.c: 81 in lib_test_abuf_realloc()
*** CID 340850: Control flow issues (UNREACHABLE)
/test/lib/abuf.c: 81 in lib_test_abuf_realloc()
75 /*
76 * TODO: crashes on sandbox sometimes due to an apparent bug in
77 * realloc().
78 */
79 return 0;
80
CID 340850: Control flow issues (UNREACHABLE)
This code cannot be reached: "start = ut_check_free();".
81 start = ut_check_free();
82
83 abuf_init();
84
85 /* Allocate an empty buffer */
86 ut_asserteq(true, abuf_realloc(, 0));
** CID 340849: Uninitialized variables (UNINIT)
/lib/efi_loader/efi_boottime.c: 1991 in efi_load_image_from_path()
*** CID 340849: Uninitialized variables (UNINIT)
/lib/efi_loader/efi_boottime.c: 1991 in efi_load_image_from_path()
1985_size, (void
*)(uintptr_t)addr));
1986if (ret != EFI_SUCCESS)
1987efi_free_pages(addr, pages);
1988 out:
1989EFI_CALL(efi_close_protocol(device, guid, efi_root, NULL));
1990if (ret == EFI_SUCCESS) {
CID 340849: Uninitialized variables (UNINIT)
Using uninitialized value "addr".
1991*buffer = (void *)(uintptr_t)addr;
1992*size = buffer_size;
1993}
1994
1995return ret;
1996 }
** CID 340848: Control flow issues (DEADCODE)
/lib/rsa/rsa-sign.c: 255 in rsa_engine_get_priv_key()
*** CID 340848: Control flow issues (DEADCODE)
/lib/rsa/rsa-sign.c: 255 in rsa_engine_get_priv_key()
249 } else if (engine_id) {
250 if (keydir && name)
251 snprintf(key_id, sizeof(key_id),
252 "%s%s",
253 keydir, name);
254 else if (name)
CID 340848: Control flow issues (DEADCODE)
Execution cannot reach the expression inside this statement: "snprintf(key_id,
1024UL, "%...".
255 snprintf(key_id, sizeof(key_id),
256 "%s",
257 name ? name : "");
258 else if (keyfile)
259 snprintf(key_id, sizeof(key_id), "%s", keyfile);
260 else
** CID 340847:(TAINTED_SCALAR)
*** CID 340847:(TAINTED_SCALAR)
/lib/zstd/zstd.c: 49 in zstd_decompress()
43 out_buf.pos = 0;
44 out_buf.size = abuf_size(out);
45
46 while (1) {
47 size_t res;
48
CID 340847:(TAINTED_SCALAR)
Passing tainted variable "dstream->inBuff" to a tainted sink.
49 res = ZSTD_decompressStream(dstream, _buf, _buf);
50 if (ZSTD_isError(res)) {
51 ret = ZSTD_getErrorCode(res);
52 log_err("ZSTD_decompressStream error %d\n", ret);
53 goto do_free;
54 }
/lib/zstd/zstd.c: 49 in zstd_decompress()
43 out_buf.pos = 0;
44 out_buf.size = abuf_size(out);
45
46 while (1) {
47 size_t res;
48
CID 340847:(TAINTED_SCALAR)
Passing tainted variable "in_buf.src" to a tainted sink.
49 res = ZSTD_decompressStream(dstream, _buf, _buf);
50 if (ZSTD_isError(res)) {
51 ret = ZSTD_getErrorCode(res);
52 log_err("ZSTD_decompressStream error %d\n", ret);
53 goto do_free;
54 }
** CID 340846: Control flow issues (UNREACHABLE)
/test/lib/abuf.c: 144 in lib_test_abuf_large()
*** CID 340846: Control flow issues (UNREACHABLE)
/test/lib/abuf.c: 144 in
RE: [PATCH v4 1/2] net: brcm: netXtreme driver
Hi Marek, > -Original Message- > From: Marek Behún > Sent: Sunday, October 31, 2021 3:56 AM > To: Roman Bacik > Cc: U-Boot Mailing List ; Bharat Gooty > ; Joe Hershberger > ; Ramon Fried ; > p...@kernel.org > Subject: Re: [PATCH v4 1/2] net: brcm: netXtreme driver > > On Sat, 30 Oct 2021 08:48:05 -0700 > Roman Bacik wrote: > > > The mac address can be read from bp only after bnxt_bring_chip is > > called, which is after read_rom_hwaddr is called. Theoretically we can > > call bnxt_bring_chip in bind or in read_rom_hwaddr and then one can > > use this method if desired. > > How long does bnxt_bring_chip() take? In milliseconds? If it isn't > extremely long, I think it could be called from read_rom_hwaddr... > > >> eth_env_set_enetaddr_by_index() > > > We can change and use this method. > > Pls do, and drop the env deletion. > > Marek We will make requested changes in v5. Thank you very much for your review, Roman -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. smime.p7s Description: S/MIME Cryptographic Signature
[scan-ad...@coverity.com: New Defects reported by Coverity Scan for Das U-Boot]
Here's the list of new defects from v2022.01-rc1
- Forwarded message from scan-ad...@coverity.com -
Date: Mon, 01 Nov 2021 19:29:37 + (UTC)
From: scan-ad...@coverity.com
To: tom.r...@gmail.com
Subject: New Defects reported by Coverity Scan for Das U-Boot
Hi,
Please find the latest report on new defect(s) introduced to Das U-Boot found
with Coverity Scan.
10 new defect(s) introduced to Das U-Boot found with Coverity Scan.
10 defect(s), reported by Coverity Scan earlier, were marked fixed in the
recent build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 10 of 10 defect(s)
** CID 340850: Control flow issues (UNREACHABLE)
/test/lib/abuf.c: 81 in lib_test_abuf_realloc()
*** CID 340850: Control flow issues (UNREACHABLE)
/test/lib/abuf.c: 81 in lib_test_abuf_realloc()
75 /*
76 * TODO: crashes on sandbox sometimes due to an apparent bug in
77 * realloc().
78 */
79 return 0;
80
>>> CID 340850: Control flow issues (UNREACHABLE)
>>> This code cannot be reached: "start = ut_check_free();".
81 start = ut_check_free();
82
83 abuf_init();
84
85 /* Allocate an empty buffer */
86 ut_asserteq(true, abuf_realloc(, 0));
** CID 340849: Uninitialized variables (UNINIT)
/lib/efi_loader/efi_boottime.c: 1991 in efi_load_image_from_path()
*** CID 340849: Uninitialized variables (UNINIT)
/lib/efi_loader/efi_boottime.c: 1991 in efi_load_image_from_path()
1985_size, (void
*)(uintptr_t)addr));
1986if (ret != EFI_SUCCESS)
1987efi_free_pages(addr, pages);
1988 out:
1989EFI_CALL(efi_close_protocol(device, guid, efi_root, NULL));
1990if (ret == EFI_SUCCESS) {
>>> CID 340849: Uninitialized variables (UNINIT)
>>> Using uninitialized value "addr".
1991*buffer = (void *)(uintptr_t)addr;
1992*size = buffer_size;
1993}
1994
1995return ret;
1996 }
** CID 340848: Control flow issues (DEADCODE)
/lib/rsa/rsa-sign.c: 255 in rsa_engine_get_priv_key()
*** CID 340848: Control flow issues (DEADCODE)
/lib/rsa/rsa-sign.c: 255 in rsa_engine_get_priv_key()
249 } else if (engine_id) {
250 if (keydir && name)
251 snprintf(key_id, sizeof(key_id),
252 "%s%s",
253 keydir, name);
254 else if (name)
>>> CID 340848: Control flow issues (DEADCODE)
>>> Execution cannot reach the expression inside this statement:
>>> "snprintf(key_id, 1024UL, "%...".
255 snprintf(key_id, sizeof(key_id),
256 "%s",
257 name ? name : "");
258 else if (keyfile)
259 snprintf(key_id, sizeof(key_id), "%s", keyfile);
260 else
** CID 340847:(TAINTED_SCALAR)
*** CID 340847:(TAINTED_SCALAR)
/lib/zstd/zstd.c: 49 in zstd_decompress()
43 out_buf.pos = 0;
44 out_buf.size = abuf_size(out);
45
46 while (1) {
47 size_t res;
48
>>> CID 340847:(TAINTED_SCALAR)
>>> Passing tainted variable "dstream->inBuff" to a tainted sink.
49 res = ZSTD_decompressStream(dstream, _buf, _buf);
50 if (ZSTD_isError(res)) {
51 ret = ZSTD_getErrorCode(res);
52 log_err("ZSTD_decompressStream error %d\n", ret);
53 goto do_free;
54 }
/lib/zstd/zstd.c: 49 in zstd_decompress()
43 out_buf.pos = 0;
44 out_buf.size = abuf_size(out);
45
46 while (1) {
47 size_t res;
48
>>> CID 340847:(TAINTED_SCALAR)
>>> Passing tainted variable "in_buf.src" to a tainted sink.
49 res = ZSTD_decompressStream(dstream, _buf, _buf);
50 if (ZSTD_isError(res)) {
51 ret = ZSTD_getErrorCode(res);
52 log_err("ZSTD_decompressStream error %d\n", ret);
53 goto do_free;
54 }
** CID 340846: Control flow issues (UNREACHABLE)
/test/lib/abuf.c: 144 in lib_test_abuf_large()
*** CID 340846: Control flow issues (UNREACHABLE)
/test/lib/abuf.c: 144 in lib_test_abuf_large()
138
[ANN] U-Boot v2022.01-rc1 released
Hey all, Well, I'm a full week off here because I thought it was supposed to be scheduled for today. Whoops, that's on me. I do think there's a few more things to come in to prepare for the next release, but this is I think largely it. In terms of a changelog, git log --merges v2021.10..v2022.01-rc1 contains what I've pulled but as always, better PR messages and tags will provide better results here. So we're now looking at regular releases every other Monday, and with final release on January 10th, 2022. Thanks all! -- Tom signature.asc Description: PGP signature
Re: [PATCH 00/31] passage: Define a standard for firmware data flow
> From: François Ozog > Date: Mon, 1 Nov 2021 09:53:40 +0100 [...] > We could further leverage Passage to pass Operating Systems parameters that > could be removed from device tree (migration of /chosen to Passage). Memory > inventory would still be in DT but allocations for CMA or GPUs would be in > Passage. This idea is to reach a point where device tree is a "pristine" > hardware description. I wanted to react on something you said in an earlier thread, but this discussion seems to be appropriate as well: The notion that device trees only describe the hardware isn't really correct. Device trees have always been used to configure firmware options (through the /options node) and between firmware and the OS (through the /chosen node) and to describe firmware interfaces (e.g. OpenFirmware calls, PSCI (on ARM), RTAS (on POWER)). This was the case on the original Open Firmware systems, and is still done on PowerNV systems that use flattened device trees. I don't see what the benefits are from using Passage instead. It would only fragment things even more.
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
On Mon, Nov 01, 2021 at 06:33:35PM +0100, François Ozog wrote: > Hi Simon > > Le lun. 1 nov. 2021 à 17:58, Simon Glass a écrit : > > > Hi Peter, > > > > On Mon, 1 Nov 2021 at 04:48, Peter Maydell > > wrote: > > > > > > On Tue, 26 Oct 2021 at 01:33, Simon Glass wrote: > > > > > > > > Add this file, generated from qemu, so there is a reference devicetree > > > > in the U-Boot tree. > > > > > > > > Signed-off-by: Simon Glass > > > > > > Note that the dtb you get from QEMU is only guaranteed to work if: > > > 1) you run it on the exact same QEMU version you generated it with > > > 2) you pass QEMU the exact same command line arguments you used > > > when you generated it > > > > Yes, I certainly understand that. In general this is not safe, but in > > practice it works well enough for development and CI. > > You recognize that you hijack a product directory with development hack > facility. There is a test directory to keep things clear. There can be a > dev-dts or something similar for Dev time tools. > I have only seen push back on those fake dts files in the dts directory: I > guess that unless someone strongly favors a continuation of the discussion, > you may consider re-shaping the proposal to address concerns. Yes. We need to document how to make development easier. But I'm still not on board with the notion of including DTS files for platforms where the source of truth for the DTB is elsewhere. That's going to bring us a lot more pain. It is important to make sure our "develop our project" workflow is sane and relatively pain free. But that needs to not come by making sacrifices to the "use our project" outcome. I would hope for example that the new Pi zero platform is just dtb changes, as far as the linux kernel is concerned which means that for rpi_arm64 (which uses run time dtb) it also just works. And that's what we want to see. -- Tom signature.asc Description: PGP signature
Re: Please pull u-boot-x86
On Mon, Nov 01, 2021 at 12:38:18PM +0800, Bin Meng wrote: > Hi Tom, > > This PR includes the following x86 changes for v2022.01: > > - Fixes for x86 build with Clang/LLVM compiler > - Tangier ACPI changes > - Edison SD card detect pin fix > - EFI on x86 doc update with latest instructions > - PXE utility fixes to align with latest x86 zboot implementation > > Azure results: PASS > https://dev.azure.com/bmeng/GitHub/_build/results?buildId=462=results > > The following changes since commit 360e392274e3bfeda3b7226d2cac7514774d0da1: > > Merge tag 'dm-pull-boo21' of > https://source.denx.de/u-boot/custodians/u-boot-dm (2021-10-31 > 15:48:43 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-x86 > > for you to fetch changes up to 5270bee9b27cf63251696916e4b5a5d4412d3a2d: > > x86: tangier: pinmux: Move error message to the caller (2021-11-01 > 10:19:05 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
Hi Simon Le lun. 1 nov. 2021 à 17:58, Simon Glass a écrit : > Hi Peter, > > On Mon, 1 Nov 2021 at 04:48, Peter Maydell > wrote: > > > > On Tue, 26 Oct 2021 at 01:33, Simon Glass wrote: > > > > > > Add this file, generated from qemu, so there is a reference devicetree > > > in the U-Boot tree. > > > > > > Signed-off-by: Simon Glass > > > > Note that the dtb you get from QEMU is only guaranteed to work if: > > 1) you run it on the exact same QEMU version you generated it with > > 2) you pass QEMU the exact same command line arguments you used > > when you generated it > > Yes, I certainly understand that. In general this is not safe, but in > practice it works well enough for development and CI. You recognize that you hijack a product directory with development hack facility. There is a test directory to keep things clear. There can be a dev-dts or something similar for Dev time tools. I have only seen push back on those fake dts files in the dts directory: I guess that unless someone strongly favors a continuation of the discussion, you may consider re-shaping the proposal to address concerns. > I am able to use > QEMU versions that differ by two years, partly because I am not trying > to do anything clever. > > I have sent a patch to add an indication of where the devicetree came > from, to help with visibility on this. > > Regards, > Simon > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH v2 3/4] fpga: add fit_fpga_load function
Hi Michal,
On Mon, Nov 1, 2021 at 2:05 PM Michal Simek wrote:
>
>
>
> On 11/1/21 11:47, Oleksandr Suvorov wrote:
> > Introduce a function which passes an fpga compatible string from
> > FIT images to FPGA drivers. This lets the different implementations
> > decide how to handle it.
> >
> > Some code of Jorge Ramirez-Ortiz is reused.
> >
> > Signed-off-by: Oleksandr Suvorov
> > ---
> >
> > (no changes since v1)
> >
> > common/spl/spl_fit.c | 6 ++
> > drivers/fpga/fpga.c | 26 --
> > include/fpga.h | 4
> > 3 files changed, 30 insertions(+), 6 deletions(-)
> >
> > diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> > index 5fe0273d66..bd29e8c59d 100644
> > --- a/common/spl/spl_fit.c
> > +++ b/common/spl/spl_fit.c
> > @@ -580,11 +580,9 @@ static int spl_fit_upload_fpga(struct spl_fit_info
> > *ctx, int node,
> > compatible = fdt_getprop(ctx->fit, node, "compatible", NULL);
> > if (!compatible)
> > warn_deprecated("'fpga' image without 'compatible' property");
> > - else if (strcmp(compatible, "u-boot,fpga-legacy"))
> > - printf("Ignoring compatible = %s property\n", compatible);
> >
> > - ret = fpga_load(0, (void *)fpga_image->load_addr, fpga_image->size,
> > - BIT_FULL);
> > + ret = fit_fpga_load(0, (void *)fpga_image->load_addr,
> > fpga_image->size,
> > + BIT_FULL, compatible);
> > if (ret) {
> > printf("%s: Cannot load the image to the FPGA\n", __func__);
> > return ret;
> > diff --git a/drivers/fpga/fpga.c b/drivers/fpga/fpga.c
> > index 3b0a44b242..e4b5dd392e 100644
> > --- a/drivers/fpga/fpga.c
> > +++ b/drivers/fpga/fpga.c
> > @@ -249,15 +249,31 @@ int fpga_loads(int devnum, const void *buf, size_t
> > size,
> > }
> > #endif
> >
> > +int fit_fpga_load(int devnum, const void *buf, size_t bsize,
> > + bitstream_type bstype, const char *compatible)
> > +{
> > + fpga_desc *desc = (fpga_desc *) fpga_validate(devnum, buf, bsize,
> > + (char *)__func__);
> > +
>
> nit: Better to separate it:
>
> fpga_desc *desc;
>
> desc = (fpga_desc *) fpga_validate(devnum, buf, bsize, (char *)__func__);
> if (!desc)
> ...
>
>
> > + if (!desc)
> > + return FPGA_FAIL;
> > + /*
> > + * Store the compatible string to proceed it in underlying
> > + * functions
> > + */
> > + desc->compatible = (char *)compatible;
> > +
> > + return fpga_load(devnum, buf, bsize, bstype);
> > +}
> > /*
> > - * Generic multiplexing code
> > + * Generic multiplexing code:
> > + * Each architecture must handle the mandatory FPGA DT compatible property.
> >*/
> > int fpga_load(int devnum, const void *buf, size_t bsize, bitstream_type
> > bstype)
> > {
> > int ret_val = FPGA_FAIL; /* assume failure */
> > const fpga_desc *desc = fpga_validate(devnum, buf, bsize,
> > (char *)__func__);
> > -
>
> this should break the rule that you should separate variable
> declaration/definitions from the actual code. Do it via two steps as is
> described above.
>
> And in this content it is separate change.
>
> > if (desc) {
> > switch (desc->devtype) {
> > case fpga_xilinx:
> > @@ -270,6 +286,9 @@ int fpga_load(int devnum, const void *buf, size_t
> > bsize, bitstream_type bstype)
> > break;
> > case fpga_altera:
> > #if defined(CONFIG_FPGA_ALTERA)
> > + if (strcmp(desc->compatible, "u-boot,fpga-legacy"))
>
> strncmp please
Thank you for such a detailed review. I will take into account all your
comments in the next version of the patch.
>
> > + printf("Ignoring compatible = %s property\n",
> > +desc->compatible);
> > ret_val = altera_load(desc->devdesc, buf, bsize);
> > #else
> > fpga_no_sup((char *)__func__, "Altera devices");
> > @@ -277,6 +296,9 @@ int fpga_load(int devnum, const void *buf, size_t
> > bsize, bitstream_type bstype)
> > break;
> > case fpga_lattice:
> > #if defined(CONFIG_FPGA_LATTICE)
> > + if (strcmp(desc->compatible, "u-boot,fpga-legacy"))
> > + printf("Ignoring compatible = %s property\n",
> > +desc->compatible);
> > ret_val = lattice_load(desc->devdesc, buf, bsize);
> > #else
> > fpga_no_sup((char *)__func__, "Lattice devices");
> > diff --git a/include/fpga.h b/include/fpga.h
> > index ec5144334d..2891f32106 100644
> > --- a/include/fpga.h
> > +++ b/include/fpga.h
> > @@ -35,6 +35,7 @@ typedef enum { /* typedef fpga_type
> > */
> > typedef struct {/* typedef fpga_desc */
> >
Re: [PATCH v2 2/4] cmd: fpga: Separating the support of fpga loads
On Mon, Nov 1, 2021 at 1:54 PM Michal Simek wrote: > > > > On 11/1/21 11:47, Oleksandr Suvorov wrote: > > This patch allows enabling support of "fpga lodas command which loads > > secure bitstreams (authenticated or encrypted, or both) independently > > in SPL and in u-boot. > > > > Signed-off-by: Oleksandr Suvorov > > --- > > > > (no changes since v1) > > > > cmd/Kconfig | 9 + > > cmd/fpga.c | 8 > > SPL doesn't use commands that's why this is quite weird. Omg, thanks! That case when doing something weird using tough mind template :-D > > M -- Best regards, Oleksandr Suvorov Software Engineer T: +380 63 8489656 E: oleksandr.suvo...@foundries.io W: www.foundries.io
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
Hi Peter, On Mon, 1 Nov 2021 at 04:48, Peter Maydell wrote: > > On Tue, 26 Oct 2021 at 01:33, Simon Glass wrote: > > > > Add this file, generated from qemu, so there is a reference devicetree > > in the U-Boot tree. > > > > Signed-off-by: Simon Glass > > Note that the dtb you get from QEMU is only guaranteed to work if: > 1) you run it on the exact same QEMU version you generated it with > 2) you pass QEMU the exact same command line arguments you used > when you generated it Yes, I certainly understand that. In general this is not safe, but in practice it works well enough for development and CI. I am able to use QEMU versions that differ by two years, partly because I am not trying to do anything clever. I have sent a patch to add an indication of where the devicetree came from, to help with visibility on this. Regards, Simon
Re: [PATCHv3] zynqmp: restore the jtag interface
On Thu, Oct 14, 2021 at 4:15 AM Michal Simek wrote:
>
> On 10/13/21 15:48, Jorge Ramirez-Ortiz wrote:
> > When boot.bin is configured for secure boot the CSU will disable the
> > JTAG interface on all cases.
> >
> > Some boards might rely on this interface for flashing to QSPI in which
> > case those systems might end up bricked during development.
> >
> > This commit will restore the interface under CSU control
> >
> > Signed-off-by: Jorge Ramirez-Ortiz
> > ---
> >
> > v3: delete unvalid removal of empty line
> >
> > arch/arm/mach-zynqmp/Kconfig | 8 +
> > arch/arm/mach-zynqmp/include/mach/hardware.h | 31 +++-
> > board/xilinx/zynqmp/zynqmp.c | 19
> > 3 files changed, 51 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm/mach-zynqmp/Kconfig b/arch/arm/mach-zynqmp/Kconfig
> > index f7b08db355..ee0895d9a2 100644
> > --- a/arch/arm/mach-zynqmp/Kconfig
> > +++ b/arch/arm/mach-zynqmp/Kconfig
> > @@ -149,6 +149,14 @@ config SPL_ZYNQMP_ALT_BOOTMODE_ENABLED
> > Overwrite bootmode selected via boot mode pins to tell SPL what
> > should
> > be the next boot device.
> >
> > +config SPL_ZYNQMP_RESTORE_JTAG
> > + bool "Restore JTAG"
> > + depends on SPL
> > + help
> > + Booting SPL in secure mode causes the CSU to disable the JTAG
> > interface
> > + even if no eFuses were burnt. This option restores the interface if
> > + possible.
>
> here should be tab and 2 spaces.
>
> I have fixed it myself and applied.
I see this is applied at your next tree, but there is one minor issue
which is fixed with the patch bellow:
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index dfb5dab7afa..2b5239ccb47 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -394,7 +394,7 @@ int board_init(void)
printf("Silicon version:\t%d\n", zynqmp_get_silicon_version());
/* the CSU disables the JTAG interface when secure boot is enabled */
- if (CONFIG_IS_ENABLED(SPL_ZYNQMP_RESTORE_JTAG))
+ if (CONFIG_IS_ENABLED(ZYNQMP_RESTORE_JTAG))
restore_jtag();
#else
if (CONFIG_IS_ENABLED(DM_I2C) && CONFIG_IS_ENABLED(I2C_EEPROM))
Do you want me to send a patch directly to you or do you prefer to
squash the changes as it seems this wasn't asked to be merged upstream
yet?
Thanks,
--
Ricardo Salveti
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
On Fri, Oct 29, 2021 at 01:20:52PM +0300, Ilias Apalodimas wrote: > Hi Simon, > > [...] > > > > > > > > > Why me? Perhaps Linaro could take this on instead of working in a > > > > separate tool and domain? You guys could really pull things together > > > > and reduce the fragmentation, if you took it on. > > > > > > > > Honestly it is hard enough to even get Linaro people to write a test > > > > for code they have written. What gives? > > > > > > That's completely inaccurate. We've added selftests for *every* > > > single feature we've sent for EFI up to now. Functionality wise the > > > past 2 years we've added > > > - EFI variables > > > - EFI secure boot > > > - capsule updates > > > - initrd loading > > > - efi TCG protocol > > > - ESRT tables > > > - RNG protocol > > > > > > 5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests > > > 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi() > > > 1170fee695197 efi_selftest: fix variables test for GetNextVariableName() > > > ce62b0f8f45f1 test/py: Fix efidebug related tests > > > 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule > > > de489d82e3189 test: test the ESRT creation > > > 57be8cdce35 test/py: efi_secboot: small rework for adding a new test > > > e1174c566a61c test/py: efi_secboot: add test for intermediate certificates > > > 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load > > > initramfs > > > > > > and I am pretty sure I am forgetting more on functionality and selftests. > > > > > > So basically we've either contributed new selftests for *everything* > > > we've or fixed the existing ones. The only thing that's not merged is > > > the TCG selftests which are on upstream review. > > > > Er, I didn't say or mean that no tests were written, just that there > > is too much push-back on it. Heinrich put a huge amount of effort into > > There's no pushback at all, apart from the TPM one. (and for a very good > reason I've explained over and over again). In fact we add the sefltests > as part of our patchsets. And, for that set of TPM things, I agree with NOT making sandbox the requirement there. As QEMU is able to provide a TPM that will see real world usage, that's what we need to validate against primarily. > > the tests and basically created a strong base for it. Congrats and > > huge kudos to him. As to Linaro, no offence intended, and it is great > > that all these tests have been added. Thank you for your efforts and > > it is very helpful. But I think you miss my point. Or perhaps you > > don't even agree with it? I sent an email about this on one patch just > > a day or two ago. > > I guess you mean [1]. I've lost count of how many times I responded to > this. Threads [2], [3] and [4] are just a few examples, so I just got > tired or replying the same thing over and over. > > So bottom line, we are contributing selftests as always, we just don't agree > with the way *you* want this specific TPM test, trying to force us into > sandbox. > So instead of respecting what we have (which btw is acceptable from u-boot's > perspective and cleans up a lot of the TPM crud along the way), you went ahead > making misleading statements on the selftests we contribute, in general. > What's > even more annoying is that, as I showed you, we pretty much add a selftest > for *every* feature we add. Excellent ... that's certainly ... encouraging > ... and > very productive. > > > > > As to the leadership side (my bigger point), Linaro is leading us all > > down this fragmented path, with TF-A, FIP, more and more binaries and > > larger firmware diagrams. Or do you disagree with that too? > > > > Of course I disagree. People decided not to use SPL for their own reasons. > I am certainly not qualified to answer why Arm choose to do that, but it seems > to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure > U-Boot is compatible and remains the de-facto choice for embedded boot > loaders playing nicely with all the new FSBLs come up with. If you > cosinder SPL and U-Boot the center of the known universe, we certainly view > things differently. FWIW it's *our* work mostly that made U-Boot SystemReady > compliant, which is something Arm pushes for [5]. Let me say for the record that I am appreciative of the fact the Linaro has been putting so much effort in to U-Boot, both in terms of tests and also in general SystemReady compliance work. -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 0/5] Fix compiler warnings for 32-bit ARM
On Sun, Oct 31, 2021 at 05:47:00PM -0600, Simon Glass wrote: > Hi, > > On Sun, 1 Aug 2021 at 18:56, Simon Glass wrote: > > > > These were noticed when building sandbox on a Raspberry Pi 400, which uses > > 32-bit linux. > > > > To make this work, I enabled CONFIG_HOST_32BIT in 'make menuconfig'. It > > would be nice if that were automatic, since we have the logic already in > > arch/sandbox/config.mk > > > > So this series adds that. > > > > It also fixes the unicode warnings of the form: > > > > /usr/bin/ld: warning: arch/sandbox/cpu/start.o uses 2-byte wchar_t yet the > > output is to use 4-byte wchar_t; use of wchar_t values across objects > > may fail > > > > as suggested by Heinrich. > > > > Changes in v3: > > - Mention the link to the new upstream patch > > - Change some things EFI things missed (or new since) last time > > - Use 'bitness' instead of 'bit' > > - Add a new patch to change non-EFI occurences > > > > Changes in v2: > > - Add new patch to reduce checkpatch unicode-string spam > > - Drop patches previously applied > > - Put all the packages in gcc.rst > > > > Joe Perches (1): > > checkpatch: Support wide strings Has this been merged upstream yet? It's going to get lost otherwise. > > Simon Glass (4): > > efi: Use 16-bit unicode strings > > treewide: Use 16-bit unicode strings What was the outcome here? I think I was saying we should make some global correction to the source tree, was this in fact it? > > sandbox: Detect the host bit size automatically Commented on now. > > RFC: treewide: Drop -fshort-char I think this causes other problems unfortunately? -- Tom signature.asc Description: PGP signature
Re: [PATCH] dts: rockchip: rk3399: enable emmc phy for spl
On Mon, Nov 1, 2021 at 4:44 AM Yifeng Zhao wrote:
>
> adapting commit ac804143cf ("mmc: rockchip_sdhci: add phy and clock
> config for rk3399") to fix the issue "Not found emmc phy device".
>
> Signed-off-by: Yifeng Zhao
Fixes: ac804143cf ("mmc: rockchip_sdhci: add phy and clock config for rk3399")
Reviewed-by: Peter Robinson
Tested-by: Peter Robinson - on a Rock960
> ---
>
> arch/arm/dts/rk3399-u-boot.dtsi | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
> index 73922c328a..716b9a433a 100644
> --- a/arch/arm/dts/rk3399-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
> @@ -88,6 +88,10 @@
> u-boot,dm-pre-reloc;
> };
>
> +_phy {
> + u-boot,dm-pre-reloc;
> +};
> +
> {
> u-boot,dm-pre-reloc;
> };
> --
> 2.17.1
>
>
>
Re: [PATCH v3 3/5] sandbox: Detect the host bit size automatically
On Mon, Nov 01, 2021 at 08:04:44AM +0100, Pali Rohár wrote:
> On Sunday 01 August 2021 18:56:11 Simon Glass wrote:
> > At present if you build sandbox on a 32-bit host a lot of errors are
> > produced. This is because CONFIG_HOST_64BIT is enabled by default.
> >
> > It is quite annoying to have to change that manually before building
> > sandbox. It is also quite confusing for new users.
> >
> > Add a way to detect the setting and add the appropriate
> > CONFIG_HOST_64BIT=y or CONFIG_HOST_32BIT=y to the defconfig, to avoid
> > this issue.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > Changes in v3:
> > - Use 'bitness' instead of 'bit'
> >
> > Changes in v2:
> > - Drop patches previously applied
> > - Put all the packages in gcc.rst
> >
> > Makefile | 11 ++-
> > arch/sandbox/Kconfig | 13 -
> > scripts/kconfig/Makefile | 14 +-
> > 3 files changed, 31 insertions(+), 7 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 269e353a28a..57c3e9a77df 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -565,8 +565,17 @@ export KBUILD_DEFCONFIG KBUILD_KCONFIG
> > config: scripts_basic outputmakefile FORCE
> > $(Q)$(MAKE) $(build)=scripts/kconfig $@
> >
> > +# If nothing is specified explicitly, detect the bit size for sandbox,
> > +# referred to from arch/sandbox/Kconfig
> > +# Add it to the end of the defconfig file
> > %config: scripts_basic outputmakefile FORCE
> > - $(Q)$(MAKE) $(build)=scripts/kconfig $@
> > + $(Q)if test -f $(srctree)/configs/$@ && \
> > + ! grep -Eq "CONFIG_HOST_(32|64)BIT=y" $(srctree)/configs/$@;
> > then \
> > + echo '#include \nint main(void) {
> > printf("CONFIG_HOST_%dBIT=y\\n", __WORDSIZE); return 0; }' \
> > +| gcc -x c - -o get_word_size; \
>
> Should not Makefile use user's specified compiler instead of hardcoded 'gcc'?
And it should probably look a bit more like how we do CC_IS_GCC, etc.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v4 03/16] i.MX8M: crypto: updated device tree for supporting DM in SPL
On Tue, Oct 26, 2021 at 1:57 AM Gaurav Jain wrote:
>
> disabled use of JR0 in SPL and uboot, as JR0 is reserved
> for secure boot.
>
> Signed-off-by: Gaurav Jain
> Reviewed-by: Ye Li
> ---
> arch/arm/dts/imx8mm-evk-u-boot.dtsi | 18 +-
> arch/arm/dts/imx8mm.dtsi | 1 +
> arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi | 18 +-
> arch/arm/dts/imx8mn.dtsi | 1 +
> arch/arm/dts/imx8mp-evk-u-boot.dtsi | 18 +-
> arch/arm/dts/imx8mp.dtsi | 1 +
> arch/arm/dts/imx8mq.dtsi | 1 +
> 7 files changed, 55 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> index 3c75415e8f..40f5cfda9a 100644
> --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> - * Copyright 2019 NXP
> + * Copyright 2019, 2021 NXP
> */
>
> #include "imx8mm-u-boot.dtsi"
> @@ -72,6 +72,22 @@
> u-boot,dm-spl;
> };
>
> + {
> + u-boot,dm-spl;
> +};
> +
> +_jr0 {
> + u-boot,dm-spl;
> +};
> +
> +_jr1 {
> + u-boot,dm-spl;
> +};
> +
> +_jr2 {
> + u-boot,dm-spl;
> +};
> +
> {
> u-boot,dm-spl;
> };
> diff --git a/arch/arm/dts/imx8mm.dtsi b/arch/arm/dts/imx8mm.dtsi
> index b142b80734..00bf3a 100644
> --- a/arch/arm/dts/imx8mm.dtsi
> +++ b/arch/arm/dts/imx8mm.dtsi
> @@ -824,6 +824,7 @@
> compatible = "fsl,sec-v4.0-job-ring";
> reg = <0x1000 0x1000>;
> interrupts = IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
Changing the SoC DTSI files makes future re-synchronizing difficult.
If you mark these as disabled in the respective u-boot.dtsi files, it
will create less work in the future. You're already enabling a bunch
of new features in the respective -u-boot.dtsi files, I would suggest
doing the disable in the same way.
> };
>
> sec_jr1: jr@2000 {
> diff --git a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> b/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> index 1d3844437d..b462d24eb2 100644
> --- a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> - * Copyright 2019 NXP
> + * Copyright 2019, 2021 NXP
> */
>
> / {
> @@ -104,6 +104,22 @@
> u-boot,dm-spl;
> };
>
> + {
> + u-boot,dm-spl;
> +};
> +
> +_jr0 {
> + u-boot,dm-spl;
> +};
> +
> +_jr1 {
> + u-boot,dm-spl;
> +};
> +
> +_jr2 {
> + u-boot,dm-spl;
> +};
> +
> {
> u-boot,dm-spl;
> };
> diff --git a/arch/arm/dts/imx8mn.dtsi b/arch/arm/dts/imx8mn.dtsi
> index edcb415b53..1820a5af37 100644
> --- a/arch/arm/dts/imx8mn.dtsi
> +++ b/arch/arm/dts/imx8mn.dtsi
> @@ -822,6 +822,7 @@
> compatible = "fsl,sec-v4.0-job-ring";
> reg = <0x1000 0x1000>;
> interrupts = IRQ_TYPE_LEVEL_HIGH>;
> +status = "disabled";
ditto
> };
>
> sec_jr1: jr@2000 {
> diff --git a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> index ab849ebaac..52f473dc52 100644
> --- a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> - * Copyright 2019 NXP
> + * Copyright 2019, 2021 NXP
> */
>
> #include "imx8mp-u-boot.dtsi"
> @@ -67,6 +67,22 @@
> u-boot,dm-spl;
> };
>
> + {
> + u-boot,dm-spl;
> +};
> +
> +_jr0 {
> + u-boot,dm-spl;
> +};
> +
> +_jr1 {
> + u-boot,dm-spl;
> +};
> +
> +_jr2 {
> + u-boot,dm-spl;
> +};
> +
> {
> u-boot,dm-spl;
> };
> diff --git a/arch/arm/dts/imx8mp.dtsi b/arch/arm/dts/imx8mp.dtsi
> index c2d51a46cb..57b01c3a57 100644
> --- a/arch/arm/dts/imx8mp.dtsi
> +++ b/arch/arm/dts/imx8mp.dtsi
> @@ -624,6 +624,7 @@
> compatible = "fsl,sec-v4.0-job-ring";
> reg = <0x1000 0x1000>;
> interrupts = IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
ditto
> };
>
> sec_jr1: jr@2000 {
> diff --git a/arch/arm/dts/imx8mq.dtsi b/arch/arm/dts/imx8mq.dtsi
> index a44f729d0e..ecab44ca13 100644
> --- a/arch/arm/dts/imx8mq.dtsi
> +++ b/arch/arm/dts/imx8mq.dtsi
> @@ -955,6 +955,7 @@
> compatible = "fsl,sec-v4.0-job-ring";
> reg = <0x1000 0x1000>;
>
[PATCH u-boot-marvell] tools: kwboot: Do not send magic seq when changing baudrate back to 115200
From: Pali Rohár
After successful transfer of whole image only two things can happen:
- BootROM starts execution of data block, which changes UART baudrate
back to 115200 Bd,
- board crashes and causes CPU reset
In both cases UART baudrate is reset to the default speed. So there is
no need to send special magic sequence to inform kwboot that baudrate is
going to be reset and kwboot does not need to wait for this event and
can do it immediately after BootROM acknowledges end of xmodem transfer.
Move ARM code for sending magic sequence from main baudrate change
section to binhdr_pre section which is executed only before changing
baudrate from the default value of 115200 Bd to some new value. Remove
kwboot code waiting for magic sequence after successful xmodem transfer.
Rationale: sometimes when using very high UART speeds, magic sequence is
damaged and kwboot fails at this last stage. Removal of this magic
sequence makes booting more stable.
Data transfer protocol (xmodem) is using checksums and retransmit, so it
already deals with possible errors on transfer line.
Signed-off-by: Pali Rohár
Signed-off-by: Marek Behún
---
tools/kwboot.c | 115 ++---
1 file changed, 60 insertions(+), 55 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 359b43c0d8..bacca15301 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -81,23 +81,15 @@ struct kwboot_block {
/* ARM code to change baudrate */
static unsigned char kwboot_baud_code[] = {
/* ; #define UART_BASE 0xd0012000 */
- /* ; #define THR 0x00 */
/* ; #define DLL 0x00 */
/* ; #define DLH 0x04 */
/* ; #define LCR 0x0c */
/* ; #define DLAB0x80 */
/* ; #define LSR 0x14 */
- /* ; #define THRE0x20 */
/* ; #define TEMT0x40 */
/* ; #define DIV_ROUND(a, b) ((a + b/2) / b) */
/* ; */
/* ; u32 set_baudrate(u32 old_b, u32 new_b) { */
- /* ; const u8 *str = "$baudratechange"; */
- /* ; u8 c; */
- /* ; do { */
- /* ; c = *str++;*/
- /* ; writel(UART_BASE + THR, c);*/
- /* ; } while (c); */
/* ; while */
/* ; (!(readl(UART_BASE + LSR) & TEMT)); */
/* ; u32 lcr = readl(UART_BASE + LCR); */
@@ -120,29 +112,6 @@ static unsigned char kwboot_baud_code[] = {
0x0d, 0x02, 0xa0, 0xe3, /* mov r0, #0xd000 */
0x12, 0x0a, 0x80, 0xe3, /* orr r0, r0, #0x12000 */
- /* ; r2 = address of preamble string */
- 0xc8, 0x20, 0x8f, 0xe2, /* adr r2, preamble */
-
- /* ; Send preamble string over UART */
- /* .Lloop_preamble: */
- /**/
- /* ; Wait until Transmitter Holding is Empty */
- /* .Lloop_thre: */
- /* ; r1 = UART_BASE[LSR] & THRE */
- 0x14, 0x10, 0x90, 0xe5, /* ldr r1, [r0, #0x14] */
- 0x20, 0x00, 0x11, 0xe3, /* tst r1, #0x20*/
- 0xfc, 0xff, 0xff, 0x0a, /* beq .Lloop_thre */
-
- /* ; Put character into Transmitter FIFO */
- /* ; r1 = *r2++ */
- 0x01, 0x10, 0xd2, 0xe4, /* ldrb r1, [r2], #1 */
- /* ; UART_BASE[THR] = r1 */
- 0x00, 0x10, 0x80, 0xe5, /* str r1, [r0, #0x0] */
-
- /* ; Loop until end of preamble string */
- 0x00, 0x00, 0x51, 0xe3, /* cmp r1, #0 */
- 0xf8, 0xff, 0xff, 0x1a, /* bne .Lloop_preamble */
-
Re: [PATCH 0/3] rockchip: sdhci: Add HS400 Enhanced Strobe support
On 01/11/2021 14:18, Jack Mitchell wrote:
> On 01/11/2021 09:07, Alper Nebi Yasak wrote:
>> I'm trying to make my gru-kevin's eMMC work properly (it times out while
>> tuning for HS400 and stops working when reinitialized via "mmc dev 0").
>
> I'm also experiencing issue with the re-init of emmc on a 3399 platform,
> did you come to any conclusions on the reason? It works fine to load
> u-boot proper from SPL but then fails in u-boot proper when attempting
> to perform any mmc activity.
Not really. But I have a nice hack to keep it in a working state:
diff --git a/cmd/mmc.c b/cmd/mmc.c
index 96d81ffdf368..83bd18e34609 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -129,10 +129,13 @@ static struct mmc *__init_mmc_device(...)
if (!mmc) {
printf("no mmc device at slot %x\n", dev);
return NULL;
}
+ if (mmc->cfg->host_caps & MMC_CAP_NONREMOVABLE)
+ force_init = false;
+
if (!mmc_getcd(mmc))
force_init = true;
if (force_init)
mmc->has_init = 0;
Re: [PATCH v2 4/4] fpga: zynqmp: support loading authenticated images
On 11/1/21 11:47, Oleksandr Suvorov wrote:
Add supporting new compatible string "u-boot,zynqmp-fpga-ddrauth" to
handle loading authenticated images (DDR).
Based on solution by Jorge Ramirez-Ortiz
Signed-off-by: Oleksandr Suvorov
Co-developed-by: Ricardo Salveti
Signed-off-by: Ricardo Salveti
Tested-by: Ricardo Salveti
---
Changes in v2:
- add function fit_fpga_load() to simplify calls of fpga_load()
from contexts without a compatible attribute.
- move all ZynqMP-specific logic to drivers/fpga/zynqmppl.c
- prepare for passing a "compatible" FDT property to any fpga driver.
drivers/fpga/zynqmppl.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/fpga/zynqmppl.c b/drivers/fpga/zynqmppl.c
index 8ff12bf50a..ce25381890 100644
--- a/drivers/fpga/zynqmppl.c
+++ b/drivers/fpga/zynqmppl.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -209,6 +210,26 @@ static int zynqmp_load(xilinx_desc *desc, const void *buf,
size_t bsize,
u32 buf_lo, buf_hi;
u32 ret_payload[PAYLOAD_ARG_CNT];
bool xilfpga_old = false;
+ fpga_desc *fdesc = container_of((void *)desc, fpga_desc, devdesc);
+
+ if (fdesc && fdesc->compatible &&
+ !strcmp(fdesc->compatible, "u-boot,zynqmp-fpga-ddrauth")) {
+#if CONFIG_IS_ENABLED(FPGA_LOAD_SECURE)
+ struct fpga_secure_info info = { 0 };
+
+ if (!desc->operations->loads) {
+ printf("%s: Missing load operation\n", __func__);
+ return FPGA_FAIL;
+ }
+ /* DDR authentication */
+ info.authflag = 1;
+ info.encflag = 2;
+ return desc->operations->loads(desc, buf, bsize, );
+#else
+ printf("No support for %s\n", fdesc->compatible);
+ return FPGA_FAIL;
+#endif
+ }
if (zynqmp_firmware_version() <= PMUFW_V1_0) {
puts("WARN: PMUFW v1.0 or less is detected\n");
This is fine but I would like to also see update in documentation to
describe that possible/supported types.
Thanks,
Michal
Re: [PATCH v2 3/4] fpga: add fit_fpga_load function
On 11/1/21 11:47, Oleksandr Suvorov wrote:
Introduce a function which passes an fpga compatible string from
FIT images to FPGA drivers. This lets the different implementations
decide how to handle it.
Some code of Jorge Ramirez-Ortiz is reused.
Signed-off-by: Oleksandr Suvorov
---
(no changes since v1)
common/spl/spl_fit.c | 6 ++
drivers/fpga/fpga.c | 26 --
include/fpga.h | 4
3 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 5fe0273d66..bd29e8c59d 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -580,11 +580,9 @@ static int spl_fit_upload_fpga(struct spl_fit_info *ctx,
int node,
compatible = fdt_getprop(ctx->fit, node, "compatible", NULL);
if (!compatible)
warn_deprecated("'fpga' image without 'compatible' property");
- else if (strcmp(compatible, "u-boot,fpga-legacy"))
- printf("Ignoring compatible = %s property\n", compatible);
- ret = fpga_load(0, (void *)fpga_image->load_addr, fpga_image->size,
- BIT_FULL);
+ ret = fit_fpga_load(0, (void *)fpga_image->load_addr, fpga_image->size,
+ BIT_FULL, compatible);
if (ret) {
printf("%s: Cannot load the image to the FPGA\n", __func__);
return ret;
diff --git a/drivers/fpga/fpga.c b/drivers/fpga/fpga.c
index 3b0a44b242..e4b5dd392e 100644
--- a/drivers/fpga/fpga.c
+++ b/drivers/fpga/fpga.c
@@ -249,15 +249,31 @@ int fpga_loads(int devnum, const void *buf, size_t size,
}
#endif
+int fit_fpga_load(int devnum, const void *buf, size_t bsize,
+ bitstream_type bstype, const char *compatible)
+{
+ fpga_desc *desc = (fpga_desc *) fpga_validate(devnum, buf, bsize,
+ (char *)__func__);
+
nit: Better to separate it:
fpga_desc *desc;
desc = (fpga_desc *) fpga_validate(devnum, buf, bsize, (char *)__func__);
if (!desc)
...
+ if (!desc)
+ return FPGA_FAIL;
+ /*
+* Store the compatible string to proceed it in underlying
+* functions
+*/
+ desc->compatible = (char *)compatible;
+
+ return fpga_load(devnum, buf, bsize, bstype);
+}
/*
- * Generic multiplexing code
+ * Generic multiplexing code:
+ * Each architecture must handle the mandatory FPGA DT compatible property.
*/
int fpga_load(int devnum, const void *buf, size_t bsize, bitstream_type
bstype)
{
int ret_val = FPGA_FAIL; /* assume failure */
const fpga_desc *desc = fpga_validate(devnum, buf, bsize,
(char *)__func__);
-
this should break the rule that you should separate variable
declaration/definitions from the actual code. Do it via two steps as is
described above.
And in this content it is separate change.
if (desc) {
switch (desc->devtype) {
case fpga_xilinx:
@@ -270,6 +286,9 @@ int fpga_load(int devnum, const void *buf, size_t bsize,
bitstream_type bstype)
break;
case fpga_altera:
#if defined(CONFIG_FPGA_ALTERA)
+ if (strcmp(desc->compatible, "u-boot,fpga-legacy"))
strncmp please
+ printf("Ignoring compatible = %s property\n",
+ desc->compatible);
ret_val = altera_load(desc->devdesc, buf, bsize);
#else
fpga_no_sup((char *)__func__, "Altera devices");
@@ -277,6 +296,9 @@ int fpga_load(int devnum, const void *buf, size_t bsize,
bitstream_type bstype)
break;
case fpga_lattice:
#if defined(CONFIG_FPGA_LATTICE)
+ if (strcmp(desc->compatible, "u-boot,fpga-legacy"))
+ printf("Ignoring compatible = %s property\n",
+ desc->compatible);
ret_val = lattice_load(desc->devdesc, buf, bsize);
#else
fpga_no_sup((char *)__func__, "Lattice devices");
diff --git a/include/fpga.h b/include/fpga.h
index ec5144334d..2891f32106 100644
--- a/include/fpga.h
+++ b/include/fpga.h
@@ -35,6 +35,7 @@ typedef enum {/* typedef fpga_type */
typedef struct { /* typedef fpga_desc */
fpga_type devtype; /* switch value to select sub-functions */
void *devdesc; /* real device descriptor */
+ char *compatible; /* device compatible string */
} fpga_desc; /* end, typedef fpga_desc */
typedef struct {/* typedef fpga_desc */
@@ -63,6 +64,9 @@ int fpga_add(fpga_type devtype, void *desc);
int fpga_count(void);
const fpga_desc *const fpga_get_desc(int devnum);
int fpga_is_partial_data(int devnum, size_t img_len);
+/* the DT
Re: [PATCH v2 2/4] cmd: fpga: Separating the support of fpga loads
On 11/1/21 11:47, Oleksandr Suvorov wrote: This patch allows enabling support of "fpga lodas command which loads secure bitstreams (authenticated or encrypted, or both) independently in SPL and in u-boot. Signed-off-by: Oleksandr Suvorov --- (no changes since v1) cmd/Kconfig | 9 + cmd/fpga.c | 8 SPL doesn't use commands that's why this is quite weird. M
Re: [PATCH v2 1/4] fpga: add option for loading FPGA secure bitstreams
On 11/1/21 11:47, Oleksandr Suvorov wrote:
It allows using this feature without enabling the "fpga loads"
command.
Signed-off-by: Oleksandr Suvorov
---
(no changes since v1)
cmd/Kconfig | 3 ++-
drivers/fpga/Kconfig| 14 ++
drivers/fpga/fpga.c | 2 +-
drivers/fpga/xilinx.c | 2 +-
drivers/fpga/zynqmppl.c | 4 ++--
5 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 5b30b13e43..270d1765d3 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -949,8 +949,9 @@ config CMD_FPGA_LOADP
a partial bitstream.
config CMD_FPGA_LOAD_SECURE
- bool "fpga loads - loads secure bitstreams (Xilinx only)"
+ bool "fpga loads - loads secure bitstreams"
depends on CMD_FPGA
+ select FPGA_LOAD_SECURE
help
Enables the fpga loads command which is used to load secure
(authenticated or encrypted or both) bitstreams on to FPGA.
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index dc0b3dd31b..262f95a252 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -85,4 +85,18 @@ config FPGA_ZYNQPL
Enable FPGA driver for loading bitstream in BIT and BIN format
on Xilinx Zynq devices.
+config FPGA_LOAD_SECURE
+ bool "Enable loading secure bitstreams"
+ depends on FPGA
+ help
+ Enables the fpga loads() functions that are used to load secure
+ (authenticated or encrypted or both) bitstreams on to FPGA.
+
+config SPL_FPGA_LOAD_SECURE
+ bool "Enable loading secure bitstreams for SPL"
+ depends on FPGA
+ help
+ Enables the fpga loads() functions that are used to load secure
+ (authenticated or encrypted or both) bitstreams on to FPGA.
+
endmenu
diff --git a/drivers/fpga/fpga.c b/drivers/fpga/fpga.c
index fe3dfa1233..3b0a44b242 100644
--- a/drivers/fpga/fpga.c
+++ b/drivers/fpga/fpga.c
@@ -220,7 +220,7 @@ int fpga_fsload(int devnum, const void *buf, size_t size,
}
#endif
-#if defined(CONFIG_CMD_FPGA_LOAD_SECURE)
+#if CONFIG_IS_ENABLED(FPGA_LOAD_SECURE)
int fpga_loads(int devnum, const void *buf, size_t size,
struct fpga_secure_info *fpga_sec_info)
{
diff --git a/drivers/fpga/xilinx.c b/drivers/fpga/xilinx.c
index cbebefb55f..6bc1bc491f 100644
--- a/drivers/fpga/xilinx.c
+++ b/drivers/fpga/xilinx.c
@@ -172,7 +172,7 @@ int xilinx_loadfs(xilinx_desc *desc, const void *buf,
size_t bsize,
}
#endif
-#if defined(CONFIG_CMD_FPGA_LOAD_SECURE)
+#if CONFIG_IS_ENABLED(FPGA_LOAD_SECURE)
int xilinx_loads(xilinx_desc *desc, const void *buf, size_t bsize,
struct fpga_secure_info *fpga_sec_info)
{
diff --git a/drivers/fpga/zynqmppl.c b/drivers/fpga/zynqmppl.c
index 6b394869db..8ff12bf50a 100644
--- a/drivers/fpga/zynqmppl.c
+++ b/drivers/fpga/zynqmppl.c
@@ -245,7 +245,7 @@ static int zynqmp_load(xilinx_desc *desc, const void *buf,
size_t bsize,
return ret;
}
-#if defined(CONFIG_CMD_FPGA_LOAD_SECURE) && !defined(CONFIG_SPL_BUILD)
+#if CONFIG_IS_ENABLED(FPGA_LOAD_SECURE)
static int zynqmp_loads(xilinx_desc *desc, const void *buf, size_t bsize,
struct fpga_secure_info *fpga_sec_info)
{
@@ -306,7 +306,7 @@ static int zynqmp_pcap_info(xilinx_desc *desc)
struct xilinx_fpga_op zynqmp_op = {
.load = zynqmp_load,
-#if defined(CONFIG_CMD_FPGA_LOAD_SECURE) && !defined(CONFIG_SPL_BUILD)
+#if CONFIG_IS_ENABLED(FPGA_LOAD_SECURE)
.loads = zynqmp_loads,
#endif
.info = zynqmp_pcap_info,
Acked-by: Michal Simek
Thanks,
Michal
Re: [PATCH v1] arm: xea: Modify board code to generate single binary u-boot
Hi Simon, > Hi Lukasz, > > On Sat, 23 Oct 2021 at 09:04, Lukasz Majewski wrote: > > > > This change provides the possibility to build XEA (imx287 based) > > board U-Boot as a single binary (without support for > > CONFIG_SPL_FRAMEWORK). > > > > The generated u-boot.sb can be used in the factory environment to > > for example perform initial setup or HW testing. > > > > It can be used with 'uuu' utility > > (SDPS: boot -f /srv/tftp/xea/u-boot.sb) > > > > In the configs/imx28_xea_defconfig one needs to disable following > > configs: > > Something is missing here. I've posted the v2 of this patch with this information added. > > > > > The board_init_ll() is used in arch/arm/cpu/arm926ejs/mxs/start.S, > > which is utilized when CONFIG_SPL_FRAMEWORK is disabled. > > > > However, when it is enabled the arch/arm/cpu/arm926ejs/start.S is > > used, which requires the lowlevel_init() function. > > > > Signed-off-by: Lukasz Majewski > > > > --- > > > > board/liebherr/xea/spl_xea.c | 7 +++ > > board/liebherr/xea/xea.c | 2 +- > > 2 files changed, 8 insertions(+), 1 deletion(-) > > Could you add a Kconifig to control this feature and add something to > the board docs? This don't need any special Kconfig option. You just undefine the CONFIG_SPL_FRAMEWORK, and that's all. As fair as I can tell - the CONFIG_SPL_FRAMEWORK option is used with for example imx28evk board. The issue here is that imx28 SoC needs u-boot.sb to boot up when USB is used to debrick it (this is somewhat the legacy approach with a single binary u-boot). > > Regards, > Simon Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpVQlVmQmlmM.pgp Description: OpenPGP digital signature
Re: [PATCH 0/3] rockchip: sdhci: Add HS400 Enhanced Strobe support
On 01/11/2021 09:07, Alper Nebi Yasak wrote: > I'm trying to make my gru-kevin's eMMC work properly (it times out while > tuning for HS400 and stops working when reinitialized via "mmc dev 0"). I'm also experiencing issue with the re-init of emmc on a 3399 platform, did you come to any conclusions on the reason? It works fine to load u-boot proper from SPL but then fails in u-boot proper when attempting to perform any mmc activity. Regards, Jack. > While experimenting with what works on my board I ended up implementing > HS400ES support. And while I'm at it, I decided to do it for RK3568 as > well since it turned out easy enough. Both are ported from relevant > Linux drivers. > > I'm trying this with "load mmc 0:1 0xd000 /bigfile $size" and getting > the following speeds; and with "mmc info" the following differences: > > gru-kevin mmc0 | w/o this series | w/ this series > +---+--- > Bus Speed | 5200 | 2 > Mode| MMC High Speed (52MHz)| HS400ES (200 MHz) > 8MiB Load Speed | ~9.5 MiB/s| ~51.5 MiB/s > 256MiB Load Speed | ~177.8 MiB/s | ~114.5 MiB/s > > Listing partitions, listing files, reading files and the loaded bytes > all look fine to me, but I'm not sure I haven't missed anything. > > > Alper Nebi Yasak (3): > mmc: sdhci: Add HS400 Enhanced Strobe support > rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3399 > rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3568 > > drivers/mmc/rockchip_sdhci.c | 51 > drivers/mmc/sdhci.c | 18 + > include/sdhci.h | 1 + > 3 files changed, 70 insertions(+) > -- Jack Mitchell, Consultant https://www.tuxable.co.uk
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi Simon,
On Thu, 28 Oct 2021 at 05:51, Simon Glass wrote:
>
> Hi Ilias,
>
> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> wrote:
> >
> > Hi Simon,
> >
> > A bit late to the party, sorry!
>
> (Did you remember the beer?
We'll probably need something stronger to sort this out :)
> I am replying to this but I don't think it
> is all that helpful for me to reply to a lot of things on this thread,
> since I would not be adding much to my cover letter and patches)
>
> >
> > [...]
> >
> > > >
> > > > I really want to see what the binary case looks like since we could then
> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > then also do a rpi_arm32_defconfig too.
> > > >
> > > > I want to see less device trees in U-Boot sources, if they can come
> > > > functionally correct from the hardware/our caller.
> > > >
> > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > > > use the device tree from build time at run time, ignoring the device
> > > > tree provided to us at run time by the caller.
> > >
> > > Firstly I should say that I find building firmware very messy and
> > > confusing these days. Lots of things to build and it's hard to find
> > > the instructions. It doesn't have to be that way, but if we carry on
> > > as we are, it will continue to be messy and in five years you will
> > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > objective here is to simplify things, bringing some consistency to the
> > > different components. Binman was one effort there. I feel that putting
> > > at least the U-Boot house in order, in my role as devicetree
> > > maintainer (and as author of devicetree support in U-Boot back in
> > > 2011), is the next step.
> > >
> > > If we set things up correctly and agree on the bindings, devicetree
> > > can be the unifying configuration mechanism through the whole of
> > > firmware (except for very early bits) and into the OS, this will set
> > > us up very well to deal with the complexity that is coming.
> > >
> > > Anyway, here are the mental steps that I've gone through over the past
> > > two months:
> > >
> > > Step 1: At present, some people think U-Boot is not even allowed to
> > > have its own nodes/properties in the DT. It is an abuse of the
> > > devicetree standard, like the /chosen node but with less history. We
> > > should sacrifice efficiency, expedience and expandability on the altar
> > > of 'devicetree is a hardware description'. How do we get over that
> > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > > for its own purposes, as well as for booting the OS. I am not saying
> > > it always has to have those properties, but with existing features
> > > like verified boot, SPL as well as complex firmware images where
> > > U-Boot needs to be able to find things in the image, it is essential.
> > > So let's just assume that we need this everywhere, since we certainly
> > > need it in at least some places.
> > >
> > > (stop reading here if you disagree, because nothing below will make
> > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > OF_CONTROL :-)
> >
> > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
> > that to the DTs that are copied over from linux isn't imho. There are
> > various reasons for that. First of all syncing device trees is a huge pain
> > and that's probably one of the main reasons our DTs are out of sync for a
> > large number of boards.
> > The point is this was fine in 2011 were we had SPL only, but the reality
> > today is completely different. There's previous stage boot loaders (and
> > enough cases were vendors prefer those over SPL). If that bootloader needs
> > to use it's own device tree for whatever reason, imposing restrictions on
> > it wrt to the device tree it has to include, and require them to have
> > knowledge of U-Boot and it's internal config mechanism makes no sense not
> > to mention it doesn't scale at all.
>
> I think the solution here may be the binman image packer. It works
> from a description of the image (i.e. is data-driver) and can collect
> all the pieces together. The U-Boot properties (and the ones required
> by TF-A, etc.) can be added at package time.
I am not sure I am following you here or why binman is relevant to
this discussion. If the boot process doesn't require a FIP (e.g SPL
+ U-Boot proper or SPL -> EL3 -> U-Boot proper or TF-A + U-Boot) then
using binman makes a lot of sense. If the boot process is TF-A ->
U-Boot and requires a FIP, TF-A has it's own set of tools for
preparing that [1] [2] , why would we want to teach binman FIP
packaging? And if we do are you willing to keep it up to date with
everything they come up with? IOW packaging the firmware is not
U-Boot's responsibility, it's the vendors. Why should he not be able
to choose FIP? (ST already changed that in u-boot btw).
>
> If you think about it, it doesn't matter
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
On Tue, 26 Oct 2021 at 01:33, Simon Glass wrote: > > Add this file, generated from qemu, so there is a reference devicetree > in the U-Boot tree. > > Signed-off-by: Simon Glass Note that the dtb you get from QEMU is only guaranteed to work if: 1) you run it on the exact same QEMU version you generated it with 2) you pass QEMU the exact same command line arguments you used when you generated it thanks -- PMM
[PATCH v2 3/4] fpga: add fit_fpga_load function
Introduce a function which passes an fpga compatible string from
FIT images to FPGA drivers. This lets the different implementations
decide how to handle it.
Some code of Jorge Ramirez-Ortiz is reused.
Signed-off-by: Oleksandr Suvorov
---
(no changes since v1)
common/spl/spl_fit.c | 6 ++
drivers/fpga/fpga.c | 26 --
include/fpga.h | 4
3 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 5fe0273d66..bd29e8c59d 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -580,11 +580,9 @@ static int spl_fit_upload_fpga(struct spl_fit_info *ctx,
int node,
compatible = fdt_getprop(ctx->fit, node, "compatible", NULL);
if (!compatible)
warn_deprecated("'fpga' image without 'compatible' property");
- else if (strcmp(compatible, "u-boot,fpga-legacy"))
- printf("Ignoring compatible = %s property\n", compatible);
- ret = fpga_load(0, (void *)fpga_image->load_addr, fpga_image->size,
- BIT_FULL);
+ ret = fit_fpga_load(0, (void *)fpga_image->load_addr, fpga_image->size,
+ BIT_FULL, compatible);
if (ret) {
printf("%s: Cannot load the image to the FPGA\n", __func__);
return ret;
diff --git a/drivers/fpga/fpga.c b/drivers/fpga/fpga.c
index 3b0a44b242..e4b5dd392e 100644
--- a/drivers/fpga/fpga.c
+++ b/drivers/fpga/fpga.c
@@ -249,15 +249,31 @@ int fpga_loads(int devnum, const void *buf, size_t size,
}
#endif
+int fit_fpga_load(int devnum, const void *buf, size_t bsize,
+ bitstream_type bstype, const char *compatible)
+{
+ fpga_desc *desc = (fpga_desc *) fpga_validate(devnum, buf, bsize,
+ (char *)__func__);
+
+ if (!desc)
+ return FPGA_FAIL;
+ /*
+* Store the compatible string to proceed it in underlying
+* functions
+*/
+ desc->compatible = (char *)compatible;
+
+ return fpga_load(devnum, buf, bsize, bstype);
+}
/*
- * Generic multiplexing code
+ * Generic multiplexing code:
+ * Each architecture must handle the mandatory FPGA DT compatible property.
*/
int fpga_load(int devnum, const void *buf, size_t bsize, bitstream_type bstype)
{
int ret_val = FPGA_FAIL; /* assume failure */
const fpga_desc *desc = fpga_validate(devnum, buf, bsize,
(char *)__func__);
-
if (desc) {
switch (desc->devtype) {
case fpga_xilinx:
@@ -270,6 +286,9 @@ int fpga_load(int devnum, const void *buf, size_t bsize,
bitstream_type bstype)
break;
case fpga_altera:
#if defined(CONFIG_FPGA_ALTERA)
+ if (strcmp(desc->compatible, "u-boot,fpga-legacy"))
+ printf("Ignoring compatible = %s property\n",
+ desc->compatible);
ret_val = altera_load(desc->devdesc, buf, bsize);
#else
fpga_no_sup((char *)__func__, "Altera devices");
@@ -277,6 +296,9 @@ int fpga_load(int devnum, const void *buf, size_t bsize,
bitstream_type bstype)
break;
case fpga_lattice:
#if defined(CONFIG_FPGA_LATTICE)
+ if (strcmp(desc->compatible, "u-boot,fpga-legacy"))
+ printf("Ignoring compatible = %s property\n",
+ desc->compatible);
ret_val = lattice_load(desc->devdesc, buf, bsize);
#else
fpga_no_sup((char *)__func__, "Lattice devices");
diff --git a/include/fpga.h b/include/fpga.h
index ec5144334d..2891f32106 100644
--- a/include/fpga.h
+++ b/include/fpga.h
@@ -35,6 +35,7 @@ typedef enum {/* typedef fpga_type */
typedef struct { /* typedef fpga_desc */
fpga_type devtype; /* switch value to select sub-functions */
void *devdesc; /* real device descriptor */
+ char *compatible; /* device compatible string */
} fpga_desc; /* end, typedef fpga_desc */
typedef struct {/* typedef fpga_desc */
@@ -63,6 +64,9 @@ int fpga_add(fpga_type devtype, void *desc);
int fpga_count(void);
const fpga_desc *const fpga_get_desc(int devnum);
int fpga_is_partial_data(int devnum, size_t img_len);
+/* the DT compatible property must be handled by the different FPGA archs */
+int fit_fpga_load(int devnum, const void *buf, size_t bsize,
+ bitstream_type bstype, const char *compatible);
int fpga_load(int devnum, const void *buf, size_t bsize,
bitstream_type bstype);
int fpga_fsload(int devnum, const void *buf, size_t size,
--
2.31.1
[PATCH v2 4/4] fpga: zynqmp: support loading authenticated images
Add supporting new compatible string "u-boot,zynqmp-fpga-ddrauth" to
handle loading authenticated images (DDR).
Based on solution by Jorge Ramirez-Ortiz
Signed-off-by: Oleksandr Suvorov
Co-developed-by: Ricardo Salveti
Signed-off-by: Ricardo Salveti
Tested-by: Ricardo Salveti
---
Changes in v2:
- add function fit_fpga_load() to simplify calls of fpga_load()
from contexts without a compatible attribute.
- move all ZynqMP-specific logic to drivers/fpga/zynqmppl.c
- prepare for passing a "compatible" FDT property to any fpga driver.
drivers/fpga/zynqmppl.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/fpga/zynqmppl.c b/drivers/fpga/zynqmppl.c
index 8ff12bf50a..ce25381890 100644
--- a/drivers/fpga/zynqmppl.c
+++ b/drivers/fpga/zynqmppl.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -209,6 +210,26 @@ static int zynqmp_load(xilinx_desc *desc, const void *buf,
size_t bsize,
u32 buf_lo, buf_hi;
u32 ret_payload[PAYLOAD_ARG_CNT];
bool xilfpga_old = false;
+ fpga_desc *fdesc = container_of((void *)desc, fpga_desc, devdesc);
+
+ if (fdesc && fdesc->compatible &&
+ !strcmp(fdesc->compatible, "u-boot,zynqmp-fpga-ddrauth")) {
+#if CONFIG_IS_ENABLED(FPGA_LOAD_SECURE)
+ struct fpga_secure_info info = { 0 };
+
+ if (!desc->operations->loads) {
+ printf("%s: Missing load operation\n", __func__);
+ return FPGA_FAIL;
+ }
+ /* DDR authentication */
+ info.authflag = 1;
+ info.encflag = 2;
+ return desc->operations->loads(desc, buf, bsize, );
+#else
+ printf("No support for %s\n", fdesc->compatible);
+ return FPGA_FAIL;
+#endif
+ }
if (zynqmp_firmware_version() <= PMUFW_V1_0) {
puts("WARN: PMUFW v1.0 or less is detected\n");
--
2.31.1
[PATCH v2 2/4] cmd: fpga: Separating the support of fpga loads
This patch allows enabling support of "fpga lodas command which loads
secure bitstreams (authenticated or encrypted, or both) independently
in SPL and in u-boot.
Signed-off-by: Oleksandr Suvorov
---
(no changes since v1)
cmd/Kconfig | 9 +
cmd/fpga.c | 8
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 270d1765d3..3702a022e6 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -956,6 +956,15 @@ config CMD_FPGA_LOAD_SECURE
Enables the fpga loads command which is used to load secure
(authenticated or encrypted or both) bitstreams on to FPGA.
+config CMD_SPL_FPGA_LOAD_SECURE
+ bool "fpga loads - loads secure bitstreams for SPL"
+ depends on CMD_FPGA && CMD_SPL
+ select SPL_FPGA_LOAD_SECURE
+ help
+ Enables the fpga loads command which is used to load secure
+ (authenticated or encrypted or both) bitstreams on to FPGA from
+ SPL.
+
config CMD_FPGAD
bool "fpgad - dump FPGA registers"
help
diff --git a/cmd/fpga.c b/cmd/fpga.c
index 3fdd0b35e8..9a14618660 100644
--- a/cmd/fpga.c
+++ b/cmd/fpga.c
@@ -67,7 +67,7 @@ static int do_fpga_check_params(long *dev, long *fpga_data,
size_t *data_size,
return 0;
}
-#if defined(CONFIG_CMD_FPGA_LOAD_SECURE)
+#if CONFIG_IS_ENABLED(CMD_FPGA_LOAD_SECURE)
int do_fpga_loads(struct cmd_tbl *cmdtp, int flag, int argc, char *const
argv[])
{
size_t data_size = 0;
@@ -382,7 +382,7 @@ static struct cmd_tbl fpga_commands[] = {
#if defined(CONFIG_CMD_FPGA_LOADMK)
U_BOOT_CMD_MKENT(loadmk, 2, 1, do_fpga_loadmk, "", ""),
#endif
-#if defined(CONFIG_CMD_FPGA_LOAD_SECURE)
+#if CONFIG_IS_ENABLED(CMD_FPGA_LOAD_SECURE)
U_BOOT_CMD_MKENT(loads, 6, 1, do_fpga_loads, "", ""),
#endif
};
@@ -416,7 +416,7 @@ static int do_fpga_wrapper(struct cmd_tbl *cmdtp, int flag,
int argc,
return cmd_process_error(fpga_cmd, ret);
}
-#if defined(CONFIG_CMD_FPGA_LOADFS) || defined(CONFIG_CMD_FPGA_LOAD_SECURE)
+#if defined(CONFIG_CMD_FPGA_LOADFS) || CONFIG_IS_ENABLED(CMD_FPGA_LOAD_SECURE)
U_BOOT_CMD(fpga, 9, 1, do_fpga_wrapper,
#else
U_BOOT_CMD(fpga, 6, 1, do_fpga_wrapper,
@@ -451,7 +451,7 @@ U_BOOT_CMD(fpga, 6, 1, do_fpga_wrapper,
"\tsubimage unit name in the form of addr:"
#endif
#endif
-#if defined(CONFIG_CMD_FPGA_LOAD_SECURE)
+#if CONFIG_IS_ENABLED(CMD_FPGA_LOAD_SECURE)
"Load encrypted bitstream (Xilinx only)\n"
" loads [dev] [address] [size] [auth-OCM-0/DDR-1/noauth-2]\n"
"[enc-devkey(0)/userkey(1)/nenc(2) [Userkey address]\n"
--
2.31.1
[PATCH v2 1/4] fpga: add option for loading FPGA secure bitstreams
It allows using this feature without enabling the "fpga loads"
command.
Signed-off-by: Oleksandr Suvorov
---
(no changes since v1)
cmd/Kconfig | 3 ++-
drivers/fpga/Kconfig| 14 ++
drivers/fpga/fpga.c | 2 +-
drivers/fpga/xilinx.c | 2 +-
drivers/fpga/zynqmppl.c | 4 ++--
5 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 5b30b13e43..270d1765d3 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -949,8 +949,9 @@ config CMD_FPGA_LOADP
a partial bitstream.
config CMD_FPGA_LOAD_SECURE
- bool "fpga loads - loads secure bitstreams (Xilinx only)"
+ bool "fpga loads - loads secure bitstreams"
depends on CMD_FPGA
+ select FPGA_LOAD_SECURE
help
Enables the fpga loads command which is used to load secure
(authenticated or encrypted or both) bitstreams on to FPGA.
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index dc0b3dd31b..262f95a252 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -85,4 +85,18 @@ config FPGA_ZYNQPL
Enable FPGA driver for loading bitstream in BIT and BIN format
on Xilinx Zynq devices.
+config FPGA_LOAD_SECURE
+ bool "Enable loading secure bitstreams"
+ depends on FPGA
+ help
+ Enables the fpga loads() functions that are used to load secure
+ (authenticated or encrypted or both) bitstreams on to FPGA.
+
+config SPL_FPGA_LOAD_SECURE
+ bool "Enable loading secure bitstreams for SPL"
+ depends on FPGA
+ help
+ Enables the fpga loads() functions that are used to load secure
+ (authenticated or encrypted or both) bitstreams on to FPGA.
+
endmenu
diff --git a/drivers/fpga/fpga.c b/drivers/fpga/fpga.c
index fe3dfa1233..3b0a44b242 100644
--- a/drivers/fpga/fpga.c
+++ b/drivers/fpga/fpga.c
@@ -220,7 +220,7 @@ int fpga_fsload(int devnum, const void *buf, size_t size,
}
#endif
-#if defined(CONFIG_CMD_FPGA_LOAD_SECURE)
+#if CONFIG_IS_ENABLED(FPGA_LOAD_SECURE)
int fpga_loads(int devnum, const void *buf, size_t size,
struct fpga_secure_info *fpga_sec_info)
{
diff --git a/drivers/fpga/xilinx.c b/drivers/fpga/xilinx.c
index cbebefb55f..6bc1bc491f 100644
--- a/drivers/fpga/xilinx.c
+++ b/drivers/fpga/xilinx.c
@@ -172,7 +172,7 @@ int xilinx_loadfs(xilinx_desc *desc, const void *buf,
size_t bsize,
}
#endif
-#if defined(CONFIG_CMD_FPGA_LOAD_SECURE)
+#if CONFIG_IS_ENABLED(FPGA_LOAD_SECURE)
int xilinx_loads(xilinx_desc *desc, const void *buf, size_t bsize,
struct fpga_secure_info *fpga_sec_info)
{
diff --git a/drivers/fpga/zynqmppl.c b/drivers/fpga/zynqmppl.c
index 6b394869db..8ff12bf50a 100644
--- a/drivers/fpga/zynqmppl.c
+++ b/drivers/fpga/zynqmppl.c
@@ -245,7 +245,7 @@ static int zynqmp_load(xilinx_desc *desc, const void *buf,
size_t bsize,
return ret;
}
-#if defined(CONFIG_CMD_FPGA_LOAD_SECURE) && !defined(CONFIG_SPL_BUILD)
+#if CONFIG_IS_ENABLED(FPGA_LOAD_SECURE)
static int zynqmp_loads(xilinx_desc *desc, const void *buf, size_t bsize,
struct fpga_secure_info *fpga_sec_info)
{
@@ -306,7 +306,7 @@ static int zynqmp_pcap_info(xilinx_desc *desc)
struct xilinx_fpga_op zynqmp_op = {
.load = zynqmp_load,
-#if defined(CONFIG_CMD_FPGA_LOAD_SECURE) && !defined(CONFIG_SPL_BUILD)
+#if CONFIG_IS_ENABLED(FPGA_LOAD_SECURE)
.loads = zynqmp_loads,
#endif
.info = zynqmp_pcap_info,
--
2.31.1
[PATCH v2 0/4] fpga: zynqmp: Adding support of loading authenticated images
This patchset introduces support for the authenticated FPGA images on ZynqMP boards, besides that introducing common way to pass the compatible property to any fpga driver. It bases on the initial work by Jorge Ramirez-Ortiz https://patchwork.ozlabs.org/project/uboot/patch/20211015091506.2602-1-jo...@foundries.io/ https://patchwork.ozlabs.org/project/uboot/patch/20211005111324.19749-3-jo...@foundries.io/ Changes in v2: - add function fit_fpga_load() to simplify calls of fpga_load() from contexts without a compatible attribute. - move all ZynqMP-specific logic to drivers/fpga/zynqmppl.c - prepare for passing a "compatible" FDT property to any fpga driver. Oleksandr Suvorov (4): fpga: add option for loading FPGA secure bitstreams cmd: fpga: Separating the support of fpga loads fpga: add fit_fpga_load function fpga: zynqmp: support loading authenticated images cmd/Kconfig | 12 +++- cmd/fpga.c | 8 common/spl/spl_fit.c| 6 ++ drivers/fpga/Kconfig| 14 ++ drivers/fpga/fpga.c | 28 +--- drivers/fpga/xilinx.c | 2 +- drivers/fpga/zynqmppl.c | 25 +++-- include/fpga.h | 4 8 files changed, 84 insertions(+), 15 deletions(-) -- 2.31.1
Re: [PATCH 0/3] rockchip: sdhci: Add HS400 Enhanced Strobe support
On 01/11/2021 12:19, Jaehoon Chung wrote: > On 11/1/21 6:07 PM, Alper Nebi Yasak wrote: >> I'm trying this with "load mmc 0:1 0xd000 /bigfile $size" and getting >> the following speeds; and with "mmc info" the following differences: >> >> gru-kevin mmc0 | w/o this series | w/ this series >> +---+--- >> Bus Speed | 5200 | 2 >> Mode| MMC High Speed (52MHz)| HS400ES (200 MHz) >> 8MiB Load Speed | ~9.5 MiB/s| ~51.5 MiB/s >> 256MiB Load Speed | ~177.8 MiB/s | ~114.5 MiB/s > > I wonder why HS400ES is lower than High Speed mode in 256MiB Load Speed. I messed up the table, noticed it shortly after sending the series and sent a correction same time as your email. The actual values are: > 8MiB Load Speed | ~9.5 MiB/s| ~177.8 MiB/s > 256MiB Load Speed | ~51.5 MiB/s | ~114.5 MiB/s Sorry for the noise.
Re: [PATCH 2/2] Revert "arch: arm: use dt and UCLASS_SYSCON to get gic lpi details"
On Sun, 31 Oct 2021 16:45:41 +,
"Z.Q. Hou" wrote:
>
>
>
> > -Original Message-
> > From: Marc Zyngier [mailto:m...@kernel.org]
> > Sent: 2021年10月29日 5:09
> > To: Michael Walle
> > Cc: u-boot@lists.denx.de; Vladimir Oltean ; Z.Q.
> > Hou
> > ; Bharat Gooty ;
> > Rayagonda Kokatanur ; Simon Glass
> > ; Priyanka Jain ; Tom Rini
> >
> > Subject: Re: [PATCH 2/2] Revert "arch: arm: use dt and UCLASS_SYSCON to get
> > gic
> > lpi details"
> >
> > On Wed, 27 Oct 2021 17:54:54 +0100,
> > Michael Walle wrote:
> > >
> > > Stop using the device tree as a source for ad-hoc information.
> > >
> > > This reverts commit 2ae7adc659f7fca9ea65df4318e5bca2b8274310.
> > >
> > > Signed-off-by: Michael Walle
> > > ---
> > > arch/arm/Kconfig| 2 -
> > > arch/arm/cpu/armv8/fsl-layerscape/soc.c | 27 +-
> > > arch/arm/include/asm/gic-v3.h | 4 +-
> > > arch/arm/lib/gic-v3-its.c | 66 +++--
> > > 4 files changed, 36 insertions(+), 63 deletions(-)
> > >
> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index
> > > 02f8306f15..86c1ebde05 100644
> > > --- a/arch/arm/Kconfig
> > > +++ b/arch/arm/Kconfig
> > > @@ -82,8 +82,6 @@ config GICV3
> > >
> > > config GIC_V3_ITS
> > > bool "ARM GICV3 ITS"
> > > - select REGMAP
> > > - select SYSCON
> > > select IRQ
> > > help
> > > ARM GICV3 Interrupt translation service (ITS).
> > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > > b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > > index c0e100d21c..a08ed3f544 100644
> > > --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > > +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> >
> > Why is this FSL specific?
> >
> > > @@ -41,11 +41,36 @@ DECLARE_GLOBAL_DATA_PTR; #endif
> > >
> > > #ifdef CONFIG_GIC_V3_ITS
> > > +#define PENDTABLE_MAX_SZ ALIGN(BIT(ITS_MAX_LPI_NRBITS), SZ_64K)
> > > +#define PROPTABLE_MAX_SZ ALIGN(BIT(ITS_MAX_LPI_NRBITS) / 8,
> > SZ_64K)
> >
> > This looks completely wrong.
> >
> > The pending table needs one bit per LPI, and the property table one byte
> > per LPI.
> > Here, you have it the other way around.
>
> It's a typo, will fix after the revert patch applied.
A typo that has the potential to corrupt to corrupt memory. This
clearly was never tested.
>
> > Also, the property table alignment requirement is 4kB, not 64kB,
> > and its size is defined as the maximum number of LPIs - 8192.
>
> As in the accessor gic_lpi_tables_init() there isn't alignment
> operation for both property table and pending table, we have to pass
> a 64KB alignment address, even though the property table only
> requires 4KB alignment.
So how about fixing it?
>
> >
> > Finally, ITS_MAX_LPI_NRBITS is hardcoded to 16, while it can
> > actually vary from 14 to 32 (and even further limited by some
> > hypervisors), depending on the implementation. Granted, this was
> > broken before this patch, and in most cases, 64k is more than
> > enough.
> >
>
> This is only for Layerscape platforms, so hardcoded to 16 bit works.
Let me say it again: hardcoding things for a specific platform for no
good reason is utterly wasteful. There is no reason to write SoC
specific code here, and allocating tables should be done in an
architectural way.
>
> > However, given that this defining the number of LPIs for the
> > lifetime of the system, it would be better to actually allocate
> > what the HW advertises (GICD_TYPER.IDbits, capped by
> > GICD_TYPER.num_LPIs).
> >
> > > +#define GIC_LPI_SIZE ALIGN(cpu_numcores() * PENDTABLE_MAX_SZ
> > > + \
> > > + PROPTABLE_MAX_SZ, SZ_1M)
> >
> > Why the 1MB alignment? There is no such requirement in the
> > architecture (64kB for the pending tables, 4kB for the property
> > table).
>
> This is definition of the size instead of address, 1MB size
> alignment is to ensure we have enough space to do address alignment,
> perhaps 64KB should be enough.
Again: straying out of the architecture requirement is wasteful. The
architecture states all the requirements. How about you follow them
instead of picking random numbers?
>
> >
> > > +static int fdt_add_resv_mem_gic_rd_tables(void *blob, u64 base,
> > > +size_t size) {
> > > + int err;
> > > + struct fdt_memory gic_rd_tables;
> > > +
> > > + gic_rd_tables.start = base;
> > > + gic_rd_tables.end = base + size - 1;
> > > + err = fdtdec_add_reserved_memory(blob, "gic-rd-tables", _rd_tables,
> > > + NULL, 0, NULL, 0);
> > > + if (err < 0)
> > > + debug("%s: failed to add reserved memory: %d\n", __func__, err);
> > > +
> > > + return err;
> > > +}
> > > +
> > > int ls_gic_rd_tables_init(void *blob) {
> > > + u64 gic_lpi_base;
> > > int ret;
> > >
> > > - ret = gic_lpi_tables_init();
> > > + gic_lpi_base = ALIGN(gd->arch.resv_ram - GIC_LPI_SIZE, SZ_64K);
> > > + ret = fdt_add_resv_mem_gic_rd_tables(blob, gic_lpi_base, GIC_LPI_SIZE);
> > > + if (ret)
> > > + return ret;
Re: [PATCH 2/2] efi_selftest: add selftest for EFI_TCG2_PROTOCOL and Measured Boot
Hi Heinrich, Ilias, On Sat, 30 Oct 2021 at 15:18, Heinrich Schuchardt wrote: > > > > Am 30. Oktober 2021 08:02:02 MESZ schrieb Ilias Apalodimas > : > >Hi Heinrich > > > >[...] > > > >> >>> +$(obj)/efi_selftest_tcg2.o: > >> >>> $(obj)/efi_miniapp_file_image_measuredboot.h > >> >>> diff --git a/lib/efi_selftest/efi_selftest_miniapp_measuredboot.c > >> >>> b/lib/efi_selftest/efi_selftest_miniapp_measuredboot.c > >> >> > >> >> Thank you for going the extra mile and adding the test. > >> >> > >> >> Which image is actually loaded seems to be irrelevant for the test. Can > >> >> we reuse an existing one, e.g. efi_miniapp_file_image_return.h? > >> >> > >> >> I guess the PCR related to the loaded image is not checked as it will > >> >> depend on the build tools and date. > >> > > >> > Sorry, I'm doing wrong. > >> > Actually this selftest verifies the PE/COFF image measurement, so > >> > measuremt > >> > will be different depending on the build tools and date. > >> > # In my build environment, timestamp is set to all zero. > >> > > >> > To test the PE/COFF image measurement, I must prepare the > >> > static PE/COFF image. I plan to add efi_miniapp_file_image_measuredboot.h > >> > as a pre-compiled small static PE/COFF image for the measurement test, > >> > instead of adding efi_selftest_miniapp_measuredboot.c or reusing > >> > existing one. > >> > >> You will need one image per UEFI architecture (ia32, x64, arm, aa64, > >> riscv32, riscv64). You could present the image via the > >> EFI_LOAD_FILE2_PROTOCOL, see lib/efi_selftest/efi_selftest_load_file.c. > > > >The EFI TCG2 is governed by a spec. What it basically does is extend > >a number of hardware PCRs with a sha1/256/384/512 for a given image. > >Wouldn't performing the selftest for arm/arm64 be enough? What am I > >missing? > > People on other architectures should be able to run the selftest on a real > device (not QEMU). If you have trouble building for RISC-V, I can help. I am encountering errors in x86_64, riscv32 and riscv64. [x86_64] - swtpm does not work on x86_64 qemu, It is probably U-Boot side issue but I could not run tcg2 efi_selftest for x86_64. = U-Boot 2021.10-00965-g2c308dc11a (Nov 01 2021 - 14:24:18 +0900) CPU: QEMU Virtual CPU version 2.5+ DRAM: 128 MiB Loading Environment from nowhere... OK Incorrect expansion ROM header signature 4daa Model: QEMU x86 (I440FX) Net: e1000: 52:54:00:12:34:56 eth0: e1000#0 Hit any key to stop autoboot: 0 => => tpm2 startup TPM2_SU_CLEAR Couldn't set TPM 0 (rc = 1) = [riscv32/riscv64] - riscv32/riscv64 QEMU seems not to support TPM device, qemu-system-riscv32 and qemu-system-riscv64 ends with the error "No TPM backend types are available". - The available backend types are "passthrough" or "emulator", "emulator" must be used for swtpm. = ubuntu@ubuntu-W331AU:~/src/test/u-boot$ qemu-system-riscv32 -nographic -machine virt -bios u-boot -chardev socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0 qemu-system-riscv32: -tpmdev emulator,id=tpm0,chardev=chrtpm: Parameter 'type' expects a TPM backend type No TPM backend types are available = = ubuntu@ubuntu-W331AU:~/src/test/u-boot$ qemu-system-riscv64 -nographic -machine virt -bios u-boot -chardev socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0 qemu-system-riscv64: -tpmdev emulator,id=tpm0,chardev=chrtpm: Parameter 'type' expects a TPM backend type No TPM backend types are available = Is it OK if I add the tcg2 efi_selftest for arm/arm64 for now? Thanks, Masahisa Kojima > > Regards > > Heinrich > > > > >[...] > > > >Regards > >/Ilias
Re: [PATCH 0/3] rockchip: sdhci: Add HS400 Enhanced Strobe support
Hi, On 11/1/21 6:07 PM, Alper Nebi Yasak wrote: > I'm trying to make my gru-kevin's eMMC work properly (it times out while > tuning for HS400 and stops working when reinitialized via "mmc dev 0"). > While experimenting with what works on my board I ended up implementing > HS400ES support. And while I'm at it, I decided to do it for RK3568 as > well since it turned out easy enough. Both are ported from relevant > Linux drivers. > > I'm trying this with "load mmc 0:1 0xd000 /bigfile $size" and getting > the following speeds; and with "mmc info" the following differences: > > gru-kevin mmc0 | w/o this series | w/ this series > +---+--- > Bus Speed | 5200 | 2 > Mode| MMC High Speed (52MHz)| HS400ES (200 MHz) > 8MiB Load Speed | ~9.5 MiB/s| ~51.5 MiB/s > 256MiB Load Speed | ~177.8 MiB/s | ~114.5 MiB/s I wonder why HS400ES is lower than High Speed mode in 256MiB Load Speed. Best Regards, Jaehoon Chung > > Listing partitions, listing files, reading files and the loaded bytes > all look fine to me, but I'm not sure I haven't missed anything. > > > Alper Nebi Yasak (3): > mmc: sdhci: Add HS400 Enhanced Strobe support > rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3399 > rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3568 > > drivers/mmc/rockchip_sdhci.c | 51 > drivers/mmc/sdhci.c | 18 + > include/sdhci.h | 1 + > 3 files changed, 70 insertions(+) >
Re: [PATCH 0/3] rockchip: sdhci: Add HS400 Enhanced Strobe support
On 01/11/2021 12:07, Alper Nebi Yasak wrote: > I'm trying this with "load mmc 0:1 0xd000 /bigfile $size" and getting > the following speeds; and with "mmc info" the following differences: > > gru-kevin mmc0 | w/o this series | w/ this series > +---+--- > Bus Speed | 5200 | 2 > Mode| MMC High Speed (52MHz)| HS400ES (200 MHz) > 8MiB Load Speed | ~9.5 MiB/s| ~51.5 MiB/s > 256MiB Load Speed | ~177.8 MiB/s | ~114.5 MiB/s I have messed this table up while reformatting it from one orientation to another... The last two rows are transposed, and are instead: > 8MiB Load Speed | ~9.5 MiB/s| ~177.8 MiB/s > 256MiB Load Speed | ~51.5 MiB/s | ~114.5 MiB/s
[PATCH] arm: a37xx: pci: Program the data strobe for config read requests
According to the Armada 3720 Functional Specification Data Strobe applies for both read and write config requests. Data strobe bits configure which bytes from the start address should be returned for read request. Set value 0xf (all 4 bits) into Data Strobe register to read all four bytes from specified 32-bit config space register. Same value for Data Strobe register is programmed by Linux pci-aardvark.c driver for config read requests. Without this patch pci-aardvark driver sets data strobe register only during config write operations. So any followup config read operations could result with just partial datai returned (if previous write operation was not 32-bit wide). This patch fixes it and ensures that config read operations always read all bytes from requested register. Signed-off-by: Pali Rohár --- drivers/pci/pci-aardvark.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/pci/pci-aardvark.c b/drivers/pci/pci-aardvark.c index 9e623b6e617b..4e94b776c5b9 100644 --- a/drivers/pci/pci-aardvark.c +++ b/drivers/pci/pci-aardvark.c @@ -472,6 +472,9 @@ static int pcie_advk_read_config(const struct udevice *bus, pci_dev_t bdf, advk_writel(pcie, reg, PIO_ADDR_LS); advk_writel(pcie, 0, PIO_ADDR_MS); + /* Program the data strobe */ + advk_writel(pcie, 0xf, PIO_WR_DATA_STRB); + retry_count = 0; retry: -- 2.20.1
[PATCH 3/3] rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3568
On RK3568, a register bit must be set to enable Enhanced Strobe.
However, it appears that the address of this register may differ from
vendor to vendor and should be read from the underlying MMC IP.
Let the Rockchip SDHCI driver read this address and set the relevant bit
when Enhanced Strobe configuration is requested.
This is mostly ported from Linux' Synopsys DWC MSHC driver which happens
to be the underlying IP. (drivers/mmc/host/sdhci-of-dwcmshc.c in Linux
tree).
Signed-off-by: Alper Nebi Yasak
---
Merely build-tested as I don't have a RK3568 board.
drivers/mmc/rockchip_sdhci.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c
index 7457255fa080..c95f95578672 100644
--- a/drivers/mmc/rockchip_sdhci.c
+++ b/drivers/mmc/rockchip_sdhci.c
@@ -45,6 +45,13 @@
#define ARASAN_VENDOR_REGISTER 0x78
#define ARASAN_VENDOR_ENHANCED_STROBE BIT(0)
+/* DWC IP vendor area 1 pointer */
+#define DWCMSHC_P_VENDOR_AREA1 0xe8
+#define DWCMSHC_AREA1_MASK GENMASK(11, 0)
+/* Offset inside the vendor area 1 */
+#define DWCMSHC_EMMC_CONTROL 0x2c
+#define DWCMSHC_ENHANCED_STROBEBIT(8)
+
/* Rockchip specific Registers */
#define DWCMSHC_EMMC_DLL_CTRL 0x800
#define DWCMSHC_EMMC_DLL_CTRL_RESETBIT(1)
@@ -284,6 +291,21 @@ static int rk3568_emmc_get_phy(struct udevice *dev)
return 0;
}
+static int rk3568_set_enhanced_strobe(struct sdhci_host *host)
+{
+ u32 vendor;
+ int reg;
+
+ reg = (sdhci_readl(host, DWCMSHC_P_VENDOR_AREA1) & DWCMSHC_AREA1_MASK)
+ + DWCMSHC_EMMC_CONTROL;
+
+ vendor = sdhci_readl(host, reg);
+ vendor |= DWCMSHC_ENHANCED_STROBE;
+ sdhci_writel(host, vendor, reg);
+
+ return 0;
+}
+
static int rockchip_sdhci_set_ios_post(struct sdhci_host *host)
{
struct rockchip_sdhc *priv = container_of(host, struct rockchip_sdhc,
host);
@@ -473,6 +495,7 @@ static const struct sdhci_data rk3568_data = {
.emmc_set_clock = rk3568_sdhci_emmc_set_clock,
.get_phy = rk3568_emmc_get_phy,
.emmc_phy_init = rk3568_emmc_phy_init,
+ .set_enhanced_strobe = rk3568_set_enhanced_strobe,
};
static const struct udevice_id sdhci_ids[] = {
--
2.33.1
[PATCH 2/3] rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3399
On RK3399, a register bit must be set to enable Enhanced Strobe.
Let the Rockchip SDHCI driver set it when Enhanced Strobe configuration
is requested.
This is mostly ported from Linux' Arasan SDHCI driver which happens
to be the underlying IP. (drivers/mmc/host/sdhci-of-arasan.c in Linux
tree).
Signed-off-by: Alper Nebi Yasak
---
drivers/mmc/rockchip_sdhci.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c
index 278473899c7c..7457255fa080 100644
--- a/drivers/mmc/rockchip_sdhci.c
+++ b/drivers/mmc/rockchip_sdhci.c
@@ -42,6 +42,9 @@
x) >> PHYCTRL_DLLRDY_SHIFT) & PHYCTRL_DLLRDY_MASK) ==\
PHYCTRL_DLLRDY_DONE)
+#define ARASAN_VENDOR_REGISTER 0x78
+#define ARASAN_VENDOR_ENHANCED_STROBE BIT(0)
+
/* Rockchip specific Registers */
#define DWCMSHC_EMMC_DLL_CTRL 0x800
#define DWCMSHC_EMMC_DLL_CTRL_RESETBIT(1)
@@ -93,6 +96,7 @@ struct sdhci_data {
int (*emmc_set_clock)(struct sdhci_host *host, unsigned int clock);
int (*emmc_phy_init)(struct udevice *dev);
int (*get_phy)(struct udevice *dev);
+ int (*set_enhanced_strobe)(struct sdhci_host *host);
};
static int rk3399_emmc_phy_init(struct udevice *dev)
@@ -198,6 +202,17 @@ static int rk3399_sdhci_emmc_set_clock(struct sdhci_host
*host, unsigned int clo
return 0;
}
+static int rk3399_set_enhanced_strobe(struct sdhci_host *host)
+{
+ u32 vendor;
+
+ vendor = sdhci_readl(host, ARASAN_VENDOR_REGISTER);
+ vendor |= ARASAN_VENDOR_ENHANCED_STROBE;
+ sdhci_writel(host, vendor, ARASAN_VENDOR_REGISTER);
+
+ return 0;
+}
+
static int rk3568_emmc_phy_init(struct udevice *dev)
{
struct rockchip_sdhc *prv = dev_get_priv(dev);
@@ -355,9 +370,21 @@ static int rockchip_sdhci_execute_tuning(struct mmc *mmc,
u8 opcode)
return ret;
}
+static int rockchip_sdhci_set_enhanced_strobe(struct sdhci_host *host)
+{
+ struct rockchip_sdhc *priv = container_of(host, struct rockchip_sdhc,
host);
+ struct sdhci_data *data = (struct sdhci_data
*)dev_get_driver_data(priv->dev);
+
+ if (data->set_enhanced_strobe)
+ return data->set_enhanced_strobe(host);
+
+ return -ENOTSUPP;
+}
+
static struct sdhci_ops rockchip_sdhci_ops = {
.set_ios_post = rockchip_sdhci_set_ios_post,
.platform_execute_tuning = _sdhci_execute_tuning,
+ .set_enhanced_strobe = _sdhci_set_enhanced_strobe,
};
static int rockchip_sdhci_probe(struct udevice *dev)
@@ -439,6 +466,7 @@ static const struct sdhci_data rk3399_data = {
.emmc_set_clock = rk3399_sdhci_emmc_set_clock,
.get_phy = rk3399_emmc_get_phy,
.emmc_phy_init = rk3399_emmc_phy_init,
+ .set_enhanced_strobe = rk3399_set_enhanced_strobe,
};
static const struct sdhci_data rk3568_data = {
--
2.33.1
[PATCH 1/3] mmc: sdhci: Add HS400 Enhanced Strobe support
Delegate setting the Enhanced Strobe configuration to individual drivers
if they set a function for it. Return -ENOTSUPP if they do not, like
what the MMC uclass does.
Signed-off-by: Alper Nebi Yasak
---
drivers/mmc/sdhci.c | 18 ++
include/sdhci.h | 1 +
2 files changed, 19 insertions(+)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 766e4a6b0c5e..bf989a594f7e 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -513,6 +513,7 @@ void sdhci_set_uhs_timing(struct sdhci_host *host)
reg |= SDHCI_CTRL_UHS_SDR104;
break;
case MMC_HS_400:
+ case MMC_HS_400_ES:
reg |= SDHCI_CTRL_HS400;
break;
default:
@@ -666,6 +667,7 @@ static int sdhci_set_ios(struct mmc *mmc)
mmc->selected_mode == MMC_DDR_52 ||
mmc->selected_mode == MMC_HS_200 ||
mmc->selected_mode == MMC_HS_400 ||
+ mmc->selected_mode == MMC_HS_400_ES ||
mmc->selected_mode == UHS_SDR25 ||
mmc->selected_mode == UHS_SDR50 ||
mmc->selected_mode == UHS_SDR104 ||
@@ -799,6 +801,19 @@ static int sdhci_wait_dat0(struct udevice *dev, int state,
return -ETIMEDOUT;
}
+#if CONFIG_IS_ENABLED(MMC_HS400_ES_SUPPORT)
+static int sdhci_set_enhanced_strobe(struct udevice *dev)
+{
+ struct mmc *mmc = mmc_get_mmc_dev(dev);
+ struct sdhci_host *host = mmc->priv;
+
+ if (host->ops && host->ops->set_enhanced_strobe)
+ return host->ops->set_enhanced_strobe(host);
+
+ return -ENOTSUPP;
+}
+#endif
+
const struct dm_mmc_ops sdhci_ops = {
.send_cmd = sdhci_send_command,
.set_ios= sdhci_set_ios,
@@ -808,6 +823,9 @@ const struct dm_mmc_ops sdhci_ops = {
.execute_tuning = sdhci_execute_tuning,
#endif
.wait_dat0 = sdhci_wait_dat0,
+#if CONFIG_IS_ENABLED(MMC_HS400_ES_SUPPORT)
+ .set_enhanced_strobe = sdhci_set_enhanced_strobe,
+#endif
};
#else
static const struct mmc_ops sdhci_ops = {
diff --git a/include/sdhci.h b/include/sdhci.h
index c718dd7206c1..7a65fdf95d30 100644
--- a/include/sdhci.h
+++ b/include/sdhci.h
@@ -272,6 +272,7 @@ struct sdhci_ops {
int (*platform_execute_tuning)(struct mmc *host, u8 opcode);
int (*set_delay)(struct sdhci_host *host);
int (*deferred_probe)(struct sdhci_host *host);
+ int (*set_enhanced_strobe)(struct sdhci_host *host);
};
#define ADMA_MAX_LEN 65532
--
2.33.1
[PATCH 0/3] rockchip: sdhci: Add HS400 Enhanced Strobe support
I'm trying to make my gru-kevin's eMMC work properly (it times out while tuning for HS400 and stops working when reinitialized via "mmc dev 0"). While experimenting with what works on my board I ended up implementing HS400ES support. And while I'm at it, I decided to do it for RK3568 as well since it turned out easy enough. Both are ported from relevant Linux drivers. I'm trying this with "load mmc 0:1 0xd000 /bigfile $size" and getting the following speeds; and with "mmc info" the following differences: gru-kevin mmc0 | w/o this series | w/ this series +---+--- Bus Speed | 5200 | 2 Mode| MMC High Speed (52MHz)| HS400ES (200 MHz) 8MiB Load Speed | ~9.5 MiB/s| ~51.5 MiB/s 256MiB Load Speed | ~177.8 MiB/s | ~114.5 MiB/s Listing partitions, listing files, reading files and the loaded bytes all look fine to me, but I'm not sure I haven't missed anything. Alper Nebi Yasak (3): mmc: sdhci: Add HS400 Enhanced Strobe support rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3399 rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3568 drivers/mmc/rockchip_sdhci.c | 51 drivers/mmc/sdhci.c | 18 + include/sdhci.h | 1 + 3 files changed, 70 insertions(+) -- 2.33.1
[PATCH v2] riscv: ae350: Use #if defined instead of CONFIG_IS_ENABLED
According to ./include/linux/kconfig.h,
CONFIG_IS_ENABLED(OF_BOARD) expands to 0
when CONFIG_SPL_BUILD is defined because
there is no CONFIG_SPL_OF_BOARD.
Use #if defined instead.
Fixes: 2e8d2f88439d ("riscv: Remove OF_PRIOR_STAGE from RISC-V boards")
Signed-off-by: Leo Yu-Chi Liang
Reviewed-by: Rick Chen
Reviewed-by: Bin Meng
---
board/AndesTech/ax25-ae350/ax25-ae350.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
b/board/AndesTech/ax25-ae350/ax25-ae350.c
index b28894ed46..58bf236497 100644
--- a/board/AndesTech/ax25-ae350/ax25-ae350.c
+++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
@@ -56,9 +56,9 @@ ulong board_flash_get_legacy(ulong base, int banknum,
flash_info_t *info)
void *board_fdt_blob_setup(void)
{
-#if CONFIG_IS_ENABLED(OF_BOARD)
+#if defined(CONFIG_OF_BOARD)
return (void *)(ulong)gd->arch.firmware_fdt_addr;
-#elif CONFIG_IS_ENABLED(OF_SEPARATE)
+#elif defined(CONFIG_OF_SEPARATE)
return (void *)CONFIG_SYS_FDT_BASE;
#else
return NULL;
--
2.17.0
Re: [PATCH] riscv: ae350: Use #if defined instead of CONFIG_IS_ENABLED
On Mon, Nov 01, 2021 at 04:37:32PM +0800, Bin Meng wrote:
> Hi Leo,
>
> On Mon, Nov 1, 2021 at 3:49 PM Leo Liang wrote:
> >
> > Hi Bin,
> > On Mon, Nov 01, 2021 at 02:04:48PM +0800, Bin Meng wrote:
> > > Hi Leo,
> > >
> > > On Wed, Oct 27, 2021 at 4:59 PM Leo Yu-Chi Liang
> > > wrote:
> > > >
> > > > According to ./include/linux/kconfig.h,
> > > > CONFIG_IS_ENABLED(OF_BOARD) expands to 0
> > > > when CONFIG_SPL_BUILD is defined because
> > > > there is no CONFIG_SPL_OF_BOARD.
> > >
> > > Why is the change?
> > >
> >
> > The original code was
> >
> > void *board_fdt_blob_setup(void)
> > {
> > #if CONFIG_IS_ENABLED(OF_BOARD)
> > return (void *)(ulong)gd->arch.firmware_fdt_addr;
> > #elif CONFIG_IS_ENABLED(OF_SEPARATE)
> > return (void *)CONFIG_SYS_FDT_BASE;
> > #else
> > return NULL;
> > }
> >
> > But the "return (void *)(ulong)gd->arch.firmware_fdt_addr;" does not get
> > compiled even if OF_BOARD is selected when building
> > ae350_*_spl_*_defconfig, thus this patch.
> >
> > The reason is because ./include/linux/kconfig.h states
> > "CONFIG_IS_ENABLED(FOO) expands to 1 if CONFIG_SPL_BUILD is defined
> > and CONFIG_SPL_FOO is set to 'y'".
> > However, we don't have CONFIG_SPL_OF_BOARD, so
> > CONFIG_IS_ENABLED(OF_BOARD) only expands to 0.
> >
>
> Thanks!
>
> Please add:
>
> Fixes: 2e8d2f88439d ("riscv: Remove OF_PRIOR_STAGE from RISC-V boards")
> Reviewed-by: Bin Meng
>
Will do. Thanks!
Best regards,
Leo
> Regards,
> Bin
Re: [PATCH v1 3/5] i2c: Add Microchip PolarFire SoC I2C driver
On Fri, Oct 22, 2021 at 02:26:46PM +0530, Padmarao Begari wrote: > Add I2C driver code for the Microchip PolarFire SoC. > This driver supports I2C data transfer and probe for I2C > slave addresses. > > Signed-off-by: Padmarao Begari > --- > drivers/i2c/Kconfig | 6 + > drivers/i2c/Makefile| 1 + > drivers/i2c/i2c-microchip.c | 482 > 3 files changed, 489 insertions(+) > create mode 100644 drivers/i2c/i2c-microchip.c Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH 00/31] passage: Define a standard for firmware data flow
Hi Simon, this seems a great endeavor. I'd like to better understand the scope of it. Is it to be used as part of what could become a U-Boot entry ABI scheme? By that I mean giving some fixed aspects to U-Boot entry while letting boards to have flexibility (say for instance that the first 5 architecture ABI parameter registers are reserved for U-Boot), and the Passage is about specifying either those reserved registers or one of them? Thinking entry ABI, here is what I observed on Arm: Linux has two entry ABIs: - plain: x0 = dtb; command line = dtb:/chosen/bootargs; initrd = dtb:/chosen/linux,initrd-* - EFI: x0=handle, x1=systemtable, x30=return address; dtb = EFI_UUID config table; initrd = efi:, x2-x5 = , other registers are per platform, SMC calls allowed too - EFI: x0=handle, x1=systemtable, x30=return address; (when U-Boot is launched as an EFI app) dtb = EFI_UUID config table, + Passage = Passage UUID config table We could further leverage Passage to pass Operating Systems parameters that could be removed from device tree (migration of /chosen to Passage). Memory inventory would still be in DT but allocations for CMA or GPUs would be in Passage. This idea is to reach a point where device tree is a "pristine" hardware description. Cheers PS: as Ilias mentions, this patch set contains bug fixes, non immediately related additional functions (DM stats). It would be great to carve those out to fast path them and keep this one with the very core of your idea. On Mon, 1 Nov 2021 at 02:17, Simon Glass wrote: > > This series adds a standard way of passing information between different > firmware phases. This already exists in U-Boot at a very basic level, in > the form of a bloblist containing an spl_handoff structure, but the intent > here is to define something useful across projects. > > The need for this is growing as firmware fragments into multiple binaries > each with its own purpose. Without any run-time connection, we must rely > on build-time settings which are brittle and painful to keep in sync. > > This feature is named 'standard passage' since the name is more unique > than many others that could be chosen, it is a passage in the sense that > information is flowing from one place to another and it is standard, > because that is what we want to create. > > The implementation is simply a pointer to a bloblist in a register, with > an extra register to point to a devicetree, for more complex data, if one > is present in the bloblist. This should cover all cases (small memory > footprint as well as complex data flow) and be easy enough to implement on > all architectures. > > The core bloblist code is relicensed to BSD-3-Clause in case it is useful > in non-GPL projects but there is no requirement to use the same code. > > This series includes tweaks to the bloblist implementation in U-Boot to > make it more suitable for the task, including: > >- Allocate tags explicitly in the enum >- Put the magic number first >- Define a process for adding tags > > The emphasis is on enabling open communcation between binaries, not > enabling passage of secret, undocumented data, although this is possible > in a private environment. > > This series is built on the OF_BOARD series It is available at > u-boot-dm/pass-working or: > > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/commit/073b5c156f222c69a98b8ebcaa563d1ff10eb217 > > > Simon Glass (31): > Makefile: Correct TPL rule for OF_REAL > kconfig: Add support for conditional values > dm: core: Allow getting some basic stats > stddef: Avoid warning with clang with offsetof() > fdt: Drop SPL_BUILD macro > bloblist: Put the magic number first > bloblist: Rename the SPL tag > bloblist: Drop unused tags > bloblist: Use explicit numbering for the tags > bloblist: Support allocating the bloblist > bloblist: Use LOG_CATEGORY to simply logging > bloblist: Use 'phase' consistently for bloblists > bloblist: Refactor Kconfig to support alloc or fixed > arm: qemu: Add an SPL build > bloblist: Add functions to obtain base address and size > passage: Support an incoming passage > passage: Support a control devicetree > passage: arm: Accept a passage from the previous phase > passage: spl: Support adding the dtb to the passage bloblist > passage: spl: Support passing the passage to U-Boot > passage: Record where the devicetree came from > passage: Report the devicetree source > passage: Add a qemu test for ARM > bloblist: doc: Bring in the API documentation > bloblist: Relicense to allow BSD-3-Clause > sandbox: Add a way of checking structs for standard passage > passage: Add documentation > passage: Add docs for spl_handoff > x86: Move Intel GNVS file into the common include directory > passage: Add checks for pre-existing blobs > WIP: RFC: Add a gitlab test > > .gitlab-ci.yml| 6 + > MAINTAINERS
Re: [PATCH 1/1] board: sifive: unmatched: enlarge CONFIG_SYS_SPL_MALLOC_SIZE
Hi Rick, On Mon, Oct 25, 2021 at 10:24 AM Rick Chen wrote: > > Hi, Bin > > > Hi Rick, > > > > On Mon, Oct 25, 2021 at 9:49 AM Rick Chen wrote: > > > > > > Hi Bin, > > > > > > > From: Bin Meng > > > > Sent: Tuesday, October 19, 2021 4:55 PM > > > > To: Alexandre Ghiti > > > > Cc: Heinrich Schuchardt ; Tom Rini > > > > ; Leo Yu-Chi Liang(梁育齊) ; > > > > Rick Jian-Zhi Chen(陳建志) ; Pragnesh Patel > > > > ; Dimitri John Ledkov > > > > ; Zong Li ; Green Wan > > > > ; U-Boot Mailing List > > > > Subject: Re: [PATCH 1/1] board: sifive: unmatched: enlarge > > > > CONFIG_SYS_SPL_MALLOC_SIZE > > > > > > > > On Tue, Oct 19, 2021 at 4:32 PM Alexandre Ghiti > > > > wrote: > > > > > > > > > > Hi, > > > > > > > > > > On Fri, Oct 1, 2021 at 5:35 PM Bin Meng wrote: > > > > > > > > > > > > Hi Heinrich, > > > > > > > > > > > > On Fri, Oct 1, 2021 at 7:37 PM Heinrich Schuchardt > > > > > > wrote: > > > > > > > > > > > > > > Avoid an error like > > > > > > > > > > > > > > Could not get FIT buffer of 1725952 bytes > > > > > > > check CONFIG_SYS_SPL_MALLOC_SIZE > > > > > > > No device tree specified in SPL image > > > > > > > ### ERROR ### Please RESET the board ### > > > > > > > > > > > > > > Signed-off-by: Heinrich Schuchardt > > > > > > > > > > > > > > --- > > > > > > > include/configs/sifive-unmatched.h | 2 +- > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > > > diff --git a/include/configs/sifive-unmatched.h > > > > > > > b/include/configs/sifive-unmatched.h > > > > > > > index f8ad2cce1f..8d3deabdd3 100644 > > > > > > > --- a/include/configs/sifive-unmatched.h > > > > > > > +++ b/include/configs/sifive-unmatched.h > > > > > > > @@ -18,7 +18,7 @@ > > > > > > > #define CONFIG_SPL_BSS_MAX_SIZE0x0010 > > > > > > > #define CONFIG_SYS_SPL_MALLOC_START > > > > > > > (CONFIG_SPL_BSS_START_ADDR + \ > > > > > > > CONFIG_SPL_BSS_MAX_SIZE) > > > > > > > -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0010 > > > > > > > +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0020 > > > > > > > > > > > > > > #define CONFIG_SPL_STACK (0x0800 + 0x001D - \ > > > > > > > GENERATED_GBL_DATA_SIZE) > > > > > > > > > > > > What caused this? > > > > > > > > > > > > Last time this was seen on Ax25-AE350, CONFIG_SPL_SYS_MALLOC_F_LEN > > > > > > was increased, instead of CONFIG_SYS_SPL_MALLOC_SIZE which the error > > > > > > messages point to > > > > > > > > > > > > https://lists.denx.de/pipermail/u-boot/2021-May/449447.html > > > > > > > > > > > > > > > > I fell into the same issue this morning and increasing > > > > > CONFIG_SYS_SPL_MALLOC_SIZE fixed it, though I had to increase it even > > > > > more than Heinrich. > > > > > > > > Is this default build that caused Unmatched boot failure? > > > > > > > > @Rick Chen can you comment on why CONFIG_SPL_SYS_MALLOC_F_LEN was > > > > needed on AE350? > > > > > > It is needed for limited memory cases on AE350 platforms. > > > > But the error message indicates that CONFIG_SYS_SPL_MALLOC_SIZE should > > be increased, which is what this patch doing. > > > > Why is CONFIG_SYS_SPL_MALLOC_SIZE not working on AE350? > > I review why I increase SPL_SYS_MALLOC_F_LEN and recall that it will > report memory size problem in spl_get_fit_load_buffer() of spl_fit.c. > But Increase CONFIG_SYS_SPL_MALLOC_SIZE is helpful for boards with > CONFIG_SYS_SPL_MALLOC_SIZE definition, > On Ae350 it is not define SYS_SPL_MALLOC_SIZE, so I increase > SPL_SYS_MALLOC_F_LEN instead. > Thanks. So this suggests we should fix the message in spl_get_fit_load_buffer() to provide different hints for different configurations? Regards, Bin
Re: [PATCH v1 5/5] doc: board: Update Microchip MPFS Icicle Kit doc
On Fri, Oct 22, 2021 at 4:58 PM Padmarao Begari wrote: > > UART1 uses for U-BOOT and Linux console instead of UART0 and nits: s/U-BOOT/U-Boot > UART0 is reserved for Hart Software Services(HSS). > > Signed-off-by: Padmarao Begari > --- > doc/board/microchip/mpfs_icicle.rst | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/doc/board/microchip/mpfs_icicle.rst > b/doc/board/microchip/mpfs_icicle.rst > index c71c2f3cab..d7af542c0e 100644 > --- a/doc/board/microchip/mpfs_icicle.rst > +++ b/doc/board/microchip/mpfs_icicle.rst > @@ -18,8 +18,9 @@ The support for following drivers are already enabled: > > 1. NS16550 UART Driver. > 2. Microchip Clock Driver. > -3. Cadence MACB ethernet driver for networking support. > -4. Cadence MMC Driver for eMMC/SD support. > +3. Microchip I2C Driver. nits: can we just insert this after the existing entries? > +4. Cadence MACB ethernet driver for networking support. > +5. Cadence MMC Driver for eMMC/SD support. > > Booting from eMMC using HSS > --- > @@ -214,7 +215,8 @@ GPT partition. > Booting > ~~~ > > -You should see the U-Boot prompt on UART0. > +You should see the U-Boot prompt on UART1. > +(Note: UART0 is reserved for HSS) > > Sample boot log from MPFS Icicle Kit > > @@ -451,7 +453,8 @@ copied payload and Linux image. > > sudo dd if= of=/dev/sdX2 bs=512 > > -You should see the U-Boot prompt on UART0. > +You should see the U-Boot prompt on UART1. > +(Note: UART0 is reserved for HSS) > > GUID type > ~ Otherwise, Reviewed-by: Bin Meng Regards, Bin
Re: [PATCH v1 4/5] net: macb: Compatible as per device tree
On Fri, Oct 22, 2021 at 4:58 PM Padmarao Begari
wrote:
>
> Update compatible as per Microchip PolarFire SoC ethernet
> device node.
>
> Signed-off-by: Padmarao Begari
> ---
> drivers/net/macb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index 8c6461e717..1b867bd5c2 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -1502,7 +1502,7 @@ static const struct udevice_id macb_eth_ids[] = {
> { .compatible = "cdns,zynq-gem" },
> { .compatible = "sifive,fu540-c000-gem",
> .data = (ulong)_config },
> - { .compatible = "microchip,mpfs-mss-gem",
> + { .compatible = "microchip,mpfs-gem",
Could you please provide the upstream Linux kernel binding reference?
I can't find such string in the Linux kernel.
> .data = (ulong)_config },
> { }
> };
Regards,
Bin
Re: [PATCH v1 2/5] riscv: Update Microchip MPFS Icicle Kit support
On Fri, Oct 22, 2021 at 4:58 PM Padmarao Begari
wrote:
>
> This patch updates Microchip MPFS Icicle Kit support. For now,
> add Microchip I2C driver, set environment variables for
> mac addesses and default build for SBI_V02.
>
> Signed-off-by: Padmarao Begari
> ---
> board/microchip/mpfs_icicle/Kconfig | 5 +
> board/microchip/mpfs_icicle/mpfs_icicle.c | 17 -
> configs/microchip_mpfs_icicle_defconfig | 1 -
> 3 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/board/microchip/mpfs_icicle/Kconfig
> b/board/microchip/mpfs_icicle/Kconfig
> index 4678462378..092e411215 100644
> --- a/board/microchip/mpfs_icicle/Kconfig
> +++ b/board/microchip/mpfs_icicle/Kconfig
> @@ -45,5 +45,10 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> imply MMC_WRITE
> imply MMC_SDHCI
> imply MMC_SDHCI_CADENCE
> + imply MMC_SDHCI_ADMA
> + imply MMC_HS200_SUPPORT
> + imply CMD_I2C
> + imply DM_I2C
> + imply SYS_I2C_MICROCHIP
>
> endif
> diff --git a/board/microchip/mpfs_icicle/mpfs_icicle.c
> b/board/microchip/mpfs_icicle/mpfs_icicle.c
> index afef719dff..e74c9fb03c 100644
> --- a/board/microchip/mpfs_icicle/mpfs_icicle.c
> +++ b/board/microchip/mpfs_icicle/mpfs_icicle.c
> @@ -119,7 +119,22 @@ int board_late_init(void)
> if (icicle_mac_addr[idx] == ':')
> icicle_mac_addr[idx] = ' ';
> }
> - env_set("icicle_mac_addr", icicle_mac_addr);
> + env_set("icicle_mac_addr0", icicle_mac_addr);
What's this environment for? Shouldn't the U-Boot standard environment
variable "ethaddr" be set here?
> +
> + mac_addr[5] = device_serial_number[0] + 1;
> +
> + icicle_mac_addr[0] = '[';
> +
> + sprintf(_mac_addr[1], "%pM", mac_addr);
"eth1addr"?
> +
> + icicle_mac_addr[18] = ']';
> + icicle_mac_addr[19] = '\0';
> +
> + for (idx = 0; idx < 20; idx++) {
> + if (icicle_mac_addr[idx] == ':')
> + icicle_mac_addr[idx] = ' ';
> + }
> + env_set("icicle_mac_addr1", icicle_mac_addr);
>
> return 0;
> }
> diff --git a/configs/microchip_mpfs_icicle_defconfig
> b/configs/microchip_mpfs_icicle_defconfig
> index 90ae76cc12..b3c7e6db8f 100644
> --- a/configs/microchip_mpfs_icicle_defconfig
> +++ b/configs/microchip_mpfs_icicle_defconfig
> @@ -6,7 +6,6 @@ CONFIG_DEFAULT_DEVICE_TREE="microchip-mpfs-icicle-kit"
> CONFIG_TARGET_MICROCHIP_ICICLE=y
> CONFIG_ARCH_RV64I=y
> CONFIG_RISCV_SMODE=y
> -CONFIG_SBI_V01=y
> CONFIG_DISTRO_DEFAULTS=y
> CONFIG_SYS_LOAD_ADDR=0x8020
> CONFIG_FIT=y
> --
Regards,
Bin
Re: [PATCH v1 1/5] riscv: dts: Split Microchip device tree
Hi Padmarao, On Fri, Oct 22, 2021 at 4:58 PM Padmarao Begari wrote: > > The device tree split into .dtsi and .dts files, common > device node for eMMC/SD, enable I2C1, UART1 for console > instead of UART0, enable the DDR 2GB memory and in > that 288MB memory is reserved for fabric buffer. > > Signed-off-by: Padmarao Begari > --- > arch/riscv/dts/microchip-mpfs-icicle-kit.dts | 518 > arch/riscv/dts/microchip-mpfs.dtsi| 571 ++ > .../microchip-mpfs-plic.h | 195 ++ > .../interrupt-controller/riscv-hart.h | 18 + > 4 files changed, 913 insertions(+), 389 deletions(-) > create mode 100644 arch/riscv/dts/microchip-mpfs.dtsi > create mode 100644 > include/dt-bindings/interrupt-controller/microchip-mpfs-plic.h > create mode 100644 include/dt-bindings/interrupt-controller/riscv-hart.h Are these files sync'ed from upstream Linux kernel? > [snip] Regards, Bin
Re: [PATCH] riscv: ae350: Use #if defined instead of CONFIG_IS_ENABLED
Hi Leo,
On Mon, Nov 1, 2021 at 3:49 PM Leo Liang wrote:
>
> Hi Bin,
> On Mon, Nov 01, 2021 at 02:04:48PM +0800, Bin Meng wrote:
> > Hi Leo,
> >
> > On Wed, Oct 27, 2021 at 4:59 PM Leo Yu-Chi Liang
> > wrote:
> > >
> > > According to ./include/linux/kconfig.h,
> > > CONFIG_IS_ENABLED(OF_BOARD) expands to 0
> > > when CONFIG_SPL_BUILD is defined because
> > > there is no CONFIG_SPL_OF_BOARD.
> >
> > Why is the change?
> >
>
> The original code was
>
> void *board_fdt_blob_setup(void)
> {
> #if CONFIG_IS_ENABLED(OF_BOARD)
> return (void *)(ulong)gd->arch.firmware_fdt_addr;
> #elif CONFIG_IS_ENABLED(OF_SEPARATE)
> return (void *)CONFIG_SYS_FDT_BASE;
> #else
> return NULL;
> }
>
> But the "return (void *)(ulong)gd->arch.firmware_fdt_addr;" does not get
> compiled even if OF_BOARD is selected when building
> ae350_*_spl_*_defconfig, thus this patch.
>
> The reason is because ./include/linux/kconfig.h states
> "CONFIG_IS_ENABLED(FOO) expands to 1 if CONFIG_SPL_BUILD is defined
> and CONFIG_SPL_FOO is set to 'y'".
> However, we don't have CONFIG_SPL_OF_BOARD, so
> CONFIG_IS_ENABLED(OF_BOARD) only expands to 0.
>
Thanks!
Please add:
Fixes: 2e8d2f88439d ("riscv: Remove OF_PRIOR_STAGE from RISC-V boards")
Reviewed-by: Bin Meng
Regards,
Bin
Re: [PATCH v1 2/5] riscv: Update Microchip MPFS Icicle Kit support
Hi Padmarao,
On Fri, Oct 22, 2021 at 02:26:45PM +0530, Padmarao Begari wrote:
> This patch updates Microchip MPFS Icicle Kit support. For now,
> add Microchip I2C driver, set environment variables for
> mac addesses and default build for SBI_V02.
typo: addresses
Otherwise,
Reviewed-by: Leo Yu-Chi Liang
> Signed-off-by: Padmarao Begari
> ---
> board/microchip/mpfs_icicle/Kconfig | 5 +
> board/microchip/mpfs_icicle/mpfs_icicle.c | 17 -
> configs/microchip_mpfs_icicle_defconfig | 1 -
> 3 files changed, 21 insertions(+), 2 deletions(-)
Re: [PATCH v1 1/5] riscv: dts: Split Microchip device tree
On Fri, Oct 22, 2021 at 02:26:44PM +0530, Padmarao Begari wrote: > The device tree split into .dtsi and .dts files, common > device node for eMMC/SD, enable I2C1, UART1 for console > instead of UART0, enable the DDR 2GB memory and in > that 288MB memory is reserved for fabric buffer. > > Signed-off-by: Padmarao Begari > --- > arch/riscv/dts/microchip-mpfs-icicle-kit.dts | 518 > arch/riscv/dts/microchip-mpfs.dtsi| 571 ++ > .../microchip-mpfs-plic.h | 195 ++ > .../interrupt-controller/riscv-hart.h | 18 + > 4 files changed, 913 insertions(+), 389 deletions(-) > create mode 100644 arch/riscv/dts/microchip-mpfs.dtsi > create mode 100644 > include/dt-bindings/interrupt-controller/microchip-mpfs-plic.h > create mode 100644 include/dt-bindings/interrupt-controller/riscv-hart.h Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH v1 5/5] doc: board: Update Microchip MPFS Icicle Kit doc
On Fri, Oct 22, 2021 at 02:26:48PM +0530, Padmarao Begari wrote: > UART1 uses for U-BOOT and Linux console instead of UART0 and > UART0 is reserved for Hart Software Services(HSS). > > Signed-off-by: Padmarao Begari > --- > doc/board/microchip/mpfs_icicle.rst | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH v1 4/5] net: macb: Compatible as per device tree
On Fri, Oct 22, 2021 at 02:26:47PM +0530, Padmarao Begari wrote: > Update compatible as per Microchip PolarFire SoC ethernet > device node. > > Signed-off-by: Padmarao Begari > --- > drivers/net/macb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH v2] imx: spl: fix imx8m secure boot
On 17/08/2021 08.17, Heiko Schocher wrote:
> cherry-picked from NXP code:
> 719d665a87c6: ("MLK-20467 imx8m: Fix issue for booting signed image through
> uuu")
>
> which fixes secure boot on imx8m based boards.
>
[...]
> Works on sdcard and QSPI NOR boot on phycore-imx8mp board.
Hm, the subject of that patch mentions booting through uuu, and here you
mention imx8mp. I'm quite interested in that combination, as it doesn't
seem that the imx8mp_evk in mainline U-Boot (signed or not) can be
booted via uuu. Does serial download work on phycore-imx8mp?
As I mentioned in
https://lore.kernel.org/u-boot/0996154d-774c-607f-8b5c-9cc0d268e...@prevas.dk/
, I've bisected the start of it working in the NXP fork to a specific
commit, but I can't figure out what part of that is really responsible
(and if it's just that that commit enables some CONFIG_* symbols for
imx8mp_evk, the real meat is likely in earlier commits adding the code
that thus gets enabled).
Any ideas?
Rasmus
Re: [PATCH] riscv: ae350: Use #if defined instead of CONFIG_IS_ENABLED
Hi Bin,
On Mon, Nov 01, 2021 at 02:04:48PM +0800, Bin Meng wrote:
> Hi Leo,
>
> On Wed, Oct 27, 2021 at 4:59 PM Leo Yu-Chi Liang
> wrote:
> >
> > According to ./include/linux/kconfig.h,
> > CONFIG_IS_ENABLED(OF_BOARD) expands to 0
> > when CONFIG_SPL_BUILD is defined because
> > there is no CONFIG_SPL_OF_BOARD.
>
> Why is the change?
>
The original code was
void *board_fdt_blob_setup(void)
{
#if CONFIG_IS_ENABLED(OF_BOARD)
return (void *)(ulong)gd->arch.firmware_fdt_addr;
#elif CONFIG_IS_ENABLED(OF_SEPARATE)
return (void *)CONFIG_SYS_FDT_BASE;
#else
return NULL;
}
But the "return (void *)(ulong)gd->arch.firmware_fdt_addr;" does not get
compiled even if OF_BOARD is selected when building
ae350_*_spl_*_defconfig, thus this patch.
The reason is because ./include/linux/kconfig.h states
"CONFIG_IS_ENABLED(FOO) expands to 1 if CONFIG_SPL_BUILD is defined
and CONFIG_SPL_FOO is set to 'y'".
However, we don't have CONFIG_SPL_OF_BOARD, so
CONFIG_IS_ENABLED(OF_BOARD) only expands to 0.
Best regards,
Leo
> >
> > Use #if defined instead.
> >
> > Signed-off-by: Leo Yu-Chi Liang
> > ---
> > board/AndesTech/ax25-ae350/ax25-ae350.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
>
> Regards,
> Bin
Re: [PATCH 05/31] fdt: Drop SPL_BUILD macro
Hi Simon,
Seems irrelevant to the current series, but can be sent with patch#1 separately?
On Mon, 1 Nov 2021 at 03:19, Simon Glass wrote:
>
> This old macro is not needed anymore since we can use IS_ENABLED() now.
> Drop it.
>
> Signed-off-by: Simon Glass
> ---
>
> drivers/serial/serial-uclass.c | 3 ++-
> include/fdtdec.h | 6 --
> 2 files changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
> index 30d44214d7d..96a1cb65ba2 100644
> --- a/drivers/serial/serial-uclass.c
> +++ b/drivers/serial/serial-uclass.c
> @@ -104,7 +104,8 @@ static void serial_find_console_or_panic(void)
> }
> }
> }
> - if (!SPL_BUILD || !CONFIG_IS_ENABLED(OF_CONTROL) || !blob) {
> + if (!IS_ENABLED(CONFIG_SPL_BUILD) || !CONFIG_IS_ENABLED(OF_CONTROL) ||
> + !blob) {
> /*
> * Try to use CONFIG_CONS_INDEX if available (it is numbered
> * from 1!).
> diff --git a/include/fdtdec.h b/include/fdtdec.h
> index 68a36f10583..24992baed8b 100644
> --- a/include/fdtdec.h
> +++ b/include/fdtdec.h
> @@ -49,12 +49,6 @@ struct fdt_memory {
>
> struct bd_info;
>
> -#ifdef CONFIG_SPL_BUILD
> -#define SPL_BUILD 1
> -#else
> -#define SPL_BUILD 0
> -#endif
> -
> /*
> * Information about a resource. start is the first address of the resource
> * and end is the last address (inclusive). The length of the resource will
> --
> 2.33.1.1089.g2158813163f-goog
>
Reviewed-by: Ilias Apalodimas
Re: [PATCH v4] driver: spi: add bcm iproc qspi support.
On Tue, Oct 26, 2021 at 1:07 AM Roman Bacik wrote: > > From: Rayagonda Kokatanur > > IPROC qspi driver supports both BSPI and MSPI modes. > > Signed-off-by: Rayagonda Kokatanur > Signed-off-by: Bharat Gooty > Acked-by: Rayagonda Kokatanur > > Signed-off-by: Roman Bacik > --- > > Changes in v4: > - move iproc_qspi.c from spi to mtd/spi > - remove iproc_qspi.h > - rename IPROC_QSPI to SPI_FLASH_IPROC > > Changes in v3: > - fix warning by including linux/delay.h > - change ofdata_to_platdata to of_to_plat > - change priv_auto_alloc_size to priv_auto > > Changes in v2: > - remove include spi-nor.h > - define and use named BITs for writing register values > - remove bspi_set_4byte_mode() method > > drivers/mtd/spi/Kconfig | 6 + > drivers/mtd/spi/Makefile | 1 + > drivers/mtd/spi/iproc_qspi.c | 718 +++ > 3 files changed, 725 insertions(+) > create mode 100644 drivers/mtd/spi/iproc_qspi.c Look like you confused what I've mentioned before, your driver is flash specific so add a driver in UCLASS_SPI_FLASH. drivers with UCLASS_SPI to be in drivers/spi/ Jagan.
Re: [PATCH 03/31] dm: core: Allow getting some basic stats
Hi Simon,
How is this related to the bloblist patchset? Is it required or it can split of?
Regards
/Ilias
On Mon, 1 Nov 2021 at 03:19, Simon Glass wrote:
>
> Add a function that returns some basic stats about driver model. For now
> we only have two.
>
> Signed-off-by: Simon Glass
> ---
>
> drivers/core/device.c| 11 ++
> drivers/core/root.c | 7 ++
> drivers/core/uclass.c| 13
> include/dm/device.h | 11 +-
> include/dm/root.h| 8 +++
> include/dm/uclass-internal.h | 7 ++
> test/dm/core.c | 41
> 7 files changed, 97 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/core/device.c b/drivers/core/device.c
> index d7a778a2413..7d327aba49e 100644
> --- a/drivers/core/device.c
> +++ b/drivers/core/device.c
> @@ -723,6 +723,17 @@ int device_get_child_count(const struct udevice *parent)
> return count;
> }
>
> +int device_get_decendent_count(const struct udevice *parent)
> +{
> + const struct udevice *dev;
> + int count = 1;
> +
> + list_for_each_entry(dev, >child_head, sibling_node)
> + count += device_get_decendent_count(dev);
> +
> + return count;
> +}
> +
> int device_find_child_by_seq(const struct udevice *parent, int seq,
> struct udevice **devp)
> {
> diff --git a/drivers/core/root.c b/drivers/core/root.c
> index 26b8195faa3..815173f86eb 100644
> --- a/drivers/core/root.c
> +++ b/drivers/core/root.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -407,6 +408,12 @@ int dm_init_and_scan(bool pre_reloc_only)
> return 0;
> }
>
> +void dm_get_stats(int *device_countp, int *uclass_countp)
> +{
> + *device_countp = device_get_decendent_count(gd->dm_root);
> + *uclass_countp = uclass_get_count();
> +}
> +
> #ifdef CONFIG_ACPIGEN
> static int root_acpi_get_name(const struct udevice *dev, char *out_name)
> {
> diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
> index c5a50952fd0..46b3e85fdbb 100644
> --- a/drivers/core/uclass.c
> +++ b/drivers/core/uclass.c
> @@ -638,6 +638,19 @@ int uclass_next_device_check(struct udevice **devp)
> return device_probe(*devp);
> }
>
> +int uclass_get_count(void)
> +{
> + const struct uclass *uc;
> + int count = 0;
> +
> + if (gd->dm_root) {
> + list_for_each_entry(uc, gd->uclass_root, sibling_node)
> + count++;
> + }
> +
> + return count;
> +}
> +
> int uclass_first_device_drvdata(enum uclass_id id, ulong driver_data,
> struct udevice **devp)
> {
> diff --git a/include/dm/device.h b/include/dm/device.h
> index 3028d002ab0..68e783ea409 100644
> --- a/include/dm/device.h
> +++ b/include/dm/device.h
> @@ -593,7 +593,7 @@ int device_get_child(const struct udevice *parent, int
> index,
> struct udevice **devp);
>
> /**
> - * device_get_child_count() - Get the available child count of a device
> + * device_get_child_count() - Get the child count of a device
> *
> * Returns the number of children to a device.
> *
> @@ -601,6 +601,15 @@ int device_get_child(const struct udevice *parent, int
> index,
> */
> int device_get_child_count(const struct udevice *parent);
>
> +/**
> + * device_get_decendent_count() - Get the total number of decendents of a
> device
> + *
> + * Returns the total number of decendents, including all children
> + *
> + * @parent:Parent device to check
> + */
> +int device_get_decendent_count(const struct udevice *parent);
> +
> /**
> * device_find_child_by_seq() - Find a child device based on a sequence
> *
> diff --git a/include/dm/root.h b/include/dm/root.h
> index 42510b106ab..780f269db65 100644
> --- a/include/dm/root.h
> +++ b/include/dm/root.h
> @@ -131,4 +131,12 @@ int dm_remove_devices_flags(uint flags);
> static inline int dm_remove_devices_flags(uint flags) { return 0; }
> #endif
>
> +/**
> + * dm_get_stats() - Get some stats for driver mode
> + *
> + * @device_countp: Returns total number of devices that are bound
> + * @uclass_countp: Returns total number of uclasses in use
> + */
> +void dm_get_stats(int *device_countp, int *uclass_countp);
> +
> #endif
> diff --git a/include/dm/uclass-internal.h b/include/dm/uclass-internal.h
> index 57c664c6daa..c71d8b1de45 100644
> --- a/include/dm/uclass-internal.h
> +++ b/include/dm/uclass-internal.h
> @@ -294,6 +294,13 @@ int uclass_pre_remove_device(struct udevice *dev);
> static inline int uclass_pre_remove_device(struct udevice *dev) { return 0; }
> #endif
>
> +/**
> + * uclass_get_count() - Get the number of uclasses
> + *
> + * Returns the number of uclasses instantiated in driver model
> + */
> +int uclass_get_count(void);
> +
> /**
> * uclass_find() - Find uclass by its id
> *
> diff --git a/test/dm/core.c b/test/dm/core.c
> index
Re: [PATCH] mtd: cqspi: Wait for transfer completion
Hi Pratyush,
On Tue, Oct 26, 2021 at 1:23 AM Pratyush Yadav wrote:
>
> On 08/10/21 06:06PM, Jagan Teki wrote:
> > On Wed, Sep 15, 2021 at 2:05 PM Marek Vasut wrote:
> > >
> > > On 9/15/21 10:28 AM, Pratyush Yadav wrote:
> > > > On 14/09/21 08:22PM, Marek Vasut wrote:
> > > >> On 9/14/21 7:42 PM, Pratyush Yadav wrote:
> > > >>> On 14/09/21 05:22AM, Marek Vasut wrote:
> > > Wait for the read/write transfer finish bit get actually cleared,
> > > this does not happen immediately on at least SoCFPGA Gen5.
> > >
> > > Signed-off-by: Marek Vasut
> > > Cc: Jagan Teki
> > > Cc: Vignesh R
> > > Cc: Pratyush Yadav
> > > ---
> > > drivers/spi/cadence_qspi_apb.c | 17 +
> > > 1 file changed, 17 insertions(+)
> > >
> > > diff --git a/drivers/spi/cadence_qspi_apb.c
> > > b/drivers/spi/cadence_qspi_apb.c
> > > index 429ee335db6..2cdf4c9c9f8 100644
> > > --- a/drivers/spi/cadence_qspi_apb.c
> > > +++ b/drivers/spi/cadence_qspi_apb.c
> > > @@ -858,6 +858,14 @@ cadence_qspi_apb_indirect_read_execute(struct
> > > cadence_spi_plat *plat,
> > > writel(CQSPI_REG_INDIRECTRD_DONE,
> > > plat->regbase + CQSPI_REG_INDIRECTRD);
> > > + /* Check indirect done status */
> > > + ret = wait_for_bit_le32(plat->regbase + CQSPI_REG_INDIRECTRD,
> > > + CQSPI_REG_INDIRECTRD_DONE, 0, 10, 0);
> > > + if (ret) {
> > > + printf("Indirect read clear completion error (%i)\n",
> > > ret);
> > > + goto failrd;
> > > + }
> > > +
> > > >>>
> > > >>> Huh, this is strange. I would expect the bit to clear immediately
> > > >>> since
> > > >>> it doesn't really do any operation on the flash. How long does it
> > > >>> usually take to clear? If you don't wait for it to clear does anything
> > > >>> break?
> > > >>
> > > >> Often it does clear immediately, but there were a few odd cases where
> > > >> it did
> > > >> not happen right away, in which case I had transfer corruption.
> > > >
> > > > By "transfer corruption" do you mean the current transfer gets corrupted
> > > > or the next one?
> > > >
> > > > We get here _after_ the transfer is completed and this bit should have
> > > > little to do with the data received. If the current transfer fails then
> > > > I suspect something else might be going wrong the this is just a symptom
> > > > of the problem.
> > >
> > > As far as I recall, the problem was triggered when using UBI on the SPI
> > > NOR, so that could very well be the next transfer.
> >
> > Any further decisions here? shall I take it or v2?
>
> I think we need more information here. I don't see why checking this bit
> would interfere with the current transfer since that is already finished
> by the time we get here. If it is the next transfer then this might just
> be a symptom and the real problem might be somewhere else.
Do you mean the bit is using on the patch is not proper for all
transfers? did you find any issues on your tests some where? please
indicate what's wrong?
Jagan.
Re: [PATCH 02/31] kconfig: Add support for conditional values
On Mon, 1 Nov 2021 at 03:19, Simon Glass wrote:
>
> At present if an optional Kconfig value needs to be used it must be
> bracketed by #ifdef. For example, with this Kconfig setup:
>
> config WIBBLE
> bool "Support wibbles, the world needs more wibbles"
>
> config WIBBLE_ADDR
> hex "Address of the wibble"
> depends on WIBBLE
>
> then the following code must be used:
>
> #ifdef CONFIG_WIBBLE
> static void handle_wibble(void)
> {
> int val = CONFIG_WIBBLE_ADDR;
>
> ...
> }
> #endif
>
The example here might be a bit off and we might need this for int
related values. Was this function handle_wibble() supposed to return
an int or not? We could shield the linker easier here without adding
macros. Something along the lines of
static void handle_wibble(void)
{
#ifdef CONFIG_WIBBLE
int val = CONFIG_WIBBLE_ADDR;
#endif
}
In that case you don't an extra ifdef to call handle_wibble().
Personally I find this easier to read.
> static void init_machine()
> {
> ...
> #ifdef CONFIG_WIBBLE
> handle_wibble();
> #endif
> }
>
> Add a new IF_ENABLED_INT() to help with this. So now it is possible to
> write, without #ifdefs:
>
> static void handle_wibble(void)
> {
> int val = IF_ENABLED_INT(CONFIG_WIBBLE, CONFIG_WIBBLE_ADDR);
>
> ...
> }
>
> static void init_machine()
> {
> ...
> if (IS_ENABLED(CONFIG_WIBBLE))
> handle_wibble();
> }
>
> The value will be 0 if CONFIG_WIBBLE is not defined, and
> CONFIG_WIBBLE_ADDR if it is. This allows us to reduce the use of #ifdef in
> the code, ensuring that the compiler still checks the code even if it is
> not ultimately used for a particular build.
>
> Add a CONFIG_IF_ENABLED_INT() version as well.
>
> Signed-off-by: Simon Glass
> ---
>
> include/linux/kconfig.h | 18 ++
> scripts/config_whitelist.txt | 1 +
> 2 files changed, 19 insertions(+)
>
> diff --git a/include/linux/kconfig.h b/include/linux/kconfig.h
> index a1d1a298426..119c698a158 100644
> --- a/include/linux/kconfig.h
> +++ b/include/linux/kconfig.h
> @@ -59,6 +59,18 @@
> */
> #define CONFIG_VAL(option) config_val(option)
>
> +/* This use a similar mechanism to config_enabled() above */
> +#define config_opt_enabled(cfg, opt_cfg) _config_opt_enabled(cfg, opt_cfg)
> +#define _config_opt_enabled(cfg_val, opt_value) \
> + __config_opt_enabled(__ARG_PLACEHOLDER_##cfg_val, opt_value)
> +#define __config_opt_enabled(arg1_or_junk, arg2) \
> + ___config_opt_enabled(arg1_or_junk arg2, 0)
> +#define ___config_opt_enabled(__ignored, val, ...) val
> +
> +/* Evaluates to 0 if option is not defined, int_option if it is defined */
> +#define IF_ENABLED_INT(option, int_option) \
> + config_opt_enabled(option, int_option)
> +
> /*
> * Count number of arguments to a variadic macro. Currently only need
> * it for 1, 2 or 3 arguments.
> @@ -113,5 +125,11 @@
> #define CONFIG_IS_ENABLED(option, ...) \
> __concat(__CONFIG_IS_ENABLED_, __count_args(option, ##__VA_ARGS__))
> (option, ##__VA_ARGS__)
>
> +/*
> + * Evaluates to 0 if SPL_/TPL_/option is not defined, SPL_/TPL_int_option if
> it
> + * is defined
> + */
> +#define CONFIG_IF_ENABLED_INT(option, int_option) \
> + CONFIG_IS_ENABLED(option, (CONFIG_VAL(int_option)), (0))
>
> #endif /* __LINUX_KCONFIG_H */
> diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
> index 022a27288c9..f9d9f4a9cfe 100644
> --- a/scripts/config_whitelist.txt
> +++ b/scripts/config_whitelist.txt
> @@ -609,6 +609,7 @@ CONFIG_ICS307_REFCLK_HZ
> CONFIG_IDE_PREINIT
> CONFIG_IDE_RESET
> CONFIG_IDE_SWAP_IO
> +CONFIG_IF_ENABLED_INT
> CONFIG_IMA
> CONFIG_IMX
> CONFIG_IMX6_PWM_PER_CLK
> --
> 2.33.1.1089.g2158813163f-goog
>
Regards
/Ilias
Re: [PATCH v3 3/5] sandbox: Detect the host bit size automatically
On Sunday 01 August 2021 18:56:11 Simon Glass wrote:
> At present if you build sandbox on a 32-bit host a lot of errors are
> produced. This is because CONFIG_HOST_64BIT is enabled by default.
>
> It is quite annoying to have to change that manually before building
> sandbox. It is also quite confusing for new users.
>
> Add a way to detect the setting and add the appropriate
> CONFIG_HOST_64BIT=y or CONFIG_HOST_32BIT=y to the defconfig, to avoid
> this issue.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v3:
> - Use 'bitness' instead of 'bit'
>
> Changes in v2:
> - Drop patches previously applied
> - Put all the packages in gcc.rst
>
> Makefile | 11 ++-
> arch/sandbox/Kconfig | 13 -
> scripts/kconfig/Makefile | 14 +-
> 3 files changed, 31 insertions(+), 7 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 269e353a28a..57c3e9a77df 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -565,8 +565,17 @@ export KBUILD_DEFCONFIG KBUILD_KCONFIG
> config: scripts_basic outputmakefile FORCE
> $(Q)$(MAKE) $(build)=scripts/kconfig $@
>
> +# If nothing is specified explicitly, detect the bit size for sandbox,
> +# referred to from arch/sandbox/Kconfig
> +# Add it to the end of the defconfig file
> %config: scripts_basic outputmakefile FORCE
> - $(Q)$(MAKE) $(build)=scripts/kconfig $@
> + $(Q)if test -f $(srctree)/configs/$@ && \
> + ! grep -Eq "CONFIG_HOST_(32|64)BIT=y" $(srctree)/configs/$@;
> then \
> + echo '#include \nint main(void) {
> printf("CONFIG_HOST_%dBIT=y\\n", __WORDSIZE); return 0; }' \
> + | gcc -x c - -o get_word_size; \
Should not Makefile use user's specified compiler instead of hardcoded 'gcc'?
> + extra=$$(./get_word_size); \
> + fi; \
> + $(MAKE) $(build)=scripts/kconfig EXTRA_DEFCONFIG=$$extra $@
>
> else
> # ===
> diff --git a/arch/sandbox/Kconfig b/arch/sandbox/Kconfig
> index f83282d9d56..0332aaee798 100644
> --- a/arch/sandbox/Kconfig
> +++ b/arch/sandbox/Kconfig
> @@ -35,12 +35,12 @@ config SYS_CONFIG_NAME
>
> choice
> prompt "Run sandbox on 32/64-bit host"
> - default HOST_64BIT
> + default HOST_DETECT_BITNESS
> help
> - Sandbox can be built on 32-bit and 64-bit hosts.
> - The default is to build on a 64-bit host and run
> - on a 64-bit host. If you want to run sandbox on
> - a 32-bit host, change it here.
> + Sandbox can be built on 32-bit and 64-bit hosts. This is generally
> + auto-detected but you can force a particular word size here. If you
> + see strange warnings about SANDBOX_BITS_PER_LONG then you may have
> + selected the wrong value.
>
> config HOST_32BIT
> bool "32-bit host"
> @@ -49,6 +49,9 @@ config HOST_32BIT
> config HOST_64BIT
> bool "64-bit host"
>
> +config HOST_DETECT_BITNESS
> + bool "Auto-detect host bitness"
> +
> endchoice
>
> config SANDBOX_CRASH_RESET
> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> index d52128425ce..8e14db7ade3 100644
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -12,6 +12,9 @@ PHONY += xconfig gconfig menuconfig config localmodconfig
> localyesconfig \
> # Set SRCARCH to .. fake this Makefile.
> SRCARCH := ..
>
> +# For U-Boot, EXTRA_DEFCONFIG contains a line to be added to the defconfig
> +# before processing. If empty, no line is added.
> +
> ifdef KBUILD_KCONFIG
> Kconfig := $(KBUILD_KCONFIG)
> else
> @@ -92,8 +95,17 @@ else
> endif
> endif
>
> +# If EXTRA_DEFCONFIG is defined, add it to the end of the defconfig, before
> +# processing. This allows the caller to change a setting on the fly
> %_defconfig: $(obj)/conf
> - $(Q)$< $(silent) --defconfig=arch/$(SRCARCH)/configs/$@ $(Kconfig)
> + $(Q)defconfig="$(srctree)/arch/$(SRCARCH)/configs/$@"; \
> + if [ -n "$(EXTRA_DEFCONFIG)" ]; then \
> + cat $$defconfig >defconfig_tmp; \
> + echo $(EXTRA_DEFCONFIG) >>defconfig_tmp; \
> + $< $(silent) --defconfig=defconfig_tmp $(Kconfig); \
> + else \
> + $< $(silent) --defconfig=$$defconfig $(Kconfig); \
> + fi
>
> # Added for U-Boot (backward compatibility)
> %_config: %_defconfig
> --
> 2.32.0.554.ge1b32706d8-goog
>
Re: [PATCH] image: fix select_ramdisk for raw initrd
Hi Simon, Tom , and ...
> Do we need this patch as well as the other one? If so, can you combine them?
> Also, is it possible to drop the assignment to rd_addr at the top of
the function?
this patch must be replaced by another one
https://patchwork.ozlabs.org/project/uboot/patch/20211016051915.4157293-1-...@khadas.com/
( last patch will be enough alone)
On Mon, Nov 1, 2021 at 7:47 AM Simon Glass wrote:
>
> Hi Artem,
>
> On Fri, 15 Oct 2021 at 04:15, Artem Lapkin wrote:
> >
> > Problem
> >
> > We have unbootable raw initrd images because, select_ramdisk for raw
> > initrd images ignore submited select addr and setup rd_datap value to 0
> >
> > Solution: setup rd_datap value from select
> >
> > Signed-off-by: Artem Lapkin
> > ---
> > common/image-board.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Do we need this patch as well as the other one? If so, can you combine them?
>
> Also, is it possible to drop the assignment to rd_addr at the top of
> the function?
>
> >
> > diff --git a/common/image-board.c b/common/image-board.c
> > index e7660352e9..e3c6ea806a 100644
> > --- a/common/image-board.c
> > +++ b/common/image-board.c
> > @@ -439,7 +439,7 @@ static int select_ramdisk(bootm_headers_t *images,
> > const char *select, u8 arch,
> > end = strchr(select, ':');
> > if (end) {
> > *rd_lenp = hextoul(++end, NULL);
> > - *rd_datap = rd_addr;
> > + *rd_datap = hextoul(select, NULL);
> > processed = true;
> > }
> > }
> > --
> > 2.25.1
> >
>
> Regards,
> Simon
Re: [PATCH 01/31] Makefile: Correct TPL rule for OF_REAL
Hi Simon,
As I expect this series to go through some versions before we agree on
something and this seems like a pure bugfix can you split it of as a
single patch?
On Mon, 1 Nov 2021 at 03:19, Simon Glass wrote:
>
> Correct an error in the tpl-dtb parameter to binman. At present the TPL
> rule follows SPL but this is not correct, if TPL uses of-platdata, for
> example.
>
> Fixes: f99cbe4e867 ("fdt: Update Makefile rules with the new OF_REAL Kconfig")
> Signed-off-by: Simon Glass
> ---
>
> Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 09a5cea8cb8..d256a3cdc33 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1309,7 +1309,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if
> $(BINMAN_DEBUG),-D) \
> -a spl-bss-pad=$(if $(CONFIG_SPL_SEPARATE_BSS),,1) \
> -a tpl-bss-pad=$(if $(CONFIG_TPL_SEPARATE_BSS),,1) \
> -a spl-dtb=$(CONFIG_SPL_OF_REAL) \
> - -a tpl-dtb=$(CONFIG_SPL_OF_REAL) \
> + -a tpl-dtb=$(CONFIG_TPL_OF_REAL) \
> $(BINMAN_$(@F))
>
> OBJCOPYFLAGS_u-boot.ldr.hex := -I binary -O ihex
> --
> 2.33.1.1089.g2158813163f-goog
>
Reviewed-by: Ilias Apalodimas
Re: [PATCH] image-board: fix wrong implementation ram disk address setup from cmdline
hi Simon
> Fixes: f33a2c1bd0f ("image: Remove #ifdefs from select_ramdisk()")
> (I believe, can you confirm?)
confirm f33a2c1bd0f has wrong implementation logic for raw ramdisk image
sure i have tested it ...
On Mon, Nov 1, 2021 at 7:47 AM Simon Glass wrote:
>
> Hi Artem,
>
> On Fri, 15 Oct 2021 at 23:19, Artem Lapkin wrote:
> >
> > Problem
> >
> > Wrong implementation logic: ramdisk cmdline image address always ignored!
> > Next block { rd_addr = hextoul(select, NULL) } unusable for raw initrd.
> >
> > We have unbootable raw initrd images because, select_ramdisk for raw
> > initrd images ignore submited select addr and setup rd_datap value to 0
> >
> > Come-from:
> > https://patchwork.ozlabs.org/project/uboot/patch/20211015101501.4091141-1-...@khadas.com/
> >
> > Signed-off-by: Artem Lapkin
> > ---
> > common/image-board.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
>
> Fixes: f33a2c1bd0f ("image: Remove #ifdefs from select_ramdisk()")
>
> (I believe, can you confirm?)
>
> Reviewed-by: Simon Glass
>
>
> >
> > diff --git a/common/image-board.c b/common/image-board.c
> > index e7660352e9..e7063016ef 100644
> > --- a/common/image-board.c
> > +++ b/common/image-board.c
> > @@ -333,7 +333,7 @@ static int select_ramdisk(bootm_headers_t *images,
> > const char *select, u8 arch,
> >
> > if (select) {
> > ulong default_addr;
> > - bool done = true;
> > + bool done = false;
> >
> > if (CONFIG_IS_ENABLED(FIT)) {
> > /*
> > @@ -351,13 +351,13 @@ static int select_ramdisk(bootm_headers_t *images,
> > const char *select, u8 arch,
> >_uname_config)) {
> > debug("* ramdisk: config '%s' from image
> > at 0x%08lx\n",
> > fit_uname_config, rd_addr);
> > + done = true;
> > } else if (fit_parse_subimage(select, default_addr,
> > _addr,
> > _uname_ramdisk)) {
> > debug("* ramdisk: subimage '%s' from image
> > at 0x%08lx\n",
> > fit_uname_ramdisk, rd_addr);
> > - } else {
> > - done = false;
> > + done = true;
> > }
> > }
> > if (!done) {
> > --
> > 2.25.1
> >
Re: [RFC PATCH] RFC: Sketch of dm event notification
Hello Simon,
On Sun, Oct 31, 2021 at 09:07:01PM -0600, Simon Glass wrote:
> This is a patch for Takahiro to look at, just for illustration. Not ready
> for review.
Thank you for posting the draft.
At a first glance, it looks good and I don't see any specific issue
with your implementation.
Since my code has already added DM_TAG support, I'm looking forward for
getting your final patch.
The only remaining issue is *modeling* partitions :)
-Takahiro Akashi
> To run the test:
>
> ./u-boot -T -c "ut common test_event_probe"
>
> Signed-off-by: Simon Glass
> ---
>
> common/Kconfig| 11
> common/Makefile | 2 +
> common/board_f.c | 2 +
> common/event.c| 103 ++
> common/log.c | 1 +
> drivers/core/device.c | 14
> include/asm-generic/global_data.h | 3 +
> include/event.h | 103 ++
> include/event_internal.h | 34 ++
> include/log.h | 2 +
> test/common/Makefile | 1 +
> test/common/event.c | 85
> test/test-main.c | 5 ++
> 13 files changed, 366 insertions(+)
> create mode 100644 common/event.c
> create mode 100644 include/event.h
> create mode 100644 include/event_internal.h
> create mode 100644 test/common/event.c
>
> diff --git a/common/Kconfig b/common/Kconfig
> index d6f77ab7b9c..54d0adaa8d5 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -484,6 +484,17 @@ config DISPLAY_BOARDINFO_LATE
>
> menu "Start-up hooks"
>
> +config EVENT
> + bool "General-purpose event-handling mechanism"
> + default y if SANDBOX
> + help
> + This enables sending and processing of events, to allow interested
> + parties to be alerted when something happens. This is an attempt to
> + step the flow of weak functions, hooks, functions in board_f.c
> + and board_r.c and the Kconfig options below.
> +
> + See doc/develop/event.rst for more information.
> +
> config ARCH_EARLY_INIT_R
> bool "Call arch-specific init soon after relocation"
> help
> diff --git a/common/Makefile b/common/Makefile
> index e7839027b6c..1b4601ac13f 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -101,6 +101,8 @@ obj-y += malloc_simple.o
> endif
> endif
>
> +obj-$(CONFIG_EVENT) += event.o
> +
> obj-y += image.o image-board.o
> obj-$(CONFIG_$(SPL_TPL_)HASH) += hash.o
> obj-$(CONFIG_ANDROID_AB) += android_ab.o
> diff --git a/common/board_f.c b/common/board_f.c
> index 3dc0eaa59c5..faf262d564c 100644
> --- a/common/board_f.c
> +++ b/common/board_f.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -820,6 +821,7 @@ static const init_fnc_t init_sequence_f[] = {
> initf_malloc,
> log_init,
> initf_bootstage,/* uses its own timer, so does not need DM */
> + event_init,
> #ifdef CONFIG_BLOBLIST
> bloblist_init,
> #endif
> diff --git a/common/event.c b/common/event.c
> new file mode 100644
> index 000..428628da44d
> --- /dev/null
> +++ b/common/event.c
> @@ -0,0 +1,103 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Events provide a general-purpose way to react to / subscribe to changes
> + * within U-Boot
> + *
> + * Copyright 2021 Google LLC
> + * Written by Simon Glass
> + */
> +
> +#define LOG_CATEGORY LOGC_EVENT
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static void spy_free(struct event_spy *spy)
> +{
> + list_del(>sibling_node);
> +}
> +
> +int event_register(const char *id, enum event_t type, event_handler_t func,
> void *ctx)
> +{
> + struct event_state *state = gd->event_state;
> + struct event_spy *spy;
> +
> + spy = malloc(sizeof(*spy));
> + if (!spy)
> + return log_msg_ret("alloc", -ENOMEM);
> +
> + spy->id = id;
> + spy->type = type;
> + spy->func = func;
> + spy->ctx = ctx;
> + list_add_tail(>sibling_node, >spy_head);
> +
> + return 0;
> +}
> +
> +int event_notify(enum event_t type, void *data, int size)
> +{
> + struct event_state *state = gd->event_state;
> + struct event_spy *spy, *next;
> + struct event event;
> +
> + event.type = type;
> + if (size > sizeof(event.data))
> + return log_msg_ret("size", -E2BIG);
> + memcpy(, data, size);
> + list_for_each_entry_safe(spy, next, >spy_head, sibling_node) {
> + if (spy->type == type) {
> + int ret;
> +
> + log_debug("Sending event %x to spy '%s'\n", type,
> + spy->id);
> + ret = spy->func(spy->ctx, );
> +
> + /*
> + * TODO: Handle various return codes
