[PATCH v2 2/2] riscv: cpu: make riscv_cpu_probe to EVT_DM_POST_INIT_R callback
Since the Patch 55171aedda88, VisionFive2 booting has been broken [1].
VisionFive2 board requires to enable CONFIG_TIMER_EARLY but booting went
to panic from initr_dm_devices due to lack of a timer device.
- Error logs
initcall sequence fffd8d38 failed at call 402185e4
(err=-19)
Thus, we need to move riscv_cpu_probe function in order to register
the timer earlier than initr_dm_devices.
Fixes: 7fe32b3442f0 ("event: Convert arch_cpu_init_dm() to use events")
Cc: Simon Glass
Cc: Bin Meng
Signed-off-by: Chanho Park
---
arch/riscv/cpu/cpu.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
index ecfb1fb08c4b..0b4208e72199 100644
--- a/arch/riscv/cpu/cpu.c
+++ b/arch/riscv/cpu/cpu.c
@@ -66,7 +66,7 @@ static inline bool supports_extension(char ext)
#endif /* CONFIG_CPU */
}
-static int riscv_cpu_probe(void)
+static int riscv_cpu_probe(void *ctx, struct event *event)
{
#ifdef CONFIG_CPU
int ret;
@@ -79,6 +79,7 @@ static int riscv_cpu_probe(void)
return 0;
}
+EVENT_SPY(EVT_DM_POST_INIT_R, riscv_cpu_probe);
/*
* This is called on secondary harts just after the IPI is init'd. Currently
@@ -95,7 +96,7 @@ int riscv_cpu_setup(void *ctx, struct event *event)
{
int ret;
- ret = riscv_cpu_probe();
+ ret = riscv_cpu_probe(ctx, event);
if (ret)
return ret;
@@ -149,12 +150,6 @@ EVENT_SPY(EVT_DM_POST_INIT_F, riscv_cpu_setup);
int arch_early_init_r(void)
{
- int ret;
-
- ret = riscv_cpu_probe();
- if (ret)
- return ret;
-
if (IS_ENABLED(CONFIG_SYSRESET_SBI))
device_bind_driver(gd->dm_root, "sbi-sysreset",
"sbi-sysreset", NULL);
--
2.39.2
[PATCH v2 0/2] introduce EVT_DM_POST_INIT_R to fix VF2 boot fail
Since the Patch 55171aedda88, VisionFive2 booting has been broken [1]. VisionFive2 board requires to enable CONFIG_TIMER_EARLY but booting went to panic from initr_dm_devices due to lack of a timer device. - Error logs initcall sequence fffd8d38 failed at call 402185e4 (err=-19) We can reproduce it on Qemu Sifive HiFive Unleashed emulation[2] after enabling CONFIG_TIMER_EARLY manually. As suggested by Simon[3], we can address this by adding EVT_DM_POST_INIT_R event and it's spy-callback function. Changes from v1: - Add EVT_DM_POST_INIT_R event type and emit it after relocation - Make riscv_cpu_probe as the callback of EVT_DM_POST_INIT_R [1]: https://lists.denx.de/pipermail/u-boot/2023-June/521220.html [2]: https://www.qemu.org/docs/master/system/riscv/sifive_u.html#running-u-boot [3]: https://lore.kernel.org/u-boot/capnjgz2pbhvy_wlvq7xcd-hykkwoh8r3lgxfoo7s6sbvj0+...@mail.gmail.com/ Chanho Park (2): dm: event: add EVT_DM_POST_INIT_R event type riscv: cpu: make riscv_cpu_probe to EVT_DM_POST_INIT_R callback arch/riscv/cpu/cpu.c | 11 +++ drivers/core/root.c | 6 -- include/event.h | 1 + 3 files changed, 8 insertions(+), 10 deletions(-) -- 2.39.2
[PATCH v2 1/2] dm: event: add EVT_DM_POST_INIT_R event type
This patch introduces EVT_DM_POST_INIT_R event type for handling hooks
after relocation.
Fixes: 55171aedda88 ("dm: Emit the arch_cpu_init_dm() even only before
relocation")
Suggested-by: Simon Glass
Cc: Bin Meng
Signed-off-by: Chanho Park
---
drivers/core/root.c | 6 --
include/event.h | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/core/root.c b/drivers/core/root.c
index 6775fb0b6575..79d871ab291a 100644
--- a/drivers/core/root.c
+++ b/drivers/core/root.c
@@ -436,8 +436,10 @@ int dm_init_and_scan(bool pre_reloc_only)
return ret;
}
}
- if (CONFIG_IS_ENABLED(DM_EVENT) && !(gd->flags & GD_FLG_RELOC)) {
- ret = event_notify_null(EVT_DM_POST_INIT_F);
+ if (CONFIG_IS_ENABLED(DM_EVENT)) {
+ ret = event_notify_null(gd->flags & GD_FLG_RELOC ?
+ EVT_DM_POST_INIT_R :
+ EVT_DM_POST_INIT_F);
if (ret)
return log_msg_ret("ev", ret);
}
diff --git a/include/event.h b/include/event.h
index daf44bf8a83b..bb38ba98e73b 100644
--- a/include/event.h
+++ b/include/event.h
@@ -24,6 +24,7 @@ enum event_t {
/* Events related to driver model */
EVT_DM_POST_INIT_F,
+ EVT_DM_POST_INIT_R,
EVT_DM_PRE_PROBE,
EVT_DM_POST_PROBE,
EVT_DM_PRE_REMOVE,
--
2.39.2
RE: [PATCH] dm: core: allow DM_POST_INIT_F notification for TIMER_EARLY
Hi Simon,
> -Original Message-
> From: Simon Glass
> Sent: Wednesday, August 9, 2023 2:54 AM
> To: Chanho Park
> Cc: u-boot@lists.denx.de; Bin Meng
> Subject: Re: [PATCH] dm: core: allow DM_POST_INIT_F notification for
> TIMER_EARLY
>
> Hi Chanho,
>
> On Tue, 8 Aug 2023 at 01:35, Chanho Park wrote:
> >
> > Since the Patch 55171aedda88, VisionFive2 booting has been broken [1].
> > VisionFive2 board requires to enable CONFIG_TIMER_EARLY but booting
> > went to panic from initr_dm_devices due to lack of a timer device.
> >
> > - Error logs
> > initcall sequence fffd8d38 failed at call 402185e4
> > (err=-19)
> >
> > We can reproduce it on Qemu Sifive HiFive Unleashed emulation[2] after
> > enabling CONFIG_TIMER_EARLY manually.
> >
> > [1]:
> > https://protect2.fireeye.com/v1/url?k=38a0f71d-592be204-38a17c52-74fe4
> > 85cbfec-8b0f4f7ae7f889ef=1=3bf1c52b-7aa0-464a-86d3-ecec3db1395d=
> > https%3A%2F%2Flists.denx.de%2Fpipermail%2Fu-boot%2F2023-June%2F521220.
> > html
> > [2]:
> > https://www.qemu.org/docs/master/system/riscv/sifive_u.html#running-u-
> > boot
> > Fixes: 55171aedda88 ("dm: Emit the arch_cpu_init_dm() even only before
> > relocation")
> > Cc: Simon Glass
> > Cc: Bin Meng
> > Signed-off-by: Chanho Park
> > ---
> > drivers/core/root.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/core/root.c b/drivers/core/root.c index
> > 6775fb0b6575..e939da484b2a 100644
> > --- a/drivers/core/root.c
> > +++ b/drivers/core/root.c
> > @@ -436,7 +436,8 @@ int dm_init_and_scan(bool pre_reloc_only)
> > return ret;
> > }
> > }
> > - if (CONFIG_IS_ENABLED(DM_EVENT) && !(gd->flags & GD_FLG_RELOC)) {
> > + if (CONFIG_IS_ENABLED(DM_EVENT) &&
> > + (!(gd->flags & GD_FLG_RELOC) ||
> > + CONFIG_IS_ENABLED(TIMER_EARLY))) {
> > ret = event_notify_null(EVT_DM_POST_INIT_F);
> > if (ret)
> > return log_msg_ret("ev", ret);
> > --
> > 2.39.2
> >
>
> It looks like you need a new notification. The correct fix would be to add
> a new EVT_DM_POST_INIT_R event and emit that after relocation, e.g.
>
> if (CONFIG_IS_ENABLED(DM_EVENT) {
>ret = event_notify_null(gd->flags & GD_FLG_RELOC ?
> EVT_DM_POST_INIT_R : EVT_DM_POST_INIT_F);
>if (ret)
> return log_msg_ret("ev", ret);
> }
Sorry for this late reply.
I feel like I need to move riscv_cpu_probe call from arch_early_init_r and make
it as the callback of the new event.
I'll send v2 with the changes.
Best Regards,
Chanho Park
Re: [PATCH] MAINTAINERS: Update UFS maintainer
Hi Nishanth On 17/08/23 21:27, Nishanth Menon wrote: On 17:39-20230817, Neha Malcom Francis wrote: Dropping Faiz Abbas from the UFS maintainer list as his e-mail ID is no longer valid. Adding Bhupesh Sharma who has been using this framework working on Qualcomm Snapdragon SoCs as well as sending out fixes. Adding myself as well to support in reviewing and testing patches. Signed-off-by: Neha Malcom Francis Cc: Bhupesh Sharma Cc: Vignesh R Cc: Nishnath Menon Thanks for mixing my name up, but other than that, for what ever it is worth.. > Reviewed-by: Nishanth Menon My bad, sorry about that! But thanks! --- Based on discussion: https://lore.kernel.org/u-boot/CAH=2NtzyQgximynKuG45UUux715Du=wkkusm9-aqghcuzsw...@mail.gmail.com/ MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 77a8b0ac21..d19e1fd60b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1585,7 +1585,8 @@ T:git https://source.denx.de/u-boot/custodians/u-boot-ubi.git F:drivers/mtd/ubi/ UFS -M: Faiz Abbas +M: Bhupesh Sharma +M: Neha Malcom Francis S:Maintained F:drivers/ufs/ -- 2.34.1 -- Thanking You Neha Malcom Francis
Re: [PATCH] MAINTAINERS: Update UFS maintainer
Hi Marek On 18/08/23 00:10, Marek Vasut wrote: On 8/17/23 14:09, Neha Malcom Francis wrote: Dropping Faiz Abbas from the UFS maintainer list as his e-mail ID is no longer valid. Adding Bhupesh Sharma who has been using this framework working on Qualcomm Snapdragon SoCs as well as sending out fixes. Adding myself as well to support in reviewing and testing patches. Signed-off-by: Neha Malcom Francis Add '---' here so the CC list is not part of the commit message when this patch is applied, like this: Signed-of-by: Foo User <...> --- CC: Bar Example <...> ... --- V2: Did stuff V3: Did more stuff Thanks for this! Will keep in mind in future. Cc: Bhupesh Sharma Cc: Vignesh R Cc: Nishnath Menon --- Based on discussion: https://lore.kernel.org/u-boot/CAH=2NtzyQgximynKuG45UUux715Du=wkkusm9-aqghcuzsw...@mail.gmail.com/ MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 77a8b0ac21..d19e1fd60b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1585,7 +1585,8 @@ T: git https://source.denx.de/u-boot/custodians/u-boot-ubi.git F: drivers/mtd/ubi/ UFS -M: Faiz Abbas +M: Bhupesh Sharma +M: Neha Malcom Francis S: Maintained F: drivers/ufs/ With that fixed: Acked-by: Marek Vasut Thanks -- Thanking You Neha Malcom Francis
[PATCH 7/7] spi: zynq_qspi: Add parallel memories support in QSPI driver
Add support for parallel memories in zynq_qspi.c driver. In case of
parallel memories STRIPE bit is set and sent to the qspi ip, which will
send data bits to both the flashes in parallel. However for few commands
we should not use stripe, instead send same data to both the flashes.
Those commands are exclueded by using zynqmp_qspi_update_stripe().
Also update copyright info for this file.
Signed-off-by: Ashok Reddy Soma
Signed-off-by: Venkatesh Yadav Abbarapu
---
drivers/spi/zynq_qspi.c | 139
include/spi.h | 3 +
2 files changed, 129 insertions(+), 13 deletions(-)
diff --git a/drivers/spi/zynq_qspi.c b/drivers/spi/zynq_qspi.c
index 069d2a77de..9f4c1f487b 100644
--- a/drivers/spi/zynq_qspi.c
+++ b/drivers/spi/zynq_qspi.c
@@ -1,7 +1,8 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * (C) Copyright 2013 Xilinx, Inc.
+ * (C) Copyright 2013 - 2022, Xilinx, Inc.
* (C) Copyright 2015 Jagan Teki
+ * (C) Copyright 2023, Advanced Micro Devices, Inc.
*
* Xilinx Zynq Quad-SPI(QSPI) controller driver (master mode only)
*/
@@ -13,10 +14,12 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+#include "../mtd/spi/sf_internal.h"
DECLARE_GLOBAL_DATA_PTR;
@@ -42,6 +45,22 @@ DECLARE_GLOBAL_DATA_PTR;
#define ZYNQ_QSPI_TXD_00_01_OFFSET 0x80/* Transmit 1-byte inst */
#define ZYNQ_QSPI_TXD_00_10_OFFSET 0x84/* Transmit 2-byte inst */
#define ZYNQ_QSPI_TXD_00_11_OFFSET 0x88/* Transmit 3-byte inst */
+#define ZYNQ_QSPI_FR_QOUT_CODE 0x6B/* read instruction code */
+#define ZYNQ_QSPI_FR_DUALIO_CODE 0xBB
+
+#define QSPI_SELECT_LOWER_CS BIT(0)
+#define QSPI_SELECT_UPPER_CS BIT(1)
+
+/*
+ * QSPI Linear Configuration Register
+ *
+ * It is named Linear Configuration but it controls other modes when not in
+ * linear mode also.
+ */
+#define ZYNQ_QSPI_LCFG_TWO_MEM_MASK0x4000 /* QSPI Enable Bit Mask */
+#define ZYNQ_QSPI_LCFG_SEP_BUS_MASK0x2000 /* QSPI Enable Bit Mask */
+#define ZYNQ_QSPI_LCFG_U_PAGE 0x1000 /* QSPI Upper memory set */
+#define ZYNQ_QSPI_LCFG_DUMMY_SHIFT 8
#define ZYNQ_QSPI_TXFIFO_THRESHOLD 1 /* Tx FIFO threshold level*/
#define ZYNQ_QSPI_RXFIFO_THRESHOLD 32 /* Rx FIFO threshold level */
@@ -101,7 +120,12 @@ struct zynq_qspi_priv {
int bytes_to_transfer;
int bytes_to_receive;
unsigned int is_inst;
+ unsigned int is_parallel;
+ unsigned int is_stacked;
+ unsigned int is_dio;
+ unsigned int u_page;
unsigned cs_change:1;
+ unsigned is_strip:1;
};
static int zynq_qspi_of_to_plat(struct udevice *bus)
@@ -112,7 +136,6 @@ static int zynq_qspi_of_to_plat(struct udevice *bus)
plat->regs = (struct zynq_qspi_regs *)fdtdec_get_addr(blob,
node, "reg");
-
return 0;
}
@@ -147,6 +170,9 @@ static void zynq_qspi_init_hw(struct zynq_qspi_priv *priv)
/* Disable Interrupts */
writel(ZYNQ_QSPI_IXR_ALL_MASK, >idr);
+ /* Disable linear mode as the boot loader may have used it */
+ writel(0x0, >lqspicfg);
+
/* Clear the TX and RX threshold reg */
writel(ZYNQ_QSPI_TXFIFO_THRESHOLD, >txftr);
writel(ZYNQ_QSPI_RXFIFO_THRESHOLD, >rxftr);
@@ -164,12 +190,11 @@ static void zynq_qspi_init_hw(struct zynq_qspi_priv *priv)
confr |= ZYNQ_QSPI_CR_IFMODE_MASK | ZYNQ_QSPI_CR_MCS_MASK |
ZYNQ_QSPI_CR_PCS_MASK | ZYNQ_QSPI_CR_FW_MASK |
ZYNQ_QSPI_CR_MSTREN_MASK;
- writel(confr, >cr);
- /* Disable the LQSPI feature */
- confr = readl(>lqspicfg);
- confr &= ~ZYNQ_QSPI_LQSPICFG_LQMODE_MASK;
- writel(confr, >lqspicfg);
+ if (priv->is_stacked)
+ confr |= 0x10;
+
+ writel(confr, >cr);
/* Enable SPI */
writel(ZYNQ_QSPI_ENR_SPI_EN_MASK, >enr);
@@ -180,6 +205,8 @@ static int zynq_qspi_child_pre_probe(struct udevice *bus)
struct spi_slave *slave = dev_get_parent_priv(bus);
struct zynq_qspi_priv *priv = dev_get_priv(bus->parent);
+ slave->multi_cs_cap = true;
+ slave->dio = priv->is_dio;
priv->max_hz = slave->max_hz;
return 0;
@@ -363,8 +390,8 @@ static void zynq_qspi_fill_tx_fifo(struct zynq_qspi_priv
*priv, u32 size)
unsigned len, offset;
struct zynq_qspi_regs *regs = priv->regs;
static const unsigned offsets[4] = {
- ZYNQ_QSPI_TXD_00_00_OFFSET, ZYNQ_QSPI_TXD_00_01_OFFSET,
- ZYNQ_QSPI_TXD_00_10_OFFSET, ZYNQ_QSPI_TXD_00_11_OFFSET };
+ ZYNQ_QSPI_TXD_00_01_OFFSET, ZYNQ_QSPI_TXD_00_10_OFFSET,
+ ZYNQ_QSPI_TXD_00_11_OFFSET, ZYNQ_QSPI_TXD_00_00_OFFSET };
while ((fifocount < size) &&
(priv->bytes_to_transfer > 0)) {
@@ -386,7 +413,11 @@ static void zynq_qspi_fill_tx_fifo(struct
[PATCH 6/7] spi: zynqmp_gqspi: Add parallel memories support in GQSPI driver
Add support for parallel memories in zynqmp_gqspi.c driver. In case of
parallel memories STRIPE bit is set and sent to the qspi ip, which will
send data bits to both the flashes in parallel. However for few commands
we should not use stripe, instead send same data to both the flashes.
Those commands are exclueded by using zynqmp_qspi_update_stripe().
Also update copyright info for this file.
Signed-off-by: Ashok Reddy Soma
Signed-off-by: Venkatesh Yadav Abbarapu
---
drivers/spi/zynqmp_gqspi.c | 146 -
include/spi.h | 12 +++
2 files changed, 140 insertions(+), 18 deletions(-)
diff --git a/drivers/spi/zynqmp_gqspi.c b/drivers/spi/zynqmp_gqspi.c
index c4aee279aa..1c7483bbd8 100644
--- a/drivers/spi/zynqmp_gqspi.c
+++ b/drivers/spi/zynqmp_gqspi.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * (C) Copyright 2018 Xilinx
+ * (C) Copyright 2013 - 2022, Xilinx, Inc.
+ * (C) Copyright 2023, Advanced Micro Devices, Inc.
*
* Xilinx ZynqMP Generic Quad-SPI(QSPI) controller driver(master mode only)
*/
@@ -23,6 +24,8 @@
#include
#include
#include
+#include
+#include "../mtd/spi/sf_internal.h"
#include
#define GQSPI_GFIFO_STRT_MODE_MASK BIT(29)
@@ -86,6 +89,9 @@
#define SPI_XFER_ON_LOWER 1
#define SPI_XFER_ON_UPPER 2
+#define GQSPI_SELECT_LOWER_CS BIT(0)
+#define GQSPI_SELECT_UPPER_CS BIT(1)
+
#define GQSPI_DMA_ALIGN0x4
#define GQSPI_MAX_BAUD_RATE_VAL7
#define GQSPI_DFLT_BAUD_RATE_VAL 2
@@ -181,13 +187,14 @@ struct zynqmp_qspi_priv {
int bytes_to_transfer;
int bytes_to_receive;
const struct spi_mem_op *op;
+ unsigned int is_parallel;
+ unsigned int u_page;
+ unsigned int bus;
+ unsigned int stripe;
+ unsigned int flags;
+ u32 max_hz;
};
-__weak int zynqmp_mmio_write(const u32 address, const u32 mask, const u32
value)
-{
- return 0;
-}
-
static int zynqmp_qspi_of_to_plat(struct udevice *bus)
{
struct zynqmp_qspi_plat *plat = dev_get_plat(bus);
@@ -234,9 +241,30 @@ static u32 zynqmp_qspi_bus_select(struct zynqmp_qspi_priv
*priv)
{
u32 gqspi_fifo_reg = 0;
- gqspi_fifo_reg = GQSPI_GFIFO_LOW_BUS |
-GQSPI_GFIFO_CS_LOWER;
-
+ if (priv->is_parallel) {
+ if (priv->bus == SPI_XFER_ON_BOTH)
+ gqspi_fifo_reg = GQSPI_GFIFO_LOW_BUS |
+GQSPI_GFIFO_UP_BUS |
+GQSPI_GFIFO_CS_UPPER |
+GQSPI_GFIFO_CS_LOWER;
+ else if (priv->bus == SPI_XFER_ON_LOWER)
+ gqspi_fifo_reg = GQSPI_GFIFO_LOW_BUS |
+GQSPI_GFIFO_CS_UPPER |
+GQSPI_GFIFO_CS_LOWER;
+ else if (priv->bus == SPI_XFER_ON_UPPER)
+ gqspi_fifo_reg = GQSPI_GFIFO_UP_BUS |
+GQSPI_GFIFO_CS_LOWER |
+GQSPI_GFIFO_CS_UPPER;
+ else
+ debug("Wrong Bus selection:0x%x\n", priv->bus);
+ } else {
+ if (priv->u_page)
+ gqspi_fifo_reg = GQSPI_GFIFO_LOW_BUS |
+GQSPI_GFIFO_CS_UPPER;
+ else
+ gqspi_fifo_reg = GQSPI_GFIFO_LOW_BUS |
+GQSPI_GFIFO_CS_LOWER;
+ }
return gqspi_fifo_reg;
}
@@ -279,7 +307,6 @@ static void zynqmp_qspi_fill_gen_fifo(struct
zynqmp_qspi_priv *priv,
GQSPI_TIMEOUT, 1);
if (ret)
printf("%s Timeout\n", __func__);
-
}
static void zynqmp_qspi_chipselect(struct zynqmp_qspi_priv *priv, int is_on)
@@ -291,7 +318,13 @@ static void zynqmp_qspi_chipselect(struct zynqmp_qspi_priv
*priv, int is_on)
gqspi_fifo_reg |= GQSPI_SPI_MODE_SPI |
GQSPI_IMD_DATA_CS_ASSERT;
} else {
- gqspi_fifo_reg = GQSPI_GFIFO_LOW_BUS;
+ if (priv->is_parallel)
+ gqspi_fifo_reg = GQSPI_GFIFO_UP_BUS |
+GQSPI_GFIFO_LOW_BUS;
+ else if (priv->u_page)
+ gqspi_fifo_reg = GQSPI_GFIFO_UP_BUS;
+ else
+ gqspi_fifo_reg = GQSPI_GFIFO_LOW_BUS;
gqspi_fifo_reg |= GQSPI_IMD_DATA_CS_DEASSERT;
}
@@ -362,13 +395,15 @@ static int zynqmp_qspi_set_speed(struct udevice *bus,
uint speed)
u32 confr;
u8 baud_rate_val = 0;
- debug("%s\n", __func__);
- if (speed > plat->frequency)
- speed = plat->frequency;
+ /*
+* If speed == 0 or speed > max freq, then set speed to highest
+*/
+ if
[PATCH 5/7] spi: spi-uclass: Read chipselect and restrict capabilities
Read chipselect properties from DT which are populated using 'reg'
property and save it in plat->cs[] array for later use.
Also read multi chipselect capability which is used for
parallel-memories and return errors if they are passed on using DT but
driver is not capable of handling it.
Signed-off-by: Ashok Reddy Soma
Signed-off-by: Venkatesh Yadav Abbarapu
---
drivers/spi/spi-uclass.c | 21 -
drivers/spi/xilinx_spi.c | 4 ++--
drivers/spi/zynq_qspi.c | 6 +++---
drivers/spi/zynq_spi.c | 6 +++---
include/spi.h| 2 +-
5 files changed, 25 insertions(+), 14 deletions(-)
diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
index c929e7c1d0..cdcf16d346 100644
--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -257,7 +257,7 @@ int spi_chip_select(struct udevice *dev)
{
struct dm_spi_slave_plat *plat = dev_get_parent_plat(dev);
- return plat ? plat->cs : -ENOENT;
+ return plat ? plat->cs[0] : -ENOENT;
}
int spi_find_chip_select(struct udevice *bus, int cs, struct udevice **devp)
@@ -294,8 +294,8 @@ int spi_find_chip_select(struct udevice *bus, int cs,
struct udevice **devp)
struct dm_spi_slave_plat *plat;
plat = dev_get_parent_plat(dev);
- dev_dbg(bus, "%s: plat=%p, cs=%d\n", __func__, plat, plat->cs);
- if (plat->cs == cs) {
+ dev_dbg(bus, "%s: plat=%p, cs=%d\n", __func__, plat,
plat->cs[0]);
+ if (plat->cs[0] == cs) {
*devp = dev;
return 0;
}
@@ -448,7 +448,7 @@ int _spi_get_bus_and_cs(int busnum, int cs, int speed, int
mode,
return ret;
}
plat = dev_get_parent_plat(dev);
- plat->cs = cs;
+ plat->cs[0] = cs;
if (speed) {
plat->max_hz = speed;
} else {
@@ -479,6 +479,11 @@ int _spi_get_bus_and_cs(int busnum, int cs, int speed, int
mode,
slave = dev_get_parent_priv(dev);
bus_data = dev_get_uclass_priv(bus);
+ if ((dev_read_bool(dev, "parallel-memories")) && !slave->multi_cs_cap) {
+ dev_err(dev, "controller doesn't support multi CS\n");
+ return -EINVAL;
+ }
+
/*
* In case the operation speed is not yet established by
* dm_spi_claim_bus() ensure the bus is configured properly.
@@ -541,8 +546,14 @@ int spi_slave_of_to_plat(struct udevice *dev, struct
dm_spi_slave_plat *plat)
{
int mode = 0;
int value;
+ int ret;
+
+ ret = dev_read_u32_array(dev, "reg", plat->cs, SPI_CS_CNT_MAX);
+ if (ret && ret != -EOVERFLOW) {
+ dev_err(dev, "has no valid 'reg' property (%d)\n", ret);
+ return ret;
+ }
- plat->cs = dev_read_u32_default(dev, "reg", -1);
plat->max_hz = dev_read_u32_default(dev, "spi-max-frequency",
SPI_DEFAULT_SPEED_HZ);
if (dev_read_bool(dev, "spi-cpol"))
diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
index b58a3f632a..7c4a9b79bb 100644
--- a/drivers/spi/xilinx_spi.c
+++ b/drivers/spi/xilinx_spi.c
@@ -270,7 +270,7 @@ static void xilinx_spi_startup_block(struct spi_slave *spi)
* Perform a dummy read as a work around for
* the startup block issue.
*/
- spi_cs_activate(spi->dev, slave_plat->cs);
+ spi_cs_activate(spi->dev, slave_plat->cs[0]);
txp = 0x9f;
start_transfer(spi, (void *), NULL, 1);
@@ -298,7 +298,7 @@ static int xilinx_spi_mem_exec_op(struct spi_slave *spi,
startup++;
}
- spi_cs_activate(spi->dev, slave_plat->cs);
+ spi_cs_activate(spi->dev, slave_plat->cs[0]);
if (op->cmd.opcode) {
ret = start_transfer(spi, (void *)>cmd.opcode, NULL, 1);
diff --git a/drivers/spi/zynq_qspi.c b/drivers/spi/zynq_qspi.c
index cb52c0f307..069d2a77de 100644
--- a/drivers/spi/zynq_qspi.c
+++ b/drivers/spi/zynq_qspi.c
@@ -586,13 +586,13 @@ static int zynq_qspi_xfer(struct udevice *dev, unsigned
int bitlen,
struct zynq_qspi_priv *priv = dev_get_priv(bus);
struct dm_spi_slave_plat *slave_plat = dev_get_parent_plat(dev);
- priv->cs = slave_plat->cs;
+ priv->cs = slave_plat->cs[0];
priv->tx_buf = dout;
priv->rx_buf = din;
priv->len = bitlen / 8;
- debug("zynq_qspi_xfer: bus:%i cs:%i bitlen:%i len:%i flags:%lx\n",
- dev_seq(bus), slave_plat->cs, bitlen, priv->len, flags);
+ debug("zynq_qspi_xfer: bus:%i cs[0]:%i bitlen:%i len:%i flags:%lx\n",
+ dev_seq(bus), slave_plat->cs[0], bitlen, priv->len, flags);
/*
* Festering sore.
diff --git a/drivers/spi/zynq_spi.c b/drivers/spi/zynq_spi.c
index b3e0858eb9..17bb1015fa 100644
--- a/drivers/spi/zynq_spi.c
+++ b/drivers/spi/zynq_spi.c
[PATCH 3/7] mtd: spi-nor: Add parallel memories support for read_sr and read_fsr
Add support for parallel memories flash configuration in read status
register and read flag status register functions.
Signed-off-by: Ashok Reddy Soma
Signed-off-by: Venkatesh Yadav Abbarapu
---
drivers/mtd/spi/spi-nor-core.c | 50 --
1 file changed, 36 insertions(+), 14 deletions(-)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 061d88b627..e733b180de 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -437,8 +437,9 @@ static ssize_t spi_nor_write_data(struct spi_nor *nor,
loff_t to, size_t len,
}
/*
- * Read the status register, returning its value in the location
- * Return the status register value.
+ * Return the status register value. If the chip is parallel, then the
+ * read will be striped, so we should read 2 bytes to get the sr
+ * register value from both of the parallel chips.
* Returns negative if error occurred.
*/
static int read_sr(struct spi_nor *nor)
@@ -470,18 +471,29 @@ static int read_sr(struct spi_nor *nor)
if (spi_nor_protocol_is_dtr(nor->reg_proto))
op.data.nbytes = 2;
- ret = spi_nor_read_write_reg(nor, , val);
- if (ret < 0) {
- pr_debug("error %d reading SR\n", (int)ret);
- return ret;
+ if (nor->flags & SNOR_F_HAS_PARALLEL) {
+ op.data.nbytes = 2;
+ ret = spi_nor_read_write_reg(nor, , [0]);
+ if (ret < 0) {
+ pr_debug("error %d reading SR\n", (int)ret);
+ return ret;
+ }
+ val[0] |= val[1];
+ } else {
+ ret = spi_nor_read_write_reg(nor, , [0]);
+ if (ret < 0) {
+ pr_debug("error %d reading SR\n", (int)ret);
+ return ret;
+ }
}
- return *val;
+ return val[0];
}
/*
- * Read the flag status register, returning its value in the location
- * Return the status register value.
+ * Return the flag status register value. If the chip is parallel, then
+ * the read will be striped, so we should read 2 bytes to get the fsr
+ * register value from both of the parallel chips.
* Returns negative if error occurred.
*/
static int read_fsr(struct spi_nor *nor)
@@ -513,13 +525,23 @@ static int read_fsr(struct spi_nor *nor)
if (spi_nor_protocol_is_dtr(nor->reg_proto))
op.data.nbytes = 2;
- ret = spi_nor_read_write_reg(nor, , val);
- if (ret < 0) {
- pr_debug("error %d reading FSR\n", ret);
- return ret;
+ if (nor->flags & SNOR_F_HAS_PARALLEL) {
+ op.data.nbytes = 2;
+ ret = spi_nor_read_write_reg(nor, , [0]);
+ if (ret < 0) {
+ pr_debug("error %d reading SR\n", (int)ret);
+ return ret;
+ }
+ val[0] &= val[1];
+ } else {
+ ret = spi_nor_read_write_reg(nor, , [0]);
+ if (ret < 0) {
+ pr_debug("error %d reading FSR\n", ret);
+ return ret;
+ }
}
- return *val;
+ return val[0];
}
/*
--
2.17.1
[PATCH 4/7] mtd: spi-nor: Add parallel and stacked memories support in read_bar and write_bar
Add support for parallel memories and stacked memories configuration
in read_bar and write_bar functions.
Signed-off-by: Ashok Reddy Soma
Signed-off-by: Venkatesh Yadav Abbarapu
---
drivers/mtd/spi/spi-nor-core.c | 55 +-
1 file changed, 47 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index e733b180de..4d15a90c8f 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -884,12 +884,32 @@ static int clean_bar(struct spi_nor *nor)
static int write_bar(struct spi_nor *nor, u32 offset)
{
- u8 cmd, bank_sel;
+ u8 cmd, bank_sel, upage_curr;
int ret;
+ struct mtd_info *mtd = >mtd;
+
+ /* Wait until previous write command is finished */
+ if (spi_nor_wait_till_ready(nor))
+ return 1;
+
+ if (nor->flags & (SNOR_F_HAS_PARALLEL | SNOR_F_HAS_STACKED) &&
+ mtd->size <= SZ_32M)
+ return 0;
+
+ if (mtd->size <= SZ_16M)
+ return 0;
+
+ offset = offset % (u32)mtd->size;
+ bank_sel = offset >> 24;
- bank_sel = offset / SZ_16M;
- if (bank_sel == nor->bank_curr)
- goto bar_end;
+ upage_curr = nor->spi->flags & SPI_XFER_U_PAGE;
+
+ if (!(nor->flags & SNOR_F_HAS_STACKED) && bank_sel == nor->bank_curr)
+ return 0;
+ else if (upage_curr == nor->upage_prev && bank_sel == nor->bank_curr)
+ return 0;
+ else
+ nor->upage_prev = upage_curr;
cmd = nor->bank_write_cmd;
write_enable(nor);
@@ -899,15 +919,19 @@ static int write_bar(struct spi_nor *nor, u32 offset)
return ret;
}
-bar_end:
nor->bank_curr = bank_sel;
- return nor->bank_curr;
+
+ return write_disable(nor);
}
static int read_bar(struct spi_nor *nor, const struct flash_info *info)
{
u8 curr_bank = 0;
int ret;
+ struct mtd_info *mtd = >mtd;
+
+ if (mtd->size <= SZ_16M)
+ return 0;
switch (JEDEC_MFR(info)) {
case SNOR_MFR_SPANSION:
@@ -919,15 +943,30 @@ static int read_bar(struct spi_nor *nor, const struct
flash_info *info)
nor->bank_write_cmd = SPINOR_OP_WREAR;
}
+ if (nor->flags & SNOR_F_HAS_PARALLEL)
+ nor->spi->flags |= SPI_XFER_LOWER;
+
ret = nor->read_reg(nor, nor->bank_read_cmd,
- _bank, 1);
+ _bank, 1);
if (ret) {
debug("SF: fail to read bank addr register\n");
return ret;
}
nor->bank_curr = curr_bank;
- return 0;
+ // Make sure both chips use the same BAR
+ if (nor->flags & SNOR_F_HAS_PARALLEL) {
+ write_enable(nor);
+ ret = nor->write_reg(nor, nor->bank_write_cmd, _bank, 1);
+ if (ret)
+ return ret;
+
+ ret = write_disable(nor);
+ if (ret)
+ return ret;
+ }
+
+ return ret;
}
#endif
--
2.17.1
[PATCH 2/7] mtd: spi-nor: Add parallel and stacked memories support
In parallel mode, the current implementation assumes that a maximum of
two flashes are connected. The QSPI controller splits the data evenly
between both the flashes so, both the flashes that are connected in
parallel mode should be identical.
During each operation SPI-NOR sets 0th bit for CS0 & 1st bit for CS1 in
nor->flags.
In stacked mode the current implementation assumes that a maximum of two
flashes are connected and both the flashes are of same make but can
differ in sizes. So, except the sizes all other flash parameters of both
the flashes are identical
Spi-nor will pass on the appropriate flash select flag to low level
driver, and it will select pass all the data to that particular flash.
Write operation in parallel mode are performed in page size * 2 chunks as
each write operation results in writing both the flashes. For doubling
the address space each operation is performed at addr/2 flash offset,
where addr is the address specified by the user.
Similarly for read and erase operations it will read from both flashes,
so size and offset are divided by 2 and send to flash.
Signed-off-by: Ashok Reddy Soma
Signed-off-by: Venkatesh Yadav Abbarapu
---
drivers/mtd/spi/spi-nor-core.c | 280 +
include/linux/mtd/spi-nor.h| 13 ++
include/spi.h | 12 ++
3 files changed, 277 insertions(+), 28 deletions(-)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 6093277f17..061d88b627 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -638,12 +638,17 @@ static u8 spi_nor_convert_3to4_erase(u8 opcode)
static void spi_nor_set_4byte_opcodes(struct spi_nor *nor,
const struct flash_info *info)
{
+ bool shift = 0;
+
+ if (nor->flags & SNOR_F_HAS_PARALLEL)
+ shift = 1;
+
/* Do some manufacturer fixups first */
switch (JEDEC_MFR(info)) {
case SNOR_MFR_SPANSION:
/* No small sector erase for 4-byte command set */
nor->erase_opcode = SPINOR_OP_SE;
- nor->mtd.erasesize = info->sector_size;
+ nor->mtd.erasesize = info->sector_size << shift;
break;
default:
@@ -964,8 +969,8 @@ static int spi_nor_erase_sector(struct spi_nor *nor, u32
addr)
static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)
{
struct spi_nor *nor = mtd_to_spi_nor(mtd);
+ u32 addr, len, rem, offset;
bool addr_known = false;
- u32 addr, len, rem;
int ret, err;
dev_dbg(nor->dev, "at 0x%llx, len %lld\n", (long long)instr->addr,
@@ -990,6 +995,19 @@ static int spi_nor_erase(struct mtd_info *mtd, struct
erase_info *instr)
ret = -EINTR;
goto erase_err;
}
+
+ offset = addr;
+ if (nor->flags & SNOR_F_HAS_PARALLEL)
+ offset /= 2;
+
+ if (nor->flags & SNOR_F_HAS_STACKED) {
+ if (offset >= (mtd->size / 2)) {
+ offset = offset - (mtd->size / 2);
+ nor->spi->flags |= SPI_XFER_U_PAGE;
+ } else {
+ nor->spi->flags &= ~SPI_XFER_U_PAGE;
+ }
+ }
#ifdef CONFIG_SPI_FLASH_BAR
ret = write_bar(nor, addr);
if (ret < 0)
@@ -1393,6 +1411,9 @@ static const struct flash_info *spi_nor_read_id(struct
spi_nor *nor)
u8 id[SPI_NOR_MAX_ID_LEN];
const struct flash_info *info;
+ if (nor->flags & SNOR_F_HAS_PARALLEL)
+ nor->spi->flags |= SPI_XFER_LOWER;
+
tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, SPI_NOR_MAX_ID_LEN);
if (tmp < 0) {
dev_dbg(nor->dev, "error %d reading JEDEC ID\n", tmp);
@@ -1417,28 +1438,57 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t
from, size_t len,
{
struct spi_nor *nor = mtd_to_spi_nor(mtd);
int ret;
+ u32 offset = from;
+ u32 stack_shift = 0;
+ u32 read_len = 0;
+ u32 rem_bank_len = 0;
+ u8 bank;
+ u8 is_ofst_odd = 0;
dev_dbg(nor->dev, "from 0x%08x, len %zd\n", (u32)from, len);
- while (len) {
- loff_t addr = from;
- size_t read_len = len;
+ if ((nor->flags & SNOR_F_HAS_PARALLEL) && (offset & 1)) {
+ /* We can hit this case when we use file system like ubifs */
+ from = (loff_t)(from - 1);
+ len = (size_t)(len + 1);
+ is_ofst_odd = 1;
+ }
-#ifdef CONFIG_SPI_FLASH_BAR
- u32 remain_len;
+ while (len) {
+ if (nor->addr_width == 3) {
+ if (nor->flags & SNOR_F_HAS_PARALLEL) {
+ bank = (u32)from / (SZ_16M << 0x01);
+
[PATCH 1/7] dm: core: support reading a single indexed u64 value
Add helper function to allow reading a single indexed u64 value from a
device-tree property containing multiple u64 values, that is an array of
u64's.
Signed-off-by: Ashok Reddy Soma
---
drivers/core/of_access.c | 22 ++
drivers/core/ofnode.c| 30 ++
include/dm/of_access.h | 19 +++
include/dm/ofnode.h | 12
4 files changed, 83 insertions(+)
diff --git a/drivers/core/of_access.c b/drivers/core/of_access.c
index 57f10445b1..b5c315ac3a 100644
--- a/drivers/core/of_access.c
+++ b/drivers/core/of_access.c
@@ -570,6 +570,28 @@ int of_read_u32_index(const struct device_node *np, const
char *propname,
return 0;
}
+int of_read_u64_index(const struct device_node *np, const char *propname,
+ int index, u64 *outp)
+{
+ const __be64 *val;
+
+ debug("%s: %s: ", __func__, propname);
+ if (!np)
+ return -EINVAL;
+
+ val = of_find_property_value_of_size(np, propname,
+sizeof(*outp) * (index + 1));
+ if (IS_ERR(val)) {
+ debug("(not found)\n");
+ return PTR_ERR(val);
+ }
+
+ *outp = be64_to_cpup(val + index);
+ debug("%#x (%d)\n", *outp, *outp);
+
+ return 0;
+}
+
int of_read_u64(const struct device_node *np, const char *propname, u64 *outp)
{
const __be64 *val;
diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index 8df16e56af..9a43343ed3 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -344,6 +344,36 @@ int ofnode_read_u32_index(ofnode node, const char
*propname, int index,
return 0;
}
+int ofnode_read_u64_index(ofnode node, const char *propname, int index,
+ u64 *outp)
+{
+ const fdt64_t *cell;
+ int len;
+
+ assert(ofnode_valid(node));
+
+ if (ofnode_is_np(node))
+ return of_read_u64_index(ofnode_to_np(node), propname, index,
+outp);
+
+ cell = fdt_getprop(ofnode_to_fdt(node), ofnode_to_offset(node),
+ propname, );
+ if (!cell) {
+ debug("(not found)\n");
+ return -EINVAL;
+ }
+
+ if (len < (sizeof(int) * (index + 1))) {
+ debug("(not large enough)\n");
+ return -EOVERFLOW;
+ }
+
+ *outp = fdt64_to_cpu(cell[index]);
+ debug("%#llx (%lld)\n", *outp, *outp);
+
+ return 0;
+}
+
u32 ofnode_read_u32_index_default(ofnode node, const char *propname, int index,
u32 def)
{
diff --git a/include/dm/of_access.h b/include/dm/of_access.h
index c556a18f7d..9e027c9293 100644
--- a/include/dm/of_access.h
+++ b/include/dm/of_access.h
@@ -333,6 +333,25 @@ int of_read_u32(const struct device_node *np, const char
*propname, u32 *outp);
int of_read_u32_index(const struct device_node *np, const char *propname,
int index, u32 *outp);
+/**
+ * of_read_u64_index() - Find and read a 64-bit value from a multi-value
+ * property
+ *
+ * Search for a property in a device node and read a 64-bit value from
+ * it.
+ *
+ * @np:device node from which the property value is to be read.
+ * @propname: name of the property to be searched.
+ * @index: index of the u32 in the list of values
+ * @outp: pointer to return value, modified only if return value is 0.
+ *
+ * Return:
+ * 0 on success, -EINVAL if the property does not exist, or -EOVERFLOW if the
+ * property data isn't large enough.
+ */
+int of_read_u64_index(const struct device_node *np, const char *propname,
+ int index, u64 *outp);
+
/**
* of_read_u64() - Find and read a 64-bit integer from a property
*
diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
index 0f38b3e736..0a85db31f3 100644
--- a/include/dm/ofnode.h
+++ b/include/dm/ofnode.h
@@ -434,6 +434,18 @@ int ofnode_read_u32(ofnode node, const char *propname, u32
*outp);
int ofnode_read_u32_index(ofnode node, const char *propname, int index,
u32 *outp);
+/**
+ * ofnode_read_u64_index() - Read a 64-bit integer from a multi-value property
+ *
+ * @node: valid node reference to read property from
+ * @propname: name of the property to read from
+ * @index: index of the integer to return
+ * @outp: place to put value (if found)
+ * Return: 0 if OK, -ve on error
+ */
+int ofnode_read_u64_index(ofnode node, const char *propname, int index,
+ u64 *outp);
+
/**
* ofnode_read_s32() - Read a 32-bit integer from a property
*
--
2.17.1
[PATCH 0/7] spi-nor: Add parallel and stacked memories support
This series adds support for Xilinx qspi parallel and stacked memeories. In parallel mode, the current implementation assumes that a maximum of two flashes are connected. The QSPI controller splits the data evenly between both the flashes so, both the flashes that are connected in parallel mode should be identical. During each operation SPI-NOR sets 0th bit for CS0 & 1st bit for CS1 in nor->flags. In stacked mode the current implementation assumes that a maximum of two flashes are connected and both the flashes are of same make but can differ in sizes. So, except the sizes all other flash parameters of both the flashes are identical Spi-nor will pass on the appropriate flash select flag to low level driver, and it will select pass all the data to that particular flash. Write operation in parallel mode are performed in page size * 2 chunks as each write operation results in writing both the flashes. For doubling the address space each operation is performed at addr/2 flash offset, where addr is the address specified by the user. Similarly for read and erase operations it will read from both flashes, so size and offset are divided by 2 and send to flash. Ashok Reddy Soma (7): dm: core: support reading a single indexed u64 value mtd: spi-nor: Add parallel and stacked memories support mtd: spi-nor: Add parallel memories support for read_sr and read_fsr mtd: spi-nor: Add parallel and stacked memories support in read_bar and write_bar spi: spi-uclass: Read chipselect and restrict capabilities spi: zynqmp_gqspi: Add parallel memories support in GQSPI driver spi: zynq_qspi: Add parallel memories support in QSPI driver drivers/core/of_access.c | 22 ++ drivers/core/ofnode.c | 30 +++ drivers/mtd/spi/spi-nor-core.c | 385 - drivers/spi/spi-uclass.c | 21 +- drivers/spi/xilinx_spi.c | 4 +- drivers/spi/zynq_qspi.c| 145 +++-- drivers/spi/zynq_spi.c | 6 +- drivers/spi/zynqmp_gqspi.c | 146 +++-- include/dm/of_access.h | 19 ++ include/dm/ofnode.h| 12 + include/linux/mtd/spi-nor.h| 13 ++ include/spi.h | 29 ++- 12 files changed, 737 insertions(+), 95 deletions(-) -- 2.17.1
Re: [PATCH 2/5] drivers: security: Add TPM2 implementation of security devices
Hi Sean, On Thu, 17 Aug 2023 at 17:29, Sean Edmond wrote: > > Hi Simon, > > On 2023-08-17 6:41 a.m., Simon Glass wrote: > > Hi Sean, > > > > On Fri, 11 Aug 2023 at 18:28, wrote: > >> From: Stephen Carlson > >> > >> This implementation of the security uclass driver allows existing TPM2 > >> devices declared in the device tree to be referenced for storing the OS > >> anti-rollback counter, using the TPM2 non-volatile storage API. > >> > >> Signed-off-by: Stephen Carlson > >> --- > >> MAINTAINERS | 1 + > >> drivers/security/Makefile | 1 + > >> drivers/security/security-tpm.c | 173 > >> include/tpm-v2.h| 1 + > >> 4 files changed, 176 insertions(+) > >> create mode 100644 drivers/security/security-tpm.c > > This is a bit wonky w.r.t driver model. The TPM itself should > > implement this API, perhaps ina separate file shared with all v2 TPMs. > > You should not be opening the device, etc. in here. > > > > I hope that makes sense...you effectively need to turn the TPM into a > > multi-function device within driver model. Of course TPMs are > > multi-function devices anyway, but here you are making their functions > > available more explicitly with a nicer API. > > > > Then you can call the TPM API to do what you want, but at least you > > know that the TPM has been probed before you start. > > > > Regards, > > Simon > > > Let's step back for a moment to understand our intention with this feature. > > We want secure storage for the anti-rollback counter. The intention is > that this storage is provided by whatever "secure driver" (let's start > calling it the "rollback driver"). On our platform, we're using a > different "rollback driver" which accesses a non-TPM based secure > storage (which we can't upstream because it's proprietary). For the > purpose of making this feature publicly available, we've added the > TPM-backed "rollback driver" (this patch). I'll make this intention > more clear in the documentation, which should lead to less confusion? > > At the end of the day, all we require is dm_security_arbvn_get() and > dm_security_arbvn_set(), to get/set from the secure storage (we'll > rename these to something less ugly, because yes arbvn is gross). We > don't want to lock this feature to the TPM, because it doesn't enable > us/others to choose a different secure storage mechanism. It doesn't need to be locked to the TPM. But since you have a uclass you can have different drivers implementing the same UCLASS_ROLLBACK: - a 'stand-alone' one that does strage and secret things - a TPM-based one that makes TPM calls > > W.r.t opening/initializing the TPM. Someone has to open it? In our > case, it's being opened earlier with our measured boot, so "-EBUSY" in > returned on tpm_open() (we return and everyone is happy). My > understanding is that this is the currently available way for multiple > drivers to access the TPM. Ilias has recommended we use > tpm_auto_start(), which is an enhancement I'm planning to make. This > should clean thing up? If this doesn't meet your expectations, can you > describe in more detail how we should turn the TPM into a > "multi-function device"? The TPM will be probed automatically by probing its child device. Not opened, though...that would have to happen elsewhere. But it doesn't mean you need to turn the TPM into a multi-function device. It's just that, in most cases, others would use a TPM to provide the rollback counters. For testing purposes, you should probably create a device which is a child of the sandbox TPM2 and run the tests with that. Regards, Simon
Re: Strange gitlab idea
Hi Tom, On Thu, 17 Aug 2023 at 11:07, Tom Rini wrote: > > On Thu, Aug 17, 2023 at 10:58:15AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 17 Aug 2023 at 09:10, Tom Rini wrote: > > > > > > On Thu, Aug 17, 2023 at 07:41:50AM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Tue, 15 Aug 2023 at 08:56, Tom Rini wrote: > > > > > > > > > > On Tue, Aug 15, 2023 at 08:44:20AM -0600, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Sun, 13 Aug 2023 at 09:52, Tom Rini wrote: > > > > > > > > > > > > > > On Sat, Aug 12, 2023 at 09:14:45PM -0600, Simon Glass wrote: > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > I notice that the runners are not utilised much by the QEMU jobs, > > > > > > > > since we only run one at a time. > > > > > > > > > > > > > > > > I wonder if we could improve this, perhaps by using a different tag > > > > > > > > for the QEMU ones and then having a machine that only runs those (and > > > > > > > > runs 40 in parallel)? > > > > > > > > > > > > > > > > In general our use of the runners seems a bit primitive, since the > > > > > > > > main use of parallelism is in the world builds. > > > > > > > > > > > > > > I'm honestly not sure. I think there's a few tweaks that we should do, > > > > > > > like putting the opensbi and coreboot files in to the Dockerfile logic > > > > > > > instead. And maybe seeing if just like we can have a docker registry > > > > > > > cache, if we can setup local pypi cache too? I'm not otherwise sure > > > > > > > what's taking 23 seconds or so of > > > > > > > https://source.denx.de/u-boot/u-boot/-/jobs/673565#L34 since the build > > > > > > > and run parts aren't much. > > > > > > > > > > > > > > My first big worry about running 2 or 3 qemu jobs at the same time on a > > > > > > > host is that any wins get from a shorter queue will be lost to buildman > > > > > > > doing "make -j$(nproc)" 2 or 3 times at once and so we build slower. > > > > > > > > > > > > Yes, perhaps. > > > > > > > > > > > > > > > > > > > > My second big worry is that getting the right tags on runners will be a > > > > > > > little tricky. > > > > > > > > > > > > Yes, and error-prone. Also it makes it harder to deal with broken machines. > > > > > > > > > > > > > > > > > > > > My third big worry (but this is something you can test easy enough at > > > > > > > least) is that running the big sandbox tests, 2 or 3 times at once on > > > > > > > the same host will get much slower. I think, but profiling would be > > > > > > > helpful, that those get slow due to I/O and not CPU. > > > > > > > > > > > > I suspect it would be fast enough. > > > > > > > > > > > > But actually the other problem is that I am not sure whether the jobs > > > > > > would have their own filesystem? > > > > > > > > > > Yes, they should be properly sandboxed. If you want to test some of > > > > > these ideas, I think the best path is to just un-register temproarily > > > > > (comment out the token in config.toml) some of your runners and then > > > > > register them with just the DM tree and experiment. > > > > > > > > OK thanks for the idea. I tried this on tui > > > > > > > > I used a 'concurrent = 10' and it got up to a load of 70 or so every > > > > now and then, but mostly it was much less. > > > > > > > > The whole run (of just the test.py stage) took 8 minutes, with > > > > 'sandbox with clang test' taking the longest. > > > > > > > > I'm not too sure what that tells us... > > > > > > Well, looking at > > > https://source.denx.de/u-boot/u-boot/-/pipelines/17391/builds the whole > > > run took 56 minutes, of which 46 minutes was on 32bit ARM world build. > > > And the longest test.py stage was sandbox without LTO at just under 8 > > > minutes. So I think trying to get more concurrency in this stage is > > > likely to be a wash in terms of overall CI run time. > > > > There is quite a lot of variability. Two of the machines take about > > 15mins to 32-bit ARM and another two take under 20mins, e.g.: > > > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/jobs/676055 > > > > Perhaps we should reserve the big jobs for the fastest machines? But > > then what if they all go offline at once? > > Barring some significant donation of resources, we probably are just > going to have to live with enough variation in build time "about an > hour" is what we'll end up with. I see that overall the pipeline the > above example is from took 50 minutes. Yes I think so. Regards, Simon
Re: [PATCH 2/5] scripts/Makefile.lib: Embed capsule public key in platform's dtb
Hi Tom, On Thu, 17 Aug 2023 at 09:10, Tom Rini wrote: > > On Thu, Aug 17, 2023 at 07:41:33AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Wed, 16 Aug 2023 at 15:26, Tom Rini wrote: > > > > > > On Wed, Aug 16, 2023 at 09:58:42AM +0530, Sughosh Ganu wrote: > > > > hi Simon, > > > > > > > > On Wed, 16 Aug 2023 at 00:09, Simon Glass wrote: > > > > > > > > > > Hi Sughosh, > > > > > > > > > > On Tue, 15 Aug 2023 at 10:26, Sughosh Ganu < sughosh.g...@linaro.org> wrote: > > > > > > > > > > > > The EFI capsule authentication logic in u-boot expects the public key > > > > > > in the form of an EFI Signature List(ESL) to be provided as part of > > > > > > the platform's dtb. Currently, the embedding of the ESL file into the > > > > > > dtb needs to be done manually. > > > > > > > > > > > > Add a target for generating a dtsi file which contains the signature > > > > > > node with the ESL file included as a property under the signature > > > > > > node. Include the dtsi file in the dtb. This brings the embedding of > > > > > > the ESL in the dtb into the U-Boot build flow. > > > > > > > > > > > > The path to the ESL file is specified through the > > > > > > CONFIG_EFI_CAPSULE_ESL_FILE symbol. > > > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > > --- > > > > > > Changes since RFC series: > > > > > > * Remove the default value of the config symbol. > > > > > > * s/include_files/dtsi_include_list > > > > > > * Add all the dtsi files being included as dependency for the dtb > > > > > > target. > > > > > > > > > > > > lib/efi_loader/Kconfig | 8 > > > > > > lib/efi_loader/capsule_esl.dtsi.in | 11 +++ > > > > > > scripts/Makefile.lib | 18 +- > > > > > > 3 files changed, 36 insertions(+), 1 deletion(-) > > > > > > create mode 100644 lib/efi_loader/capsule_esl.dtsi.in > > > > > > > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > > > > index 9989e3f384..d20aaab6db 100644 > > > > > > --- a/lib/efi_loader/Kconfig > > > > > > +++ b/lib/efi_loader/Kconfig > > > > > > @@ -272,6 +272,14 @@ config EFI_CAPSULE_MAX > > > > > > Select the max capsule index value used for capsule report > > > > > > variables. This value is used to create CapsuleMax variable. > > > > > > > > > > > > +config EFI_CAPSULE_ESL_FILE > > > > > > + string "Path to the EFI Signature List File" > > > > > > > > > > Do we need this, or could we name it as we do with the .env file? It > > > > > seems confusing to have to set this for each board - it might be > > > > > better to have it in a defined location. > > > > > > > > The reason I put this is because I thought this gave the user the > > > > flexibility to provide the location and name of the ESL. But I suppose > > > > that the board directory would be a good location to expect this file. > > > > Then this file can have a name like capsule_pub_key,esl. Tom, what are > > > > your thoughts on this? > > > > > > I feel like an automatic name we can guess isn't likely how this will be > > > used in the real world, so we should leave this as configurable. > > > > Are we expecting these files to end up in the source tree? Where would they go? > > Yes, they should be > board/vendor/common/whatever-vendor-uses-internally.esl or so. As I > think I mentioned on IRC, in theory someone like Asus should be using > the same file here for their rockchip-based tinker board and their x8664 > based motherboards too. And it's a public key, not a private key. But > we still need to ask here because a vendor may care more about > "security" and so have the key /over/somewhere/else more than > reproducible builds. OK. Regards, Simon
Re: [PATCHv6 07/14] net/lwip: implement ping cmd
Hi Maxim,
On Wed, 16 Aug 2023 at 14:15, Maxim Uvarov wrote:
>
>
>
> On Wed, 16 Aug 2023 at 20:39, Simon Glass wrote:
>>
>> Hi Maxim,
>>
>> On Wed, 16 Aug 2023 at 03:09, Maxim Uvarov
wrote:
>> >
>> > On Wed, 16 Aug 2023 at 14:42, Ilias Apalodimas <
ilias.apalodi...@linaro.org>
>> > wrote:
>> >
>> > > On Mon, Aug 14, 2023 at 07:32:46PM +0600, Maxim Uvarov wrote:
>> > > > * can return immediately if previous request was cached or it
might
>> > > require
>> > > > @@ -38,3 +39,28 @@ int ulwip_dhcp(void);
>> > > > * !0 if error
>> > > > */
>> > > > int ulwip_wget(ulong addr, char *url);
>> > > > +
>> > > > +/**
>> > > > + * ulwip_tftp() - load file with tftp
>> > > > + *
>> > > > + * Load file with tftp to specific address
>> > > > + *
>> > > > + * @param addr - address to store downloaded file
>> > > > + * @param filename - file name on remote tftp server to download
>> > >
>> > > Please fix function comments properly
>> > >
>> > > > + *
>> > > > + *
>> > > > + * @return 0 if success, !0 if error
>> > > > + */
>> > > > +int ulwip_tftp(ulong addr, const char *filename);
>> > > > +
>> > > > +/*
>> > > > +* This function creates the ping for address provided in
parameters.
>> > > > +* After this function you need to invoke the polling
>> > > > +* loop to process network communication.
>> > > > +*
>> > > > +*
>> > > > +* @ping_addr start address to download result
>> > > > +* Return: 0 for success
>> > > > +* !0 if error
>> > > > +*/
>> > > > +int ulwip_ping(char *ping_addr);
>> > > > diff --git a/net/lwip/Makefile b/net/lwip/Makefile
>> > > > index 4c6df94807..8b3e843426 100644
>> > > > --- a/net/lwip/Makefile
>> > > > +++ b/net/lwip/Makefile
>> > > > @@ -67,5 +67,6 @@ obj-$(CONFIG_NET) += port/sys-arch.o
>> > > >
>> > > > obj-$(CONFIG_CMD_DHCP) += apps/dhcp/lwip-dhcp.o
>> > > > obj-$(CONFIG_CMD_DNS) += apps/dns/lwip-dns.o
>> > > > +obj-$(CONFIG_CMD_PING) += apps/ping/
>> > > > obj-$(CONFIG_CMD_TFTPBOOT) += apps/tftp/
>> > > > obj-$(CONFIG_CMD_WGET) += apps/http/
>> > > > diff --git a/net/lwip/apps/ping/Makefile
b/net/lwip/apps/ping/Makefile
>> > > > new file mode 100644
>> > > > index 00..dc63feb7b5
>> > > > --- /dev/null
>> > > > +++ b/net/lwip/apps/ping/Makefile
>> > > > @@ -0,0 +1,11 @@
>> > > > +ccflags-y += -I$(srctree)/net/lwip/port/include
>> > > > +ccflags-y += -I$(srctree)/net/lwip/lwip-external/src/include
>> > > -I$(srctree)/net/lwip
>> > > > +ccflags-y += -I$(obj)
>> > > > +
>> > > > +.PHONY: $(obj)/ping.c
>> > > > +$(obj)/ping.o: $(obj)/ping.c
>> > > > +$(obj)/ping.c:
>> > > > + cp $(srctree)/net/lwip/lwip-external/contrib/apps/ping/ping.c
>> > > $(obj)/ping.c
>> > > > +
>> > > > +obj-$(CONFIG_CMD_PING) += ping.o
>> > > > +obj-$(CONFIG_CMD_PING) += lwip_ping.o
>> > > > diff --git a/net/lwip/apps/ping/lwip_ping.c
>> > > b/net/lwip/apps/ping/lwip_ping.c
>> > > > new file mode 100644
>> > > > index 00..611fcaf591
>> > > > --- /dev/null
>> > > > +++ b/net/lwip/apps/ping/lwip_ping.c
>> > > > @@ -0,0 +1,37 @@
>> > > > +// SPDX-License-Identifier: GPL-2.0
>> > > > +
>> > > > +/*
>> > > > + * (C) Copyright 2023 Linaro Ltd.
>> > > > + */
>> > > > +
>> > > > +#include "lwip/opt.h"
>> > > > +#include "lwip/ip_addr.h"
>> > > > +#include "ping.h"
>> > > > +#include "lwip_ping.h"
>> > > > +
>> > > > +static ip_addr_t ip_target;
>> > > > +
>> > > > +static int ulwip_ping_tmo(void)
>> > > > +{
>> > > > +
>> > > > + log_err("ping failed; host %s is not alive\n",
>> > > ipaddr_ntoa(_target));
>> > > > + return 1;
>> > > > +}
>> > > > +
>> > > > +int ulwip_ping(char *ping_addr)
>> > > > +{
>> > > > + int err;
>> > > > +
>> > > > + err = ipaddr_aton(ping_addr, _target);
>> > > > + if (!err) {
>> > > > + log_err("wrong ping addr string \"%s\" \n",
ping_addr);
>> > >
>> > > Invalid ip address is enough
>> > >
>> > > > + return -1;
>> > > > + }
>> > > > +
>> > > > + ulwip_set_tmo(ulwip_ping_tmo);
>> > > > +
>> > > > + ping_init(_target);
>> > > > + ping_send_now();
>> > > > +
>> > > > + return 0;
>> > > > +}
>> > > > diff --git a/net/lwip/apps/ping/lwip_ping.h
>> > > b/net/lwip/apps/ping/lwip_ping.h
>> > > > new file mode 100644
>> > > > index 00..0374f07d9e
>> > > > --- /dev/null
>> > > > +++ b/net/lwip/apps/ping/lwip_ping.h
>> > > > @@ -0,0 +1,15 @@
>> > > > +/* SPDX-License-Identifier: GPL-2.0+ */
>> > > > +
>> > > > +/*
>> > > > + * (C) Copyright 2023 Linaro Ltd.
>> > > > + */
>> > > > +
>> > > > +#ifndef LWIP_PING_H
>> > > > +#define LWIP_PING_H
>> > > > +
>> > > > +#include
>> > > > +
>> > > > +void ping_raw_init(void);
>> > > > +void ping_send_now(void);
>> > > > +
>> > > > +#endif /* LWIP_PING_H */
>> > > > diff --git a/net/lwip/apps/ping/ping.h b/net/lwip/apps/ping/ping.h
>> > > > new file mode 100644
>> > > > index 00..006a18c658
>> > > > --- /dev/null
>> > > > +++ b/net/lwip/apps/ping/ping.h
>> > > > @@ -0,0 +1,19 @@
>> > > > +/* SPDX-License-Identifier: GPL-2.0 */
>> > > > +
>> >
Re: [PATCH] tools: image-host: print error messages to stderr
On Thu, 17 Aug 2023 at 09:36, Oleksandr Suvorov < oleksandr.suvo...@foundries.io> wrote: > > The make by default cuts off the stdout output from external tools, > so all error messages from the image-host are not shown in a make > output. Besides that, it is a common approach to use stderr stream > for error messages. > Use stderr for all error messages in image-host. > > Signed-off-by: Oleksandr Suvorov > --- > > tools/image-host.c | 202 - > 1 file changed, 107 insertions(+), 95 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH 1/3] fdt: common API to populate kaslr seed
Hi Sean, On Thu, 17 Aug 2023 at 10:03, Sean Edmond wrote: > > > On 2023-08-15 10:46 a.m., Sean Edmond wrote: > > > On 2023-08-15 7:44 a.m., Simon Glass wrote: > > Hi Sean, > > On Mon, 14 Aug 2023 at 13:12, Sean Edmond > wrote: > > > On 2023-08-12 6:09 a.m., Simon Glass wrote: > > Hi Sean, > > On Fri, 11 Aug 2023 at 11:14, Sean Edmond > wrote: > > On 2023-08-09 6:49 p.m., Simon Glass wrote: > > Hi Sean, > > On Wed, 9 Aug 2023 at 16:35, Sean Edmond > > wrote: > > On 2023-08-08 7:03 p.m., Simon Glass wrote: > > Hi, > > On Fri, 4 Aug 2023 at 17:34, wrote: > > From: Dhananjay Phadke > > fdt_fixup_kaslr_seed() will update given FDT with random seed value. > Source for random seed can be TPM or RNG driver in u-boot or sec > firmware (ARM). > > Signed-off-by: Dhananjay Phadke > --- > arch/arm/cpu/armv8/sec_firmware.c | 32 > > +++ > > common/fdt_support.c | 31 > > ++ > > include/fdt_support.h | 3 +++ > 3 files changed, 41 insertions(+), 25 deletions(-) > > We need to find a way to use the ofnode API here. > > diff --git a/arch/arm/cpu/armv8/sec_firmware.c > > b/arch/arm/cpu/armv8/sec_firmware.c > > index c0e8726346..84ba49924e 100644 > --- a/arch/arm/cpu/armv8/sec_firmware.c > +++ b/arch/arm/cpu/armv8/sec_firmware.c > @@ -411,46 +411,28 @@ int sec_firmware_init(const void > > *sec_firmware_img, > > /* > * fdt_fix_kaslr - Add kalsr-seed node in Device tree > * @fdt: Device tree > - * @eret: 0 in case of error, 1 for success > + * @eret: 0 for success > */ > int fdt_fixup_kaslr(void *fdt) > > You could pass an oftree to this function, e.g. obtained with: > > oftree_from_fdt(fdt) > > The common API I added is fdt_fixup_kaslr_seed(), which was added to > "common/fdt_support.c". > > There are 3 callers: > sec_firmware_init()->fdt_fixup_kaslr_seed() > do_kaslr_seed()->fdt_fixup_kaslr_seed() > image_setup_libfdt()->fdt_tpm_kaslr_seed->fdt_fixup_kaslr_seed() > > I think the ask is to create a common API that uses the ofnode API. > > So, > > instead of fdt_fixup_kaslr_seed() I can create > ofnode_fixup_kaslr_seed()? Where should it live? > > If you like you could add common/ofnode_support.c ? > > But it is OK to have it in the same file, I think. > > Are you also wanting > the callers (eg. fdt_tpm_kaslr_seed, fdt_fixup_kaslr) to take oftree as > input too? > > So far as you can go, yes. Also you may want to pass an ofnode (the > root node) so that things can deal with adding their stuff to any > node. > > Regards, > Simon > > I re-worked the API to use the ofnode API and tested it on our board. I > was required to explicitly enable CONFIG_OFNODE_MULTI_TREE in order for > it to work. > > I have concerns this will create a breaking change for users of the > kaslr fdt touch up. In our case, if CONFIG_OFNODE_MULTI_TREE isn't set, > the control FDT gets touched up, not the kernel FDT as required. > Everything runs to completion, but "/proc/device-tree/chosen/kaslr-seed" > isn't present after boot. > > Am I missing something? Perhaps there's a way to modify the default > value for CONFIG_OFNODE_MULTI_TREE to ensure this works out-of-the-box? > > Yes, perhaps we should enable this when fixups are used? Is there a way to > tell? > > I don't think there's a way to tell unfortunately. Fixups are always > called if OF_LIBFDT is enabled, and if an FDT is found during bootm. > > I'm having trouble understanding the intention of the current default > for OFNODE_MULTI_TREE: > default y if EVENT && !DM_DEV_READ_INLINE && !DM_INLINE_OFNODE > Could we simplify to this? > default y if !OF_LIVE > > I don't think it will build if inlining is used, but I can't remember... > > I wasn't able to break this by turning off DM_DEV_READ_INLINE, and enabling OFNODE_MULTI_TREE/SPL_DM_INLINE_OFNODE/TPL_DM_INLINE_OFNODE. Perhaps things have changes since this was created. > > The EVENT thing is because there is an of-fixup event, which was the > original thing using ofnode fixups. > > I wonder what sort of size increment this will create with !OF_LIVE ? > > > With default (OFNODE_MULTI_TREE is not set): > > textdatabssdechex filename > > 9380135536846752 1040133fdf05 u-boot/u-boot/u-boot > > > With !OF_LIVE (OFNODE_MULTI_TREE is set with OFNODE_MULTI_TREE_MAX=4): > > seanedmond@ovlvm106:~/code/QEMU/qemu_uboot$ sizeu-boot/u-boot/u-boot > > textdatabssdechex filename > > 9390165536846752 1041136fe2f0 u-boot/u-boot/u-boot > > > Sorry about the formatting... let's try that again. > > With default (OFNODE_MULTI_TREE is not set): > >text: 938013 >data: 55368 >bss: 46752 >dec: 1040133 >hex: fdf05 > > With !OF_LIVE (OFNODE_MULTI_TREE is set with OFNODE_MULTI_TREE_MAX=4): > >text: 939016 >data: 55368 >bss: 46752 >dec: 1041136 >hex: fe2f0 > > > > Also, we should make it return an error when attempting to use a tree > without
Re: [PATCH v2 11/20] efi: x86: Correct the condition for installing ACPI tables
Am 18. August 2023 02:26:50 MESZ schrieb Simon Glass :
>It is not always the case that U-Boot builds the ACPI tables itself. For
>example, when booting from coreboot, the ACPI tables are built by
>coreboot.
>
>Correct the Makefile condition so that U-Boot can pass on tables built
>by a previous firmware stage.
>
>Tidy up the installation-condition code while we are here.
>
>Signed-off-by: Simon Glass
>---
>
>Changes in v2:
>- Add new patch
>
> lib/efi_loader/Makefile| 2 +-
> lib/efi_loader/efi_setup.c | 10 +-
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
>diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
>index 1a8c8d7cab5c..0eb748ff1a59 100644
>--- a/lib/efi_loader/Makefile
>+++ b/lib/efi_loader/Makefile
>@@ -78,7 +78,7 @@ obj-$(CONFIG_EFI_ESRT) += efi_esrt.o
> obj-$(CONFIG_VIDEO) += efi_gop.o
> obj-$(CONFIG_BLK) += efi_disk.o
> obj-$(CONFIG_NETDEVICES) += efi_net.o
>-obj-$(CONFIG_GENERATE_ACPI_TABLE) += efi_acpi.o
>+obj-$(CONFIG_ACPI) += efi_acpi.o
> obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += efi_smbios.o
> obj-$(CONFIG_EFI_RNG_PROTOCOL) += efi_rng.o
> obj-$(CONFIG_EFI_TCG2_PROTOCOL) += efi_tcg2.o
>diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
>index 58d4e1340233..ad719afd6328 100644
>--- a/lib/efi_loader/efi_setup.c
>+++ b/lib/efi_loader/efi_setup.c
>@@ -321,11 +321,11 @@ efi_status_t efi_init_obj_list(void)
> if (ret != EFI_SUCCESS)
> goto out;
> #endif
>-#ifdef CONFIG_GENERATE_ACPI_TABLE
>- ret = efi_acpi_register();
>- if (ret != EFI_SUCCESS)
>- goto out;
>-#endif
>+ if (IS_ENABLED(CONFIG_ACPI)) {
>+ ret = efi_acpi_register();
>+ if (ret != EFI_SUCCESS)
>+ goto out;
>+ }
> #ifdef CONFIG_GENERATE_SMBIOS_TABLE
Shouldn't this become CONFIG_SMBIOS?
It would help my review work if you would stop suppressing half of your patch
series when sending mails.
Best regards
Heinrich
> ret = efi_smbios_register();
> if (ret != EFI_SUCCESS)
Re: [PATCH v2 12/20] x86: smbios: Add a Kconfig indicating SMBIOS-table presence
Am 18. August 2023 02:26:51 MESZ schrieb Simon Glass : >When booted from coreboot, U-Boot does not build the SMBIOS tables, but >it should still pass them on to the OS. Add a new option which indicates >whether SMBIOS tables are present, however they were built. > >Flip the ordering so that the dependency is listed first, which is less >confusing. > >Signed-off-by: Simon Glass >--- > >Changes in v2: >- Add new patch > > lib/Kconfig | 12 +++- > 1 file changed, 11 insertions(+), 1 deletion(-) > >diff --git a/lib/Kconfig b/lib/Kconfig >index a9dca5f52b5a..b7bbf3f81c56 100644 >--- a/lib/Kconfig >+++ b/lib/Kconfig >@@ -984,8 +984,9 @@ config BLOBLIST_TABLES > > config GENERATE_SMBIOS_TABLE > bool "Generate an SMBIOS (System Management BIOS) table" >- default y > depends on X86 || EFI_LOADER >+ default y >+ imply SMBIOS Is there any use case for GENERATE_SMBIOD_TABLE=y and SMBIOS=n? I would have expected 'depends on SMBIOS' here. > help > The System Management BIOS (SMBIOS) specification addresses how > motherboard and system vendors present management information about >@@ -1054,6 +1055,15 @@ config SPL_OID_REGISTRY > unambiguous persistent name > (https://en.wikipedia.org/wiki/Object_identifier). > Enable fast lookup object identifier registry in the SPL. > >+config SMBIOS >+ bool "SMBIOS support" >+ depends on X86 We need SMBIOS tables on all EFI architectures. >+ default y >+ help >+Indicates that this platform can create System Management BIOS This is very confusing: create and generate are just synonyms. Given this description I would not know what is the difference between the symbols. Best regards Heinrich >+(SMBIOS) tables. These provide various pieces of information about >+the board, such as the manufacturer and the model name. >+ > config SMBIOS_PARSER > bool "SMBIOS parser" > help
Re: [PATCH v2 14/20] efi: x86: Use the installed SMBIOS tables
Am 18. August 2023 02:26:53 MESZ schrieb Simon Glass :
>U-Boot sets up the SMBIOS tables during startup. Rather than creating a
>new set, install the existing ones. Rely on the ACPI table's memory-map
>record to cover the tables.
>
>Tidy up the installation-condition code while we are here.
>
>Signed-off-by: Simon Glass
>---
>
>Changes in v2:
>- Add new patch
>
> lib/efi_loader/efi_setup.c | 10 +-
> lib/efi_loader/efi_smbios.c | 37 +++--
> 2 files changed, 12 insertions(+), 35 deletions(-)
>
>diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
>index ad719afd6328..e6de685e8795 100644
>--- a/lib/efi_loader/efi_setup.c
>+++ b/lib/efi_loader/efi_setup.c
>@@ -326,11 +326,11 @@ efi_status_t efi_init_obj_list(void)
> if (ret != EFI_SUCCESS)
> goto out;
> }
>-#ifdef CONFIG_GENERATE_SMBIOS_TABLE
>- ret = efi_smbios_register();
>- if (ret != EFI_SUCCESS)
>- goto out;
>-#endif
>+ if (IS_ENABLED(CONFIG_SMBIOS)) {
>+ ret = efi_smbios_register();
>+ if (ret != EFI_SUCCESS)
>+ goto out;
>+ }
> ret = efi_watchdog_register();
> if (ret != EFI_SUCCESS)
> goto out;
>diff --git a/lib/efi_loader/efi_smbios.c b/lib/efi_loader/efi_smbios.c
>index 306c0bc54f90..0e6454a8fe0b 100644
>--- a/lib/efi_loader/efi_smbios.c
>+++ b/lib/efi_loader/efi_smbios.c
>@@ -20,36 +20,13 @@
> */
> efi_status_t efi_smbios_register(void)
> {
>- /* Map within the low 32 bits, to allow for 32bit SMBIOS tables */
>- u64 dmi_addr = U32_MAX;
>- efi_status_t ret;
>- void *dmi;
>+ ulong addr;
>
>- /* Reserve 4kiB page for SMBIOS */
>- ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
>- EFI_RUNTIME_SERVICES_DATA, 1, _addr);
>+ /* space for all tables is marked in efi_acpi_register() */
>+ addr = gd->arch.smbios_start;
>+ printf("EFI using SMBIOS tables at %lx\n", addr);
This is should be log_debug() as typically only developers will ever need this
address.
Best regards
Heinrich
>
>- if (ret != EFI_SUCCESS) {
>- /* Could not find space in lowmem, use highmem instead */
>- ret = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES,
>- EFI_RUNTIME_SERVICES_DATA, 1,
>- _addr);
>-
>- if (ret != EFI_SUCCESS)
>- return ret;
>- }
>-
>- /*
>- * Generate SMBIOS tables - we know that efi_allocate_pages() returns
>- * a 4k-aligned address, so it is safe to assume that
>- * write_smbios_table() will write the table at that address.
>- */
>- assert(!(dmi_addr & 0xf));
>- dmi = (void *)(uintptr_t)dmi_addr;
>- if (write_smbios_table(map_to_sysmem(dmi)))
>- /* Install SMBIOS information as configuration table */
>- return efi_install_configuration_table(_guid, dmi);
>- efi_free_pages(dmi_addr, 1);
>- log_err("Cannot create SMBIOS table\n");
>- return EFI_SUCCESS;
>+ /* Install SMBIOS information as configuration table */
>+ return efi_install_configuration_table(_guid,
>+ map_sysmem(addr, 0));
> }
Re: [PATCH] rockchip: rk3566-anbernic-rgxx3: Rename defconfig to include SoC name
On 2023/8/18 05:52, Jonas Karlman wrote:
Rename defconfig to include SoC name, use similar pattern as other
RK356x boards: -.dts -> -_defconfig
Suggested-by: Kever Yang
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
Thanks,
- Kever
---
board/anbernic/rgxx3_rk3566/MAINTAINERS | 2 +-
...anbernic-rgxx3_defconfig => anbernic-rgxx3-rk3566_defconfig} | 0
doc/board/rockchip/rockchip.rst | 2 +-
3 files changed, 2 insertions(+), 2 deletions(-)
rename configs/{anbernic-rgxx3_defconfig => anbernic-rgxx3-rk3566_defconfig}
(100%)
diff --git a/board/anbernic/rgxx3_rk3566/MAINTAINERS
b/board/anbernic/rgxx3_rk3566/MAINTAINERS
index 6be16a47e8eb..7970e5a4aad7 100644
--- a/board/anbernic/rgxx3_rk3566/MAINTAINERS
+++ b/board/anbernic/rgxx3_rk3566/MAINTAINERS
@@ -3,7 +3,7 @@ M: Chris Morgan
S:Maintained
F:board/anbernic/rgxx3_rk3566
F:include/configs/anbernic-rgxx3-rk3566.h
-F: configs/anbernic-rgxx3_defconfig
+F: configs/anbernic-rgxx3-rk3566_defconfig
F:arch/arm/dts/rk3566-anbernic-rgxx3.dts
F:arch/arm/dts/rk3566-anbernic-rgxx3.dtsi
F:arch/arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi
diff --git a/configs/anbernic-rgxx3_defconfig
b/configs/anbernic-rgxx3-rk3566_defconfig
similarity index 100%
rename from configs/anbernic-rgxx3_defconfig
rename to configs/anbernic-rgxx3-rk3566_defconfig
diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst
index 4668e598515e..de9fe8e642b1 100644
--- a/doc/board/rockchip/rockchip.rst
+++ b/doc/board/rockchip/rockchip.rst
@@ -91,7 +91,7 @@ List of mainline supported Rockchip boards:
- Theobroma Systems RK3399-Q7 SoM - Puma (puma_rk3399)
* rk3566
- - Anbernic RGxx3 (anbernic-rgxx3)
+ - Anbernic RGxx3 (anbernic-rgxx3-rk3566)
- Pine64 Quartz64-A Board (quartz64-a-rk3566)
- Pine64 Quartz64-B Board (quartz64-b-rk3566)
- Pine64 SOQuartz on Blade (soquartz-blade-rk3566)
[PATCH v2 19/20] x86: doc: Split out manual booting into its own file
Move this out of the main file since for simple users it is easier to rely on standard boot. Signed-off-by: Simon Glass --- Changes in v2: - Add new patch doc/arch/x86/index.rst | 1 + doc/arch/x86/manual_boot.rst | 276 +++ doc/arch/x86/x86.rst | 272 +- 3 files changed, 280 insertions(+), 269 deletions(-) create mode 100644 doc/arch/x86/manual_boot.rst diff --git a/doc/arch/x86/index.rst b/doc/arch/x86/index.rst index 3dc19d603d4c..69db0a5d6489 100644 --- a/doc/arch/x86/index.rst +++ b/doc/arch/x86/index.rst @@ -9,3 +9,4 @@ x86 :maxdepth: 2 x86 + manual_boot diff --git a/doc/arch/x86/manual_boot.rst b/doc/arch/x86/manual_boot.rst new file mode 100644 index ..ec069f2c3972 --- /dev/null +++ b/doc/arch/x86/manual_boot.rst @@ -0,0 +1,276 @@ +Booting Ubuntu Manually +--- + +This shows a manual approach to booting Ubuntu without standard boot or the EFI +interface. + +As an example of how to set up your boot flow with U-Boot, here are +instructions for starting Ubuntu from U-Boot. These instructions have been +tested on Minnowboard MAX with a SATA drive but are equally applicable on +other platforms and other media. There are really only four steps and it's a +very simple script, but a more detailed explanation is provided here for +completeness. + +Note: It is possible to set up U-Boot to boot automatically using syslinux. +It could also use the grub.cfg file (/efi/ubuntu/grub.cfg) to obtain the +GUID. If you figure these out, please post patches to this README. + +Firstly, you will need Ubuntu installed on an available disk. It should be +possible to make U-Boot start a USB start-up disk but for now let's assume +that you used another boot loader to install Ubuntu. + +Use the U-Boot command line to find the UUID of the partition you want to +boot. For example our disk is SCSI device 0:: + + => part list scsi 0 + + Partition Map for SCSI device 0 -- Partition Type: EFI + + Part Start LBA End LBA Name +Attributes +Type GUID +Partition GUID + 10x0800 0x001007ff "" +attrs: 0x +type: c12a7328-f81f-11d2-ba4b-00a0c93ec93b +guid: 9d02e8e4-4d59-408f-a9b0-fd497bc9291c + 20x00100800 0x037d8fff "" +attrs: 0x +type: 0fc63daf-8483-4772-8e79-3d69d8477de4 +guid: 965c59ee-1822-4326-90d2-b02446050059 + 30x037d9000 0x03ba27ff "" +attrs: 0x +type: 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f +guid: 2c4282bd-1e82-4bcf-a5ff-51dedbf39f17 + => + +This shows that your SCSI disk has three partitions. The really long hex +strings are called Globally Unique Identifiers (GUIDs). You can look up the +'type' ones `here`_. On this disk the first partition is for EFI and is in +VFAT format (DOS/Windows):: + + => fatls scsi 0:1 + efi/ + + 0 file(s), 1 dir(s) + + +Partition 2 is 'Linux filesystem data' so that will be our root disk. It is +in ext2 format:: + + => ext2ls scsi 0:2 + 4096 . + 4096 .. + 16384 lost+found + 4096 boot + 12288 etc + 4096 media + 4096 bin + 4096 dev + 4096 home + 4096 lib + 4096 lib64 + 4096 mnt + 4096 opt + 4096 proc + 4096 root + 4096 run + 12288 sbin + 4096 srv + 4096 sys + 4096 tmp + 4096 usr + 4096 var +33 initrd.img +30 vmlinuz + 4096 cdrom +33 initrd.img.old + => + +and if you look in the /boot directory you will see the kernel:: + + => ext2ls scsi 0:2 /boot + 4096 . + 4096 .. + 4096 efi + 4096 grub +3381262 System.map-3.13.0-32-generic +1162712 abi-3.13.0-32-generic + 165611 config-3.13.0-32-generic + 176500 memtest86+.bin + 178176 memtest86+.elf + 178680 memtest86+_multiboot.bin +5798112 vmlinuz-3.13.0-32-generic + 165762 config-3.13.0-58-generic +1165129 abi-3.13.0-58-generic +5823136 vmlinuz-3.13.0-58-generic + 19215259 initrd.img-3.13.0-58-generic +3391763 System.map-3.13.0-58-generic +5825048 vmlinuz-3.13.0-58-generic.efi.signed + 28304443 initrd.img-3.13.0-32-generic + => + +The 'vmlinuz' files contain a packaged Linux kernel. The format is a kind of +self-extracting compressed file mixed with some 'setup' configuration data. +Despite its size (uncompressed it is >10MB) this only includes a basic set of +device drivers, enough to boot on most hardware types. + +The 'initrd' files contain a RAM disk. This is something that can be loaded +into RAM and will appear to Linux
[PATCH v2 20/20] x86: doc: coreboot: Mention 64-bit Linux distros
Add a little more detail as to why coreboot64 is preferred for booting Linux distros. Signed-off-by: Simon Glass --- Changes in v2: - Add new patch doc/board/coreboot/coreboot.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/board/coreboot/coreboot.rst b/doc/board/coreboot/coreboot.rst index 88437c27740e..a32c3a864f90 100644 --- a/doc/board/coreboot/coreboot.rst +++ b/doc/board/coreboot/coreboot.rst @@ -82,6 +82,8 @@ build in `$CBDIR`:: -device ahci,id=ahci \ -device ide-hd,drive=disk,bus=ahci.0 \ +This allows booting and installing various distros, many of which are +64-bit-only, so cannot work with the 32-bit 'coreboot' build. CBFS access --- -- 2.42.0.rc1.204.g551eb34607-goog
[PATCH v2 18/20] x86: doc: Update summaries and add links
Refresh the summary information so it is more up-to-date. Add links to the coreboot and slimbootloader docs. Signed-off-by: Simon Glass --- Changes in v2: - Add new patch doc/arch/x86/x86.rst | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/doc/arch/x86/x86.rst b/doc/arch/x86/x86.rst index ef6970b88a59..e75b5a73ffc0 100644 --- a/doc/arch/x86/x86.rst +++ b/doc/arch/x86/x86.rst @@ -11,9 +11,9 @@ including supported boards, build instructions, todo list, etc. Status -- U-Boot supports running as a `coreboot`_ payload on x86. So far only Link -(Chromebook Pixel) and `QEMU`_ x86 targets have been tested, but it should -work with minimal adjustments on other x86 boards since coreboot deals with -most of the low-level details. +(Chromebook Pixel), Brya (Alder Lake Chromebook) and `QEMU`_ x86 targets have +been tested, but it should work with minimal adjustments on other x86 boards +since coreboot deals with most of the low-level details. U-Boot is a main bootloader on Intel Edison board. @@ -31,12 +31,14 @@ are supported: - Link (Chromebook Pixel) - Minnowboard MAX - Samus (Chromebook Pixel 2015) + - Coral (Apollo Lake Chromebooks circa 2017) - QEMU x86 (32-bit & 64-bit) As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit Linux kernel as part of a FIT image. It also supports a compressed zImage. U-Boot supports loading an x86 VxWorks kernel. Please check README.vxworks -for more details. +for more details. Finally, U-Boot can boot Linux distributions with a UEFI +interface. Build Instructions for U-Boot as BIOS replacement (bare mode) - @@ -700,9 +702,10 @@ for details of EFI support in U-Boot. Chain-loading - -U-Boot can be chain-loaded from another bootloader, such as coreboot or -Slim Bootloader. Typically this is done by building for targets 'coreboot' or -'slimbootloader'. +U-Boot can be chain-loaded from another bootloader, such as +:doc:`../../board/coreboot/index` coreboot or +:doc:`../../board/intel/slimbootloader`. Typically this is done by building for +targets 'coreboot' or 'slimbootloader'. For example, at present we have a 'coreboot' target but this runs very different code from the bare-metal targets, such as coral. There is very little -- 2.42.0.rc1.204.g551eb34607-goog
[PATCH v2 17/20] x86: doc: Move into its own directory
There is enough material that it makes sense to split this up into
several files. Create an x86/ directory for this purpose.
Signed-off-by: Simon Glass
---
Changes in v2:
- Add new patch
doc/arch/index.rst | 2 +-
doc/arch/x86/index.rst | 11 +++
doc/arch/{ => x86}/x86.rst | 6 +++---
3 files changed, 15 insertions(+), 4 deletions(-)
create mode 100644 doc/arch/x86/index.rst
rename doc/arch/{ => x86}/x86.rst (99%)
diff --git a/doc/arch/index.rst b/doc/arch/index.rst
index 2f916f4026c5..60c93b3b6640 100644
--- a/doc/arch/index.rst
+++ b/doc/arch/index.rst
@@ -15,5 +15,5 @@ Architecture-specific doc
riscv
sandbox/index
sh
- x86
+ x86/index
xtensa
diff --git a/doc/arch/x86/index.rst b/doc/arch/x86/index.rst
new file mode 100644
index ..3dc19d603d4c
--- /dev/null
+++ b/doc/arch/x86/index.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0+ */
+.. Copyright 2023 Google LLC
+.. sectionauthor:: Simon Glass
+
+x86
+===
+
+.. toctree::
+ :maxdepth: 2
+
+ x86
diff --git a/doc/arch/x86.rst b/doc/arch/x86/x86.rst
similarity index 99%
rename from doc/arch/x86.rst
rename to doc/arch/x86/x86.rst
index 725a1ae58639..ef6970b88a59 100644
--- a/doc/arch/x86.rst
+++ b/doc/arch/x86/x86.rst
@@ -695,8 +695,8 @@ to load a 'u-boot-payload.efi', see below test logs on QEMU.
No controllers found
Hit any key to stop autoboot: 0
-See :doc:`../develop/uefi/u-boot_on_efi` and :doc:`../develop/uefi/uefi` for
-details of EFI support in U-Boot.
+See :doc:`../../develop/uefi/u-boot_on_efi` and :doc:`../../develop/uefi/uefi`
+for details of EFI support in U-Boot.
Chain-loading
-
@@ -732,7 +732,7 @@ SMBIOS tables
To generate SMBIOS tables in U-Boot, for use by the OS, enable the
CONFIG_GENERATE_SMBIOS_TABLE option. The easiest way to provide the values to
use is via the device tree. For details see
-:download:`smbios.txt <../device-tree-bindings/sysinfo/smbios.txt>`.
+:download:`smbios.txt <../../device-tree-bindings/sysinfo/smbios.txt>`.
TODO List
-
--
2.42.0.rc1.204.g551eb34607-goog
[PATCH v2 16/20] x86: coreboot: Record the position of the SMBIOS tables
Make a note of where coreboot installed the SMBIOS tables so that we can pass this on to EFI. Signed-off-by: Simon Glass --- Changes in v2: - Add new patch arch/x86/lib/coreboot/cb_sysinfo.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/lib/coreboot/cb_sysinfo.c b/arch/x86/lib/coreboot/cb_sysinfo.c index dfbc80c430e1..f7fd9ea5bcbb 100644 --- a/arch/x86/lib/coreboot/cb_sysinfo.c +++ b/arch/x86/lib/coreboot/cb_sysinfo.c @@ -471,6 +471,7 @@ int get_coreboot_info(struct sysinfo_t *info) return -ENOENT; gd->arch.coreboot_table = addr; gd_set_acpi_start(map_to_sysmem(info->rsdp)); + gd_set_smbios_start(info->smbios_start); gd->flags |= GD_FLG_SKIP_LL_INIT; return 0; -- 2.42.0.rc1.204.g551eb34607-goog
[PATCH v2 15/20] efi: x86: Install the SMBIOS tables if present
When these are available in memory, whether generated by U-Boot or by an earlier firmware stage, install them. Signed-off-by: Simon Glass --- Changes in v2: - Add new patch lib/efi_loader/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile index 0eb748ff1a59..8d31fc61c601 100644 --- a/lib/efi_loader/Makefile +++ b/lib/efi_loader/Makefile @@ -79,7 +79,7 @@ obj-$(CONFIG_VIDEO) += efi_gop.o obj-$(CONFIG_BLK) += efi_disk.o obj-$(CONFIG_NETDEVICES) += efi_net.o obj-$(CONFIG_ACPI) += efi_acpi.o -obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += efi_smbios.o +obj-$(CONFIG_SMBIOS) += efi_smbios.o obj-$(CONFIG_EFI_RNG_PROTOCOL) += efi_rng.o obj-$(CONFIG_EFI_TCG2_PROTOCOL) += efi_tcg2.o obj-$(CONFIG_EFI_RISCV_BOOT_PROTOCOL) += efi_riscv.o -- 2.42.0.rc1.204.g551eb34607-goog
[PATCH v2 14/20] efi: x86: Use the installed SMBIOS tables
U-Boot sets up the SMBIOS tables during startup. Rather than creating a
new set, install the existing ones. Rely on the ACPI table's memory-map
record to cover the tables.
Tidy up the installation-condition code while we are here.
Signed-off-by: Simon Glass
---
Changes in v2:
- Add new patch
lib/efi_loader/efi_setup.c | 10 +-
lib/efi_loader/efi_smbios.c | 37 +++--
2 files changed, 12 insertions(+), 35 deletions(-)
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index ad719afd6328..e6de685e8795 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -326,11 +326,11 @@ efi_status_t efi_init_obj_list(void)
if (ret != EFI_SUCCESS)
goto out;
}
-#ifdef CONFIG_GENERATE_SMBIOS_TABLE
- ret = efi_smbios_register();
- if (ret != EFI_SUCCESS)
- goto out;
-#endif
+ if (IS_ENABLED(CONFIG_SMBIOS)) {
+ ret = efi_smbios_register();
+ if (ret != EFI_SUCCESS)
+ goto out;
+ }
ret = efi_watchdog_register();
if (ret != EFI_SUCCESS)
goto out;
diff --git a/lib/efi_loader/efi_smbios.c b/lib/efi_loader/efi_smbios.c
index 306c0bc54f90..0e6454a8fe0b 100644
--- a/lib/efi_loader/efi_smbios.c
+++ b/lib/efi_loader/efi_smbios.c
@@ -20,36 +20,13 @@
*/
efi_status_t efi_smbios_register(void)
{
- /* Map within the low 32 bits, to allow for 32bit SMBIOS tables */
- u64 dmi_addr = U32_MAX;
- efi_status_t ret;
- void *dmi;
+ ulong addr;
- /* Reserve 4kiB page for SMBIOS */
- ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
-EFI_RUNTIME_SERVICES_DATA, 1, _addr);
+ /* space for all tables is marked in efi_acpi_register() */
+ addr = gd->arch.smbios_start;
+ printf("EFI using SMBIOS tables at %lx\n", addr);
- if (ret != EFI_SUCCESS) {
- /* Could not find space in lowmem, use highmem instead */
- ret = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES,
-EFI_RUNTIME_SERVICES_DATA, 1,
-_addr);
-
- if (ret != EFI_SUCCESS)
- return ret;
- }
-
- /*
-* Generate SMBIOS tables - we know that efi_allocate_pages() returns
-* a 4k-aligned address, so it is safe to assume that
-* write_smbios_table() will write the table at that address.
-*/
- assert(!(dmi_addr & 0xf));
- dmi = (void *)(uintptr_t)dmi_addr;
- if (write_smbios_table(map_to_sysmem(dmi)))
- /* Install SMBIOS information as configuration table */
- return efi_install_configuration_table(_guid, dmi);
- efi_free_pages(dmi_addr, 1);
- log_err("Cannot create SMBIOS table\n");
- return EFI_SUCCESS;
+ /* Install SMBIOS information as configuration table */
+ return efi_install_configuration_table(_guid,
+ map_sysmem(addr, 0));
}
--
2.42.0.rc1.204.g551eb34607-goog
[PATCH v2 13/20] x86: Record the position of the SMBIOS tables
Remember where these end up so that we can pass this information on to
the EFI layer.
Signed-off-by: Simon Glass
---
Changes in v2:
- Add new patch
arch/x86/include/asm/global_data.h | 1 +
arch/x86/lib/tables.c | 3 +++
include/asm-generic/global_data.h | 8
3 files changed, 12 insertions(+)
diff --git a/arch/x86/include/asm/global_data.h
b/arch/x86/include/asm/global_data.h
index ea58259ad774..6f4a7130f1da 100644
--- a/arch/x86/include/asm/global_data.h
+++ b/arch/x86/include/asm/global_data.h
@@ -127,6 +127,7 @@ struct arch_global_data {
ulong table_end;/* End address of x86 tables */
ulong table_start_high; /* Start address of high x86 tables */
ulong table_end_high; /* End address of high x86 tables */
+ ulong smbios_start; /* Start address of SMBIOS table */
};
#endif
diff --git a/arch/x86/lib/tables.c b/arch/x86/lib/tables.c
index 67bc0a72aebc..5b5070f7ca57 100644
--- a/arch/x86/lib/tables.c
+++ b/arch/x86/lib/tables.c
@@ -97,6 +97,9 @@ int write_tables(void)
int size = table->size ? : CONFIG_ROM_TABLE_SIZE;
u32 rom_table_end;
+ if (!strcmp("smbios", table->name))
+ gd->arch.smbios_start = rom_addr;
+
if (IS_ENABLED(CONFIG_BLOBLIST_TABLES) && table->tag) {
if (!gd->arch.table_end)
gd->arch.table_end = rom_addr;
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index 8fc205ded1a3..3421daea3632 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -552,6 +552,14 @@ static_assert(sizeof(struct global_data) == GD_SIZE);
#define gd_set_acpi_start(addr)
#endif
+#ifdef CONFIG_SMBIOS
+#define gd_smbios_start() gd->smbios_start
+#define gd_set_smbios_start(addr) gd->arch.smbios_start = addr
+#else
+#define gd_smbios_start() 0UL
+#define gd_set_smbios_start(addr)
+#endif
+
#if CONFIG_IS_ENABLED(MULTI_DTB_FIT)
#define gd_multi_dtb_fit() gd->multi_dtb_fit
#define gd_set_multi_dtb_fit(_dtb) gd->multi_dtb_fit = _dtb
--
2.42.0.rc1.204.g551eb34607-goog
[PATCH v2 12/20] x86: smbios: Add a Kconfig indicating SMBIOS-table presence
When booted from coreboot, U-Boot does not build the SMBIOS tables, but it should still pass them on to the OS. Add a new option which indicates whether SMBIOS tables are present, however they were built. Flip the ordering so that the dependency is listed first, which is less confusing. Signed-off-by: Simon Glass --- Changes in v2: - Add new patch lib/Kconfig | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/lib/Kconfig b/lib/Kconfig index a9dca5f52b5a..b7bbf3f81c56 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -984,8 +984,9 @@ config BLOBLIST_TABLES config GENERATE_SMBIOS_TABLE bool "Generate an SMBIOS (System Management BIOS) table" - default y depends on X86 || EFI_LOADER + default y + imply SMBIOS help The System Management BIOS (SMBIOS) specification addresses how motherboard and system vendors present management information about @@ -1054,6 +1055,15 @@ config SPL_OID_REGISTRY unambiguous persistent name (https://en.wikipedia.org/wiki/Object_identifier). Enable fast lookup object identifier registry in the SPL. +config SMBIOS + bool "SMBIOS support" + depends on X86 + default y + help + Indicates that this platform can create System Management BIOS + (SMBIOS) tables. These provide various pieces of information about + the board, such as the manufacturer and the model name. + config SMBIOS_PARSER bool "SMBIOS parser" help -- 2.42.0.rc1.204.g551eb34607-goog
[PATCH v2 10/20] x86: coreboot: Enable VIDEO_COPY
At least on modern machines the write-back mechanism for the frame buffer
is quite slow when scrolling, since it must read the entire frame buffer
and write it back.
Enable the VIDEO_COPY feature to resolve this problem.
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/x86/dts/coreboot.dts| 1 +
configs/coreboot64_defconfig | 1 +
configs/coreboot_defconfig | 1 +
drivers/video/coreboot.c | 12
4 files changed, 15 insertions(+)
diff --git a/arch/x86/dts/coreboot.dts b/arch/x86/dts/coreboot.dts
index f9ff5346a79b..0eb31cae42c1 100644
--- a/arch/x86/dts/coreboot.dts
+++ b/arch/x86/dts/coreboot.dts
@@ -42,6 +42,7 @@
};
coreboot-fb {
+ bootph-some-ram;
compatible = "coreboot-fb";
};
};
diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig
index 2263554a47ce..e5546dadcb0a 100644
--- a/configs/coreboot64_defconfig
+++ b/configs/coreboot64_defconfig
@@ -60,6 +60,7 @@ CONFIG_NVME_PCI=y
CONFIG_SYS_NS16550_MEM32=y
CONFIG_SOUND=y
CONFIG_SOUND_I8254=y
+CONFIG_VIDEO_COPY=y
CONFIG_CONSOLE_SCROLL_LINES=5
CONFIG_SPL_ACPI=y
CONFIG_CMD_DHRYSTONE=y
diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig
index 790b84a87bc7..78694d635532 100644
--- a/configs/coreboot_defconfig
+++ b/configs/coreboot_defconfig
@@ -54,6 +54,7 @@ CONFIG_NVME_PCI=y
CONFIG_SYS_NS16550_MEM32=y
CONFIG_SOUND=y
CONFIG_SOUND_I8254=y
+CONFIG_VIDEO_COPY=y
CONFIG_CONSOLE_SCROLL_LINES=5
CONFIG_CMD_DHRYSTONE=y
# CONFIG_GZIP is not set
diff --git a/drivers/video/coreboot.c b/drivers/video/coreboot.c
index c586475e41ed..5b718ae3e5a5 100644
--- a/drivers/video/coreboot.c
+++ b/drivers/video/coreboot.c
@@ -73,6 +73,17 @@ err:
return ret;
}
+static int coreboot_video_bind(struct udevice *dev)
+{
+ struct video_uc_plat *uc_plat = dev_get_uclass_plat(dev);
+
+ /* Set the maximum supported resolution */
+ uc_plat->size = 4096 * 2160 * 4;
+ log_debug("%s: Frame buffer size %x\n", __func__, uc_plat->size);
+
+ return 0;
+}
+
static const struct udevice_id coreboot_video_ids[] = {
{ .compatible = "coreboot-fb" },
{ }
@@ -82,5 +93,6 @@ U_BOOT_DRIVER(coreboot_video) = {
.name = "coreboot_video",
.id = UCLASS_VIDEO,
.of_match = coreboot_video_ids,
+ .bind = coreboot_video_bind,
.probe = coreboot_video_probe,
};
--
2.42.0.rc1.204.g551eb34607-goog
[PATCH v2 11/20] efi: x86: Correct the condition for installing ACPI tables
It is not always the case that U-Boot builds the ACPI tables itself. For
example, when booting from coreboot, the ACPI tables are built by
coreboot.
Correct the Makefile condition so that U-Boot can pass on tables built
by a previous firmware stage.
Tidy up the installation-condition code while we are here.
Signed-off-by: Simon Glass
---
Changes in v2:
- Add new patch
lib/efi_loader/Makefile| 2 +-
lib/efi_loader/efi_setup.c | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 1a8c8d7cab5c..0eb748ff1a59 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -78,7 +78,7 @@ obj-$(CONFIG_EFI_ESRT) += efi_esrt.o
obj-$(CONFIG_VIDEO) += efi_gop.o
obj-$(CONFIG_BLK) += efi_disk.o
obj-$(CONFIG_NETDEVICES) += efi_net.o
-obj-$(CONFIG_GENERATE_ACPI_TABLE) += efi_acpi.o
+obj-$(CONFIG_ACPI) += efi_acpi.o
obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += efi_smbios.o
obj-$(CONFIG_EFI_RNG_PROTOCOL) += efi_rng.o
obj-$(CONFIG_EFI_TCG2_PROTOCOL) += efi_tcg2.o
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index 58d4e1340233..ad719afd6328 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -321,11 +321,11 @@ efi_status_t efi_init_obj_list(void)
if (ret != EFI_SUCCESS)
goto out;
#endif
-#ifdef CONFIG_GENERATE_ACPI_TABLE
- ret = efi_acpi_register();
- if (ret != EFI_SUCCESS)
- goto out;
-#endif
+ if (IS_ENABLED(CONFIG_ACPI)) {
+ ret = efi_acpi_register();
+ if (ret != EFI_SUCCESS)
+ goto out;
+ }
#ifdef CONFIG_GENERATE_SMBIOS_TABLE
ret = efi_smbios_register();
if (ret != EFI_SUCCESS)
--
2.42.0.rc1.204.g551eb34607-goog
[PATCH v2 09/20] x86: coreboot: Align options between coreboot and coreboot64
These two builds are similar but have some different options for not good reason. Line them up to be as similar as possible. Signed-off-by: Simon Glass --- Changes in v2: - Update the malloc size too configs/coreboot64_defconfig | 7 +++ configs/coreboot_defconfig | 9 - 2 files changed, 7 insertions(+), 9 deletions(-) diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig index 29b68d6929c7..2263554a47ce 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -1,5 +1,6 @@ CONFIG_X86=y CONFIG_TEXT_BASE=0x112 +CONFIG_SYS_MALLOC_LEN=0x200 CONFIG_NR_DRAM_BANKS=8 CONFIG_ENV_SIZE=0x1000 CONFIG_DEFAULT_DEVICE_TREE="coreboot" @@ -18,6 +19,9 @@ CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro" CONFIG_PRE_CONSOLE_BUFFER=y CONFIG_SYS_CONSOLE_INFO_QUIET=y +CONFIG_LOG=y +CONFIG_LOGF_LINE=y +CONFIG_LOGF_FUNC=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_LAST_STAGE_INIT=y CONFIG_SPL_NO_BSS_LIMIT=y @@ -51,10 +55,13 @@ CONFIG_SYS_ATA_ALT_OFFSET=0 CONFIG_ATAPI=y CONFIG_LBA48=y CONFIG_SYS_64BIT_LBA=y +CONFIG_NVME_PCI=y # CONFIG_PCI_PNP is not set CONFIG_SYS_NS16550_MEM32=y CONFIG_SOUND=y CONFIG_SOUND_I8254=y CONFIG_CONSOLE_SCROLL_LINES=5 CONFIG_SPL_ACPI=y +CONFIG_CMD_DHRYSTONE=y # CONFIG_GZIP is not set +CONFIG_SMBIOS_PARSER=y diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig index 2961908f29cd..790b84a87bc7 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -25,23 +25,14 @@ CONFIG_LAST_STAGE_INIT=y CONFIG_PCI_INIT_R=y CONFIG_CMD_IDE=y CONFIG_CMD_MMC=y -CONFIG_CMD_PART=y CONFIG_CMD_SATA=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set -CONFIG_CMD_DHCP=y CONFIG_BOOTP_BOOTFILESIZE=y -CONFIG_CMD_PING=y CONFIG_CMD_TIME=y CONFIG_CMD_SOUND=y -CONFIG_CMD_EXT2=y -CONFIG_CMD_EXT4=y CONFIG_CMD_EXT4_WRITE=y -CONFIG_CMD_FAT=y -CONFIG_CMD_FS_GENERIC=y CONFIG_MAC_PARTITION=y -CONFIG_ISO_PARTITION=y -CONFIG_EFI_PARTITION=y CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_USE_BOOTFILE=y -- 2.42.0.rc1.204.g551eb34607-goog
[PATCH v2 08/20] x86: coreboot: Drop USB init on startup
This is very annoying as it is quite slow on many machines. Also, U-Boot
has an existing 'preboot' mechanism to enable this feature if desired.
Drop this code so that it is possible to choose whether to init USB or
not.
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/x86/cpu/coreboot/coreboot.c | 4
1 file changed, 4 deletions(-)
diff --git a/arch/x86/cpu/coreboot/coreboot.c b/arch/x86/cpu/coreboot/coreboot.c
index a0c62cce2293..fa3daeff8229 100644
--- a/arch/x86/cpu/coreboot/coreboot.c
+++ b/arch/x86/cpu/coreboot/coreboot.c
@@ -82,10 +82,6 @@ static void board_final_init(void)
int last_stage_init(void)
{
- /* start usb so that usb keyboard can be used as input device */
- if (IS_ENABLED(CONFIG_USB_KEYBOARD))
- usb_init();
-
board_final_init();
return 0;
--
2.42.0.rc1.204.g551eb34607-goog
[PATCH v2 07/20] x86: coreboot: Enable CONFIG_SYS_NS16550_MEM32
The debug UART on modern machines uses a 32-bit wide transfer. Without this, setting debug output causes a hang or no output. It is not obvious (when enabling CONFIG_DEBUG_UART) that this is needed. Enable 32-bit access to avoid this trap. Signed-off-by: Simon Glass --- (no changes since v1) configs/coreboot64_defconfig | 1 + configs/coreboot_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig index a094a7c24234..29b68d6929c7 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -52,6 +52,7 @@ CONFIG_ATAPI=y CONFIG_LBA48=y CONFIG_SYS_64BIT_LBA=y # CONFIG_PCI_PNP is not set +CONFIG_SYS_NS16550_MEM32=y CONFIG_SOUND=y CONFIG_SOUND_I8254=y CONFIG_CONSOLE_SCROLL_LINES=5 diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig index 735cd6eb4c22..2961908f29cd 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -60,6 +60,7 @@ CONFIG_LBA48=y CONFIG_SYS_64BIT_LBA=y CONFIG_NVME_PCI=y # CONFIG_PCI_PNP is not set +CONFIG_SYS_NS16550_MEM32=y CONFIG_SOUND=y CONFIG_SOUND_I8254=y CONFIG_CONSOLE_SCROLL_LINES=5 -- 2.42.0.rc1.204.g551eb34607-goog
[PATCH v2 06/20] x86: coreboot: Look for DBG2 UART in SPL too
If coreboot does not set up sysinfo for the UART, SPL currently hangs. Use the DBG2 teechnique there as well. This allows coreboot64 to boot from coreboot even if the console info is missing from sysinfo Signed-off-by: Simon Glass --- (no changes since v1) configs/coreboot64_defconfig | 1 + drivers/serial/Kconfig | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig index 602465175d20..a094a7c24234 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -55,4 +55,5 @@ CONFIG_SYS_64BIT_LBA=y CONFIG_SOUND=y CONFIG_SOUND_I8254=y CONFIG_CONSOLE_SCROLL_LINES=5 +CONFIG_SPL_ACPI=y # CONFIG_GZIP is not set diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index a1e089962a91..01100b6d93f3 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -672,7 +672,7 @@ config COREBOOT_SERIAL config COREBOOT_SERIAL_FROM_DBG2 bool "Obtain UART from ACPI tables" depends on COREBOOT_SERIAL - default y if !SPL + default y help Select this to try to find a DBG2 record in the ACPI tables, in the event that coreboot does not provide information about the UART in the -- 2.42.0.rc1.204.g551eb34607-goog
[PATCH v2 05/20] x86: Allow APCI in SPL
This is needed so we can find the DBG2 table provided by coreboot. Add a Kconfig so it can be enabled. Signed-off-by: Simon Glass --- (no changes since v1) lib/Kconfig | 8 1 file changed, 8 insertions(+) diff --git a/lib/Kconfig b/lib/Kconfig index 07e61de5b641..a9dca5f52b5a 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -289,6 +289,14 @@ config ACPI not necessarily include generation of tables (see GENERATE_ACPI_TABLE), but allows for tables to be located. +config SPL_ACPI + bool "Enable support for ACPI libraries in SPL" + depends on SPL && SUPPORT_ACPI + help + Provides library functions for dealing with ACPI tables in SPL. This + does not necessarily include generation of tables + (see GENERATE_ACPI_TABLE), but allows for tables to be located. + config GENERATE_ACPI_TABLE bool "Generate an ACPI (Advanced Configuration and Power Interface) table" depends on ACPI -- 2.42.0.rc1.204.g551eb34607-goog
[PATCH v2 04/20] x86: Set the CPU vendor in SPL
We don't read this information in 64-bit mode, since we don't have the
macros for doing it. Set it to Intel by default. This allows the TSC timer
to work correctly.
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/x86/cpu/x86_64/cpu.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/cpu/x86_64/cpu.c b/arch/x86/cpu/x86_64/cpu.c
index d1c3873dd6a7..2647bff891f8 100644
--- a/arch/x86/cpu/x86_64/cpu.c
+++ b/arch/x86/cpu/x86_64/cpu.c
@@ -8,8 +8,11 @@
#include
#include
#include
+#include
#include
+DECLARE_GLOBAL_DATA_PTR;
+
int cpu_has_64bit(void)
{
return true;
@@ -38,6 +41,10 @@ int x86_mp_init(void)
int x86_cpu_reinit_f(void)
{
+ /* set the vendor to Intel so that native_calibrate_tsc() works */
+ gd->arch.x86_vendor = X86_VENDOR_INTEL;
+ gd->arch.has_mtrr = true;
+
return 0;
}
--
2.42.0.rc1.204.g551eb34607-goog
[PATCH v2 03/20] x86: coreboot: Rearrange arch_cpu_init()
Init errors in SPL are currently ignored by this function.
Change the code to init the CPU, reporting an error if something is wrong.
After that, look for the coreboot table.
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/x86/cpu/coreboot/coreboot.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/x86/cpu/coreboot/coreboot.c b/arch/x86/cpu/coreboot/coreboot.c
index d7eedbd7436e..a0c62cce2293 100644
--- a/arch/x86/cpu/coreboot/coreboot.c
+++ b/arch/x86/cpu/coreboot/coreboot.c
@@ -20,7 +20,14 @@
int arch_cpu_init(void)
{
- int ret = get_coreboot_info(_sysinfo);
+ int ret;
+
+ ret = IS_ENABLED(CONFIG_X86_RUN_64BIT) ? x86_cpu_reinit_f() :
+x86_cpu_init_f();
+ if (ret)
+ return ret;
+
+ ret = get_coreboot_info(_sysinfo);
if (ret != 0) {
printf("Failed to parse coreboot tables.\n");
return ret;
@@ -28,8 +35,7 @@ int arch_cpu_init(void)
timestamp_init();
- return IS_ENABLED(CONFIG_X86_RUN_64BIT) ? x86_cpu_reinit_f() :
-x86_cpu_init_f();
+ return 0;
}
int checkcpu(void)
--
2.42.0.rc1.204.g551eb34607-goog
[PATCH v2 02/20] x86: coreboot: Enable standard boot
Enable bootstd options and provide instructions on how to boot a linux distro using coreboot. Signed-off-by: Simon Glass --- (no changes since v1) configs/coreboot64_defconfig| 14 ++ configs/coreboot_defconfig | 1 + doc/board/coreboot/coreboot.rst | 16 ++-- 3 files changed, 17 insertions(+), 14 deletions(-) diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig index ded0e6f2422d..602465175d20 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -10,40 +10,30 @@ CONFIG_VENDOR_COREBOOT=y CONFIG_TARGET_COREBOOT=y CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y +CONFIG_BOOTSTD_FULL=y +CONFIG_BOOTSTD_DEFAULTS=y CONFIG_SYS_MONITOR_BASE=0x0112 CONFIG_SHOW_BOOT_PROGRESS=y CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro" -CONFIG_USE_BOOTCOMMAND=y -CONFIG_BOOTCOMMAND="ext2load scsi 0:3 0100 /boot/vmlinuz; zboot 0100" CONFIG_PRE_CONSOLE_BUFFER=y CONFIG_SYS_CONSOLE_INFO_QUIET=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_LAST_STAGE_INIT=y CONFIG_SPL_NO_BSS_LIMIT=y -CONFIG_HUSH_PARSER=y CONFIG_SYS_PBSIZE=532 CONFIG_CMD_IDE=y CONFIG_CMD_MMC=y -CONFIG_CMD_PART=y CONFIG_CMD_SATA=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set -CONFIG_CMD_DHCP=y CONFIG_BOOTP_BOOTFILESIZE=y -CONFIG_CMD_PING=y CONFIG_CMD_TIME=y CONFIG_CMD_SOUND=y -CONFIG_CMD_EXT2=y -CONFIG_CMD_EXT4=y CONFIG_CMD_EXT4_WRITE=y -CONFIG_CMD_FAT=y -CONFIG_CMD_FS_GENERIC=y CONFIG_MAC_PARTITION=y # CONFIG_SPL_MAC_PARTITION is not set # CONFIG_SPL_DOS_PARTITION is not set -CONFIG_ISO_PARTITION=y -CONFIG_EFI_PARTITION=y # CONFIG_SPL_EFI_PARTITION is not set CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig index 56cc542df6c6..735cd6eb4c22 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -10,6 +10,7 @@ CONFIG_TARGET_COREBOOT=y CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y CONFIG_BOOTSTD_FULL=y +CONFIG_BOOTSTD_DEFAULTS=y CONFIG_SYS_MONITOR_BASE=0x0111 CONFIG_SHOW_BOOT_PROGRESS=y CONFIG_USE_BOOTARGS=y diff --git a/doc/board/coreboot/coreboot.rst b/doc/board/coreboot/coreboot.rst index be5b0de5495e..88437c27740e 100644 --- a/doc/board/coreboot/coreboot.rst +++ b/doc/board/coreboot/coreboot.rst @@ -67,9 +67,21 @@ To use 4GB of memory, typically necessary for booting Linux distros, add In addition to the 32-bit 'coreboot' build there is a 'coreboot64' build. This produces an image which can be booted from coreboot (32-bit). Internally it works by using a 32-bit SPL binary to switch to 64-bit for running U-Boot. It -can be useful for running UEFI applications, for example. +can be useful for running UEFI applications, for example with the coreboot +build in `$CBDIR`:: + + DISK=ubuntu-23.04-desktop-amd64.iso + CBDIR=~/coreboot/build + + cp $CBDIR/coreboot.rom.in coreboot.rom + cbfstool coreboot.rom add-flat-binary -f u-boot-x86-with-spl.bin \ + -n fallback/payload -c LZMA -l 0x111 -e 0x111 + + qemu-system-x86_64 -m 2G -smp 4 -bios coreboot.rom \ + -drive id=disk,file=$DISK,if=none \ + -device ahci,id=ahci \ + -device ide-hd,drive=disk,bus=ahci.0 \ -This has only been lightly tested. CBFS access --- -- 2.42.0.rc1.204.g551eb34607-goog
[PATCH v2 01/20] x86: coreboot: Add IDE and SATA
Add these options to permit access to more disk types. Add some documentation as well. Signed-off-by: Simon Glass --- (no changes since v1) configs/coreboot64_defconfig| 1 + configs/coreboot_defconfig | 9 + doc/board/coreboot/coreboot.rst | 20 3 files changed, 30 insertions(+) diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig index 8aadaa68c279..ded0e6f2422d 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -26,6 +26,7 @@ CONFIG_SYS_PBSIZE=532 CONFIG_CMD_IDE=y CONFIG_CMD_MMC=y CONFIG_CMD_PART=y +CONFIG_CMD_SATA=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig index 8e11de663819..56cc542df6c6 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -22,8 +22,10 @@ CONFIG_LOGF_FUNC=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_LAST_STAGE_INIT=y CONFIG_PCI_INIT_R=y +CONFIG_CMD_IDE=y CONFIG_CMD_MMC=y CONFIG_CMD_PART=y +CONFIG_CMD_SATA=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y @@ -48,6 +50,13 @@ CONFIG_USE_ROOTPATH=y CONFIG_REGMAP=y CONFIG_SYSCON=y # CONFIG_ACPIGEN is not set +CONFIG_SYS_IDE_MAXDEVICE=4 +CONFIG_SYS_ATA_DATA_OFFSET=0 +CONFIG_SYS_ATA_REG_OFFSET=0 +CONFIG_SYS_ATA_ALT_OFFSET=0 +CONFIG_ATAPI=y +CONFIG_LBA48=y +CONFIG_SYS_64BIT_LBA=y CONFIG_NVME_PCI=y # CONFIG_PCI_PNP is not set CONFIG_SOUND=y diff --git a/doc/board/coreboot/coreboot.rst b/doc/board/coreboot/coreboot.rst index d660a223d9c8..be5b0de5495e 100644 --- a/doc/board/coreboot/coreboot.rst +++ b/doc/board/coreboot/coreboot.rst @@ -41,6 +41,26 @@ At present it seems that for Minnowboard Max, coreboot does not pass through the video information correctly (it always says the resolution is 0x0). This works correctly for link though. +You can run via QEMU using:: + + qemu-system-x86_64 -bios build/coreboot.rom -serial mon:stdio + +The `-serial mon:stdio` part shows both output in the display and on the +console. It is optional. You can add `nographic` as well to *only* get console +output. + +To run with a SATA drive called `$DISK`:: + + qemu-system-x86_64 -bios build/coreboot.rom -serial mon:stdio \ + -drive id=disk,file=$DISK,if=none \ + -device ahci,id=ahci \ + -device ide-hd,drive=disk,bus=ahci.0 + +Then you can scan it with `scsi scan` and access it normally. + +To use 4GB of memory, typically necessary for booting Linux distros, add +`-m 4GB`. + 64-bit U-Boot - -- 2.42.0.rc1.204.g551eb34607-goog
[PATCH v2 00/20] x86: efi: Fixes and improvements for coreboot
This little series fixes various bugs and annoyances in coreboot and
coreboot64.
With this both coreboot and coreboot64 start up and work reasonably well
on Brya (x86 Chromebook) and U-Boot can boot common Linux distros.
- Make coreboot64 debug UART start reliably
- Avoid the long USB-init delay on startup
- Correct the timer speed on coreboo64
- Fix a bootstd cros bug (will likely be squashed into another patch)
- Fix the terribly slow console scrolling
With v2 I have also brought in some lost x86 patches so they are all in
one series.
Changes in v2:
- Update the malloc size too
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
- Add new patch
Simon Glass (20):
x86: coreboot: Add IDE and SATA
x86: coreboot: Enable standard boot
x86: coreboot: Rearrange arch_cpu_init()
x86: Set the CPU vendor in SPL
x86: Allow APCI in SPL
x86: coreboot: Look for DBG2 UART in SPL too
x86: coreboot: Enable CONFIG_SYS_NS16550_MEM32
x86: coreboot: Drop USB init on startup
x86: coreboot: Align options between coreboot and coreboot64
x86: coreboot: Enable VIDEO_COPY
efi: x86: Correct the condition for installing ACPI tables
x86: smbios: Add a Kconfig indicating SMBIOS-table presence
x86: Record the position of the SMBIOS tables
efi: x86: Use the installed SMBIOS tables
efi: x86: Install the SMBIOS tables if present
x86: coreboot: Record the position of the SMBIOS tables
x86: doc: Move into its own directory
x86: doc: Update summaries and add links
x86: doc: Split out manual booting into its own file
x86: doc: coreboot: Mention 64-bit Linux distros
arch/x86/cpu/coreboot/coreboot.c | 16 +-
arch/x86/cpu/x86_64/cpu.c | 7 +
arch/x86/dts/coreboot.dts | 1 +
arch/x86/include/asm/global_data.h | 1 +
arch/x86/lib/coreboot/cb_sysinfo.c | 1 +
arch/x86/lib/tables.c | 3 +
configs/coreboot64_defconfig | 25 +--
configs/coreboot_defconfig | 21 +-
doc/arch/index.rst | 2 +-
doc/arch/x86/index.rst | 12 ++
doc/arch/x86/manual_boot.rst | 276 +++
doc/arch/{ => x86}/x86.rst | 295 ++---
doc/board/coreboot/coreboot.rst| 38 +++-
drivers/serial/Kconfig | 2 +-
drivers/video/coreboot.c | 12 ++
include/asm-generic/global_data.h | 8 +
lib/Kconfig| 20 +-
lib/efi_loader/Makefile| 4 +-
lib/efi_loader/efi_setup.c | 20 +-
lib/efi_loader/efi_smbios.c| 37 +---
20 files changed, 447 insertions(+), 354 deletions(-)
create mode 100644 doc/arch/x86/index.rst
create mode 100644 doc/arch/x86/manual_boot.rst
rename doc/arch/{ => x86}/x86.rst (64%)
--
2.42.0.rc1.204.g551eb34607-goog
Re: [PATCH 1/5] board: rockchip: Add Pine64 Quartz64-A Board
Hi Christopher, On 2023-08-08 16:25, Christopher Obbard wrote: > Hi Jonas, > > On Sun, 2023-07-23 at 15:04 +, Jonas Karlman wrote: >> On 2023-07-23 16:55, Jonas Karlman wrote: >>> The Pine64 Quartz64 Model A is a single-board computer based on the >>> Rockchip RK3566 SoC. The board features USB3, SATA, PCIe, HDMI, USB2.0, >>> CSI, DSI, eDP, eMMC, SD, and an e-paper parallel port, as well as a >>> 20 pin GPIO header. >>> >>> Features tested on a Quartz64-A 8GB v2.0 2021-04-27: >>> - SD-card boot >>> - eMMC boot >>> - PCIe/NVMe/AHCI >>> - USB host >>> >>> Device tree is imported from linux v6.4. >>> >>> Co-developed-by: Nicolas Frattaroli >>> Signed-off-by: Nicolas Frattaroli >>> Signed-off-by: Jonas Karlman >>> --- >> >> [...] >> >> Boot log with ROCKCHIP_TPL=rk3566_ddr_1056MHz_v1.17.bin and >> BL31=rk3568_bl31_v1.43.elf: >> >> [...] >> >> U-Boot 2023.07 (Jul 23 2023 - 12:42:18 +) >> >> Model: Pine64 RK3566 Quartz64-A Board >> DRAM: 8 GiB (effective 7.7 GiB) >> PMIC: RK8170 (on=0x10, off=0x00) >> Core: 321 devices, 27 uclasses, devicetree: separate >> MMC: rockchip_sdhci_probe clk set rate fail! >> mmc@fe2b: 1, mmc@fe2c: 2, mmc@fe31: 0 >> Loading Environment from nowhere... OK >> In: serial@fe66 >> Out: serial@fe66 >> Err: serial@fe66 >> Model: Pine64 RK3566 Quartz64-A Board >> Net: No ethernet found. >> >> Hit any key to stop autoboot: 0 >> => > > > I just tried booting U-Boot v2023.10-rc2 with > ROCKCHIP_TPL=rk3566_ddr_1056MHz_v1.17.bin and BL31=rk3568_bl31_v1.43.elf, on > my Quartz64-A but it fails during > loading of some parts. I removed the output of the RK TPL from my logs as > there were no errors. Try with latest rk3566_ddr_1056MHz_v1.18.bin and see if that makes any difference. > > This is when booting from eMMC. Does it boot with SD-card or other eMMC modules? > > I also tried building your branch from > https://github.com/Kwiboo/u-boot-rockchip/tree/rk3568-2023.10 and Please try with a GitHub actions built u-boot-rockchip.bin based on my rk3568-2023.07.02 branch at https://github.com/Kwiboo/u-boot-build/actions/runs/561235 > > > The full build commands: > > export ROCKCHIP_TPL=rkbin/bin/rk35/rk3566_ddr_1056MHz_v1.17.bin > export BL31=rkbin/bin/rk35/rk3568_bl31_v1.43.elf > make quartz64-a-rk3566_defconfig > make -j16 > > rkdeveloptool db rk356x_spl_loader_v1.13.112.bin > rkdeveloptool wl 64 u-boot-rockchip.bin What happens if you write u-boot-rockchip.bin to eMMC module usinga USB adapter: dd if=u-boot-rockchip.bin of=/dev/ bs=32k seek=1 conv=fsync or using U-Boot cmd when booted from a SD-card? # Read u-boot-rockchip.bin from first partition of a SD card load mmc 1:1 1000 u-boot-rockchip.bin # Change to eMMC mmc dev 0 # Write 10 MiB (0x5000 blocks) at sector 64 (0x40) mmc write $fileaddr 40 5000 Does that make any difference? > > Boot log (v2023.10-rc2): > > U-Boot SPL 2023.10-rc2 (Aug 08 2023 - 14:02:34 +0100) > rockchip_sdhci_probe clk set rate fail! > Trying to boot from MMC1 > spl: mmc init failed with error: -110 > Trying to boot from MMC2 > Card did not respond to voltage select! : -110 > spl: mmc init failed with error: -95 > Trying to boot from MMC1 Strange that second try of eMMC (MMC1) gets little bit longer. > ## Checking hash(es) for config config-1 ... OK > ## Checking hash(es) for Image atf-1 ... sha256+ OK > spl_load_simple_fit: can't load image loadables index 0 (ret = -5) > mmc_load_image_raw_sector: mmc block read error > SPL: failed to boot from all boot devices > ### ERROR ### Please RESET the board ### > > > Boot log (your branch): > > U-Boot SPL 2023.10-rc1-00368-g16cb31d427 (Aug 08 2023 - 15:17:35 +0100) > Trying to boot from MMC1 > spl: mmc init failed with error: -70 > Trying to boot from MMC2 > Card did not respond to voltage select! : -110 > spl: mmc init failed with error: -95 > Trying to boot from MMC1 > ## Checking hash(es) for config config-1 ... OK > mmc_load_image_raw_sector: mmc block read error > SPL: failed to boot from all boot devices > ### ERROR ### Please RESET the board ### I have not been able to reproduce this kind of issue on any of my two Quartz64-A boards, tested with different eMMC modules. Does your eMMC module have some compatibility issue? Do you have any more details on the eMMC module you have tested with? There was also some clk and pinctrl changes recently merged into master branch, but they was probably included in the build from my branch based on the lack of "rockchip_sdhci_probe clk set rate fail!" message. Regards, Jonas > > > Thanks! > > Chris >
Re: [PATCH 2/5] drivers: security: Add TPM2 implementation of security devices
Hi Simon,
On 2023-08-17 6:41 a.m., Simon Glass wrote:
Hi Sean,
On Fri, 11 Aug 2023 at 18:28, wrote:
From: Stephen Carlson
This implementation of the security uclass driver allows existing TPM2
devices declared in the device tree to be referenced for storing the OS
anti-rollback counter, using the TPM2 non-volatile storage API.
Signed-off-by: Stephen Carlson
---
MAINTAINERS | 1 +
drivers/security/Makefile | 1 +
drivers/security/security-tpm.c | 173
include/tpm-v2.h| 1 +
4 files changed, 176 insertions(+)
create mode 100644 drivers/security/security-tpm.c
This is a bit wonky w.r.t driver model. The TPM itself should
implement this API, perhaps ina separate file shared with all v2 TPMs.
You should not be opening the device, etc. in here.
I hope that makes sense...you effectively need to turn the TPM into a
multi-function device within driver model. Of course TPMs are
multi-function devices anyway, but here you are making their functions
available more explicitly with a nicer API.
Then you can call the TPM API to do what you want, but at least you
know that the TPM has been probed before you start.
Regards,
Simon
Let's step back for a moment to understand our intention with this feature.
We want secure storage for the anti-rollback counter. The intention is
that this storage is provided by whatever "secure driver" (let's start
calling it the "rollback driver"). On our platform, we're using a
different "rollback driver" which accesses a non-TPM based secure
storage (which we can't upstream because it's proprietary). For the
purpose of making this feature publicly available, we've added the
TPM-backed "rollback driver" (this patch). I'll make this intention
more clear in the documentation, which should lead to less confusion?
At the end of the day, all we require is dm_security_arbvn_get() and
dm_security_arbvn_set(), to get/set from the secure storage (we'll
rename these to something less ugly, because yes arbvn is gross). We
don't want to lock this feature to the TPM, because it doesn't enable
us/others to choose a different secure storage mechanism.
W.r.t opening/initializing the TPM. Someone has to open it? In our
case, it's being opened earlier with our measured boot, so "-EBUSY" in
returned on tpm_open() (we return and everyone is happy). My
understanding is that this is the currently available way for multiple
drivers to access the TPM. Ilias has recommended we use
tpm_auto_start(), which is an enhancement I'm planning to make. This
should clean thing up? If this doesn't meet your expectations, can you
describe in more detail how we should turn the TPM into a
"multi-function device"?
diff --git a/MAINTAINERS b/MAINTAINERS
index 73b6943e03..257660a847 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1444,6 +1444,7 @@ S:Maintained
F: drivers/security/Kconfig
F: drivers/security/Makefile
F: drivers/security/sandbox_security.c
+F: drivers/security/security-tpm.c
F: drivers/security/security-uclass.c
SEMIHOSTING
diff --git a/drivers/security/Makefile b/drivers/security/Makefile
index ed10c3f234..e81966bb4a 100644
--- a/drivers/security/Makefile
+++ b/drivers/security/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_DM_SECURITY) += security-uclass.o
obj-$(CONFIG_SECURITY_SANDBOX) += sandbox_security.o
+obj-$(CONFIG_SECURITY_TPM) += security-tpm.o
diff --git a/drivers/security/security-tpm.c b/drivers/security/security-tpm.c
new file mode 100644
index 00..9070dd49ac
--- /dev/null
+++ b/drivers/security/security-tpm.c
@@ -0,0 +1,173 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2021 Microsoft, Inc
+ * Written by Stephen Carlson
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+struct security_state {
+ u32 index_arbvn;
+ struct udevice *tpm_dev;
+};
+
+static int tpm_security_init(struct udevice *tpm_dev)
+{
+ int res;
+
+ /* Initialize TPM but allow reuse of existing session */
+ res = tpm_open(tpm_dev);
+ if (res == -EBUSY) {
+ log(UCLASS_SECURITY, LOGL_DEBUG,
+ "Existing TPM session found, reusing\n");
+ } else {
+ if (res) {
+ log(UCLASS_SECURITY, LOGL_ERR,
+ "TPM initialization failed (ret=%d)\n", res);
+ return res;
+ }
+
+ res = tpm2_startup(tpm_dev, TPM2_SU_CLEAR);
+ if (res) {
+ log(UCLASS_SECURITY, LOGL_ERR,
+ "TPM startup failed (ret=%d)\n", res);
+ return res;
+ }
+ }
+
+ return 0;
+}
+
+static int tpm_security_arbvn_get(struct udevice *dev, u64 *arbvn)
+{
+ struct security_state *priv = dev_get_priv(dev);
+ int ret;
+
+ if (!arbvn)
+ return -EINVAL;
+
+
[PATCH] rockchip: rk3566-anbernic-rgxx3: Rename defconfig to include SoC name
Rename defconfig to include SoC name, use similar pattern as other
RK356x boards: -.dts -> -_defconfig
Suggested-by: Kever Yang
Signed-off-by: Jonas Karlman
---
board/anbernic/rgxx3_rk3566/MAINTAINERS | 2 +-
...anbernic-rgxx3_defconfig => anbernic-rgxx3-rk3566_defconfig} | 0
doc/board/rockchip/rockchip.rst | 2 +-
3 files changed, 2 insertions(+), 2 deletions(-)
rename configs/{anbernic-rgxx3_defconfig => anbernic-rgxx3-rk3566_defconfig}
(100%)
diff --git a/board/anbernic/rgxx3_rk3566/MAINTAINERS
b/board/anbernic/rgxx3_rk3566/MAINTAINERS
index 6be16a47e8eb..7970e5a4aad7 100644
--- a/board/anbernic/rgxx3_rk3566/MAINTAINERS
+++ b/board/anbernic/rgxx3_rk3566/MAINTAINERS
@@ -3,7 +3,7 @@ M: Chris Morgan
S: Maintained
F: board/anbernic/rgxx3_rk3566
F: include/configs/anbernic-rgxx3-rk3566.h
-F: configs/anbernic-rgxx3_defconfig
+F: configs/anbernic-rgxx3-rk3566_defconfig
F: arch/arm/dts/rk3566-anbernic-rgxx3.dts
F: arch/arm/dts/rk3566-anbernic-rgxx3.dtsi
F: arch/arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi
diff --git a/configs/anbernic-rgxx3_defconfig
b/configs/anbernic-rgxx3-rk3566_defconfig
similarity index 100%
rename from configs/anbernic-rgxx3_defconfig
rename to configs/anbernic-rgxx3-rk3566_defconfig
diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst
index 4668e598515e..de9fe8e642b1 100644
--- a/doc/board/rockchip/rockchip.rst
+++ b/doc/board/rockchip/rockchip.rst
@@ -91,7 +91,7 @@ List of mainline supported Rockchip boards:
- Theobroma Systems RK3399-Q7 SoM - Puma (puma_rk3399)
* rk3566
- - Anbernic RGxx3 (anbernic-rgxx3)
+ - Anbernic RGxx3 (anbernic-rgxx3-rk3566)
- Pine64 Quartz64-A Board (quartz64-a-rk3566)
- Pine64 Quartz64-B Board (quartz64-b-rk3566)
- Pine64 SOQuartz on Blade (soquartz-blade-rk3566)
--
2.41.0
Re: [PATCH 1/3] doc: rockchip: Add supported RK3566/RK3568 boards
On 2023-08-17 21:29, Tom Rini wrote: > On Thu, Aug 17, 2023 at 04:32:41PM +0800, Kever Yang wrote: >> Hi Jonas, >> >> Thanks for your patch. >> >> On 2023/8/17 14:04, Jonas Karlman wrote: >>> Update Rockchip documentation to include RK3566/RK3568 boards already >>> supported. Also list Pine64 boards under RK3566 and drop defconfig to >>> match other listed boards. >>> >>> Signed-off-by: Jonas Karlman >>> --- >>> doc/board/rockchip/rockchip.rst | 20 >>> 1 file changed, 12 insertions(+), 8 deletions(-) >>> >>> diff --git a/doc/board/rockchip/rockchip.rst >>> b/doc/board/rockchip/rockchip.rst >>> index 31aeb8567607..4668e598515e 100644 >>> --- a/doc/board/rockchip/rockchip.rst >>> +++ b/doc/board/rockchip/rockchip.rst >>> @@ -91,18 +91,22 @@ List of mainline supported Rockchip boards: >>>- Theobroma Systems RK3399-Q7 SoM - Puma (puma_rk3399) >>> * rk3566 >>> - - Anbernic RGxx3 (rgxx3-rk3566) >>> + - Anbernic RGxx3 (anbernic-rgxx3) >> >> This board is using anbernic-rgxx3 as defconfig name, but I would prefer >> update this defconfig to >> >> use name rgxx3-rk3566_defconfig instead, to follow all the other boards with >> SoC name. > > Sorry, in my rush to get more MAINTAINERS entries updated / correct I > missed your feedback here. Jonas, please update and I'll make sure it > gets in to the tree. > Thanks, will send a patch that rename to anbernic-rgxx3-rk3566_defconfig and update docs to reflect the new name shortly. Regards, Jonas
Re: [PATCH 2/3] board: rockchip: rk35xx: Add device tree files to MAINTAINERS
On Thu, Aug 17, 2023 at 10:46:14AM +0200, Quentin Schulz wrote: > Hi Jonas, > > On 8/17/23 08:04, Jonas Karlman wrote: > > Update MAINTAINERS files for RK3566/RK3568/RK3588 boards to include > > related device tree files. Also replace space with tabs. > > > > Signed-off-by: Jonas Karlman > > --- > > board/anbernic/rgxx3_rk3566/MAINTAINERS | 3 ++ > > .../neural-compute-module-6/MAINTAINERS | 6 +++ > > board/radxa/rock5a-rk3588s/MAINTAINERS| 2 + > > board/radxa/rock5b-rk3588/MAINTAINERS | 4 +- > > board/rockchip/evb_rk3568/MAINTAINERS | 51 ++- > > board/rockchip/evb_rk3588/MAINTAINERS | 3 +- > > 6 files changed, 43 insertions(+), 26 deletions(-) > > > > diff --git a/board/anbernic/rgxx3_rk3566/MAINTAINERS > > b/board/anbernic/rgxx3_rk3566/MAINTAINERS > > index 1c0d3fe7b5bf..6be16a47e8eb 100644 > > --- a/board/anbernic/rgxx3_rk3566/MAINTAINERS > > +++ b/board/anbernic/rgxx3_rk3566/MAINTAINERS > > @@ -4,3 +4,6 @@ S: Maintained > > F:board/anbernic/rgxx3_rk3566 > > F:include/configs/anbernic-rgxx3-rk3566.h > > F:configs/anbernic-rgxx3_defconfig > > +F: arch/arm/dts/rk3566-anbernic-rgxx3.dts > > +F: arch/arm/dts/rk3566-anbernic-rgxx3.dtsi > > +F: arch/arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi > > An easier way to deal with this is to use the "*" character since it's > supported in MAINTAINERS file apparently (ag -Q "*" **/MAINTAINERS returns > multiple matches in multiple files). So maybe replace it with something like > > F: arch/arm/dts/rk3566-anbernic-rgxx3* > > ? > > That way if the files eventually get split into multiple ones, get renamed, > have one created (e.g. -u-boot.dtsi), they are all matched by that same > line. Less maintenance here (and hopefully precise enough that we don't have > false positives). > > Just a suggestion, Using the "N:" syntax might be better-still, since you could do: N: anbernic-rgxx3 And that covers anything with anbernic-rgxx3 in the name. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/3] doc: rockchip: Add supported RK3566/RK3568 boards
On Thu, Aug 17, 2023 at 04:32:41PM +0800, Kever Yang wrote: > Hi Jonas, > > Thanks for your patch. > > On 2023/8/17 14:04, Jonas Karlman wrote: > > Update Rockchip documentation to include RK3566/RK3568 boards already > > supported. Also list Pine64 boards under RK3566 and drop defconfig to > > match other listed boards. > > > > Signed-off-by: Jonas Karlman > > --- > > doc/board/rockchip/rockchip.rst | 20 > > 1 file changed, 12 insertions(+), 8 deletions(-) > > > > diff --git a/doc/board/rockchip/rockchip.rst > > b/doc/board/rockchip/rockchip.rst > > index 31aeb8567607..4668e598515e 100644 > > --- a/doc/board/rockchip/rockchip.rst > > +++ b/doc/board/rockchip/rockchip.rst > > @@ -91,18 +91,22 @@ List of mainline supported Rockchip boards: > >- Theobroma Systems RK3399-Q7 SoM - Puma (puma_rk3399) > > * rk3566 > > - - Anbernic RGxx3 (rgxx3-rk3566) > > + - Anbernic RGxx3 (anbernic-rgxx3) > > This board is using anbernic-rgxx3 as defconfig name, but I would prefer > update this defconfig to > > use name rgxx3-rk3566_defconfig instead, to follow all the other boards with > SoC name. Sorry, in my rush to get more MAINTAINERS entries updated / correct I missed your feedback here. Jonas, please update and I'll make sure it gets in to the tree. -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 0/4] arm: dts: k3-am64: Sync DT with Linux
On Sat, Aug 05, 2023 at 11:14:36AM +0300, Roger Quadros wrote: > Hi, > > This series syncs AM64 DT files from Linux v6.5-rc1. > > Tested on AM642-EVM GP SR1.0 and AM642-SK-EVM HS-FS SR2.0. > > cheers, > -roger > > Changelog: > > v5: > -squash documenation change to correct patch. Update commit log. > -add Nishanth's Reviewed/Tested by > > v4: > -Add documentation for am642-evm and am642-sk-evm. > -Add license to am64 svg file > -drop mmc0 pinmux from k3-am642-r5-evm.dts > -drop stdout-path from -r5 & -u-boot dts. > -drop vtt-supply and vtt pinmux from memorycontroller in k3-am642-r5-evm.dts > -am642-evm: move bootph-pre-ram for main_esm, mcu_esm into -r5 .dts > > v3: > - include board DT file in -r5 DT file. > - move including -u-boot.dtsi file at the top of -r5 DT file. > - drop duplicate nodes > - document why we need to delete clock/power properties from > main_timer0 > > v2: > - Sync with v6.5-rc1 > - Rebase on latest uboot/master > - CPSW node cleanup > - Timer node cleanup > > > Roger Quadros (4): > board: ti: am64x: Recognize AM64-HSEVM > Revert "ARM: dts: k3-am642-sk-u-boot: add PMIC node" > doc: board: ti: am64: Add boot flow diagram > arm: dts: k3-am64: Sync DT with Linux v6.5-rc1 > > arch/arm/dts/k3-am64-main.dtsi | 171 ++- > arch/arm/dts/k3-am64-mcu.dtsi | 53 +- > arch/arm/dts/k3-am64-thermal.dtsi | 33 + > arch/arm/dts/k3-am64.dtsi | 22 +- > arch/arm/dts/k3-am642-evm-u-boot.dtsi | 57 +- > arch/arm/dts/k3-am642-evm.dts | 173 ++- > arch/arm/dts/k3-am642-r5-evm.dts | 231 +--- > arch/arm/dts/k3-am642-r5-sk.dts| 218 +-- > arch/arm/dts/k3-am642-sk-u-boot.dtsi | 113 +- > arch/arm/dts/k3-am642-sk.dts | 166 ++- > arch/arm/dts/k3-am642.dtsi |1 + > board/ti/am64x/evm.c |3 +- > doc/board/ti/am64x_evm.rst | 197 +++ > doc/board/ti/img/boot_diagram_am64.svg | 1702 > doc/board/ti/k3.rst|1 + > 15 files changed, 2506 insertions(+), 635 deletions(-) > create mode 100644 arch/arm/dts/k3-am64-thermal.dtsi > create mode 100644 doc/board/ti/am64x_evm.rst > create mode 100644 doc/board/ti/img/boot_diagram_am64.svg For the series, applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] MAINTAINERS: Update UFS maintainer
On Thu, Aug 17, 2023 at 05:39:14PM +0530, Neha Malcom Francis wrote: > Dropping Faiz Abbas from the UFS maintainer list as his e-mail ID is no > longer valid. > > Adding Bhupesh Sharma who has been using this framework working on > Qualcomm Snapdragon SoCs as well as sending out fixes. > > Adding myself as well to support in reviewing and testing patches. > > Signed-off-by: Neha Malcom Francis Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm_ffa: use debug logs
On Wed, Aug 09, 2023 at 12:47:30PM +0100, Abdellatif El Khlifi wrote: > replace info logs with debug logs > > Signed-off-by: Abdellatif El Khlifi > Cc: Tom Rini > Cc: Simon Glass > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] CI: x86: coreboot: Update to latest coreboot
On Fri, Aug 11, 2023 at 12:17:43PM -0600, Simon Glass wrote: > Use a recent coreboot build for this test. > > The coreboot commit is: > >6f5ead14b4 mb/google/nissa/var/joxer: Update eMMC DLL settings > > This is build with default settings, i.e. QEMU x86 i440fx/piix4 > > Add some documentation as to how to update it next time. > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/3] board: rockchip: rk35xx: Add myself as reviewer to MAINTAINERS
On Thu, Aug 17, 2023 at 06:04:38AM +, Jonas Karlman wrote: > Add myself as a reviewer for RK3566/RK3568/RK3588 boards that I have and > can help with review and testing of defconfig and device tree changes. > > Signed-off-by: Jonas Karlman > Acked-by: Eugen Hristev Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/3] board: rockchip: rk35xx: Add device tree files to MAINTAINERS
On Thu, Aug 17, 2023 at 06:04:36AM +, Jonas Karlman wrote: > Update MAINTAINERS files for RK3566/RK3568/RK3588 boards to include > related device tree files. Also replace space with tabs. > > Signed-off-by: Jonas Karlman > Acked-by: Eugen Hristev Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/3] doc: rockchip: Add supported RK3566/RK3568 boards
On Thu, Aug 17, 2023 at 06:04:34AM +, Jonas Karlman wrote: > Update Rockchip documentation to include RK3566/RK3568 boards already > supported. Also list Pine64 boards under RK3566 and drop defconfig to > match other listed boards. > > Signed-off-by: Jonas Karlman Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] corstone1000: update maintainers
On Fri, Aug 11, 2023 at 01:22:57PM +0100, abdellatif.elkhl...@arm.com wrote: > From: Abdellatif El Khlifi > > Update MAINTAINERS of corstone1000 board. > > Signed-off-by: Xueliang Zhong > Signed-off-by: Abdellatif El Khlifi Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: Add arch/arm/dts/Makefile specifically to MAINTAINERS
On Mon, Aug 07, 2023 at 05:08:11PM -0400, Tom Rini wrote: > In order to reduce the number of people that are cc'd on a patch for > simply touching arch/arm/dts/Makefile (which is a big common file) add > an entry specifically to MAINTAINERS under the ARM entry. > > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] MAINTAINERS: Update UFS maintainer
On 8/17/23 14:09, Neha Malcom Francis wrote: Dropping Faiz Abbas from the UFS maintainer list as his e-mail ID is no longer valid. Adding Bhupesh Sharma who has been using this framework working on Qualcomm Snapdragon SoCs as well as sending out fixes. Adding myself as well to support in reviewing and testing patches. Signed-off-by: Neha Malcom Francis Add '---' here so the CC list is not part of the commit message when this patch is applied, like this: Signed-of-by: Foo User <...> --- CC: Bar Example <...> ... --- V2: Did stuff V3: Did more stuff Cc: Bhupesh Sharma Cc: Vignesh R Cc: Nishnath Menon --- Based on discussion: https://lore.kernel.org/u-boot/CAH=2NtzyQgximynKuG45UUux715Du=wkkusm9-aqghcuzsw...@mail.gmail.com/ MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 77a8b0ac21..d19e1fd60b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1585,7 +1585,8 @@ T:git https://source.denx.de/u-boot/custodians/u-boot-ubi.git F:drivers/mtd/ubi/ UFS -M: Faiz Abbas +M: Bhupesh Sharma +M: Neha Malcom Francis S:Maintained F:drivers/ufs/ With that fixed: Acked-by: Marek Vasut Thanks
Re: [PATCH] spl: provide weak empty stub for reset_cpu()
On Thu, Aug 17, 2023 at 05:35:37PM +0300, Oleksandr Suvorov wrote:
> This stub needs to link SPL properly.
>
> Signed-off-by: Oleksandr Suvorov
> ---
>
> common/spl/spl.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index 0062f3f45d9..781858891b9 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -1026,3 +1026,11 @@ ulong bootcount_load(void)
> return 0;
> }
> #endif
> +
> +/**
> + * Weak default function for board-specific reset. Provide empty stub only.
> + */
> +__weak void reset_cpu(void)
> +{
> + /* Nothing to do! */
> +}
NAK, there are already architectures and SoCs that have a weak
reset_cpu. If you're working on one without reset_cpu, it needs to be
implemented one way or another, not like this.
--
Tom
signature.asc
Description: PGP signature
[PATCH 4/4] ti: mach-k3: Move dfu.h include to be with the code
Move where we include to be guarded by a DFU-related Kconfig
option.
Signed-off-by: Tom Rini
---
This becomes an issue with
https://patchwork.ozlabs.org/project/uboot/patch/20220620111354.448512-1-jh80.ch...@samsung.com/
applied as now we can't include without CONFIG_DFU_NAME_MAX_SIZE
set (or we have a dummy value for ifndef).
---
arch/arm/mach-k3/sysfw-loader.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-k3/sysfw-loader.c b/arch/arm/mach-k3/sysfw-loader.c
index 9be2d9eaea26..a8edc4a92d11 100644
--- a/arch/arm/mach-k3/sysfw-loader.c
+++ b/arch/arm/mach-k3/sysfw-loader.c
@@ -18,7 +18,6 @@
#include
#include
#include
-#include
#include
#include
@@ -297,6 +296,8 @@ static void k3_sysfw_configure_using_fit(void *fit,
}
#if CONFIG_IS_ENABLED(DFU)
+#include
+
static int k3_sysfw_dfu_download(void *addr)
{
char dfu_str[50];
--
2.34.1
[PATCH 3/4] xilinx: zynqmp: Move dfu.h include to be with the code
Move where we include to be guarded by a DFU-related Kconfig option. Signed-off-by: Tom Rini --- This becomes an issue with https://patchwork.ozlabs.org/project/uboot/patch/20220620111354.448512-1-jh80.ch...@samsung.com/ applied as now we can't include without CONFIG_DFU_NAME_MAX_SIZE set (or we have a dummy value for ifndef). Another option would be to restructure the code to move the dfu code to another file, but I don't know if that will make the rest of the real use cases here easier or harder. Cc: Michal Simek --- board/xilinx/zynqmp/zynqmp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c index 309f24a5f43d..367c3c65a9dc 100644 --- a/board/xilinx/zynqmp/zynqmp.c +++ b/board/xilinx/zynqmp/zynqmp.c @@ -8,7 +8,6 @@ #include #include #include -#include #include #include #include @@ -606,6 +605,7 @@ enum env_location env_get_location(enum env_operation op, int prio) } #if defined(CONFIG_SET_DFU_ALT_INFO) +#include #define DFU_ALT_BUF_LENSZ_1K -- 2.34.1
[PATCH 2/4] fwu-mdata: Make FWU_MDATA_GPT_BLK depend on DFU
The implementation of this option in lib/fwu_updates/fwu_gpt.c is wholly dependent on DFU, so make that a requirement here. Signed-off-by: Tom Rini --- I'm honestly not sure how to best proceed here as drivers/fwu-mdata/gpt_blk.c doesn't need DFU, but both files are controlled by this single symbol. Cc: Masami Hiramatsu Cc: Jassi Brar Cc: Sughosh Ganu Cc: Ilias Apalodimas Cc: Heinrich Schuchardt --- drivers/fwu-mdata/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig index 42736a5e43b0..0bd5fef4abfa 100644 --- a/drivers/fwu-mdata/Kconfig +++ b/drivers/fwu-mdata/Kconfig @@ -15,7 +15,7 @@ config FWU_MDATA_GPT_BLK bool "FWU Metadata access for GPT partitioned Block devices" select PARTITION_TYPE_GUID select PARTITION_UUIDS - depends on FWU_MDATA && BLK && EFI_PARTITION + depends on FWU_MDATA && BLK && EFI_PARTITION && DFU help Enable support for accessing FWU Metadata on GPT partitioned block devices. -- 2.34.1
[PATCH 1/4] usb: gadget: g_dnl.c: Drop unused includes
We don't need nor in this file, drop them. Signed-off-by: Tom Rini --- drivers/usb/gadget/g_dnl.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c index afb7b74f3057..8423da377ca9 100644 --- a/drivers/usb/gadget/g_dnl.c +++ b/drivers/usb/gadget/g_dnl.c @@ -16,8 +16,6 @@ #include #include -#include -#include #include -- 2.34.1
Re: Strange gitlab idea
On Thu, Aug 17, 2023 at 10:58:15AM -0600, Simon Glass wrote: > Hi Tom, > > On Thu, 17 Aug 2023 at 09:10, Tom Rini wrote: > > > > On Thu, Aug 17, 2023 at 07:41:50AM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Tue, 15 Aug 2023 at 08:56, Tom Rini wrote: > > > > > > > > On Tue, Aug 15, 2023 at 08:44:20AM -0600, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Sun, 13 Aug 2023 at 09:52, Tom Rini wrote: > > > > > > > > > > > > On Sat, Aug 12, 2023 at 09:14:45PM -0600, Simon Glass wrote: > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > I notice that the runners are not utilised much by the QEMU jobs, > > > > > > > since we only run one at a time. > > > > > > > > > > > > > > I wonder if we could improve this, perhaps by using a different > > > > > > > tag > > > > > > > for the QEMU ones and then having a machine that only runs those > > > > > > > (and > > > > > > > runs 40 in parallel)? > > > > > > > > > > > > > > In general our use of the runners seems a bit primitive, since the > > > > > > > main use of parallelism is in the world builds. > > > > > > > > > > > > I'm honestly not sure. I think there's a few tweaks that we should > > > > > > do, > > > > > > like putting the opensbi and coreboot files in to the Dockerfile > > > > > > logic > > > > > > instead. And maybe seeing if just like we can have a docker > > > > > > registry > > > > > > cache, if we can setup local pypi cache too? I'm not otherwise sure > > > > > > what's taking 23 seconds or so of > > > > > > https://source.denx.de/u-boot/u-boot/-/jobs/673565#L34 since the > > > > > > build > > > > > > and run parts aren't much. > > > > > > > > > > > > My first big worry about running 2 or 3 qemu jobs at the same time > > > > > > on a > > > > > > host is that any wins get from a shorter queue will be lost to > > > > > > buildman > > > > > > doing "make -j$(nproc)" 2 or 3 times at once and so we build slower. > > > > > > > > > > Yes, perhaps. > > > > > > > > > > > > > > > > > My second big worry is that getting the right tags on runners will > > > > > > be a > > > > > > little tricky. > > > > > > > > > > Yes, and error-prone. Also it makes it harder to deal with broken > > > > > machines. > > > > > > > > > > > > > > > > > My third big worry (but this is something you can test easy enough > > > > > > at > > > > > > least) is that running the big sandbox tests, 2 or 3 times at once > > > > > > on > > > > > > the same host will get much slower. I think, but profiling would be > > > > > > helpful, that those get slow due to I/O and not CPU. > > > > > > > > > > I suspect it would be fast enough. > > > > > > > > > > But actually the other problem is that I am not sure whether the jobs > > > > > would have their own filesystem? > > > > > > > > Yes, they should be properly sandboxed. If you want to test some of > > > > these ideas, I think the best path is to just un-register temproarily > > > > (comment out the token in config.toml) some of your runners and then > > > > register them with just the DM tree and experiment. > > > > > > OK thanks for the idea. I tried this on tui > > > > > > I used a 'concurrent = 10' and it got up to a load of 70 or so every > > > now and then, but mostly it was much less. > > > > > > The whole run (of just the test.py stage) took 8 minutes, with > > > 'sandbox with clang test' taking the longest. > > > > > > I'm not too sure what that tells us... > > > > Well, looking at > > https://source.denx.de/u-boot/u-boot/-/pipelines/17391/builds the whole > > run took 56 minutes, of which 46 minutes was on 32bit ARM world build. > > And the longest test.py stage was sandbox without LTO at just under 8 > > minutes. So I think trying to get more concurrency in this stage is > > likely to be a wash in terms of overall CI run time. > > There is quite a lot of variability. Two of the machines take about > 15mins to 32-bit ARM and another two take under 20mins, e.g.: > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/jobs/676055 > > Perhaps we should reserve the big jobs for the fastest machines? But > then what if they all go offline at once? Barring some significant donation of resources, we probably are just going to have to live with enough variation in build time "about an hour" is what we'll end up with. I see that overall the pipeline the above example is from took 50 minutes. -- Tom signature.asc Description: PGP signature
[PATCH RESEND 5/5] clk: ccf: call clock provided ops directly for endisable()
From: Yang Xiwen
Calling into CCF framework will cause a clock being enabled twice
instead of once (clk->enable_count becomes 2 rather than 1), thus making
it hard to disable (needs to call clk_disable() twice).
Fix that by calling clock provided ops directly.
Signed-off-by: Yang Xiwen
---
drivers/clk/clk.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index a38daaac0c..00d082c46f 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
int clk_register(struct clk *clk, const char *drv_name,
const char *name, const char *parent_name)
@@ -115,11 +116,20 @@ int ccf_clk_set_parent(struct clk *clk, struct clk
*parent)
static int ccf_clk_endisable(struct clk *clk, bool enable)
{
struct clk *c;
+ const struct clk_ops *ops;
int err = clk_get_by_id(clk->id, );
if (err)
return err;
- return enable ? clk_enable(c) : clk_disable(c);
+ else
+ ops = clk_dev_ops(c->dev);
+
+ if (enable && ops->enable)
+ return ops->enable(c);
+ else if (!enable && ops->disable)
+ return ops->disable(c);
+
+ return -ENOSYS;
}
int ccf_clk_enable(struct clk *clk)
--
2.34.1
[PATCH RESEND 2/5] clk: call log_debug() instead to avoid console log printing
From: Yang Xiwen
it's a very common case to register a clock without a parent, such as
clk_register_fixed_rate(). Replace log_error() with log_debug() to avoid
useless console log if not debugging.
Signed-off-by: Yang Xiwen
---
drivers/clk/clk.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index a5a3461b66..a38daaac0c 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -24,8 +24,8 @@ int clk_register(struct clk *clk, const char *drv_name,
ret = uclass_get_device_by_name(UCLASS_CLK, parent_name, );
if (ret) {
- log_err("%s: failed to get %s device (parent of %s)\n",
- __func__, parent_name, name);
+ log_debug("%s: failed to get %s device (parent of %s)\n",
+ __func__, parent_name, name);
} else {
log_debug("%s: name: %s parent: %s [0x%p]\n", __func__, name,
parent->name, parent);
--
2.34.1
[PATCH RESEND 4/5] clk: promote clk_dev_ops to linux/clk-provider.h
From: Yang Xiwen
So that it can be used by others.
Signed-off-by: Yang Xiwen
---
drivers/clk/clk-uclass.c | 5 -
include/linux/clk-provider.h | 5 +
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index dc3e9d6a26..5cc80e5e39 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -25,11 +25,6 @@
#include
#include
-static inline const struct clk_ops *clk_dev_ops(struct udevice *dev)
-{
- return (const struct clk_ops *)dev->driver->ops;
-}
-
struct clk *dev_get_clk_ptr(struct udevice *dev)
{
return (struct clk *)dev_get_uclass_priv(dev);
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 801404480b..dfafb4cc9d 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -21,6 +21,11 @@ static inline void clk_dm(ulong id, struct clk *clk)
clk->id = id;
}
+static inline const struct clk_ops *clk_dev_ops(struct udevice *dev)
+{
+ return (const struct clk_ops *)dev->driver->ops;
+}
+
/*
* flags used across common struct clk. these flags should only affect the
* top-level framework. custom flags for dealing with hardware specifics
--
2.34.1
[PATCH RESEND 3/5] clk: also handle ENOENT in *_optional functions
From: Yang Xiwen
If the device does not specify any clocks in device tree, these
functions will return PTR_ERR(-ENOENT). This is not the intended
behavior and does not comply with linux kernel CCF. Fix that by
returning NULL under such circumstances instead.
Signed-off-by: Yang Xiwen
---
include/clk.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/include/clk.h b/include/clk.h
index d91285235f..f95da0838d 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -223,9 +223,11 @@ struct clk *devm_clk_get(struct udevice *dev, const char
*id);
static inline struct clk *devm_clk_get_optional(struct udevice *dev,
const char *id)
{
+ int ret;
struct clk *clk = devm_clk_get(dev, id);
- if (PTR_ERR(clk) == -ENODATA)
+ ret = PTR_ERR(clk);
+ if (ret == -ENODATA || ret == -ENOENT)
return NULL;
return clk;
@@ -335,7 +337,7 @@ static inline int clk_get_by_name_optional(struct udevice
*dev,
int ret;
ret = clk_get_by_name(dev, name, clk);
- if (ret == -ENODATA)
+ if (ret == -ENODATA || ret == -ENOENT)
return 0;
return ret;
@@ -359,7 +361,7 @@ static inline int clk_get_by_name_nodev_optional(ofnode
node, const char *name,
int ret;
ret = clk_get_by_name_nodev(node, name, clk);
- if (ret == -ENODATA)
+ if (ret == -ENODATA || ret == -ENOENT)
return 0;
return ret;
--
2.34.1
[PATCH RESEND 1/5] clk: export clk_register_mux_table()
From: Yang Xiwen It's already implemented in clk-mux.c, export it in the header file. Signed-off-by: Yang Xiwen --- include/linux/clk-provider.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h index b8acacd49e..801404480b 100644 --- a/include/linux/clk-provider.h +++ b/include/linux/clk-provider.h @@ -247,6 +247,12 @@ struct clk *clk_register_mux(struct device *dev, const char *name, void __iomem *reg, u8 shift, u8 width, u8 clk_mux_flags); +struct clk *clk_register_mux_table(struct device *dev, const char *name, + const char * const *parent_names, u8 num_parents, + unsigned long flags, + void __iomem *reg, u8 shift, u32 mask, + u8 clk_mux_flags, u32 *table); + struct clk *clk_register_fixed_rate(struct device *dev, const char *name, ulong rate); -- 2.34.1
[PATCH RESEND 0/5] clk: A few bugfixes/enhancements for CCF
They are found during my development for HiSilicon clock driver. Details are in commit logs. Signed-off-by: Yang Xiwen --- Yang Xiwen (5): clk: export clk_register_mux_table() clk: call log_debug() instead to avoid console log printing clk: also handle ENOENT in *_optional functions clk: promote clk_dev_ops to linux/clk-provider.h clk: ccf: call clock provided ops directly for endisable() drivers/clk/clk-uclass.c | 5 - drivers/clk/clk.c| 16 +--- include/clk.h| 8 +--- include/linux/clk-provider.h | 11 +++ 4 files changed, 29 insertions(+), 11 deletions(-) --- base-commit: 580eb31199be8a822e62f20965854a242f895d03 change-id: 20230807-clk-fix-17e895f79817 Best regards, -- Yang Xiwen
Re: Strange gitlab idea
Hi Tom, On Thu, 17 Aug 2023 at 09:10, Tom Rini wrote: > > On Thu, Aug 17, 2023 at 07:41:50AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Tue, 15 Aug 2023 at 08:56, Tom Rini wrote: > > > > > > On Tue, Aug 15, 2023 at 08:44:20AM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Sun, 13 Aug 2023 at 09:52, Tom Rini wrote: > > > > > > > > > > On Sat, Aug 12, 2023 at 09:14:45PM -0600, Simon Glass wrote: > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > I notice that the runners are not utilised much by the QEMU jobs, > > > > > > since we only run one at a time. > > > > > > > > > > > > I wonder if we could improve this, perhaps by using a different tag > > > > > > for the QEMU ones and then having a machine that only runs those > > > > > > (and > > > > > > runs 40 in parallel)? > > > > > > > > > > > > In general our use of the runners seems a bit primitive, since the > > > > > > main use of parallelism is in the world builds. > > > > > > > > > > I'm honestly not sure. I think there's a few tweaks that we should do, > > > > > like putting the opensbi and coreboot files in to the Dockerfile logic > > > > > instead. And maybe seeing if just like we can have a docker registry > > > > > cache, if we can setup local pypi cache too? I'm not otherwise sure > > > > > what's taking 23 seconds or so of > > > > > https://source.denx.de/u-boot/u-boot/-/jobs/673565#L34 since the build > > > > > and run parts aren't much. > > > > > > > > > > My first big worry about running 2 or 3 qemu jobs at the same time on > > > > > a > > > > > host is that any wins get from a shorter queue will be lost to > > > > > buildman > > > > > doing "make -j$(nproc)" 2 or 3 times at once and so we build slower. > > > > > > > > Yes, perhaps. > > > > > > > > > > > > > > My second big worry is that getting the right tags on runners will be > > > > > a > > > > > little tricky. > > > > > > > > Yes, and error-prone. Also it makes it harder to deal with broken > > > > machines. > > > > > > > > > > > > > > My third big worry (but this is something you can test easy enough at > > > > > least) is that running the big sandbox tests, 2 or 3 times at once on > > > > > the same host will get much slower. I think, but profiling would be > > > > > helpful, that those get slow due to I/O and not CPU. > > > > > > > > I suspect it would be fast enough. > > > > > > > > But actually the other problem is that I am not sure whether the jobs > > > > would have their own filesystem? > > > > > > Yes, they should be properly sandboxed. If you want to test some of > > > these ideas, I think the best path is to just un-register temproarily > > > (comment out the token in config.toml) some of your runners and then > > > register them with just the DM tree and experiment. > > > > OK thanks for the idea. I tried this on tui > > > > I used a 'concurrent = 10' and it got up to a load of 70 or so every > > now and then, but mostly it was much less. > > > > The whole run (of just the test.py stage) took 8 minutes, with > > 'sandbox with clang test' taking the longest. > > > > I'm not too sure what that tells us... > > Well, looking at > https://source.denx.de/u-boot/u-boot/-/pipelines/17391/builds the whole > run took 56 minutes, of which 46 minutes was on 32bit ARM world build. > And the longest test.py stage was sandbox without LTO at just under 8 > minutes. So I think trying to get more concurrency in this stage is > likely to be a wash in terms of overall CI run time. There is quite a lot of variability. Two of the machines take about 15mins to 32-bit ARM and another two take under 20mins, e.g.: https://source.denx.de/u-boot/custodians/u-boot-dm/-/jobs/676055 Perhaps we should reserve the big jobs for the fastest machines? But then what if they all go offline at once? Regards, Simon
Re: Doc style for method functions
On 16.08.23 19:47, Simon Glass wrote:
Hi Jonathan,
On Wed, 16 Aug 2023 at 11:15, Jonathan Corbet wrote:
Simon Glass writes:
Hi Jonathan,
I would like to do something like this:
struct part_driver {
/**
* get_info() - Get information about a partition
^ causes error
*
* @desc: Block device descriptor
* @part: Partition number (1 = first)
* @info: Returns partition information
*/
int (*get_info)(struct blk_desc *desc, int part, struct
disk_partition *info);
...
};
But this gives:
scripts/kernel-doc:292:
print STDERR "Incorrect use of kernel-doc format: $_";
Without the brackets on get_info() it works OK. What is the purpose of
that check, please?
That's how the kerneldoc syntax was defined, well before my time as the
maintainer. This could be relaxed, I guess, but one would have to look
at the parsing code to be sure that the right thing happens all the way
through the process. I'm not entirely sure it's worth it...
I see. It is inconsistent, since we use () after normal functions.
I think I can fix it just by removing that check.
Regards,
Simon
If the structure element in not a function pointer, we probably still
want to forbid adding parentheses. Just dropping the check might not be
the solution.
Best regards
Heinrich
Re: [PATCH 1/3] fdt: common API to populate kaslr seed
On 2023-08-15 10:46 a.m., Sean Edmond wrote: On 2023-08-15 7:44 a.m., Simon Glass wrote: Hi Sean, On Mon, 14 Aug 2023 at 13:12, Sean Edmond wrote: On 2023-08-12 6:09 a.m., Simon Glass wrote: Hi Sean, On Fri, 11 Aug 2023 at 11:14, Sean Edmond wrote: On 2023-08-09 6:49 p.m., Simon Glass wrote: Hi Sean, On Wed, 9 Aug 2023 at 16:35, Sean Edmond wrote: On 2023-08-08 7:03 p.m., Simon Glass wrote: Hi, On Fri, 4 Aug 2023 at 17:34, wrote: From: Dhananjay Phadke fdt_fixup_kaslr_seed() will update given FDT with random seed value. Source for random seed can be TPM or RNG driver in u-boot or sec firmware (ARM). Signed-off-by: Dhananjay Phadke --- arch/arm/cpu/armv8/sec_firmware.c | 32 +++ common/fdt_support.c | 31 ++ include/fdt_support.h | 3 +++ 3 files changed, 41 insertions(+), 25 deletions(-) We need to find a way to use the ofnode API here. diff --git a/arch/arm/cpu/armv8/sec_firmware.c b/arch/arm/cpu/armv8/sec_firmware.c index c0e8726346..84ba49924e 100644 --- a/arch/arm/cpu/armv8/sec_firmware.c +++ b/arch/arm/cpu/armv8/sec_firmware.c @@ -411,46 +411,28 @@ int sec_firmware_init(const void *sec_firmware_img, /* * fdt_fix_kaslr - Add kalsr-seed node in Device tree * @fdt: Device tree - * @eret: 0 in case of error, 1 for success + * @eret: 0 for success */ int fdt_fixup_kaslr(void *fdt) You could pass an oftree to this function, e.g. obtained with: oftree_from_fdt(fdt) The common API I added is fdt_fixup_kaslr_seed(), which was added to "common/fdt_support.c". There are 3 callers: sec_firmware_init()->fdt_fixup_kaslr_seed() do_kaslr_seed()->fdt_fixup_kaslr_seed() image_setup_libfdt()->fdt_tpm_kaslr_seed->fdt_fixup_kaslr_seed() I think the ask is to create a common API that uses the ofnode API. So, instead of fdt_fixup_kaslr_seed() I can create ofnode_fixup_kaslr_seed()? Where should it live? If you like you could add common/ofnode_support.c ? But it is OK to have it in the same file, I think. Are you also wanting the callers (eg. fdt_tpm_kaslr_seed, fdt_fixup_kaslr) to take oftree as input too? So far as you can go, yes. Also you may want to pass an ofnode (the root node) so that things can deal with adding their stuff to any node. Regards, Simon I re-worked the API to use the ofnode API and tested it on our board. I was required to explicitly enable CONFIG_OFNODE_MULTI_TREE in order for it to work. I have concerns this will create a breaking change for users of the kaslr fdt touch up. In our case, if CONFIG_OFNODE_MULTI_TREE isn't set, the control FDT gets touched up, not the kernel FDT as required. Everything runs to completion, but "/proc/device-tree/chosen/kaslr-seed" isn't present after boot. Am I missing something? Perhaps there's a way to modify the default value for CONFIG_OFNODE_MULTI_TREE to ensure this works out-of-the-box? Yes, perhaps we should enable this when fixups are used? Is there a way to tell? I don't think there's a way to tell unfortunately. Fixups are always called if OF_LIBFDT is enabled, and if an FDT is found during bootm. I'm having trouble understanding the intention of the current default for OFNODE_MULTI_TREE: default y if EVENT && !DM_DEV_READ_INLINE && !DM_INLINE_OFNODE Could we simplify to this? default y if !OF_LIVE I don't think it will build if inlining is used, but I can't remember... I wasn't able to break this by turning off DM_DEV_READ_INLINE, and enabling OFNODE_MULTI_TREE/SPL_DM_INLINE_OFNODE/TPL_DM_INLINE_OFNODE. Perhaps things have changes since this was created. The EVENT thing is because there is an of-fixup event, which was the original thing using ofnode fixups. I wonder what sort of size increment this will create with !OF_LIVE ? With default (OFNODE_MULTI_TREE is not set): textdatabssdechex filename 9380135536846752 1040133fdf05 u-boot/u-boot/u-boot With !OF_LIVE (OFNODE_MULTI_TREE is set with OFNODE_MULTI_TREE_MAX=4): seanedmond@ovlvm106:~/code/QEMU/qemu_uboot$ sizeu-boot/u-boot/u-boot textdatabssdechex filename 9390165536846752 1041136fe2f0 u-boot/u-boot/u-boot Sorry about the formatting... let's try that again. With default (OFNODE_MULTI_TREE is not set): text: 938013 data: 55368 bss:46752 dec: 1040133 hex: fdf05 With !OF_LIVE (OFNODE_MULTI_TREE is set with OFNODE_MULTI_TREE_MAX=4): text: 939016 data: 55368 bss: 46752 dec: 1041136 hex: fe2f0 Also, we should make it return an error when attempting to use a tree without that option enabled. I would expect oftree_ensure() to provide that? I'll add a check. OK thanks. Regards, Simon
Re: [PATCH] MAINTAINERS: Update UFS maintainer
On 17:39-20230817, Neha Malcom Francis wrote: > Dropping Faiz Abbas from the UFS maintainer list as his e-mail ID is no > longer valid. > > Adding Bhupesh Sharma who has been using this framework working on > Qualcomm Snapdragon SoCs as well as sending out fixes. > > Adding myself as well to support in reviewing and testing patches. > > Signed-off-by: Neha Malcom Francis > Cc: Bhupesh Sharma > Cc: Vignesh R > Cc: Nishnath Menon Thanks for mixing my name up, but other than that, for what ever it is worth.. Reviewed-by: Nishanth Menon > --- > Based on discussion: > https://lore.kernel.org/u-boot/CAH=2NtzyQgximynKuG45UUux715Du=wkkusm9-aqghcuzsw...@mail.gmail.com/ > > MAINTAINERS | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 77a8b0ac21..d19e1fd60b 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1585,7 +1585,8 @@ T: git > https://source.denx.de/u-boot/custodians/u-boot-ubi.git > F: drivers/mtd/ubi/ > > UFS > -M: Faiz Abbas > +M: Bhupesh Sharma > +M: Neha Malcom Francis > S: Maintained > F: drivers/ufs/ > > -- > 2.34.1 > -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: FIT Image not working in U-Boot
On Thu, 17 Aug 2023 at 16:51, Simon Glass wrote: > Hi Freddie, > > On Thu, 17 Aug 2023 at 09:02, Freddie wrote: > > > > > > > > On Thu, Aug 17, 2023 at 3:13 PM Simon Glass wrote: > >> > >> Hi Freddie, > >> > >> On Thu, 17 Aug 2023 at 07:57, Freddie wrote: > >> > > >> > > >> > > >> > On Thu, Aug 17, 2023 at 2:45 PM Simon Glass wrote: > >> >> > >> >> Hi Freddie, > >> >> > >> >> On Thu, 17 Aug 2023 at 07:39, Freddie wrote: > >> >> > > >> >> > > >> >> > > >> >> > On Thu, Aug 17, 2023 at 2:19 PM Simon Glass > wrote: > >> >> >> > >> >> >> Hi Freddie, > >> >> >> > >> >> >> On Thu, 17 Aug 2023 at 07:02, Freddie wrote: > >> >> >> > > >> >> >> > Hi Simon, > >> >> >> > > >> >> >> > I'm quite new to this so sorry for asking so many questions but > where do I run the 'dump_image -l' command and which code should I look > into adding print statements to? > >> >> >> > >> >> >> One thing is to add your reply at the bottom, not the top. > >> >> >> > >> >> >> Actually it is 'dumpimage -l file.fit' to list the contents of > your > >> >> >> fit file called 'file.fit'. The program is built in the tools/ > >> >> >> directory or your build, or you can > >> >> >> > >> >> >> I mean if you are completely stumped, go to where the error is > >> >> >> generated and add lots of debugging around it. This is > >> >> >> boot_get_kernel() which is in v2021.10 is in common/bootm.c - so > just > >> >> >> add lots of printf() stuff there, rebuild and run on the board > and see > >> >> >> if you can figure out what is wrong. From my side I am really not > >> >> >> sure. > >> >> >> > >> >> >> Feel free to share the FIT through a link if you like. > >> >> >> > >> >> >> Also, you could try using a simple FIT without the signature part. > >> >> >> > >> >> >> > > >> >> >> > I have also just looked into my .config file and this is the > contents: > >> >> >> > > >> >> >> > # > >> >> >> > # Automatically generated file; DO NOT EDIT. > >> >> >> > # U-Boot 2021.10 Configuration > >> >> >> > # > >> >> >> > > >> >> >> [..] > >> >> >> > >> >> >> > # > >> >> >> > # Boot images > >> >> >> > # > >> >> >> > # CONFIG_ANDROID_BOOT_IMAGE is not set > >> >> >> > CONFIG_FIT=y > >> >> >> > CONFIG_FIT_EXTERNAL_OFFSET=0x0 > >> >> >> > CONFIG_FIT_FULL_CHECK=y > >> >> >> > CONFIG_FIT_SIGNATURE=y > >> >> >> > CONFIG_FIT_SIGNATURE_MAX_SIZE=0x1000 > >> >> >> > # CONFIG_FIT_RSASSA_PSS is not set > >> >> >> > # CONFIG_FIT_CIPHER is not set > >> >> >> > # CONFIG_FIT_VERBOSE is not set > >> >> >> > # CONFIG_FIT_BEST_MATCH is not set > >> >> >> > CONFIG_FIT_PRINT=y > >> >> >> > # CONFIG_LEGACY_IMAGE_FORMAT is not set > >> >> >> > CONFIG_SUPPORT_RAW_INITRD=y > >> >> >> > CONFIG_OF_BOARD_SETUP=y > >> >> >> > # CONFIG_OF_SYSTEM_SETUP is not set > >> >> >> > # CONFIG_OF_STDOUT_VIA_ALIAS is not set > >> >> >> > CONFIG_SYS_EXTRA_OPTIONS="" > >> >> >> > CONFIG_HAVE_SYS_TEXT_BASE=y > >> >> >> > CONFIG_ARCH_FIXUP_FDT_MEMORY=y > >> >> >> > # CONFIG_CHROMEOS is not set > >> >> >> > # CONFIG_CHROMEOS_VBOOT is not set > >> >> >> > > >> >> >> [..] > >> >> >> > >> >> >> This has CONFIG_FIT and CONFIG_LEGACY_IMAGE_FORMAT is disabled > (since > >> >> >> you have signature verification on). > >> >> >> > >> >> >> Regards, > >> >> >> Simon > >> >> > > >> >> > > >> >> > Hi Simon, > >> >> > > >> >> > Thank you for your advice, I'll make sure to reply at the bottom > of the message from now on. > >> >> > > >> >> > I've run the dumpimage command and this was my output: > >> >> > root@freddie-pi-dev:/home/fit# ../optee/u-boot/tools/dumpimage -l > image.fit > >> >> > FIT description: RPi FIT Image > >> >> > Created: Thu Aug 3 15:47:15 2023 > >> >> > Image 0 (kernel-1) > >> >> > Description: default kernel > >> >> > Created: Thu Aug 3 15:47:15 2023 > >> >> > Type: Kernel Image > >> >> > Compression: uncompressed > >> >> > Data Size:20869632 Bytes = 20380.50 KiB = 19.90 MiB > >> >> > Architecture: AArch64 > >> >> > OS: Linux > >> >> > Load Address: 0x1200 > >> >> > Entry Point: 0x1200 > >> >> > Hash algo:sha1 > >> >> > Hash value: 08d43ed37129fa26e0f5f9d303a211b708c66783 > >> >> > Image 1 (tee-1) > >> >> > Description: atf > >> >> > Created: Thu Aug 3 15:47:15 2023 > >> >> > Type: Standalone Program > >> >> > Compression: uncompressed > >> >> > Data Size:1257464 Bytes = 1227.99 KiB = 1.20 MiB > >> >> > Architecture: AArch64 > >> >> > Load Address: 0x0840 > >> >> > Entry Point: 0x0840 > >> >> > Hash algo:sha1 > >> >> > Hash value: 4907d9c33098b2767cd6bc4bc9836f2f913464c7 > >> >> > Image 2 (fdt-1) > >> >> > Description: device tree > >> >> > Created: Thu Aug 3 15:47:15 2023 > >> >> > Type: Flat Device Tree > >> >> > Compression: uncompressed > >> >> > Data Size:32501 Bytes = 31.74 KiB = 0.03 MiB > >> >> > Architecture: AArch64 > >> >> > Load Address: 0x0100 > >> >> > Hash algo:sha1 > >> >> > Hash value:
Re: FIT Image not working in U-Boot
Hi Freddie, On Thu, 17 Aug 2023 at 09:02, Freddie wrote: > > > > On Thu, Aug 17, 2023 at 3:13 PM Simon Glass wrote: >> >> Hi Freddie, >> >> On Thu, 17 Aug 2023 at 07:57, Freddie wrote: >> > >> > >> > >> > On Thu, Aug 17, 2023 at 2:45 PM Simon Glass wrote: >> >> >> >> Hi Freddie, >> >> >> >> On Thu, 17 Aug 2023 at 07:39, Freddie wrote: >> >> > >> >> > >> >> > >> >> > On Thu, Aug 17, 2023 at 2:19 PM Simon Glass wrote: >> >> >> >> >> >> Hi Freddie, >> >> >> >> >> >> On Thu, 17 Aug 2023 at 07:02, Freddie wrote: >> >> >> > >> >> >> > Hi Simon, >> >> >> > >> >> >> > I'm quite new to this so sorry for asking so many questions but >> >> >> > where do I run the 'dump_image -l' command and which code should I >> >> >> > look into adding print statements to? >> >> >> >> >> >> One thing is to add your reply at the bottom, not the top. >> >> >> >> >> >> Actually it is 'dumpimage -l file.fit' to list the contents of your >> >> >> fit file called 'file.fit'. The program is built in the tools/ >> >> >> directory or your build, or you can >> >> >> >> >> >> I mean if you are completely stumped, go to where the error is >> >> >> generated and add lots of debugging around it. This is >> >> >> boot_get_kernel() which is in v2021.10 is in common/bootm.c - so just >> >> >> add lots of printf() stuff there, rebuild and run on the board and see >> >> >> if you can figure out what is wrong. From my side I am really not >> >> >> sure. >> >> >> >> >> >> Feel free to share the FIT through a link if you like. >> >> >> >> >> >> Also, you could try using a simple FIT without the signature part. >> >> >> >> >> >> > >> >> >> > I have also just looked into my .config file and this is the >> >> >> > contents: >> >> >> > >> >> >> > # >> >> >> > # Automatically generated file; DO NOT EDIT. >> >> >> > # U-Boot 2021.10 Configuration >> >> >> > # >> >> >> > >> >> >> [..] >> >> >> >> >> >> > # >> >> >> > # Boot images >> >> >> > # >> >> >> > # CONFIG_ANDROID_BOOT_IMAGE is not set >> >> >> > CONFIG_FIT=y >> >> >> > CONFIG_FIT_EXTERNAL_OFFSET=0x0 >> >> >> > CONFIG_FIT_FULL_CHECK=y >> >> >> > CONFIG_FIT_SIGNATURE=y >> >> >> > CONFIG_FIT_SIGNATURE_MAX_SIZE=0x1000 >> >> >> > # CONFIG_FIT_RSASSA_PSS is not set >> >> >> > # CONFIG_FIT_CIPHER is not set >> >> >> > # CONFIG_FIT_VERBOSE is not set >> >> >> > # CONFIG_FIT_BEST_MATCH is not set >> >> >> > CONFIG_FIT_PRINT=y >> >> >> > # CONFIG_LEGACY_IMAGE_FORMAT is not set >> >> >> > CONFIG_SUPPORT_RAW_INITRD=y >> >> >> > CONFIG_OF_BOARD_SETUP=y >> >> >> > # CONFIG_OF_SYSTEM_SETUP is not set >> >> >> > # CONFIG_OF_STDOUT_VIA_ALIAS is not set >> >> >> > CONFIG_SYS_EXTRA_OPTIONS="" >> >> >> > CONFIG_HAVE_SYS_TEXT_BASE=y >> >> >> > CONFIG_ARCH_FIXUP_FDT_MEMORY=y >> >> >> > # CONFIG_CHROMEOS is not set >> >> >> > # CONFIG_CHROMEOS_VBOOT is not set >> >> >> > >> >> >> [..] >> >> >> >> >> >> This has CONFIG_FIT and CONFIG_LEGACY_IMAGE_FORMAT is disabled (since >> >> >> you have signature verification on). >> >> >> >> >> >> Regards, >> >> >> Simon >> >> > >> >> > >> >> > Hi Simon, >> >> > >> >> > Thank you for your advice, I'll make sure to reply at the bottom of the >> >> > message from now on. >> >> > >> >> > I've run the dumpimage command and this was my output: >> >> > root@freddie-pi-dev:/home/fit# ../optee/u-boot/tools/dumpimage -l >> >> > image.fit >> >> > FIT description: RPi FIT Image >> >> > Created: Thu Aug 3 15:47:15 2023 >> >> > Image 0 (kernel-1) >> >> > Description: default kernel >> >> > Created: Thu Aug 3 15:47:15 2023 >> >> > Type: Kernel Image >> >> > Compression: uncompressed >> >> > Data Size:20869632 Bytes = 20380.50 KiB = 19.90 MiB >> >> > Architecture: AArch64 >> >> > OS: Linux >> >> > Load Address: 0x1200 >> >> > Entry Point: 0x1200 >> >> > Hash algo:sha1 >> >> > Hash value: 08d43ed37129fa26e0f5f9d303a211b708c66783 >> >> > Image 1 (tee-1) >> >> > Description: atf >> >> > Created: Thu Aug 3 15:47:15 2023 >> >> > Type: Standalone Program >> >> > Compression: uncompressed >> >> > Data Size:1257464 Bytes = 1227.99 KiB = 1.20 MiB >> >> > Architecture: AArch64 >> >> > Load Address: 0x0840 >> >> > Entry Point: 0x0840 >> >> > Hash algo:sha1 >> >> > Hash value: 4907d9c33098b2767cd6bc4bc9836f2f913464c7 >> >> > Image 2 (fdt-1) >> >> > Description: device tree >> >> > Created: Thu Aug 3 15:47:15 2023 >> >> > Type: Flat Device Tree >> >> > Compression: uncompressed >> >> > Data Size:32501 Bytes = 31.74 KiB = 0.03 MiB >> >> > Architecture: AArch64 >> >> > Load Address: 0x0100 >> >> > Hash algo:sha1 >> >> > Hash value: 1b5bb266752cb247d89245c63bd041acfa34c7c0 >> >> > Default Configuration: 'config-1' >> >> > Configuration 0 (config-1) >> >> > Description: default configuration >> >> > Kernel: kernel-1 >> >> > FDT: fdt-1 >> >> > Loadables:tee-1 >> >> > Sign algo:
[PATCH] tools: image-host: print error messages to stderr
The make by default cuts off the stdout output from external tools,
so all error messages from the image-host are not shown in a make
output. Besides that, it is a common approach to use stderr stream
for error messages.
Use stderr for all error messages in image-host.
Signed-off-by: Oleksandr Suvorov
---
tools/image-host.c | 202 -
1 file changed, 107 insertions(+), 95 deletions(-)
diff --git a/tools/image-host.c b/tools/image-host.c
index 4a24dee8153..ca4950312f9 100644
--- a/tools/image-host.c
+++ b/tools/image-host.c
@@ -38,9 +38,9 @@ static int fit_set_hash_value(void *fit, int noffset, uint8_t
*value,
ret = fdt_setprop(fit, noffset, FIT_VALUE_PROP, value, value_len);
if (ret) {
- printf("Can't set hash '%s' property for '%s' node(%s)\n",
- FIT_VALUE_PROP, fit_get_name(fit, noffset, NULL),
- fdt_strerror(ret));
+ fprintf(stderr, "Can't set hash '%s' property for '%s'
node(%s)\n",
+ FIT_VALUE_PROP, fit_get_name(fit, noffset, NULL),
+ fdt_strerror(ret));
return ret == -FDT_ERR_NOSPACE ? -ENOSPC : -EIO;
}
@@ -72,21 +72,23 @@ static int fit_image_process_hash(void *fit, const char
*image_name,
node_name = fit_get_name(fit, noffset, NULL);
if (fit_image_hash_get_algo(fit, noffset, )) {
- printf("Can't get hash algo property for '%s' hash node in '%s'
image node\n",
- node_name, image_name);
+ fprintf(stderr,
+ "Can't get hash algo property for '%s' hash node in
'%s' image node\n",
+ node_name, image_name);
return -ENOENT;
}
if (calculate_hash(data, size, algo, value, _len)) {
- printf("Unsupported hash algorithm (%s) for '%s' hash node in
'%s' image node\n",
- algo, node_name, image_name);
+ fprintf(stderr,
+ "Unsupported hash algorithm (%s) for '%s' hash node in
'%s' image node\n",
+ algo, node_name, image_name);
return -EPROTONOSUPPORT;
}
ret = fit_set_hash_value(fit, noffset, value, value_len);
if (ret) {
- printf("Can't set hash value for '%s' hash node in '%s' image
node\n",
- node_name, image_name);
+ fprintf(stderr, "Can't set hash value for '%s' hash node in
'%s' image node\n",
+ node_name, image_name);
return ret;
}
@@ -170,8 +172,9 @@ static int fit_image_setup_sig(struct image_sign_info *info,
node_name = fit_get_name(fit, noffset, NULL);
if (!algo_name) {
if (fit_image_hash_get_algo(fit, noffset, _name)) {
- printf("Can't get algo property for '%s' signature node
in '%s' image node\n",
- node_name, image_name);
+ fprintf(stderr,
+ "Can't get algo property for '%s' signature
node in '%s' image node\n",
+ node_name, image_name);
return -1;
}
}
@@ -191,8 +194,9 @@ static int fit_image_setup_sig(struct image_sign_info *info,
info->require_keys = require_keys;
info->engine_id = engine_id;
if (!info->checksum || !info->crypto) {
- printf("Unsupported signature algorithm (%s) for '%s' signature
node in '%s' image node\n",
- algo_name, node_name, image_name);
+ fprintf(stderr,
+ "Unsupported signature algorithm (%s) for '%s'
signature node in '%s' image node\n",
+ algo_name, node_name, image_name);
return -1;
}
@@ -241,8 +245,8 @@ static int fit_image_process_sig(const char *keydir, const
char *keyfile,
region.size = size;
ret = info.crypto->sign(, , 1, , _len);
if (ret) {
- printf("Failed to sign '%s' signature node in '%s' image node:
%d\n",
- node_name, image_name, ret);
+ fprintf(stderr, "Failed to sign '%s' signature node in '%s'
image node: %d\n",
+ node_name, image_name, ret);
/* We allow keys to be missing */
if (ret == -ENOENT)
@@ -255,8 +259,9 @@ static int fit_image_process_sig(const char *keydir, const
char *keyfile,
if (ret) {
if (ret == -FDT_ERR_NOSPACE)
return -ENOSPC;
- printf("Can't write signature for '%s' signature node in '%s'
conf node: %s\n",
- node_name, image_name, fdt_strerror(ret));
+ fprintf(stderr,
+ "Can't write signature for '%s' signature node in '%s'
conf node: %s\n",
+
Re: [PATCH v2 3/6] scripts/Makefile.lib: Embed capsule public key in platform's dtb
On Thu, Aug 17, 2023 at 11:18:53AM +0530, Sughosh Ganu wrote: > The EFI capsule authentication logic in u-boot expects the public key > in the form of an EFI Signature List(ESL) to be provided as part of > the platform's dtb. Currently, the embedding of the ESL file into the > dtb needs to be done manually. > > Add a target for generating a dtsi file which contains the signature > node with the ESL file included as a property under the signature > node. Include the dtsi file in the dtb. This brings the embedding of > the ESL in the dtb into the U-Boot build flow. > > The path to the ESL file is specified through the > CONFIG_EFI_CAPSULE_ESL_FILE symbol. > > Signed-off-by: Sughosh Ganu Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 5/9] board_f: Fix corruption of relocaddr
On Wed, Aug 16, 2023 at 09:16:05PM +0530, Devarsh Thakkar wrote:
> Hi Simon,
>
> On 15/08/23 20:14, Simon Glass wrote:
> > Hi Devarsh,
> >
> > On Tue, 15 Aug 2023 at 03:23, Devarsh Thakkar wrote:
> >>
> >> Hi Simon, Tom,
> >>
> >> On 15/08/23 04:13, Simon Glass wrote:
> >>> Hi Devarsh, Nikhil, Tom,
> >>>
> >>> On Wed, 9 Aug 2023 at 09:29, Bin Meng wrote:
>
> On Thu, Aug 3, 2023 at 7:03 PM Bin Meng wrote:
> >
> > On Thu, Aug 3, 2023 at 6:37 PM Bin Meng wrote:
> >>
> >> On Tue, Aug 1, 2023 at 12:00 AM Simon Glass wrote:
> >>>
> >>> When the video framebuffer comes from the bloblist, we should not
> >>> change
> >>> relocaddr to this address, since it interfers with the normal memory
> >>
> >> typo: interferes
> >>
> >>> allocation.
> >>>
> >>> This fixes a boot loop in qemu-x86_64
> >>>
> >>> Signed-off-by: Simon Glass
> >>> Fixes: 5bc610a7d9d ("common: board_f: Pass frame buffer info from SPL
> >>> to u-boot")
> >>> Suggested-by: Nikhil M Jain
> >>> ---
> >>>
> >>> Changes in v3:
> >>> - Reword the Kconfig help as suggested
> >>>
> >>> Changes in v2:
> >>> - Add a Kconfig as the suggested conditional did not work
> >>>
> >>> common/board_f.c | 3 ++-
> >>> drivers/video/Kconfig | 9 +
> >>> 2 files changed, 11 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/common/board_f.c b/common/board_f.c
> >>> index 7d2c380e91e..5173d0a0c2d 100644
> >>> --- a/common/board_f.c
> >>> +++ b/common/board_f.c
> >>> @@ -419,7 +419,8 @@ static int reserve_video(void)
> >>> if (!ho)
> >>> return log_msg_ret("blf", -ENOENT);
> >>> video_reserve_from_bloblist(ho);
> >>> - gd->relocaddr = ho->fb;
> >>> + if (IS_ENABLED(CONFIG_VIDEO_RESERVE_SPL))
> >>> + gd->relocaddr = ho->fb;
> >>> } else if (CONFIG_IS_ENABLED(VIDEO)) {
> >>> ulong addr;
> >>> int ret;
> >>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> >>> index b41dc60cec5..f2e56204d52 100644
> >>> --- a/drivers/video/Kconfig
> >>> +++ b/drivers/video/Kconfig
> >>> @@ -1106,6 +1106,15 @@ config SPL_VIDEO_REMOVE
> >>>if this option is enabled video driver will be removed at
> >>> the end of
> >>>SPL stage, beforeloading the next stage.
> >>>
> >>> +config VIDEO_RESERVE_SPL
> >>> + bool
> >>> + help
> >>> + This adjusts reserve_video() to redirect memory reservation
> >>> when it
> >>> + sees a video handoff blob (BLOBLISTT_U_BOOT_VIDEO). This
> >>> avoids the
> >>> + memory used for framebuffer from being allocated by U-Boot
> >>> proper,
> >>> + thus preventing any further memory reservations done by
> >>> U-Boot proper
> >>> + from overwriting the framebuffer.
> >>> +
> >>> if SPL_SPLASH_SCREEN
> >>>
> >>> config SPL_SPLASH_SCREEN_ALIGN
> >>
> >> Reviewed-by: Bin Meng
> >
> > applied to u-boot-x86, thanks!
>
> Dropped this one from the x86 queue per the discussion.
> >>>
> >>> I just wanted to come back to this discussion.
> >>>
> >>> Do we have an agreed way forward? Who is waiting for who?
> >>>
> >>
> >> I was waiting on feedback on
> >> https://lore.kernel.org/all/3b1e8005-f161-8058-13e7-3de2316aa...@ti.com/
> >> but per my opinion, I would prefer to go with "Approach 2" with a
> >> Kconfig as it looks simpler to me. It would look something like below :
> >>
> >> if (gd->relocaddr > (unsigned long)ho->fb) {
> >> ulong fb_reloc_gap = gd->relocaddr - gd->ho->fb;
> >>
> >> /* Relocate after framebuffer area if nearing too close to it */
> >> if (fb_reloc_gap < CONFIG_BLOBLIST_FB_RELOC_MIN_GAP)
> >> gd->relocaddr = ho->fb;
> >> }
> >>
> >> Regarding CONFIG_BLOBLIST_FB_RELOC_MIN_GAP
> >> -> This describes minimum gap to keep between framebuffer address and
> >> relocation address to avoid overlap when framebuffer address used by
> >> blob is below the current relocation address
> >>
> >> -> It would be selected as default when CONFIG_BLOBLIST is selected with
> >> default value set to 100Mb
> >>
> >> -> SoC specific Vendors can override this in their defconfigs to a
> >> custom value if they feel 100Mb is not enough
> >>
> >> Also probably we can have some debug/error prints in the code to show
> >> overlap happened (or is going happen) so that users can fine tune this
> >> Kconfig if they got it wrong at first place.
> >>
> >> I can re-spin updated patch if we are aligned on this,
> >> Kindly let me know your opinion.
> >
> > I'm just nervous about the whole idea, TBH. Perhaps I am missing some
> > documentation on how people are supposed to lay out
Re: [PATCH 2/5] scripts/Makefile.lib: Embed capsule public key in platform's dtb
On Thu, Aug 17, 2023 at 07:41:33AM -0600, Simon Glass wrote: > Hi Tom, > > On Wed, 16 Aug 2023 at 15:26, Tom Rini wrote: > > > > On Wed, Aug 16, 2023 at 09:58:42AM +0530, Sughosh Ganu wrote: > > > hi Simon, > > > > > > On Wed, 16 Aug 2023 at 00:09, Simon Glass wrote: > > > > > > > > Hi Sughosh, > > > > > > > > On Tue, 15 Aug 2023 at 10:26, Sughosh Ganu > > > > wrote: > > > > > > > > > > The EFI capsule authentication logic in u-boot expects the public key > > > > > in the form of an EFI Signature List(ESL) to be provided as part of > > > > > the platform's dtb. Currently, the embedding of the ESL file into the > > > > > dtb needs to be done manually. > > > > > > > > > > Add a target for generating a dtsi file which contains the signature > > > > > node with the ESL file included as a property under the signature > > > > > node. Include the dtsi file in the dtb. This brings the embedding of > > > > > the ESL in the dtb into the U-Boot build flow. > > > > > > > > > > The path to the ESL file is specified through the > > > > > CONFIG_EFI_CAPSULE_ESL_FILE symbol. > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > --- > > > > > Changes since RFC series: > > > > > * Remove the default value of the config symbol. > > > > > * s/include_files/dtsi_include_list > > > > > * Add all the dtsi files being included as dependency for the dtb > > > > > target. > > > > > > > > > > lib/efi_loader/Kconfig | 8 > > > > > lib/efi_loader/capsule_esl.dtsi.in | 11 +++ > > > > > scripts/Makefile.lib | 18 +- > > > > > 3 files changed, 36 insertions(+), 1 deletion(-) > > > > > create mode 100644 lib/efi_loader/capsule_esl.dtsi.in > > > > > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > > > index 9989e3f384..d20aaab6db 100644 > > > > > --- a/lib/efi_loader/Kconfig > > > > > +++ b/lib/efi_loader/Kconfig > > > > > @@ -272,6 +272,14 @@ config EFI_CAPSULE_MAX > > > > > Select the max capsule index value used for capsule report > > > > > variables. This value is used to create CapsuleMax variable. > > > > > > > > > > +config EFI_CAPSULE_ESL_FILE > > > > > + string "Path to the EFI Signature List File" > > > > > > > > Do we need this, or could we name it as we do with the .env file? It > > > > seems confusing to have to set this for each board - it might be > > > > better to have it in a defined location. > > > > > > The reason I put this is because I thought this gave the user the > > > flexibility to provide the location and name of the ESL. But I suppose > > > that the board directory would be a good location to expect this file. > > > Then this file can have a name like capsule_pub_key,esl. Tom, what are > > > your thoughts on this? > > > > I feel like an automatic name we can guess isn't likely how this will be > > used in the real world, so we should leave this as configurable. > > Are we expecting these files to end up in the source tree? Where would they > go? Yes, they should be board/vendor/common/whatever-vendor-uses-internally.esl or so. As I think I mentioned on IRC, in theory someone like Asus should be using the same file here for their rockchip-based tinker board and their x8664 based motherboards too. And it's a public key, not a private key. But we still need to ask here because a vendor may care more about "security" and so have the key /over/somewhere/else more than reproducible builds. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 2/6] scripts/Makefile.lib: Add dtsi include files as deps for building DTB
On Thu, Aug 17, 2023 at 11:18:52AM +0530, Sughosh Ganu wrote: > At the time of building the DTB, some dtsi files can be selected for > inclusion. Have these dtsi files as dependencies for the DTB > target. This also ensures generation or updating the dtsi files if > need be. > > Signed-off-by: Sughosh Ganu Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: Strange gitlab idea
On Thu, Aug 17, 2023 at 07:41:50AM -0600, Simon Glass wrote: > Hi Tom, > > On Tue, 15 Aug 2023 at 08:56, Tom Rini wrote: > > > > On Tue, Aug 15, 2023 at 08:44:20AM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Sun, 13 Aug 2023 at 09:52, Tom Rini wrote: > > > > > > > > On Sat, Aug 12, 2023 at 09:14:45PM -0600, Simon Glass wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > I notice that the runners are not utilised much by the QEMU jobs, > > > > > since we only run one at a time. > > > > > > > > > > I wonder if we could improve this, perhaps by using a different tag > > > > > for the QEMU ones and then having a machine that only runs those (and > > > > > runs 40 in parallel)? > > > > > > > > > > In general our use of the runners seems a bit primitive, since the > > > > > main use of parallelism is in the world builds. > > > > > > > > I'm honestly not sure. I think there's a few tweaks that we should do, > > > > like putting the opensbi and coreboot files in to the Dockerfile logic > > > > instead. And maybe seeing if just like we can have a docker registry > > > > cache, if we can setup local pypi cache too? I'm not otherwise sure > > > > what's taking 23 seconds or so of > > > > https://source.denx.de/u-boot/u-boot/-/jobs/673565#L34 since the build > > > > and run parts aren't much. > > > > > > > > My first big worry about running 2 or 3 qemu jobs at the same time on a > > > > host is that any wins get from a shorter queue will be lost to buildman > > > > doing "make -j$(nproc)" 2 or 3 times at once and so we build slower. > > > > > > Yes, perhaps. > > > > > > > > > > > My second big worry is that getting the right tags on runners will be a > > > > little tricky. > > > > > > Yes, and error-prone. Also it makes it harder to deal with broken > > > machines. > > > > > > > > > > > My third big worry (but this is something you can test easy enough at > > > > least) is that running the big sandbox tests, 2 or 3 times at once on > > > > the same host will get much slower. I think, but profiling would be > > > > helpful, that those get slow due to I/O and not CPU. > > > > > > I suspect it would be fast enough. > > > > > > But actually the other problem is that I am not sure whether the jobs > > > would have their own filesystem? > > > > Yes, they should be properly sandboxed. If you want to test some of > > these ideas, I think the best path is to just un-register temproarily > > (comment out the token in config.toml) some of your runners and then > > register them with just the DM tree and experiment. > > OK thanks for the idea. I tried this on tui > > I used a 'concurrent = 10' and it got up to a load of 70 or so every > now and then, but mostly it was much less. > > The whole run (of just the test.py stage) took 8 minutes, with > 'sandbox with clang test' taking the longest. > > I'm not too sure what that tells us... Well, looking at https://source.denx.de/u-boot/u-boot/-/pipelines/17391/builds the whole run took 56 minutes, of which 46 minutes was on 32bit ARM world build. And the longest test.py stage was sandbox without LTO at just under 8 minutes. So I think trying to get more concurrency in this stage is likely to be a wash in terms of overall CI run time. -- Tom signature.asc Description: PGP signature
Re: [PATCHv6 04/14] net/lwip: implement dhcp cmd
On Thu, Aug 17, 2023 at 08:55:17PM +0600, Maxim Uvarov wrote:
> On Thu, 17 Aug 2023 at 20:04, Peter Robinson wrote:
>
> > On Thu, Aug 17, 2023 at 2:46 PM Maxim Uvarov
> > wrote:
> > >
> > > On Mon, 14 Aug 2023 at 21:29, Tom Rini wrote:
> > >
> > > > On Mon, Aug 14, 2023 at 09:18:19PM +0600, Maxim Uvarov wrote:
> > > > > On Mon, 14 Aug 2023 at 20:21, Ilias Apalodimas <
> > > > ilias.apalodi...@linaro.org>
> > > > > wrote:
> > > > >
> > > > > > On Mon, Aug 14, 2023 at 07:32:43PM +0600, Maxim Uvarov wrote:
> > > > > > > Implement function for dhcp command with lwIP variant. Usage and
> > > > output
> > > > > > is
> > > > > > > the same as the original command. This code called by
> > compatibility
> > > > code
> > > > > > > between U-Boot and lwIP.
> > > > > >
> > > > > > Same as the dns command
> > > > > >
> > > > > > >
> > > > > > > Signed-off-by: Maxim Uvarov
> > > > > > > ---
> > > > > > > include/net/lwip.h | 10 +++
> > > > > > > net/lwip/Makefile | 1 +
> > > > > > > net/lwip/apps/dhcp/lwip-dhcp.c | 51
> > > > ++
> > > > > > > 3 files changed, 62 insertions(+)
> > > > > > > create mode 100644 net/lwip/apps/dhcp/lwip-dhcp.c
> > > > > > >
> > > > > > > diff --git a/include/net/lwip.h b/include/net/lwip.h
> > > > > > > index c83b5c8231..2f035280eb 100644
> > > > > > > --- a/include/net/lwip.h
> > > > > > > +++ b/include/net/lwip.h
> > > > > > > @@ -15,3 +15,13 @@ int do_lwip_dns(struct cmd_tbl *cmdtp, int
> > flag,
> > > > int
> > > > > > argc,
> > > > > > > * Other value < 0, if error
> > > > > > > */
> > > > > > > int ulwip_dns(char *name, char *varname);
> > > > > > > +
> > > > > > > +/*
> > > > > > > +* This function creates the DHCP request to obtain IP address.
> > If
> > > > DHCP
> > > > > > server
> > > > > >
> > > > > > Sphinx needs something more, please check the existing functions
> > > > > >
> > > > > > > +* returns file name, this file will be downloaded with tftp.
> > After
> > > > this
> > > > > > > +* function you need to invoke the polling loop to process
> > network
> > > > > > communication.
> > > > > > > +*
> > > > > > > +* Return: 0 if success
> > > > > > > +* Other value < 0, if error
> > > > > > > +*/
> > > > > > > +int ulwip_dhcp(void);
> > > > > > > diff --git a/net/lwip/Makefile b/net/lwip/Makefile
> > > > > > > index 6d2c00605b..59323fb325 100644
> > > > > > > --- a/net/lwip/Makefile
> > > > > > > +
> > > > > > > +static struct dhcp dhcp;
> > > > > > > +
> > > > > > > +static int ulwip_dhcp_tmo(void)
> > > > > > > +{
> > > > > > > + switch (dhcp.state) {
> > > > > > > + case DHCP_STATE_BOUND:
> > > > > > > + env_set("bootfile", dhcp.boot_file_name);
> > > > > > > + env_set("ipaddr",
> > ip4addr_ntoa(_ip_addr));
> > > > > > > + env_set("netmask",
> > > > ip4addr_ntoa(_sn_mask));
> > > > > > > + env_set("serverip",
> > > > ip4addr_ntoa(_ip_addr));
> > > > > > > + printf("DHCP client bound to address %s\n",
> > > > > > ip4addr_ntoa(_ip_addr));
> > > > > > > + break;
> > > > > > > + default:
> > > > > > > + return -1;
> > > > > > > + }
> > > > > > > +
> > > > > > > + return 0;
> > > > > > > +}
> > > > > > > +
> > > > > > > +int ulwip_dhcp(void)
> > > > > > > +{
> > > > > > > + int err;
> > > > > > > + struct netif *netif;
> > > > > > > +
> > > > > > > + ulwip_set_tmo(ulwip_dhcp_tmo);
> > > > > > > + netif = netif_get_by_index(1);
> > > > > >
> > > > > > What's (1)?
> > > > > >
> > > > > >
> > > > > Only one lwip netif is registered. 1 - here is the index of netif. I
> > > > don't
> > > > > think that there is any definition for that...
> > > > >
> > > >
> > > > And there's only ever going to be one interface (even if we have ipv4
> > > > and ipv60 ? If so, define it to something please, thanks.
> > > >
> > > > --
> > > > Tom
> > > >
> > >
> > > Yes, one interface has 2 addresses ipv4 and ipv6.
> >
> > What about a device like a router which may have multiple wired
> > ethernet interface?
>
> Yea, looks like we need lwip netif per U-Boots eth_devs. I did not yet
> support several eth devices, but it will be good to add this to not break
> existing functionality..
The general case ends up being if we have more than one interface,
ethact is what's used. I'm unsure off-hand if some of the fancier
networking-centric chipsets and devices have something more complex
setup in their stacks.
--
Tom
signature.asc
Description: PGP signature
Re: FIT Image not working in U-Boot
On Thu, Aug 17, 2023 at 3:13 PM Simon Glass wrote: > Hi Freddie, > > On Thu, 17 Aug 2023 at 07:57, Freddie wrote: > > > > > > > > On Thu, Aug 17, 2023 at 2:45 PM Simon Glass wrote: > >> > >> Hi Freddie, > >> > >> On Thu, 17 Aug 2023 at 07:39, Freddie wrote: > >> > > >> > > >> > > >> > On Thu, Aug 17, 2023 at 2:19 PM Simon Glass wrote: > >> >> > >> >> Hi Freddie, > >> >> > >> >> On Thu, 17 Aug 2023 at 07:02, Freddie wrote: > >> >> > > >> >> > Hi Simon, > >> >> > > >> >> > I'm quite new to this so sorry for asking so many questions but > where do I run the 'dump_image -l' command and which code should I look > into adding print statements to? > >> >> > >> >> One thing is to add your reply at the bottom, not the top. > >> >> > >> >> Actually it is 'dumpimage -l file.fit' to list the contents of your > >> >> fit file called 'file.fit'. The program is built in the tools/ > >> >> directory or your build, or you can > >> >> > >> >> I mean if you are completely stumped, go to where the error is > >> >> generated and add lots of debugging around it. This is > >> >> boot_get_kernel() which is in v2021.10 is in common/bootm.c - so just > >> >> add lots of printf() stuff there, rebuild and run on the board and > see > >> >> if you can figure out what is wrong. From my side I am really not > >> >> sure. > >> >> > >> >> Feel free to share the FIT through a link if you like. > >> >> > >> >> Also, you could try using a simple FIT without the signature part. > >> >> > >> >> > > >> >> > I have also just looked into my .config file and this is the > contents: > >> >> > > >> >> > # > >> >> > # Automatically generated file; DO NOT EDIT. > >> >> > # U-Boot 2021.10 Configuration > >> >> > # > >> >> > > >> >> [..] > >> >> > >> >> > # > >> >> > # Boot images > >> >> > # > >> >> > # CONFIG_ANDROID_BOOT_IMAGE is not set > >> >> > CONFIG_FIT=y > >> >> > CONFIG_FIT_EXTERNAL_OFFSET=0x0 > >> >> > CONFIG_FIT_FULL_CHECK=y > >> >> > CONFIG_FIT_SIGNATURE=y > >> >> > CONFIG_FIT_SIGNATURE_MAX_SIZE=0x1000 > >> >> > # CONFIG_FIT_RSASSA_PSS is not set > >> >> > # CONFIG_FIT_CIPHER is not set > >> >> > # CONFIG_FIT_VERBOSE is not set > >> >> > # CONFIG_FIT_BEST_MATCH is not set > >> >> > CONFIG_FIT_PRINT=y > >> >> > # CONFIG_LEGACY_IMAGE_FORMAT is not set > >> >> > CONFIG_SUPPORT_RAW_INITRD=y > >> >> > CONFIG_OF_BOARD_SETUP=y > >> >> > # CONFIG_OF_SYSTEM_SETUP is not set > >> >> > # CONFIG_OF_STDOUT_VIA_ALIAS is not set > >> >> > CONFIG_SYS_EXTRA_OPTIONS="" > >> >> > CONFIG_HAVE_SYS_TEXT_BASE=y > >> >> > CONFIG_ARCH_FIXUP_FDT_MEMORY=y > >> >> > # CONFIG_CHROMEOS is not set > >> >> > # CONFIG_CHROMEOS_VBOOT is not set > >> >> > > >> >> [..] > >> >> > >> >> This has CONFIG_FIT and CONFIG_LEGACY_IMAGE_FORMAT is disabled (since > >> >> you have signature verification on). > >> >> > >> >> Regards, > >> >> Simon > >> > > >> > > >> > Hi Simon, > >> > > >> > Thank you for your advice, I'll make sure to reply at the bottom of > the message from now on. > >> > > >> > I've run the dumpimage command and this was my output: > >> > root@freddie-pi-dev:/home/fit# ../optee/u-boot/tools/dumpimage -l > image.fit > >> > FIT description: RPi FIT Image > >> > Created: Thu Aug 3 15:47:15 2023 > >> > Image 0 (kernel-1) > >> > Description: default kernel > >> > Created: Thu Aug 3 15:47:15 2023 > >> > Type: Kernel Image > >> > Compression: uncompressed > >> > Data Size:20869632 Bytes = 20380.50 KiB = 19.90 MiB > >> > Architecture: AArch64 > >> > OS: Linux > >> > Load Address: 0x1200 > >> > Entry Point: 0x1200 > >> > Hash algo:sha1 > >> > Hash value: 08d43ed37129fa26e0f5f9d303a211b708c66783 > >> > Image 1 (tee-1) > >> > Description: atf > >> > Created: Thu Aug 3 15:47:15 2023 > >> > Type: Standalone Program > >> > Compression: uncompressed > >> > Data Size:1257464 Bytes = 1227.99 KiB = 1.20 MiB > >> > Architecture: AArch64 > >> > Load Address: 0x0840 > >> > Entry Point: 0x0840 > >> > Hash algo:sha1 > >> > Hash value: 4907d9c33098b2767cd6bc4bc9836f2f913464c7 > >> > Image 2 (fdt-1) > >> > Description: device tree > >> > Created: Thu Aug 3 15:47:15 2023 > >> > Type: Flat Device Tree > >> > Compression: uncompressed > >> > Data Size:32501 Bytes = 31.74 KiB = 0.03 MiB > >> > Architecture: AArch64 > >> > Load Address: 0x0100 > >> > Hash algo:sha1 > >> > Hash value: 1b5bb266752cb247d89245c63bd041acfa34c7c0 > >> > Default Configuration: 'config-1' > >> > Configuration 0 (config-1) > >> > Description: default configuration > >> > Kernel: kernel-1 > >> > FDT: fdt-1 > >> > Loadables:tee-1 > >> > Sign algo:sha1,rsa2048:dev > >> > Sign value: > >
Re: [PATCHv6 04/14] net/lwip: implement dhcp cmd
On Thu, 17 Aug 2023 at 20:04, Peter Robinson wrote:
> On Thu, Aug 17, 2023 at 2:46 PM Maxim Uvarov
> wrote:
> >
> > On Mon, 14 Aug 2023 at 21:29, Tom Rini wrote:
> >
> > > On Mon, Aug 14, 2023 at 09:18:19PM +0600, Maxim Uvarov wrote:
> > > > On Mon, 14 Aug 2023 at 20:21, Ilias Apalodimas <
> > > ilias.apalodi...@linaro.org>
> > > > wrote:
> > > >
> > > > > On Mon, Aug 14, 2023 at 07:32:43PM +0600, Maxim Uvarov wrote:
> > > > > > Implement function for dhcp command with lwIP variant. Usage and
> > > output
> > > > > is
> > > > > > the same as the original command. This code called by
> compatibility
> > > code
> > > > > > between U-Boot and lwIP.
> > > > >
> > > > > Same as the dns command
> > > > >
> > > > > >
> > > > > > Signed-off-by: Maxim Uvarov
> > > > > > ---
> > > > > > include/net/lwip.h | 10 +++
> > > > > > net/lwip/Makefile | 1 +
> > > > > > net/lwip/apps/dhcp/lwip-dhcp.c | 51
> > > ++
> > > > > > 3 files changed, 62 insertions(+)
> > > > > > create mode 100644 net/lwip/apps/dhcp/lwip-dhcp.c
> > > > > >
> > > > > > diff --git a/include/net/lwip.h b/include/net/lwip.h
> > > > > > index c83b5c8231..2f035280eb 100644
> > > > > > --- a/include/net/lwip.h
> > > > > > +++ b/include/net/lwip.h
> > > > > > @@ -15,3 +15,13 @@ int do_lwip_dns(struct cmd_tbl *cmdtp, int
> flag,
> > > int
> > > > > argc,
> > > > > > * Other value < 0, if error
> > > > > > */
> > > > > > int ulwip_dns(char *name, char *varname);
> > > > > > +
> > > > > > +/*
> > > > > > +* This function creates the DHCP request to obtain IP address.
> If
> > > DHCP
> > > > > server
> > > > >
> > > > > Sphinx needs something more, please check the existing functions
> > > > >
> > > > > > +* returns file name, this file will be downloaded with tftp.
> After
> > > this
> > > > > > +* function you need to invoke the polling loop to process
> network
> > > > > communication.
> > > > > > +*
> > > > > > +* Return: 0 if success
> > > > > > +* Other value < 0, if error
> > > > > > +*/
> > > > > > +int ulwip_dhcp(void);
> > > > > > diff --git a/net/lwip/Makefile b/net/lwip/Makefile
> > > > > > index 6d2c00605b..59323fb325 100644
> > > > > > --- a/net/lwip/Makefile
> > > > > > +
> > > > > > +static struct dhcp dhcp;
> > > > > > +
> > > > > > +static int ulwip_dhcp_tmo(void)
> > > > > > +{
> > > > > > + switch (dhcp.state) {
> > > > > > + case DHCP_STATE_BOUND:
> > > > > > + env_set("bootfile", dhcp.boot_file_name);
> > > > > > + env_set("ipaddr",
> ip4addr_ntoa(_ip_addr));
> > > > > > + env_set("netmask",
> > > ip4addr_ntoa(_sn_mask));
> > > > > > + env_set("serverip",
> > > ip4addr_ntoa(_ip_addr));
> > > > > > + printf("DHCP client bound to address %s\n",
> > > > > ip4addr_ntoa(_ip_addr));
> > > > > > + break;
> > > > > > + default:
> > > > > > + return -1;
> > > > > > + }
> > > > > > +
> > > > > > + return 0;
> > > > > > +}
> > > > > > +
> > > > > > +int ulwip_dhcp(void)
> > > > > > +{
> > > > > > + int err;
> > > > > > + struct netif *netif;
> > > > > > +
> > > > > > + ulwip_set_tmo(ulwip_dhcp_tmo);
> > > > > > + netif = netif_get_by_index(1);
> > > > >
> > > > > What's (1)?
> > > > >
> > > > >
> > > > Only one lwip netif is registered. 1 - here is the index of netif. I
> > > don't
> > > > think that there is any definition for that...
> > > >
> > >
> > > And there's only ever going to be one interface (even if we have ipv4
> > > and ipv60 ? If so, define it to something please, thanks.
> > >
> > > --
> > > Tom
> > >
> >
> > Yes, one interface has 2 addresses ipv4 and ipv6.
>
> What about a device like a router which may have multiple wired
> ethernet interface?
>
Yea, looks like we need lwip netif per U-Boots eth_devs. I did not yet
support several eth devices, but it will be good to add this to not break
existing functionality..
BR,
Maxim.
[PATCH] spl: provide weak empty stub for reset_cpu()
This stub needs to link SPL properly.
Signed-off-by: Oleksandr Suvorov
---
common/spl/spl.c | 8
1 file changed, 8 insertions(+)
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 0062f3f45d9..781858891b9 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -1026,3 +1026,11 @@ ulong bootcount_load(void)
return 0;
}
#endif
+
+/**
+ * Weak default function for board-specific reset. Provide empty stub only.
+ */
+__weak void reset_cpu(void)
+{
+ /* Nothing to do! */
+}
--
2.41.0
Re: Strange gitlab idea
Hi Tom, On Thu, 17 Aug 2023 at 07:41, Simon Glass wrote: > > Hi Tom, > > On Tue, 15 Aug 2023 at 08:56, Tom Rini wrote: > > > > On Tue, Aug 15, 2023 at 08:44:20AM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Sun, 13 Aug 2023 at 09:52, Tom Rini wrote: > > > > > > > > On Sat, Aug 12, 2023 at 09:14:45PM -0600, Simon Glass wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > I notice that the runners are not utilised much by the QEMU jobs, > > > > > since we only run one at a time. > > > > > > > > > > I wonder if we could improve this, perhaps by using a different tag > > > > > for the QEMU ones and then having a machine that only runs those (and > > > > > runs 40 in parallel)? > > > > > > > > > > In general our use of the runners seems a bit primitive, since the > > > > > main use of parallelism is in the world builds. > > > > > > > > I'm honestly not sure. I think there's a few tweaks that we should do, > > > > like putting the opensbi and coreboot files in to the Dockerfile logic > > > > instead. And maybe seeing if just like we can have a docker registry > > > > cache, if we can setup local pypi cache too? I'm not otherwise sure > > > > what's taking 23 seconds or so of > > > > https://source.denx.de/u-boot/u-boot/-/jobs/673565#L34 since the build > > > > and run parts aren't much. > > > > > > > > My first big worry about running 2 or 3 qemu jobs at the same time on a > > > > host is that any wins get from a shorter queue will be lost to buildman > > > > doing "make -j$(nproc)" 2 or 3 times at once and so we build slower. > > > > > > Yes, perhaps. > > > > > > > > > > > My second big worry is that getting the right tags on runners will be a > > > > little tricky. > > > > > > Yes, and error-prone. Also it makes it harder to deal with broken > > > machines. > > > > > > > > > > > My third big worry (but this is something you can test easy enough at > > > > least) is that running the big sandbox tests, 2 or 3 times at once on > > > > the same host will get much slower. I think, but profiling would be > > > > helpful, that those get slow due to I/O and not CPU. > > > > > > I suspect it would be fast enough. > > > > > > But actually the other problem is that I am not sure whether the jobs > > > would have their own filesystem? > > > > Yes, they should be properly sandboxed. If you want to test some of > > these ideas, I think the best path is to just un-register temproarily > > (comment out the token in config.toml) some of your runners and then > > register them with just the DM tree and experiment. > > OK thanks for the idea. I tried this on tui > > I used a 'concurrent = 10' and it got up to a load of 70 or so every > now and then, but mostly it was much less. > > The whole run (of just the test.py stage) took 8 minutes, with > 'sandbox with clang test' taking the longest. > > I'm not too sure what that tells us... After a bit more thought, perhaps we should: - Give everything except the world builds a special tag like 'single', meaning it is somewhat single-threaded - Adjust some runners to have a second registration which only accepts 'single' jobs, with a concurrency of 10, say - Consider running everything in a single stage That might be easy to maintain? Regards, Simon
Re: FIT Image not working in U-Boot
Hi Freddie, On Thu, 17 Aug 2023 at 07:57, Freddie wrote: > > > > On Thu, Aug 17, 2023 at 2:45 PM Simon Glass wrote: >> >> Hi Freddie, >> >> On Thu, 17 Aug 2023 at 07:39, Freddie wrote: >> > >> > >> > >> > On Thu, Aug 17, 2023 at 2:19 PM Simon Glass wrote: >> >> >> >> Hi Freddie, >> >> >> >> On Thu, 17 Aug 2023 at 07:02, Freddie wrote: >> >> > >> >> > Hi Simon, >> >> > >> >> > I'm quite new to this so sorry for asking so many questions but where >> >> > do I run the 'dump_image -l' command and which code should I look into >> >> > adding print statements to? >> >> >> >> One thing is to add your reply at the bottom, not the top. >> >> >> >> Actually it is 'dumpimage -l file.fit' to list the contents of your >> >> fit file called 'file.fit'. The program is built in the tools/ >> >> directory or your build, or you can >> >> >> >> I mean if you are completely stumped, go to where the error is >> >> generated and add lots of debugging around it. This is >> >> boot_get_kernel() which is in v2021.10 is in common/bootm.c - so just >> >> add lots of printf() stuff there, rebuild and run on the board and see >> >> if you can figure out what is wrong. From my side I am really not >> >> sure. >> >> >> >> Feel free to share the FIT through a link if you like. >> >> >> >> Also, you could try using a simple FIT without the signature part. >> >> >> >> > >> >> > I have also just looked into my .config file and this is the contents: >> >> > >> >> > # >> >> > # Automatically generated file; DO NOT EDIT. >> >> > # U-Boot 2021.10 Configuration >> >> > # >> >> > >> >> [..] >> >> >> >> > # >> >> > # Boot images >> >> > # >> >> > # CONFIG_ANDROID_BOOT_IMAGE is not set >> >> > CONFIG_FIT=y >> >> > CONFIG_FIT_EXTERNAL_OFFSET=0x0 >> >> > CONFIG_FIT_FULL_CHECK=y >> >> > CONFIG_FIT_SIGNATURE=y >> >> > CONFIG_FIT_SIGNATURE_MAX_SIZE=0x1000 >> >> > # CONFIG_FIT_RSASSA_PSS is not set >> >> > # CONFIG_FIT_CIPHER is not set >> >> > # CONFIG_FIT_VERBOSE is not set >> >> > # CONFIG_FIT_BEST_MATCH is not set >> >> > CONFIG_FIT_PRINT=y >> >> > # CONFIG_LEGACY_IMAGE_FORMAT is not set >> >> > CONFIG_SUPPORT_RAW_INITRD=y >> >> > CONFIG_OF_BOARD_SETUP=y >> >> > # CONFIG_OF_SYSTEM_SETUP is not set >> >> > # CONFIG_OF_STDOUT_VIA_ALIAS is not set >> >> > CONFIG_SYS_EXTRA_OPTIONS="" >> >> > CONFIG_HAVE_SYS_TEXT_BASE=y >> >> > CONFIG_ARCH_FIXUP_FDT_MEMORY=y >> >> > # CONFIG_CHROMEOS is not set >> >> > # CONFIG_CHROMEOS_VBOOT is not set >> >> > >> >> [..] >> >> >> >> This has CONFIG_FIT and CONFIG_LEGACY_IMAGE_FORMAT is disabled (since >> >> you have signature verification on). >> >> >> >> Regards, >> >> Simon >> > >> > >> > Hi Simon, >> > >> > Thank you for your advice, I'll make sure to reply at the bottom of the >> > message from now on. >> > >> > I've run the dumpimage command and this was my output: >> > root@freddie-pi-dev:/home/fit# ../optee/u-boot/tools/dumpimage -l image.fit >> > FIT description: RPi FIT Image >> > Created: Thu Aug 3 15:47:15 2023 >> > Image 0 (kernel-1) >> > Description: default kernel >> > Created: Thu Aug 3 15:47:15 2023 >> > Type: Kernel Image >> > Compression: uncompressed >> > Data Size:20869632 Bytes = 20380.50 KiB = 19.90 MiB >> > Architecture: AArch64 >> > OS: Linux >> > Load Address: 0x1200 >> > Entry Point: 0x1200 >> > Hash algo:sha1 >> > Hash value: 08d43ed37129fa26e0f5f9d303a211b708c66783 >> > Image 1 (tee-1) >> > Description: atf >> > Created: Thu Aug 3 15:47:15 2023 >> > Type: Standalone Program >> > Compression: uncompressed >> > Data Size:1257464 Bytes = 1227.99 KiB = 1.20 MiB >> > Architecture: AArch64 >> > Load Address: 0x0840 >> > Entry Point: 0x0840 >> > Hash algo:sha1 >> > Hash value: 4907d9c33098b2767cd6bc4bc9836f2f913464c7 >> > Image 2 (fdt-1) >> > Description: device tree >> > Created: Thu Aug 3 15:47:15 2023 >> > Type: Flat Device Tree >> > Compression: uncompressed >> > Data Size:32501 Bytes = 31.74 KiB = 0.03 MiB >> > Architecture: AArch64 >> > Load Address: 0x0100 >> > Hash algo:sha1 >> > Hash value: 1b5bb266752cb247d89245c63bd041acfa34c7c0 >> > Default Configuration: 'config-1' >> > Configuration 0 (config-1) >> > Description: default configuration >> > Kernel: kernel-1 >> > FDT: fdt-1 >> > Loadables:tee-1 >> > Sign algo:sha1,rsa2048:dev >> > Sign value: >> > 22cd61395ae659917626ef88ebf82429d6d592a7975cf48eb1e301f81c8f2a9ae60e203e283b8800971b72cd1b6bf93fb4f5f54d9bc4fb0f49ae0e48115ff087d8638f8080fdc9f72fbfdd2228d60dba33849a75dba6958a134eefb9441b43f6f8319b7885c052c7993a7c791fe0acc577a629b04630060f02e24e82f9e5c8851c0df3d63da45ee5daeeabe198b990c2b8cbe24834763df299d8ed5a25cb90818caa23676e764d4d6e91e852451c1dae8a2946b9741e637b7556b6ebf27fa9e0ad5252909d13da67179b40f5097cc29c4ac1539c0fb89b567e8ee2d56ef92707d2a9d82a090d35c66cf23e8e66e5c8da5e197ec4a0dd771ef4a3246f6f499850 >> >
Re: [PATCHv6 04/14] net/lwip: implement dhcp cmd
On Thu, Aug 17, 2023 at 2:46 PM Maxim Uvarov wrote:
>
> On Mon, 14 Aug 2023 at 21:29, Tom Rini wrote:
>
> > On Mon, Aug 14, 2023 at 09:18:19PM +0600, Maxim Uvarov wrote:
> > > On Mon, 14 Aug 2023 at 20:21, Ilias Apalodimas <
> > ilias.apalodi...@linaro.org>
> > > wrote:
> > >
> > > > On Mon, Aug 14, 2023 at 07:32:43PM +0600, Maxim Uvarov wrote:
> > > > > Implement function for dhcp command with lwIP variant. Usage and
> > output
> > > > is
> > > > > the same as the original command. This code called by compatibility
> > code
> > > > > between U-Boot and lwIP.
> > > >
> > > > Same as the dns command
> > > >
> > > > >
> > > > > Signed-off-by: Maxim Uvarov
> > > > > ---
> > > > > include/net/lwip.h | 10 +++
> > > > > net/lwip/Makefile | 1 +
> > > > > net/lwip/apps/dhcp/lwip-dhcp.c | 51
> > ++
> > > > > 3 files changed, 62 insertions(+)
> > > > > create mode 100644 net/lwip/apps/dhcp/lwip-dhcp.c
> > > > >
> > > > > diff --git a/include/net/lwip.h b/include/net/lwip.h
> > > > > index c83b5c8231..2f035280eb 100644
> > > > > --- a/include/net/lwip.h
> > > > > +++ b/include/net/lwip.h
> > > > > @@ -15,3 +15,13 @@ int do_lwip_dns(struct cmd_tbl *cmdtp, int flag,
> > int
> > > > argc,
> > > > > * Other value < 0, if error
> > > > > */
> > > > > int ulwip_dns(char *name, char *varname);
> > > > > +
> > > > > +/*
> > > > > +* This function creates the DHCP request to obtain IP address. If
> > DHCP
> > > > server
> > > >
> > > > Sphinx needs something more, please check the existing functions
> > > >
> > > > > +* returns file name, this file will be downloaded with tftp. After
> > this
> > > > > +* function you need to invoke the polling loop to process network
> > > > communication.
> > > > > +*
> > > > > +* Return: 0 if success
> > > > > +* Other value < 0, if error
> > > > > +*/
> > > > > +int ulwip_dhcp(void);
> > > > > diff --git a/net/lwip/Makefile b/net/lwip/Makefile
> > > > > index 6d2c00605b..59323fb325 100644
> > > > > --- a/net/lwip/Makefile
> > > > > +
> > > > > +static struct dhcp dhcp;
> > > > > +
> > > > > +static int ulwip_dhcp_tmo(void)
> > > > > +{
> > > > > + switch (dhcp.state) {
> > > > > + case DHCP_STATE_BOUND:
> > > > > + env_set("bootfile", dhcp.boot_file_name);
> > > > > + env_set("ipaddr", ip4addr_ntoa(_ip_addr));
> > > > > + env_set("netmask",
> > ip4addr_ntoa(_sn_mask));
> > > > > + env_set("serverip",
> > ip4addr_ntoa(_ip_addr));
> > > > > + printf("DHCP client bound to address %s\n",
> > > > ip4addr_ntoa(_ip_addr));
> > > > > + break;
> > > > > + default:
> > > > > + return -1;
> > > > > + }
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > +int ulwip_dhcp(void)
> > > > > +{
> > > > > + int err;
> > > > > + struct netif *netif;
> > > > > +
> > > > > + ulwip_set_tmo(ulwip_dhcp_tmo);
> > > > > + netif = netif_get_by_index(1);
> > > >
> > > > What's (1)?
> > > >
> > > >
> > > Only one lwip netif is registered. 1 - here is the index of netif. I
> > don't
> > > think that there is any definition for that...
> > >
> >
> > And there's only ever going to be one interface (even if we have ipv4
> > and ipv60 ? If so, define it to something please, thanks.
> >
> > --
> > Tom
> >
>
> Yes, one interface has 2 addresses ipv4 and ipv6.
What about a device like a router which may have multiple wired
ethernet interface?
Re: FIT Image not working in U-Boot
On Thu, Aug 17, 2023 at 2:45 PM Simon Glass wrote: > Hi Freddie, > > On Thu, 17 Aug 2023 at 07:39, Freddie wrote: > > > > > > > > On Thu, Aug 17, 2023 at 2:19 PM Simon Glass wrote: > >> > >> Hi Freddie, > >> > >> On Thu, 17 Aug 2023 at 07:02, Freddie wrote: > >> > > >> > Hi Simon, > >> > > >> > I'm quite new to this so sorry for asking so many questions but where > do I run the 'dump_image -l' command and which code should I look into > adding print statements to? > >> > >> One thing is to add your reply at the bottom, not the top. > >> > >> Actually it is 'dumpimage -l file.fit' to list the contents of your > >> fit file called 'file.fit'. The program is built in the tools/ > >> directory or your build, or you can > >> > >> I mean if you are completely stumped, go to where the error is > >> generated and add lots of debugging around it. This is > >> boot_get_kernel() which is in v2021.10 is in common/bootm.c - so just > >> add lots of printf() stuff there, rebuild and run on the board and see > >> if you can figure out what is wrong. From my side I am really not > >> sure. > >> > >> Feel free to share the FIT through a link if you like. > >> > >> Also, you could try using a simple FIT without the signature part. > >> > >> > > >> > I have also just looked into my .config file and this is the contents: > >> > > >> > # > >> > # Automatically generated file; DO NOT EDIT. > >> > # U-Boot 2021.10 Configuration > >> > # > >> > > >> [..] > >> > >> > # > >> > # Boot images > >> > # > >> > # CONFIG_ANDROID_BOOT_IMAGE is not set > >> > CONFIG_FIT=y > >> > CONFIG_FIT_EXTERNAL_OFFSET=0x0 > >> > CONFIG_FIT_FULL_CHECK=y > >> > CONFIG_FIT_SIGNATURE=y > >> > CONFIG_FIT_SIGNATURE_MAX_SIZE=0x1000 > >> > # CONFIG_FIT_RSASSA_PSS is not set > >> > # CONFIG_FIT_CIPHER is not set > >> > # CONFIG_FIT_VERBOSE is not set > >> > # CONFIG_FIT_BEST_MATCH is not set > >> > CONFIG_FIT_PRINT=y > >> > # CONFIG_LEGACY_IMAGE_FORMAT is not set > >> > CONFIG_SUPPORT_RAW_INITRD=y > >> > CONFIG_OF_BOARD_SETUP=y > >> > # CONFIG_OF_SYSTEM_SETUP is not set > >> > # CONFIG_OF_STDOUT_VIA_ALIAS is not set > >> > CONFIG_SYS_EXTRA_OPTIONS="" > >> > CONFIG_HAVE_SYS_TEXT_BASE=y > >> > CONFIG_ARCH_FIXUP_FDT_MEMORY=y > >> > # CONFIG_CHROMEOS is not set > >> > # CONFIG_CHROMEOS_VBOOT is not set > >> > > >> [..] > >> > >> This has CONFIG_FIT and CONFIG_LEGACY_IMAGE_FORMAT is disabled (since > >> you have signature verification on). > >> > >> Regards, > >> Simon > > > > > > Hi Simon, > > > > Thank you for your advice, I'll make sure to reply at the bottom of the > message from now on. > > > > I've run the dumpimage command and this was my output: > > root@freddie-pi-dev:/home/fit# ../optee/u-boot/tools/dumpimage -l > image.fit > > FIT description: RPi FIT Image > > Created: Thu Aug 3 15:47:15 2023 > > Image 0 (kernel-1) > > Description: default kernel > > Created: Thu Aug 3 15:47:15 2023 > > Type: Kernel Image > > Compression: uncompressed > > Data Size:20869632 Bytes = 20380.50 KiB = 19.90 MiB > > Architecture: AArch64 > > OS: Linux > > Load Address: 0x1200 > > Entry Point: 0x1200 > > Hash algo:sha1 > > Hash value: 08d43ed37129fa26e0f5f9d303a211b708c66783 > > Image 1 (tee-1) > > Description: atf > > Created: Thu Aug 3 15:47:15 2023 > > Type: Standalone Program > > Compression: uncompressed > > Data Size:1257464 Bytes = 1227.99 KiB = 1.20 MiB > > Architecture: AArch64 > > Load Address: 0x0840 > > Entry Point: 0x0840 > > Hash algo:sha1 > > Hash value: 4907d9c33098b2767cd6bc4bc9836f2f913464c7 > > Image 2 (fdt-1) > > Description: device tree > > Created: Thu Aug 3 15:47:15 2023 > > Type: Flat Device Tree > > Compression: uncompressed > > Data Size:32501 Bytes = 31.74 KiB = 0.03 MiB > > Architecture: AArch64 > > Load Address: 0x0100 > > Hash algo:sha1 > > Hash value: 1b5bb266752cb247d89245c63bd041acfa34c7c0 > > Default Configuration: 'config-1' > > Configuration 0 (config-1) > > Description: default configuration > > Kernel: kernel-1 > > FDT: fdt-1 > > Loadables:tee-1 > > Sign algo:sha1,rsa2048:dev > > Sign value: > > 22cd61395ae659917626ef88ebf82429d6d592a7975cf48eb1e301f81c8f2a9ae60e203e283b8800971b72cd1b6bf93fb4f5f54d9bc4fb0f49ae0e48115ff087d8638f8080fdc9f72fbfdd2228d60dba33849a75dba6958a134eefb9441b43f6f8319b7885c052c7993a7c791fe0acc577a629b04630060f02e24e82f9e5c8851c0df3d63da45ee5daeeabe198b990c2b8cbe24834763df299d8ed5a25cb90818caa23676e764d4d6e91e852451c1dae8a2946b9741e637b7556b6ebf27fa9e0ad5252909d13da67179b40f5097cc29c4ac1539c0fb89b567e8ee2d56ef92707d2a9d82a090d35c66cf23e8e66e5c8da5e197ec4a0dd771ef4a3246f6f499850 > > Timestamp:Thu Aug 3 15:47:15 2023 > > > > That looks fine > > > > > I have tried to use an unsigned FIT before, but I also ran into the same > error. In this case, do I simply disable the signature parts of
[PATCH 1/1] Documentation extended with specific information for VirtualBox
From: Thomas Mittelstaedt
Signed-off-by: Thomas Mittelstaedt
---
doc/develop/uefi/u-boot_on_efi.rst | 76 ++
1 file changed, 76 insertions(+)
diff --git a/doc/develop/uefi/u-boot_on_efi.rst
b/doc/develop/uefi/u-boot_on_efi.rst
index acad6397e8..927e1dc266 100644
--- a/doc/develop/uefi/u-boot_on_efi.rst
+++ b/doc/develop/uefi/u-boot_on_efi.rst
@@ -254,6 +254,82 @@ This shows running with serial enabled (see
`include/configs/efi-x86_app.h`)::
=> QEMU: Terminated
+Run at VirtualBox (x86)
+--
+
+Enable EFI
+
+At settings for virtual machine the flag at **System->Motherboard->Enable EFI
(special OSes only)** has to be enabled.
+
+Installation
+
+Install the needed system at a VDI disk and connect this to SATA controller
(type AHCI) at settings
+for virtual machine at **System->Storage->Controller:SATA**.
+
+For the following description 3 partitions are assumed:
+
+- Partition 1: formatted as **vfat**, used for U-Boot and and its environment
filesenvironment, flag **boot** set
+- Partition 2: formatted as **ext2/ext4**, used for Linux image and boot
configuration, flag **boot** set
+- Partition 3: formatted as **ext4**, used for root file system
+
+Create an extlinux.conf or a boot script
+
+
+Following files are assumed to be located at system for boot configuration::
+
+ Partition FileComment
+ 1 EFI/BOOT/BOOTX64.efi# renamed U-Boot EFI image
+ 2 Image # Linux image
+ 2 Initrd # Initramfs of Linux
+
+Boot script
+~~~
+
+The boot script **boot.scr** is assumed to be located at::
+
+ Partition FileComment
+ 2 boot.scr# Boot script, generated with mkimage from template
+
+Content of **boot.scr**:
+
+.. code-block:: bash
+
+ ext4load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r}
${prefix}Image
+ setenv kernel_size ${filesize}
+ ext4load ${devtype} ${devnum}:${distro_bootpart} ${ramdisk_addr_r}
${prefix}Initrd
+ setenv initrd_size ${filesize}
+ zboot ${kernel_addr_r} ${kernel_size} ${ramdisk_addr_r} ${initrd_size}
+
+Extlinux configuration
+~~
+
+Alternatively a configuration **extlinux.conf** can be used. **extlinux.conf**
is assumed to be located at::
+
+ Partition FileComment
+ 2 extlinux/extlinux.conf # Extlinux boot configuration
+
+Content of **extlinux.conf**:
+
+.. code-block:: bash
+
+ default l0
+ menu title U-Boot menu
+ prompt 0
+ timeout 50
+
+ label l0
+menu label Linux
+linux /Image
+initrd /Initrd
+
+
+Additionally something like (sda is assumed as disk device):
+
+.. code-block:: bash
+
+ append root=/dev/sda3 console=tty0 console=ttyS0,115200n8 rootwait rw
+
+
Future work
---
--
2.30.2
[PATCH 0/1] *** Documentation to set up U-Boot with VirtualBox ***
From: Thomas Mittelstaedt This documentation explains concrete steps to install and run U-Boot at VirtualBox with x86 images. Thomas Mittelstaedt (1): Documentation extended with specific information for VirtualBox doc/develop/uefi/u-boot_on_efi.rst | 76 ++ 1 file changed, 76 insertions(+) -- 2.30.2
Re: [PATCHv6 04/14] net/lwip: implement dhcp cmd
On Mon, 14 Aug 2023 at 21:29, Tom Rini wrote:
> On Mon, Aug 14, 2023 at 09:18:19PM +0600, Maxim Uvarov wrote:
> > On Mon, 14 Aug 2023 at 20:21, Ilias Apalodimas <
> ilias.apalodi...@linaro.org>
> > wrote:
> >
> > > On Mon, Aug 14, 2023 at 07:32:43PM +0600, Maxim Uvarov wrote:
> > > > Implement function for dhcp command with lwIP variant. Usage and
> output
> > > is
> > > > the same as the original command. This code called by compatibility
> code
> > > > between U-Boot and lwIP.
> > >
> > > Same as the dns command
> > >
> > > >
> > > > Signed-off-by: Maxim Uvarov
> > > > ---
> > > > include/net/lwip.h | 10 +++
> > > > net/lwip/Makefile | 1 +
> > > > net/lwip/apps/dhcp/lwip-dhcp.c | 51
> ++
> > > > 3 files changed, 62 insertions(+)
> > > > create mode 100644 net/lwip/apps/dhcp/lwip-dhcp.c
> > > >
> > > > diff --git a/include/net/lwip.h b/include/net/lwip.h
> > > > index c83b5c8231..2f035280eb 100644
> > > > --- a/include/net/lwip.h
> > > > +++ b/include/net/lwip.h
> > > > @@ -15,3 +15,13 @@ int do_lwip_dns(struct cmd_tbl *cmdtp, int flag,
> int
> > > argc,
> > > > * Other value < 0, if error
> > > > */
> > > > int ulwip_dns(char *name, char *varname);
> > > > +
> > > > +/*
> > > > +* This function creates the DHCP request to obtain IP address. If
> DHCP
> > > server
> > >
> > > Sphinx needs something more, please check the existing functions
> > >
> > > > +* returns file name, this file will be downloaded with tftp. After
> this
> > > > +* function you need to invoke the polling loop to process network
> > > communication.
> > > > +*
> > > > +* Return: 0 if success
> > > > +* Other value < 0, if error
> > > > +*/
> > > > +int ulwip_dhcp(void);
> > > > diff --git a/net/lwip/Makefile b/net/lwip/Makefile
> > > > index 6d2c00605b..59323fb325 100644
> > > > --- a/net/lwip/Makefile
> > > > +
> > > > +static struct dhcp dhcp;
> > > > +
> > > > +static int ulwip_dhcp_tmo(void)
> > > > +{
> > > > + switch (dhcp.state) {
> > > > + case DHCP_STATE_BOUND:
> > > > + env_set("bootfile", dhcp.boot_file_name);
> > > > + env_set("ipaddr", ip4addr_ntoa(_ip_addr));
> > > > + env_set("netmask",
> ip4addr_ntoa(_sn_mask));
> > > > + env_set("serverip",
> ip4addr_ntoa(_ip_addr));
> > > > + printf("DHCP client bound to address %s\n",
> > > ip4addr_ntoa(_ip_addr));
> > > > + break;
> > > > + default:
> > > > + return -1;
> > > > + }
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +int ulwip_dhcp(void)
> > > > +{
> > > > + int err;
> > > > + struct netif *netif;
> > > > +
> > > > + ulwip_set_tmo(ulwip_dhcp_tmo);
> > > > + netif = netif_get_by_index(1);
> > >
> > > What's (1)?
> > >
> > >
> > Only one lwip netif is registered. 1 - here is the index of netif. I
> don't
> > think that there is any definition for that...
> >
>
> And there's only ever going to be one interface (even if we have ipv4
> and ipv60 ? If so, define it to something please, thanks.
>
> --
> Tom
>
Yes, one interface has 2 addresses ipv4 and ipv6.
Re: FIT Image not working in U-Boot
Hi Freddie, On Thu, 17 Aug 2023 at 07:39, Freddie wrote: > > > > On Thu, Aug 17, 2023 at 2:19 PM Simon Glass wrote: >> >> Hi Freddie, >> >> On Thu, 17 Aug 2023 at 07:02, Freddie wrote: >> > >> > Hi Simon, >> > >> > I'm quite new to this so sorry for asking so many questions but where do I >> > run the 'dump_image -l' command and which code should I look into adding >> > print statements to? >> >> One thing is to add your reply at the bottom, not the top. >> >> Actually it is 'dumpimage -l file.fit' to list the contents of your >> fit file called 'file.fit'. The program is built in the tools/ >> directory or your build, or you can >> >> I mean if you are completely stumped, go to where the error is >> generated and add lots of debugging around it. This is >> boot_get_kernel() which is in v2021.10 is in common/bootm.c - so just >> add lots of printf() stuff there, rebuild and run on the board and see >> if you can figure out what is wrong. From my side I am really not >> sure. >> >> Feel free to share the FIT through a link if you like. >> >> Also, you could try using a simple FIT without the signature part. >> >> > >> > I have also just looked into my .config file and this is the contents: >> > >> > # >> > # Automatically generated file; DO NOT EDIT. >> > # U-Boot 2021.10 Configuration >> > # >> > >> [..] >> >> > # >> > # Boot images >> > # >> > # CONFIG_ANDROID_BOOT_IMAGE is not set >> > CONFIG_FIT=y >> > CONFIG_FIT_EXTERNAL_OFFSET=0x0 >> > CONFIG_FIT_FULL_CHECK=y >> > CONFIG_FIT_SIGNATURE=y >> > CONFIG_FIT_SIGNATURE_MAX_SIZE=0x1000 >> > # CONFIG_FIT_RSASSA_PSS is not set >> > # CONFIG_FIT_CIPHER is not set >> > # CONFIG_FIT_VERBOSE is not set >> > # CONFIG_FIT_BEST_MATCH is not set >> > CONFIG_FIT_PRINT=y >> > # CONFIG_LEGACY_IMAGE_FORMAT is not set >> > CONFIG_SUPPORT_RAW_INITRD=y >> > CONFIG_OF_BOARD_SETUP=y >> > # CONFIG_OF_SYSTEM_SETUP is not set >> > # CONFIG_OF_STDOUT_VIA_ALIAS is not set >> > CONFIG_SYS_EXTRA_OPTIONS="" >> > CONFIG_HAVE_SYS_TEXT_BASE=y >> > CONFIG_ARCH_FIXUP_FDT_MEMORY=y >> > # CONFIG_CHROMEOS is not set >> > # CONFIG_CHROMEOS_VBOOT is not set >> > >> [..] >> >> This has CONFIG_FIT and CONFIG_LEGACY_IMAGE_FORMAT is disabled (since >> you have signature verification on). >> >> Regards, >> Simon > > > Hi Simon, > > Thank you for your advice, I'll make sure to reply at the bottom of the > message from now on. > > I've run the dumpimage command and this was my output: > root@freddie-pi-dev:/home/fit# ../optee/u-boot/tools/dumpimage -l image.fit > FIT description: RPi FIT Image > Created: Thu Aug 3 15:47:15 2023 > Image 0 (kernel-1) > Description: default kernel > Created: Thu Aug 3 15:47:15 2023 > Type: Kernel Image > Compression: uncompressed > Data Size:20869632 Bytes = 20380.50 KiB = 19.90 MiB > Architecture: AArch64 > OS: Linux > Load Address: 0x1200 > Entry Point: 0x1200 > Hash algo:sha1 > Hash value: 08d43ed37129fa26e0f5f9d303a211b708c66783 > Image 1 (tee-1) > Description: atf > Created: Thu Aug 3 15:47:15 2023 > Type: Standalone Program > Compression: uncompressed > Data Size:1257464 Bytes = 1227.99 KiB = 1.20 MiB > Architecture: AArch64 > Load Address: 0x0840 > Entry Point: 0x0840 > Hash algo:sha1 > Hash value: 4907d9c33098b2767cd6bc4bc9836f2f913464c7 > Image 2 (fdt-1) > Description: device tree > Created: Thu Aug 3 15:47:15 2023 > Type: Flat Device Tree > Compression: uncompressed > Data Size:32501 Bytes = 31.74 KiB = 0.03 MiB > Architecture: AArch64 > Load Address: 0x0100 > Hash algo:sha1 > Hash value: 1b5bb266752cb247d89245c63bd041acfa34c7c0 > Default Configuration: 'config-1' > Configuration 0 (config-1) > Description: default configuration > Kernel: kernel-1 > FDT: fdt-1 > Loadables:tee-1 > Sign algo:sha1,rsa2048:dev > Sign value: > 22cd61395ae659917626ef88ebf82429d6d592a7975cf48eb1e301f81c8f2a9ae60e203e283b8800971b72cd1b6bf93fb4f5f54d9bc4fb0f49ae0e48115ff087d8638f8080fdc9f72fbfdd2228d60dba33849a75dba6958a134eefb9441b43f6f8319b7885c052c7993a7c791fe0acc577a629b04630060f02e24e82f9e5c8851c0df3d63da45ee5daeeabe198b990c2b8cbe24834763df299d8ed5a25cb90818caa23676e764d4d6e91e852451c1dae8a2946b9741e637b7556b6ebf27fa9e0ad5252909d13da67179b40f5097cc29c4ac1539c0fb89b567e8ee2d56ef92707d2a9d82a090d35c66cf23e8e66e5c8da5e197ec4a0dd771ef4a3246f6f499850 > Timestamp:Thu Aug 3 15:47:15 2023 > That looks fine > > I have tried to use an unsigned FIT before, but I also ran into the same > error. In this case, do I simply disable the signature parts of the config, > enable the legacy image format option and make the new image without any of > the signing or are there other changes as well? Well no point in trying it then...you can normally just omit the signing step. > > Where would be an appropriate place to upload my FIT file to in order to > share
Re: [PATCH 3/5] common: Add OS anti-rollback validation using security devices
Hi Sean,
On Fri, 11 Aug 2023 at 18:28, wrote:
>
> From: Stephen Carlson
>
> New config CONFIG_ARBP to enable enforcement of OS anti-rollback counter
> during image loading.
>
> Images with an anti-rollback counter value "arbvn" declared in the FDT will
> be compared against the current device anti-rollback counter value, and
> older images will not pass signature validation. If the image is newer, the
> device anti-rollback counter value will be updated.
>
> Signed-off-by: Stephen Carlson
> ---
> boot/Kconfig | 9 +
> boot/image-fit-sig.c | 89
> boot/image-fit.c | 23
> include/image.h | 4 ++
> 4 files changed, 125 insertions(+)
>
> diff --git a/boot/Kconfig b/boot/Kconfig
> index e8fb03b801..e08c274b7c 100644
> --- a/boot/Kconfig
> +++ b/boot/Kconfig
> @@ -103,6 +103,15 @@ config FIT_CIPHER
> Enable the feature of data ciphering/unciphering in the tool mkimage
> and in the u-boot support of the FIT image.
>
> +config FIT_ARBP
FIT_ROLLBACK would be better
arbp is really horrible :-)
> + bool "Enable Anti rollback version check for FIT images"
> + depends on FIT_SIGNATURE
> + default n
> + help
> + Enables FIT image anti-rollback protection. This feature is required
> + when a platform needs to retire previous versions of FIT images due
> to
> + security flaws and prevent devices from being reverted to them.
> +
> config FIT_VERBOSE
> bool "Show verbose messages when FIT images fail"
> depends on FIT
> diff --git a/boot/image-fit-sig.c b/boot/image-fit-sig.c
> index 12369896fe..bf3b81a3a3 100644
> --- a/boot/image-fit-sig.c
> +++ b/boot/image-fit-sig.c
> @@ -11,6 +11,8 @@
> #include
> #include
> #include
> +#include
> +#include
You don't need dm- in your headerfiles. I think this should be
rolllback.h and that should be the name of your uclass.
> DECLARE_GLOBAL_DATA_PTR;
> #endif /* !USE_HOSTCC*/
> #include
> @@ -63,6 +65,39 @@ struct image_region *fit_region_make_list(const void *fit,
> return region;
> }
>
> +#if !defined(USE_HOSTCC)
Can we drop that?
> +static int fit_image_verify_arbvn(const void *fit, int image_noffset)
> +{
> + u64 image_arbvn;
> + u64 plat_arbvn = 0ULL;
> + struct udevice *dev;
> + int ret;
> +
> + ret = fit_image_get_arbvn(fit, image_noffset, _arbvn);
> + if (ret)
> + return 0;
?? Isn't this an error?
> +
> + ret = uclass_first_device_err(UCLASS_SECURITY, );
> + if (ret)
> + return -ENODEV;
return ret
> +
> + ret = dm_security_arbvn_get(dev, _arbvn);
> + if (ret)
> + return -EIO;
> +
> + if (image_arbvn < plat_arbvn) {
> + return -EPERM;
> + } else if (image_arbvn > plat_arbvn) {
> + ret = dm_security_arbvn_set(dev, image_arbvn);
> + printf(" Updating OS anti-rollback to %llu from %llu\n",
> + image_arbvn, plat_arbvn);
So the update happens in U-Boot? Don't we want to update it when we
know it boots?
> + return ret;
> + }
> +
> + return 0;
> +}
> +#endif
> +
> static int fit_image_setup_verify(struct image_sign_info *info,
> const void *fit, int noffset,
> const void *key_blob, int required_keynode,
> @@ -175,6 +210,16 @@ static int fit_image_verify_sig(const void *fit, int
> image_noffset,
> goto error;
> }
>
> +#if !defined(USE_HOSTCC)
Can you use
if (!tools_build())
?
This seems to be adding to FIT so the FIT docs should be updated.
Regards,
Simon
Re: [PATCH 1/5] drivers: security: Add security devices to driver model
Hi Sean, On Fri, 11 Aug 2023 at 18:28, wrote: > > From: Stephen Carlson > > Security devices currently implement operations to store an OS > anti-rollback monotonic counter. Existing devices such as the Trusted > Platform Module (TPM) already support this operation, but this uclass > provides abstraction for current and future devices that may support > different features. > > - New Driver Model uclass UCLASS_SECURITY. > - New config CONFIG_DM_SECURITY to enable security device support. > - New driver sandbox_security matching "security,sandbox", enabled with > new config CONFIG_SECURITY_SANDBOX. How about calling this UCLASS_ROLLBACK and implementing that function? Then you can add this device as a child of a TPM and the TPM can implement the API. Regards, Simon
Re: [PATCH] CI: Add automatic retry for test.py jobs
Hi Tom, On Thu, 27 Jul 2023 at 14:35, Tom Rini wrote: > > On Thu, Jul 27, 2023 at 01:18:12PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Sun, 16 Jul 2023 at 12:18, Tom Rini wrote: > > > > > > On Sat, Jul 15, 2023 at 05:40:25PM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 13 Jul 2023 at 15:57, Tom Rini wrote: > > > > > > > > > > On Thu, Jul 13, 2023 at 03:03:57PM -0600, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Wed, 12 Jul 2023 at 14:38, Tom Rini wrote: > > > > > > > > > > > > > > On Wed, Jul 12, 2023 at 02:32:18PM -0600, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Wed, 12 Jul 2023 at 11:09, Tom Rini > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Wed, Jul 12, 2023 at 08:00:23AM -0600, Simon Glass wrote: > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > > > On Tue, 11 Jul 2023 at 20:33, Tom Rini > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > It is not uncommon for some of the QEMU-based jobs to > > > > > > > > > > > fail not because > > > > > > > > > > > of a code issue but rather because of a timing issue or > > > > > > > > > > > similar problem > > > > > > > > > > > that is out of our control. Make use of the keywords that > > > > > > > > > > > Azure and > > > > > > > > > > > GitLab provide so that we will automatically re-run these > > > > > > > > > > > when they fail > > > > > > > > > > > 2 times. If they fail that often it is likely we have > > > > > > > > > > > found a real issue > > > > > > > > > > > to investigate. > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Tom Rini > > > > > > > > > > > --- > > > > > > > > > > > .azure-pipelines.yml | 1 + > > > > > > > > > > > .gitlab-ci.yml | 1 + > > > > > > > > > > > 2 files changed, 2 insertions(+) > > > > > > > > > > > > > > > > > > > > This seems like a slippery slope. Do we know why things > > > > > > > > > > fail? I wonder > > > > > > > > > > if we should disable the tests / builders instead, until it > > > > > > > > > > can be > > > > > > > > > > corrected? > > > > > > > > > > > > > > > > > > It happens in Azure, so it's not just the broken runner > > > > > > > > > problem we have > > > > > > > > > in GitLab. And the problem is timing, as I said in the commit. > > > > > > > > > Sometimes we still get the RTC test failing. Other times we > > > > > > > > > don't get > > > > > > > > > QEMU + U-Boot spawned in time (most often m68k, but sometimes > > > > > > > > > x86). > > > > > > > > > > > > > > > > How do we keep this list from growing? > > > > > > > > > > > > > > Do we need to? The problem is in essence since we rely on free > > > > > > > resources, sometimes some heavy lifts take longer. That's what > > > > > > > this > > > > > > > flag is for. > > > > > > > > > > > > I'm fairly sure the RTC thing could be made deterministic. > > > > > > > > > > We've already tried that once, and it happens a lot less often. If we > > > > > make it even looser we risk making the test itself useless. > > > > > > > > For sleep, yes, but for rtc it should be deterministic now...next time > > > > you get a failure could you send me the trace? > > > > > > Found one: > > > https://dev.azure.com/u-boot/u-boot/_build/results?buildId=6592=logs=b6c47816-145c-5bfe-20a7-c6a2572e6c41=0929c28c-6e32-5635-9624-54eaa917d713=599 > > > > I don't seem to have access to that...but it is rtc or sleep? > > It was the RTC one, and has since rolled off and been deleted. > > > > And note that we have a different set of timeout problems that may or may > > > not > > > be configurable, which is in the upload of the pytest results. I haven't > > > seen > > > if there's a knob for this one yet, within Azure (or the python project > > > we're > > > adding for it). > > > > Oh dear. > > > > > > > > > > > The spawning thing...is there a timeout for that? What actually > > > > > > fails? > > > > > > > > > > It doesn't spawn in time for the framework to get to the prompt. We > > > > > could maybe increase the timeout value. It's always the version test > > > > > that fails. > > > > > > > > Ah OK, yes increasing the timeout makes sense. > > > > > > > > > > > > > > > > > > > I'll note that we don't have this problem with sandbox > > > > > > > > > > tests. > > > > > > > > > > > > > > > > > > OK, but that's not relevant? > > > > > > > > > > > > > > > > It is relevant to the discussion about using QEMU instead of > > > > > > > > sandbox, > > > > > > > > e.g. with the TPM. I recall a discussion with Ilias a while > > > > > > > > back. > > > > > > > > > > > > > > I'm sure we could make sandbox take too long to start as well, if > > > > > > > enough > > > > > > > other things are going on with the system. And sandbox has its > > > > > > > own set > > > > > > > of super frustrating issues instead, so I don't think this is a > > > > > > > great > > > > > > > argument to have right here (I have to run it in docker, to get >
