Re: [PATCH] drivers: watchdog: wdt-uclass.c: add a property u-boot, noautostart
On 2/10/22 18:17, Philippe Reynes wrote:
Since commit 492ee6b8d0e7 ("watchdog: wdt-uclass.c: handle all DM
watchdogs in watchdog_reset()"), all the watchdog are started when
the config WATCHDOG_AUTOSTART.
To avoid a binary choice none/all, a property u-boot,noautostart
may be added in the watchdog node of the u-boot device tree to not
autostart this watchdog.
Signed-off-by: Philippe Reynes
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
drivers/watchdog/wdt-uclass.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c
index 6d0f473867..dbf556467d 100644
--- a/drivers/watchdog/wdt-uclass.c
+++ b/drivers/watchdog/wdt-uclass.c
@@ -36,6 +36,8 @@ struct wdt_priv {
ulong next_reset;
/* Whether watchdog_start() has been called on the device. */
bool running;
+ /* No autostart */
+ bool noautostart;
};
static void init_watchdog_dev(struct udevice *dev)
@@ -52,7 +54,7 @@ static void init_watchdog_dev(struct udevice *dev)
dev->name);
}
- if (!IS_ENABLED(CONFIG_WATCHDOG_AUTOSTART)) {
+ if (!IS_ENABLED(CONFIG_WATCHDOG_AUTOSTART) || priv->noautostart) {
printf("WDT: Not starting %s\n", dev->name);
return;
}
@@ -256,16 +258,19 @@ static int wdt_pre_probe(struct udevice *dev)
* indicated by a hw_margin_ms property.
*/
ulong reset_period = 1000;
+ bool noautostart = false;
struct wdt_priv *priv;
if (CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)) {
timeout = dev_read_u32_default(dev, "timeout-sec", timeout);
reset_period = dev_read_u32_default(dev, "hw_margin_ms",
4 * reset_period) / 4;
+ noautostart = dev_read_bool(dev, "u-boot,noautostart");
}
priv = dev_get_uclass_priv(dev);
priv->timeout = timeout;
priv->reset_period = reset_period;
+ priv->noautostart = noautostart;
/*
* Pretend this device was last reset "long" ago so the first
* watchdog_reset will actually call its ->reset method.
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: drivers: clk: stm32h7: Endless loop of dead in driver probe function
Hi,
On 3/2/22 18:00, Johannes (krjdev) Krottmayer wrote:
Hi,
Some IMHO fatal issues in the the clock driver for the
STM32H7 series driver.
Affected driver:
drivers/clk/clk_stm32h7.c
Affected configs (boards):
configs/stm32h750-art-pi_defconfig
configs/stm32h743-disco_defconfig
configs/stm32h743-eval_defconfig
Description:
The driver currently requires a external working clock source
(HSE). No issues in the circuit are accepted by the current
implementation. Also a fixed (defined) frequency of the external
clock source.
In the probe function stm32_clk_probe() from the driver there
will be configure_clocks() called. Here are the issues.
As code snippet from configure_clocks():
/* Switch on HSE */
setbits_le32(®s->cr, RCC_CR_HSEON);
while (!(readl(®s->cr) & RCC_CR_HSERDY))
;
RCC_CR_HSERDY will here never set, when there is no external
clock source or an issue in the circuit. -> Endless loop of dead.
Yes, the current clock driver for STM32 MCU is not perfect,
as the all U-Boot and the Linux support on STM32 MCU.
For information, in the other driver based on a other version of RCC for
STM32 MPU
STM32MP1 = clk_stm32mp1.c, it is correctly managed in
stm32mp1_osc_wait(1, rcc, RCC_OCRDYR, RCC_OCRDYR_HSERDY);
by using readl_poll_timeout() function.
My possible fixes:
At a timeout when reading the register and if the timeout is
elapsed, print an error message and return with ETIMEDOUT, so
the dm manger can call the hang() function.
I agree, it is a correct management: at least indicate this hardware issue
even if the rdy bit can't be stay at 0 in normal use case when HSE is
present.
=> replace all while() in the RCC clock driver with readl_poll_timeout
but to call readl_poll_timeout(), the arch timer need to ready
(timer_init() already called) when RCC clokc driver probe is executed.
An issue the I encounters on STM32MP need to be checked in MCU driver:
the timer can't dependant of RCC probe when polling function is used.
This issue was solved in STM32MP by using the generic armv7 timer
(only dependant of Cortex core) and call the initialization in
arch/arm/mach-stm32mp/cpu.c:
int arch_cpu_init(void)
{
/* early armv7 timer init: needed for polling */
timer_init();
return 0;
}
The timer management on MCU need to be check before any patch.
Can you propose something ?
Johannes K.
Patrick
Re: [PATCH] drivers: watchdog: wdt-uclass.c: add a property u-boot, noautostart
On 2/10/22 18:17, Philippe Reynes wrote:
Since commit 492ee6b8d0e7 ("watchdog: wdt-uclass.c: handle all DM
watchdogs in watchdog_reset()"), all the watchdog are started when
the config WATCHDOG_AUTOSTART.
To avoid a binary choice none/all, a property u-boot,noautostart
may be added in the watchdog node of the u-boot device tree to not
autostart this watchdog.
Signed-off-by: Philippe Reynes
Applied to u-boot-watchdog/master
Thanks,
Stefan
---
drivers/watchdog/wdt-uclass.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/wdt-uclass.c b/drivers/watchdog/wdt-uclass.c
index 6d0f473867..dbf556467d 100644
--- a/drivers/watchdog/wdt-uclass.c
+++ b/drivers/watchdog/wdt-uclass.c
@@ -36,6 +36,8 @@ struct wdt_priv {
ulong next_reset;
/* Whether watchdog_start() has been called on the device. */
bool running;
+ /* No autostart */
+ bool noautostart;
};
static void init_watchdog_dev(struct udevice *dev)
@@ -52,7 +54,7 @@ static void init_watchdog_dev(struct udevice *dev)
dev->name);
}
- if (!IS_ENABLED(CONFIG_WATCHDOG_AUTOSTART)) {
+ if (!IS_ENABLED(CONFIG_WATCHDOG_AUTOSTART) || priv->noautostart) {
printf("WDT: Not starting %s\n", dev->name);
return;
}
@@ -256,16 +258,19 @@ static int wdt_pre_probe(struct udevice *dev)
* indicated by a hw_margin_ms property.
*/
ulong reset_period = 1000;
+ bool noautostart = false;
struct wdt_priv *priv;
if (CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)) {
timeout = dev_read_u32_default(dev, "timeout-sec", timeout);
reset_period = dev_read_u32_default(dev, "hw_margin_ms",
4 * reset_period) / 4;
+ noautostart = dev_read_bool(dev, "u-boot,noautostart");
}
priv = dev_get_uclass_priv(dev);
priv->timeout = timeout;
priv->reset_period = reset_period;
+ priv->noautostart = noautostart;
/*
* Pretend this device was last reset "long" ago so the first
* watchdog_reset will actually call its ->reset method.
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH] MAINTAINERS: Add watchdog maintainers entry
On 1/14/22 00:52, Tom Rini wrote: On Thu, Jan 13, 2022 at 04:57:31PM +0100, Stefan Roese wrote: I've been handling "inofficially" the watchdog related patches for a few years now. Let's make this official and add a tree for it and also add myself here in the MAINTAINERS file. Signed-off-by: Stefan Roese Cc: Tom Rini Cc: Harald Seiler Reviewed-by: Tom Rini Applied to u-boot-watchdog/master Thanks, Stefan
Re: [PATCH u-boot-mvebu] watchdog: armada_37xx: Probe driver also when watchdog is already running
On 2/23/22 14:21, Pali Rohár wrote:
If Armada 37xx watchdog is started before U-Boot then CNTR_CTRL_ACTIVE bit
is set, U-Boot armada-37xx-wdt.c driver fails to initialize and so U-Boot
is unable to use or kick this watchdog.
Do not check for CNTR_CTRL_ACTIVE bit and always initialize watchdog. Same
behavior is implemented in Linux kernel driver.
This change allows to activate watchdog in firmware which loads U-Boot.
Signed-off-by: Pali Rohár
Applied to u-boot-watchdog/master
Thanks,
Stefan
---
drivers/watchdog/armada-37xx-wdt.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/watchdog/armada-37xx-wdt.c
b/drivers/watchdog/armada-37xx-wdt.c
index 2e119b9b5aad..bacebbc7926a 100644
--- a/drivers/watchdog/armada-37xx-wdt.c
+++ b/drivers/watchdog/armada-37xx-wdt.c
@@ -58,13 +58,11 @@ static void counter_disable(struct a37xx_wdt *priv, int id)
clrbits_le32(priv->reg + CNTR_CTRL(id), CNTR_CTRL_ENABLE);
}
-static int init_counter(struct a37xx_wdt *priv, int id, u32 mode, u32 trig_src)
+static void init_counter(struct a37xx_wdt *priv, int id, u32 mode, u32
trig_src)
{
u32 reg;
reg = readl(priv->reg + CNTR_CTRL(id));
- if (reg & CNTR_CTRL_ACTIVE)
- return -EBUSY;
reg &= ~(CNTR_CTRL_MODE_MASK | CNTR_CTRL_PRESCALE_MASK |
CNTR_CTRL_TRIG_SRC_MASK);
@@ -79,8 +77,6 @@ static int init_counter(struct a37xx_wdt *priv, int id, u32
mode, u32 trig_src)
reg |= trig_src;
writel(reg, priv->reg + CNTR_CTRL(id));
-
- return 0;
}
static int a37xx_wdt_reset(struct udevice *dev)
@@ -116,16 +112,9 @@ static int a37xx_wdt_expire_now(struct udevice *dev, ulong
flags)
static int a37xx_wdt_start(struct udevice *dev, u64 ms, ulong flags)
{
struct a37xx_wdt *priv = dev_get_priv(dev);
- int err;
-
- err = init_counter(priv, 0, CNTR_CTRL_MODE_ONESHOT, 0);
- if (err < 0)
- return err;
- err = init_counter(priv, 1, CNTR_CTRL_MODE_HWSIG,
- CNTR_CTRL_TRIG_SRC_PREV_CNTR);
- if (err < 0)
- return err;
+ init_counter(priv, 0, CNTR_CTRL_MODE_ONESHOT, 0);
+ init_counter(priv, 1, CNTR_CTRL_MODE_HWSIG,
CNTR_CTRL_TRIG_SRC_PREV_CNTR);
priv->timeout = ms * priv->clk_rate / 1000 / CNTR_CTRL_PRESCALE_MIN;
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH] watchdog: rti_wdt: Add 10% safety margin to clock frequency
On 2/21/22 17:21, Jan Kiszka wrote:
From: Jan Kiszka
When running against RC_OSC_32k, the watchdog may suffer from running
faster than expected, expiring earlier. The Linux kernel adds a 10%
margin to the timeout calculation by slowing down the read clock rate
accordingly. Do the same here, also to have comparable preset values
for both drivers.
Along this, fix the name of the local var holding to frequency - in Hz,
not kHz.
Signed-off-by: Jan Kiszka
Applied to u-boot-watchdog/master
Thanks,
Stefan
---
drivers/watchdog/rti_wdt.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c
index 253286d349b..8d93f19b984 100644
--- a/drivers/watchdog/rti_wdt.c
+++ b/drivers/watchdog/rti_wdt.c
@@ -41,7 +41,7 @@
struct rti_wdt_priv {
phys_addr_t regs;
- unsigned int clk_khz;
+ unsigned int clk_hz;
};
#ifdef CONFIG_WDT_K3_RTI_LOAD_FW
@@ -139,7 +139,7 @@ static int rti_wdt_start(struct udevice *dev, u64
timeout_ms, ulong flags)
if (ret < 0)
return ret;
- timer_margin = timeout_ms * priv->clk_khz / 1000;
+ timer_margin = timeout_ms * priv->clk_hz / 1000;
timer_margin >>= WDT_PRELOAD_SHIFT;
if (timer_margin > WDT_PRELOAD_MAX)
timer_margin = WDT_PRELOAD_MAX;
@@ -185,7 +185,15 @@ static int rti_wdt_probe(struct udevice *dev)
if (ret)
return ret;
- priv->clk_khz = clk_get_rate(&clk);
+ priv->clk_hz = clk_get_rate(&clk);
+
+ /*
+* If watchdog is running at 32k clock, it is not accurate.
+* Adjust frequency down in this case so that it does not expire
+* earlier than expected.
+*/
+ if (priv->clk_hz < 32768)
+ priv->clk_hz = priv->clk_hz * 9 / 10;
return 0;
}
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Please pull u-boot-watchdog/master
Hi Tom, please pull the following watchdog related patches: - Update MAINTAINERS file (Stefan) - wdt-uclass.c: add a property u-boot, noautostart (Philippe) - armada_37xx: Probe driver also when watchdog is already running (Pali) - rti_wdt: Add 10% safety margin to clock frequency (Jan) Here the Azure build, with only one unrelated issue (binman fiptool missing): https://dev.azure.com/sr0718/u-boot/_build/results?buildId=164&view=results Thanks, Stefan The following changes since commit 6d3c46ed0e230d999c3f20f7fd4f3a88c03b14ca: Merge https://source.denx.de/u-boot/custodians/u-boot-sunxi (2022-03-05 20:46:55 -0500) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-watchdog.git for you to fetch changes up to 817e153fe546c2da9df8e8affc94d12036815659: watchdog: rti_wdt: Add 10% safety margin to clock frequency (2022-03-08 09:08:09 +0100) Jan Kiszka (1): watchdog: rti_wdt: Add 10% safety margin to clock frequency Pali Rohár (1): watchdog: armada_37xx: Probe driver also when watchdog is already running Philippe Reynes (1): drivers: watchdog: wdt-uclass.c: add a property u-boot, noautostart Stefan Roese (1): MAINTAINERS: Add watchdog maintainers entry MAINTAINERS| 8 drivers/watchdog/armada-37xx-wdt.c | 17 +++-- drivers/watchdog/rti_wdt.c | 14 +++--- drivers/watchdog/wdt-uclass.c | 7 ++- 4 files changed, 28 insertions(+), 18 deletions(-)
[PATCH] board: .gitignore: replace dsdt.c by dsdt_generated.c
Since commit 5d94cbd1dca7 ("scripts: Makefile.lib: generate
dsdt_generated.c instead of dsdt.c"), the file generated
is named dsdt_generated.c instead of dsdt.c.
So all files .gitignore referencing dsdt.c should be
upated with dsdt_generated.c.
Signed-off-by: Philippe Reynes
---
board/advantech/som-db5800-som-6867/.gitignore| 6 +++---
board/congatec/conga-qeval20-qa3-e3845/.gitignore | 6 +++---
board/intel/bayleybay/.gitignore | 6 +++---
board/intel/edison/.gitignore | 6 +++---
board/intel/galileo/.gitignore| 6 +++---
board/intel/minnowmax/.gitignore | 6 +++---
6 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/board/advantech/som-db5800-som-6867/.gitignore
b/board/advantech/som-db5800-som-6867/.gitignore
index 6eb8a5481a..39e46ba0ae 100644
--- a/board/advantech/som-db5800-som-6867/.gitignore
+++ b/board/advantech/som-db5800-som-6867/.gitignore
@@ -1,3 +1,3 @@
-dsdt.aml
-dsdt.asl.tmp
-dsdt.c
+dsdt_generated.aml
+dsdt_generated.asl.tmp
+dsdt_generated.c
diff --git a/board/congatec/conga-qeval20-qa3-e3845/.gitignore
b/board/congatec/conga-qeval20-qa3-e3845/.gitignore
index 6eb8a5481a..39e46ba0ae 100644
--- a/board/congatec/conga-qeval20-qa3-e3845/.gitignore
+++ b/board/congatec/conga-qeval20-qa3-e3845/.gitignore
@@ -1,3 +1,3 @@
-dsdt.aml
-dsdt.asl.tmp
-dsdt.c
+dsdt_generated.aml
+dsdt_generated.asl.tmp
+dsdt_generated.c
diff --git a/board/intel/bayleybay/.gitignore b/board/intel/bayleybay/.gitignore
index 6eb8a5481a..39e46ba0ae 100644
--- a/board/intel/bayleybay/.gitignore
+++ b/board/intel/bayleybay/.gitignore
@@ -1,3 +1,3 @@
-dsdt.aml
-dsdt.asl.tmp
-dsdt.c
+dsdt_generated.aml
+dsdt_generated.asl.tmp
+dsdt_generated.c
diff --git a/board/intel/edison/.gitignore b/board/intel/edison/.gitignore
index 6eb8a5481a..39e46ba0ae 100644
--- a/board/intel/edison/.gitignore
+++ b/board/intel/edison/.gitignore
@@ -1,3 +1,3 @@
-dsdt.aml
-dsdt.asl.tmp
-dsdt.c
+dsdt_generated.aml
+dsdt_generated.asl.tmp
+dsdt_generated.c
diff --git a/board/intel/galileo/.gitignore b/board/intel/galileo/.gitignore
index 6eb8a5481a..39e46ba0ae 100644
--- a/board/intel/galileo/.gitignore
+++ b/board/intel/galileo/.gitignore
@@ -1,3 +1,3 @@
-dsdt.aml
-dsdt.asl.tmp
-dsdt.c
+dsdt_generated.aml
+dsdt_generated.asl.tmp
+dsdt_generated.c
diff --git a/board/intel/minnowmax/.gitignore b/board/intel/minnowmax/.gitignore
index 6eb8a5481a..39e46ba0ae 100644
--- a/board/intel/minnowmax/.gitignore
+++ b/board/intel/minnowmax/.gitignore
@@ -1,3 +1,3 @@
-dsdt.aml
-dsdt.asl.tmp
-dsdt.c
+dsdt_generated.aml
+dsdt_generated.asl.tmp
+dsdt_generated.c
--
2.17.1
Re: [PATCH v4] scripts: Makefile.lib: generate dsdt_generated.c instead of dsdt.c
Hi Tom, Le 25/02/2022 à 21:53, Tom Rini a écrit : On Fri, Feb 25, 2022 at 06:30:05PM +0100, Philippe Reynes wrote: There is a conflict between the static file lib/acpi/dsdt.c and the file dsdt.c generated dynamicaly by scripts/Makefile.lib. When a mrproper is done, the static file dsdt.c is removed. If a build with acpi enabled is launched after, the following error is raised: CC lib/acpi/acpi_table.o make[2]: *** No rule to make target 'lib/acpi/dsdt.asl', needed by 'lib/acpi/dsdt.c'. Stop. scripts/Makefile.build:394: recipe for target 'lib/acpi' failed To avoid such error, the generated file is named dsdt_generated.c instead of dstdt.c. Tested-by: Heiko Thiery Signed-off-by: Philippe Reynes --- Changelog: v4: - update dsdt.* to dsdt_generated.* in several .gitignore v3: - update comments in file scripts/Makefile.lib - add changelog v2 - change generated file name (dsdt_generated.c) instead of changing the name of the static file - NOTE : forgot to call it v2 and forgot changelog Sorry, I missed that this had come through while testing and applying v3. Can you please do an incremental patch with the changes? Thanks! No problem, I understand, I just send a new patch with only the update on files .gitignore Regards, Philippe
RE: [EXT] Re: [PATCH v8 01/15] crypto/fsl: Add support for CAAM Job ring driver model
Hi Tom > -Original Message- > From: Tom Rini > Sent: Monday, March 7, 2022 8:46 PM > To: Gaurav Jain > Cc: Michael Walle ; sba...@denx.de; Varun Sethi > ; Adrian Alonso ; Alison Wang > ; Andy Tang ; > feste...@gmail.com; Franck Lenormand ; Horia > Geanta ; Ji Luo ; ma...@denx.de; > Meenakshi Aggarwal ; Mingkai Hu > ; olte...@gmail.com; Pankaj Gupta > ; Peng Fan ; Pramod Kumar > ; Priyanka Jain ; Rajesh > Bhagat ; Sahil Malhotra ; > Shengzhou Liu ; Silvano Di Ninno > ; s...@chromium.org; u-boot@lists.denx.de; dl- > uboot-imx ; Wasim Khan ; Ye Li > > Subject: Re: [EXT] Re: [PATCH v8 01/15] crypto/fsl: Add support for CAAM Job > ring driver model > > On Mon, Mar 07, 2022 at 12:03:42PM +, Gaurav Jain wrote: > > > > > > > -Original Message- > > > From: Michael Walle > > > Sent: Monday, March 7, 2022 5:12 PM > > > To: Gaurav Jain > > > Cc: sba...@denx.de; Varun Sethi ; Adrian Alonso > > > ; Alison Wang ; Andy > > > Tang ; feste...@gmail.com; Franck Lenormand > > > ; Horia Geanta ; Ji > > > Luo ; ma...@denx.de; Meenakshi Aggarwal > > > ; Mingkai Hu ; > > > olte...@gmail.com; Pankaj Gupta ; Peng Fan > > > ; Pramod Kumar ; > Priyanka > > > Jain ; Rajesh Bhagat ; > > > Sahil Malhotra ; Shengzhou Liu > > > ; Silvano Di Ninno ; > > > s...@chromium.org; u- b...@lists.denx.de; dl-uboot-imx > > > ; Wasim Khan ; Ye Li > > > > > > Subject: Re: [EXT] Re: [PATCH v8 01/15] crypto/fsl: Add support for > > > CAAM Job ring driver model > > > > > > Caution: EXT Email > > > > > > Am 2022-03-07 12:33, schrieb Gaurav Jain: > > > >> -Original Message- > > > >> From: Michael Walle > > > >> Sent: Monday, March 7, 2022 4:39 PM > > > >> To: Gaurav Jain > > > >> Cc: sba...@denx.de; Varun Sethi ; Adrian Alonso > > > >> ; Alison Wang ; Andy > > > Tang > > > >> ; feste...@gmail.com; Franck Lenormand > > > >> ; Horia Geanta ; > > > >> Ji Luo ; ma...@denx.de; Meenakshi Aggarwal > > > >> ; Mingkai Hu ; > > > >> olte...@gmail.com; Pankaj Gupta ; Peng Fan > > > >> ; Pramod Kumar ; > > > Priyanka > > > >> Jain ; Rajesh Bhagat > > > >> ; Sahil Malhotra ; > > > >> Shengzhou Liu ; Silvano Di Ninno > > > >> ; s...@chromium.org; u- > > > >> b...@lists.denx.de; dl-uboot-imx ; Wasim Khan > > > >> ; Ye Li > > > >> Subject: Re: [EXT] Re: [PATCH v8 01/15] crypto/fsl: Add support > > > >> for CAAM Job ring driver model > > > >> > > > >> Caution: EXT Email > > > >> > > > >> Am 2022-03-07 11:56, schrieb Gaurav Jain: > > > >> >> -Original Message- > > > >> >> From: Michael Walle > > > >> >> Sent: Monday, March 7, 2022 3:28 PM > > > >> >> To: sba...@denx.de > > > >> >> Cc: Varun Sethi ; Adrian Alonso > > > >> >> ; Alison Wang ; > > > >> >> Andy > > > >> Tang > > > >> >> ; feste...@gmail.com; Franck Lenormand > > > >> >> ; Gaurav Jain ; > > > >> >> Horia Geanta ; Ji Luo ; > > > >> >> ma...@denx.de; Meenakshi Aggarwal > > > >> >> ; Mingkai Hu > ; > > > >> >> olte...@gmail.com; Pankaj Gupta ; Peng > > > >> >> Fan ; Pramod > > > Kumar > > > >> >> ; Priyanka Jain > > > >> >> ; Rajesh Bhagat > > > >> >> ; Sahil Malhotra > > > >> >> ; Shengzhou Liu > > > >> >> ; Silvano Di Ninno > > > >> >> ; s...@chromium.org; u- > > > >> >> b...@lists.denx.de; dl-uboot-imx ; Wasim > > > >> >> Khan ; Ye Li ; Michael > > > >> >> Walle > > > >> >> Subject: Re: [EXT] Re: [PATCH v8 01/15] crypto/fsl: Add > > > >> >> support for CAAM Job ring driver model > > > >> >> > > > >> >> Caution: EXT Email > > > >> >> > > > >> >> > On 03.03.22 14:41, Gaurav Jain wrote: > > > >> >> >> As we have not received any response from imx6dl_mamoj > > > >> >> >> board > > > >> maintainer. > > > >> >> >> I propose the below solution > > > >> >> >> > > > >> >> >> --- a/arch/arm/mach-imx/Kconfig > > > >> >> >> +++ b/arch/arm/mach-imx/Kconfig > > > >> >> >> @@ -49,8 +49,8 @@ config USE_IMXIMG_PLUGIN config > IMX_HAB > > > >> >> >> - select FSL_CAAM if HAS_CAAM > > > >> >> >> - imply CMD_DEKBLOB if HAS_CAAM > > > >> >> >> + imply FSL_CAAM if HAS_CAAM > > > >> >> >> + imply CMD_DEKBLOB if FSL_CAAM > > > >> >> >> Help > > > >> >> >> > > > >> >> > > > > >> >> > IMO this is ok, I was also wrong, Marek is not the > > > >> >> > maintainer of this board. This was the only board with > > > >> >> > broken build - let's say, I will still wait a couple of > > > >> >> > days, and if there is no comments, I will apply your series > > > >> >> > (but then V10). I can apply this fix myself, no need to post > > > >> >> > the series again (I have not seen any other comment or > > > >> >> > request to > > > >> >> change). > > > >> >> > > > >> >> I don't understand why the solution isn't the same one as for > > > >> >> the layerscape part in this series[1]: enable the config per > > > >> >> board (that is your boards) and leave all others the same as before? > > > >> > > > > >> > imx6dl_mamoj caam driver is not enabled by any of my changes. > > > >> > This board is enabling IMX_HAB which select FSL_CAAM. > > > >> > Proposed changes making it imply s
Re: [EXT] Re: [PATCH v8 01/15] crypto/fsl: Add support for CAAM Job ring driver model
On Tue, Mar 8, 2022 at 8:10 AM Gaurav Jain wrote: > I further checked on your concern and propose the below change to stop > building caam driver in SPL for imx6dl_mamoj. > > --- a/configs/imx6dl_mamoj_defconfig > +++ b/configs/imx6dl_mamoj_defconfig > @@ -61,3 +61,4 @@ CONFIG_USB_GADGET_MANUFACTURER="FSL" > CONFIG_USB_GADGET_VENDOR_NUM=0x0525 > CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 > CONFIG_CI_UDC=y > +CONFIG_SPL_CRYPTO=n No, this is not how defconfig works. You should set: # CONFIG_SPL_CRYPTO is not set
RE: [EXT] Re: [PATCH v8 01/15] crypto/fsl: Add support for CAAM Job ring driver model
> -Original Message- > From: Fabio Estevam > Sent: Tuesday, March 8, 2022 4:42 PM > To: Gaurav Jain > Cc: Tom Rini ; Michael Walle ; > sba...@denx.de; Varun Sethi ; Adrian Alonso > ; Alison Wang ; Andy Tang > ; Franck Lenormand ; > Horia Geanta ; Ji Luo ; > ma...@denx.de; Meenakshi Aggarwal ; > Mingkai Hu ; olte...@gmail.com; Pankaj Gupta > ; Peng Fan ; Pramod Kumar > ; Priyanka Jain ; Rajesh > Bhagat ; Sahil Malhotra ; > Shengzhou Liu ; Silvano Di Ninno > ; s...@chromium.org; u-boot@lists.denx.de; dl- > uboot-imx ; Wasim Khan ; Ye Li > > Subject: Re: [EXT] Re: [PATCH v8 01/15] crypto/fsl: Add support for CAAM Job > ring driver model > > Caution: EXT Email > > On Tue, Mar 8, 2022 at 8:10 AM Gaurav Jain wrote: > > > I further checked on your concern and propose the below change to stop > building caam driver in SPL for imx6dl_mamoj. > > > > --- a/configs/imx6dl_mamoj_defconfig > > +++ b/configs/imx6dl_mamoj_defconfig > > @@ -61,3 +61,4 @@ CONFIG_USB_GADGET_MANUFACTURER="FSL" > > CONFIG_USB_GADGET_VENDOR_NUM=0x0525 > > CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 > > CONFIG_CI_UDC=y > > +CONFIG_SPL_CRYPTO=n > > No, this is not how defconfig works. > > You should set: > > # CONFIG_SPL_CRYPTO is not set Ok. Noted. Gaurav
[PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model
With this patch set[1] applied, UEFI subsystem maintains a list of its disk objects dynamically at runtime based on block device's probing. (See "issues" below.) [1] https://github.com/t-akashi/u-boot/tree/efi/dm_disk For instance, => dm tree Class Index Probed DriverName --- root 0 [ + ] root_driver root_driver ... pci 0 [ + ] pci_generic_ecam |-- pcie@1000 ... ahci 0 [ ] ahci_pci | |-- ahci_pci scsi 0 [ ] ahci_scsi | | `-- ahci_scsi usb 0 [ ] xhci_pci | `-- xhci_pci ... => efi devices Missing RNG device for EFI_RNG_PROTOCOL No EFI system partition Unable to find TPMv2 device Device Device Path 00013eee88d0 /VenHw(..) 00013ffeb798 /VenHw(..)/Uart(0,0,D,D) 00013eeeb810 /VenHw(..)/MAC(525252525252,1) => scsi rescan ... => efi devices Device Device Path 00013eee88d0 /VenHw(..) 00013ffeb798 /VenHw(..)/Uart(0,0,D,D) 00013eeeb810 /VenHw(..)/MAC(525252525252,1) 00013eefb730 /VenHw(..)/Scsi(0,0) 00013eefb840 /VenHw(..)/Scsi(0,0)/HD(1,GPT,ce86c5a7-b32a-488f-a346-88fe698e0edc,0x22,0x4c2a) 00013eefbc80 /VenHw(..)/Scsi(0,0)/HD(2,GPT,aa80aab9-33e6-42b6-b5db-def2cb8d7844,0x5000,0x1a800) => usb start ... => efi devices Device Device Path 00013eee88d0 /VenHw(..) 00013ffeb798 /VenHw(..)/Uart(0,0,D,D) 00013eeeb810 /VenHw(..)/MAC(525252525252,1) 00013eefb730 /VenHw(..)/Scsi(0,0) 00013eefb840 /VenHw(..)/Scsi(0,0)/HD(1,GPT,ce86c5a7-b32a-488f-a346-88fe698e0edc,0x22,0x4c2a) 00013eefbc80 /VenHw(..)/Scsi(0,0)/HD(2,GPT,aa80aab9-33e6-42b6-b5db-def2cb8d7844,0x5000,0x1a800) 00013ef01330 /VenHw(..)/UsbClass(0x0,0x0,0x9,0x0,0x3)/UsbClass(0x46f4,0x1,0x0,0x0,0x0) 00013ef014b0 /VenHw(..)/UsbClass(0x0,0x0,0x9,0x0,0x3)/UsbClass(0x46f4,0x1,0x0,0x0,0x0)/HD(1,GPT,ce86c5a7-b32a-488f-a346-88fe698e0edc,0x22,0x4c2a) 00013ef018f0 /VenHw(..)/UsbClass(0x0,0x0,0x9,0x0,0x3)/UsbClass(0x46f4,0x1,0x0,0x0,0x0)/HD(2,GPT,aa80aab9-33e6-42b6-b5db-def2cb8d7844,0x5000,0x1a800) => dm tree ... pci 0 [ + ] pci_generic_ecam |-- pcie@1000 ... ahci 0 [ + ] ahci_pci | |-- ahci_pci scsi 0 [ + ] ahci_scsi | | `-- ahci_scsi blk 2 [ + ] scsi_blk | | `-- ahci_scsi.id0lun0 partition 0 [ + ] blk_partition | | |-- ahci_scsi.id0lun0:1 partition 1 [ + ] blk_partition | | `-- ahci_scsi.id0lun0:2 usb 0 [ + ] xhci_pci | `-- xhci_pci usb_hub 0 [ + ] usb_hub | `-- usb_hub usb_mass_s0 [ + ] usb_mass_storage | |-- usb_mass_storage blk 3 [ + ] usb_storage_blk | | `-- usb_mass_storage.lun0 partition 2 [ + ] blk_partition | | |-- usb_mass_storage.lun0:1 partition 3 [ + ] blk_partition | | `-- usb_mass_storage.lun0:2 ... => usb stop stopping USB.. => efi devices Device Device Path 00013eee88d0 /VenHw(..) 00013ffeb798 /VenHw(..)/Uart(0,0,D,D) 00013eeeb810 /VenHw(..)/MAC(525252525252,1) 00013eefb730 /VenHw(..)/Scsi(0,0) 00013eefb840 /VenHw(..)/Scsi(0,0)/HD(1,GPT,ce86c5a7-b32a-488f-a346-88fe698e0edc,0x22,0x4c2a) 00013eefbc80 /VenHw(..)/Scsi(0,0)/HD(2,GPT,aa80aab9-33e6-42b6-b5db-def2cb8d7844,0x5000,0x1a800) Issues: === * The image size of U-Boot may increase. CI build test complains, for instance, rcar3_salvator-x: "u-boot.img exceeds file size limit: ... excess: 0x79c bytes" phycore-rk3288: "SPL image is too large (size 0x8800 than 0x8000)" See [2]. * For removal case, we may need more consideration since removing handles unconditionally may end up breaking integrity of handles (as some may still be held and referenced to by a UEFI app). [2] https://dev.azure.com/u-boot/u-boot/_build/results?buildId=3770&view=results Prerequisite: = * Simon's event[3] [3] https://lists.denx.de/pipermail/u-boot/2022-March/476844.html Patchs: === For easy understandings, patches may be categorized into separate groups of changes. Patch#1-#7: DM: add device_probe() for later use of events Patch#8-#10: DM: add a new feature (DM tag) Patch#11-#15: UEFI: dynamically create/remove efi_disk's for a raw disk and its partitions Patch#16-#17: UEFI: use udevice read/write interfaces Patch#18-#19: UEFI: fix-up efi_driver, aligning with changes in DM integration Change history: === v3 (Mar 8, 2022) * rebased on 2022.04-rc3 * rebased on v2 of Simon's event patch (hence removed his patc
[PATCH v3 01/19] scsi: call device_probe() after scanning
Every time a scsi bus/port is scanned and a new block device is detected,
we want to call device_probe() as it will give us a chance to run
additional post-processings for some purposes.
In particular, support for creating partitions on a device will be added.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Simon Glass
---
drivers/scsi/scsi.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index d7b33010e469..78d729d809d7 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -595,6 +595,11 @@ static int do_scsi_scan_one(struct udevice *dev, int id,
int lun, bool verbose)
ata_swap_buf_le16((u16 *)&bdesc->revision, sizeof(bd.revision)
/ 2);
}
+ ret = blk_probe_or_unbind(bdev);
+ if (ret < 0)
+ /* TODO: undo create */
+ return ret;
+
if (verbose) {
printf(" Device %d: ", bdesc->devnum);
dev_print(bdesc);
--
2.33.0
[PATCH v3 02/19] usb: storage: call device_probe() after scanning
Every time a usb bus/port is scanned and a new device is detected, we want to call device_probe() as it will give us a chance to run additional post-processings for some purposes. In particular, support for creating partitions on a device will be added. Signed-off-by: AKASHI Takahiro Reviewed-by: Simon Glass --- common/usb_storage.c | 4 1 file changed, 4 insertions(+) diff --git a/common/usb_storage.c b/common/usb_storage.c index c9e2d7343ce2..291728f37e0a 100644 --- a/common/usb_storage.c +++ b/common/usb_storage.c @@ -239,6 +239,10 @@ static int usb_stor_probe_device(struct usb_device *udev) if (ret) return ret; } + + ret = blk_probe_or_unbind(dev); + if (ret) + return ret; } #else /* We don't have space to even probe if we hit the maximum */ -- 2.33.0
[PATCH v3 03/19] mmc: call device_probe() after scanning
Every time a mmc bus/port is scanned and a new device is detected,
we want to call device_probe() as it will give us a chance to run
additional post-processings for some purposes.
In particular, support for creating partitions on a device will be added.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Jaehoon Chung
---
drivers/mmc/mmc-uclass.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
index b80e838066ca..57da788ad805 100644
--- a/drivers/mmc/mmc-uclass.c
+++ b/drivers/mmc/mmc-uclass.c
@@ -467,6 +467,18 @@ static int mmc_blk_probe(struct udevice *dev)
return ret;
}
+ ret = device_probe(dev);
+ if (ret) {
+ debug("Probing %s failed (err=%d)\n", dev->name, ret);
+
+ if (CONFIG_IS_ENABLED(MMC_UHS_SUPPORT) ||
+ CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) ||
+ CONFIG_IS_ENABLED(MMC_HS400_SUPPORT))
+ mmc_deinit(mmc);
+
+ return ret;
+ }
+
return 0;
}
--
2.33.0
[PATCH v3 04/19] nvme: call device_probe() after scanning
Every time a nvme bus/port is scanned and a new device is detected, we want to call device_probe() as it will give us a chance to run additional post-processings for some purposes. In particular, support for creating partitions on a device will be added. Signed-off-by: AKASHI Takahiro Reviewed-by: Simon Glass --- drivers/nvme/nvme.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c index 1d56517e9969..a305305885ec 100644 --- a/drivers/nvme/nvme.c +++ b/drivers/nvme/nvme.c @@ -884,6 +884,10 @@ int nvme_init(struct udevice *udev) -1, 512, 0, &ns_udev); if (ret) goto free_id; + + ret = blk_probe_or_unbind(ns_udev); + if (ret) + goto free_id; } free(id); -- 2.33.0
[PATCH v3 05/19] sata: call device_probe() after scanning
Every time a sata bus/port is scanned and a new device is detected,
we want to call device_probe() as it will give us a chance to run
additional post-processings for some purposes.
In particular, support for creating partitions on a device will be added.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Simon Glass
---
drivers/ata/dwc_ahsata.c | 5 +
drivers/ata/fsl_sata.c | 11 +++
drivers/ata/sata_mv.c| 5 +
drivers/ata/sata_sil.c | 12
4 files changed, 33 insertions(+)
diff --git a/drivers/ata/dwc_ahsata.c b/drivers/ata/dwc_ahsata.c
index 6d42548087b3..d9fd850c6fae 100644
--- a/drivers/ata/dwc_ahsata.c
+++ b/drivers/ata/dwc_ahsata.c
@@ -1026,6 +1026,11 @@ int dwc_ahsata_scan(struct udevice *dev)
return ret;
}
+ ret = blk_probe_or_unbind(dev);
+ if (ret < 0)
+ /* TODO: undo create */
+ return ret;
+
return 0;
}
diff --git a/drivers/ata/fsl_sata.c b/drivers/ata/fsl_sata.c
index e44db0a37458..d1bab931895a 100644
--- a/drivers/ata/fsl_sata.c
+++ b/drivers/ata/fsl_sata.c
@@ -982,6 +982,17 @@ static int fsl_ata_probe(struct udevice *dev)
failed_number++;
continue;
}
+
+ ret = device_probe(dev);
+ if (ret < 0) {
+ debug("Probing %s failed (%d)\n", dev->name, ret);
+ ret = fsl_unbind_device(blk);
+ if (ret)
+ return ret;
+
+ failed_number++;
+ continue;
+ }
}
if (failed_number == nr_ports)
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index 003222d47be6..a187796dfcdf 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -1099,6 +1099,11 @@ static int sata_mv_probe(struct udevice *dev)
continue;
}
+ ret = blk_probe_or_unbind(dev);
+ if (ret < 0)
+ /* TODO: undo create */
+ continue;
+
/* If we got here, the current SATA port was probed
* successfully, so set the probe status to successful.
*/
diff --git a/drivers/ata/sata_sil.c b/drivers/ata/sata_sil.c
index a4f0dae4bbd1..b213ebac2fb9 100644
--- a/drivers/ata/sata_sil.c
+++ b/drivers/ata/sata_sil.c
@@ -753,6 +753,18 @@ static int sil_pci_probe(struct udevice *dev)
failed_number++;
continue;
}
+
+ ret = device_probe(dev);
+ if (ret < 0) {
+ debug("Probing %s failed (%d)\n", dev->name, ret);
+ ret = sil_unbind_device(blk);
+ device_unbind(dev);
+ if (ret)
+ return ret;
+
+ failed_number++;
+ continue;
+ }
}
if (failed_number == sata_info.maxport)
--
2.33.0
[PATCH v3 06/19] block: ide: call device_probe() after scanning
Every time an ide bus/port is scanned and a new device is detected, we want to call device_probe() as it will give us a chance to run additional post-processings for some purposes. In particular, support for creating partitions on a device will be added. Signed-off-by: AKASHI Takahiro Reviewed-by: Simon Glass --- drivers/block/ide.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/block/ide.c b/drivers/block/ide.c index 63c4cfdc1c21..e8518ff3a11a 100644 --- a/drivers/block/ide.c +++ b/drivers/block/ide.c @@ -1123,6 +1123,10 @@ static int ide_probe(struct udevice *udev) blksz, size, &blk_dev); if (ret) return ret; + + ret = blk_probe_or_unbind(blk_dev); + if (ret) + return ret; } } -- 2.33.0
[PATCH v3 07/19] virtio: call device_probe() in scanning
virtio_init() enumerates all the peripherals that are to be materialised
with udevices(UCLASS_VIRIO) and creates particular device instances
(UCLASS_BlK or whatever else) as children.
On the other hand, device_probe() won't be invoked against those resultant
udevices unlike other ordinary device drivers do in the driver model.
This is particularly inconvenient when we want to add "event notification"
callback so that we will be able to automatically create all efi_disk
objects in a later patch.
With this patch applied, "virtio scan" will work in a similar way
to "scsi rescan", "usb start" or others in term of 'probe' semantics.
I didn't add this change to virtio_init() itself because this function
may be called in board_init_r() (indirectly in board_late_init())
before UEFI subsustem is initialized.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Simon Glass
---
cmd/virtio.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/cmd/virtio.c b/cmd/virtio.c
index 3dace5344f7e..ea3ed2e631e4 100644
--- a/cmd/virtio.c
+++ b/cmd/virtio.c
@@ -17,8 +17,25 @@ static int do_virtio(struct cmd_tbl *cmdtp, int flag, int
argc,
char *const argv[])
{
if (argc == 2 && !strcmp(argv[1], "scan")) {
- /* make sure all virtio devices are enumerated */
- virtio_init();
+ /*
+* make sure all virtio devices are enumerated.
+* Do the same as virtio_init(), but also call
+* device_probe() for children (i.e. virtio devices)
+*/
+ struct udevice *bus, *child;
+ int ret;
+
+ ret = uclass_first_device(UCLASS_VIRTIO, &bus);
+ if (ret)
+ return CMD_RET_FAILURE;
+
+ while (bus) {
+ device_foreach_child_probe(child, bus)
+ ;
+ ret = uclass_next_device(&bus);
+ if (ret)
+ break;
+ }
return CMD_RET_SUCCESS;
}
--
2.33.0
[PATCH v3 10/19] test: dm: add tests for tag support
The new test covers all tag-related interfaces.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Simon Glass
---
test/dm/Makefile | 1 +
test/dm/tag.c| 84
2 files changed, 85 insertions(+)
create mode 100644 test/dm/tag.c
diff --git a/test/dm/Makefile b/test/dm/Makefile
index d46552fbf320..dc3177dbb7f4 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -102,6 +102,7 @@ obj-y += syscon.o
obj-$(CONFIG_RESET_SYSCON) += syscon-reset.o
obj-$(CONFIG_SYSINFO) += sysinfo.o
obj-$(CONFIG_SYSINFO_GPIO) += sysinfo-gpio.o
+obj-$(CONFIG_UT_DM) += tag.o
obj-$(CONFIG_TEE) += tee.o
obj-$(CONFIG_TIMER) += timer.o
obj-$(CONFIG_DM_USB) += usb.o
diff --git a/test/dm/tag.c b/test/dm/tag.c
new file mode 100644
index ..8289954e7c26
--- /dev/null
+++ b/test/dm/tag.c
@@ -0,0 +1,84 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DM tag test
+ *
+ * Copyright (c) 2021 Linaro Limited
+ * Author: AKASHI Takahiro
+ */
+
+#include
+#include
+#include /* DM_TEST() */
+#include /* struct unit_test_state */
+#include /* assertions */
+
+/*
+ * Test dm_tag_ptr() API
+ */
+static int dm_test_tag_ptr(struct unit_test_state *uts)
+{
+ ulong val;
+ void *ptr = NULL;
+
+ ut_assertok(dev_tag_set_ptr(uts->root, DM_TAG_EFI, &val));
+
+ ut_assertok(dev_tag_get_ptr(uts->root, DM_TAG_EFI, &ptr));
+
+ ut_asserteq_ptr(&val, ptr);
+
+ ut_assertok(dev_tag_del(uts->root, DM_TAG_EFI));
+
+ return 0;
+}
+
+DM_TEST(dm_test_tag_ptr, 0);
+
+/*
+ * Test dm_tag_val() API
+ */
+static int dm_test_tag_val(struct unit_test_state *uts)
+{
+ ulong val1 = 0x12345678, val2 = 0;
+
+ ut_assertok(dev_tag_set_val(uts->root, DM_TAG_EFI, val1));
+
+ ut_assertok(dev_tag_get_val(uts->root, DM_TAG_EFI, &val2));
+
+ ut_asserteq_64(val1, val2);
+
+ ut_assertok(dev_tag_del(uts->root, DM_TAG_EFI));
+
+ return 0;
+}
+
+DM_TEST(dm_test_tag_val, 0);
+
+/*
+ * Test against an invalid tag
+ */
+static int dm_test_tag_inval(struct unit_test_state *uts)
+{
+ ulong val;
+
+ ut_asserteq(-EINVAL, dev_tag_set_ptr(uts->root, DM_TAG_COUNT, &val));
+
+ return 0;
+}
+
+DM_TEST(dm_test_tag_inval, 0);
+
+/*
+ * Test dm_tag_del_all() AP:
+ */
+static int dm_test_tag_del_all(struct unit_test_state *uts)
+{
+ ulong val;
+
+ ut_assertok(dev_tag_set_ptr(uts->root, DM_TAG_EFI, &val));
+
+ ut_assertok(dev_tag_del_all(uts->root));
+
+ return 0;
+}
+
+DM_TEST(dm_test_tag_del_all, 0);
--
2.33.0
[PATCH v3 09/19] dm: tag: add some document
Some basic stuff about tag support is explained under doc/devlop/driver-model. Signed-off-by: AKASHI Takahiro Reviewed-by: Simon Glass --- doc/develop/driver-model/design.rst | 20 1 file changed, 20 insertions(+) diff --git a/doc/develop/driver-model/design.rst b/doc/develop/driver-model/design.rst index b0e6337030a1..3e88dc40e6fd 100644 --- a/doc/develop/driver-model/design.rst +++ b/doc/develop/driver-model/design.rst @@ -1042,6 +1042,26 @@ data structure might be worthwhile in some rare cases, once we understand what the bottlenecks are. +Tag Support +--- + +It is sometimes useful for a subsystem to associate its own private +data (or object) to a DM device, i.e. struct udevice, to support +additional features. + +Tag support in driver model will give us the ability to do so dynamically +instead of modifying "udevice" data structure. In the initial release, we +will support two type of attributes: +- a pointer with dm_tag_set_ptr(), and +- an unsigned long with dm_tag_set_val() + +For example, UEFI subsystem utilizes the feature to maintain efi_disk +objects depending on linked udevice's lifecycle. + +While the current implementation is quite simple, it will get evolved +as the feature is more extensively used in U-Boot subsystems. + + Changes since v1 -- 2.33.0
[PATCH v3 11/19] dm: disk: add UCLASS_PARTITION
With this new function, UCLASS_PARTITION devices will be created as
child nodes of UCLASS_BLK device.
Signed-off-by: AKASHI Takahiro
---
disk/Makefile | 3 +
disk/disk-uclass.c | 153 +
include/dm/uclass-id.h | 1 +
include/part.h | 11 +++
4 files changed, 168 insertions(+)
create mode 100644 disk/disk-uclass.c
diff --git a/disk/Makefile b/disk/Makefile
index 6ce5a687b36c..ec37b74f5f40 100644
--- a/disk/Makefile
+++ b/disk/Makefile
@@ -6,6 +6,9 @@
#ccflags-y += -DET_DEBUG -DDEBUG
obj-$(CONFIG_PARTITIONS) += part.o
+ifdef CONFIG_$(SPL_)BLK
+obj-$(CONFIG_PARTITIONS) += disk-uclass.o
+endif
obj-$(CONFIG_$(SPL_)MAC_PARTITION) += part_mac.o
obj-$(CONFIG_$(SPL_)DOS_PARTITION) += part_dos.o
obj-$(CONFIG_$(SPL_)ISO_PARTITION) += part_iso.o
diff --git a/disk/disk-uclass.c b/disk/disk-uclass.c
new file mode 100644
index ..4918a2f72d1e
--- /dev/null
+++ b/disk/disk-uclass.c
@@ -0,0 +1,153 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Software partition device (UCLASS_PARTITION)
+ *
+ * Copyright (c) 2021 Linaro Limited
+ * Author: AKASHI Takahiro
+ */
+
+#define LOG_CATEGORY UCLASS_PARTITION
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+int part_create_block_devices(struct udevice *blk_dev)
+{
+ int part, count;
+ struct blk_desc *desc = dev_get_uclass_plat(blk_dev);
+ struct disk_partition info;
+ struct disk_part *part_data;
+ char devname[32];
+ struct udevice *dev;
+ int ret;
+
+ if (!CONFIG_IS_ENABLED(PARTITIONS) ||
+ !CONFIG_IS_ENABLED(HAVE_BLOCK_DEVICE))
+ return 0;
+
+ if (device_get_uclass_id(blk_dev) != UCLASS_BLK)
+ return 0;
+
+ /* Add devices for each partition */
+ for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
+ if (part_get_info(desc, part, &info))
+ continue;
+ snprintf(devname, sizeof(devname), "%s:%d", blk_dev->name,
+part);
+
+ ret = device_bind_driver(blk_dev, "blk_partition",
+strdup(devname), &dev);
+ if (ret)
+ return ret;
+
+ part_data = dev_get_uclass_plat(dev);
+ part_data->partnum = part;
+ part_data->gpt_part_info = info;
+ count++;
+
+ ret = device_probe(dev);
+ if (ret) {
+ debug("Can't probe\n");
+ count--;
+ device_unbind(dev);
+
+ continue;
+ }
+ }
+ debug("%s: %d partitions found in %s\n", __func__, count,
+ blk_dev->name);
+
+ return 0;
+}
+
+static ulong blk_part_read(struct udevice *dev, lbaint_t start,
+ lbaint_t blkcnt, void *buffer)
+{
+ struct udevice *parent;
+ struct disk_part *part;
+ const struct blk_ops *ops;
+
+ parent = dev_get_parent(dev);
+ ops = blk_get_ops(parent);
+ if (!ops->read)
+ return -ENOSYS;
+
+ part = dev_get_uclass_plat(dev);
+ if (start >= part->gpt_part_info.size)
+ return 0;
+
+ if ((start + blkcnt) > part->gpt_part_info.size)
+ blkcnt = part->gpt_part_info.size - start;
+ start += part->gpt_part_info.start;
+
+ return ops->read(parent, start, blkcnt, buffer);
+}
+
+static ulong blk_part_write(struct udevice *dev, lbaint_t start,
+ lbaint_t blkcnt, const void *buffer)
+{
+ struct udevice *parent;
+ struct disk_part *part;
+ const struct blk_ops *ops;
+
+ parent = dev_get_parent(dev);
+ ops = blk_get_ops(parent);
+ if (!ops->write)
+ return -ENOSYS;
+
+ part = dev_get_uclass_plat(dev);
+ if (start >= part->gpt_part_info.size)
+ return 0;
+
+ if ((start + blkcnt) > part->gpt_part_info.size)
+ blkcnt = part->gpt_part_info.size - start;
+ start += part->gpt_part_info.start;
+
+ return ops->write(parent, start, blkcnt, buffer);
+}
+
+static ulong blk_part_erase(struct udevice *dev, lbaint_t start,
+ lbaint_t blkcnt)
+{
+ struct udevice *parent;
+ struct disk_part *part;
+ const struct blk_ops *ops;
+
+ parent = dev_get_parent(dev);
+ ops = blk_get_ops(parent);
+ if (!ops->erase)
+ return -ENOSYS;
+
+ part = dev_get_uclass_plat(dev);
+ if (start >= part->gpt_part_info.size)
+ return 0;
+
+ if ((start + blkcnt) > part->gpt_part_info.size)
+ blkcnt = part->gpt_part_info.size - start;
+ start += part->gpt_part_info.start;
+
+ return ops->erase(parent, start, blkcnt);
+}
+
+static const struct blk_ops blk_p
[PATCH v3 12/19] dm: blk: add a device-probe hook for scanning disk partitions
Now that all the block device drivers have enable a probe hook, we will
call part_create_block_devices() to enumerate all the partitions and
create associated udevices when a block device is detected.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Simon Glass
---
drivers/block/blk-uclass.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
index bee1cd6f0d80..58dc74e71f1e 100644
--- a/drivers/block/blk-uclass.c
+++ b/drivers/block/blk-uclass.c
@@ -717,6 +717,10 @@ static int blk_post_probe(struct udevice *dev)
struct blk_desc *desc = dev_get_uclass_plat(dev);
part_init(desc);
+
+ if (desc->part_type != PART_TYPE_UNKNOWN &&
+ part_create_block_devices(dev))
+ debug("*** creating partitions failed\n");
}
return 0;
--
2.33.0
[PATCH v3 14/19] efi_loader: disk: a helper function to create efi_disk objects from udevice
Add efi_disk_probe() function.
This function creates an efi_disk object for a raw disk device (UCLASS_BLK)
and additional objects for related partitions (UCLASS_PARTITION).
So this function is expected to be called through driver model's "probe"
interface every time one raw disk device is detected and activated.
We assume that partition devices (UCLASS_PARTITION) have been created
when this function is invoked.
Signed-off-by: AKASHI Takahiro
---
include/efi_loader.h | 4 +-
lib/efi_loader/Kconfig | 3 +
lib/efi_loader/efi_disk.c | 201 +++--
lib/efi_loader/efi_setup.c | 4 +-
4 files changed, 133 insertions(+), 79 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index a9075c992687..24ec692c4d09 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -523,8 +523,8 @@ void efi_carve_out_dt_rsv(void *fdt);
void efi_try_purge_kaslr_seed(void *fdt);
/* Called by bootefi to make console interface available */
efi_status_t efi_console_register(void);
-/* Called by bootefi to make all disk storage accessible as EFI objects */
-efi_status_t efi_disk_register(void);
+/* Called by efi_init_obj_list() to initialize efi_disks */
+efi_status_t efi_disk_init(void);
/* Called by efi_init_obj_list() to install EFI_RNG_PROTOCOL */
efi_status_t efi_rng_register(void);
/* Called by efi_init_obj_list() to install EFI_TCG2_PROTOCOL */
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index e5e35fe51f65..7ffd59759359 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -14,6 +14,8 @@ config EFI_LOADER
depends on DM_ETH || !NET
depends on !EFI_APP
default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8
+ select DM_EVENT
+ select EVENT_DYNAMIC
select LIB_UUID
select PARTITION_UUIDS
select HAVE_BLOCK_DEVICE
@@ -41,6 +43,7 @@ config CMD_BOOTEFI_BOOTMGR
config EFI_SETUP_EARLY
bool
+ default y
choice
prompt "Store for non-volatile UEFI variables"
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index 45127d176869..bf9824b9b1a4 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -10,6 +10,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
#include
@@ -487,103 +490,153 @@ error:
return ret;
}
-/**
- * efi_disk_create_partitions() - create handles and protocols for partitions
+/*
+ * Create a handle for a whole raw disk
+ *
+ * @devuclass device (UCLASS_BLK)
*
- * Create handles and protocols for the partitions of a block device.
+ * Create an efi_disk object which is associated with @dev.
+ * The type of @dev must be UCLASS_BLK.
*
- * @parent:handle of the parent disk
- * @desc: block device
- * @if_typename: interface type
- * @diskid:device number
- * @pdevname: device name
- * Return: number of partitions created
+ * @return 0 on success, -1 otherwise
*/
-int efi_disk_create_partitions(efi_handle_t parent, struct blk_desc *desc,
- const char *if_typename, int diskid,
- const char *pdevname)
+static int efi_disk_create_raw(struct udevice *dev)
{
- int disks = 0;
- char devname[32] = { 0 }; /* dp->str is u16[32] long */
- int part;
- struct efi_device_path *dp = NULL;
+ struct efi_disk_obj *disk;
+ struct blk_desc *desc;
+ const char *if_typename;
+ int diskid;
efi_status_t ret;
- struct efi_handler *handler;
- /* Get the device path of the parent */
- ret = efi_search_protocol(parent, &efi_guid_device_path, &handler);
- if (ret == EFI_SUCCESS)
- dp = handler->protocol_interface;
-
- /* Add devices for each partition */
- for (part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
- struct disk_partition info;
-
- if (part_get_info(desc, part, &info))
- continue;
- snprintf(devname, sizeof(devname), "%s:%x", pdevname,
-part);
- ret = efi_disk_add_dev(parent, dp, if_typename, desc, diskid,
- &info, part, NULL);
- if (ret != EFI_SUCCESS) {
- log_err("Adding partition %s failed\n", pdevname);
- continue;
- }
- disks++;
+ desc = dev_get_uclass_plat(dev);
+ if_typename = blk_get_if_type_name(desc->if_type);
+ diskid = desc->devnum;
+
+ ret = efi_disk_add_dev(NULL, NULL, if_typename, desc,
+ diskid, NULL, 0, &disk);
+ if (ret != EFI_SUCCESS) {
+ if (ret == EFI_NOT_READY)
+ log_notice("Disk %s not ready\n", dev->name);
+ else
+ log_err("Adding disk for
[PATCH v3 15/19] efi_loader: disk: a helper function to delete efi_disk objects
This function is expected to be called, in particular from dm's pre_remove
hook, when associated block devices no longer exist.
Add efi_disk_remove() function.
This function removes an efi_disk object for a raw disk device (UCLASS_BLK)
and related objects for its partitions (UCLASS_PARTITION).
So this function is expected to be called through driver model's "remove"
interface every time a raw disk device is to be disconnected.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Simon Glass
---
lib/efi_loader/efi_disk.c | 88 +++
1 file changed, 88 insertions(+)
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index bf9824b9b1a4..53bee6654421 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -627,6 +627,87 @@ static int efi_disk_probe(void *ctx, struct event *event)
return 0;
}
+/*
+ * Delete an efi_disk object for a whole raw disk
+ *
+ * @devuclass device (UCLASS_BLK)
+ *
+ * Delete an efi_disk object which is associated with @dev.
+ * The type of @dev must be UCLASS_BLK.
+ *
+ * @return 0 on success, -1 otherwise
+ */
+static int efi_disk_delete_raw(struct udevice *dev)
+{
+ efi_handle_t handle;
+ struct efi_disk_obj *diskobj;
+
+ if (dev_tag_get_ptr(dev, DM_TAG_EFI, (void **)&handle))
+ return -1;
+
+ diskobj = container_of(handle, struct efi_disk_obj, header);
+ efi_free_pool(diskobj->dp);
+
+ efi_delete_handle(handle);
+ dev_tag_del(dev, DM_TAG_EFI);
+
+ return 0;
+}
+
+/*
+ * Delete an efi_disk object for a disk partition
+ *
+ * @devuclass device (UCLASS_PARTITION)
+ *
+ * Delete an efi_disk object which is associated with @dev.
+ * The type of @dev must be UCLASS_PARTITION.
+ *
+ * @return 0 on success, -1 otherwise
+ */
+static int efi_disk_delete_part(struct udevice *dev)
+{
+ efi_handle_t handle;
+ struct efi_disk_obj *diskobj;
+
+ if (dev_tag_get_ptr(dev, DM_TAG_EFI, (void **)&handle))
+ return -1;
+
+ diskobj = container_of(handle, struct efi_disk_obj, header);
+
+ efi_free_pool(diskobj->dp);
+ efi_delete_handle(handle);
+ dev_tag_del(dev, DM_TAG_EFI);
+
+ return 0;
+}
+
+/*
+ * Delete an efi_disk object for a block device
+ *
+ * @devuclass device (UCLASS_BLK or UCLASS_PARTITION)
+ *
+ * Delete an efi_disk object which is associated with @dev.
+ * The type of @dev must be either UCLASS_BLK or UCLASS_PARTITION.
+ * This function is expected to be called at EV_PM_PRE_REMOVE.
+ *
+ * @return 0 on success, -1 otherwise
+ */
+static int efi_disk_remove(void *ctx, struct event *event)
+{
+ enum uclass_id id;
+ struct udevice *dev;
+
+ dev = event->data.dm.dev;
+ id = device_get_uclass_id(dev);
+
+ if (id == UCLASS_BLK)
+ return efi_disk_delete_raw(dev);
+ else if (id == UCLASS_PARTITION)
+ return efi_disk_delete_part(dev);
+ else
+ return 0;
+}
+
efi_status_t efi_disk_init(void)
{
int ret;
@@ -638,6 +719,13 @@ efi_status_t efi_disk_init(void)
return EFI_OUT_OF_RESOURCES;
}
+ ret = event_register("efi_disk del", EVT_DM_PRE_REMOVE,
+efi_disk_remove, NULL);
+ if (ret) {
+ log_err("Event registration for efi_disk del failed\n");
+ return EFI_OUT_OF_RESOURCES;
+ }
+
return EFI_SUCCESS;
}
--
2.33.0
[PATCH v3 16/19] dm: disk: add read/write interfaces with udevice
In include/blk.h, Simon suggested:
===>
/*
* These functions should take struct udevice instead of struct blk_desc,
* but this is convenient for migration to driver model. Add a 'd' prefix
* to the function operations, so that blk_read(), etc. can be reserved for
* functions with the correct arguments.
*/
unsigned long blk_dread(struct blk_desc *block_dev, lbaint_t start,
lbaint_t blkcnt, void *buffer);
unsigned long blk_dwrite(struct blk_desc *block_dev, lbaint_t start,
lbaint_t blkcnt, const void *buffer);
unsigned long blk_derase(struct blk_desc *block_dev, lbaint_t start,
lbaint_t blkcnt);
<===
So new interfaces are provided with this patch.
They are expected to be used everywhere in U-Boot at the end.
The exceptions are block device drivers, partition drivers and efi_disk
which should know details of blk_desc structure.
Signed-off-by: AKASHI Takahiro
---
disk/disk-uclass.c | 94 ++
include/part.h | 7
2 files changed, 101 insertions(+)
diff --git a/disk/disk-uclass.c b/disk/disk-uclass.c
index 4918a2f72d1e..72ff62ebf581 100644
--- a/disk/disk-uclass.c
+++ b/disk/disk-uclass.c
@@ -146,6 +146,100 @@ U_BOOT_DRIVER(blk_partition) = {
.ops= &blk_part_ops,
};
+/*
+ * BLOCK IO APIs
+ */
+static struct blk_desc *dev_get_blk(struct udevice *dev)
+{
+ struct blk_desc *block_dev;
+
+ switch (device_get_uclass_id(dev)) {
+ /*
+* We won't support UCLASS_BLK with dev_* interfaces.
+*/
+ case UCLASS_PARTITION:
+ block_dev = dev_get_uclass_plat(dev_get_parent(dev));
+ break;
+ default:
+ block_dev = NULL;
+ break;
+ }
+
+ return block_dev;
+}
+
+unsigned long dev_read(struct udevice *dev, lbaint_t start,
+ lbaint_t blkcnt, void *buffer)
+{
+ struct blk_desc *block_dev;
+ const struct blk_ops *ops;
+ struct disk_part *part;
+ lbaint_t start_in_disk;
+ ulong blks_read;
+
+ block_dev = dev_get_blk(dev);
+ if (!block_dev)
+ return -ENOSYS;
+
+ ops = blk_get_ops(dev);
+ if (!ops->read)
+ return -ENOSYS;
+
+ start_in_disk = start;
+ if (device_get_uclass_id(dev) == UCLASS_PARTITION) {
+ part = dev_get_uclass_plat(dev);
+ start_in_disk += part->gpt_part_info.start;
+ }
+
+ if (blkcache_read(block_dev->if_type, block_dev->devnum,
+ start_in_disk, blkcnt, block_dev->blksz, buffer))
+ return blkcnt;
+ blks_read = ops->read(dev, start, blkcnt, buffer);
+ if (blks_read == blkcnt)
+ blkcache_fill(block_dev->if_type, block_dev->devnum,
+ start_in_disk, blkcnt, block_dev->blksz, buffer);
+
+ return blks_read;
+}
+
+unsigned long dev_write(struct udevice *dev, lbaint_t start,
+ lbaint_t blkcnt, const void *buffer)
+{
+ struct blk_desc *block_dev;
+ const struct blk_ops *ops;
+
+ block_dev = dev_get_blk(dev);
+ if (!block_dev)
+ return -ENOSYS;
+
+ ops = blk_get_ops(dev);
+ if (!ops->write)
+ return -ENOSYS;
+
+ blkcache_invalidate(block_dev->if_type, block_dev->devnum);
+
+ return ops->write(dev, start, blkcnt, buffer);
+}
+
+unsigned long dev_erase(struct udevice *dev, lbaint_t start,
+ lbaint_t blkcnt)
+{
+ struct blk_desc *block_dev;
+ const struct blk_ops *ops;
+
+ block_dev = dev_get_blk(dev);
+ if (!block_dev)
+ return -ENOSYS;
+
+ ops = blk_get_ops(dev);
+ if (!ops->erase)
+ return -ENOSYS;
+
+ blkcache_invalidate(block_dev->if_type, block_dev->devnum);
+
+ return ops->erase(dev, start, blkcnt);
+}
+
UCLASS_DRIVER(partition) = {
.id = UCLASS_PARTITION,
.per_device_plat_auto = sizeof(struct disk_part),
diff --git a/include/part.h b/include/part.h
index 95e30e60af10..d4e5cd921db1 100644
--- a/include/part.h
+++ b/include/part.h
@@ -264,6 +264,13 @@ struct udevice;
*/
int part_create_block_devices(struct udevice *blk_dev);
+unsigned long dev_read(struct udevice *dev, lbaint_t start,
+ lbaint_t blkcnt, void *buffer);
+unsigned long dev_write(struct udevice *dev, lbaint_t start,
+ lbaint_t blkcnt, const void *buffer);
+unsigned long dev_erase(struct udevice *dev, lbaint_t start,
+ lbaint_t blkcnt);
+
#else
static inline struct blk_desc *blk_get_dev(const char *ifname, int dev)
{ return NULL; }
--
2.33.0
[PATCH v3 17/19] efi_loader: disk: use udevice instead of blk_desc
In most of all cases, we can avoid using blk_desc which is expected
to be private to udevice(UCLASS_BLK), that is, the data should not
be manipulated outside the device driver unless really needed.
Now efi_disk's internally use dev_read/write() interfaces.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Simon Glass
---
lib/efi_loader/efi_disk.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index 53bee6654421..0b4f7a9ca317 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -36,7 +36,7 @@ const efi_guid_t efi_system_partition_guid =
PARTITION_SYSTEM_GUID;
* @part: partition
* @volume:simple file system protocol of the partition
* @offset:offset into disk for simple partition
- * @desc: internal block device descriptor
+ * @dev: associated DM device
*/
struct efi_disk_obj {
struct efi_object header;
@@ -48,7 +48,7 @@ struct efi_disk_obj {
unsigned int part;
struct efi_simple_file_system_protocol *volume;
lbaint_t offset;
- struct blk_desc *desc;
+ struct udevice *dev; /* TODO: move it to efi_object */
};
/**
@@ -83,14 +83,12 @@ static efi_status_t efi_disk_rw_blocks(struct efi_block_io
*this,
void *buffer, enum efi_disk_direction direction)
{
struct efi_disk_obj *diskobj;
- struct blk_desc *desc;
int blksz;
int blocks;
unsigned long n;
diskobj = container_of(this, struct efi_disk_obj, ops);
- desc = (struct blk_desc *) diskobj->desc;
- blksz = desc->blksz;
+ blksz = diskobj->media.block_size;
blocks = buffer_size / blksz;
lba += diskobj->offset;
@@ -102,9 +100,9 @@ static efi_status_t efi_disk_rw_blocks(struct efi_block_io
*this,
return EFI_BAD_BUFFER_SIZE;
if (direction == EFI_DISK_READ)
- n = blk_dread(desc, lba, blocks, buffer);
+ n = dev_read(diskobj->dev, lba, blocks, buffer);
else
- n = blk_dwrite(desc, lba, blocks, buffer);
+ n = dev_write(diskobj->dev, lba, blocks, buffer);
/* We don't do interrupts, so check for timers cooperatively */
efi_timer_check();
@@ -446,7 +444,6 @@ static efi_status_t efi_disk_add_dev(
diskobj->ops = block_io_disk_template;
diskobj->ifname = if_typename;
diskobj->dev_index = dev_index;
- diskobj->desc = desc;
/* Fill in EFI IO Media info (for read/write callbacks) */
diskobj->media.removable_media = desc->removable;
@@ -522,6 +519,7 @@ static int efi_disk_create_raw(struct udevice *dev)
return -1;
}
+ disk->dev = dev;
if (dev_tag_set_ptr(dev, DM_TAG_EFI, &disk->header)) {
efi_free_pool(disk->dp);
efi_delete_handle(&disk->header);
@@ -578,6 +576,7 @@ static int efi_disk_create_part(struct udevice *dev)
log_err("Adding partition for %s failed\n", dev->name);
return -1;
}
+ disk->dev = dev;
if (dev_tag_set_ptr(dev, DM_TAG_EFI, &disk->header)) {
efi_free_pool(disk->dp);
efi_delete_handle(&disk->header);
@@ -740,20 +739,22 @@ bool efi_disk_is_system_part(efi_handle_t handle)
{
struct efi_handler *handler;
struct efi_disk_obj *diskobj;
- struct disk_partition info;
+ struct udevice *dev;
+ struct disk_part *part;
efi_status_t ret;
- int r;
/* check if this is a block device */
ret = efi_search_protocol(handle, &efi_block_io_guid, &handler);
if (ret != EFI_SUCCESS)
return false;
+ /* find a partition udevice */
diskobj = container_of(handle, struct efi_disk_obj, header);
-
- r = part_get_info(diskobj->desc, diskobj->part, &info);
- if (r)
+ dev = diskobj->dev;
+ if (!dev || dev->driver->id != UCLASS_PARTITION)
return false;
- return !!(info.bootable & PART_EFI_SYSTEM_PARTITION);
+ part = dev_get_uclass_plat(dev);
+
+ return !!(part->gpt_part_info.bootable & PART_EFI_SYSTEM_PARTITION);
}
--
2.33.0
[PATCH v3 18/19] efi_loader: disk: not create BLK device for BLK(IF_TYPE_EFI_LOADER) devices
When we create an efi_disk device with an UEFI application using driver
binding protocol, the 'efi_driver' framework tries to create
a corresponding block device(UCLASS_BLK/IF_TYPE_EFI). This will lead to
calling a PROBE callback, efi_disk_probe().
In this case, however, we don't need to create another "efi_disk" device
as we already have this device instance.
So we should avoid recursively invoke further processing in the callback
function.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Simon Glass
---
lib/efi_loader/efi_disk.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index 0b4f7a9ca317..7c3eebf31e22 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -603,6 +603,7 @@ static int efi_disk_probe(void *ctx, struct event *event)
{
struct udevice *dev;
enum uclass_id id;
+ struct blk_desc *desc;
struct udevice *child;
int ret;
@@ -613,9 +614,16 @@ static int efi_disk_probe(void *ctx, struct event *event)
if (id != UCLASS_BLK)
return 0;
- ret = efi_disk_create_raw(dev);
- if (ret)
- return -1;
+ /*
+* avoid creating duplicated objects now that efi_driver
+* has already created an efi_disk at this moment.
+*/
+ desc = dev_get_uclass_plat(dev);
+ if (desc->if_type != IF_TYPE_EFI_LOADER) {
+ ret = efi_disk_create_raw(dev);
+ if (ret)
+ return -1;
+ }
device_foreach_child(child, dev) {
ret = efi_disk_create_part(child);
@@ -639,13 +647,17 @@ static int efi_disk_probe(void *ctx, struct event *event)
static int efi_disk_delete_raw(struct udevice *dev)
{
efi_handle_t handle;
+ struct blk_desc *desc;
struct efi_disk_obj *diskobj;
if (dev_tag_get_ptr(dev, DM_TAG_EFI, (void **)&handle))
return -1;
- diskobj = container_of(handle, struct efi_disk_obj, header);
- efi_free_pool(diskobj->dp);
+ desc = dev_get_uclass_plat(dev);
+ if (desc->if_type != IF_TYPE_EFI_LOADER) {
+ diskobj = container_of(handle, struct efi_disk_obj, header);
+ efi_free_pool(diskobj->dp);
+ }
efi_delete_handle(handle);
dev_tag_del(dev, DM_TAG_EFI);
--
2.33.0
[PATCH v3 19/19] efi_driver: align with efi_disk-dm integration
With DM-efi_disk integration, we don't need to explicitly call
efi_disk_create_partitions().
The only thing to do is to associate an efi_disk object to
the corresponding udevice as we skip most of processing in
efi_disk_probe() by the previous commit ("efi_loader: disk: not create
BLK device for BLK(IF_TYPE_EFI) devices").
Signed-off-by: AKASHI Takahiro
Reviewed-by: Simon Glass
---
lib/efi_driver/efi_block_device.c | 34 +--
1 file changed, 10 insertions(+), 24 deletions(-)
diff --git a/lib/efi_driver/efi_block_device.c
b/lib/efi_driver/efi_block_device.c
index 04cb3ef0d4e5..5baa6f87a375 100644
--- a/lib/efi_driver/efi_block_device.c
+++ b/lib/efi_driver/efi_block_device.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
/*
* EFI attributes of the udevice handled by this driver.
@@ -106,25 +107,6 @@ static ulong efi_bl_write(struct udevice *dev, lbaint_t
blknr, lbaint_t blkcnt,
return blkcnt;
}
-/**
- * Create partions for the block device.
- *
- * @handle:EFI handle of the block device
- * @dev: udevice of the block device
- * Return: number of partitions created
- */
-static int efi_bl_bind_partitions(efi_handle_t handle, struct udevice *dev)
-{
- struct blk_desc *desc;
- const char *if_typename;
-
- desc = dev_get_uclass_plat(dev);
- if_typename = blk_get_if_type_name(desc->if_type);
-
- return efi_disk_create_partitions(handle, desc, if_typename,
- desc->devnum, dev->name);
-}
-
/**
* Create a block device for a handle
*
@@ -139,7 +121,6 @@ static int efi_bl_bind(efi_handle_t handle, void *interface)
char *name;
struct efi_object *obj = efi_search_obj(handle);
struct efi_block_io *io = interface;
- int disks;
struct efi_blk_plat *plat;
EFI_PRINT("%s: handle %p, interface %p\n", __func__, handle, io);
@@ -173,15 +154,20 @@ static int efi_bl_bind(efi_handle_t handle, void
*interface)
plat->handle = handle;
plat->io = interface;
+ /*
+* FIXME: necessary because we won't do almost nothing in
+* efi_disk_create() when called from device_probe().
+*/
+ ret = dev_tag_set_ptr(bdev, DM_TAG_EFI, handle);
+ if (ret)
+ /* FIXME: cleanup for bdev */
+ return ret;
+
ret = device_probe(bdev);
if (ret)
return ret;
EFI_PRINT("%s: block device '%s' created\n", __func__, bdev->name);
- /* Create handles for the partions of the block device */
- disks = efi_bl_bind_partitions(handle, bdev);
- EFI_PRINT("Found %d partitions\n", disks);
-
return 0;
}
--
2.33.0
Re: [PATCH u-boot-mvebu v3 0/5] arm: mvebu: a37xx: Add support for reading OTP
Hello! Is v3 series Ok now? On Wednesday 23 February 2022 14:15:44 Pali Rohár wrote: > Add support for reading NB fuse OTP, SB fuse OTP and Security OTP > values via U-Boot fuse API on Armada 37xx boards. > > Changes in v3: > * Updated comment in patch 5/5 about MBOX_CMD_OTP_READ command > * In patch 5/5 fixed number of output arguments for MBOX_CMD_OTP_READ_32B > command > > Pali Rohár (5): > arm: mvebu: a37xx: Add support for reading NB and SB fuse OTP value > arm: mvebu: a37xx: Enable fuse command on all Armada 3720 boards > arm: mvebu: a37xx: Move generic mbox code to arch/arm/mach-mvebu > arm: mvebu: a37xx: Extend mbox_do_cmd() code > arm: mvebu: a37xx: Add support for reading Security OTP values > > arch/arm/mach-mvebu/Kconfig | 1 + > arch/arm/mach-mvebu/Makefile| 3 + > arch/arm/mach-mvebu/armada3700/Makefile | 3 +- > arch/arm/mach-mvebu/armada3700/efuse.c | 171 > arch/arm/mach-mvebu/armada3700/mbox.c | 83 ++ > arch/arm/mach-mvebu/include/mach/mbox.h | 40 + > board/CZ.NIC/turris_mox/mox_sp.c| 73 + > configs/mvebu_db-88f3720_defconfig | 2 + > configs/mvebu_espressobin-88f3720_defconfig | 2 + > configs/turris_mox_defconfig| 2 + > configs/uDPU_defconfig | 2 + > 11 files changed, 311 insertions(+), 71 deletions(-) > create mode 100644 arch/arm/mach-mvebu/armada3700/efuse.c > create mode 100644 arch/arm/mach-mvebu/armada3700/mbox.c > create mode 100644 arch/arm/mach-mvebu/include/mach/mbox.h > > -- > 2.20.1 >
Re: [PATCH] board: .gitignore: replace dsdt.c by dsdt_generated.c
On 3/8/22 10:37, Philippe Reynes wrote:
Since commit 5d94cbd1dca7 ("scripts: Makefile.lib: generate
dsdt_generated.c instead of dsdt.c"), the file generated
is named dsdt_generated.c instead of dsdt.c.
So all files .gitignore referencing dsdt.c should be
upated with dsdt_generated.c.
Signed-off-by: Philippe Reynes
Reviewed-by: Heinrich Schuchardt
Re: [PATCH u-boot-mvebu v3 0/5] arm: mvebu: a37xx: Add support for reading OTP
On 3/8/22 12:42, Pali Rohár wrote: Hello! Is v3 series Ok now? I don't have any objections. I plan to pull this patch series in the next merge window, as we are at rc3 now already. Thanks, Stefan On Wednesday 23 February 2022 14:15:44 Pali Rohár wrote: Add support for reading NB fuse OTP, SB fuse OTP and Security OTP values via U-Boot fuse API on Armada 37xx boards. Changes in v3: * Updated comment in patch 5/5 about MBOX_CMD_OTP_READ command * In patch 5/5 fixed number of output arguments for MBOX_CMD_OTP_READ_32B command Pali Rohár (5): arm: mvebu: a37xx: Add support for reading NB and SB fuse OTP value arm: mvebu: a37xx: Enable fuse command on all Armada 3720 boards arm: mvebu: a37xx: Move generic mbox code to arch/arm/mach-mvebu arm: mvebu: a37xx: Extend mbox_do_cmd() code arm: mvebu: a37xx: Add support for reading Security OTP values arch/arm/mach-mvebu/Kconfig | 1 + arch/arm/mach-mvebu/Makefile| 3 + arch/arm/mach-mvebu/armada3700/Makefile | 3 +- arch/arm/mach-mvebu/armada3700/efuse.c | 171 arch/arm/mach-mvebu/armada3700/mbox.c | 83 ++ arch/arm/mach-mvebu/include/mach/mbox.h | 40 + board/CZ.NIC/turris_mox/mox_sp.c| 73 + configs/mvebu_db-88f3720_defconfig | 2 + configs/mvebu_espressobin-88f3720_defconfig | 2 + configs/turris_mox_defconfig| 2 + configs/uDPU_defconfig | 2 + 11 files changed, 311 insertions(+), 71 deletions(-) create mode 100644 arch/arm/mach-mvebu/armada3700/efuse.c create mode 100644 arch/arm/mach-mvebu/armada3700/mbox.c create mode 100644 arch/arm/mach-mvebu/include/mach/mbox.h -- 2.20.1 Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 1/3] tools: kwboot: Allow to specify custom baudrate only in supported operations
On 3/7/22 19:03, Pali Rohár wrote:
Custom baudrate different than 115200 may be specified only when kwboot is
not going to send boot/debug message pattern or when it is going to send
boot message pattern with image file (in which case baudrate change happens
after sending kwbimage header). BootROM detects boot/debug message pattern
only at baudrate 115200.
Signed-off-by: Pali Rohár
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
tools/kwboot.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 69d1be0f4823..986f27c2012a 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -2133,6 +2133,12 @@ main(int argc, char **argv)
if (optind != argc)
goto usage;
+ /* boot and debug message use baudrate 115200 */
+ if (((bootmsg && !imgpath) || debugmsg) && baudrate != 115200) {
+ fprintf(stderr, "Baudrate other than 115200 cannot be used for this
operation.\n");
+ goto usage;
+ }
+
tty = kwboot_open_tty(ttypath, imgpath ? 115200 : baudrate);
if (tty < 0) {
perror(ttypath);
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 2/3] tools: kwboot: Check if baudrate value is supported before sending image
On 3/7/22 19:03, Pali Rohár wrote:
Call kwboot_open_tty() which baudrate value which was specified at the
command line by option -B. This function returns error if baudrate is not
supported by selected tty device.
Initial baudrate for image transfer is always 115200, so call
kwboot_tty_change_baudrate() with value 115200 immediately after
kwboot_open_tty() if baudrate specified by option -B is different than
115200.
This makes kwboot fail immediately, informing that baudrate is unsupported,
instead of failing only after the first part of image is already sent.
Signed-off-by: Pali Rohár
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
tools/kwboot.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 986f27c2012a..3b45e19a30aa 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -2139,12 +2139,24 @@ main(int argc, char **argv)
goto usage;
}
- tty = kwboot_open_tty(ttypath, imgpath ? 115200 : baudrate);
+ tty = kwboot_open_tty(ttypath, baudrate);
if (tty < 0) {
perror(ttypath);
goto out;
}
+ /*
+* initial baudrate for image transfer is always 115200,
+* the change to different baudrate is done only after the header is
sent
+*/
+ if (imgpath && baudrate != 115200) {
+ rc = kwboot_tty_change_baudrate(tty, 115200);
+ if (rc) {
+ perror(ttypath);
+ goto out;
+ }
+ }
+
if (baudrate == 115200)
/* do not change baudrate during Xmodem to the same value */
baudrate = 0;
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 3/3] tools: kwboot: Allow to mix positional arguments with option -b
On 3/7/22 19:03, Pali Rohár wrote:
Commit 9e6d71d2b55f ("tools: kwboot: Allow to use -b without image path as
the last getopt() option") broke usage of kwboot with following arguments:
kwboot -t -B 115200 /dev/ttyUSB0 -b u-boot-spl.kwb
Fix parsing of option -b with optional argument again.
Fixes: 9e6d71d2b55f ("tools: kwboot: Allow to use -b without image path as the last
getopt() option")
Signed-off-by: Pali Rohár
Reported-by: Tony Dinh
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
Tony and Marcel, could you test this change if all your kwboot use cases
still work correctly?
---
tools/kwboot.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 3b45e19a30aa..9f2dd2de4ef5 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -2073,7 +2073,8 @@ main(int argc, char **argv)
bootmsg = 1;
if (prev_optind == optind)
goto usage;
- if (optind < argc - 1 && argv[optind] &&
argv[optind][0] != '-')
+ /* Option -b could have optional argument which specify
image path */
+ if (optind < argc && argv[optind] && argv[optind][0] !=
'-')
imgpath = argv[optind++];
break;
@@ -2128,10 +2129,19 @@ main(int argc, char **argv)
if (!bootmsg && !term && !debugmsg && !imgpath)
goto usage;
- ttypath = argv[optind++];
-
- if (optind != argc)
+ /*
+* If there is no remaining argument but optional imgpath was parsed
+* then it means that optional imgpath was eaten by getopt parser.
+* Reassing imgpath to required ttypath argument.
+*/
+ if (optind == argc && imgpath) {
+ ttypath = imgpath;
+ imgpath = NULL;
+ } else if (optind + 1 == argc) {
+ ttypath = argv[optind];
+ } else {
goto usage;
+ }
/* boot and debug message use baudrate 115200 */
if (((bootmsg && !imgpath) || debugmsg) && baudrate != 115200) {
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH] arm: a37xx: Remap IO space to bus address 0x0
On 3/7/22 19:12, Pali Rohár wrote: Remap PCI I/O space to the bus address 0x0 in the Armada 37xx device-tree in order to support legacy I/O port based cards which have hardcoded I/O ports in low address space. Some legacy PCI I/O based cards do not support 32-bit I/O addressing. Signed-off-by: Pali Rohár Reviewed-by: Stefan Roese Thanks, Stefan --- Same change was sent to linux kernel: https://lore.kernel.org/linux-arm-kernel/20220304163027.29357-1-p...@kernel.org/ --- arch/arm/dts/armada-3720-turris-mox.dts | 7 ++- arch/arm/dts/armada-37xx.dtsi | 2 +- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/arm/dts/armada-3720-turris-mox.dts b/arch/arm/dts/armada-3720-turris-mox.dts index 1fc4a30d03e7..595b4b5abba0 100644 --- a/arch/arm/dts/armada-3720-turris-mox.dts +++ b/arch/arm/dts/armada-3720-turris-mox.dts @@ -139,7 +139,9 @@ /* * U-Boot port for Turris Mox has a bug which always expects that "ranges" DT property * contains exactly 2 ranges with 3 (child) address cells, 2 (parent) address cells and -* 2 size cells and also expects that the second range starts at 16 MB offset. If these +* 2 size cells and also expects that the second range starts at 16 MB offset. Also it +* expects that first range uses same address for PCI (child) and CPU (parent) cells (so +* no remapping) and that this address is the lowest from all specified ranges. If these * conditions are not met then U-Boot crashes during loading kernel DTB file. PCIe address * space is 128 MB long, so the best split between MEM and IO is to use fixed 16 MB window * for IO and the rest 112 MB (64+32+16) for MEM. Controller supports 32-bit IO mapping. @@ -148,6 +150,9 @@ * https://source.denx.de/u-boot/u-boot/-/commit/cb2ddb291ee6fcbddd6d8f4ff49089dfe580f5d7 * https://source.denx.de/u-boot/u-boot/-/commit/c64ac3b3185aeb3846297ad7391fc6df8ecd73bf * https://source.denx.de/u-boot/u-boot/-/commit/4a82fca8e330157081fc132a591ebd99ba02ee33 +* Bug related to requirement of same child and parent addresses for first range is fixed +* in U-Boot version 2022.04 by following commit: +* https://source.denx.de/u-boot/u-boot/-/commit/1fd54253bca7d43d046bba4853fe5fafd034bc17 */ #address-cells = <3>; #size-cells = <2>; diff --git a/arch/arm/dts/armada-37xx.dtsi b/arch/arm/dts/armada-37xx.dtsi index 9fa6457facb8..0bb4f607630a 100644 --- a/arch/arm/dts/armada-37xx.dtsi +++ b/arch/arm/dts/armada-37xx.dtsi @@ -499,7 +499,7 @@ * (totaling 127 MiB) for MEM. */ ranges = <0x8200 0 0xe800 0 0xe800 0 0x07f0 /* Port 0 MEM */ - 0x8100 0 0xeff0 0 0xeff0 0 0x0010>; /* Port 0 IO*/ + 0x8100 0 0x 0 0xeff0 0 0x0010>; /* Port 0 IO */ interrupt-map-mask = <0 0 0 7>; interrupt-map = <0 0 0 1 &pcie_intc 0>, <0 0 0 2 &pcie_intc 1>, Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH] arm: kirkwood: Sheevaplug : Use Marvell uclass mvgbe and PHY driver for Ethernet
On 3/7/22 00:12, Tony Dinh wrote:
The Globalscale Technologies Sheevaplug board has the network chip
Marvell 88E1116R. Use uclass mvgbe and the compatible driver M88E1310
driver to bring up Ethernet.
- Currently, CONFIG_RESET_PHY_R symbol is used in
arch/arm/mach-kirkwood/include/mach/config.h for all Kirkwood
boards with mv8831116 PHY, with each board defines the function
reset_phy(). Undefine it for this board.
- Add board_eth_init() to use uclass mvgbe to bring up the network.
And remove ad-hoc code.
- Enable CONFIG_PHY_MARVELL to properly configure the network.
- Miscellaneous changes: Move constants to .c file and remove header file
board/Marvell/sheevaplug/sheevaplug.h, use BIT macro, and add/cleanup
comments.
Signed-off-by: Tony Dinh
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
board/Marvell/sheevaplug/sheevaplug.c | 83 +--
board/Marvell/sheevaplug/sheevaplug.h | 24
configs/sheevaplug_defconfig | 1 +
include/configs/sheevaplug.h | 17 +++---
4 files changed, 22 insertions(+), 103 deletions(-)
delete mode 100644 board/Marvell/sheevaplug/sheevaplug.h
diff --git a/board/Marvell/sheevaplug/sheevaplug.c
b/board/Marvell/sheevaplug/sheevaplug.c
index 5952d158b2..26ee39ef77 100644
--- a/board/Marvell/sheevaplug/sheevaplug.c
+++ b/board/Marvell/sheevaplug/sheevaplug.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright (C) 2021 Tony Dinh
+ * Copyright (C) 2021-2022 Tony Dinh
* (C) Copyright 2009
* Marvell Semiconductor
* Written-by: Prafulla Wadaskar
@@ -8,17 +8,21 @@
#include
#include
-#include
-#include
+#include
#include
#include
#include
#include
#include
-#include "sheevaplug.h"
+#include
DECLARE_GLOBAL_DATA_PTR;
+#define SHEEVAPLUG_OE_LOW (~(0))
+#define SHEEVAPLUG_OE_HIGH (~(0))
+#define SHEEVAPLUG_OE_VAL_LOW BIT(29) /* USB_PWEN low */
+#define SHEEVAPLUG_OE_VAL_HIGH BIT(17) /* LED pin high */
+
int board_early_init_f(void)
{
/*
@@ -88,6 +92,11 @@ int board_early_init_f(void)
return 0;
}
+int board_eth_init(struct bd_info *bis)
+{
+ return cpu_eth_init(bis);
+}
+
int board_init(void)
{
/*
@@ -95,72 +104,8 @@ int board_init(void)
*/
gd->bd->bi_arch_number = MACH_TYPE_SHEEVAPLUG;
- /* adress of boot parameters */
+ /* address of boot parameters */
gd->bd->bi_boot_params = mvebu_sdram_bar(0) + 0x100;
return 0;
}
-
-static int fdt_get_phy_addr(const char *path)
-{
- const void *fdt = gd->fdt_blob;
- const u32 *reg;
- const u32 *val;
- int node, phandle, addr;
-
- /* Find the node by its full path */
- node = fdt_path_offset(fdt, path);
- if (node >= 0) {
- /* Look up phy-handle */
- val = fdt_getprop(fdt, node, "phy-handle", NULL);
- if (val) {
- phandle = fdt32_to_cpu(*val);
- if (!phandle)
- return -1;
- /* Follow it to its node */
- node = fdt_node_offset_by_phandle(fdt, phandle);
- if (node) {
- /* Look up reg */
- reg = fdt_getprop(fdt, node, "reg", NULL);
- if (reg) {
- addr = fdt32_to_cpu(*reg);
- return addr;
- }
- }
- }
- }
- return -1;
-}
-
-#ifdef CONFIG_RESET_PHY_R
-/* Configure and enable MV88E1116 PHY */
-void reset_phy(void)
-{
- u16 reg;
- int phyaddr;
- char *name = "ethernet-controller@72000";
- char *eth0_path =
"/ocp@f100/ethernet-controller@72000/ethernet0-port@0";
-
- if (miiphy_set_current_dev(name))
- return;
-
- phyaddr = fdt_get_phy_addr(eth0_path);
- if (phyaddr < 0)
- return;
-
- /*
-* Enable RGMII delay on Tx and Rx for CPU port
-* Ref: sec 4.7.2 of chip datasheet
-*/
- miiphy_write(name, phyaddr, MV88E1116_PGADR_REG, 2);
- miiphy_read(name, phyaddr, MV88E1116_MAC_CTRL_REG, ®);
- reg |= (MV88E1116_RGMII_RXTM_CTRL | MV88E1116_RGMII_TXTM_CTRL);
- miiphy_write(name, phyaddr, MV88E1116_MAC_CTRL_REG, reg);
- miiphy_write(name, phyaddr, MV88E1116_PGADR_REG, 0);
-
- /* reset the phy */
- miiphy_reset(name, phyaddr);
-
- printf("88E1116 Initialized on %s\n", name);
-}
-#endif /* CONFIG_RESET_PHY_R */
diff --git a/board/Marvell/sheevaplug/sheevaplug.h
b/board/Marvell/sheevaplug/sheevaplug.h
deleted file mode 100644
index e026c1b53b..00
--- a/board/Marvell/sheevaplug/sheevaplug.h
+++ /dev/null
@@ -1,24 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * (C) Copyright 2009
- * Marvell Sem
Re: [EXT] Re: [PATCH v8 01/15] crypto/fsl: Add support for CAAM Job ring driver model
On Tue, Mar 08, 2022 at 08:12:27AM -0300, Fabio Estevam wrote: > On Tue, Mar 8, 2022 at 8:10 AM Gaurav Jain wrote: > > > I further checked on your concern and propose the below change to stop > > building caam driver in SPL for imx6dl_mamoj. > > > > --- a/configs/imx6dl_mamoj_defconfig > > +++ b/configs/imx6dl_mamoj_defconfig > > @@ -61,3 +61,4 @@ CONFIG_USB_GADGET_MANUFACTURER="FSL" > > CONFIG_USB_GADGET_VENDOR_NUM=0x0525 > > CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 > > CONFIG_CI_UDC=y > > +CONFIG_SPL_CRYPTO=n > > No, this is not how defconfig works. > > You should set: > > # CONFIG_SPL_CRYPTO is not set But more, WHY is this the right answer? You're disabling functionality and the board maintainers aren't even on the CC list for this thread it looks like. Why are you not fixing the board so it still links? What makes this board a problem that other (I assume) imx6dl boards are not? -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model
On 3/8/22 12:36, AKASHI Takahiro wrote: With this patch set[1] applied, UEFI subsystem maintains a list of its disk objects dynamically at runtime based on block device's probing. (See "issues" below.) [1] https://github.com/t-akashi/u-boot/tree/efi/dm_disk On sandbox_defconfig with CONFIG_EFI_SELFTEST=y I see this error which does not occur without your patches: Executing 'load file protocol' lib/efi_selftest/efi_selftest_load_file.c(220): ERROR: Wrong remaining device path lib/efi_selftest/efi_selftest_load_file.c(396): ERROR: Failed to load image lib/efi_selftest/efi_selftest.c(114): ERROR: Executing 'load file protocol' failed Could you, please, check. Best regards Heinrich
[PATCH v1 0/1]wdt: nuvoton: Add support for Nuvoton
Add watchdog controller driver for NPCM7xx/npcm8xx jimliu2 (1): wdt: nuvoton: Add support for Nuvoton drivers/watchdog/Kconfig| 6 ++ drivers/watchdog/Makefile | 1 + drivers/watchdog/npcm_wdt.c | 119 3 files changed, 126 insertions(+) create mode 100644 drivers/watchdog/npcm_wdt.c -- 2.17.1
[PATCH v1 1/1] wdt: nuvoton: Add support for Nuvoton
Add watchdog controller driver for NPCM7xx/npcm8xx
Signed-off-by: jimliu2
---
drivers/watchdog/Kconfig| 6 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/npcm_wdt.c | 119
3 files changed, 126 insertions(+)
create mode 100644 drivers/watchdog/npcm_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index f90f0ca02b..15edcf570f 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -196,6 +196,12 @@ config WDT_MTK
The watchdog timer is stopped when initialized.
It performs full SoC reset.
+config WDT_NPCM
+ bool "Nuvoton watchdog timer support"
+ depends on WDT && ARCH_NPCM
+ help
+ Nuvoton npcm7xx/npcm8xx watchdog.
+
config WDT_OCTEONTX
bool "OcteonTX core watchdog support"
depends on WDT && (ARCH_OCTEONTX || ARCH_OCTEONTX2)
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index a35bd559f5..1089cd21f5 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_WDT_MPC8xx) += mpc8xx_wdt.o
obj-$(CONFIG_WDT_MT7620) += mt7620_wdt.o
obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o
obj-$(CONFIG_WDT_MTK) += mtk_wdt.o
+obj-$(CONFIG_WDT_NPCM) += npcm_wdt.o
obj-$(CONFIG_WDT_OCTEONTX) += octeontx_wdt.o
obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o
obj-$(CONFIG_WDT_SBSA) += sbsa_gwdt.o
diff --git a/drivers/watchdog/npcm_wdt.c b/drivers/watchdog/npcm_wdt.c
new file mode 100644
index 00..1f1b726db3
--- /dev/null
+++ b/drivers/watchdog/npcm_wdt.c
@@ -0,0 +1,119 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2022 Nuvoton Technology, Inc
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define NPCM_WTCLK (BIT(10) | BIT(11)) /* Clock divider */
+#define NPCM_WTE BIT(7) /* Enable */
+#define NPCM_WTIE BIT(6) /* Enable irq */
+#define NPCM_WTIS (BIT(4) | BIT(5)) /* Interval selection */
+#define NPCM_WTIF BIT(3) /* Interrupt flag*/
+#define NPCM_WTRF BIT(2) /* Reset flag */
+#define NPCM_WTRE BIT(1) /* Reset enable */
+#define NPCM_WTR BIT(0) /* Reset counter */
+
+struct npcm_wdt_priv {
+ struct npcm_wdt *regs;
+};
+
+static int npcm_wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags)
+{
+ struct npcm_wdt_priv *priv = dev_get_priv(dev);
+ u32 time_out, val;
+
+ time_out = (u32)(timeout_ms) / 1000;
+ if (time_out < 2)
+ val = 0x800;
+ else if (time_out < 3)
+ val = 0x420;
+ else if (time_out < 6)
+ val = 0x810;
+ else if (time_out < 11)
+ val = 0x430;
+ else if (time_out < 22)
+ val = 0x820;
+ else if (time_out < 44)
+ val = 0xC00;
+ else if (time_out < 87)
+ val = 0x830;
+ else if (time_out < 173)
+ val = 0xC10;
+ else if (time_out < 688)
+ val = 0xC20;
+ else
+ val = 0xC30;
+
+ val |= NPCM_WTRE | NPCM_WTE | NPCM_WTR | NPCM_WTIE;
+ writel(val, priv->regs);
+
+ return 0;
+}
+
+static int npcm_wdt_stop(struct udevice *dev)
+{
+ struct npcm_wdt_priv *priv = dev_get_priv(dev);
+
+ writel(0, priv->regs);
+
+ return 0;
+}
+
+static int npcm_wdt_reset(struct udevice *dev)
+{
+ struct npcm_wdt_priv *priv = dev_get_priv(dev);
+
+ writel(NPCM_WTR | NPCM_WTRE | NPCM_WTE, priv->regs);
+ udelay(1000);
+
+ return 0;
+}
+
+static int npcm_wdt_of_to_plat(struct udevice *dev)
+{
+ struct npcm_wdt_priv *priv = dev_get_priv(dev);
+
+ priv->regs = dev_read_addr_ptr(dev);
+ if (!priv->regs)
+ return -EINVAL;
+
+ return 0;
+}
+
+static const struct wdt_ops npcm_wdt_ops = {
+ .start = npcm_wdt_start,
+ .reset = npcm_wdt_reset,
+ .stop = npcm_wdt_stop,
+};
+
+static const struct udevice_id npcm_wdt_ids[] = {
+ { .compatible = "nuvoton,npcm750-wdt" },
+ { .compatible = "nuvoton,npcm845-wdt" },
+ { }
+};
+
+static int npcm_wdt_probe(struct udevice *dev)
+{
+ debug("%s() wdt%u\n", __func__, dev_seq(dev));
+ npcm_wdt_stop(dev);
+
+ return 0;
+}
+
+U_BOOT_DRIVER(npcm_wdt) = {
+ .name = "npcm_wdt",
+ .id = UCLASS_WDT,
+ .of_match = npcm_wdt_ids,
+ .probe = npcm_wdt_probe,
+ .priv_auto = sizeof(struct npcm_wdt_priv),
+ .of_to_plat = npcm_wdt_of_to_plat,
+ .ops = &npcm_wdt_ops,
+};
--
2.17.1
Re: [PATCH] drivers: led: bcm6858: Set default brightness when setting LED state
Hi,
While discussing that change internally. One remark was that the
brightness of the LED controller is being set at every state change
while in principle, a "default" brightness could be set once and for
all, for instance in the probing function.
Currently, the U-Boot LED driver does not support setting the
brightness if supported by the LED controller, while it might be an
interesting feature in the future, I wanted to first have a fix to
make sure the LED controller is properly initialized and in that case
that some default brightness is set. I was therefore wondering if for
that purpose it would also not make sense to actually retrieve the
default brightness from the device tree. For instance by adding a
property "default-brightness" as there can be a "default-state" in the
LED related nodes. That "default-brightness" property could be parsed
in the probing function, if supported by the LED controller and would
set a default brightness.
As such, if no property "default-brightness" is specified in U-Boot's
device tree, the behaviour does not change compared to the original
implementation and if the LED controller is initialized at an earlier
boot stage, the brightness setting is not overwritten.
Thx in advance for your feedback.
Paul HENRYS
Le mer. 2 mars 2022 à 16:43, Paul HENRYS
a écrit :
>
> When setting the LED state (OFF, ON or blinking), the default
> maximum brightness is set for ON and blinking state and the
> brightness is set to 0 for OFF state.
> This should make sure the LED controller's registers affecting the
> brightness are correctly initialized and should give consistent
> behaviour.
>
> Signed-off-by: Paul HENRYS
> ---
> drivers/led/led_bcm6858.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/led/led_bcm6858.c b/drivers/led/led_bcm6858.c
> index fbf46a114c..02a8308611 100644
> --- a/drivers/led/led_bcm6858.c
> +++ b/drivers/led/led_bcm6858.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> * Copyright (C) 2019 Philippe Reynes
> + * Copyright (C) 2022 Paul HENRYS
> *
> * based on:
> * drivers/led/led_bcm6328.c
> @@ -38,6 +39,8 @@
> #define LED_HW_LED_EN_REG 0x08
> /* LED Flash control register0 */
> #define LED_FLASH_RATE_CONTROL_REG00x10
> +/* LED Brightness control register0 */
> +#define LED_BRIGHTNESS_CONTROL_REG00x20
> /* Soft LED input register */
> #define LED_SW_LED_IP_REG 0xb8
> /* Parallel LED Output Polarity Register */
> @@ -96,6 +99,24 @@ static int bcm6858_led_set_period(struct udevice *dev, int
> period_ms)
> }
> #endif
>
> +static int led_set_brightness(struct udevice *dev, unsigned int brightness)
> +{
> + struct bcm6858_led_priv *priv = dev_get_priv(dev);
> + u32 offset, shift, mask, value;
> +
> + offset = (priv->pin / 8) * 4;
> + shift = (priv->pin % 8) * 4;
> + mask = 0xf << shift;
> +
> +/* 8 levels of brightness achieved through PWM */
> + value = (brightness > 7 ? 7 : brightness) << shift;
> +
> + clrbits_32(priv->regs + LED_BRIGHTNESS_CONTROL_REG0 + offset, mask);
> + setbits_32(priv->regs + LED_BRIGHTNESS_CONTROL_REG0 + offset, value);
> +
> + return 0;
> +}
> +
> static enum led_state_t bcm6858_led_get_state(struct udevice *dev)
> {
> struct bcm6858_led_priv *priv = dev_get_priv(dev);
> @@ -116,12 +137,15 @@ static int bcm6858_led_set_state(struct udevice *dev,
> enum led_state_t state)
> switch (state) {
> case LEDST_OFF:
> clrbits_32(priv->regs + LED_SW_LED_IP_REG, (1 << priv->pin));
> + led_set_brightness(dev, 0);
> #ifdef CONFIG_LED_BLINK
> bcm6858_led_set_period(dev, 0);
> #endif
> break;
> case LEDST_ON:
> setbits_32(priv->regs + LED_SW_LED_IP_REG, (1 << priv->pin));
> + /* Set maximum brightness by default */
> + led_set_brightness(dev, 7);
> #ifdef CONFIG_LED_BLINK
> bcm6858_led_set_period(dev, 0);
> #endif
> @@ -135,6 +159,8 @@ static int bcm6858_led_set_state(struct udevice *dev,
> enum led_state_t state)
> #ifdef CONFIG_LED_BLINK
> case LEDST_BLINK:
> setbits_32(priv->regs + LED_SW_LED_IP_REG, (1 << priv->pin));
> + /* Set maximum brightness by default */
> + led_set_brightness(dev, 7);
> break;
> #endif
> default:
> --
> 2.25.1
>
Porting U-Boot's UEFI Payload to coreboot
Hi everyone, I am trying to work on a project to port the U-Boot UEFI code to coreboot as a payload. I haven't worked with UEFI before except running a basic EFI payload in a coreboot/u-boot environment. (Serial output: https://gist.github.com/drac98/6166d29f6c3a2baf2f4e791925ea98d3) I would like to know how UEFI is implemented in U-Boot. Is UEFI integrated into u-boot or is it implemented like a payload? Where is the UEFI source code? Is it the following files in the tree https://source.denx.de/u-boot/custodians/u-boot-efi lib/ |__ efi/ |__ efi_driver/ |__ efi_loader/ Please help me understand the structure. Best regards, Husni.
Re: [PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model
On Tue, Mar 08, 2022 at 01:59:08PM +0100, Heinrich Schuchardt wrote: > On 3/8/22 12:36, AKASHI Takahiro wrote: > > With this patch set[1] applied, UEFI subsystem maintains a list of its > > disk objects dynamically at runtime based on block device's probing. > > (See "issues" below.) > > > > [1] https://github.com/t-akashi/u-boot/tree/efi/dm_disk > > On sandbox_defconfig with CONFIG_EFI_SELFTEST=y I see this error which > does not occur without your patches: > > Executing 'load file protocol' > lib/efi_selftest/efi_selftest_load_file.c(220): > ERROR: Wrong remaining device path > lib/efi_selftest/efi_selftest_load_file.c(396): > ERROR: Failed to load image > lib/efi_selftest/efi_selftest.c(114): > ERROR: Executing 'load file protocol' failed > > Could you, please, check. I will, but I also request you to review *the code* itself. -Takahiro Akashi > Best regards > > Heinrich
Re: [PATCH v2 00/13] event: Provide support for events to connect subsystems
On 3/4/22 16:42, Simon Glass wrote: It is a common need in U-Boot to have one subsystem notify another when something happens. An example is reading a partition table when a new block device is set up. It is also common to add weak functions and 'hook' functions to modify how U-Boot works. See for example ft_board_setup() and the like. U-Boot would benefit from a generic mechanism to handle these cases, with the ability to hook into various 'events' in a subsystem-independent and transparent way. This series provides a way to create and dispatch events, with a way of registering a 'spy' which watches for events of different types. This allows 'hook' functions to be created in a generic way. It also includes a script to list the hooks in an image, which is a bit easier to debug than weak functions, as well as an 'event' command to do the same from within U-Boot. These 'static' events can be used to replace hooks like misc_init_f(), for example. Also included is basic support for 'dynamic' events, where a spy can be registered at runtime. The need for this is still being figured out. @Simon, Tom: What is the status of this series? Takahiro's UEFI integration series builds on it. Is it going to be pushed to origin/next soon? Best regards Heinrich Changes in v2: - Add a 'used' attribute to avoid LTO dropping the code - Update keymile pg-wcom boards also - Make the sandbox function static - Convert arch/arm/mach-imx/imx8/cpu.c also - Add DM_EVENT to ARCH_IMX8 too - Tidy up galileo defconfig and rename quark_init_dm() - Make a few more of the functions static - Add a weak function for spl - Update for patman snake-case change - Use a regular expression in the test to avoid dependency on build dir Simon Glass (12): Makefile: Allow LTO to be disabled for a build sandbox: start: Sort the header files binman: Expand elf support a little event: Add basic support for events event: Add a simple test event: Set up the event system on start-up event: Add events for device probe/remove event: Convert misc_init_f() to use events event: Convert arch_cpu_init_dm() to use events event: Add a command event: Add a script to decode the event-spy list event: Add documentation Tim Harvey (1): phy: nop-phy: Fix phy reset if no reset-gpio defined MAINTAINERS | 10 + Makefile | 18 +- arch/Kconfig | 3 + arch/arm/Kconfig | 4 + arch/arm/config.mk| 4 +- arch/arm/include/asm/global_data.h| 2 +- arch/arm/mach-imx/imx8/cpu.c | 4 +- arch/arm/mach-imx/imx8m/soc.c | 4 +- arch/arm/mach-imx/imx8ulp/soc.c | 4 +- arch/arm/mach-omap2/am33xx/board.c| 4 +- arch/arm/mach-omap2/hwinit-common.c | 5 +- arch/mips/Kconfig | 1 + arch/mips/mach-pic32/cpu.c| 4 +- arch/nios2/cpu/cpu.c | 4 +- arch/riscv/cpu/cpu.c | 5 +- arch/riscv/include/asm/system.h | 5 + arch/riscv/lib/spl.c | 3 +- arch/sandbox/cpu/start.c | 8 +- arch/x86/cpu/baytrail/cpu.c | 4 +- arch/x86/cpu/broadwell/cpu.c | 4 +- arch/x86/cpu/ivybridge/cpu.c | 4 +- arch/x86/cpu/quark/quark.c| 4 +- arch/x86/include/asm/fsp2/fsp_api.h | 8 + arch/x86/lib/fsp2/fsp_init.c | 4 +- arch/x86/lib/spl.c| 5 +- arch/x86/lib/tpl.c| 10 - board/google/chromebook_coral/coral.c | 7 +- board/keymile/kmcent2/kmcent2.c | 4 +- .../keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c | 5 +- cmd/Kconfig | 8 + cmd/Makefile | 1 + cmd/event.c | 27 +++ common/Kconfig| 37 ++- common/Makefile | 2 + common/board_f.c | 13 +- common/board_r.c | 1 + common/event.c| 196 common/log.c | 1 + configs/chromebook_coral_defconfig| 1 + configs/kmcent2_defconfig | 2 +- configs/pg_wcom_expu1_defconfig | 1 + configs/pg_wcom_expu1_update_defconfig| 1 + configs/pg_wcom_seli8_defconfig | 1 + configs/pg_wcom_seli8_update_defconfig| 1 + configs/sandbox64_defconfig | 1 - configs/sandbox_defconfig | 1 - configs/sandbox_flattree_defconfig| 1 - confi
Re: [PATCH v4 05/11] EFI: FMP: Add provision to update image's ImageTypeId in image descriptor
On Sat, Feb 26, 2022 at 03:24:10PM +0530, Sughosh Ganu wrote: > hello Heinrich, > > On Sat, 26 Feb 2022 at 12:24, Heinrich Schuchardt wrote: > > > > On 2/17/22 11:10, Sughosh Ganu wrote: > > > On Thu, 17 Feb 2022 at 13:52, Ilias Apalodimas > > > wrote: > > >> > > >>> > > >> > > >> [...] > > >> > > >>> Yes, we can use --index when we know the index value corresponding > > >>> to > > >>> the firmware image that we need to update. But like I mentioned in > > >>> my > > >>> earlier reply, for A/B updates, we do not know what the index value > > >>> is > > >>> going to be. That is going to be determined at runtime. > > >> > > >> I don't think so. See below for alternative approach. > > >> > > >>> Also, the point I was making is that we can have a capsule which is > > >>> consumed by an FMP protocol which has more than one image, and those > > >>> images have different ImageTypeId/UpdateImageTypeId. > > >> > > >> Yes, but it is a design choice in my first implementation. > > >> I didn't think that we need to "have a capsule which is consumed > > >> by an FMP protocol which has more than one image" as long as we > > >> use DFU framework (and FIT as standard format of aggregation on > > >> U-Boot). > > > > > > But this design can be extended without any hassle, and more > > > importantly without any regression, no? What kind of a problem does it > > > create if the FMP can handle more than one image type. > > > > > > Even as per the UEFI spec, we have the EFI_FIRMWARE_MANAGEMENT_CAPSULE > > > header for all images to be managed by the FMP protocol which has > > > multiple images with different UpdateImageTypeId. > > > > > >> > > > > > Please check the > > > GenerateCapsule script in EDK2. In case of a multi payload based > > > capsule, individual parameters like the UpdateImageTypeId are > > > passed > > > through the json file, where each of the UpdateImageTypeId has a > > > different value per payload. > > > > > >> > > 2) Each firmware object handled by a given FMP driver can > > further be > > identified by ImageIndex. > > > > My implementation of efi_fmp_find() does (1) and Raw FMP > > driver does > > (2) in efi_firmware_raw_set_image() which takes "image_index" > > as > > a parameter. > > > > Using ImageTypeId as an identifier is simply wrong in my > > opinion and > > doesn't meet the UEFI specification. > > >>> > > >>> So, as per what you are stating, all payloads under a given > > >>> EFI_FIRMWARE_MANAGEMENT_CAPSULE_HEADER should have the same > > >>> ImageTypeId, either EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID or > > >>> EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID. Same applies for all > > >>> images in > > >>> the EFI_FIRMWARE_IMAGE_DESCRIPTOR. Because, without one of the > > >>> two > > >>> values, > the check in efi_fmp_find to compare the > > >>> UpdateImageTypeId > > >>> with the ImageTypeId retrieved from the image descriptor would > > >>> simply > > >>> fail. > > >> > > >> I don't follow your point. > > >> Please elaborate a bit more. > > > > > > The current implementation of GetImageInfo, passes either of > > > EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID or > > > EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID for all the images of the > > > image > > > descriptor array. So, in case the capsule is generated with a > > > '--guid' > > > value which is different from these two values, the check in > > > efi_fmp_find on line 204 will fail. > > > > That is an expected behavior, isn't it? > > >>> > > >>> Yes it is. Do not contest that. > > >>> > > If you want to use a different FMP driver (with another GUID), > > you naturally need to add your own FMP driver. > > >>> > > >>> This is where I differ. We can use the same FMP protocol instance > > >>> for > > >>> any type of ImageTypeId. I do not see why we need to define a > > >>> different FMP protocol instance for a GUID value other than what has > > >>> been defined for u-boot raw and u-boot FIT GUIDs. > > >> > > >> I do understand part of your concern a bit. > > >> I thought of using the same ImageType GUID, say IMAGE_TYPE_DFU_GUID, > > >> at first > > >> but we needed different GUIDs here simply because we need to > > >> determine > > >> the format of payload, FIT format or raw binary. > > >> > > >>> The platform can give us the image descriptor array, and with that, > > >>> the same FMP
Re: [PATCH v2 01/13] phy: nop-phy: Fix phy reset if no reset-gpio defined
On 3/4/22 16:42, Simon Glass wrote:
From: Tim Harvey
Ensure there is a valid reset-gpio defined before using it.
Fixes: f9852acdce02 ("phy: nop-phy: Fix enabling reset")
Cc: Adam Ford
Signed-off-by: Tim Harvey
Signed-off-by: Simon Glass
This patch is already in origin/master.
[PATCH v2 1/2] generic-phy: s/CONFIG_PHY/CONFIG_IS_ENABLED(PHY)/
Allow to disable PHY driver in SPL because it checks the CONFIG_SPL_PHY
variable for SPL builds.
The same change was done for usb by commit fd09c205fc57 ("usb:
s/CONFIG_DM_USB/CONFIG_IS_ENABLED(DM_USB)/").
Signed-off-by: Michal Simek
---
Changes in v2:
- based on bug reported by Marek
https://lore.kernel.org/all/d7adc9a4-f505-eaab-8cd9-45f778bc3...@denx.de/
include/generic-phy.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/generic-phy.h b/include/generic-phy.h
index ff48b3708195..d40ce589b645 100644
--- a/include/generic-phy.h
+++ b/include/generic-phy.h
@@ -155,7 +155,7 @@ struct phy_bulk {
unsigned int count;
};
-#ifdef CONFIG_PHY
+#if CONFIG_IS_ENABLED(PHY)
/**
* generic_phy_init() - initialize the PHY port
--
2.35.1
[PATCH v2 2/2] usb: dwc3: Add support for usb3-phy PHY configuration
When usb3-phy label is found, PHY driver is called and serdes line is
initialized. This is preparation for serdes/psgtr driver to configure GT
lines based on description in DT.
Signed-off-by: Michal Simek
---
Changes in v2:
- Add missing header
drivers/usb/dwc3/dwc3-generic.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index 01bd0ca190e3..2c5205df62cd 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -409,6 +410,17 @@ static int dwc3_glue_probe(struct udevice *dev)
struct udevice *child = NULL;
int index = 0;
int ret;
+ struct phy phy;
+
+ ret = generic_phy_get_by_name(dev, "usb3-phy", &phy);
+ if (!ret) {
+ ret = generic_phy_init(&phy);
+ if (ret)
+ return ret;
+ } else if (ret != -ENOENT) {
+ debug("could not get phy (err %d)\n", ret);
+ return ret;
+ }
glue->regs = dev_read_addr(dev);
@@ -420,6 +432,12 @@ static int dwc3_glue_probe(struct udevice *dev)
if (ret)
return ret;
+ if (phy.dev) {
+ ret = generic_phy_power_on(&phy);
+ if (ret)
+ return ret;
+ }
+
ret = device_find_first_child(dev, &child);
if (ret)
return ret;
--
2.35.1
RE: [EXT] Re: [PATCH v8 01/15] crypto/fsl: Add support for CAAM Job ring driver model
> -Original Message- > From: Tom Rini > Sent: Tuesday, March 8, 2022 6:19 PM > To: Fabio Estevam > Cc: Gaurav Jain ; Michael Walle ; > sba...@denx.de; Varun Sethi ; Adrian Alonso > ; Alison Wang ; Andy Tang > ; Franck Lenormand ; > Horia Geanta ; Ji Luo ; > ma...@denx.de; Meenakshi Aggarwal ; > Mingkai Hu ; olte...@gmail.com; Pankaj Gupta > ; Peng Fan ; Pramod Kumar > ; Priyanka Jain ; Rajesh > Bhagat ; Sahil Malhotra ; > Shengzhou Liu ; Silvano Di Ninno > ; s...@chromium.org; u-boot@lists.denx.de; dl- > uboot-imx ; Wasim Khan ; Ye Li > > Subject: Re: [EXT] Re: [PATCH v8 01/15] crypto/fsl: Add support for CAAM Job > ring driver model > > On Tue, Mar 08, 2022 at 08:12:27AM -0300, Fabio Estevam wrote: > > On Tue, Mar 8, 2022 at 8:10 AM Gaurav Jain wrote: > > > > > I further checked on your concern and propose the below change to stop > building caam driver in SPL for imx6dl_mamoj. > > > > > > --- a/configs/imx6dl_mamoj_defconfig > > > +++ b/configs/imx6dl_mamoj_defconfig > > > @@ -61,3 +61,4 @@ CONFIG_USB_GADGET_MANUFACTURER="FSL" > > > CONFIG_USB_GADGET_VENDOR_NUM=0x0525 > > > CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 > > > CONFIG_CI_UDC=y > > > +CONFIG_SPL_CRYPTO=n > > > > No, this is not how defconfig works. > > > > You should set: > > > > # CONFIG_SPL_CRYPTO is not set > > But more, WHY is this the right answer? You're disabling functionality and > the > board maintainers aren't even on the CC list for this thread it looks like. > Why are > you not fixing the board so it still links? What makes this board a problem > that > other (I assume) imx6dl boards are not? > SPL exceeds the maximum size for only imx6dl_mamoj. spl/u-boot-spl.bin exceeds file size limit: limit: 0xefa0 bytes actual: 0x1004d bytes excess: 0x10ad bytes on further checking I see that caam is not initialized in SPL but only built. So disabling the build for caam driver in SPL should not be a problem. (Added Jagan, Raffaele, Simone as board maintainer.) Gaurav > -- > Tom
Re: [PATCH] usb: dwc3: Add support for usb3-phy PHY configuration
On 3/4/22 18:33, Marek Vasut wrote: On 3/4/22 05:42, Marek Vasut wrote: On 3/3/22 09:40, Bin Meng wrote: On Wed, Feb 23, 2022 at 10:56 PM Michal Simek wrote: When usb3-phy label is found, PHY driver is called and serdes line is initialized. This is preparation for serdes/psgtr driver to configure GT lines based on description in DT. Signed-off-by: Michal Simek --- drivers/usb/dwc3/dwc3-generic.c | 17 + 1 file changed, 17 insertions(+) Reviewed-by: Bin Meng Applied, thanks. Fails to build, please fix. Patch dropped: https://source.denx.de/u-boot/custodians/u-boot-usb/-/jobs/399461 This patch is fixing the problem https://lore.kernel.org/r/eabd31079152659556432fed561cd3a98300c8f5.1646745547.git.michal.si...@xilinx.com Thanks, Michal
Re: [PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model
On 3/8/22 14:04, AKASHI Takahiro wrote: On Tue, Mar 08, 2022 at 01:59:08PM +0100, Heinrich Schuchardt wrote: On 3/8/22 12:36, AKASHI Takahiro wrote: With this patch set[1] applied, UEFI subsystem maintains a list of its disk objects dynamically at runtime based on block device's probing. (See "issues" below.) [1] https://github.com/t-akashi/u-boot/tree/efi/dm_disk On sandbox_defconfig with CONFIG_EFI_SELFTEST=y I see this error which does not occur without your patches: Executing 'load file protocol' lib/efi_selftest/efi_selftest_load_file.c(220): ERROR: Wrong remaining device path lib/efi_selftest/efi_selftest_load_file.c(396): ERROR: Failed to load image lib/efi_selftest/efi_selftest.c(114): ERROR: Executing 'load file protocol' failed I missed to put Simon's event series first. With both series the error vanishes. Best regards Heinrich Could you, please, check. I will, but I also request you to review *the code* itself. -Takahiro Akashi Best regards Heinrich
Re: [PATCH v2 00/13] event: Provide support for events to connect subsystems
On Tue, Mar 08, 2022 at 02:11:02PM +0100, Heinrich Schuchardt wrote: > On 3/4/22 16:42, Simon Glass wrote: > > It is a common need in U-Boot to have one subsystem notify another > > when something happens. An example is reading a partition table when a > > new block device is set up. > > > > It is also common to add weak functions and 'hook' functions to modify > > how U-Boot works. See for example ft_board_setup() and the like. > > > > U-Boot would benefit from a generic mechanism to handle these cases, > > with the ability to hook into various 'events' in a > > subsystem-independent and transparent way. > > > > This series provides a way to create and dispatch events, with a way of > > registering a 'spy' which watches for events of different types. This > > allows 'hook' functions to be created in a generic way. > > > > It also includes a script to list the hooks in an image, which is a bit > > easier to debug than weak functions, as well as an 'event' command to > > do the same from within U-Boot. > > > > These 'static' events can be used to replace hooks like misc_init_f(), > > for example. Also included is basic support for 'dynamic' events, where > > a spy can be registered at runtime. The need for this is still being > > figured out. > > @Simon, Tom: > > What is the status of this series? Takahiro's UEFI integration series > builds on it. Is it going to be pushed to origin/next soon? I'm waiting for Simon to reply to Takahiro's comment on v2 before applying. -- Tom signature.asc Description: PGP signature
Re: [EXT] Re: [PATCH v8 01/15] crypto/fsl: Add support for CAAM Job ring driver model
Hi Tom, On 08.03.22 13:48, Tom Rini wrote: On Tue, Mar 08, 2022 at 08:12:27AM -0300, Fabio Estevam wrote: On Tue, Mar 8, 2022 at 8:10 AM Gaurav Jain wrote: I further checked on your concern and propose the below change to stop building caam driver in SPL for imx6dl_mamoj. --- a/configs/imx6dl_mamoj_defconfig +++ b/configs/imx6dl_mamoj_defconfig @@ -61,3 +61,4 @@ CONFIG_USB_GADGET_MANUFACTURER="FSL" CONFIG_USB_GADGET_VENDOR_NUM=0x0525 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 CONFIG_CI_UDC=y +CONFIG_SPL_CRYPTO=n No, this is not how defconfig works. You should set: # CONFIG_SPL_CRYPTO is not set But more, WHY is this the right answer? You're disabling functionality and the board maintainers aren't even on the CC list for this thread it looks like. This was my blocking point, too, for this series. There is no answer about the board. I can just imagine (as for other MX6DL) that the required functionality is secure boot, then CONFIG_IMX_HAB is enough. But well, just the board maintainers can say. Added Raffaele and Jagan as reported maintainers for this board. Why are you not fixing the board so it still links? What makes this board a problem that other (I assume) imx6dl boards are not? Well, this board has, compared to other MX6DL, a lot of SPL_ option that are bloating the SPL size. And then does not match anymore with the internal RAm, while other MX6DL boards are not so affected by the increased size because they have no SPL at all or SPL with less options and then smaller. We do not need to fix the link, but reduce the size, and nobody else than the maintainers can tell us if removing some feature is ok. Regards, Stefano -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
Re: [EXT] Re: [PATCH v8 01/15] crypto/fsl: Add support for CAAM Job ring driver model
On Tue, Mar 08, 2022 at 01:21:41PM +, Gaurav Jain wrote: > > > > -Original Message- > > From: Tom Rini > > Sent: Tuesday, March 8, 2022 6:19 PM > > To: Fabio Estevam > > Cc: Gaurav Jain ; Michael Walle ; > > sba...@denx.de; Varun Sethi ; Adrian Alonso > > ; Alison Wang ; Andy Tang > > ; Franck Lenormand ; > > Horia Geanta ; Ji Luo ; > > ma...@denx.de; Meenakshi Aggarwal ; > > Mingkai Hu ; olte...@gmail.com; Pankaj Gupta > > ; Peng Fan ; Pramod Kumar > > ; Priyanka Jain ; Rajesh > > Bhagat ; Sahil Malhotra ; > > Shengzhou Liu ; Silvano Di Ninno > > ; s...@chromium.org; u-boot@lists.denx.de; dl- > > uboot-imx ; Wasim Khan ; Ye Li > > > > Subject: Re: [EXT] Re: [PATCH v8 01/15] crypto/fsl: Add support for CAAM Job > > ring driver model > > > > On Tue, Mar 08, 2022 at 08:12:27AM -0300, Fabio Estevam wrote: > > > On Tue, Mar 8, 2022 at 8:10 AM Gaurav Jain wrote: > > > > > > > I further checked on your concern and propose the below change to stop > > building caam driver in SPL for imx6dl_mamoj. > > > > > > > > --- a/configs/imx6dl_mamoj_defconfig > > > > +++ b/configs/imx6dl_mamoj_defconfig > > > > @@ -61,3 +61,4 @@ CONFIG_USB_GADGET_MANUFACTURER="FSL" > > > > CONFIG_USB_GADGET_VENDOR_NUM=0x0525 > > > > CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 > > > > CONFIG_CI_UDC=y > > > > +CONFIG_SPL_CRYPTO=n > > > > > > No, this is not how defconfig works. > > > > > > You should set: > > > > > > # CONFIG_SPL_CRYPTO is not set > > > > But more, WHY is this the right answer? You're disabling functionality and > > the > > board maintainers aren't even on the CC list for this thread it looks like. > > Why are > > you not fixing the board so it still links? What makes this board a > > problem that > > other (I assume) imx6dl boards are not? > > > SPL exceeds the maximum size for only imx6dl_mamoj. > spl/u-boot-spl.bin exceeds file size limit: > limit: 0xefa0 bytes > actual: 0x1004d bytes > excess: 0x10ad bytes > > on further checking I see that caam is not initialized in SPL but only built. > So disabling the build for caam driver in SPL should not be a problem. > > (Added Jagan, Raffaele, Simone as board maintainer.) That's a lot of growth, what's going on? And is the CAAM being built but not initialized a generic issue with imx6 platforms? That seems like something to further understand, and hopefully the board maintainers can chime in here soon. -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 01/19] scsi: call device_probe() after scanning
On 3/8/22 12:36, AKASHI Takahiro wrote:
Every time a scsi bus/port is scanned and a new block device is detected,
we want to call device_probe() as it will give us a chance to run
additional post-processings for some purposes.
In particular, support for creating partitions on a device will be added.
Signed-off-by: AKASHI Takahiro
Reviewed-by: Simon Glass
---
drivers/scsi/scsi.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index d7b33010e469..78d729d809d7 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -595,6 +595,11 @@ static int do_scsi_scan_one(struct udevice *dev, int id,
int lun, bool verbose)
ata_swap_buf_le16((u16 *)&bdesc->revision, sizeof(bd.revision)
/ 2);
}
+ ret = blk_probe_or_unbind(bdev);
+ if (ret < 0)
+ /* TODO: undo create */
Isn't device_unbind() releasing all resources? What is missing?
Best regards
Heinrich
+ return ret;
+
if (verbose) {
printf(" Device %d: ", bdesc->devnum);
dev_print(bdesc);
Re: [EXT] Re: [PATCH v8 01/15] crypto/fsl: Add support for CAAM Job ring driver model
Hi On Tue, Mar 8, 2022 at 2:28 PM Stefano Babic wrote: > > Hi Tom, > > On 08.03.22 13:48, Tom Rini wrote: > > On Tue, Mar 08, 2022 at 08:12:27AM -0300, Fabio Estevam wrote: > >> On Tue, Mar 8, 2022 at 8:10 AM Gaurav Jain wrote: > >> > >>> I further checked on your concern and propose the below change to stop > >>> building caam driver in SPL for imx6dl_mamoj. > >>> > >>> --- a/configs/imx6dl_mamoj_defconfig > >>> +++ b/configs/imx6dl_mamoj_defconfig > >>> @@ -61,3 +61,4 @@ CONFIG_USB_GADGET_MANUFACTURER="FSL" > >>> CONFIG_USB_GADGET_VENDOR_NUM=0x0525 > >>> CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 > >>> CONFIG_CI_UDC=y > >>> +CONFIG_SPL_CRYPTO=n > >> > >> No, this is not how defconfig works. > >> > >> You should set: > >> > >> # CONFIG_SPL_CRYPTO is not set > > > > But more, WHY is this the right answer? You're disabling functionality > > and the board maintainers aren't even on the CC list for this thread it > > looks like. > > This was my blocking point, too, for this series. There is no answer > about the board. > > I can just imagine (as for other MX6DL) that the required functionality > is secure boot, then CONFIG_IMX_HAB is enough. But well, just the board > maintainers can say. Added Raffaele and Jagan as reported maintainers > for this board. > > > Why are you not fixing the board so it still links? What > > makes this board a problem that other (I assume) imx6dl boards are not? > > Well, this board has, compared to other MX6DL, a lot of SPL_ option that > are bloating the SPL size. And then does not match anymore with the > internal RAm, while other MX6DL boards are not so affected by the > increased size because they have no SPL at all or SPL with less options > and then smaller. We do not need to fix the link, but reduce the size, > and nobody else than the maintainers can tell us if removing some > feature is ok. > I will test this week, and try to find a board here to test * Jagan * Do you have a momoj? Michael > Regards, > Stefano > > -- > = > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de > = -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [PATCH] usb: dwc3: Add support for usb3-phy PHY configuration
On 3/8/22 14:21, Michal Simek wrote: On 3/4/22 18:33, Marek Vasut wrote: On 3/4/22 05:42, Marek Vasut wrote: On 3/3/22 09:40, Bin Meng wrote: On Wed, Feb 23, 2022 at 10:56 PM Michal Simek wrote: When usb3-phy label is found, PHY driver is called and serdes line is initialized. This is preparation for serdes/psgtr driver to configure GT lines based on description in DT. Signed-off-by: Michal Simek --- drivers/usb/dwc3/dwc3-generic.c | 17 + 1 file changed, 17 insertions(+) Reviewed-by: Bin Meng Applied, thanks. Fails to build, please fix. Patch dropped: https://source.denx.de/u-boot/custodians/u-boot-usb/-/jobs/399461 This patch is fixing the problem https://lore.kernel.org/r/eabd31079152659556432fed561cd3a98300c8f5.1646745547.git.michal.si...@xilinx.com I'm confused, is this a patch I should try to apply somehow ?
Re: [PATCH v2 2/2] usb: dwc3: Add support for usb3-phy PHY configuration
On 3/8/22 14:19, Michal Simek wrote: When usb3-phy label is found, PHY driver is called and serdes line is initialized. This is preparation for serdes/psgtr driver to configure GT lines based on description in DT. Signed-off-by: Michal Simek --- Changes in v2: - Add missing header I think 1/2 patch was not submitted ?
Re: [PATCH v2] tools: mkimage: Call verify_header after writing image to disk
On Fri, Jan 14, 2022 at 06:34:43PM +0100, Pali Rohár wrote:
> If image backend provides verify_header callback then call it after writing
> image to disk. This ensures that written image is correct.
>
> Signed-off-by: Pali Rohár
> Reviewed-by: Stefan Roese
> Reviewed-by: Simon Glass
> ---
> tools/mkimage.c | 41 +
> 1 file changed, 41 insertions(+)
>
> diff --git a/tools/mkimage.c b/tools/mkimage.c
> index fbe883ce3620..d5ad0925225c 100644
> --- a/tools/mkimage.c
> +++ b/tools/mkimage.c
> @@ -336,6 +336,44 @@ static void process_args(int argc, char **argv)
> usage("Missing output filename");
> }
>
> +static void verify_image(const struct image_type_params *tparams)
> +{
> + struct stat sbuf;
> + void *ptr;
> + int ifd;
> +
> + ifd = open(params.imagefile, O_RDONLY | O_BINARY);
> + if (ifd < 0) {
> + fprintf(stderr, "%s: Can't open %s: %s\n",
> + params.cmdname, params.imagefile,
> + strerror(errno));
> + exit(EXIT_FAILURE);
> + }
> +
> + if (fstat(ifd, &sbuf) < 0) {
> + fprintf(stderr, "%s: Can't stat %s: %s\n",
> + params.cmdname, params.imagefile, strerror(errno));
> + exit(EXIT_FAILURE);
> + }
> + params.file_size = sbuf.st_size;
> +
> + ptr = mmap(0, params.file_size, PROT_READ, MAP_SHARED, ifd, 0);
> + if (ptr == MAP_FAILED) {
> + fprintf(stderr, "%s: Can't map %s: %s\n",
> + params.cmdname, params.imagefile, strerror(errno));
> + exit(EXIT_FAILURE);
> + }
> +
> + if (tparams->verify_header((unsigned char *)ptr, params.file_size,
> ¶ms) != 0) {
> + fprintf(stderr, "%s: Failed to verify header of %s\n",
> + params.cmdname, params.imagefile);
> + exit(EXIT_FAILURE);
> + }
> +
> + (void)munmap(ptr, params.file_size);
> + (void)close(ifd);
> +}
> +
> int main(int argc, char **argv)
> {
> int ifd = -1;
> @@ -698,6 +736,9 @@ int main(int argc, char **argv)
> exit (EXIT_FAILURE);
> }
>
> + if (tparams->verify_header)
> + verify_image(tparams);
> +
> exit (EXIT_SUCCESS);
> }
I've added Joseph Chen to the thread as with this patch applied,
evb-rk3568 fails to build now with:
./tools/mkimage: Failed to verify header of idbloader.img
which is another issue to resolve.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] usb: dwc3: Add support for usb3-phy PHY configuration
On 3/8/22 14:39, Marek Vasut wrote: On 3/8/22 14:21, Michal Simek wrote: On 3/4/22 18:33, Marek Vasut wrote: On 3/4/22 05:42, Marek Vasut wrote: On 3/3/22 09:40, Bin Meng wrote: On Wed, Feb 23, 2022 at 10:56 PM Michal Simek wrote: When usb3-phy label is found, PHY driver is called and serdes line is initialized. This is preparation for serdes/psgtr driver to configure GT lines based on description in DT. Signed-off-by: Michal Simek --- drivers/usb/dwc3/dwc3-generic.c | 17 + 1 file changed, 17 insertions(+) Reviewed-by: Bin Meng Applied, thanks. Fails to build, please fix. Patch dropped: https://source.denx.de/u-boot/custodians/u-boot-usb/-/jobs/399461 This patch is fixing the problem https://lore.kernel.org/r/eabd31079152659556432fed561cd3a98300c8f5.1646745547.git.michal.si...@xilinx.com I'm confused, is this a patch I should try to apply somehow ? It should be applied before that dwc3 patch. If you don't want to apply it via your usb tree I can take it via my tree or ask Tom to take it. Thanks, Michal
Re: [PATCH v2 2/2] usb: dwc3: Add support for usb3-phy PHY configuration
On 3/8/22 14:39, Marek Vasut wrote: On 3/8/22 14:19, Michal Simek wrote: When usb3-phy label is found, PHY driver is called and serdes line is initialized. This is preparation for serdes/psgtr driver to configure GT lines based on description in DT. Signed-off-by: Michal Simek --- Changes in v2: - Add missing header I think 1/2 patch was not submitted ? It was but you are not in CC. M
Re: Porting U-Boot's UEFI Payload to coreboot
On 3/8/22 13:59, Ahamed Husni wrote: Hi everyone, I am trying to work on a project to port the U-Boot UEFI code to coreboot as a payload. I haven't worked with UEFI before except running a basic EFI payload in a coreboot/u-boot environment. (Serial output: https://gist.github.com/drac98/6166d29f6c3a2baf2f4e791925ea98d3) I would like to know how UEFI is implemented in U-Boot. Is UEFI integrated into u-boot or is it implemented like a payload? Hello Ahamed, the UEFI API implementation is an integral part of U-Boot. Where is the UEFI source code? Is it the following files in the tree https://source.denx.de/u-boot/custodians/u-boot-efi lib/ |__ efi/ |__ efi_driver/ |__ efi_loader/ U-Boot can both be run on top of UEFI. This is the code you find in /lib/efi/. Furthermore UEFI can run as a firmware providing the UEFI API. This is what you find in /lib/efi_loader/ and /lib/efi_driver/. You can build U-Boot as payload for coreboot which offers the UEFI API implementation. See configs/coreboot64_defconfig. U-Boot runs ARM and RISC-V Linux successfully via UEFI. What architecture are you looking at? Simon (on CC) has been working on U-Boot on UEFI and Coreboot while I have concentrated on the UEFI API implementation in U-Boot. Best regards Heinrich Please help me understand the structure. Best regards, Husni.
[RFC PATCH v3 0/2] enable menu-driven boot device selection
This patch series adds the menu-driven boot device selection, by extending the existing "bootmenu" to include UEFI and distro_boot related entries. The menu example shown with this patch series is as follows. *** U-Boot Boot Menu *** Boot 1. kernel (bootmenu_0) Boot 2. kernel (bootmenu_1) Reset board (bootmenu_2) debian (BOOT) ubuntu (BOOT0001) UEFI Boot Manager usb0 scsi0 virtio0 dhcp UEFI Boot Manager Maintenance U-Boot console Press UP/DOWN to move, ENTER to select, ESC/CTRL+C to quit This example shows three "bootmenu_0..2" entries, UEFI "Boot" and "Boot0001" entries, distro_boot "boot_targets" entries(usb0, scici0, virtio0 and dhcp) and some pre-defined entries(UEFI Boot Manager, UEFI Boot Manager Maintenance and U-Boot console). Note that this patch series aims to propose the above menu structure, the code quality is very low and requires much cleanup/refactoring. [How to run on QEMU(arm64)] 1) clone source code $ git clone https://git.linaro.org/people/masahisa.kojima/u-boot.git \ -b kojima/efibootmenu_v3_upstream --depth 2 2) update U-Boot .config $ make qemu_arm64_menuconfig then, enable CONFIG_CMD_BOOTMENU and CONFIG_AUTOBOOT_MENU_SHOW 3) run on QEMU(arm64) example $ qemu-system-aarch64 -machine virt,gic-version=3 -cpu cortex-a57 -m 4G -nographic \ -no-acpi -bios ./u-boot.bin -hda xxx.img [Changes in v3] - Major difference from previous version is that this version extends the existing bootmenu capability instead of updating efi bootmgr. - include distro_boot entries - "bootefi bootindex" command is newly added Masahisa Kojima (2): efi_loader: introduce "bootefi bootindex" command bootmenu: add UEFI and disto_boot entries cmd/bootefi.c| 42 ++ cmd/bootmenu.c | 268 +-- include/efi_loader.h | 1 + lib/efi_loader/efi_bootmgr.c | 7 +- 4 files changed, 305 insertions(+), 13 deletions(-) -- 2.17.1
[RFC PATCH v3 1/2] efi_loader: introduce "bootefi bootindex" command
This commit introduces the new command "bootefi bootindex".
With this command, user can select which "Boot" option
to load and execute.
Signed-off-by: Masahisa Kojima
---
Changes in v3:
- newly created
cmd/bootefi.c| 42
include/efi_loader.h | 1 +
lib/efi_loader/efi_bootmgr.c | 7 +++---
3 files changed, 46 insertions(+), 4 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 46eebd5ee2..df86438fec 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -416,6 +416,30 @@ static int do_efibootmgr(void)
return CMD_RET_SUCCESS;
}
+/**
+ * do_efibootindex() - load and execute the specified Boot option
+ *
+ * Return: status code
+ */
+static int do_efibootindex(u16 boot_index)
+{
+ efi_handle_t handle;
+ efi_status_t ret;
+ void *load_options;
+
+ ret = efi_try_load_entry(boot_index, &handle, &load_options);
+ if (ret != EFI_SUCCESS) {
+ log_notice("EFI boot manager: failed to load Boot%04X\n",
boot_index);
+ return CMD_RET_FAILURE;
+ }
+
+ ret = do_bootefi_exec(handle, load_options);
+
+ if (ret != EFI_SUCCESS)
+ return CMD_RET_FAILURE;
+
+ return CMD_RET_SUCCESS;
+}
/**
* do_bootefi_image() - execute EFI binary
*
@@ -654,6 +678,22 @@ static int do_bootefi(struct cmd_tbl *cmdtp, int flag, int
argc,
return CMD_RET_FAILURE;
}
+ if (IS_ENABLED(CONFIG_CMD_BOOTEFI_BOOTMGR)) {
+ if (!strcmp(argv[1], "bootindex")) {
+ char *endp;
+ int boot_index;
+
+ if (argc < 3)
+ return CMD_RET_USAGE;
+
+ boot_index = (int)hextoul(argv[2], &endp);
+ if (*endp != '\0' || boot_index > 0x)
+ return CMD_RET_USAGE;
+
+ return do_efibootindex((u16)boot_index);
+ }
+ }
+
if (argc > 2) {
uintptr_t fdt_addr;
@@ -702,6 +742,8 @@ static char bootefi_help_text[] =
"\n"
"If specified, the device tree located at gets\n"
"exposed as EFI configuration table.\n"
+ "bootefi bootindex \n"
+ " - load and boot EFI payload based on the specified Boot
variable.\n"
#endif
;
#endif
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 80a5f1ec01..e5972f5fee 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -861,6 +861,7 @@ efi_status_t efi_set_load_options(efi_handle_t handle,
efi_uintn_t load_options_size,
void *load_options);
efi_status_t efi_bootmgr_load(efi_handle_t *handle, void **load_options);
+efi_status_t efi_try_load_entry(u16 n, efi_handle_t *handle, void
**load_options);
/**
* struct efi_image_regions - A list of memory regions
diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index 8c04ecbdc8..a3060b5c62 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -42,8 +42,7 @@ static const struct efi_runtime_services *rs;
* @load_options: load options set on the loaded image protocol
* Return: status code
*/
-static efi_status_t try_load_entry(u16 n, efi_handle_t *handle,
- void **load_options)
+efi_status_t efi_try_load_entry(u16 n, efi_handle_t *handle, void
**load_options)
{
struct efi_load_option lo;
u16 varname[] = u"Boot";
@@ -165,7 +164,7 @@ efi_status_t efi_bootmgr_load(efi_handle_t *handle, void
**load_options)
/* load BootNext */
if (ret == EFI_SUCCESS) {
if (size == sizeof(u16)) {
- ret = try_load_entry(bootnext, handle,
+ ret = efi_try_load_entry(bootnext, handle,
load_options);
if (ret == EFI_SUCCESS)
return ret;
@@ -189,7 +188,7 @@ efi_status_t efi_bootmgr_load(efi_handle_t *handle, void
**load_options)
for (i = 0; i < num; i++) {
log_debug("%s trying to load Boot%04X\n", __func__,
bootorder[i]);
- ret = try_load_entry(bootorder[i], handle, load_options);
+ ret = efi_try_load_entry(bootorder[i], handle, load_options);
if (ret == EFI_SUCCESS)
break;
}
--
2.17.1
[RFC PATCH v3 2/2] bootmenu: add UEFI and disto_boot entries
This commit adds the UEFI related menu entries and
distro_boot entries into the bootmenu.
For UEFI, user can select which UEFI "Boot" option
to execute, call UEFI bootmgr and UEFI boot variable
maintenance menu. UEFI bootmgr entry is required to
correctly handle "BootNext" variable.
For distro_boot, user can select the boot device
included in "boot_targets" u-boot environment variable.
The menu example is as follows.
*** U-Boot Boot Menu ***
Boot 1. kernel (bootmenu_0)
Boot 2. kernel (bootmenu_1)
Reset board (bootmenu_2)
debian (BOOT)
ubuntu (BOOT0001)
UEFI Boot Manager
usb0
scsi0
virtio0
dhcp
UEFI Boot Manager Maintenance
U-Boot console
Press UP/DOWN to move, ENTER to select, ESC/CTRL+C to quit
Signed-off-by: Masahisa Kojima
---
Changes in v3:
- newly created
cmd/bootmenu.c | 268 +++--
1 file changed, 259 insertions(+), 9 deletions(-)
diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
index 409ef9a848..a8dc50dcaa 100644
--- a/cmd/bootmenu.c
+++ b/cmd/bootmenu.c
@@ -3,9 +3,12 @@
* (C) Copyright 2011-2013 Pali Rohár
*/
+#include
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -24,11 +27,20 @@
*/
#define MAX_ENV_SIZE (9 + 2 + 1)
+enum boot_type {
+ BOOT_TYPE_NONE = 0,
+ BOOT_TYPE_BOOTMENU,
+ BOOT_TYPE_UEFI,
+ BOOT_TYPE_DISTRO_BOOT,
+};
+
struct bootmenu_entry {
unsigned short int num; /* unique number 0 .. MAX_COUNT */
char key[3];/* key identifier of number */
- char *title;/* title of entry */
+ u16 *title; /* title of entry */
char *command; /* hush command of entry */
+ enum boot_type type;
+ u16 bootorder;
struct bootmenu_data *menu; /* this bootmenu */
struct bootmenu_entry *next;/* next menu entry (num+1) */
};
@@ -75,7 +87,12 @@ static void bootmenu_print_entry(void *data)
if (reverse)
puts(ANSI_COLOR_REVERSE);
- puts(entry->title);
+ if (entry->type == BOOT_TYPE_BOOTMENU)
+ printf("%ls (bootmenu_%d)", entry->title, entry->bootorder);
+ else if (entry->type == BOOT_TYPE_UEFI)
+ printf("%ls (BOOT%04X)", entry->title, entry->bootorder);
+ else
+ printf("%ls", entry->title);
if (reverse)
puts(ANSI_COLOR_RESET);
@@ -87,6 +104,10 @@ static void bootmenu_autoboot_loop(struct bootmenu_data
*menu,
int i, c;
if (menu->delay > 0) {
+ /* flush input */
+ while (tstc())
+ getchar();
+
printf(ANSI_CURSOR_POSITION, menu->count + 5, 1);
printf(" Hit any key to stop autoboot: %2d ", menu->delay);
}
@@ -300,6 +321,8 @@ static struct bootmenu_data *bootmenu_create(int delay)
menu->active = (int)simple_strtol(default_str, NULL, 10);
while ((option = bootmenu_getoption(i))) {
+ u16 *buf;
+
sep = strchr(option, '=');
if (!sep) {
printf("Invalid bootmenu entry: %s\n", option);
@@ -311,13 +334,13 @@ static struct bootmenu_data *bootmenu_create(int delay)
goto cleanup;
len = sep-option;
- entry->title = malloc(len + 1);
+ buf = calloc(1, (len + 1) * sizeof(u16));
+ entry->title = buf;
if (!entry->title) {
free(entry);
goto cleanup;
}
- memcpy(entry->title, option, len);
- entry->title[len] = 0;
+ utf8_utf16_strncpy(&buf, option, len);
len = strlen(sep + 1);
entry->command = malloc(len + 1);
@@ -333,6 +356,190 @@ static struct bootmenu_data *bootmenu_create(int delay)
entry->num = i;
entry->menu = menu;
+ entry->type = BOOT_TYPE_BOOTMENU;
+ entry->bootorder = i;
+ entry->next = NULL;
+
+ if (!iter)
+ menu->first = entry;
+ else
+ iter->next = entry;
+
+ iter = entry;
+ ++i;
+
+ if (i == MAX_COUNT - 1)
+ break;
+ }
+
+{
+ u16 *bootorder;
+ efi_status_t ret;
+ unsigned short j;
+ efi_uintn_t num, size;
+ void *load_option;
+ struct efi_load_option lo;
+ u16 varname[] = u"Boot";
+
+ /* Initialize EFI drivers */
+ ret = efi_init_obj_list();
+ if (ret != EFI_SUCCESS) {
+ log_err("Error: Cannot initialize UEFI sub-system, r = %lu\n",
+ ret & ~EFI_ERROR_MASK);
+ goto cleanup;
+ }
+
+ b
Re: [RFC PATCH v3 1/2] efi_loader: introduce "bootefi bootindex" command
On Tue, Mar 08, 2022 at 11:07:44PM +0900, Masahisa Kojima wrote:
> This commit introduces the new command "bootefi bootindex".
> With this command, user can select which "Boot" option
> to load and execute.
You can do the same thing with:
$ efidebug boot next 1 (for BOOT0001)
$ bootefi bootmgr
-Takahiro Akashi
> Signed-off-by: Masahisa Kojima
> ---
> Changes in v3:
> - newly created
>
> cmd/bootefi.c| 42
> include/efi_loader.h | 1 +
> lib/efi_loader/efi_bootmgr.c | 7 +++---
> 3 files changed, 46 insertions(+), 4 deletions(-)
>
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 46eebd5ee2..df86438fec 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -416,6 +416,30 @@ static int do_efibootmgr(void)
> return CMD_RET_SUCCESS;
> }
>
> +/**
> + * do_efibootindex() - load and execute the specified Boot option
> + *
> + * Return: status code
> + */
> +static int do_efibootindex(u16 boot_index)
> +{
> + efi_handle_t handle;
> + efi_status_t ret;
> + void *load_options;
> +
> + ret = efi_try_load_entry(boot_index, &handle, &load_options);
> + if (ret != EFI_SUCCESS) {
> + log_notice("EFI boot manager: failed to load Boot%04X\n",
> boot_index);
> + return CMD_RET_FAILURE;
> + }
> +
> + ret = do_bootefi_exec(handle, load_options);
> +
> + if (ret != EFI_SUCCESS)
> + return CMD_RET_FAILURE;
> +
> + return CMD_RET_SUCCESS;
> +}
> /**
> * do_bootefi_image() - execute EFI binary
> *
> @@ -654,6 +678,22 @@ static int do_bootefi(struct cmd_tbl *cmdtp, int flag,
> int argc,
> return CMD_RET_FAILURE;
> }
>
> + if (IS_ENABLED(CONFIG_CMD_BOOTEFI_BOOTMGR)) {
> + if (!strcmp(argv[1], "bootindex")) {
> + char *endp;
> + int boot_index;
> +
> + if (argc < 3)
> + return CMD_RET_USAGE;
> +
> + boot_index = (int)hextoul(argv[2], &endp);
> + if (*endp != '\0' || boot_index > 0x)
> + return CMD_RET_USAGE;
> +
> + return do_efibootindex((u16)boot_index);
> + }
> + }
> +
> if (argc > 2) {
> uintptr_t fdt_addr;
>
> @@ -702,6 +742,8 @@ static char bootefi_help_text[] =
> "\n"
> "If specified, the device tree located at gets\n"
> "exposed as EFI configuration table.\n"
> + "bootefi bootindex \n"
> + " - load and boot EFI payload based on the specified Boot
> variable.\n"
> #endif
> ;
> #endif
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 80a5f1ec01..e5972f5fee 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -861,6 +861,7 @@ efi_status_t efi_set_load_options(efi_handle_t handle,
> efi_uintn_t load_options_size,
> void *load_options);
> efi_status_t efi_bootmgr_load(efi_handle_t *handle, void **load_options);
> +efi_status_t efi_try_load_entry(u16 n, efi_handle_t *handle, void
> **load_options);
>
> /**
> * struct efi_image_regions - A list of memory regions
> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> index 8c04ecbdc8..a3060b5c62 100644
> --- a/lib/efi_loader/efi_bootmgr.c
> +++ b/lib/efi_loader/efi_bootmgr.c
> @@ -42,8 +42,7 @@ static const struct efi_runtime_services *rs;
> * @load_options:load options set on the loaded image protocol
> * Return: status code
> */
> -static efi_status_t try_load_entry(u16 n, efi_handle_t *handle,
> -void **load_options)
> +efi_status_t efi_try_load_entry(u16 n, efi_handle_t *handle, void
> **load_options)
> {
> struct efi_load_option lo;
> u16 varname[] = u"Boot";
> @@ -165,7 +164,7 @@ efi_status_t efi_bootmgr_load(efi_handle_t *handle, void
> **load_options)
> /* load BootNext */
> if (ret == EFI_SUCCESS) {
> if (size == sizeof(u16)) {
> - ret = try_load_entry(bootnext, handle,
> + ret = efi_try_load_entry(bootnext, handle,
>load_options);
> if (ret == EFI_SUCCESS)
> return ret;
> @@ -189,7 +188,7 @@ efi_status_t efi_bootmgr_load(efi_handle_t *handle, void
> **load_options)
> for (i = 0; i < num; i++) {
> log_debug("%s trying to load Boot%04X\n", __func__,
> bootorder[i]);
> - ret = try_load_entry(bootorder[i], handle, load_options);
> + ret = efi_try_load_entry(bootorder[i], handle, load_options);
> if (ret == EFI_SUCCESS)
> break;
> }
> --
> 2.17.1
>
Re: [PATCH] usb: dwc3: Add support for usb3-phy PHY configuration
On 3/8/22 14:46, Michal Simek wrote: On 3/8/22 14:39, Marek Vasut wrote: On 3/8/22 14:21, Michal Simek wrote: On 3/4/22 18:33, Marek Vasut wrote: On 3/4/22 05:42, Marek Vasut wrote: On 3/3/22 09:40, Bin Meng wrote: On Wed, Feb 23, 2022 at 10:56 PM Michal Simek wrote: When usb3-phy label is found, PHY driver is called and serdes line is initialized. This is preparation for serdes/psgtr driver to configure GT lines based on description in DT. Signed-off-by: Michal Simek --- drivers/usb/dwc3/dwc3-generic.c | 17 + 1 file changed, 17 insertions(+) Reviewed-by: Bin Meng Applied, thanks. Fails to build, please fix. Patch dropped: https://source.denx.de/u-boot/custodians/u-boot-usb/-/jobs/399461 This patch is fixing the problem https://lore.kernel.org/r/eabd31079152659556432fed561cd3a98300c8f5.1646745547.git.michal.si...@xilinx.com I'm confused, is this a patch I should try to apply somehow ? It should be applied before that dwc3 patch. If you don't want to apply it via your usb tree I can take it via my tree or ask Tom to take it. Please just collect the patches in the right order and resubmit them.
Re: [PATCH] usb: dwc3: Add support for usb3-phy PHY configuration
On 3/8/22 16:32, Marek Vasut wrote: On 3/8/22 14:46, Michal Simek wrote: On 3/8/22 14:39, Marek Vasut wrote: On 3/8/22 14:21, Michal Simek wrote: On 3/4/22 18:33, Marek Vasut wrote: On 3/4/22 05:42, Marek Vasut wrote: On 3/3/22 09:40, Bin Meng wrote: On Wed, Feb 23, 2022 at 10:56 PM Michal Simek wrote: When usb3-phy label is found, PHY driver is called and serdes line is initialized. This is preparation for serdes/psgtr driver to configure GT lines based on description in DT. Signed-off-by: Michal Simek --- drivers/usb/dwc3/dwc3-generic.c | 17 + 1 file changed, 17 insertions(+) Reviewed-by: Bin Meng Applied, thanks. Fails to build, please fix. Patch dropped: https://source.denx.de/u-boot/custodians/u-boot-usb/-/jobs/399461 This patch is fixing the problem https://lore.kernel.org/r/eabd31079152659556432fed561cd3a98300c8f5.1646745547.git.michal.si...@xilinx.com I'm confused, is this a patch I should try to apply somehow ? It should be applied before that dwc3 patch. If you don't want to apply it via your usb tree I can take it via my tree or ask Tom to take it. Please just collect the patches in the right order and resubmit them. They were sent in the right order. 1/2 header fix, 2/2 dwc3 fix. Both of them are in patchwork. M
Re: [PATCH v2 05/13] event: Add basic support for events
Hi Takahiro, On Sun, 6 Mar 2022 at 21:26, AKASHI Takahiro wrote: > > Hi Simon, > > On Fri, Mar 04, 2022 at 08:43:00AM -0700, Simon Glass wrote: > > Add a way to create and dispatch events without needing to allocate > > memory. Also add a way to 'spy' on events, thus allowing 'hooks' to be > > created. > > > > Use a linker list for static events, which we can use to replace functions > > like arch_cpu_init_f(). Allow an EVENT_DEBUG option which makes it > > easier to see what is going on at runtime, but uses more code space. > > > > Dynamic events allow the creation of a spy at runtime. This is not always > > necessary, but can be enabled with EVENT_DYNAMIC if needed. > > > > A 'test' event is the only option for now. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v2: > > - Add a 'used' attribute to avoid LTO dropping the code > > > > MAINTAINERS | 6 + > > common/Kconfig| 31 + > > common/Makefile | 2 + > > common/board_r.c | 1 + > > common/event.c| 186 + > > common/log.c | 1 + > > include/asm-generic/global_data.h | 13 +++ > > include/event.h | 188 ++ > > include/event_internal.h | 35 ++ > > include/log.h | 2 + > > 10 files changed, 465 insertions(+) > > create mode 100644 common/event.c > > create mode 100644 include/event.h > > create mode 100644 include/event_internal.h > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index fb171e0c68..b534ad66b9 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -809,6 +809,12 @@ S: Maintained > > F: doc/usage/environment.rst > > F: scripts/env2string.awk > > > > +EVENTS > > +M: Simon Glass > > +S: Maintained > > +F: common/event.c > > +F: include/event.h > > + > > FASTBOOT > > S: Orphaned > > F: cmd/fastboot.c > > diff --git a/common/Kconfig b/common/Kconfig > > index 82cd864baf..76c04b2001 100644 > > --- a/common/Kconfig > > +++ b/common/Kconfig > > @@ -492,6 +492,37 @@ config DISPLAY_BOARDINFO_LATE > > > > menu "Start-up hooks" > > > > +config EVENT > > + bool "General-purpose event-handling mechanism" > > I don't think that this config option needs to be visible (or > user-selectable). > Instead, any subsystem that needs it should explicitly select it. > I prefer that subsystem can add "select EVENT or DM_EVENT" rather than > "imply" or "depends on". But events can be added for other reasons. For example a board may want to detect that a USB controller is about to be probed and enable power to devices on that USB bus so that the devices are enumerated. This series is partly about replacing all the various hooks we currently have but goes further than that. [..] Regards, Simon
Re: [PATCH v2 00/13] event: Provide support for events to connect subsystems
Hi Tom, On Tue, 8 Mar 2022 at 06:26, Tom Rini wrote: > > On Tue, Mar 08, 2022 at 02:11:02PM +0100, Heinrich Schuchardt wrote: > > On 3/4/22 16:42, Simon Glass wrote: > > > It is a common need in U-Boot to have one subsystem notify another > > > when something happens. An example is reading a partition table when a > > > new block device is set up. > > > > > > It is also common to add weak functions and 'hook' functions to modify > > > how U-Boot works. See for example ft_board_setup() and the like. > > > > > > U-Boot would benefit from a generic mechanism to handle these cases, > > > with the ability to hook into various 'events' in a > > > subsystem-independent and transparent way. > > > > > > This series provides a way to create and dispatch events, with a way of > > > registering a 'spy' which watches for events of different types. This > > > allows 'hook' functions to be created in a generic way. > > > > > > It also includes a script to list the hooks in an image, which is a bit > > > easier to debug than weak functions, as well as an 'event' command to > > > do the same from within U-Boot. > > > > > > These 'static' events can be used to replace hooks like misc_init_f(), > > > for example. Also included is basic support for 'dynamic' events, where > > > a spy can be registered at runtime. The need for this is still being > > > figured out. > > > > @Simon, Tom: > > > > What is the status of this series? Takahiro's UEFI integration series > > builds on it. Is it going to be pushed to origin/next soon? > > I'm waiting for Simon to reply to Takahiro's comment on v2 before > applying. OK I found it and replied. Regards, Simon
Re: Porting U-Boot's UEFI Payload to coreboot
Hi, On Tue, 8 Mar 2022 at 06:57, Heinrich Schuchardt wrote: > > On 3/8/22 13:59, Ahamed Husni wrote: > > Hi everyone, > > > > I am trying to work on a project to port the U-Boot UEFI code to coreboot > > as a payload. > > I haven't worked with UEFI before except running a basic EFI payload in a > > coreboot/u-boot environment. (Serial output: > > https://gist.github.com/drac98/6166d29f6c3a2baf2f4e791925ea98d3) > > > > I would like to know how UEFI is implemented in U-Boot. Is UEFI integrated > > into u-boot or is it implemented like a payload? > > Hello Ahamed, > > the UEFI API implementation is an integral part of U-Boot. > > > > > Where is the UEFI source code? Is it the following files in the tree > > https://source.denx.de/u-boot/custodians/u-boot-efi > > lib/ > > |__ efi/ > > |__ efi_driver/ > > |__ efi_loader/ > > U-Boot can both be run on top of UEFI. This is the code you find in > /lib/efi/. Furthermore UEFI can run as a firmware providing the UEFI > API. This is what you find in /lib/efi_loader/ and /lib/efi_driver/. > > You can build U-Boot as payload for coreboot which offers the UEFI API > implementation. See configs/coreboot64_defconfig. > > U-Boot runs ARM and RISC-V Linux successfully via UEFI. > > What architecture are you looking at? > > Simon (on CC) has been working on U-Boot on UEFI and Coreboot while I > have concentrated on the UEFI API implementation in U-Boot. Yes you can use U-Boot as a coreboot payload - this is now running in CI so we make sure it works on each release. I plan to add more test cases to it but have been waiting to see if coreboot can add something similar to its CI. +Stefan Reinauer as we have been talking about this It seems better to go that way than trying to duplicate efforts. We have a program now to move UEFI to use driver model properly, for example. Regards, Simon
Re: [PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model
Hi, On Tue, 8 Mar 2022 at 06:29, Heinrich Schuchardt wrote: > > On 3/8/22 14:04, AKASHI Takahiro wrote: > > On Tue, Mar 08, 2022 at 01:59:08PM +0100, Heinrich Schuchardt wrote: > >> On 3/8/22 12:36, AKASHI Takahiro wrote: > >>> With this patch set[1] applied, UEFI subsystem maintains a list of its > >>> disk objects dynamically at runtime based on block device's probing. > >>> (See "issues" below.) > >>> > >>> [1] https://github.com/t-akashi/u-boot/tree/efi/dm_disk > >> > >> On sandbox_defconfig with CONFIG_EFI_SELFTEST=y I see this error which > >> does not occur without your patches: > >> > >> Executing 'load file protocol' > >> lib/efi_selftest/efi_selftest_load_file.c(220): > >> ERROR: Wrong remaining device path > >> lib/efi_selftest/efi_selftest_load_file.c(396): > >> ERROR: Failed to load image > >> lib/efi_selftest/efi_selftest.c(114): > >> ERROR: Executing 'load file protocol' failed > > I missed to put Simon's event series first. With both series the error > vanishes. +Tom Rini I'm really looking forward to getting this all in! It is another one that has been hanging around for too long. - Simon
Re: [PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model
On 3/8/22 12:36, AKASHI Takahiro wrote: With this patch set[1] applied, UEFI subsystem maintains a list of its disk objects dynamically at runtime based on block device's probing. (See "issues" below.) [1]https://github.com/t-akashi/u-boot/tree/efi/dm_disk This series together with Simon's series breaks multiple boards due to size constraints: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/11197 Please, investigate how to work around this issue. Best regards Heinrich
Re: [PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model
Hi, On Tue, 8 Mar 2022 at 09:49, Heinrich Schuchardt wrote: > > On 3/8/22 12:36, AKASHI Takahiro wrote: > > With this patch set[1] applied, UEFI subsystem maintains a list of its > > disk objects dynamically at runtime based on block device's probing. > > (See "issues" below.) > > > > [1]https://github.com/t-akashi/u-boot/tree/efi/dm_disk > > This series together with Simon's series breaks multiple boards due to > size constraints: > > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/11197 > > Please, investigate how to work around this issue. tbs2910 - perhaps we should just drop this board? It doesn't use DM_SERIAL and still uses OF_EMBED rcar3_salvator-x - can we put the partition changes behind a config? phycore-rk3288 - something going on in SPL, perhaps needs an additional config to disable it? Regards, Simon
Re: [PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model
On 3/8/22 17:56, Simon Glass wrote:
Hi,
On Tue, 8 Mar 2022 at 09:49, Heinrich Schuchardt wrote:
On 3/8/22 12:36, AKASHI Takahiro wrote:
With this patch set[1] applied, UEFI subsystem maintains a list of its
disk objects dynamically at runtime based on block device's probing.
(See "issues" below.)
[1]https://github.com/t-akashi/u-boot/tree/efi/dm_disk
This series together with Simon's series breaks multiple boards due to
size constraints:
https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/11197
Please, investigate how to work around this issue.
tbs2910 - perhaps we should just drop this board? It doesn't use
DM_SERIAL and still uses OF_EMBED
rcar3_salvator-x - can we put the partition changes behind a config?
This board came up before. 34f2577e926da ("ARM: renesas: reduce
rcar3_salvator-x image size"). It is generally at the size limit.
phycore-rk3288 - something going on in SPL, perhaps needs an
additional config to disable it?
Do we need any of your events on SPL?
Best regards
Heinrich
Regards,
Simon
Re: [PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model
Hi Heinrich,
On Tue, 8 Mar 2022 at 10:26, Heinrich Schuchardt wrote:
>
> On 3/8/22 17:56, Simon Glass wrote:
> > Hi,
> >
> > On Tue, 8 Mar 2022 at 09:49, Heinrich Schuchardt wrote:
> >>
> >> On 3/8/22 12:36, AKASHI Takahiro wrote:
> >>> With this patch set[1] applied, UEFI subsystem maintains a list of its
> >>> disk objects dynamically at runtime based on block device's probing.
> >>> (See "issues" below.)
> >>>
> >>> [1]https://github.com/t-akashi/u-boot/tree/efi/dm_disk
> >>
> >> This series together with Simon's series breaks multiple boards due to
> >> size constraints:
> >>
> >> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/11197
> >>
> >> Please, investigate how to work around this issue.
> >
> > tbs2910 - perhaps we should just drop this board? It doesn't use
> > DM_SERIAL and still uses OF_EMBED
> > rcar3_salvator-x - can we put the partition changes behind a config?
>
> This board came up before. 34f2577e926da ("ARM: renesas: reduce
> rcar3_salvator-x image size"). It is generally at the size limit.
>
> > phycore-rk3288 - something going on in SPL, perhaps needs an
> > additional config to disable it?
>
> Do we need any of your events on SPL?
Not so far.
Regards,
Simon
[PATCH] Nokia RX-51: Update documentation about QEMU
Add section how to run U-Boot in n900 qemu machine. Signed-off-by: Pali Rohár --- doc/board/nokia/rx51.rst | 47 1 file changed, 47 insertions(+) diff --git a/doc/board/nokia/rx51.rst b/doc/board/nokia/rx51.rst index 941f78e777ee..b297e056c4e7 100644 --- a/doc/board/nokia/rx51.rst +++ b/doc/board/nokia/rx51.rst @@ -160,3 +160,50 @@ UBIFS support add following lines into file ``configs/nokia_rx51_defconfig``:: CONFIG_CMD_UBIFS=y CONFIG_MTD_UBI_FASTMAP=y CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT=1 + +Run in QEMU +--- + +Download and compile Linaro version of qemu which contains ``n900`` qemu +machine. Source code is available in qemu-linaro git repository and the +last working version is at commit 8f8d8e0796efe1a6f34cdd83fb798f3c41217ec1. + +Use following commands to compile ``qemu-system-arm`` binary with ``n900`` +qemu machine support:: + +git clone https://git.linaro.org/qemu/qemu-linaro.git +cd qemu-linaro +git checkout 8f8d8e0796efe1a6f34cdd83fb798f3c41217ec1 +./configure --enable-system --target-list=arm-softmmu --disable-werror +make -j4 +cd .. +ln -s qemu-linaro/arm-softmmu/qemu-system-arm . + +Using ``n900`` qemu machine requires proprietary Nokia qemu ``qflasher`` tool +(in reality it is just generator of qemu MTD images) with first stage images +(``xloader-qemu.bin`` and ``secondary-qemu.bin``), similar what is required +on the real HW. License of flasher and images allows non-commercial +redistribution and it is available at maemo.org website:: + +wget -c http://repository.maemo.org/qemu-n900/qemu-n900.tar.gz +tar -xf qemu-n900.tar.gz + +To generate qemu bootable MTD image ``mtd.img`` from U-Boot binary +``u-boot.bin`` and unpacked first stage images, run following command:: + +./qflasher -v -x xloader-qemu.bin -s secondary-qemu.bin -k u-boot.bin -m rx51 -o mtd.img + +Instead of ``u-boot.bin`` binary it is possible to also used combined +U-Boot + kernel binary ``combined.bin``. + +Finally, to boot ``mtd.img`` with graphics display and keyboard with optional +serial console on current terminal, run:: + +./qemu-system-arm -M n900 -mtdblock mtd.img -serial /dev/tty + +Additionally it is possible to emulate also eMMC and uSD card by appending +qemu ``-sd`` arguments:: + +./qemu-system-arm -M n900 -mtdblock mtd.img -sd emmc.img -sd sd.img -serial /dev/tty + +For more examples, look into the ``test/nokia_rx51_test.sh`` CI testing script. -- 2.20.1
[PATCH] arm: dts: imx8m*-venice: add gpio hog support
Add gpio hog support for board-specific gpio lines:
- put hogs in u-boot.dtsi so as to keep the regular dts files
in sync with the kernel. The hogs will not be put in the kernel
as that makes them un-usable by userspace as well as
re-initializes them to dt defaults overriding changes which may
have been done by bootloader commands.
- specify gpio names and initial config
- enable GPIO_HOG
Signed-off-by: Tim Harvey
---
.../dts/imx8mm-venice-gw71xx-0x-u-boot.dtsi | 46 ++
.../dts/imx8mm-venice-gw72xx-0x-u-boot.dtsi | 81 ++
.../dts/imx8mm-venice-gw73xx-0x-u-boot.dtsi | 81 ++
arch/arm/dts/imx8mm-venice-gw7901-u-boot.dtsi | 118 ++
arch/arm/dts/imx8mm-venice-gw7902-u-boot.dtsi | 150 ++
arch/arm/dts/imx8mm-venice-gw7903-u-boot.dtsi | 83 ++
arch/arm/dts/imx8mn-venice-gw7902-u-boot.dtsi | 108 +
configs/imx8mm_venice_defconfig | 1 +
configs/imx8mn_venice_defconfig | 1 +
9 files changed, 669 insertions(+)
diff --git a/arch/arm/dts/imx8mm-venice-gw71xx-0x-u-boot.dtsi
b/arch/arm/dts/imx8mm-venice-gw71xx-0x-u-boot.dtsi
index f5d52c2fe259..b3592331c72b 100644
--- a/arch/arm/dts/imx8mm-venice-gw71xx-0x-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-venice-gw71xx-0x-u-boot.dtsi
@@ -3,3 +3,49 @@
* Copyright 2021 Gateworks Corporation
*/
#include "imx8mm-venice-gw700x-u-boot.dtsi"
+
+&gpio1 {
+ pci_usb_sel {
+ gpio-hog;
+ output-low;
+ gpios = <6 GPIO_ACTIVE_HIGH>;
+ line-name = "pci_usb_sel";
+ };
+
+ dio_0 {
+ gpio-hog;
+ input;
+ gpios = <7 GPIO_ACTIVE_HIGH>;
+ line-name = "dio0";
+ };
+
+ dio_1 {
+ gpio-hog;
+ input;
+ gpios = <9 GPIO_ACTIVE_HIGH>;
+ line-name = "dio1";
+ };
+};
+
+&gpio4 {
+ dio_2 {
+ gpio-hog;
+ input;
+ gpios = <3 GPIO_ACTIVE_HIGH>;
+ line-name = "dio2";
+ };
+
+ dio_3 {
+ gpio-hog;
+ input;
+ gpios = <4 GPIO_ACTIVE_HIGH>;
+ line-name = "dio3";
+ };
+
+ pci_wdis {
+ gpio-hog;
+ output-high;
+ gpios = <7 GPIO_ACTIVE_HIGH>;
+ line-name = "pci_wdis#";
+ };
+};
diff --git a/arch/arm/dts/imx8mm-venice-gw72xx-0x-u-boot.dtsi
b/arch/arm/dts/imx8mm-venice-gw72xx-0x-u-boot.dtsi
index f5d52c2fe259..92e44d4ba96b 100644
--- a/arch/arm/dts/imx8mm-venice-gw72xx-0x-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-venice-gw72xx-0x-u-boot.dtsi
@@ -3,3 +3,84 @@
* Copyright 2021 Gateworks Corporation
*/
#include "imx8mm-venice-gw700x-u-boot.dtsi"
+
+&gpio1 {
+ rs485_term {
+ gpio-hog;
+ output-low;
+ gpios = <0 GPIO_ACTIVE_HIGH>;
+ line-name = "rs485_term";
+ };
+
+ mipi_gpio4 {
+ gpio-hog;
+ input;
+ gpios = <1 GPIO_ACTIVE_HIGH>;
+ line-name = "mipi_gpio4";
+ };
+
+ pci_usb_sel {
+ gpio-hog;
+ output-low;
+ gpios = <6 GPIO_ACTIVE_HIGH>;
+ line-name = "pci_usb_sel";
+ };
+
+ dio_0 {
+ gpio-hog;
+ input;
+ gpios = <7 GPIO_ACTIVE_HIGH>;
+ line-name = "dio0";
+ };
+
+ dio_1 {
+ gpio-hog;
+ input;
+ gpios = <9 GPIO_ACTIVE_HIGH>;
+ line-name = "dio1";
+ };
+};
+
+&gpio4 {
+ rs485_en {
+ gpio-hog;
+ output-low;
+ gpios = <0 GPIO_ACTIVE_HIGH>;
+ line-name = "rs485_en";
+ };
+
+ mipi_gpio3 {
+ gpio-hog;
+ input;
+ gpios = <1 GPIO_ACTIVE_HIGH>;
+ line-name = "mipi_gpio3";
+ };
+
+ rs485_half {
+ gpio-hog;
+ output-low;
+ gpios = <2 GPIO_ACTIVE_HIGH>;
+ line-name = "rs485_hd";
+ };
+
+ mipi_gpio2 {
+ gpio-hog;
+ input;
+ gpios = <3 GPIO_ACTIVE_HIGH>;
+ line-name = "mipi_gpio2";
+ };
+
+ mipi_gpio1 {
+ gpio-hog;
+ input;
+ gpios = <4 GPIO_ACTIVE_HIGH>;
+ line-name = "mipi_gpio1";
+ };
+
+ pci_wdis {
+ gpio-hog;
+ output-high;
+ gpios = <7 GPIO_ACTIVE_HIGH>;
+ line-name = "pci_wdis#";
+ };
+};
diff --git a/arch/arm/dts/imx8mm-venice-gw73xx-0x-u-boot.dtsi
b/arch/arm/dts/imx8mm-venice-gw73xx-0x-u-boot.dtsi
index f5d52c2fe259..92e44d4ba96b 100644
--- a/arch/arm/dts/imx8mm-venice-gw73xx-0x-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-venice-gw73xx-0x-u-boot.dtsi
@@ -3,3 +3,84 @@
* Copyri
[PATCH] imx8m{m,n}-venice-gw7902: add GSC ADC rail for VDD_5P0
The GW7902-C revision adds an ADC for the VDD_5P0 voltage rail.
Add register definitions for it.
Signed-off-by: Tim Harvey
---
arch/arm/dts/imx8mm-venice-gw7902.dts | 7 +++
arch/arm/dts/imx8mn-venice-gw7902.dts | 7 +++
2 files changed, 14 insertions(+)
diff --git a/arch/arm/dts/imx8mm-venice-gw7902.dts
b/arch/arm/dts/imx8mm-venice-gw7902.dts
index d37ffc050da2..adf521632d63 100644
--- a/arch/arm/dts/imx8mm-venice-gw7902.dts
+++ b/arch/arm/dts/imx8mm-venice-gw7902.dts
@@ -348,6 +348,13 @@
gw,voltage-divider-ohms = <1 1>;
};
+ channel@9c {
+ gw,mode = <2>;
+ reg = <0x9c>;
+ label = "vdd_5p0";
+ gw,voltage-divider-ohms = <1 1>;
+ };
+
channel@a2 {
gw,mode = <2>;
reg = <0xa2>;
diff --git a/arch/arm/dts/imx8mn-venice-gw7902.dts
b/arch/arm/dts/imx8mn-venice-gw7902.dts
index d3c08e59c542..29897c161b96 100644
--- a/arch/arm/dts/imx8mn-venice-gw7902.dts
+++ b/arch/arm/dts/imx8mn-venice-gw7902.dts
@@ -347,6 +347,13 @@
gw,voltage-divider-ohms = <1 1>;
};
+ channel@9c {
+ gw,mode = <2>;
+ reg = <0x9c>;
+ label = "vdd_5p0";
+ gw,voltage-divider-ohms = <1 1>;
+ };
+
channel@a2 {
gw,mode = <2>;
reg = <0xa2>;
--
2.17.1
[PATCH] board: venice: add spl_board_loader_name
Implement spl_board_loader_name to provide more meaningful device names
vs MMC1 and MMC2.
Signed-off-by: Tim Harvey
---
board/gateworks/venice/spl.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/board/gateworks/venice/spl.c b/board/gateworks/venice/spl.c
index 8b301570577c..b56e1b607d58 100644
--- a/board/gateworks/venice/spl.c
+++ b/board/gateworks/venice/spl.c
@@ -301,3 +301,17 @@ int spl_board_boot_device(enum boot_device boot_dev_spl)
return BOOT_DEVICE_NONE;
}
}
+
+const char *spl_board_loader_name(u32 boot_device)
+{
+ switch (boot_device) {
+ /* SDHC2 */
+ case BOOT_DEVICE_MMC1:
+ return "eMMC";
+ /* SDHC3 */
+ case BOOT_DEVICE_MMC2:
+ return "SD card";
+ default:
+ return NULL;
+ }
+}
--
2.17.1
[PATCH] board: gateworks venice: add support for GPY111 phy
The TI DP83867 phy has been replaced with the MaxLinear GPY111 phy due
to part availability.
Add support for it by adding LED config and dt-prop based internal delay
config tx-delay/rx-delay per PHY ID.
Signed-off-by: Tim Harvey
---
board/gateworks/venice/venice.c | 16
1 file changed, 16 insertions(+)
diff --git a/board/gateworks/venice/venice.c b/board/gateworks/venice/venice.c
index 5334500ef6a7..425c69056da5 100644
--- a/board/gateworks/venice/venice.c
+++ b/board/gateworks/venice/venice.c
@@ -63,6 +63,7 @@ static int setup_fec(void)
int board_phy_config(struct phy_device *phydev)
{
unsigned short val;
+ ofnode node;
switch (phydev->phy_id) {
case 0x2000a231: /* TI DP83867 GbE PHY */
@@ -73,6 +74,21 @@ int board_phy_config(struct phy_device *phydev)
val |= 0xb << 8; /* LED2(Green;Link/Act): blink for TX/RX act */
phy_write(phydev, MDIO_DEVAD_NONE, 24, val);
break;
+ case 0xd565a401: /* MaxLinear GPY111 */
+ puts("GPY111 ");
+ node = phy_get_ofnode(phydev);
+ if (ofnode_valid(node)) {
+ u32 rx_delay, tx_delay;
+
+ rx_delay = ofnode_read_u32_default(node,
"rx-internal-delay-ps", 2000);
+ tx_delay = ofnode_read_u32_default(node,
"tx-internal-delay-ps", 2000);
+ val = phy_read(phydev, MDIO_DEVAD_NONE, 0x17);
+ val &= ~((0x7 << 12) | (0x7 << 8));
+ val |= (rx_delay / 500) << 12;
+ val |= (tx_delay / 500) << 8;
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x17, val);
+ }
+ break;
}
if (phydev->drv->config)
--
2.17.1
[PATCH] imx8m{m,n}_venice_defconfig: add DT overlay support
enable CONFIG_OF_LIBFDT_OVERLAY to support applying dt overlays in U-Boot. Signed-off-by: Tim Harvey --- configs/imx8mm_venice_defconfig | 1 + configs/imx8mn_venice_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/imx8mm_venice_defconfig b/configs/imx8mm_venice_defconfig index 03caef612790..12c283e8cbeb 100644 --- a/configs/imx8mm_venice_defconfig +++ b/configs/imx8mm_venice_defconfig @@ -139,3 +139,4 @@ CONFIG_CI_UDC=y CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_IMX_WATCHDOG=y CONFIG_HEXDUMP=y +CONFIG_OF_LIBFDT_OVERLAY=y diff --git a/configs/imx8mn_venice_defconfig b/configs/imx8mn_venice_defconfig index d0723c440708..cadaf2c0ea2e 100644 --- a/configs/imx8mn_venice_defconfig +++ b/configs/imx8mn_venice_defconfig @@ -142,3 +142,4 @@ CONFIG_CI_UDC=y CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_IMX_WATCHDOG=y CONFIG_HEXDUMP=y +CONFIG_OF_LIBFDT_OVERLAY=y -- 2.17.1
Re: [PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model
On 08.03.22 17:56, Simon Glass wrote: Hi, On Tue, 8 Mar 2022 at 09:49, Heinrich Schuchardt wrote: On 3/8/22 12:36, AKASHI Takahiro wrote: With this patch set[1] applied, UEFI subsystem maintains a list of its disk objects dynamically at runtime based on block device's probing. (See "issues" below.) [1]https://github.com/t-akashi/u-boot/tree/efi/dm_disk This series together with Simon's series breaks multiple boards due to size constraints: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/11197 Please, investigate how to work around this issue. tbs2910 - perhaps we should just drop this board? It doesn't use DM_SERIAL and still uses OF_EMBED Are we again at the same point? You are breaking working boards with (for these boards) useless additions, and all you come up with is "remove this board". Of course without adding the board maintainer. What a shame! Soeren rcar3_salvator-x - can we put the partition changes behind a config? phycore-rk3288 - something going on in SPL, perhaps needs an additional config to disable it? Regards, Simon
Re: [PATCH v2 3/3] tools: kwboot: Allow to mix positional arguments with option -b
On Monday 07 March 2022 21:23:29 Tony Dinh wrote:
> Hi Pali,
>
> I've tested this patch series and it's all working fine!
Perfect!
Stefan, I think that this change should go into 2022.04 as it is fixing
regression introduced during 2022.04 development.
Could you do more checks/testing of kwboot if everything is also working
fine for you?
> Thanks,
> Tony
>
> Tested-by: Tony Dinh
>
>
> On Mon, Mar 7, 2022 at 10:04 AM Pali Rohár wrote:
> >
> > Commit 9e6d71d2b55f ("tools: kwboot: Allow to use -b without image path as
> > the last getopt() option") broke usage of kwboot with following arguments:
> >
> > kwboot -t -B 115200 /dev/ttyUSB0 -b u-boot-spl.kwb
> >
> > Fix parsing of option -b with optional argument again.
> >
> > Fixes: 9e6d71d2b55f ("tools: kwboot: Allow to use -b without image path as
> > the last getopt() option")
> > Signed-off-by: Pali Rohár
> > Reported-by: Tony Dinh
> > ---
> > Tony and Marcel, could you test this change if all your kwboot use cases
> > still work correctly?
> > ---
> > tools/kwboot.c | 18 ++
> > 1 file changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/tools/kwboot.c b/tools/kwboot.c
> > index 3b45e19a30aa..9f2dd2de4ef5 100644
> > --- a/tools/kwboot.c
> > +++ b/tools/kwboot.c
> > @@ -2073,7 +2073,8 @@ main(int argc, char **argv)
> > bootmsg = 1;
> > if (prev_optind == optind)
> > goto usage;
> > - if (optind < argc - 1 && argv[optind] &&
> > argv[optind][0] != '-')
> > + /* Option -b could have optional argument which
> > specify image path */
> > + if (optind < argc && argv[optind] &&
> > argv[optind][0] != '-')
> > imgpath = argv[optind++];
> > break;
> >
> > @@ -2128,10 +2129,19 @@ main(int argc, char **argv)
> > if (!bootmsg && !term && !debugmsg && !imgpath)
> > goto usage;
> >
> > - ttypath = argv[optind++];
> > -
> > - if (optind != argc)
> > + /*
> > +* If there is no remaining argument but optional imgpath was parsed
> > +* then it means that optional imgpath was eaten by getopt parser.
> > +* Reassing imgpath to required ttypath argument.
> > +*/
> > + if (optind == argc && imgpath) {
> > + ttypath = imgpath;
> > + imgpath = NULL;
> > + } else if (optind + 1 == argc) {
> > + ttypath = argv[optind];
> > + } else {
> > goto usage;
> > + }
> >
> > /* boot and debug message use baudrate 115200 */
> > if (((bootmsg && !imgpath) || debugmsg) && baudrate != 115200) {
> > --
> > 2.20.1
> >
Re: [PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model
Hi Soeren, On Tue, 8 Mar 2022 at 12:15, Soeren Moch wrote: > > > > On 08.03.22 17:56, Simon Glass wrote: > > Hi, > > > > On Tue, 8 Mar 2022 at 09:49, Heinrich Schuchardt wrote: > >> > >> On 3/8/22 12:36, AKASHI Takahiro wrote: > >>> With this patch set[1] applied, UEFI subsystem maintains a list of its > >>> disk objects dynamically at runtime based on block device's probing. > >>> (See "issues" below.) > >>> > >>> [1]https://github.com/t-akashi/u-boot/tree/efi/dm_disk > >> > >> This series together with Simon's series breaks multiple boards due to > >> size constraints: > >> > >> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/11197 > >> > >> Please, investigate how to work around this issue. > > > > tbs2910 - perhaps we should just drop this board? It doesn't use > > DM_SERIAL and still uses OF_EMBED > > Are we again at the same point? You are breaking working boards with > (for these boards) useless additions, and all you come up with is > "remove this board". Of course without adding the board maintainer. I'm just expressing reasonable frustration that this board uses OF_EMBED and does not use DM_SERIAL, after all of this time. Why should the rest of the U-Boot developers care more about this board than the maintainer? Regards, Simon
Re: [PATCH] usb: dwc3: Add support for usb3-phy PHY configuration
On 3/8/22 16:34, Michal Simek wrote: On 3/8/22 16:32, Marek Vasut wrote: On 3/8/22 14:46, Michal Simek wrote: On 3/8/22 14:39, Marek Vasut wrote: On 3/8/22 14:21, Michal Simek wrote: On 3/4/22 18:33, Marek Vasut wrote: On 3/4/22 05:42, Marek Vasut wrote: On 3/3/22 09:40, Bin Meng wrote: On Wed, Feb 23, 2022 at 10:56 PM Michal Simek wrote: When usb3-phy label is found, PHY driver is called and serdes line is initialized. This is preparation for serdes/psgtr driver to configure GT lines based on description in DT. Signed-off-by: Michal Simek --- drivers/usb/dwc3/dwc3-generic.c | 17 + 1 file changed, 17 insertions(+) Reviewed-by: Bin Meng Applied, thanks. Fails to build, please fix. Patch dropped: https://source.denx.de/u-boot/custodians/u-boot-usb/-/jobs/399461 This patch is fixing the problem https://lore.kernel.org/r/eabd31079152659556432fed561cd3a98300c8f5.1646745547.git.michal.si...@xilinx.com I'm confused, is this a patch I should try to apply somehow ? It should be applied before that dwc3 patch. If you don't want to apply it via your usb tree I can take it via my tree or ask Tom to take it. Please just collect the patches in the right order and resubmit them. They were sent in the right order. 1/2 header fix, 2/2 dwc3 fix. Both of them are in patchwork. I received random lore patch link here, another half of series in another thread and now I should look up yet more patches in patchwork. I am really confused, I do not know what you expect me to do about this, randomly try to chase down patches in multiple patch trackers, try to apply them somehow, and likely get it all wrong? Please, collect and resubmit the patches which you want applied, that way we can be certain I apply the right patches in the right order.
Re: [PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model
On Tue, Mar 08, 2022 at 02:20:15PM -0700, Simon Glass wrote: > Hi Soeren, > > On Tue, 8 Mar 2022 at 12:15, Soeren Moch wrote: > > > > > > > > On 08.03.22 17:56, Simon Glass wrote: > > > Hi, > > > > > > On Tue, 8 Mar 2022 at 09:49, Heinrich Schuchardt > > > wrote: > > >> > > >> On 3/8/22 12:36, AKASHI Takahiro wrote: > > >>> With this patch set[1] applied, UEFI subsystem maintains a list of its > > >>> disk objects dynamically at runtime based on block device's probing. > > >>> (See "issues" below.) > > >>> > > >>> [1]https://github.com/t-akashi/u-boot/tree/efi/dm_disk > > >> > > >> This series together with Simon's series breaks multiple boards due to > > >> size constraints: > > >> > > >> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/11197 > > >> > > >> Please, investigate how to work around this issue. > > > > > > tbs2910 - perhaps we should just drop this board? It doesn't use > > > DM_SERIAL and still uses OF_EMBED > > > > Are we again at the same point? You are breaking working boards with > > (for these boards) useless additions, and all you come up with is > > "remove this board". Of course without adding the board maintainer. > > I'm just expressing reasonable frustration that this board uses > OF_EMBED and does not use DM_SERIAL, after all of this time. Why > should the rest of the U-Boot developers care more about this board > than the maintainer? Please keep in mind Simon that we've had zero releases with the DM_SERIAL migration warning being posted, v2022.04 will be the first one. -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH v3 1/2] efi_loader: introduce "bootefi bootindex" command
On Tue, 8 Mar 2022 at 23:17, Takahiro Akashi wrote:
>
> On Tue, Mar 08, 2022 at 11:07:44PM +0900, Masahisa Kojima wrote:
> > This commit introduces the new command "bootefi bootindex".
> > With this command, user can select which "Boot" option
> > to load and execute.
>
> You can do the same thing with:
> $ efidebug boot next 1 (for BOOT0001)
> $ bootefi bootmgr
Thank you for the information, it is good to know.
My only concern is that user needs to enable "efidebug" command
for this case, since efidebug implies that it is for debug purpose.
Thanks,
Masahisa Kojima
>
> -Takahiro Akashi
>
>
> > Signed-off-by: Masahisa Kojima
> > ---
> > Changes in v3:
> > - newly created
> >
> > cmd/bootefi.c| 42
> > include/efi_loader.h | 1 +
> > lib/efi_loader/efi_bootmgr.c | 7 +++---
> > 3 files changed, 46 insertions(+), 4 deletions(-)
> >
> > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > index 46eebd5ee2..df86438fec 100644
> > --- a/cmd/bootefi.c
> > +++ b/cmd/bootefi.c
> > @@ -416,6 +416,30 @@ static int do_efibootmgr(void)
> > return CMD_RET_SUCCESS;
> > }
> >
> > +/**
> > + * do_efibootindex() - load and execute the specified Boot option
> > + *
> > + * Return: status code
> > + */
> > +static int do_efibootindex(u16 boot_index)
> > +{
> > + efi_handle_t handle;
> > + efi_status_t ret;
> > + void *load_options;
> > +
> > + ret = efi_try_load_entry(boot_index, &handle, &load_options);
> > + if (ret != EFI_SUCCESS) {
> > + log_notice("EFI boot manager: failed to load Boot%04X\n",
> > boot_index);
> > + return CMD_RET_FAILURE;
> > + }
> > +
> > + ret = do_bootefi_exec(handle, load_options);
> > +
> > + if (ret != EFI_SUCCESS)
> > + return CMD_RET_FAILURE;
> > +
> > + return CMD_RET_SUCCESS;
> > +}
> > /**
> > * do_bootefi_image() - execute EFI binary
> > *
> > @@ -654,6 +678,22 @@ static int do_bootefi(struct cmd_tbl *cmdtp, int flag,
> > int argc,
> > return CMD_RET_FAILURE;
> > }
> >
> > + if (IS_ENABLED(CONFIG_CMD_BOOTEFI_BOOTMGR)) {
> > + if (!strcmp(argv[1], "bootindex")) {
> > + char *endp;
> > + int boot_index;
> > +
> > + if (argc < 3)
> > + return CMD_RET_USAGE;
> > +
> > + boot_index = (int)hextoul(argv[2], &endp);
> > + if (*endp != '\0' || boot_index > 0x)
> > + return CMD_RET_USAGE;
> > +
> > + return do_efibootindex((u16)boot_index);
> > + }
> > + }
> > +
> > if (argc > 2) {
> > uintptr_t fdt_addr;
> >
> > @@ -702,6 +742,8 @@ static char bootefi_help_text[] =
> > "\n"
> > "If specified, the device tree located at gets\n"
> > "exposed as EFI configuration table.\n"
> > + "bootefi bootindex \n"
> > + " - load and boot EFI payload based on the specified Boot
> > variable.\n"
> > #endif
> > ;
> > #endif
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index 80a5f1ec01..e5972f5fee 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -861,6 +861,7 @@ efi_status_t efi_set_load_options(efi_handle_t handle,
> > efi_uintn_t load_options_size,
> > void *load_options);
> > efi_status_t efi_bootmgr_load(efi_handle_t *handle, void **load_options);
> > +efi_status_t efi_try_load_entry(u16 n, efi_handle_t *handle, void
> > **load_options);
> >
> > /**
> > * struct efi_image_regions - A list of memory regions
> > diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> > index 8c04ecbdc8..a3060b5c62 100644
> > --- a/lib/efi_loader/efi_bootmgr.c
> > +++ b/lib/efi_loader/efi_bootmgr.c
> > @@ -42,8 +42,7 @@ static const struct efi_runtime_services *rs;
> > * @load_options:load options set on the loaded image protocol
> > * Return: status code
> > */
> > -static efi_status_t try_load_entry(u16 n, efi_handle_t *handle,
> > -void **load_options)
> > +efi_status_t efi_try_load_entry(u16 n, efi_handle_t *handle, void
> > **load_options)
> > {
> > struct efi_load_option lo;
> > u16 varname[] = u"Boot";
> > @@ -165,7 +164,7 @@ efi_status_t efi_bootmgr_load(efi_handle_t *handle,
> > void **load_options)
> > /* load BootNext */
> > if (ret == EFI_SUCCESS) {
> > if (size == sizeof(u16)) {
> > - ret = try_load_entry(bootnext, handle,
> > + ret = efi_try_load_entry(bootnext, handle,
> >load_options);
> > if (ret == EFI_SUCCESS)
> > return ret;
> > @@ -189,7 +18
RE: [PATCH] arm: dts: imx8m*-venice: add gpio hog support
> Subject: [PATCH] arm: dts: imx8m*-venice: add gpio hog support
>
> Add gpio hog support for board-specific gpio lines:
> - put hogs in u-boot.dtsi so as to keep the regular dts files
> in sync with the kernel. The hogs will not be put in the kernel
> as that makes them un-usable by userspace as well as
> re-initializes them to dt defaults overriding changes which may
> have been done by bootloader commands.
> - specify gpio names and initial config
> - enable GPIO_HOG
>
> Signed-off-by: Tim Harvey
Acked-by: Peng Fan
> ---
> .../dts/imx8mm-venice-gw71xx-0x-u-boot.dtsi | 46 ++
> .../dts/imx8mm-venice-gw72xx-0x-u-boot.dtsi | 81 ++
> .../dts/imx8mm-venice-gw73xx-0x-u-boot.dtsi | 81 ++
> arch/arm/dts/imx8mm-venice-gw7901-u-boot.dtsi | 118 ++
> arch/arm/dts/imx8mm-venice-gw7902-u-boot.dtsi | 150
> ++ arch/arm/dts/imx8mm-venice-gw7903-u-boot.dtsi |
> 83 ++ arch/arm/dts/imx8mn-venice-gw7902-u-boot.dtsi | 108
> +
> configs/imx8mm_venice_defconfig | 1 +
> configs/imx8mn_venice_defconfig | 1 +
> 9 files changed, 669 insertions(+)
>
> diff --git a/arch/arm/dts/imx8mm-venice-gw71xx-0x-u-boot.dtsi
> b/arch/arm/dts/imx8mm-venice-gw71xx-0x-u-boot.dtsi
> index f5d52c2fe259..b3592331c72b 100644
> --- a/arch/arm/dts/imx8mm-venice-gw71xx-0x-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-venice-gw71xx-0x-u-boot.dtsi
> @@ -3,3 +3,49 @@
> * Copyright 2021 Gateworks Corporation
> */
> #include "imx8mm-venice-gw700x-u-boot.dtsi"
> +
> +&gpio1 {
> + pci_usb_sel {
> + gpio-hog;
> + output-low;
> + gpios = <6 GPIO_ACTIVE_HIGH>;
> + line-name = "pci_usb_sel";
> + };
> +
> + dio_0 {
> + gpio-hog;
> + input;
> + gpios = <7 GPIO_ACTIVE_HIGH>;
> + line-name = "dio0";
> + };
> +
> + dio_1 {
> + gpio-hog;
> + input;
> + gpios = <9 GPIO_ACTIVE_HIGH>;
> + line-name = "dio1";
> + };
> +};
> +
> +&gpio4 {
> + dio_2 {
> + gpio-hog;
> + input;
> + gpios = <3 GPIO_ACTIVE_HIGH>;
> + line-name = "dio2";
> + };
> +
> + dio_3 {
> + gpio-hog;
> + input;
> + gpios = <4 GPIO_ACTIVE_HIGH>;
> + line-name = "dio3";
> + };
> +
> + pci_wdis {
> + gpio-hog;
> + output-high;
> + gpios = <7 GPIO_ACTIVE_HIGH>;
> + line-name = "pci_wdis#";
> + };
> +};
> diff --git a/arch/arm/dts/imx8mm-venice-gw72xx-0x-u-boot.dtsi
> b/arch/arm/dts/imx8mm-venice-gw72xx-0x-u-boot.dtsi
> index f5d52c2fe259..92e44d4ba96b 100644
> --- a/arch/arm/dts/imx8mm-venice-gw72xx-0x-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-venice-gw72xx-0x-u-boot.dtsi
> @@ -3,3 +3,84 @@
> * Copyright 2021 Gateworks Corporation
> */
> #include "imx8mm-venice-gw700x-u-boot.dtsi"
> +
> +&gpio1 {
> + rs485_term {
> + gpio-hog;
> + output-low;
> + gpios = <0 GPIO_ACTIVE_HIGH>;
> + line-name = "rs485_term";
> + };
> +
> + mipi_gpio4 {
> + gpio-hog;
> + input;
> + gpios = <1 GPIO_ACTIVE_HIGH>;
> + line-name = "mipi_gpio4";
> + };
> +
> + pci_usb_sel {
> + gpio-hog;
> + output-low;
> + gpios = <6 GPIO_ACTIVE_HIGH>;
> + line-name = "pci_usb_sel";
> + };
> +
> + dio_0 {
> + gpio-hog;
> + input;
> + gpios = <7 GPIO_ACTIVE_HIGH>;
> + line-name = "dio0";
> + };
> +
> + dio_1 {
> + gpio-hog;
> + input;
> + gpios = <9 GPIO_ACTIVE_HIGH>;
> + line-name = "dio1";
> + };
> +};
> +
> +&gpio4 {
> + rs485_en {
> + gpio-hog;
> + output-low;
> + gpios = <0 GPIO_ACTIVE_HIGH>;
> + line-name = "rs485_en";
> + };
> +
> + mipi_gpio3 {
> + gpio-hog;
> + input;
> + gpios = <1 GPIO_ACTIVE_HIGH>;
> + line-name = "mipi_gpio3";
> + };
> +
> + rs485_half {
> + gpio-hog;
> + output-low;
> + gpios = <2 GPIO_ACTIVE_HIGH>;
> + line-name = "rs485_hd";
> + };
> +
> + mipi_gpio2 {
> + gpio-hog;
> + input;
> + gpios = <3 GPIO_ACTIVE_HIGH>;
> + line-name = "mipi_gpio2";
> + };
> +
> + mipi_gpio1 {
> + gpio-hog;
> + input;
> + gpios = <4 GPIO_ACTIVE_HIGH>;
> + line-name = "mipi_gpio1";
> + };
> +
> + pci_wdis {
> + gpio-hog;
> + output-high;
> + gpios = <7 GPIO_ACTIVE_HIGH>;
> + line-name = "pci_wdis#";
> + };
> +};
> diff --git a/arch/arm/dts/imx8mm-venice-gw73xx-0x-u-boot.dtsi
> b/arch/
RE: [PATCH] imx8m{m,n}-venice-gw7902: add GSC ADC rail for VDD_5P0
> Subject: [PATCH] imx8m{m,n}-venice-gw7902: add GSC ADC rail for VDD_5P0
>
> The GW7902-C revision adds an ADC for the VDD_5P0 voltage rail.
> Add register definitions for it.
>
> Signed-off-by: Tim Harvey
Acked-by: Peng Fan
> ---
> arch/arm/dts/imx8mm-venice-gw7902.dts | 7 +++
> arch/arm/dts/imx8mn-venice-gw7902.dts | 7 +++
> 2 files changed, 14 insertions(+)
>
> diff --git a/arch/arm/dts/imx8mm-venice-gw7902.dts
> b/arch/arm/dts/imx8mm-venice-gw7902.dts
> index d37ffc050da2..adf521632d63 100644
> --- a/arch/arm/dts/imx8mm-venice-gw7902.dts
> +++ b/arch/arm/dts/imx8mm-venice-gw7902.dts
> @@ -348,6 +348,13 @@
> gw,voltage-divider-ohms = <1 1>;
> };
>
> + channel@9c {
> + gw,mode = <2>;
> + reg = <0x9c>;
> + label = "vdd_5p0";
> + gw,voltage-divider-ohms = <1 1>;
> + };
> +
> channel@a2 {
> gw,mode = <2>;
> reg = <0xa2>;
> diff --git a/arch/arm/dts/imx8mn-venice-gw7902.dts
> b/arch/arm/dts/imx8mn-venice-gw7902.dts
> index d3c08e59c542..29897c161b96 100644
> --- a/arch/arm/dts/imx8mn-venice-gw7902.dts
> +++ b/arch/arm/dts/imx8mn-venice-gw7902.dts
> @@ -347,6 +347,13 @@
> gw,voltage-divider-ohms = <1 1>;
> };
>
> + channel@9c {
> + gw,mode = <2>;
> + reg = <0x9c>;
> + label = "vdd_5p0";
> + gw,voltage-divider-ohms = <1 1>;
> + };
> +
> channel@a2 {
> gw,mode = <2>;
> reg = <0xa2>;
> --
> 2.17.1
RE: [PATCH] board: venice: add spl_board_loader_name
> Subject: [PATCH] board: venice: add spl_board_loader_name
>
> Implement spl_board_loader_name to provide more meaningful device
> names vs MMC1 and MMC2.
>
> Signed-off-by: Tim Harvey
Nice. Reviewed-by: Peng Fan
> ---
> board/gateworks/venice/spl.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/board/gateworks/venice/spl.c b/board/gateworks/venice/spl.c
> index 8b301570577c..b56e1b607d58 100644
> --- a/board/gateworks/venice/spl.c
> +++ b/board/gateworks/venice/spl.c
> @@ -301,3 +301,17 @@ int spl_board_boot_device(enum boot_device
> boot_dev_spl)
> return BOOT_DEVICE_NONE;
> }
> }
> +
> +const char *spl_board_loader_name(u32 boot_device) {
> + switch (boot_device) {
> + /* SDHC2 */
> + case BOOT_DEVICE_MMC1:
> + return "eMMC";
> + /* SDHC3 */
> + case BOOT_DEVICE_MMC2:
> + return "SD card";
> + default:
> + return NULL;
> + }
> +}
> --
> 2.17.1
RE: [PATCH] board: gateworks venice: add support for GPY111 phy
> Subject: [PATCH] board: gateworks venice: add support for GPY111 phy
>
> The TI DP83867 phy has been replaced with the MaxLinear GPY111 phy due
> to part availability.
>
> Add support for it by adding LED config and dt-prop based internal delay
> config
> tx-delay/rx-delay per PHY ID.
>
> Signed-off-by: Tim Harvey
Acked-by: Peng Fan
> ---
> board/gateworks/venice/venice.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/board/gateworks/venice/venice.c
> b/board/gateworks/venice/venice.c index 5334500ef6a7..425c69056da5
> 100644
> --- a/board/gateworks/venice/venice.c
> +++ b/board/gateworks/venice/venice.c
> @@ -63,6 +63,7 @@ static int setup_fec(void) int board_phy_config(struct
> phy_device *phydev) {
> unsigned short val;
> + ofnode node;
>
> switch (phydev->phy_id) {
> case 0x2000a231: /* TI DP83867 GbE PHY */ @@ -73,6 +74,21 @@ int
> board_phy_config(struct phy_device *phydev)
> val |= 0xb << 8; /* LED2(Green;Link/Act): blink for TX/RX act */
> phy_write(phydev, MDIO_DEVAD_NONE, 24, val);
> break;
> + case 0xd565a401: /* MaxLinear GPY111 */
> + puts("GPY111 ");
> + node = phy_get_ofnode(phydev);
> + if (ofnode_valid(node)) {
> + u32 rx_delay, tx_delay;
> +
> + rx_delay = ofnode_read_u32_default(node,
> "rx-internal-delay-ps", 2000);
> + tx_delay = ofnode_read_u32_default(node,
> "tx-internal-delay-ps", 2000);
> + val = phy_read(phydev, MDIO_DEVAD_NONE, 0x17);
> + val &= ~((0x7 << 12) | (0x7 << 8));
> + val |= (rx_delay / 500) << 12;
> + val |= (tx_delay / 500) << 8;
> + phy_write(phydev, MDIO_DEVAD_NONE, 0x17, val);
> + }
> + break;
> }
>
> if (phydev->drv->config)
> --
> 2.17.1
Re: [PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model
Heinrich, Simon, On Tue, Mar 08, 2022 at 05:49:13PM +0100, Heinrich Schuchardt wrote: > On 3/8/22 12:36, AKASHI Takahiro wrote: > > With this patch set[1] applied, UEFI subsystem maintains a list of its > > disk objects dynamically at runtime based on block device's probing. > > (See "issues" below.) > > > > [1]https://github.com/t-akashi/u-boot/tree/efi/dm_disk > > This series together with Simon's series breaks multiple boards due to > size constraints: > > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/11197 > > Please, investigate how to work around this issue. I have already mentioned this size issue in my cover-letter in order to let reviewers aware of it and discuss a possible solution: ===8<=== Issues: === * The image size of U-Boot may increase. CI build test complains, for instance, rcar3_salvator-x: "u-boot.img exceeds file size limit: ... excess: 0x79c bytes" phycore-rk3288: "SPL image is too large (size 0x8800 than 0x8000)" See [2]. [2] https://dev.azure.com/u-boot/u-boot/_build/results?buildId=3770&view=results ===>8=== I have dug into rcar3_salvator-x case; I removed *all* the commits in this series and yet enabled CONFIG_EVENT, CONFIG_EVENT_DYNAMIC and CONFIG_DM_EVENT, which are all required for enabling my patch, with Simon's patch applied on top of v2022.04-rc3. Then I still see this size problem: ===8<=== ... MKIMAGE u-boot.img u-boot.img exceeds file size limit: limit: 0x10 bytes actual: 0x100036 bytes excess: 0x36 bytes ===>8=== So I have no way to deal with it. FYI, the combination of EVENT, EVENT_DYNAMIC and DM_EVENT will increase the binary size by up to 0x1b2 for rcar3_salvator-x and it seems the binary has almost already reached its maximum size even now. -Takahiro Akashi > Best regards > > Heinrich
Re: [PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model
Hi Tom, On Tue, 8 Mar 2022 at 17:13, Tom Rini wrote: > > On Tue, Mar 08, 2022 at 02:20:15PM -0700, Simon Glass wrote: > > Hi Soeren, > > > > On Tue, 8 Mar 2022 at 12:15, Soeren Moch wrote: > > > > > > > > > > > > On 08.03.22 17:56, Simon Glass wrote: > > > > Hi, > > > > > > > > On Tue, 8 Mar 2022 at 09:49, Heinrich Schuchardt > > > > wrote: > > > >> > > > >> On 3/8/22 12:36, AKASHI Takahiro wrote: > > > >>> With this patch set[1] applied, UEFI subsystem maintains a list of its > > > >>> disk objects dynamically at runtime based on block device's probing. > > > >>> (See "issues" below.) > > > >>> > > > >>> [1]https://github.com/t-akashi/u-boot/tree/efi/dm_disk > > > >> > > > >> This series together with Simon's series breaks multiple boards due to > > > >> size constraints: > > > >> > > > >> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/11197 > > > >> > > > >> Please, investigate how to work around this issue. > > > > > > > > tbs2910 - perhaps we should just drop this board? It doesn't use > > > > DM_SERIAL and still uses OF_EMBED > > > > > > Are we again at the same point? You are breaking working boards with > > > (for these boards) useless additions, and all you come up with is > > > "remove this board". Of course without adding the board maintainer. > > > > I'm just expressing reasonable frustration that this board uses > > OF_EMBED and does not use DM_SERIAL, after all of this time. Why > > should the rest of the U-Boot developers care more about this board > > than the maintainer? > > Please keep in mind Simon that we've had zero releases with the > DM_SERIAL migration warning being posted, v2022.04 will be the first > one. Yes, understood :-) For OF_EMBED though...? It was actually quite hard to add a migration message until we added the CONFIG_SERIAL base thing and that was a pain to do. For those of us who take on larger refactors etc., we end up spending a lot of our time on these few platforms. I'm not picking on tbs2910in in particular. Regards, Simon
Re: [PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model
Hi Takahiro, On Tue, 8 Mar 2022 at 19:10, AKASHI Takahiro wrote: > > Heinrich, Simon, > > On Tue, Mar 08, 2022 at 05:49:13PM +0100, Heinrich Schuchardt wrote: > > On 3/8/22 12:36, AKASHI Takahiro wrote: > > > With this patch set[1] applied, UEFI subsystem maintains a list of its > > > disk objects dynamically at runtime based on block device's probing. > > > (See "issues" below.) > > > > > > [1]https://github.com/t-akashi/u-boot/tree/efi/dm_disk > > > > This series together with Simon's series breaks multiple boards due to > > size constraints: > > > > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/11197 > > > > Please, investigate how to work around this issue. > > I have already mentioned this size issue in my cover-letter > in order to let reviewers aware of it and discuss a possible solution: > > ===8<=== > Issues: > === > * The image size of U-Boot may increase. CI build test complains, > for instance, > rcar3_salvator-x: > "u-boot.img exceeds file size limit: ... excess: 0x79c bytes" > phycore-rk3288: > "SPL image is too large (size 0x8800 than 0x8000)" > > See [2]. > > [2] > https://dev.azure.com/u-boot/u-boot/_build/results?buildId=3770&view=results > ===>8=== > > I have dug into rcar3_salvator-x case; I removed *all* the commits > in this series and yet enabled CONFIG_EVENT, CONFIG_EVENT_DYNAMIC > and CONFIG_DM_EVENT, which are all required for enabling my patch, > with Simon's patch applied on top of v2022.04-rc3. > > Then I still see this size problem: > ===8<=== > ... > MKIMAGE u-boot.img > u-boot.img exceeds file size limit: > limit: 0x10 bytes > actual: 0x100036 bytes > excess: 0x36 bytes > ===>8=== > > So I have no way to deal with it. > > FYI, the combination of EVENT, EVENT_DYNAMIC and DM_EVENT will > increase the binary size by up to 0x1b2 for rcar3_salvator-x and > it seems the binary has almost already reached its maximum size > even now. So you do need EVENT_DYNAMIC? Does it make sense to make enabling the partition support an option, instead of mandatory? Regards, Simon
Re: [PATCH v3 3/8] tpm: rng: Add driver model interface for TPM RNG device
Hi Sugosh,
On Fri, 4 Mar 2022 at 06:35, Sughosh Ganu wrote:
>
> The TPM device has a builtin random number generator(RNG)
> functionality. Expose the RNG functions of the TPM device to the
> driver model so that they can be used by the EFI_RNG_PROTOCOL if the
> protocol is installed.
>
> Also change the function arguments and return type of the random
> number functions to comply with the driver model api.
>
> Signed-off-by: Sughosh Ganu
> ---
>
> Changes since V2:
>
> * Export the existing tpm*_get_random functions to the driver model
> instead of moving them to the drivers/rng/ directory.
>
> include/tpm-v1.h | 4 ++--
> include/tpm-v2.h | 4 ++--
> lib/tpm-v1.c | 28
> lib/tpm-v2.c | 21 -
> lib/tpm_api.c| 23 +++
> 5 files changed, 59 insertions(+), 21 deletions(-)
>
> diff --git a/include/tpm-v1.h b/include/tpm-v1.h
> index 33d53fb695..d2ff8b446d 100644
> --- a/include/tpm-v1.h
> +++ b/include/tpm-v1.h
> @@ -555,9 +555,9 @@ u32 tpm1_find_key_sha1(struct udevice *dev, const u8
> auth[20],
> * @param dev TPM device
> * @param data output buffer for the random bytes
> * @param countsize of output buffer
> - * Return: return code of the operation
> + * Return: 0 if OK, -ve on error
> */
> -u32 tpm1_get_random(struct udevice *dev, void *data, u32 count);
> +int tpm1_get_random(struct udevice *dev, void *data, size_t count);
>
> /**
> * tpm_finalise_physical_presence() - Finalise physical presence
> diff --git a/include/tpm-v2.h b/include/tpm-v2.h
> index e79c90b939..4fb1e7a948 100644
> --- a/include/tpm-v2.h
> +++ b/include/tpm-v2.h
> @@ -619,9 +619,9 @@ u32 tpm2_pcr_setauthvalue(struct udevice *dev, const char
> *pw,
> * @param data output buffer for the random bytes
> * @param countsize of output buffer
> *
> - * Return: return code of the operation
> + * Return: 0 if OK, -ve on error
> */
> -u32 tpm2_get_random(struct udevice *dev, void *data, u32 count);
> +int tpm2_get_random(struct udevice *dev, void *data, size_t count);
>
> /**
> * Lock data in the TPM
> diff --git a/lib/tpm-v1.c b/lib/tpm-v1.c
> index 22a769c587..57bb4a39cb 100644
> --- a/lib/tpm-v1.c
> +++ b/lib/tpm-v1.c
> @@ -9,12 +9,14 @@
> #include
> #include
> #include
> -#include
> -#include
> +#include
> #include
> #include
> #include "tpm-utils.h"
>
> +#include
> +#include
> +
> #ifdef CONFIG_TPM_AUTH_SESSIONS
>
> #ifndef CONFIG_SHA1
> @@ -869,7 +871,7 @@ u32 tpm1_find_key_sha1(struct udevice *dev, const u8
> auth[20],
>
> #endif /* CONFIG_TPM_AUTH_SESSIONS */
>
> -u32 tpm1_get_random(struct udevice *dev, void *data, u32 count)
> +int tpm1_get_random(struct udevice *dev, void *data, size_t count)
> {
> const u8 command[14] = {
> 0x0, 0xc1, /* TPM_TAG */
> @@ -892,19 +894,19 @@ u32 tpm1_get_random(struct udevice *dev, void *data,
> u32 count)
> if (pack_byte_string(buf, sizeof(buf), "sd",
> 0, command, sizeof(command),
> length_offset, this_bytes))
> - return TPM_LIB_ERROR;
> - err = tpm_sendrecv_command(dev, buf, response,
> + return -EIO;
> + err = tpm_sendrecv_command(dev->parent, buf, response,
>&response_length);
Here it is a bit confused whether dev is the parent tpm device (as the
comment for this function says), or the random device.
> if (err)
> return err;
> if (unpack_byte_string(response, response_length, "d",
>data_size_offset, &data_size))
> - return TPM_LIB_ERROR;
> + return -EIO;
> if (data_size > count)
> - return TPM_LIB_ERROR;
> + return -EIO;
> if (unpack_byte_string(response, response_length, "s",
>data_offset, out, data_size))
> - return TPM_LIB_ERROR;
> + return -EIO;
>
> count -= data_size;
> out += data_size;
> @@ -912,3 +914,13 @@ u32 tpm1_get_random(struct udevice *dev, void *data, u32
> count)
>
> return 0;
> }
> +
> +static const struct dm_rng_ops tpm1_rng_ops = {
> + .read = tpm1_get_random,
> +};
> +
> +U_BOOT_DRIVER(tpm1_rng) = {
> + .name = "tpm1-rng",
> + .id = UCLASS_RNG,
> + .ops= &tpm1_rng_ops,
> +};
This declaration and the ops should go in the random driver. There
should be a op function in that driver which does the API call to the
TPM. Here you are duplicating this driver in two places.
Then you don't need to change the signature of tpm1_get_random().
> diff --git a/lib/tpm-v2.c b/lib/tpm-v2.c
> inde
Re: [PATCH v3 4/8] tpm: Add the RNG child device
Hi,
On Fri, 4 Mar 2022 at 06:35, Sughosh Ganu wrote:
>
> The TPM device comes with the random number generator(RNG)
> functionality which is built into the TPM device. Add logic to add the
> RNG child device in the TPM uclass post probe callback.
>
> The RNG device can then be used to pass a set of random bytes to the
> linux kernel, need for address space randomisation through the
> EFI_RNG_PROTOCOL interface.
>
> Signed-off-by: Sughosh Ganu
> ---
>
> Changes since V2:
> * Enable DM_RNG when CONFIG_TPM is enabled to build the RNG uclass
> code
>
> drivers/tpm/tpm-uclass.c | 60 +---
> lib/Kconfig | 1 +
> 2 files changed, 57 insertions(+), 4 deletions(-)
No new comments from last time, still needs to be addressed.
>
> diff --git a/drivers/tpm/tpm-uclass.c b/drivers/tpm/tpm-uclass.c
> index f67fe1019b..d1b9e0a757 100644
> --- a/drivers/tpm/tpm-uclass.c
> +++ b/drivers/tpm/tpm-uclass.c
> @@ -11,10 +11,16 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include "tpm_internal.h"
>
> +#include
> +
> +#define TPM_RNG1_DRV_NAME "tpm1-rng"
> +#define TPM_RNG2_DRV_NAME "tpm2-rng"
> +
> int tpm_open(struct udevice *dev)
> {
> struct tpm_ops *ops = tpm_get_ops(dev);
> @@ -136,12 +142,58 @@ int tpm_xfer(struct udevice *dev, const uint8_t
> *sendbuf, size_t send_size,
> return 0;
> }
>
> +#if IS_ENABLED(CONFIG_TPM)
> +static int tpm_uclass_post_probe(struct udevice *dev)
> +{
> + int ret;
> + const char *drv = tpm_is_v1(dev) ?
> + TPM_RNG1_DRV_NAME : TPM_RNG2_DRV_NAME;
> + struct udevice *child;
> +
> + ret = device_bind_driver(dev, drv, "tpm-rng0", &child);
> + if (ret == -ENOENT) {
> + log_err("No driver configured for tpm-rng device\n");
> + return 0;
> + }
> +
> + if (ret) {
> + log_err("Unable to bind rng driver with the tpm-rng
> device\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int tpm_uclass_child_pre_probe(struct udevice *dev)
> +{
> + int ret;
> +
> + ret = tpm_open(dev->parent);
> + if (ret == -EBUSY) {
> + log_info("TPM device already opened\n");
> + } else if (ret) {
> + log_err("Unable to open TPM device\n");
> + return ret;
> + }
> +
> + ret = tpm_startup(dev->parent, TPM_ST_CLEAR);
> + if (ret)
> + log_err("Unable to start TPM device\n");
> +
> + return ret;
> +}
> +#endif /* CONFIG_TPM */
> +
> UCLASS_DRIVER(tpm) = {
> - .id = UCLASS_TPM,
> - .name = "tpm",
> - .flags = DM_UC_FLAG_SEQ_ALIAS,
> + .id = UCLASS_TPM,
> + .name = "tpm",
> + .flags = DM_UC_FLAG_SEQ_ALIAS,
> #if CONFIG_IS_ENABLED(OF_REAL)
> - .post_bind = dm_scan_fdt_dev,
> + .post_bind = dm_scan_fdt_dev,
> +#endif
> +#if IS_ENABLED(CONFIG_TPM)
> + .post_probe = tpm_uclass_post_probe,
> + .child_pre_probe= tpm_uclass_child_pre_probe,
> #endif
> .per_device_auto= sizeof(struct tpm_chip_priv),
> };
> diff --git a/lib/Kconfig b/lib/Kconfig
> index 3c6fa99b1a..0f05c97afc 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -341,6 +341,7 @@ source lib/crypt/Kconfig
> config TPM
> bool "Trusted Platform Module (TPM) Support"
> depends on DM
> + select DM_RNG
> help
> This enables support for TPMs which can be used to provide security
> features for your board. The TPM can be connected via LPC or I2C
> --
> 2.25.1
>
Regards,
Simon
Re: [PATCH v3 5/8] qemu: arm: Remove platform specific function to get RNG device
On Fri, 4 Mar 2022 at 06:35, Sughosh Ganu wrote: > > The Qemu platform has a function defined to get the random number > generator(RNG) device. However, the RNG device can be obtained simply > by searching for a device belonging to the RNG uclass. Remove the > superfluous platform function defined for the Qemu platform for > getting the RNG device. > > Signed-off-by: Sughosh Ganu > Tested-by: Heinrich Schuchardt > --- > > Changes since V2: None > > board/emulation/qemu-arm/qemu-arm.c | 42 - > 1 file changed, 42 deletions(-) Reviewed-by: Simon Glass
