RE: [PATCH] mmc: sdhci: introduce adma_write_desc() hook to struct sdhci_ops
Hi,
> -Original Message-
> From: U-Boot On Behalf Of Jaehoon Chung
> Sent: Wednesday, April 17, 2024 9:26 AM
> To: 'Greg Malysa' ; u-boot@lists.denx.de; 'Peng Fan'
>
> Cc: 'Ian Roberts' ; 'Nathan Barrett-Morrison'
> ;
> 'Jonas Karlman' ; 'Kever Yang' ;
> 'Peter Geis'
> ; 'Sean Anderson' ; 'Simon
> Glass' ;
> 'Tom Rini'
> Subject: RE: [PATCH] mmc: sdhci: introduce adma_write_desc() hook to struct
> sdhci_ops
>
>
>
> > -Original Message-
> > From: Greg Malysa
> > Sent: Tuesday, March 26, 2024 11:18 AM
> > To: u-boot@lists.denx.de; Peng Fan ; Jaehoon Chung
> >
> > Cc: Ian Roberts ; Nathan Barrett-Morrison
> > ;
> Greg
> > Malysa ; Jonas Karlman ; Kever
> > Yang > chips.com>; Peter Geis ; Sean Anderson
> > ; Simon Glass
> > ; Tom Rini
> > Subject: [PATCH] mmc: sdhci: introduce adma_write_desc() hook to struct
> > sdhci_ops
> >
> > From: Ian Roberts
> >
> > Add this hook so that it can be overridden with driver specific
> > implementations. We also let the original sdhci_adma_write_desc()
> > accept so that the function can set its new value. Then export
> > the function so that it could be reused by driver's specific
> > implementations.
> >
> > The above is a port of Linux kernel commit 54552e4948cbf
> >
> > In addition, allow drivers to allocate their own ADMA descriptor
> > tables if additional space is required.
> >
> > Finally, fix the assignment of adma_addr to fix compiler warning
> > on 64-bit platforms that still use 32-bit DMA addressing.
> >
> > Co-developed-by: Nathan Barrett-Morrison
> > Signed-off-by: Nathan Barrett-Morrison
> > Signed-off-by: Greg Malysa
> > Signed-off-by: Ian Roberts
>
> Reviewed-by: Jaehoon Chung
Some target are failed to build. (e.g, j721e_beagleboneai64_r5)
+drivers/mmc/sdhci-adma.c: In function '__sdhci_adma_write_desc':
+drivers/mmc/sdhci-adma.c:37:43: error: 'const struct sdhci_ops' has no member
named 'adma_write_desc'
+ 37 | if (host && host->ops && host->ops->adma_write_desc)
+ | ^~
+drivers/mmc/sdhci-adma.c:38:26: error: 'const struct sdhci_ops' has no member
named 'adma_write_desc'
+ 38 | host->ops->adma_write_desc(host, desc, addr, len, end);
+ | ^~
+make[3]: *** [scripts/Makefile.build:257: drivers/mmc/sdhci-adma.o] Error 1
+make[2]: *** [scripts/Makefile.build:397: drivers/mmc] Error 2
Best Regards,
Jaehoon Chung
>
> Best Regards,
> Jaehoon Chung
>
> >
> > ---
> >
> >
> > ---
> > drivers/mmc/fsl_esdhc.c | 2 +-
> > drivers/mmc/sdhci-adma.c | 41 +++-
> > drivers/mmc/sdhci.c | 8 +---
> > include/sdhci.h | 12 ++--
> > 4 files changed, 44 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> > index d50669..bd0671cc52 100644
> > --- a/drivers/mmc/fsl_esdhc.c
> > +++ b/drivers/mmc/fsl_esdhc.c
> > @@ -252,7 +252,7 @@ static void esdhc_setup_dma(struct fsl_esdhc_priv
> > *priv, struct mmc_data *data)
> > priv->adma_desc_table) {
> > debug("Using ADMA2\n");
> > /* prefer ADMA2 if it is available */
> > - sdhci_prepare_adma_table(priv->adma_desc_table, data,
> > + sdhci_prepare_adma_table(NULL, priv->adma_desc_table, data,
> > priv->dma_addr);
> >
> > adma_addr = virt_to_phys(priv->adma_desc_table);
> > diff --git a/drivers/mmc/sdhci-adma.c b/drivers/mmc/sdhci-adma.c
> > index 8213223d3f..8c38448b6a 100644
> > --- a/drivers/mmc/sdhci-adma.c
> > +++ b/drivers/mmc/sdhci-adma.c
> > @@ -9,9 +9,10 @@
> > #include
> > #include
> >
> > -static void sdhci_adma_desc(struct sdhci_adma_desc *desc,
> > - dma_addr_t addr, u16 len, bool end)
> > +void sdhci_adma_write_desc(struct sdhci_host *host, void **next_desc,
> > + dma_addr_t addr, int len, bool end)
> > {
> > + struct sdhci_adma_desc *desc = *next_desc;
> > u8 attr;
> >
> > attr = ADMA_DESC_ATTR_VALID | ADMA_DESC_TRANSFER_DATA;
> > @@ -19,17 +20,30 @@ static void sdhci_adma_desc(struct sdhci_adma_desc
> > *desc,
> > attr |= ADMA_DESC_ATTR_END;
> >
> > desc->attr = attr;
> > - desc->len = len;
> > + desc->len = len & 0x;
> > desc->reserved = 0;
> > desc->addr_lo = lower_32_bits(addr);
> > #ifdef CONFIG_DMA_ADDR_T_64BIT
> > desc->addr_hi = upper_32_bits(addr);
> > #endif
> > +
> > + *next_desc += ADMA_DESC_LEN;
> > +}
> > +
> > +static inline void __sdhci_adma_write_desc(struct sdhci_host *host,
> > + void **desc, dma_addr_t addr,
> > + int len, bool end)
> > +{
> > + if (host && host->ops && host->ops->adma_write_desc)
> > + host->ops->adma_write_desc(host, desc, addr, len, end);
> > + else
> > + sdhci_adma_write_desc(host, desc, addr, len, end);
> > }
> >
> >
Re: [PATCH v2] ARM: stm32: Initialize TAMP_SMCR BKP..PROT fields on STM32MP15xx
On 4/18/24 8:24 PM, Patrick DELAUNAY wrote:
Hi,
Hi,
[...]
@@ -136,6 +140,18 @@ static void security_init(void)
*/
writel(0x0, TAMP_CR1);
+ /*
+ * TAMP: Configure non-zero secure protection settings. This is
+ * checked by BootROM function 35ac on OTP-CLOSED device during
+ * CPU core 1 release from endless loop. If secure protection
+ * fields are zero, the core 1 is not released from endless
+ * loop on second SGI0.
+ */
+ clrsetbits_le32(TAMP_SMCR,
+ TAMP_SMCR_BKPRWDPROT | TAMP_SMCR_BKPWDPROT,
+ FIELD_PREP(TAMP_SMCR_BKPRWDPROT, 0x10) |
+ FIELD_PREP(TAMP_SMCR_BKPWDPROT, 0x10));
+
/* GPIOZ: deactivate the security */
writel(BIT(0), RCC_MP_AHB5ENSETR);
writel(0x0, GPIOZ_SECCFGR);
The recommended mapping (the mapping done in OP-TEE for OpenSTLinux) is
described in Wiki page
- 10 backup register secure
- 4 backup register secure write / non secure read
- 17 backup register Non-secure
It is done in
https://github.com/STMicroelectronics/optee_os/blob/3.19.0-stm32mp/core/arch/arm/plat-stm32mp1/main.c
with
static TEE_Result stm32_configure_tamp(void)
{
TEE_Result res __maybe_unused = TEE_SUCCESS;
struct stm32_bkpregs_conf bkpregs_conf = {
.nb_zone1_regs = 10, /* 10 registers in zone 1 */
.nb_zone2_regs = 5 /* 5 registers in zone 2 */
/* Zone3 all remaining */
};
/* Enable BKP Register protection */
if (stm32_tamp_set_secure_bkpregs(_conf))
panic();
But when you are booting with SPL U-boot, all the boot chain and the
Linux kernel
is running in secure world
So you have no reason to manage any limit for the access to backup
register,
you can allocate all the backup registers (the 32 one) to secure world
See "Figure 552. Backup registers secure protections" in reference mnauel
Protection zone 1 => x = 31 with BKPRWDPROT = 31
Protection zone 2 & 3 => empty
+ clrsetbits_le32(TAMP_SMCR,
+ TAMP_SMCR_BKPRWDPROT | TAMP_SMCR_BKPWDPROT,
+ FIELD_PREP(TAMP_SMCR_BKPRWDPROT, 0x20) |
+ FIELD_PREP(TAMP_SMCR_BKPWDPROT, 0x20));
Sorry for the delay, I need also to check on my side
But anyway your proposal is functional,
So with or without the previous remark
Thank you for the detailed explanation and for checking this.
V3 is coming now.
[PATCH v3] ARM: stm32: Initialize TAMP_SMCR BKP..PROT fields on STM32MP15xx
In case of an OTP-CLOSED STM32MP15xx system, the CPU core 1 cannot be released from endless loop in BootROM only by populating TAMP BKPxR 4 and 5 with magic and branch address and sending SGI0 interrupt from core 0 to core 1 twice. TAMP_SMCR BKP..PROT fields must be initialized as well to release the core 1 from endless loop during the second SGI0 handling on core 1. Initialize TAMP_SMCR to protect the first 32 backup registers, the ones which contain the core 1 magic, branch address and boot information. This requirement seems to be undocumented, therefore it was necessary to trace and analyze the STM32MP15xx BootROM using OpenOCD and objdump. Ultimately, it turns out that a certain BootROM function reads out the TAMP_SMCR register and tests whether the BKP..PROT fields are non-zero. If they are zero, the BootROM code again waits for SGI0 using WFI, else the execution moves forward until it reaches handoff to the TAMP BKPxR 5 branch address. This fixes CPU core 1 release using U-Boot PSCI implementation on an OTP-CLOSED system, i.e. system with fuse 0 bit 6 set. Reviewed-by: Patrick Delaunay Signed-off-by: Marek Vasut --- Cc: Igor Opaniuk Cc: Patrice Chotard Cc: Patrick Delaunay Cc: Simon Glass Cc: Tom Rini Cc: u-b...@dh-electronics.com Cc: uboot-st...@st-md-mailman.stormreply.com --- V2: Fix up the BKPRWD/BKPWD mask typo V3: - Update the allocation to 0x20/0x20 - Update commit message - Add RB from Patrick --- arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c | 16 1 file changed, 16 insertions(+) diff --git a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c index dd99150fbc2..d75ec99d6a1 100644 --- a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c +++ b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c @@ -14,6 +14,7 @@ #include #include #include +#include /* RCC register */ #define RCC_TZCR (STM32_RCC_BASE + 0x00) @@ -41,6 +42,9 @@ #define TZC_REGION_ID_ACCESS0 (STM32_TZC_BASE + 0x114) #define TAMP_CR1 (STM32_TAMP_BASE + 0x00) +#define TAMP_SMCR (STM32_TAMP_BASE + 0x20) +#define TAMP_SMCR_BKPRWDPROT GENMASK(7, 0) +#define TAMP_SMCR_BKPWDPROTGENMASK(23, 16) #define PWR_CR1(STM32_PWR_BASE + 0x00) #define PWR_MCUCR (STM32_PWR_BASE + 0x14) @@ -136,6 +140,18 @@ static void security_init(void) */ writel(0x0, TAMP_CR1); + /* +* TAMP: Configure non-zero secure protection settings. This is +* checked by BootROM function 35ac on OTP-CLOSED device during +* CPU core 1 release from endless loop. If secure protection +* fields are zero, the core 1 is not released from endless +* loop on second SGI0. +*/ + clrsetbits_le32(TAMP_SMCR, + TAMP_SMCR_BKPRWDPROT | TAMP_SMCR_BKPWDPROT, + FIELD_PREP(TAMP_SMCR_BKPRWDPROT, 0x20) | + FIELD_PREP(TAMP_SMCR_BKPWDPROT, 0x20)); + /* GPIOZ: deactivate the security */ writel(BIT(0), RCC_MP_AHB5ENSETR); writel(0x0, GPIOZ_SECCFGR); -- 2.43.0
Re: [PATCH v2 01/23] clk: rockchip: rk356x: Add CLK_USB3OTGx_REF support
On 4/13/24 14:13, Jonas Karlman wrote: The CLK_USB3OTGx_REF clocks is used as reference clock for USB3 block. Add simple support to get rate of CLK_USB3OTGx_REF clocks to fix reference clock period configuration. Signed-off-by: Jonas Karlman --- v2: No change --- drivers/clk/rockchip/clk_rk3568.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/clk/rockchip/clk_rk3568.c b/drivers/clk/rockchip/clk_rk3568.c index 57ef27dda893..999f48ea4b4e 100644 --- a/drivers/clk/rockchip/clk_rk3568.c +++ b/drivers/clk/rockchip/clk_rk3568.c @@ -2417,6 +2417,8 @@ static ulong rk3568_clk_get_rate(struct clk *clk) case BCLK_EMMC: rate = rk3568_emmc_get_bclk(priv); break; + case CLK_USB3OTG0_REF: + case CLK_USB3OTG1_REF: case TCLK_EMMC: rate = OSC_HZ; break; @@ -2596,6 +2598,8 @@ static ulong rk3568_clk_set_rate(struct clk *clk, ulong rate) case BCLK_EMMC: ret = rk3568_emmc_set_bclk(priv, rate); break; + case CLK_USB3OTG0_REF: + case CLK_USB3OTG1_REF: case TCLK_EMMC: ret = OSC_HZ; break; Acked-by: Sean Anderson
Re: [PATCH v2 02/23] clk: rockchip: rk3588: Add REF_CLK_USB3OTGx support
On 4/13/24 14:13, Jonas Karlman wrote: The REF_CLK_USB3OTGx clocks is used as reference clock for USB3 block. Add simple support to get rate of REF_CLK_USB3OTGx clocks to fix reference clock period configuration. Signed-off-by: Jonas Karlman Reviewed-by: Quentin Schulz --- v2: Collect r-b tag --- drivers/clk/rockchip/clk_rk3588.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/clk/rockchip/clk_rk3588.c b/drivers/clk/rockchip/clk_rk3588.c index 8f33843179b0..4c611a390499 100644 --- a/drivers/clk/rockchip/clk_rk3588.c +++ b/drivers/clk/rockchip/clk_rk3588.c @@ -1569,6 +1569,9 @@ static ulong rk3588_clk_get_rate(struct clk *clk) case DCLK_DECOM: rate = rk3588_mmc_get_clk(priv, clk->id); break; + case REF_CLK_USB3OTG0: + case REF_CLK_USB3OTG1: + case REF_CLK_USB3OTG2: case TMCLK_EMMC: case TCLK_WDT0: rate = OSC_HZ; @@ -1734,6 +1737,9 @@ static ulong rk3588_clk_set_rate(struct clk *clk, ulong rate) case DCLK_DECOM: ret = rk3588_mmc_set_clk(priv, clk->id, rate); break; + case REF_CLK_USB3OTG0: + case REF_CLK_USB3OTG1: + case REF_CLK_USB3OTG2: case TMCLK_EMMC: case TCLK_WDT0: ret = OSC_HZ; Acked-by: Sean Anderson
[PATCH 3/3] patman: Add a tag for when a patch gets added to a series
When a patch is added to a series after the initial version, there are no
changes to note except that it is new. This is typically done to suppress
the "(no changes in vN)" message. It's also nice to add a change to the
cover letter so reviewers know there is an additional patch. Add a tag to
automate this process a bit.
There are two nits with the current approach:
- It favors '-' as a bullet point, but some people may prefer '*' (or
something else)
- Tags (e.g. 'patman: ' in 'patman: foo bar') are not stripped. They are
probably just noise in most series, but they may be useful for treewide
series to distinguish 'gpio: frobnicate' from 'reset: frobnicate', so
I've left them in.
Suggestions for the above appreciated.
Suggested-by: Douglas Anderson
Signed-off-by: Sean Anderson
---
tools/patman/func_test.py | 2 ++
tools/patman/patchstream.py | 5 +
tools/patman/patman.rst | 13 +
...t-cast-for-sandbox-in-fdtdec_setup_mem_siz.patch | 1 +
tools/patman/test/test01.txt| 1 +
5 files changed, 22 insertions(+)
diff --git a/tools/patman/func_test.py b/tools/patman/func_test.py
index 3b4c9448882..af6c025a441 100644
--- a/tools/patman/func_test.py
+++ b/tools/patman/func_test.py
@@ -293,6 +293,7 @@ Changes in v4:
change
- Some changes
- Some notes for the cover letter
+- fdt: Correct cast for sandbox in fdtdec_setup_mem_size_base()
Simon Glass (2):
pci: Correct cast for sandbox
@@ -342,6 +343,7 @@ Changes in v4:
- Multi
line
change
+- New
- Some changes
Changes in v2:
diff --git a/tools/patman/patchstream.py b/tools/patman/patchstream.py
index ec1ca874fb2..a09ae9c7371 100644
--- a/tools/patman/patchstream.py
+++ b/tools/patman/patchstream.py
@@ -477,6 +477,11 @@ class PatchStream:
self.change_version = self._parse_version(value, line)
elif name == 'cc':
self.commit.add_cc(value.split(','))
+elif name == 'added-in':
+version = self._parse_version(value, line)
+self.commit.add_change(version, '- New')
+self.series.AddChange(version, None, '- %s' %
+ self.commit.subject)
else:
self._add_warn('Line %d: Ignoring Commit-%s' %
(self.linenum, name))
diff --git a/tools/patman/patman.rst b/tools/patman/patman.rst
index 9971fa8c0fd..63b95a6b161 100644
--- a/tools/patman/patman.rst
+++ b/tools/patman/patman.rst
@@ -350,6 +350,19 @@ Cover-changes: n
- This line will only appear in the cover letter
+Commit-added-in: n
+Add a change noting the version this commit was added in. This is
+equivalent to::
+
+Commit-changes: n
+- New
+
+Cover-changes: n
+-
+
+It is a convenient shorthand for suppressing the '(no changes in vN)'
+message.
+
Patch-cc / Commit-cc: Their Name
This copies a single patch to another email address. Note that the
Cc: used by git send-email is ignored by patman, but will be
diff --git
a/tools/patman/test/0002-fdt-Correct-cast-for-sandbox-in-fdtdec_setup_mem_siz.patch
b/tools/patman/test/0002-fdt-Correct-cast-for-sandbox-in-fdtdec_setup_mem_siz.patch
index 55a0d6756aa..48ea1793b47 100644
---
a/tools/patman/test/0002-fdt-Correct-cast-for-sandbox-in-fdtdec_setup_mem_siz.patch
+++
b/tools/patman/test/0002-fdt-Correct-cast-for-sandbox-in-fdtdec_setup_mem_siz.patch
@@ -23,6 +23,7 @@ Series-version: 3
Patch-cc: fred
Commit-cc: joe
Series-process-log: sort, uniq
+Commit-added-in: 4
Series-changes: 4
- Some changes
- Multi
diff --git a/tools/patman/test/test01.txt b/tools/patman/test/test01.txt
index 271d9bf043f..b2d73c5972c 100644
--- a/tools/patman/test/test01.txt
+++ b/tools/patman/test/test01.txt
@@ -51,6 +51,7 @@ Date: Sat Apr 15 15:39:08 2017 -0600
Patch-cc: fred
Commit-cc: joe
Series-process-log: sort, uniq
+Commit-added-in: 4
Series-changes: 4
- Some changes
- Multi
--
2.37.1
[PATCH 2/3] patman: Add Commit-cc as an alias for Patch-cc
Most tags referring to commits (or patches) are named Commit-something. The
exception is Patch-cc. Add a Commit-cc alias so we can use whichever one is
convenient.
Signed-off-by: Sean Anderson
---
tools/patman/func_test.py| 5 -
tools/patman/patchstream.py | 2 ++
tools/patman/patman.rst | 2 +-
...dt-Correct-cast-for-sandbox-in-fdtdec_setup_mem_siz.patch | 1 +
tools/patman/test/test01.txt | 1 +
5 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/tools/patman/func_test.py b/tools/patman/func_test.py
index 9c016fb5e9a..3b4c9448882 100644
--- a/tools/patman/func_test.py
+++ b/tools/patman/func_test.py
@@ -211,6 +211,7 @@ class TestFunctional(unittest.TestCase):
'u-boot': ['u-boot@lists.denx.de'],
'simon': [self.leb],
'fred': [self.fred],
+'joe': [self.joe],
}
text = self._get_text('test01.txt')
@@ -259,6 +260,7 @@ class TestFunctional(unittest.TestCase):
self.assertEqual('Postfix:\t some-branch', next(lines))
self.assertEqual('Cover: 4 lines', next(lines))
self.assertEqual(' Cc: %s' % self.fred, next(lines))
+self.assertEqual(' Cc: %s' % self.joe, next(lines))
self.assertEqual(' Cc: %s' % self.leb,
next(lines))
self.assertEqual(' Cc: %s' % mel, next(lines))
@@ -272,7 +274,8 @@ class TestFunctional(unittest.TestCase):
self.assertEqual(('%s %s\0%s' % (args[0], rick, stefan)), cc_lines[0])
self.assertEqual(
-'%s %s\0%s\0%s\0%s' % (args[1], self.fred, self.leb, rick, stefan),
+'%s %s\0%s\0%s\0%s\0%s' % (args[1], self.fred, self.joe, self.leb,
+ rick, stefan),
cc_lines[1])
expected = '''
diff --git a/tools/patman/patchstream.py b/tools/patman/patchstream.py
index e2e2a83e677..ec1ca874fb2 100644
--- a/tools/patman/patchstream.py
+++ b/tools/patman/patchstream.py
@@ -475,6 +475,8 @@ class PatchStream:
elif name == 'changes':
self.in_change = 'Commit'
self.change_version = self._parse_version(value, line)
+elif name == 'cc':
+self.commit.add_cc(value.split(','))
else:
self._add_warn('Line %d: Ignoring Commit-%s' %
(self.linenum, name))
diff --git a/tools/patman/patman.rst b/tools/patman/patman.rst
index f4588c00fc1..9971fa8c0fd 100644
--- a/tools/patman/patman.rst
+++ b/tools/patman/patman.rst
@@ -350,7 +350,7 @@ Cover-changes: n
- This line will only appear in the cover letter
-Patch-cc: Their Name
+Patch-cc / Commit-cc: Their Name
This copies a single patch to another email address. Note that the
Cc: used by git send-email is ignored by patman, but will be
interpreted by git send-email if you use it.
diff --git
a/tools/patman/test/0002-fdt-Correct-cast-for-sandbox-in-fdtdec_setup_mem_siz.patch
b/tools/patman/test/0002-fdt-Correct-cast-for-sandbox-in-fdtdec_setup_mem_siz.patch
index 56278a6ce9b..55a0d6756aa 100644
---
a/tools/patman/test/0002-fdt-Correct-cast-for-sandbox-in-fdtdec_setup_mem_siz.patch
+++
b/tools/patman/test/0002-fdt-Correct-cast-for-sandbox-in-fdtdec_setup_mem_siz.patch
@@ -21,6 +21,7 @@ Series-cc: Stefan Brüns
Cover-letter-cc: Lord Mëlchett
Series-version: 3
Patch-cc: fred
+Commit-cc: joe
Series-process-log: sort, uniq
Series-changes: 4
- Some changes
diff --git a/tools/patman/test/test01.txt b/tools/patman/test/test01.txt
index fc3066e50b4..271d9bf043f 100644
--- a/tools/patman/test/test01.txt
+++ b/tools/patman/test/test01.txt
@@ -49,6 +49,7 @@ Date: Sat Apr 15 15:39:08 2017 -0600
Cover-letter-cc: Lord Mëlchett
Series-version: 3
Patch-cc: fred
+Commit-cc: joe
Series-process-log: sort, uniq
Series-changes: 4
- Some changes
--
2.37.1
[PATCH 1/3] patman: Fix tests if add_maintainers is set to False
If add_maintainers is set to False in the user's ~/.patman config, it will
cause the custom_get_maintainer_script to fail since that test expects
maintainers to be added. Set add_maintainer to True in the .patman config
to prevent this.
Fixes: 8c042fb7f9f ("patman: add '--get-maintainer-script' argument")
Signed-off-by: Sean Anderson
---
tools/patman/func_test.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/patman/func_test.py b/tools/patman/func_test.py
index e3918497cf4..9c016fb5e9a 100644
--- a/tools/patman/func_test.py
+++ b/tools/patman/func_test.py
@@ -540,7 +540,8 @@ complicated as possible''')
with open('.patman', 'w', buffering=1) as f:
f.write('[settings]\n'
'get_maintainer_script: dummy-script.sh\n'
-'check_patch: False\n')
+'check_patch: False\n'
+'add_maintainers: True\n')
with open('dummy-script.sh', 'w', buffering=1) as f:
f.write('#!/usr/bin/env python\n'
'print("he...@there.com")\n')
--
2.37.1
[PATCH 0/3] patman: A fix and some new tags
This series has a fix along with a couple of convenient tags. Sean Anderson (3): patman: Fix tests if add_maintainers is set to False patman: Add Commit-cc as an alias for Patch-cc patman: Add a tag for when a patch gets added to a series tools/patman/func_test.py | 10 -- tools/patman/patchstream.py | 7 +++ tools/patman/patman.rst | 15 ++- ...cast-for-sandbox-in-fdtdec_setup_mem_siz.patch | 2 ++ tools/patman/test/test01.txt | 2 ++ 5 files changed, 33 insertions(+), 3 deletions(-) -- 2.37.1
Re: [PATCH] env: mmc: print MMC device being read
On Mon, 15 Apr 2024 14:43:57 +0200, Quentin Schulz wrote: > This prints the MMC device being read similar to how we print the MMC > device we write to when e.g. calling saveenv. > > One of the side effects is that the boot log now shows from which MMC > device the env was loaded: > > Loading Environment from MMC... Reading from MMC(1)... OK > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH] Kconfig: Remove all default n options
On Mon, 15 Apr 2024 10:20:05 +0200, Michal Simek wrote:
> default n doesn't need to be specified. It is default option anyway.
> Similar changes have been done by commit 18370f14975c ("Kconfig: Remove all
> default n/no options").
>
>
Applied to u-boot/master, thanks!
--
Tom
Re: [PATCH] boot: fdt: Turn all addresses and sizes into u64
On Sun, 14 Apr 2024 20:37:20 +0200, Marek Vasut wrote: > In case of systems where DRAM bank ends at the edge of 32bit boundary, > start + size calculations would overflow. This happens on STM32MP15xx > with 1 DRAM bank starting at 0xc000 and 1 GiB of DRAM. This is a > usual 32bit system DRAM size overflow, fix it by doing all DRAM size > and offset calculations using u64 types. This also covers a case where > a 32bit PAE system might be able to address up to 36bits of DRAM. > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH] fs/erofs: add DEFLATE algorithm support
On Sun, 14 Apr 2024 23:04:14 +0800, Jianan Huang wrote: > This patch adds DEFLATE compression algorithm support. It's a good choice > to trade off between compression ratios and performance compared to LZ4. > Alternatively, DEFLATE could be used for some specific files since EROFS > supports multiple compression algorithms in one image. > > Applied to u-boot/master, thanks! -- Tom
Re: [PATCHv2] net: add support to parse the NIS domain for the dhcp options
On Fri, 12 Apr 2024 13:45:33 -0700, Charles Hardin wrote: > There is code in the bootp parsing for NIS domain and add the > same support for the dhcp options as well. This allows the same > usage of the data when the dhcp command is used in the boot > command. > > Applied to u-boot/master, thanks! -- Tom
Re: [PATCH] input: button_kbd: gracefully handle buttons that fail probe
On Thu, 11 Apr 2024 19:52:37 +0200, Caleb Connolly wrote: > If a button device fails to probe, it will still be added to the uclass > device list, and therefore will still be iterated over in > button_read_keys() resulting in a UAF on the buttons private data. > > Resolve this by unbinding button devices that aren't active after > probing, and print a warning so it's clear that the button is broken. > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH 1/1] reboot-mode: must depend on CONFIG_DM_RTC
On Tue, 09 Apr 2024 20:44:22 +0200, Heinrich Schuchardt wrote: > Reading the boot mode from RTC memory requires a real time clock. > Add the missing Kconfig dependency. > > Applied to u-boot/master, thanks! -- Tom
Re: [PATCH] configs: am335x_guardian: store boot count in AM3352 RTC block
On Mon, 08 Apr 2024 11:31:19 +0530, gireesh.hirem...@in.bosch.com wrote: > store bootcount in RTC block scratch register > > Applied to u-boot/master, thanks! -- Tom
Re: [PATCH] ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM
On Thu, Apr 18, 2024 at 9:47 PM Fabio Estevam wrote: > I don't get the error if I pass CONFIG_FSL_CAAM_JR_NTZ_ACCESS=y: Ops, sorry. This is not correct. CONFIG_DM_RNG was unselected. Please discard.
Re: [PATCH] ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM
On Thu, Apr 18, 2024 at 4:05 PM Fabio Estevam wrote: > I tested with mainline TFA 2.10 and also with NXP 2.8. The error > happens in both cases. I don't get the error if I pass CONFIG_FSL_CAAM_JR_NTZ_ACCESS=y: U-Boot SPL 2024.04-00793-g3434b88d2c2f-dirty (Apr 18 2024 - 21:46:06 -0300) No pmic SEC0: RNG instantiated WDT: Started watchdog@3028 with servicing every 1000ms (60s timeout) Trying to boot from MMC1 NOTICE: Do not release JR0 to NS as it can be used by HAB NOTICE: BL31: v2.10.3(release):lts-v2.10.3 NOTICE: BL31: Built : 21:04:50, Apr 15 2024
Re: [PATCH v2 5/5] arm: apple: Do not list bootflows on boot
On Thu, Apr 18, 2024 at 3:00 PM Janne Grunau via B4 Relay wrote: > > From: Janne Grunau > > The bootflow list is only seen briefly and is probably more confusing > than helpful. > > Signed-off-by: Janne Grunau > --- > configs/apple_m1_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/apple_m1_defconfig b/configs/apple_m1_defconfig > index c30aec7c55..4eac1a9e2d 100644 > --- a/configs/apple_m1_defconfig > +++ b/configs/apple_m1_defconfig > @@ -8,6 +8,7 @@ CONFIG_SYS_CBSIZE=256 > CONFIG_SYS_PBSIZE=276 > # CONFIG_DISPLAY_CPUINFO is not set > CONFIG_DISPLAY_BOARDINFO_LATE=y > +CONFIG_BOOTCOMMAND="bootflow scan -b" > CONFIG_BOARD_LATE_INIT=y > CONFIG_CMD_SELECT_FONT=y > # CONFIG_NET is not set > > -- > 2.44.0 > Reviewed-by: Neal Gompa -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [PATCH v2 4/5] arm: apple: Switch to standard boot
On Thu, Apr 18, 2024 at 3:00 PM Janne Grunau via B4 Relay wrote: > > From: Janne Grunau > > Use standard boot instead of the distro boot scripts. Use > BOOTSTD_FULL instead of BOOTSTD_DEFAULTS for easier interactive use. > > Signed-off-by: Janne Grunau > --- > arch/arm/Kconfig| 2 +- > include/configs/apple.h | 20 ++-- > 2 files changed, 3 insertions(+), 19 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 01d6556c42..9b83b2e6f8 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1034,7 +1034,7 @@ config ARCH_APPLE > select USB > imply CMD_DM > imply CMD_GPT > - imply DISTRO_DEFAULTS > + imply BOOTSTD_FULL > imply OF_HAS_PRIOR_STAGE > > config ARCH_OWL > diff --git a/include/configs/apple.h b/include/configs/apple.h > index a70440b3ad..1e08b11448 100644 > --- a/include/configs/apple.h > +++ b/include/configs/apple.h > @@ -9,26 +9,10 @@ > "stdout=vidconsole,serial\0" \ > "stderr=vidconsole,serial\0" > > -#if IS_ENABLED(CONFIG_CMD_NVME) > - #define BOOT_TARGET_NVME(func) func(NVME, nvme, 0) > -#else > - #define BOOT_TARGET_NVME(func) > -#endif > - > -#if IS_ENABLED(CONFIG_CMD_USB) > - #define BOOT_TARGET_USB(func) func(USB, usb, 0) > -#else > - #define BOOT_TARGET_USB(func) > -#endif > - > -#define BOOT_TARGET_DEVICES(func) \ > - BOOT_TARGET_NVME(func) \ > - BOOT_TARGET_USB(func) > - > -#include > +#define BOOT_TARGETS "nvme usb" > > #define CFG_EXTRA_ENV_SETTINGS \ > ENV_DEVICE_SETTINGS \ > - BOOTENV > + "boot_targets=" BOOT_TARGETS "\0" > > #endif > > -- > 2.44.0 > Reviewed-by: Neal Gompa -- 真実はいつも一つ！/ Always, there's only one truth!
Re: [PATCH 6/9] mach-snapdragon: implement ft_board_setup() for USB role selection
On 18/04/2024 18:25, Caleb Connolly wrote:
> Some Qualcomm boards have only one USB controller which is muxed between
> the type-c port and an internal USB hub for type-A and ethernet. We
> modify the DT for these to force them to host mode in U-Boot. However in
> Linux DRD role switching is supported (required, even). Use
> ft_board_setup() to adjust the dr_mode property for these boards.
>
> While we're here, define pr_fmt for this file so we can more easily
> identify log messages.
>
> Signed-off-by: Caleb Connolly
> ---
> arch/arm/mach-snapdragon/of_fixup.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/mach-snapdragon/of_fixup.c
> b/arch/arm/mach-snapdragon/of_fixup.c
> index 3f7ac227bd09..55368dd43b66 100644
> --- a/arch/arm/mach-snapdragon/of_fixup.c
> +++ b/arch/arm/mach-snapdragon/of_fixup.c
> @@ -16,8 +16,10 @@
> * Copyright (c) 2024 Linaro Ltd.
> * Author: Caleb Connolly
> */
>
> +#define pr_fmt(fmt) "of_fixup: " fmt
> +
> #include
> #include
> #include
> #include
> @@ -152,4 +154,22 @@ void qcom_of_fixup_nodes(void)
> {
> time_call(fixup_usb_nodes);
> time_call(fixup_power_domains);
> }
> +
> +int ft_board_setup(void *blob, struct bd_info __maybe_unused *bd)
> +{
> + struct fdt_header *fdt = blob;
> + int node;
> +
> + /* We only want to do this fix-up for the RB1 board, quick return for
> all others */
> + if (!fdt_node_check_compatible(fdt, 0, "qcom,qrb4210-rb2"))
This if block is accidentally inverted...
> + return 0;
> +
> + fdt_for_each_node_by_compatible(node, blob, 0, "snps,dwc3") {
> + log_debug("%s: Setting 'dr_mode' to OTG\n", fdt_get_name(blob,
> node, NULL));
> + fdt_setprop_string(fdt, node, "dr_mode", "otg");
> + break;
> + }
> +
> + return 0;
> +}
>
--
// Caleb (they/them)
Re: [PATCH] arm:suniv:complete the serial port configuration of Suniv
On Wed, 13 Mar 2024 13:33:23 +0800
lhdj...@126.com wrote:
Hi,
> From: lhdjply
>
> 111
There should be a proper commit message here, explaining *why* this
patch is needed.
So what does this patch or which problem does it solve?
Please note that I consider those "SUNxx_GPy_UARTz" symbols nonsense,
since they do not carry real information. I thought about replacing all
those pinmux defines with something like SUNXI_PINMUX_x, defined to
x, so say: "#define SUNXI_PINMUX_5 5".
Does that sound better to you?
Cheers,
Andre
>
> Signed-off-by: lhdjply
> ---
> arch/arm/mach-sunxi/board.c | 4 ++--
> include/sunxi_gpio.h| 6 ++
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> index f4dbb2a740..b91c9629e4 100644
> --- a/arch/arm/mach-sunxi/board.c
> +++ b/arch/arm/mach-sunxi/board.c
> @@ -151,8 +151,8 @@ static int gpio_init(void)
> sunxi_gpio_set_cfgpin(SUNXI_GPE(3), 6);
> sunxi_gpio_set_pull(SUNXI_GPE(3), SUNXI_GPIO_PULL_UP);
> #elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUNIV)
> - sunxi_gpio_set_cfgpin(SUNXI_GPA(2), SUNIV_GPE_UART0);
> - sunxi_gpio_set_cfgpin(SUNXI_GPA(3), SUNIV_GPE_UART0);
> + sunxi_gpio_set_cfgpin(SUNXI_GPA(2), SUNIV_GPA_UART1);
> + sunxi_gpio_set_cfgpin(SUNXI_GPA(3), SUNIV_GPA_UART1);
> sunxi_gpio_set_pull(SUNXI_GPA(3), SUNXI_GPIO_PULL_UP);
> #elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUN5I)
> sunxi_gpio_set_cfgpin(SUNXI_GPG(3), SUN5I_GPG_UART1);
> diff --git a/include/sunxi_gpio.h b/include/sunxi_gpio.h
> index db3742c039..51258e3dd9 100644
> --- a/include/sunxi_gpio.h
> +++ b/include/sunxi_gpio.h
> @@ -108,6 +108,8 @@ enum sunxi_gpio_number {
> #define SUN8I_H3_GPA_UART0 2
> #define SUN8I_H3_GPA_UART2 2
>
> +#define SUNIV_GPA_UART1 5
> +
> #define SUN4I_GPB_PWM2
> #define SUN4I_GPB_TWI0 2
> #define SUN4I_GPB_TWI1 2
> @@ -130,12 +132,16 @@ enum sunxi_gpio_number {
>
> #define SUNXI_GPD_LCD0 2
> #define SUNXI_GPD_LVDS0 3
> +#define SUNIV_GPD_UART1 3
> +#define SUNIV_GPD_UART2 3
>
> #define SUNIV_GPE_UART0 5
> +#define SUNIV_GPE_UART2 3
>
> #define SUNXI_GPF_SDC0 2
> #define SUNXI_GPF_UART0 4
> #define SUN8I_GPF_UART0 3
> +#define SUNIV_GPF_UART0 3
>
> #define SUN4I_GPG_SDC1 4
> #define SUN5I_GPG_SDC1 2
[PATCH 2/2] configs: qcom_defconfig: enable GENI I2C Driver
Enable the GENI I2C driver in the default Qualcomm defconfig. Signed-off-by: Neil Armstrong --- configs/qcom_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig index 1abb57345ff..8d440b23625 100644 --- a/configs/qcom_defconfig +++ b/configs/qcom_defconfig @@ -41,6 +41,7 @@ CONFIG_MSM_GPIO=y CONFIG_QCOM_PMIC_GPIO=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_QUP=y +CONFIG_SYS_I2C_GENI=y CONFIG_I2C_MUX=y CONFIG_DM_KEYBOARD=y CONFIG_BUTTON_KEYBOARD=y -- 2.34.1
[PATCH 1/2] i2c: Add support for Qualcomm Generic Interface (GENI) I2C controller
Add Support for the Qualcomm Generic Interface (GENI) I2C interface
found on newer Qualcomm SoCs.
The Generic Interface (GENI) is a firmware based Qualcomm Universal
Peripherals (QUP) Serial Engine (SE) Wrapper which can support multiple
bus protocols depending on the firmware type loaded at early boot time
based on system configuration.
It also supports the "I2C Master Hub" which is a single function Wrapper
that only FIFO mode I2C.
It replaces the fixed-function QUP Wrapper found on older SoCs.
The geni-se.h containing the generic GENI Serial Engine registers defines
is imported from Linux.
Only FIFO mode is implemented, nor SE DMA nor GPI DMA is implemented.
Signed-off-by: Neil Armstrong
---
drivers/i2c/Kconfig| 10 +
drivers/i2c/Makefile | 1 +
drivers/i2c/geni_i2c.c | 576 +
include/soc/qcom/geni-se.h | 265 +
4 files changed, 852 insertions(+)
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 59c635af80b..34b02114dc6 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -638,6 +638,16 @@ config SYS_I2C_QUP
Technical Reference Manual, chapter "6.1 Qualcomm Universal
Peripherals Engine (QUP)".
+config SYS_I2C_GENI
+ bool "Qualcomm Generic Interface (GENI) I2C controller"
+ depends on ARCH_SNAPDRAGON
+ help
+ Support for the Qualcomm Generic Interface (GENI) I2C interface.
+ The Generic Interface (GENI) is a firmware based Qualcomm Universal
+ Peripherals (QUP) Serial Engine (SE) Wrapper which can support
multiple
+ bus protocols depending on the firmware type loaded at early boot time
+ based on system configuration.
+
config SYS_I2C_S3C24X0
bool "Samsung I2C driver"
depends on (ARCH_EXYNOS4 || ARCH_EXYNOS5) && DM_I2C
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 692f63bafd0..00b90523c62 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_SYS_I2C_DAVINCI) += davinci_i2c.o
obj-$(CONFIG_SYS_I2C_DW) += designware_i2c.o
obj-$(CONFIG_SYS_I2C_DW_PCI) += designware_i2c_pci.o
obj-$(CONFIG_SYS_I2C_FSL) += fsl_i2c.o
+obj-$(CONFIG_SYS_I2C_GENI) += geni_i2c.o
obj-$(CONFIG_SYS_I2C_IHS) += ihs_i2c.o
obj-$(CONFIG_SYS_I2C_INTEL) += intel_i2c.o
obj-$(CONFIG_SYS_I2C_IMX_LPI2C) += imx_lpi2c.o
diff --git a/drivers/i2c/geni_i2c.c b/drivers/i2c/geni_i2c.c
new file mode 100644
index 000..8c3ed3bef89
--- /dev/null
+++ b/drivers/i2c/geni_i2c.c
@@ -0,0 +1,576 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2024, Linaro Limited
+ * Author: Neil Armstrong
+ *
+ * Based on Linux driver: drivers/i2c/busses/i2c-qcom-geni.c
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SE_I2C_TX_TRANS_LEN0x26c
+#define SE_I2C_RX_TRANS_LEN0x270
+#define SE_I2C_SCL_COUNTERS0x278
+
+#define SE_I2C_ERR (M_CMD_OVERRUN_EN | M_ILLEGAL_CMD_EN | M_CMD_FAILURE_EN |\
+ M_GP_IRQ_1_EN | M_GP_IRQ_3_EN | M_GP_IRQ_4_EN)
+#define SE_I2C_ABORT BIT(1)
+
+/* M_CMD OP codes for I2C */
+#define I2C_WRITE 0x1
+#define I2C_READ 0x2
+#define I2C_WRITE_READ 0x3
+#define I2C_ADDR_ONLY 0x4
+#define I2C_BUS_CLEAR 0x6
+#define I2C_STOP_ON_BUS0x7
+/* M_CMD params for I2C */
+#define PRE_CMD_DELAY BIT(0)
+#define TIMESTAMP_BEFORE BIT(1)
+#define STOP_STRETCH BIT(2)
+#define TIMESTAMP_AFTERBIT(3)
+#define POST_COMMAND_DELAY BIT(4)
+#define IGNORE_ADD_NACKBIT(6)
+#define READ_FINISHED_WITH_ACK BIT(7)
+#define BYPASS_ADDR_PHASE BIT(8)
+#define SLV_ADDR_MSK GENMASK(15, 9)
+#define SLV_ADDR_SHFT 9
+/* I2C SCL COUNTER fields */
+#define HIGH_COUNTER_MSK GENMASK(29, 20)
+#define HIGH_COUNTER_SHFT 20
+#define LOW_COUNTER_MSKGENMASK(19, 10)
+#define LOW_COUNTER_SHFT 10
+#define CYCLE_COUNTER_MSK GENMASK(9, 0)
+
+#define I2C_PACK_TXBIT(0)
+#define I2C_PACK_RXBIT(1)
+
+#define PACKING_BYTES_PW 4
+
+#define GENI_I2C_IS_MASTER_HUB BIT(0)
+
+#define I2C_TIMEOUT_MS 100
+
+struct geni_i2c_clk_fld {
+ u32 clk_freq_out;
+ u8 clk_div;
+ u8 t_high_cnt;
+ u8 t_low_cnt;
+ u8 t_cycle_cnt;
+};
+
+struct geni_i2c_priv {
+ fdt_addr_t wrapper;
+ phys_addr_t base;
+ struct clk core;
+ struct clk se;
+ u32 tx_wm;
+ bool is_master_hub;
+ const struct geni_i2c_clk_fld *clk_fld;
+};
+
+/*
+ * Hardware uses the underlying formula to calculate time periods of
+ * SCL clock cycle. Firmware uses some additional cycles excluded from
[PATCH 0/2] i2c: Add support for Qualcomm Generic Interface (GENI) I2C controller
Add Support for the Qualcomm Generic Interface (GENI) I2C interface found on newer Qualcomm SoCs. The Generic Interface (GENI) is a firmware based Qualcomm Universal Peripherals (QUP) Serial Engine (SE) Wrapper which can support multiple bus protocols depending on the firmware type loaded at early boot time based on system configuration. It also supports the "I2C Master Hub" which is a single function Wrapper that only FIFO mode I2C. It replaces the fixed-function QUP Wrapper found on older SoCs. The geni-se.h containing the generic GENI Serial Engine registers defines is imported from Linux. Only FIFO mode is implemented, nor SE DMA nor GPI DMA is implemented. Finally enable the driver in the default Qualcomm defconfig. Signed-off-by: Neil Armstrong --- Neil Armstrong (2): i2c: Add support for Qualcomm Generic Interface (GENI) I2C controller configs: qcom_defconfig: enable GENI I2C Driver configs/qcom_defconfig | 1 + drivers/i2c/Kconfig| 10 + drivers/i2c/Makefile | 1 + drivers/i2c/geni_i2c.c | 576 + include/soc/qcom/geni-se.h | 265 + 5 files changed, 853 insertions(+) --- base-commit: b2511143fba4c0631446c968fb4c0d962b01d850 change-id: 20240419-topic-sm8x50-i2c-b51e576d5f57 Best regards, -- Neil Armstrong
Re: [PATCH] drivers: pinctrl-sunxi: add suniv spi1 function
On Fri, 9 Jun 2023 13:37:16 +
路辉 wrote:
Hi,
> From 570b40e19de75511d9ce066e1a28333ada04baf2 Mon Sep 17 00:00:00 2001
> From: Lu Hui
> Date: Mon, 29 May 2023 22:26:25 +0800
> Subject: [PATCH] drivers: pinctrl-sunxi: add suniv spi1 function
There should be a commit message, explaining *why* this is needed.
So which device on which board do you use in U-Boot that requires SPI1?
Also you need a "Signed-off-by:" line with your real name and email
address.
Cheers,
Andre
> ---
> drivers/pinctrl/sunxi/pinctrl-sunxi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> index e510218090..c448e40ab0 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> @@ -240,6 +240,7 @@ static const struct sunxi_pinctrl_function
> suniv_f1c100s_pinctrl_functions[] = {
> { "mmc0",2 },/* PF0-PF5 */
> { "mmc1",3 },/* PC0-PC2 */
> { "spi0",2 },/* PC0-PC3 */
> +{ "spi1",6 },/* PA0-PA3 */
> #if IS_ENABLED(CONFIG_UART0_PORT_F)
> { "uart0",3 },/* PF2-PF4 */
> #else
Re: [PATCH] ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM
Hi Marek, On Thu, Apr 18, 2024 at 3:42 PM Marek Vasut wrote: > Interesting. Which TFA blob version do you use ? I used the mainline > 2.10 for my tests. I tested with mainline TFA 2.10 and also with NXP 2.8. The error happens in both cases. > btw. 'no pmic' ? Is that expected ? Yes, this is a separate issue. It happens because there are two PMIC variants on the imx8mm evk.
[PATCH v2 4/5] mmc: am654_sdhci: Set ENDLL=1 for DDR52 mode
According to the device datasheet [0], ENDLL=1 for
DDR52 mode, so call am654_sdhci_setup_dll() and write
itapdly after since we do not carry out tuning.
[0] https://www.ti.com/lit/ds/symlink/am62p.pdf
Fixes: c964447ea3d6 ("mmc: am654_sdhci: Add support for input tap delay")
Signed-off-by: Judith Mendez
Reviewed-by: Jaehoon Chung
---
Changes since v1:
- Add Reviewed-by
---
drivers/mmc/am654_sdhci.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/am654_sdhci.c b/drivers/mmc/am654_sdhci.c
index 62007ebd0f4..e1047812fa8 100644
--- a/drivers/mmc/am654_sdhci.c
+++ b/drivers/mmc/am654_sdhci.c
@@ -289,12 +289,14 @@ static int am654_sdhci_set_ios_post(struct sdhci_host
*host)
regmap_update_bits(plat->base, PHY_CTRL4, mask, val);
- if (mode > UHS_SDR25 && speed >= CLOCK_TOO_SLOW_HZ) {
+ if ((mode > UHS_SDR25 || mode == MMC_DDR_52) && speed >=
CLOCK_TOO_SLOW_HZ) {
ret = am654_sdhci_setup_dll(plat, speed);
if (ret)
return ret;
plat->dll_enable = true;
+ am654_sdhci_write_itapdly(plat, plat->itap_del_sel[mode],
+ plat->itap_del_ena[mode]);
} else {
am654_sdhci_setup_delay_chain(plat, mode);
plat->dll_enable = false;
--
2.43.2
[PATCH v2 5/5] mmc: am654_sdhci: Fix ITAPDLY for HS400 timing
At HS400 mode the ITAPDLY value is that from High Speed mode
which is incorrect and may cause boot failures.
The ITAPDLY for HS400 speed mode should be the same as ITAPDLY
as HS200 timing after tuning is executed. Add the functionality
to save ITAPDLY from HS200 tuning and save as HS400 ITAPDLY.
Fixes: c964447ea3d6 ("mmc: am654_sdhci: Add support for input tap delay")
Signed-off-by: Judith Mendez
---
Changes since v1:
- Use ENABLE macro instead of 0x1
---
drivers/mmc/am654_sdhci.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/mmc/am654_sdhci.c b/drivers/mmc/am654_sdhci.c
index e1047812fa8..fadab7d40bb 100644
--- a/drivers/mmc/am654_sdhci.c
+++ b/drivers/mmc/am654_sdhci.c
@@ -295,6 +295,11 @@ static int am654_sdhci_set_ios_post(struct sdhci_host
*host)
return ret;
plat->dll_enable = true;
+ if (mode == MMC_HS_400) {
+ plat->itap_del_ena[mode] = ENABLE;
+ plat->itap_del_sel[mode] = plat->itap_del_sel[mode - 1];
+ }
+
am654_sdhci_write_itapdly(plat, plat->itap_del_sel[mode],
plat->itap_del_ena[mode]);
} else {
@@ -486,6 +491,9 @@ static int am654_sdhci_execute_tuning(struct mmc *mmc, u8
opcode)
itap = am654_sdhci_calculate_itap(dev, fail_window, fail_index,
plat->dll_enable);
+ /* Save ITAPDLY */
+ plat->itap_del_sel[mode] = itap;
+
am654_sdhci_write_itapdly(plat, itap, plat->itap_del_ena[mode]);
return 0;
--
2.43.2
[PATCH v2 1/5] mmc: am654_sdhci: Add tuning algorithm for delay chain
Currently the sdhci_am654 driver only supports one tuning
algorithm which should be used only when DLL is enabled. The
ITAPDLY is selected from the largest passing window and the
buffer is viewed as a circular buffer.
The new tuning algorithm should be used when the delay chain
is enabled; the ITAPDLY is selected from the largest passing
window and the buffer is not viewed as a circular buffer.
This implementation is based off of the following paper: [1].
Also add support for multiple failing windows.
[1] https://www.ti.com/lit/an/spract9/spract9.pdf
Fixes: a759abf569d4 ("mmc: am654_sdhci: Add support for software tuning")
Signed-off-by: Judith Mendez
---
Changes since v1:
- Remove extra param from mmc_send_tunning() call
---
drivers/mmc/am654_sdhci.c | 107 +++---
1 file changed, 89 insertions(+), 18 deletions(-)
diff --git a/drivers/mmc/am654_sdhci.c b/drivers/mmc/am654_sdhci.c
index 2139fea04d5..7e41dd91f8e 100644
--- a/drivers/mmc/am654_sdhci.c
+++ b/drivers/mmc/am654_sdhci.c
@@ -97,6 +97,7 @@ struct am654_sdhci_plat {
u32 strb_sel;
u32 clkbuf_sel;
u32 flags;
+ bool dll_enable;
#define DLL_PRESENTBIT(0)
#define IOMUX_PRESENT BIT(1)
#define FREQSEL_2_BIT BIT(2)
@@ -110,6 +111,12 @@ struct timing_data {
u32 capability;
};
+struct window {
+ u8 start;
+ u8 end;
+ u8 length;
+};
+
static const struct timing_data td[] = {
[MMC_LEGACY]= {"ti,otap-del-sel-legacy",
"ti,itap-del-sel-legacy",
@@ -280,8 +287,11 @@ static int am654_sdhci_set_ios_post(struct sdhci_host
*host)
ret = am654_sdhci_setup_dll(plat, speed);
if (ret)
return ret;
+
+ plat->dll_enable = true;
} else {
am654_sdhci_setup_delay_chain(plat, mode);
+ plat->dll_enable = false;
}
regmap_update_bits(plat->base, PHY_CTRL5, CLKBUFSEL_MASK,
@@ -375,38 +385,99 @@ static void am654_sdhci_write_b(struct sdhci_host *host,
u8 val, int reg)
writeb(val, host->ioaddr + reg);
}
#ifdef MMC_SUPPORTS_TUNING
-#define ITAP_MAX 32
+#define ITAPDLY_LENGTH 32
+#define ITAPDLY_LAST_INDEX (ITAPDLY_LENGTH - 1)
+
+static u32 am654_sdhci_calculate_itap(struct udevice *dev, struct window
+ *fail_window, u8 num_fails, bool circular_buffer)
+{
+ u8 itap = 0, start_fail = 0, end_fail = 0, pass_length = 0;
+ u8 first_fail_start = 0, last_fail_end = 0;
+ struct window pass_window = {0, 0, 0};
+ int prev_fail_end = -1;
+ u8 i;
+
+ if (!num_fails)
+ return ITAPDLY_LAST_INDEX >> 1;
+
+ if (fail_window->length == ITAPDLY_LENGTH) {
+ dev_err(dev, "No passing ITAPDLY, return 0\n");
+ return 0;
+ }
+
+ first_fail_start = fail_window->start;
+ last_fail_end = fail_window[num_fails - 1].end;
+
+ for (i = 0; i < num_fails; i++) {
+ start_fail = fail_window[i].start;
+ end_fail = fail_window[i].end;
+ pass_length = start_fail - (prev_fail_end + 1);
+
+ if (pass_length > pass_window.length) {
+ pass_window.start = prev_fail_end + 1;
+ pass_window.length = pass_length;
+ }
+ prev_fail_end = end_fail;
+ }
+
+ if (!circular_buffer)
+ pass_length = ITAPDLY_LAST_INDEX - last_fail_end;
+ else
+ pass_length = ITAPDLY_LAST_INDEX - last_fail_end +
first_fail_start;
+
+ if (pass_length > pass_window.length) {
+ pass_window.start = last_fail_end + 1;
+ pass_window.length = pass_length;
+ }
+
+ if (!circular_buffer)
+ itap = pass_window.start + (pass_window.length >> 1);
+ else
+ itap = (pass_window.start + (pass_window.length >> 1)) %
ITAPDLY_LENGTH;
+
+ return (itap > ITAPDLY_LAST_INDEX) ? ITAPDLY_LAST_INDEX >> 1 : itap;
+}
+
static int am654_sdhci_execute_tuning(struct mmc *mmc, u8 opcode)
{
struct udevice *dev = mmc->dev;
struct am654_sdhci_plat *plat = dev_get_plat(dev);
- int cur_val, prev_val = 1, fail_len = 0, pass_window = 0, pass_len;
- u32 itap;
+ struct window fail_window[ITAPDLY_LENGTH];
+ u8 curr_pass, itap;
+ u8 fail_index = 0;
+ u8 prev_pass = 1;
+
+ memset(fail_window, 0, sizeof(fail_window));
/* Enable ITAPDLY */
regmap_update_bits(plat->base, PHY_CTRL4, ITAPDLYENA_MASK,
1 << ITAPDLYENA_SHIFT);
- for (itap = 0; itap < ITAP_MAX; itap++) {
+ for (itap = 0; itap < ITAPDLY_LENGTH; itap++) {
am654_sdhci_write_itapdly(plat, itap);
- cur_val = !mmc_send_tuning(mmc, opcode);
- if (cur_val && !prev_val)
- pass_window = itap;
+
[PATCH v2 3/5] mmc: am654_sdhci: Add itap_del_ena[] to store itapdlyena bit
Set itap_del_ena if ITAPDLY is found in DT or if the tuning
algorithm was executed and found the optimal ITAPDLY. Add the
functionality to save ITAPDLYENA that can be referenced later
by storing the bit in array itap_del_ena[].
Signed-off-by: Judith Mendez
---
Changes since v1:
- Use ENABLE macro instead of 0x1
---
drivers/mmc/am654_sdhci.c | 32 ++--
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/am654_sdhci.c b/drivers/mmc/am654_sdhci.c
index becb3550899..62007ebd0f4 100644
--- a/drivers/mmc/am654_sdhci.c
+++ b/drivers/mmc/am654_sdhci.c
@@ -85,6 +85,8 @@
#define AM654_SDHCI_MIN_FREQ 40
#define CLOCK_TOO_SLOW_HZ 5000
+#define ENABLE 0x1
+
struct am654_sdhci_plat {
struct mmc_config cfg;
struct mmc mmc;
@@ -92,6 +94,7 @@ struct am654_sdhci_plat {
bool non_removable;
u32 otap_del_sel[MMC_MODES_END];
u32 itap_del_sel[MMC_MODES_END];
+ u32 itap_del_ena[MMC_MODES_END];
u32 trm_icp;
u32 drv_strength;
u32 strb_sel;
@@ -223,8 +226,10 @@ static int am654_sdhci_setup_dll(struct am654_sdhci_plat
*plat,
}
static void am654_sdhci_write_itapdly(struct am654_sdhci_plat *plat,
- u32 itapdly)
+ u32 itapdly, u32 enable)
{
+ regmap_update_bits(plat->base, PHY_CTRL4, ITAPDLYENA_MASK,
+ enable << ITAPDLYENA_SHIFT);
/* Set ITAPCHGWIN before writing to ITAPDLY */
regmap_update_bits(plat->base, PHY_CTRL4, ITAPCHGWIN_MASK,
1 << ITAPCHGWIN_SHIFT);
@@ -242,7 +247,8 @@ static void am654_sdhci_setup_delay_chain(struct
am654_sdhci_plat *plat,
mask = SELDLYTXCLK_MASK | SELDLYRXCLK_MASK;
regmap_update_bits(plat->base, PHY_CTRL5, mask, val);
- am654_sdhci_write_itapdly(plat, plat->itap_del_sel[mode]);
+ am654_sdhci_write_itapdly(plat, plat->itap_del_sel[mode],
+ plat->itap_del_ena[mode]);
}
static int am654_sdhci_set_ios_post(struct sdhci_host *host)
@@ -443,6 +449,7 @@ static int am654_sdhci_execute_tuning(struct mmc *mmc, u8
opcode)
struct udevice *dev = mmc->dev;
struct am654_sdhci_plat *plat = dev_get_plat(dev);
struct window fail_window[ITAPDLY_LENGTH];
+ int mode = mmc->selected_mode;
u8 curr_pass, itap;
u8 fail_index = 0;
u8 prev_pass = 1;
@@ -450,11 +457,10 @@ static int am654_sdhci_execute_tuning(struct mmc *mmc, u8
opcode)
memset(fail_window, 0, sizeof(fail_window));
/* Enable ITAPDLY */
- regmap_update_bits(plat->base, PHY_CTRL4, ITAPDLYENA_MASK,
- 1 << ITAPDLYENA_SHIFT);
+ plat->itap_del_ena[mode] = ENABLE;
for (itap = 0; itap < ITAPDLY_LENGTH; itap++) {
- am654_sdhci_write_itapdly(plat, itap);
+ am654_sdhci_write_itapdly(plat, itap, plat->itap_del_ena[mode]);
curr_pass = !mmc_send_tuning(mmc, opcode);
@@ -478,7 +484,7 @@ static int am654_sdhci_execute_tuning(struct mmc *mmc, u8
opcode)
itap = am654_sdhci_calculate_itap(dev, fail_window, fail_index,
plat->dll_enable);
- am654_sdhci_write_itapdly(plat, itap);
+ am654_sdhci_write_itapdly(plat, itap, plat->itap_del_ena[mode]);
return 0;
}
@@ -515,6 +521,7 @@ static int j721e_4bit_sdhci_set_ios_post(struct sdhci_host
*host)
struct am654_sdhci_plat *plat = dev_get_plat(dev);
int mode = host->mmc->selected_mode;
u32 otap_del_sel;
+ u32 itap_del_ena;
u32 itap_del_sel;
u32 mask, val;
@@ -524,10 +531,11 @@ static int j721e_4bit_sdhci_set_ios_post(struct
sdhci_host *host)
val = (1 << OTAPDLYENA_SHIFT) |
(otap_del_sel << OTAPDLYSEL_SHIFT);
+ itap_del_ena = plat->itap_del_ena[mode];
itap_del_sel = plat->itap_del_sel[mode];
mask |= ITAPDLYENA_MASK | ITAPDLYSEL_MASK;
- val |= (1 << ITAPDLYENA_SHIFT) |
+ val |= (itap_del_ena << ITAPDLYENA_SHIFT) |
(itap_del_sel << ITAPDLYSEL_SHIFT);
regmap_update_bits(plat->base, PHY_CTRL4, ITAPCHGWIN_MASK,
@@ -599,9 +607,13 @@ static int sdhci_am654_get_otap_delay(struct udevice *dev,
cfg->host_caps &= ~td[i].capability;
}
- if (td[i].itap_binding)
- dev_read_u32(dev, td[i].itap_binding,
->itap_del_sel[i]);
+ if (td[i].itap_binding) {
+ ret = dev_read_u32(dev, td[i].itap_binding,
+ >itap_del_sel[i]);
+
+ if (!ret)
+ plat->itap_del_ena[i] = ENABLE;
+ }
}
return 0;
--
2.43.2
[PATCH v2 0/5] Fix MMC tuning algorithm
The following patch series includes a MMC tuning algorithm fix according to the following published paper [0]. This seris also includes fixes for OTAP/ITAP delay values in j721e_4bit_sdhci_set_ios_post and for HS400 mode. For DDR52 mode, also set ENDLL=1 and call am654_sdhci_setup_dll() instead of am654_sdhci_setup_delay_chain() according to device datasheet[1]. [0] https://www.ti.com/lit/an/spract9/spract9.pdf [1] https://www.ti.com/lit/ds/symlink/am62p.pdf Link to v1: https://lore.kernel.org/u-boot/20240415212747.2678974-1...@ti.com/ Changes since v1: - Use ENABLE macro instead of 0x1 - Fix assignment to val variable in j721e_4bit_sdhci_set_ios_post() - Remove extra param from mmc_send_tunning() call - Add Reviewed by Judith Mendez (4): mmc: am654_sdhci: Add tuning algorithm for delay chain mmc: am654_sdhci: Add itap_del_ena[] to store itapdlyena bit mmc: am654_sdhci: Set ENDLL=1 for DDR52 mode mmc: am654_sdhci: Fix ITAPDLY for HS400 timing Nitin Yadav (1): mmc: am654_sdhci: Fix OTAP/ITAP delay values drivers/mmc/am654_sdhci.c | 172 +++--- 1 file changed, 140 insertions(+), 32 deletions(-) base-commit: 3434b88d2c2fdad3cc947f9e9b03dabfdd3feb5c -- 2.43.2
[PATCH v2 2/5] mmc: am654_sdhci: Fix OTAP/ITAP delay values
From: Nitin Yadav
U-Boot is failing to boot class U1 UHS SD cards due to incorrect
OTAP and ITAP delay select values. Update OTAP and ITAP delay select
values from DT.
Fixes: c7d106b4eb3 ("mmc: am654_sdhci: Update output tap delay writes")
Signed-off-by: Nitin Yadav
Signed-off-by: Judith Mendez
---
Changes since v1:
- Fix assignment to val variable in j721e_4bit_sdhci_set_ios_post()
---
drivers/mmc/am654_sdhci.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/am654_sdhci.c b/drivers/mmc/am654_sdhci.c
index 7e41dd91f8e..becb3550899 100644
--- a/drivers/mmc/am654_sdhci.c
+++ b/drivers/mmc/am654_sdhci.c
@@ -513,12 +513,27 @@ static int j721e_4bit_sdhci_set_ios_post(struct
sdhci_host *host)
{
struct udevice *dev = host->mmc->dev;
struct am654_sdhci_plat *plat = dev_get_plat(dev);
- u32 otap_del_sel, mask, val;
+ int mode = host->mmc->selected_mode;
+ u32 otap_del_sel;
+ u32 itap_del_sel;
+ u32 mask, val;
+
+ otap_del_sel = plat->otap_del_sel[mode];
- otap_del_sel = plat->otap_del_sel[host->mmc->selected_mode];
mask = OTAPDLYENA_MASK | OTAPDLYSEL_MASK;
- val = (1 << OTAPDLYENA_SHIFT) | (otap_del_sel << OTAPDLYSEL_SHIFT);
+ val = (1 << OTAPDLYENA_SHIFT) |
+ (otap_del_sel << OTAPDLYSEL_SHIFT);
+
+ itap_del_sel = plat->itap_del_sel[mode];
+
+ mask |= ITAPDLYENA_MASK | ITAPDLYSEL_MASK;
+ val |= (1 << ITAPDLYENA_SHIFT) |
+ (itap_del_sel << ITAPDLYSEL_SHIFT);
+
+ regmap_update_bits(plat->base, PHY_CTRL4, ITAPCHGWIN_MASK,
+ 1 << ITAPCHGWIN_SHIFT);
regmap_update_bits(plat->base, PHY_CTRL4, mask, val);
+ regmap_update_bits(plat->base, PHY_CTRL4, ITAPCHGWIN_MASK, 0);
regmap_update_bits(plat->base, PHY_CTRL5, CLKBUFSEL_MASK,
plat->clkbuf_sel);
@@ -572,7 +587,7 @@ static int sdhci_am654_get_otap_delay(struct udevice *dev,
* Remove the corresponding capability if an otap-del-sel
* value is not found
*/
- for (i = MMC_HS; i <= MMC_HS_400; i++) {
+ for (i = MMC_LEGACY; i <= MMC_HS_400; i++) {
ret = dev_read_u32(dev, td[i].otap_binding,
>otap_del_sel[i]);
if (ret) {
--
2.43.2
[PATCH v2 5/5] arm: apple: Do not list bootflows on boot
From: Janne Grunau The bootflow list is only seen briefly and is probably more confusing than helpful. Signed-off-by: Janne Grunau --- configs/apple_m1_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/apple_m1_defconfig b/configs/apple_m1_defconfig index c30aec7c55..4eac1a9e2d 100644 --- a/configs/apple_m1_defconfig +++ b/configs/apple_m1_defconfig @@ -8,6 +8,7 @@ CONFIG_SYS_CBSIZE=256 CONFIG_SYS_PBSIZE=276 # CONFIG_DISPLAY_CPUINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y +CONFIG_BOOTCOMMAND="bootflow scan -b" CONFIG_BOARD_LATE_INIT=y CONFIG_CMD_SELECT_FONT=y # CONFIG_NET is not set -- 2.44.0
[PATCH v2 1/5] apple_m1_defconfig: Turn on CONFIG_SYS_64BIT_LBA
From: Hector Martin This makes USB HDDs >2TiB work. The only reason this hasn't bitten us for the internal NVMe yet is the 4K sector size, because the largest SSD Apple sells is 8TB and we can handle up to 16TiB with that sector size. Close call. Signed-off-by: Hector Martin Reviewed-by: Mark Kettenis Reviewed-by: Neal Gompa Signed-off-by: Janne Grunau --- configs/apple_m1_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/apple_m1_defconfig b/configs/apple_m1_defconfig index e00d72e8be..31d966f0ab 100644 --- a/configs/apple_m1_defconfig +++ b/configs/apple_m1_defconfig @@ -10,6 +10,7 @@ CONFIG_SYS_PBSIZE=276 CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_BOARD_LATE_INIT=y # CONFIG_NET is not set +CONFIG_SYS_64BIT_LBA=y CONFIG_APPLE_SPI_KEYB=y # CONFIG_MMC is not set CONFIG_NVME_APPLE=y -- 2.44.0
[PATCH v2 3/5] configs: apple: Enable CMD_SELECT_FONT and FONT_16X32
From: Janne Grunau Apple devices have high DPI displays so the larger fonts are preferable for improved readability. This does not yet change the used font based on the display's pixel density so the standard 8x16 font is still used by default. Reviewed-by: Mark Kettenis Reviewed-by: Neal Gompa Signed-off-by: Janne Grunau --- configs/apple_m1_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/apple_m1_defconfig b/configs/apple_m1_defconfig index 31d966f0ab..c30aec7c55 100644 --- a/configs/apple_m1_defconfig +++ b/configs/apple_m1_defconfig @@ -9,6 +9,7 @@ CONFIG_SYS_PBSIZE=276 # CONFIG_DISPLAY_CPUINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_BOARD_LATE_INIT=y +CONFIG_CMD_SELECT_FONT=y # CONFIG_NET is not set CONFIG_SYS_64BIT_LBA=y CONFIG_APPLE_SPI_KEYB=y @@ -19,6 +20,7 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_USB_XHCI_PCI=y CONFIG_USB_DWC3=y CONFIG_USB_KEYBOARD=y +CONFIG_VIDEO_FONT_16X32=y CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_NO_FB_CLEAR=y CONFIG_VIDEO_SIMPLE=y -- 2.44.0
[PATCH v2 0/5] configs: apple: Switch to standard boot + small adjustments
This series contains a few misc config changes for Apple silicon systems: - switch from the deprecated distro boot scripts to standard boot - allows EFI console resizing based on the video console size - enables 16x32 bitmap fonts as Apple devices come with high DPI displays - enables 64-bit LBA addressing Signed-off-by: Janne Grunau --- Changes in v2: - added Reviewed-by: tags - switched to BOOTSTD_FULL to enable efi_bootmgr and make interactive use easier - override BOOTCOMMAND to not list the bootflows - rebased onto v2024.04 - Link to v1: https://lore.kernel.org/r/20240317-apple_config-v1-0-1b862bc14...@jannau.net --- Hector Martin (1): apple_m1_defconfig: Turn on CONFIG_SYS_64BIT_LBA Janne Grunau (4): configs: apple: Use "vidconsole,serial" as stdout/stderr configs: apple: Enable CMD_SELECT_FONT and FONT_16X32 arm: apple: Switch to standard boot arm: apple: Do not list bootflows on boot arch/arm/Kconfig | 2 +- configs/apple_m1_defconfig | 4 include/configs/apple.h| 24 3 files changed, 9 insertions(+), 21 deletions(-) --- base-commit: 25049ad560826f7dc1c4740883b0016014a59789 change-id: 20240317-apple_config-981fcd9028b9 Best regards, -- Janne Grunau
[PATCH v2 2/5] configs: apple: Use "vidconsole,serial" as stdout/stderr
From: Janne Grunau The display size querying in efi_console relies on this order. The display should be the primary output device and should be used to display more than 80x25 chars. Reviewed-by: Mark Kettenis Reviewed-by: Neal Gompa Signed-off-by: Janne Grunau --- include/configs/apple.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/apple.h b/include/configs/apple.h index 0576bc04c9..a70440b3ad 100644 --- a/include/configs/apple.h +++ b/include/configs/apple.h @@ -6,8 +6,8 @@ /* Environment */ #define ENV_DEVICE_SETTINGS \ "stdin=serial,usbkbd,spikbd\0" \ - "stdout=serial,vidconsole\0" \ - "stderr=serial,vidconsole\0" + "stdout=vidconsole,serial\0" \ + "stderr=vidconsole,serial\0" #if IS_ENABLED(CONFIG_CMD_NVME) #define BOOT_TARGET_NVME(func) func(NVME, nvme, 0) -- 2.44.0
[PATCH v2 4/5] arm: apple: Switch to standard boot
From: Janne Grunau Use standard boot instead of the distro boot scripts. Use BOOTSTD_FULL instead of BOOTSTD_DEFAULTS for easier interactive use. Signed-off-by: Janne Grunau --- arch/arm/Kconfig| 2 +- include/configs/apple.h | 20 ++-- 2 files changed, 3 insertions(+), 19 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 01d6556c42..9b83b2e6f8 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1034,7 +1034,7 @@ config ARCH_APPLE select USB imply CMD_DM imply CMD_GPT - imply DISTRO_DEFAULTS + imply BOOTSTD_FULL imply OF_HAS_PRIOR_STAGE config ARCH_OWL diff --git a/include/configs/apple.h b/include/configs/apple.h index a70440b3ad..1e08b11448 100644 --- a/include/configs/apple.h +++ b/include/configs/apple.h @@ -9,26 +9,10 @@ "stdout=vidconsole,serial\0" \ "stderr=vidconsole,serial\0" -#if IS_ENABLED(CONFIG_CMD_NVME) - #define BOOT_TARGET_NVME(func) func(NVME, nvme, 0) -#else - #define BOOT_TARGET_NVME(func) -#endif - -#if IS_ENABLED(CONFIG_CMD_USB) - #define BOOT_TARGET_USB(func) func(USB, usb, 0) -#else - #define BOOT_TARGET_USB(func) -#endif - -#define BOOT_TARGET_DEVICES(func) \ - BOOT_TARGET_NVME(func) \ - BOOT_TARGET_USB(func) - -#include +#define BOOT_TARGETS "nvme usb" #define CFG_EXTRA_ENV_SETTINGS \ ENV_DEVICE_SETTINGS \ - BOOTENV + "boot_targets=" BOOT_TARGETS "\0" #endif -- 2.44.0
Re: [PATCH] ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM
On 4/18/24 8:02 PM, Fabio Estevam wrote:
Hi Tim,
On Thu, Apr 18, 2024 at 2:54 PM Tim Harvey wrote:
Fabio, if you enable CONFIG_DM_RNG on an imx8m{m,p}_evk do you get the
following in the SPL?
Couldn't bind rng driver (-96)
SEC0: RNG instantiated
sec_init failed!
Yes, if I add CONFIG_DM_RNG=y to imx8mm_evk_defconfig I get:
U-Boot SPL 2024.04-00793-g3434b88d2c2f-dirty (Apr 18 2024 - 14:58:57 -0300)
No pmic
Couldn't bind rng driver (-96)
SEC0: RNG instantiated
sec_init failed!
Interesting. Which TFA blob version do you use ? I used the mainline
2.10 for my tests.
btw. 'no pmic' ? Is that expected ?
[PATCH v4 2/3] dt-bindings: drop generic headers
Drop all the subsystem headers that are compatible with the headers in dts/upstream. Signed-off-by: Caleb Connolly --- include/dt-bindings/ata/ahci.h | 20 - include/dt-bindings/gpio/gpio.h| 42 -- include/dt-bindings/input/gpio-keys.h | 13 - include/dt-bindings/input/input.h | 17 - include/dt-bindings/input/linux-event-codes.h | 806 - include/dt-bindings/interrupt-controller/irq.h | 19 - include/dt-bindings/leds/common.h | 106 include/dt-bindings/mux/mux.h | 17 - include/dt-bindings/phy/phy.h | 26 - include/dt-bindings/pwm/pwm.h | 14 - include/dt-bindings/spmi/spmi.h| 10 - include/dt-bindings/thermal/thermal.h | 15 - include/dt-bindings/usb/pd.h | 88 --- 13 files changed, 1193 deletions(-) diff --git a/include/dt-bindings/ata/ahci.h b/include/dt-bindings/ata/ahci.h deleted file mode 100644 index b3f3b7cf9af8.. --- a/include/dt-bindings/ata/ahci.h +++ /dev/null @@ -1,20 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */ -/* - * This header provides constants for most AHCI bindings. - */ - -#ifndef _DT_BINDINGS_ATA_AHCI_H -#define _DT_BINDINGS_ATA_AHCI_H - -/* Host Bus Adapter generic platform capabilities */ -#define HBA_SSS(1 << 27) -#define HBA_SMPS (1 << 28) - -/* Host Bus Adapter port-specific platform capabilities */ -#define HBA_PORT_HPCP (1 << 18) -#define HBA_PORT_MPSP (1 << 19) -#define HBA_PORT_CPD (1 << 20) -#define HBA_PORT_ESP (1 << 21) -#define HBA_PORT_FBSCP (1 << 22) - -#endif diff --git a/include/dt-bindings/gpio/gpio.h b/include/dt-bindings/gpio/gpio.h deleted file mode 100644 index c029467e828b.. --- a/include/dt-bindings/gpio/gpio.h +++ /dev/null @@ -1,42 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -/* - * This header provides constants for most GPIO bindings. - * - * Most GPIO bindings include a flags cell as part of the GPIO specifier. - * In most cases, the format of the flags cell uses the standard values - * defined in this header. - */ - -#ifndef _DT_BINDINGS_GPIO_GPIO_H -#define _DT_BINDINGS_GPIO_GPIO_H - -/* Bit 0 express polarity */ -#define GPIO_ACTIVE_HIGH 0 -#define GPIO_ACTIVE_LOW 1 - -/* Bit 1 express single-endedness */ -#define GPIO_PUSH_PULL 0 -#define GPIO_SINGLE_ENDED 2 - -/* Bit 2 express Open drain or open source */ -#define GPIO_LINE_OPEN_SOURCE 0 -#define GPIO_LINE_OPEN_DRAIN 4 - -/* - * Open Drain/Collector is the combination of single-ended open drain interface. - * Open Source/Emitter is the combination of single-ended open source interface. - */ -#define GPIO_OPEN_DRAIN (GPIO_SINGLE_ENDED | GPIO_LINE_OPEN_DRAIN) -#define GPIO_OPEN_SOURCE (GPIO_SINGLE_ENDED | GPIO_LINE_OPEN_SOURCE) - -/* Bit 3 express GPIO suspend/resume and reset persistence */ -#define GPIO_PERSISTENT 0 -#define GPIO_TRANSITORY 8 - -/* Bit 4 express pull up */ -#define GPIO_PULL_UP 16 - -/* Bit 5 express pull down */ -#define GPIO_PULL_DOWN 32 - -#endif diff --git a/include/dt-bindings/input/gpio-keys.h b/include/dt-bindings/input/gpio-keys.h deleted file mode 100644 index 8962df79e753.. --- a/include/dt-bindings/input/gpio-keys.h +++ /dev/null @@ -1,13 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -/* - * This header provides constants for gpio keys bindings. - */ - -#ifndef _DT_BINDINGS_GPIO_KEYS_H -#define _DT_BINDINGS_GPIO_KEYS_H - -#define EV_ACT_ANY 0x00/* asserted or deasserted */ -#define EV_ACT_ASSERTED0x01/* asserted */ -#define EV_ACT_DEASSERTED 0x02/* deasserted */ - -#endif /* _DT_BINDINGS_GPIO_KEYS_H */ diff --git a/include/dt-bindings/input/input.h b/include/dt-bindings/input/input.h deleted file mode 100644 index a21413324a3f.. --- a/include/dt-bindings/input/input.h +++ /dev/null @@ -1,17 +0,0 @@ -/* - * This header provides constants for most input bindings. - * - * Most input bindings include key code, matrix key code format. - * In most cases, key code and matrix key code format uses - * the standard values/macro defined in this header. - */ - -#ifndef _DT_BINDINGS_INPUT_INPUT_H -#define _DT_BINDINGS_INPUT_INPUT_H - -#include "linux-event-codes.h" - -#define MATRIX_KEY(row, col, code) \ - row) & 0xFF) << 24) | (((col) & 0xFF) << 16) | ((code) & 0x)) - -#endif /* _DT_BINDINGS_INPUT_INPUT_H */ diff --git a/include/dt-bindings/input/linux-event-codes.h b/include/dt-bindings/input/linux-event-codes.h deleted file mode 100644 index 331458c0e710.. --- a/include/dt-bindings/input/linux-event-codes.h +++ /dev/null @@ -1,806 +0,0 @@ -/* - * Input event codes - * - **** IMPORTANT *** - * This file is not only included from C-code but also from devicetree source - * files. As such this file MUST only contain comments and defines. - * - * Copyright (c) 1999-2002 Vojtech Pavlik - * Copyright
[PATCH v4 3/3] dts: support building all dtb files for a specific vendor
This adjusts OF_UPSTREAM to behave more like the kernel by allowing for all the devicetree files for a given vendor to be compiled. This is useful for Qualcomm in particular as most boards are supported by a single U-Boot build just provided with a different DT. Signed-off-by: Caleb Connolly --- dts/Kconfig | 24 scripts/Makefile.dts | 13 + 2 files changed, 37 insertions(+) diff --git a/dts/Kconfig b/dts/Kconfig index b9b6367154ef..6883a000a052 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -100,8 +100,32 @@ config OF_UPSTREAM However, newer boards whose devicetree source files haven't landed in the dts/upstream subtree, they can override this option to have the DT build from existing U-Boot tree location instead. +config OF_UPSTREAM_BUILD_VENDOR + bool "Build all devicetree files for a particular vendor" + depends on OF_UPSTREAM + help + Enable building all devicetree files for a particular vendor. This + is useful for generic U-Boot configurations where many boards can + be supported with a single binary. + + This is only available for platforms using upstream devicetree. + +config OF_UPSTREAM_VENDOR + string "Vendor to build all upstream devicetree files for" + depends on OF_UPSTREAM_BUILD_VENDOR + default "qcom" if ARCH_SNAPDRAGON + default "rockchip" if ARCH_ROCKCHIP + default "amlogic" if ARCH_MESON + default "allwinner" if ARCH_SUNXI + default "mediatek" if ARCH_MEDIATEK + default "marvell" if ARCH_MVEBU || ARCH_KIRKWOOD + default "xilinx" if ARCH_VERSAL || ARCH_ZYNQ + default "nvidia" if ARCH_TEGRA + help + Select the vendor to build all devicetree files for. + choice prompt "Provider of DTB for DT control" depends on OF_CONTROL diff --git a/scripts/Makefile.dts b/scripts/Makefile.dts index 5e2429c6170c..790f3c508f19 100644 --- a/scripts/Makefile.dts +++ b/scripts/Makefile.dts @@ -1,3 +1,16 @@ # SPDX-License-Identifier: GPL-2.0+ dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST))) + +ifeq ($(CONFIG_OF_UPSTREAM_BUILD_VENDOR),y) +ifeq ($(CONFIG_ARM64),y) +dt_dir := $(srctree)/dts/upstream/src/arm64 +else +dt_dir := $(srctree)/dts/upstream/src/$(ARCH) +endif + +dtb-vendor_dts := $(patsubst %.dts,%.dtb,$(wildcard $(dt_dir)/$(subst ",,$(CONFIG_OF_UPSTREAM_VENDOR))/*.dts)) + +dtb-y += $(subst $(dt_dir)/,,$(dtb-vendor_dts)) + +endif -- 2.44.0
[PATCH v4 1/3] arm: dts: imx6dl-brppt2: fix gpio.h include
The "include" directory was included in the include path... Remove it.
Signed-off-by: Caleb Connolly
---
arch/arm/dts/imx6dl-brppt2.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/imx6dl-brppt2.dts b/arch/arm/dts/imx6dl-brppt2.dts
index 575bfac7bb73..05c843c3d0f3 100644
--- a/arch/arm/dts/imx6dl-brppt2.dts
+++ b/arch/arm/dts/imx6dl-brppt2.dts
@@ -16,9 +16,9 @@
#include "imx6dl.dtsi"
#include "imx6qdl-u-boot.dtsi"
#include
-#include
+#include
/ {
model = "PPT50";
compatible = "fsl,imx6dl";
--
2.44.0
[PATCH v4 0/3] upstream DT compatibility
This is a subset of [1]. With more platform maintainers switching to OF_UPSTREAM I didn't want to get in the way (it has also proven more difficult than I hoped to remove only the fully compatible header files). This series removes only the dt-bindings headers which contain generic data like GPIO flags, input event codes, etc. It then implements support for building all DTBs for a vendor with OF_UPSTREAM_BUILD_VENDOR. This removes the need to maintain a set list of DTBs that can be built by U-Boot and opens up the possibility of new boards becoming supported "by default" just by landing their DT upstream. [1]: https://lore.kernel.org/u-boot/20240321-b4-upstream-dt-headers-v2-0-1eac0df87...@linaro.org To: Tom Rini To: Simon Glass To: Lukasz Majewski To: Mattijs Korpershoek To: Stefano Babic To: Fabio Estevam To: NXP i.MX U-Boot Team Cc: Neil Armstrong Cc: Sumit Garg Cc: Ilias Apalodimas Cc: u-boot@lists.denx.de Changes in v4: - Fix imx6dl-brppt2 board which had an incorrect relative include path - Link to v3: https://lore.kernel.org/r/20240409-b4-of-upstream-build-vendor-v3-0-f096de0c5...@linaro.org --- Caleb Connolly (3): arm: dts: imx6dl-brppt2: fix gpio.h include dt-bindings: drop generic headers dts: support building all dtb files for a specific vendor arch/arm/dts/imx6dl-brppt2.dts | 2 +- dts/Kconfig| 24 + include/dt-bindings/ata/ahci.h | 20 - include/dt-bindings/gpio/gpio.h| 42 -- include/dt-bindings/input/gpio-keys.h | 13 - include/dt-bindings/input/input.h | 17 - include/dt-bindings/input/linux-event-codes.h | 806 - include/dt-bindings/interrupt-controller/irq.h | 19 - include/dt-bindings/leds/common.h | 106 include/dt-bindings/mux/mux.h | 17 - include/dt-bindings/phy/phy.h | 26 - include/dt-bindings/pwm/pwm.h | 14 - include/dt-bindings/spmi/spmi.h| 10 - include/dt-bindings/thermal/thermal.h | 15 - include/dt-bindings/usb/pd.h | 88 --- scripts/Makefile.dts | 13 + 16 files changed, 38 insertions(+), 1194 deletions(-) --- base-commit: 2c3fa4b8add3cb6a440184ab67debc6867d383c0 // Caleb (they/them)
Re: [PATCH v2 1/3] clk: imx8mm: Add support for PCIe clocks
On 4/18/24 8:24 PM, Tim Harvey wrote:
On Thu, Apr 18, 2024 at 11:14 AM Marek Vasut wrote:
On 4/18/24 7:56 PM, Tim Harvey wrote:
Add support for PCIe clocks required to enable PCIe support on
iMX8MM SoC.
Signed-off-by: Tim Harvey
---
v2: no changes
---
drivers/clk/imx/clk-imx8mm.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index b5c253e49663..c2f01b385201 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -66,6 +66,15 @@ static const char *imx8mm_i2c3_sels[] = {"clock-osc-24m",
"sys_pll1_160m", "sys_
static const char *imx8mm_i2c4_sels[] = {"clock-osc-24m", "sys_pll1_160m", "sys_pll2_50m",
"sys_pll3_out", "audio_pll1_out",
"video_pll1_out", "audio_pll2_out",
"sys_pll1_133m", };
+static const char *imx8mm_pcie1_ctrl_sels[] = {"clock-osc-24m", "sys_pll2_250m",
"sys_pll2_200m", "sys_pll1_266m",
+"sys_pll1_800m", "sys_pll2_500m",
"sys_pll2_333m", "sys_pll3_out", };
+
+static const char *imx8mm_pcie1_phy_sels[] = {"clock-osc-24m", "sys_pll2_100m", "sys_pll2_500m",
"clk_ext1", "clk_ext2",
+ "clk_ext3", "clk_ext4",
"sys_pll1_400m", };
+
+static const char *imx8mm_pcie1_aux_sels[] = {"clock-osc-24m", "sys_pll2_200m",
"sys_pll2_50m", "sys_pll3_out",
+ "sys_pll2_100m", "sys_pll1_80m",
"sys_pll1_160m", "sys_pll1_200m", };
+
#ifndef CONFIG_SPL_BUILD
static const char *imx8mm_pwm1_sels[] = {"clock-osc-24m", "sys_pll2_100m",
"sys_pll1_160m", "sys_pll1_40m",
"sys_pll3_out", "clk_ext1", "sys_pll1_80m",
"video_pll1_out", };
@@ -256,6 +265,15 @@ static int imx8mm_clk_probe(struct udevice *dev)
imx8m_clk_composite("usb_bus", imx8mm_usb_bus_sels, base +
0x8b80));
/* IP */
+ clk_dm(IMX8MM_CLK_PCIE1_CTRL,
+imx8m_clk_composite("pcie1_ctrl", imx8mm_pcie1_ctrl_sels,
+base + 0xa300));
+ clk_dm(IMX8MM_CLK_PCIE1_PHY,
+imx8m_clk_composite("pcie1_phy", imx8mm_pcie1_phy_sels,
+base + 0xa380));
+ clk_dm(IMX8MM_CLK_PCIE1_AUX,
+imx8m_clk_composite("pcie1_aux", imx8mm_pcie1_aux_sels,
+base + 0xa400));
Maybe this should be behind IS_ENABLED() like the SPI clock to avoid
growth of SPL ?
Makes sense... I'll add that in a v3. Thanks for the review!
Of course, glad I could help.
Re: [PATCH v2] ARM: stm32: Initialize TAMP_SMCR BKP..PROT fields on STM32MP15xx
Hi,
On 4/15/24 14:55, Marek Vasut wrote:
In case of an OTP-CLOSED STM32MP15xx system, the CPU core 1 cannot be
released from endless loop in BootROM only by populating TAMP BKPxR 4
and 5 with magic and branch address and sending SGI0 interrupt from
core 0 to core 1 twice. TAMP_SMCR BKP..PROT fields must be initialized
as well to release the core 1 from endless loop during the second SGI0
handling on core 1. Initialize TAMP_SMCR to protect the first 16 backup
registers, the ones which contain the core 1 magic, branch address and
boot information.
This requirement seems to be undocumented, therefore it was necessary
to trace and analyze the STM32MP15xx BootROM using OpenOCD and objdump.
Ultimately, it turns out that a certain BootROM function reads out the
TAMP_SMCR register and tests whether the BKP..PROT fields are non-zero.
If they are zero, the BootROM code again waits for SGI0 using WFI, else
the execution moves forward until it reaches handoff to the TAMP BKPxR 5
branch address.
These backup registers are documented in
https://wiki.st.com/stm32mpu/wiki/STM32MP15_backup_registers
This "security" configuration is done in STMicoelectronics delivery
(OpenSTLinux) in OP-TEE.
This fixes CPU core 1 release using U-Boot PSCI implementation on an
OTP-CLOSED system, i.e. system with fuse 0 bit 6 set.
A ROM code security check is done only for closed device to avoid malicious
code execution: "unsecure" code on CPU2 during wake-up by changing
BRANCH_ADDRESS
=> the STM32MP15 ROM check that only the secure world can update
the TAMP_BKP5R = BRANCH_ADDRESS
before to start the CPU2 and jump to this address.
Sorry to inconvenient, we will improve this part on next release
= OpenSTLinux V5.1
Reviewed-by: Patrick Delaunay
Thanks
Patrick
Signed-off-by: Marek Vasut
---
Cc: Igor Opaniuk
Cc: Patrice Chotard
Cc: Patrick Delaunay
Cc: Simon Glass
Cc: Tom Rini
Cc: u-b...@dh-electronics.com
Cc: uboot-st...@st-md-mailman.stormreply.com
---
V2: Fix up the BKPRWD/BKPWD mask typo
---
arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c
b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c
index dd99150fbc2..a2496361e01 100644
--- a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c
+++ b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
/* RCC register */
#define RCC_TZCR (STM32_RCC_BASE + 0x00)
@@ -41,6 +42,9 @@
#define TZC_REGION_ID_ACCESS0 (STM32_TZC_BASE + 0x114)
#define TAMP_CR1 (STM32_TAMP_BASE + 0x00)
+#define TAMP_SMCR (STM32_TAMP_BASE + 0x20)
+#define TAMP_SMCR_BKPRWDPROT GENMASK(7, 0)
+#define TAMP_SMCR_BKPWDPROTGENMASK(23, 16)
#define PWR_CR1 (STM32_PWR_BASE + 0x00)
#define PWR_MCUCR (STM32_PWR_BASE + 0x14)
@@ -136,6 +140,18 @@ static void security_init(void)
*/
writel(0x0, TAMP_CR1);
+ /*
+* TAMP: Configure non-zero secure protection settings. This is
+* checked by BootROM function 35ac on OTP-CLOSED device during
+* CPU core 1 release from endless loop. If secure protection
+* fields are zero, the core 1 is not released from endless
+* loop on second SGI0.
+*/
+ clrsetbits_le32(TAMP_SMCR,
+ TAMP_SMCR_BKPRWDPROT | TAMP_SMCR_BKPWDPROT,
+ FIELD_PREP(TAMP_SMCR_BKPRWDPROT, 0x10) |
+ FIELD_PREP(TAMP_SMCR_BKPWDPROT, 0x10));
+
/* GPIOZ: deactivate the security */
writel(BIT(0), RCC_MP_AHB5ENSETR);
writel(0x0, GPIOZ_SECCFGR);
The recommended mapping (the mapping done in OP-TEE for OpenSTLinux) is
described in Wiki page
- 10 backup register secure
- 4 backup register secure write / non secure read
- 17 backup register Non-secure
It is done in
https://github.com/STMicroelectronics/optee_os/blob/3.19.0-stm32mp/core/arch/arm/plat-stm32mp1/main.c
with
static TEE_Result stm32_configure_tamp(void)
{
TEE_Result res __maybe_unused = TEE_SUCCESS;
struct stm32_bkpregs_conf bkpregs_conf = {
.nb_zone1_regs = 10, /* 10 registers in zone 1 */
.nb_zone2_regs = 5 /* 5 registers in zone 2 */
/* Zone3 all remaining */
};
/* Enable BKP Register protection */
if (stm32_tamp_set_secure_bkpregs(_conf))
panic();
But when you are booting with SPL U-boot, all the boot chain and the
Linux kernel
is running in secure world
So you have no reason to manage any limit for the access to backup
register,
you can allocate all the backup registers (the 32 one) to secure world
See "Figure 552. Backup registers secure protections" in reference mnauel
Protection zone 1 => x = 31 with BKPRWDPROT = 31
Protection zone 2 & 3 => empty
+ clrsetbits_le32(TAMP_SMCR,
+ TAMP_SMCR_BKPRWDPROT | TAMP_SMCR_BKPWDPROT,
+
Re: [PATCH v2 1/3] clk: imx8mm: Add support for PCIe clocks
On Thu, Apr 18, 2024 at 11:14 AM Marek Vasut wrote:
>
> On 4/18/24 7:56 PM, Tim Harvey wrote:
> > Add support for PCIe clocks required to enable PCIe support on
> > iMX8MM SoC.
> >
> > Signed-off-by: Tim Harvey
> > ---
> > v2: no changes
> > ---
> > drivers/clk/imx/clk-imx8mm.c | 21 +
> > 1 file changed, 21 insertions(+)
> >
> > diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
> > index b5c253e49663..c2f01b385201 100644
> > --- a/drivers/clk/imx/clk-imx8mm.c
> > +++ b/drivers/clk/imx/clk-imx8mm.c
> > @@ -66,6 +66,15 @@ static const char *imx8mm_i2c3_sels[] =
> > {"clock-osc-24m", "sys_pll1_160m", "sys_
> > static const char *imx8mm_i2c4_sels[] = {"clock-osc-24m",
> > "sys_pll1_160m", "sys_pll2_50m", "sys_pll3_out", "audio_pll1_out",
> >"video_pll1_out", "audio_pll2_out",
> > "sys_pll1_133m", };
> >
> > +static const char *imx8mm_pcie1_ctrl_sels[] = {"clock-osc-24m",
> > "sys_pll2_250m", "sys_pll2_200m", "sys_pll1_266m",
> > +"sys_pll1_800m",
> > "sys_pll2_500m", "sys_pll2_333m", "sys_pll3_out", };
> > +
> > +static const char *imx8mm_pcie1_phy_sels[] = {"clock-osc-24m",
> > "sys_pll2_100m", "sys_pll2_500m", "clk_ext1", "clk_ext2",
> > + "clk_ext3", "clk_ext4",
> > "sys_pll1_400m", };
> > +
> > +static const char *imx8mm_pcie1_aux_sels[] = {"clock-osc-24m",
> > "sys_pll2_200m", "sys_pll2_50m", "sys_pll3_out",
> > + "sys_pll2_100m",
> > "sys_pll1_80m", "sys_pll1_160m", "sys_pll1_200m", };
> > +
> > #ifndef CONFIG_SPL_BUILD
> > static const char *imx8mm_pwm1_sels[] = {"clock-osc-24m",
> > "sys_pll2_100m", "sys_pll1_160m", "sys_pll1_40m",
> >"sys_pll3_out", "clk_ext1",
> > "sys_pll1_80m", "video_pll1_out", };
> > @@ -256,6 +265,15 @@ static int imx8mm_clk_probe(struct udevice *dev)
> > imx8m_clk_composite("usb_bus", imx8mm_usb_bus_sels, base +
> > 0x8b80));
> >
> > /* IP */
> > + clk_dm(IMX8MM_CLK_PCIE1_CTRL,
> > +imx8m_clk_composite("pcie1_ctrl", imx8mm_pcie1_ctrl_sels,
> > +base + 0xa300));
> > + clk_dm(IMX8MM_CLK_PCIE1_PHY,
> > +imx8m_clk_composite("pcie1_phy", imx8mm_pcie1_phy_sels,
> > +base + 0xa380));
> > + clk_dm(IMX8MM_CLK_PCIE1_AUX,
> > +imx8m_clk_composite("pcie1_aux", imx8mm_pcie1_aux_sels,
> > +base + 0xa400));
>
> Maybe this should be behind IS_ENABLED() like the SPI clock to avoid
> growth of SPL ?
Makes sense... I'll add that in a v3. Thanks for the review!
Best Regards,
Tim
Re: [PATCH v2 1/3] clk: imx8mm: Add support for PCIe clocks
On 4/18/24 7:56 PM, Tim Harvey wrote:
Add support for PCIe clocks required to enable PCIe support on
iMX8MM SoC.
Signed-off-by: Tim Harvey
---
v2: no changes
---
drivers/clk/imx/clk-imx8mm.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index b5c253e49663..c2f01b385201 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -66,6 +66,15 @@ static const char *imx8mm_i2c3_sels[] = {"clock-osc-24m",
"sys_pll1_160m", "sys_
static const char *imx8mm_i2c4_sels[] = {"clock-osc-24m", "sys_pll1_160m", "sys_pll2_50m",
"sys_pll3_out", "audio_pll1_out",
"video_pll1_out", "audio_pll2_out",
"sys_pll1_133m", };
+static const char *imx8mm_pcie1_ctrl_sels[] = {"clock-osc-24m", "sys_pll2_250m", "sys_pll2_200m", "sys_pll1_266m",
+ "sys_pll1_800m", "sys_pll2_500m",
"sys_pll2_333m", "sys_pll3_out", };
+
+static const char *imx8mm_pcie1_phy_sels[] = {"clock-osc-24m", "sys_pll2_100m", "sys_pll2_500m",
"clk_ext1", "clk_ext2",
+ "clk_ext3", "clk_ext4",
"sys_pll1_400m", };
+
+static const char *imx8mm_pcie1_aux_sels[] = {"clock-osc-24m", "sys_pll2_200m",
"sys_pll2_50m", "sys_pll3_out",
+ "sys_pll2_100m", "sys_pll1_80m",
"sys_pll1_160m", "sys_pll1_200m", };
+
#ifndef CONFIG_SPL_BUILD
static const char *imx8mm_pwm1_sels[] = {"clock-osc-24m", "sys_pll2_100m",
"sys_pll1_160m", "sys_pll1_40m",
"sys_pll3_out", "clk_ext1", "sys_pll1_80m",
"video_pll1_out", };
@@ -256,6 +265,15 @@ static int imx8mm_clk_probe(struct udevice *dev)
imx8m_clk_composite("usb_bus", imx8mm_usb_bus_sels, base +
0x8b80));
/* IP */
+ clk_dm(IMX8MM_CLK_PCIE1_CTRL,
+ imx8m_clk_composite("pcie1_ctrl", imx8mm_pcie1_ctrl_sels,
+ base + 0xa300));
+ clk_dm(IMX8MM_CLK_PCIE1_PHY,
+ imx8m_clk_composite("pcie1_phy", imx8mm_pcie1_phy_sels,
+ base + 0xa380));
+ clk_dm(IMX8MM_CLK_PCIE1_AUX,
+ imx8m_clk_composite("pcie1_aux", imx8mm_pcie1_aux_sels,
+ base + 0xa400));
Maybe this should be behind IS_ENABLED() like the SPI clock to avoid
growth of SPL ?
Re: [PATCH v2 2/3] pci: dw_imx: add support for IMX8MM
On 4/18/24 7:56 PM, Tim Harvey wrote: Add support for the IMX8MM SoC by adding driver data with the compatible string of the GPR controller. Signed-off-by: Tim Harvey Reviewed-by: Marek Vasut
Re: [GIT PULL] Please pull u-boot-mpc8xx
On Thu, Apr 18, 2024 at 04:03:28PM +, Christophe Leroy wrote: > Hi Tom, > > This pull request adds support for temperature sensors et FPGA loading > on boards from CS GROUP France. > > CI: https://source.denx.de/u-boot/custodians/u-boot-mpc8xx/-/pipelines/20416 > > Thanks > Christophe > > The following changes since commit 2c3fa4b8add3cb6a440184ab67debc6867d383c0: > >sandbox: don't call os_close with invalid file descriptor (2024-04-17 > 17:06:16 -0600) > > are available in the Git repository at: > >g...@source.denx.de:u-boot/custodians/u-boot-mpc8xx.git for-2024.07 > > for you to fetch changes up to 741e30e8c2b837dc92ee2eedec5478afdd83a316: > >board: cssi: Read and display MCR board address (2024-04-18 15:47:46 > +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 01/10] board: ti: am62x: Init DRAM size in R5/A53 SPL
On Thu, Apr 18, 2024 at 04:08:46PM +0530, Chintan Vankar wrote: > > > On 17/04/24 21:34, Tom Rini wrote: > > On Wed, Apr 17, 2024 at 05:48:31PM +0530, Sughosh Ganu wrote: > > > hi Chintan, > > > > > > On Wed, 17 Apr 2024 at 13:21, Chintan Vankar wrote: > > > > > > > > > > > > > > > > On 16/04/24 22:30, Tom Rini wrote: > > > > > On Tue, Apr 16, 2024 at 05:52:58PM +0530, Chintan Vankar wrote: > > > > > > > > > > > > > > > > > > On 12/04/24 03:37, Tom Rini wrote: > > > > > > > On Wed, Apr 03, 2024 at 06:18:01PM +0530, Chintan Vankar wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 22/01/24 10:11, Siddharth Vadapalli wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > On 20/01/24 22:11, Tom Rini wrote: > > > > > > > > > > On Mon, Jan 15, 2024 at 01:42:51PM +0530, Siddharth > > > > > > > > > > Vadapalli wrote: > > > > > > > > > > > Hello Tom, > > > > > > > > > > > > > > > > > > > > > > On 12/01/24 18:56, Tom Rini wrote: > > > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > The list of conditionals in > > > > > > > > > > > > common/spl/spl.c::board_init_r() should be > > > > > > > > > > > > updated and probably use SPL_NET as the option to check > > > > > > > > > > > > for. > > > > > > > > > > > > > > > > > > > > > > Thank you for reviewing the patch and pointing this out. > > > > > > > > > > > I wasn't aware of it. I > > > > > > > > > > > assume that you are referring to the following change: > > > > > > > > > > > > > > > > > > > > > > if (IS_ENABLED(CONFIG_SPL_OS_BOOT) || > > > > > > > > > > > CONFIG_IS_ENABLED(HANDOFF) || > > > > > > > > > > > - IS_ENABLED(CONFIG_SPL_ATF)) > > > > > > > > > > > + IS_ENABLED(CONFIG_SPL_ATF) || > > > > > > > > > > > IS_ENABLED(CONFIG_SPL_NET)) > > > > > > > > > > > dram_init_banksize(); > > > > > > > > > > > > > > > > > > > > > > I shall replace the current patch with the above change > > > > > > > > > > > in the v2 series. Since > > > > > > > > > > > this is in the common section, is there a generic reason > > > > > > > > > > > I could provide in the > > > > > > > > > > > commit message rather than the existing commit message > > > > > > > > > > > which seems to be board > > > > > > > > > > > specific? Also, I hope that the above change will not > > > > > > > > > > > cause regressions for > > > > > > > > > > > other non-TI devices. Please let me know. > > > > > > > > > > > > > > > > > > > > Yes, that's the area, and just note that networking also > > > > > > > > > > requires the > > > > > > > > > > DDR to be initialized. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you for confirming and providing your suggestion for > > > > > > > > > the contents of the > > > > > > > > > commit message. > > > > > > > > > > > > > > > > > Following Tom's Suggestion of adding CONFIG_SPL_NET in > > > > > > > > common/spl/spl.c > > > > > > > > "dram_init_banksize()", the issue of fetching a file at SPL > > > > > > > > stage seemed > > > > > > > > to be fixed. However the commit "ba20b2443c29", which sets > > > > > > > > gd->ram_top > > > > > > > > for the very first time in "spl_enable_cache()" results in > > > > > > > > "arch_lmb_reserve()" function reserving memory region from > > > > > > > > Stack pointer > > > > > > > > at "0x81FFB820" to gd->ram_top pointing to "0x1". > > > > > > > > Previously > > > > > > > > when gd->ram_top was zero "arch_lmb_reserve()" was noop. Now > > > > > > > > using TFTP > > > > > > > > to fetch U-Boot image at SPL stage results in > > > > > > > > "tftp_init_load_addr()" > > > > > > > > function call that invokes "arch_lmb_reserve()" function, which > > > > > > > > reserves > > > > > > > > entire memory starting from Stack Pointer to gd->ram_top > > > > > > > > leaving no > > > > > > > > space to load U-Boot image via TFTP since TFTP loads files at > > > > > > > > pre > > > > > > > > configured memory address at "0x8200". > > > > > > > > > > > > > > > > As a workaround for this issue, one solution we can propose is > > > > > > > > to > > > > > > > > disable the checks "lmb_get_free_size()" at SPL and U-Boot > > > > > > > > stage. For > > > > > > > > that we can define a new config option for LMB reserve checks as > > > > > > > > "SPL_LMB". This config will be enable by default for the > > > > > > > > backword > > > > > > > > compatibility and disable for our use case at SPL and U-Boot > > > > > > > > stage. > > > > > > > > > > > > > > The problem here is that we need LMB for booting an OS, which is > > > > > > > something we'll want in SPL in non-cortex-R cases too, which > > > > > > > means this > > > > > > > platform, so that's a no-go. I think you need to dig harder and > > > > > > > see if > > > > > > > you can correct the logic somewhere so that we don't over reserve? > > > > > > > > > > > > > Since this issue is due to function call "lmb_init_and_reserve()" > > > > > > function
Re: [PATCH v2 00/16] pxe: Allow extlinux booting without CMDLINE enabled
On Sun, Apr 14, 2024 at 06:58:03PM +0200, Jonas Karlman wrote:
> Hi Tom and Simon,
>
> On 2024-04-11 03:45, Tom Rini wrote:
> > On Thu, 14 Dec 2023 21:18:58 -0700, Simon Glass wrote:
> >
> >> This series is the culmanation of the current line of refactoring
> >> series. It adjusts pxe to call the booting functionality directly
> >> rather than going through the command-line interface.
> >>
> >> With this is is possible to boot using the extlinux bootmeth without
> >> the command line enabled.
> >>
> >> [...]
> >
> > Applied to u-boot/master, thanks!
> >
>
> This series is causing boot issues using extlinux in bootm_run_states():
>
> ERROR: booting os 'Invalid OS' (0) is not supported
>
> Following extlinux.conf was used:
>
> label linux
> kernel /Image.gz
> initrd /initramfs.cpio.gz
>
> Before this series booting works, bootm_run_states() is first called
> with states=0x1 (BOOTM_STATE_START):
>
> Scanning bootdev 'mmc@fe2b.bootdev':
> 1 extlinux ready mmc 1 m...@fe2b.bootdev.part
> /extlinux/extlinux.conf
> ** Booting bootflow 'mmc@fe2b.bootdev.part_1' with extlinux
> 1: linux
> Retrieving file: /Image.gz
> Retrieving file: /initramfs.cpio.gz
> bootm_run_states(): images->state: 0, states: 1
> bootm_run_states(): images->os.os: 0
> bootm_run_states(): images->os.arch: 0
> bootm_run_states(): boot_fn: , need_boot_fn: 0
> Uncompressing Kernel Image to 0
> ## Flattened Device Tree blob at edef8410
> Booting using the fdt blob at 0xedef8410
> Working FDT set to edef8410
> bootm_run_states(): images->state: 1, states: 1710
> Loading Ramdisk to ecdfd000, end eceb274d ... OK
> bootm_run_states(): images->os.os: 5
> bootm_run_states(): images->os.arch: 16
> boot_fn: eff2b83c, need_boot_fn: 0
> Loading Device Tree to ecde8000, end ecdfc97f ... OK
> Working FDT set to ecde8000
>
> After this series booting fails, bootm_run_states() is first called
> with states=0x1710.
>
> Scanning bootdev 'mmc@fe2b.bootdev':
> 1 extlinux ready mmc 1 m...@fe2b.bootdev.part
> /extlinux/extlinux.conf
> ** Booting bootflow 'mmc@fe2b.bootdev.part_1' with extlinux
> 1: linux
> Retrieving file: /Image.gz
> Retrieving file: /initramfs.cpio.gz
> bootm_run_states(): images->state: 0, states: 1710
> bootm_run_states(): images->os.os: 0
> bootm_run_states(): images->os.arch: 0
> bootm_run_states(): boot_fn: , need_boot_fn: 0
> ERROR: booting os 'Invalid OS' (0) is not supported
> Boot failed (err=-14)
>
> Looks like booti_start() -> bootm_run_states(bmi, BOOTM_STATE_START) is
> no longer called due to changes in this series.
I think the problem is with:
commit 6d803ec9cc757bda0c48f2fd419cb6878eab92c4
Author: Simon Glass
Date: Thu Dec 14 21:19:12 2023 -0700
pxe: Allow booting without CMDLINE for bootm methods
Use bootm_run() and booti_run() to boot rather than the command line.
This allows extlinux to be used without CMDLINE being enabled.
Collect any error but do not return it, to match the existing code.
Signed-off-by: Simon Glass
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
[snip]
@@ -641,23 +644,18 @@ static int label_run_boot(struct pxe_context *ctx, struct
pxe_label *label,
if (!fdt_addr && genimg_get_format(buf) != IMAGE_FORMAT_FIT)
fdt_addr = env_get("fdtcontroladdr");
- if (fdt_addr) {
- if (!bootm_argv[2])
- bootm_argv[2] = "-";
- bootm_argc = 4;
- }
- bootm_argv[3] = (char *)fdt_addr;
+ bmi.conf_fdt = fdt_addr;
/* Try bootm for legacy and FIT format image */
if (genimg_get_format(buf) != IMAGE_FORMAT_INVALID &&
-IS_ENABLED(CONFIG_CMD_BOOTM))
- do_bootm(ctx->cmdtp, 0, bootm_argc, bootm_argv);
+ IS_ENABLED(CONFIG_BOOTM))
+ ret = bootm_run();
/* Try booting an AArch64 Linux kernel image */
- else if (IS_ENABLED(CONFIG_CMD_BOOTI))
- do_booti(ctx->cmdtp, 0, bootm_argc, bootm_argv);
+ else if (IS_ENABLED(CONFIG_BOOTM))
+ ret = booti_run();
/* Try booting a Image */
- else if (IS_ENABLED(CONFIG_CMD_BOOTZ))
- do_bootz(ctx->cmdtp, 0, bootm_argc, bootm_argv);
+ else if (IS_ENABLED(CONFIG_BOOTM))
+ ret = bootz_run();
/* Try booting an x86_64 Linux kernel image */
else if (IS_ENABLED(CONFIG_CMD_ZBOOT))
do_zboot_parent(ctx->cmdtp, 0, zboot_argc, zboot_argv, NULL);
And this doesn't seem equivalent really. The logic used to be checking
if we had bootm/booti/bootz and now it's always checking for
CONFIG_BOOTM. Jonas, can you please share the defconfig you used here as
well? But I think for now reverting the series is the best path forward,
unfortunately.
--
Tom
signature.asc
Re: [PATCH] ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM
Hi Tim,
On Thu, Apr 18, 2024 at 2:54 PM Tim Harvey wrote:
> Fabio, if you enable CONFIG_DM_RNG on an imx8m{m,p}_evk do you get the
> following in the SPL?
> Couldn't bind rng driver (-96)
> SEC0: RNG instantiated
>
> sec_init failed!
Yes, if I add CONFIG_DM_RNG=y to imx8mm_evk_defconfig I get:
U-Boot SPL 2024.04-00793-g3434b88d2c2f-dirty (Apr 18 2024 - 14:58:57 -0300)
No pmic
Couldn't bind rng driver (-96)
SEC0: RNG instantiated
sec_init failed!
[PATCH] arm: mach-k3: am642: Fix reset for workaround errata ID i2331
To workaround an issue in AM642 we reset the SoC in early boot. For that
we first probed the sysreset driver by calling uclass_get_device(). The
ti-sci sysreset driver is now probed during the ti-sci firmware probe.
Update this call to probe the firmware driver which will then probe
the sysreset driver allowing do_reset() to again function as expected.
Reported-by: Jonathan Humphreys
Fixes: fc5d40283483 ("firmware: ti_sci: Bind sysreset driver when enabled")
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/am642_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-k3/am642_init.c b/arch/arm/mach-k3/am642_init.c
index ddf47ef0a9b..80c3cb3479f 100644
--- a/arch/arm/mach-k3/am642_init.c
+++ b/arch/arm/mach-k3/am642_init.c
@@ -226,7 +226,7 @@ void board_init_f(ulong dummy)
* The warm reset realigns internal clocks and prevents the lockup from
* happening.
*/
- ret = uclass_first_device_err(UCLASS_SYSRESET, );
+ ret = uclass_get_device_by_driver(UCLASS_FIRMWARE,
DM_DRIVER_GET(ti_sci), );
if (ret)
printf("\n%s:uclass device error [%d]\n",__func__,ret);
--
2.39.2
[PATCH v2 3/3] imx8mm_venice_defconfig: Enable PCIe/NVMe support
Enable PCIe/NVMe support. Also, enable the reset driver which is a prerequisite for PCIe support. Signed-off-by: Tim Harvey --- v2: no changes --- configs/imx8mm_venice_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/imx8mm_venice_defconfig b/configs/imx8mm_venice_defconfig index 517b70b69477..0f97b4b84243 100644 --- a/configs/imx8mm_venice_defconfig +++ b/configs/imx8mm_venice_defconfig @@ -12,6 +12,7 @@ CONFIG_DEFAULT_DEVICE_TREE="freescale/imx8mm-venice-gw71xx-0x" CONFIG_SPL_TEXT_BASE=0x7E1000 CONFIG_TARGET_IMX8MM_VENICE=y CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_DM_RESET=y CONFIG_SYS_MONITOR_LEN=524288 CONFIG_SPL_MMC=y CONFIG_SPL_SERIAL=y @@ -20,6 +21,7 @@ CONFIG_SPL_STACK=0x92 CONFIG_SPL=y CONFIG_ENV_OFFSET_REDUND=0x3f8000 CONFIG_SYS_LOAD_ADDR=0x4820 +CONFIG_PCI=y CONFIG_SYS_MEMTEST_START=0x4000 CONFIG_SYS_MEMTEST_END=0x8000 CONFIG_FIT=y @@ -60,6 +62,7 @@ CONFIG_CMD_FUSE=y CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_PCI=y CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_CMD_DHCP6=y @@ -120,6 +123,9 @@ CONFIG_PHY_GIGE=y CONFIG_FEC_MXC=y CONFIG_KSZ9477=y CONFIG_MII=y +CONFIG_NVME_PCI=y +CONFIG_PCIE_DW_IMX=y +CONFIG_PHY_IMX8M_PCIE=y CONFIG_PINCTRL=y CONFIG_SPL_PINCTRL=y CONFIG_PINCTRL_IMX8M=y -- 2.25.1
[PATCH v2 2/3] pci: dw_imx: add support for IMX8MM
Add support for the IMX8MM SoC by adding driver data with the compatible
string of the GPR controller.
Signed-off-by: Tim Harvey
---
v2: do not cache chip info in priv per Marek's suggestion
---
drivers/pci/pcie_dw_imx.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pcie_dw_imx.c b/drivers/pci/pcie_dw_imx.c
index a2ee228224b5..fdb463710ba1 100644
--- a/drivers/pci/pcie_dw_imx.c
+++ b/drivers/pci/pcie_dw_imx.c
@@ -56,6 +56,18 @@ struct pcie_dw_imx {
struct udevice *vpcie;
};
+struct pcie_chip_info {
+ const char *gpr;
+};
+
+static const struct pcie_chip_info imx8mm_chip_info = {
+ .gpr = "fsl,imx8mm-iomuxc-gpr",
+};
+
+static const struct pcie_chip_info imx8mp_chip_info = {
+ .gpr = "fsl,imx8mp-iomuxc-gpr",
+};
+
static void pcie_dw_configure(struct pcie_dw_imx *priv, u32 cap_speed)
{
dw_pcie_dbi_write_enable(>dw, true);
@@ -242,6 +254,7 @@ static int pcie_dw_imx_remove(struct udevice *dev)
static int pcie_dw_imx_of_to_plat(struct udevice *dev)
{
+ struct pcie_chip_info *info = (void *)dev_get_driver_data(dev);
struct pcie_dw_imx *priv = dev_get_priv(dev);
ofnode gpr;
int ret;
@@ -287,7 +300,7 @@ static int pcie_dw_imx_of_to_plat(struct udevice *dev)
goto err_phy;
}
- gpr = ofnode_by_compatible(ofnode_null(), "fsl,imx8mp-iomuxc-gpr");
+ gpr = ofnode_by_compatible(ofnode_null(), info->gpr);
if (ofnode_equal(gpr, ofnode_null())) {
dev_err(dev, "unable to find GPR node\n");
ret = -ENODEV;
@@ -322,7 +335,8 @@ static const struct dm_pci_ops pcie_dw_imx_ops = {
};
static const struct udevice_id pcie_dw_imx_ids[] = {
- { .compatible = "fsl,imx8mp-pcie" },
+ { .compatible = "fsl,imx8mm-pcie", .data = (ulong)_chip_info, },
+ { .compatible = "fsl,imx8mp-pcie", .data = (ulong)_chip_info, },
{ }
};
--
2.25.1
[PATCH v2 1/3] clk: imx8mm: Add support for PCIe clocks
Add support for PCIe clocks required to enable PCIe support on
iMX8MM SoC.
Signed-off-by: Tim Harvey
---
v2: no changes
---
drivers/clk/imx/clk-imx8mm.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index b5c253e49663..c2f01b385201 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -66,6 +66,15 @@ static const char *imx8mm_i2c3_sels[] = {"clock-osc-24m",
"sys_pll1_160m", "sys_
static const char *imx8mm_i2c4_sels[] = {"clock-osc-24m", "sys_pll1_160m",
"sys_pll2_50m", "sys_pll3_out", "audio_pll1_out",
"video_pll1_out", "audio_pll2_out",
"sys_pll1_133m", };
+static const char *imx8mm_pcie1_ctrl_sels[] = {"clock-osc-24m",
"sys_pll2_250m", "sys_pll2_200m", "sys_pll1_266m",
+ "sys_pll1_800m",
"sys_pll2_500m", "sys_pll2_333m", "sys_pll3_out", };
+
+static const char *imx8mm_pcie1_phy_sels[] = {"clock-osc-24m",
"sys_pll2_100m", "sys_pll2_500m", "clk_ext1", "clk_ext2",
+ "clk_ext3", "clk_ext4",
"sys_pll1_400m", };
+
+static const char *imx8mm_pcie1_aux_sels[] = {"clock-osc-24m",
"sys_pll2_200m", "sys_pll2_50m", "sys_pll3_out",
+ "sys_pll2_100m", "sys_pll1_80m",
"sys_pll1_160m", "sys_pll1_200m", };
+
#ifndef CONFIG_SPL_BUILD
static const char *imx8mm_pwm1_sels[] = {"clock-osc-24m", "sys_pll2_100m",
"sys_pll1_160m", "sys_pll1_40m",
"sys_pll3_out", "clk_ext1",
"sys_pll1_80m", "video_pll1_out", };
@@ -256,6 +265,15 @@ static int imx8mm_clk_probe(struct udevice *dev)
imx8m_clk_composite("usb_bus", imx8mm_usb_bus_sels, base +
0x8b80));
/* IP */
+ clk_dm(IMX8MM_CLK_PCIE1_CTRL,
+ imx8m_clk_composite("pcie1_ctrl", imx8mm_pcie1_ctrl_sels,
+ base + 0xa300));
+ clk_dm(IMX8MM_CLK_PCIE1_PHY,
+ imx8m_clk_composite("pcie1_phy", imx8mm_pcie1_phy_sels,
+ base + 0xa380));
+ clk_dm(IMX8MM_CLK_PCIE1_AUX,
+ imx8m_clk_composite("pcie1_aux", imx8mm_pcie1_aux_sels,
+ base + 0xa400));
clk_dm(IMX8MM_CLK_USDHC1,
imx8m_clk_composite("usdhc1", imx8mm_usdhc1_sels,
base + 0xac00));
@@ -339,6 +357,9 @@ static int imx8mm_clk_probe(struct udevice *dev)
imx_clk_gate4("pwm4_root_clk", "pwm4", base + 0x42b0, 0));
#endif
+ clk_dm(IMX8MM_CLK_PCIE1_ROOT,
+ imx_clk_gate4("pcie1_root_clk", "pcie1_ctrl", base + 0x4250, 0));
+
#if CONFIG_IS_ENABLED(DM_SPI)
clk_dm(IMX8MM_CLK_ECSPI1,
imx8m_clk_composite("ecspi1", imx8mm_ecspi1_sels, base +
0xb280));
--
2.25.1
Re: [PATCH] ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM
On Thu, Apr 18, 2024 at 10:33 AM Marek Vasut wrote:
>
> On 4/18/24 6:21 PM, Tim Harvey wrote:
> > On Fri, Jan 19, 2024 at 4:36 PM Marek Vasut wrote:
> >>
> >> Linux 6.6.y with KASLR enabled would print the following message on boot:
> >> "
> >> KASLR disabled due to lack of seed
> >> "
> >> Enable the 'kaslrseed' command so a random number seed can be pulled
> >> from CAAM and inserted into the /chosen node 'kaslr-seed' property of
> >> Linux kernel DT before boot, thus letting KASLR work properly.
> >>
> >> Signed-off-by: Marek Vasut
> >> ---
> >> Cc: Fabio Estevam
> >> Cc: Stefano Babic
> >> Cc: u-b...@dh-electronics.com
> >> ---
> >> configs/imx8mp_dhcom_pdk2_defconfig | 2 ++
> >> configs/imx8mp_dhcom_pdk3_defconfig | 2 ++
> >> 2 files changed, 4 insertions(+)
> >>
> >> diff --git a/configs/imx8mp_dhcom_pdk2_defconfig
> >> b/configs/imx8mp_dhcom_pdk2_defconfig
> >> index 4f907ce00d0..23fb6272ad5 100644
> >> --- a/configs/imx8mp_dhcom_pdk2_defconfig
> >> +++ b/configs/imx8mp_dhcom_pdk2_defconfig
> >> @@ -117,6 +117,7 @@ CONFIG_CMD_BOOTCOUNT=y
> >> CONFIG_CMD_CACHE=y
> >> CONFIG_CMD_TIME=y
> >> CONFIG_CMD_GETTIME=y
> >> +CONFIG_CMD_KASLRSEED=y
> >> CONFIG_CMD_SYSBOOT=y
> >> CONFIG_CMD_UUID=y
> >> CONFIG_CMD_PMIC=y
> >> @@ -223,6 +224,7 @@ CONFIG_DM_REGULATOR_PCA9450=y
> >> CONFIG_SPL_DM_REGULATOR_PCA9450=y
> >> CONFIG_DM_REGULATOR_FIXED=y
> >> CONFIG_DM_REGULATOR_GPIO=y
> >> +CONFIG_DM_RNG=y
> >> CONFIG_DM_RTC=y
> >> CONFIG_RTC_M41T62=y
> >> CONFIG_CONS_INDEX=2
> >> diff --git a/configs/imx8mp_dhcom_pdk3_defconfig
> >> b/configs/imx8mp_dhcom_pdk3_defconfig
> >> index 9972e2d96b6..0d47c12b1f9 100644
> >> --- a/configs/imx8mp_dhcom_pdk3_defconfig
> >> +++ b/configs/imx8mp_dhcom_pdk3_defconfig
> >> @@ -119,6 +119,7 @@ CONFIG_CMD_BOOTCOUNT=y
> >> CONFIG_CMD_CACHE=y
> >> CONFIG_CMD_TIME=y
> >> CONFIG_CMD_GETTIME=y
> >> +CONFIG_CMD_KASLRSEED=y
> >> CONFIG_CMD_SYSBOOT=y
> >> CONFIG_CMD_UUID=y
> >> CONFIG_CMD_PMIC=y
> >> @@ -228,6 +229,7 @@ CONFIG_DM_REGULATOR_PCA9450=y
> >> CONFIG_SPL_DM_REGULATOR_PCA9450=y
> >> CONFIG_DM_REGULATOR_FIXED=y
> >> CONFIG_DM_REGULATOR_GPIO=y
> >> +CONFIG_DM_RNG=y
> >> CONFIG_DM_RTC=y
> >> CONFIG_RTC_M41T62=y
> >> CONFIG_CONS_INDEX=2
> >> --
> >> 2.43.0
> >>
> >
> > Hi Marek,
> >
> > Sorry to respond to an old thread but I ran across this when enabling
> > KALSR on my boards.
> >
> > I have noticed when you enable DM_RNG on IMX8M that SPL fails to bind
> > the driver:
> > Couldn't bind rng driver (-96)
> > SEC0: RNG instantiated
> >
> > sec_init failed!
>
> Did you enable CAAM and ARCH_MISC_INIT on your machine, to initialize
> CAAM in SPL ?
yes
>
> > Didn't you encounter this as well? It seems to me that we may need to
> > add the ability to disable DM_RNG in the SPL unless I'm missing
> > something.
>
> No, but see above, I suspect that might be it, see also
>
> 1f908b1898bd ("ARM: imx8m: Deduplicate CAAM init with arch_misc_init()
> call")
yes, I have that same patch with
c8645e74113c6 ("configs: imx8m: Prepare imx8m-venice boards for HAB support")
Do you have an IMX8M board on hand to check against to see if you see
the same error in the SPL?
Fabio, if you enable CONFIG_DM_RNG on an imx8m{m,p}_evk do you get the
following in the SPL?
Couldn't bind rng driver (-96)
SEC0: RNG instantiated
sec_init failed!
Best Regards,
Tim
Re: [PATCH] rockchip: nanopi-r4s: Fix ehci usb error
Hi Jonas,
On Apr 18, 2024 at 07:52:03, Jonas Karlman wrote:
> Hi Justin,
>
> On 2024-04-18 03:45, Justin Klaassen wrote:
>
> The ehci_generic driver always failed with the error:
>
> Bus usb@fe38: ehci_generic usb@fe38:
>
> ... Failed to get clocks (ret=-19)
>
> Port not available.
>
> Bus usb@fe3c: ehci_generic usb@fe3c:
>
> ... Failed to get clocks (ret=-19)
>
> Port not available.
>
>
> This error is resolved by enabling the CONFIG_PHY_ROCKCHIP_INNO_USB2
>
> and CONFIG_PHY_ROCKCHIP_TYPEC driver options.
>
>
> Is your issue also fixed with my series "rockchip: rk3399: Sync DT with
> linux v6.8 and update defconfigs" [1] containing patch [2]? A v2 of that
> series should hit the mailing list sometime tomorrow.
>
> [1] https://patchwork.ozlabs.org/cover/1918319/
> [2] https://patchwork.ozlabs.org/patch/1918346/
>
>
It looks like your patch does include all the necessary config changes from
my patch, so that should resolve the issue.
> The CONFIG_DM_RESET option must also be enabled, otherwise the
>
> ehci_generic driver will fail with the error:
>
> Bus usb@fe38: ehci_generic usb@fe38:
>
> ... Failed to get resets (err=-524)
>
> probe failed, error -524
>
> Bus usb@fe3c: ehci_generic usb@fe3c:
>
> ... Failed to get resets (err=-524)
>
> probe failed, error -524
>
>
> Additionally the u2phy1_host device was previously disabled in the
>
> nanopi-r4s device tree and must be enabled to avoid a crash in the
>
> ehci_generic driver:
>
> Bus usb@fe38: USB EHCI 1.00
>
> Bus usb@fe3c: "Synchronous Abort" handler, esr 0x9610, far 0x0
>
>
> With these changes the usb ports can now be initialized correctly by
>
> both the ehci_generic and xhci_generic drivers:
>
> Bus usb@fe38: USB EHCI 1.00
>
> Bus usb@fe3c: USB EHCI 1.00
>
> Bus usb@fe80: Register 2000140 NbrPorts 2
>
> Starting the controller
>
> USB XHCI 1.10
>
> Bus usb@fe90: Register 2000140 NbrPorts 2
>
> Starting the controller
>
> USB XHCI 1.10
>
> scanning bus usb@fe38 for devices... 1 USB Device(s) found
>
> scanning bus usb@fe3c for devices... 1 USB Device(s) found
>
> scanning bus usb@fe80 for devices... 1 USB Device(s) found
>
> scanning bus usb@fe90 for devices... 1 USB Device(s) found
>
>scanning usb for storage devices... 0 Storage Device(s) found
>
>
> Signed-off-by: Justin Klaassen
>
> Cc: Simon Glass
>
> Cc: Philipp Tomsich
>
> Cc: Kever Yang
>
> ---
>
> arch/arm/dts/rk3399-nanopi-r4s.dts | 2 +-
>
> configs/nanopi-r4s-rk3399_defconfig | 3 +++
>
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
>
> diff --git a/arch/arm/dts/rk3399-nanopi-r4s.dts
> b/arch/arm/dts/rk3399-nanopi-r4s.dts
>
> index cef4d18b599..a992a6ac5e9 100644
>
> --- a/arch/arm/dts/rk3399-nanopi-r4s.dts
>
> +++ b/arch/arm/dts/rk3399-nanopi-r4s.dts
>
> @@ -117,7 +117,7 @@
>
> };
>
>
>
> _host {
>
> - status = "disabled";
>
> + phy-supply = <_5v>;
>
>
> This does not match upstream linux device tree file. If this change is
> needed please submit a change to linux kernel, else make a U-Boot
> specific change in rk3399-nanopi-r4s-u-boot.dtsi.
>
I tested your patch (without this change) and it does result in the same
crash:
Bus usb@fe38: USB EHCI 1.00
Bus usb@fe3c: "Synchronous Abort" handler, esr 0x9610, far 0x0
elr: 00241c7c lr : 00241c68 (reloc)
elr: f3f72c7c lr : f3f72c68
x0 : x1 : 7d08
x2 : 7d0c x3 : 7d40
x4 : f6c4 x5 : 00010ab0
x6 : 7d0c x7 : f1f182e0
x8 : 7d08 x9 : f1f179dc
x10: 0002 x11: 7c8c
x12: f1f17aac x13: f1f182e0
x14: 0002 x15: f1f17684
x16: f3f71b94 x17: 409ff249
x18: f1f28da0 x19: f1f5b2a0
x20: x21: f1f5b100
x22: f1f5b280 x23: f1f5b290
x24: f1f5b2a0 x25:
x26: f3fd2d3d x27: 0001
x28: x29: f1f17ac0
While this change should probably be upstreamed to the linux device tree
file, I think we need something more immediate to prevent this crash/boot
loop once your change lands.
Do you prefer to incorporate this change into your patch or do you want me
to update this patch?
Thanks,
Justin
> Regards,
> Jonas
>
> };
>
>
>
> {
>
> diff --git a/configs/nanopi-r4s-rk3399_defconfig
> b/configs/nanopi-r4s-rk3399_defconfig
>
> index ea01d323541..d8c34dc48cb 100644
>
> --- a/configs/nanopi-r4s-rk3399_defconfig
>
> +++ b/configs/nanopi-r4s-rk3399_defconfig
>
> @@ -5,6 +5,7 @@ CONFIG_ARCH_ROCKCHIP=y
>
> CONFIG_NR_DRAM_BANKS=1
>
> CONFIG_ENV_OFFSET=0x3F8000
>
> CONFIG_DEFAULT_DEVICE_TREE="rk3399-nanopi-r4s"
>
> +CONFIG_DM_RESET=y
>
> CONFIG_ROCKCHIP_RK3399=y
>
> CONFIG_TARGET_EVB_RK3399=y
>
> CONFIG_DEBUG_UART_BASE=0xFF1A
>
> @@ -36,6 +37,8 @@ CONFIG_MMC_SDHCI=y
>
> CONFIG_MMC_SDHCI_ROCKCHIP=y
>
>
Re: [PATCH] ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM
On 4/18/24 6:21 PM, Tim Harvey wrote:
On Fri, Jan 19, 2024 at 4:36 PM Marek Vasut wrote:
Linux 6.6.y with KASLR enabled would print the following message on boot:
"
KASLR disabled due to lack of seed
"
Enable the 'kaslrseed' command so a random number seed can be pulled
from CAAM and inserted into the /chosen node 'kaslr-seed' property of
Linux kernel DT before boot, thus letting KASLR work properly.
Signed-off-by: Marek Vasut
---
Cc: Fabio Estevam
Cc: Stefano Babic
Cc: u-b...@dh-electronics.com
---
configs/imx8mp_dhcom_pdk2_defconfig | 2 ++
configs/imx8mp_dhcom_pdk3_defconfig | 2 ++
2 files changed, 4 insertions(+)
diff --git a/configs/imx8mp_dhcom_pdk2_defconfig
b/configs/imx8mp_dhcom_pdk2_defconfig
index 4f907ce00d0..23fb6272ad5 100644
--- a/configs/imx8mp_dhcom_pdk2_defconfig
+++ b/configs/imx8mp_dhcom_pdk2_defconfig
@@ -117,6 +117,7 @@ CONFIG_CMD_BOOTCOUNT=y
CONFIG_CMD_CACHE=y
CONFIG_CMD_TIME=y
CONFIG_CMD_GETTIME=y
+CONFIG_CMD_KASLRSEED=y
CONFIG_CMD_SYSBOOT=y
CONFIG_CMD_UUID=y
CONFIG_CMD_PMIC=y
@@ -223,6 +224,7 @@ CONFIG_DM_REGULATOR_PCA9450=y
CONFIG_SPL_DM_REGULATOR_PCA9450=y
CONFIG_DM_REGULATOR_FIXED=y
CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_DM_RNG=y
CONFIG_DM_RTC=y
CONFIG_RTC_M41T62=y
CONFIG_CONS_INDEX=2
diff --git a/configs/imx8mp_dhcom_pdk3_defconfig
b/configs/imx8mp_dhcom_pdk3_defconfig
index 9972e2d96b6..0d47c12b1f9 100644
--- a/configs/imx8mp_dhcom_pdk3_defconfig
+++ b/configs/imx8mp_dhcom_pdk3_defconfig
@@ -119,6 +119,7 @@ CONFIG_CMD_BOOTCOUNT=y
CONFIG_CMD_CACHE=y
CONFIG_CMD_TIME=y
CONFIG_CMD_GETTIME=y
+CONFIG_CMD_KASLRSEED=y
CONFIG_CMD_SYSBOOT=y
CONFIG_CMD_UUID=y
CONFIG_CMD_PMIC=y
@@ -228,6 +229,7 @@ CONFIG_DM_REGULATOR_PCA9450=y
CONFIG_SPL_DM_REGULATOR_PCA9450=y
CONFIG_DM_REGULATOR_FIXED=y
CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_DM_RNG=y
CONFIG_DM_RTC=y
CONFIG_RTC_M41T62=y
CONFIG_CONS_INDEX=2
--
2.43.0
Hi Marek,
Sorry to respond to an old thread but I ran across this when enabling
KALSR on my boards.
I have noticed when you enable DM_RNG on IMX8M that SPL fails to bind
the driver:
Couldn't bind rng driver (-96)
SEC0: RNG instantiated
sec_init failed!
Did you enable CAAM and ARCH_MISC_INIT on your machine, to initialize
CAAM in SPL ?
Didn't you encounter this as well? It seems to me that we may need to
add the ability to disable DM_RNG in the SPL unless I'm missing
something.
No, but see above, I suspect that might be it, see also
1f908b1898bd ("ARM: imx8m: Deduplicate CAAM init with arch_misc_init()
call")
[PATCH 9/9] qcom_defconfig: generate SMBIOS tables
EFI initialisation fails without this, and with proper SMBIOS v3 support in (and automatic generation of useful tables) there's no reason for us not to do this on qcom platforms. Signed-off-by: Caleb Connolly --- configs/qcom_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig index 41545fd72fcc..7919aeb9755d 100644 --- a/configs/qcom_defconfig +++ b/configs/qcom_defconfig @@ -104,6 +104,6 @@ CONFIG_VIDEO_FONT_16X32=y CONFIG_SYS_WHITE_ON_BLACK=y CONFIG_NO_FB_CLEAR=y CONFIG_VIDEO_SIMPLE=y CONFIG_HEXDUMP=y -# CONFIG_GENERATE_SMBIOS_TABLE is not set +CONFIG_GENERATE_SMBIOS_TABLE=y CONFIG_LMB_MAX_REGIONS=64 -- 2.44.0
[PATCH 8/9] qcom_defconfig: define safe default SYS_LOAD_ADDR
Defining this as 0 results in bootm causing a null pointer exception... Define it at a safe default which is valid RAM on most qcom boards. Signed-off-by: Caleb Connolly --- configs/qcom_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig index 209a7ba324d0..41545fd72fcc 100644 --- a/configs/qcom_defconfig +++ b/configs/qcom_defconfig @@ -2,9 +2,9 @@ CONFIG_ARM=y CONFIG_SKIP_LOWLEVEL_INIT=y CONFIG_POSITION_INDEPENDENT=y CONFIG_ARCH_SNAPDRAGON=y CONFIG_DEFAULT_DEVICE_TREE="qcom/sdm845-db845c" -CONFIG_SYS_LOAD_ADDR=0x0 +CONFIG_SYS_LOAD_ADDR=0xA000 CONFIG_SYS_INIT_SP_BSS_OFFSET=1572864 CONFIG_BUTTON_CMD=y CONFIG_FIT=y CONFIG_FIT_VERBOSE=y -- 2.44.0
[PATCH 7/9] qcom_defconfig: enable OF_BOARD_SETUP
Use our new ft_board_setup(). Signed-off-by: Caleb Connolly --- configs/qcom_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig index 7b589f0bf7a7..209a7ba324d0 100644 --- a/configs/qcom_defconfig +++ b/configs/qcom_defconfig @@ -33,8 +33,9 @@ CONFIG_CMD_USB=y CONFIG_CMD_CAT=y CONFIG_CMD_BMP=y CONFIG_CMD_LOG=y CONFIG_OF_LIVE=y +CONFIG_OF_BOARD_SETUP=y CONFIG_BUTTON_QCOM_PMIC=y CONFIG_CLK=y CONFIG_CLK_QCOM_QCM2290=y CONFIG_CLK_QCOM_QCS404=y -- 2.44.0
[PATCH 6/9] mach-snapdragon: implement ft_board_setup() for USB role selection
Some Qualcomm boards have only one USB controller which is muxed between
the type-c port and an internal USB hub for type-A and ethernet. We
modify the DT for these to force them to host mode in U-Boot. However in
Linux DRD role switching is supported (required, even). Use
ft_board_setup() to adjust the dr_mode property for these boards.
While we're here, define pr_fmt for this file so we can more easily
identify log messages.
Signed-off-by: Caleb Connolly
---
arch/arm/mach-snapdragon/of_fixup.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/mach-snapdragon/of_fixup.c
b/arch/arm/mach-snapdragon/of_fixup.c
index 3f7ac227bd09..55368dd43b66 100644
--- a/arch/arm/mach-snapdragon/of_fixup.c
+++ b/arch/arm/mach-snapdragon/of_fixup.c
@@ -16,8 +16,10 @@
* Copyright (c) 2024 Linaro Ltd.
* Author: Caleb Connolly
*/
+#define pr_fmt(fmt) "of_fixup: " fmt
+
#include
#include
#include
#include
@@ -152,4 +154,22 @@ void qcom_of_fixup_nodes(void)
{
time_call(fixup_usb_nodes);
time_call(fixup_power_domains);
}
+
+int ft_board_setup(void *blob, struct bd_info __maybe_unused *bd)
+{
+ struct fdt_header *fdt = blob;
+ int node;
+
+ /* We only want to do this fix-up for the RB1 board, quick return for
all others */
+ if (!fdt_node_check_compatible(fdt, 0, "qcom,qrb4210-rb2"))
+ return 0;
+
+ fdt_for_each_node_by_compatible(node, blob, 0, "snps,dwc3") {
+ log_debug("%s: Setting 'dr_mode' to OTG\n", fdt_get_name(blob,
node, NULL));
+ fdt_setprop_string(fdt, node, "dr_mode", "otg");
+ break;
+ }
+
+ return 0;
+}
--
2.44.0
[PATCH 5/9] arm: dts: qrb4210-rb2-u-boot: add u-boot fixups
Add a fixup to force dr_mode to host for U-Boot.
Signed-off-by: Caleb Connolly
---
arch/arm/dts/qrb4210-rb2-u-boot.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/dts/qrb4210-rb2-u-boot.dtsi
b/arch/arm/dts/qrb4210-rb2-u-boot.dtsi
new file mode 100644
index ..7d1375f38c44
--- /dev/null
+++ b/arch/arm/dts/qrb4210-rb2-u-boot.dtsi
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/* This is usually OTG but U-Boot doesn't support that properly */
+_dwc3 {
+ dr_mode = "host";
+};
--
2.44.0
[PATCH 4/9] phy: qcom: snps-femto-v2: drop clocks
There is a clock associated with this phy, but it's always from the
rpmhcc and isn't actually needed for the hardware to work.
Drop all the clock handling from the driver.
Signed-off-by: Caleb Connolly
---
drivers/phy/qcom/phy-qcom-snps-femto-v2.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/phy/qcom/phy-qcom-snps-femto-v2.c
b/drivers/phy/qcom/phy-qcom-snps-femto-v2.c
index a1675b664e46..04f0f0e7817d 100644
--- a/drivers/phy/qcom/phy-qcom-snps-femto-v2.c
+++ b/drivers/phy/qcom/phy-qcom-snps-femto-v2.c
@@ -5,10 +5,8 @@
*
* Based on Linux driver
*/
-#include
-#include
#include
#include
#include
#include
@@ -16,9 +14,8 @@
#include
#include
#include
-#include
#include
#include
#define USB2_PHY_USB_PHY_UTMI_CTRL0 (0x3c)
@@ -61,9 +58,8 @@
#define REFCLK_SEL_DEFAULT (0x2 << 0)
struct qcom_snps_hsphy {
void __iomem *base;
- struct clk_bulk clks;
struct reset_ctl_bulk resets;
};
/*
@@ -142,10 +138,8 @@ static int qcom_snps_hsphy_power_on(struct phy *phy)
{
struct qcom_snps_hsphy *priv = dev_get_priv(phy->dev);
int ret;
- clk_enable_bulk(>clks);
-
ret = reset_deassert_bulk(>resets);
if (ret)
return ret;
@@ -160,9 +154,8 @@ static int qcom_snps_hsphy_power_off(struct phy *phy)
{
struct qcom_snps_hsphy *priv = dev_get_priv(phy->dev);
reset_assert_bulk(>resets);
- clk_disable_bulk(>clks);
return 0;
}
@@ -174,21 +167,14 @@ static int qcom_snps_hsphy_phy_probe(struct udevice *dev)
priv->base = dev_read_addr_ptr(dev);
if (IS_ERR(priv->base))
return PTR_ERR(priv->base);
- ret = clk_get_bulk(dev, >clks);
- if (ret < 0 && ret != -ENOENT) {
- printf("%s: Failed to get clocks %d\n", __func__, ret);
- return ret;
- }
-
ret = reset_get_bulk(dev, >resets);
if (ret < 0) {
printf("failed to get resets, ret = %d\n", ret);
return ret;
}
- clk_enable_bulk(>clks);
reset_deassert_bulk(>resets);
return 0;
}
--
2.44.0
[PATCH 3/9] iommu: qcom-smmu: add qcom generic compatible
With the exception of SDM845, most other Qualcomm SoCs have the Qualcomm
specific (but not SoC) specific SMMU compatible string. Add it here so
we can match those without having to add individual SoCs to the list
here.
Signed-off-by: Caleb Connolly
---
drivers/iommu/qcom-hyp-smmu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/qcom-hyp-smmu.c b/drivers/iommu/qcom-hyp-smmu.c
index f2b39de56f4a..7b646d840dd4 100644
--- a/drivers/iommu/qcom-hyp-smmu.c
+++ b/drivers/iommu/qcom-hyp-smmu.c
@@ -380,8 +380,9 @@ static struct iommu_ops qcom_smmu_ops = {
};
static const struct udevice_id qcom_smmu500_ids[] = {
{ .compatible = "qcom,sdm845-smmu-500" },
+ { .compatible = "qcom,smmu-500", },
{ /* sentinel */ }
};
U_BOOT_DRIVER(qcom_smmu500) = {
--
2.44.0
[PATCH 2/9] gpio: qcom_pmic: add pm8150l
This is used for the volume keys on some SM8150/SM8250 devices.
Signed-off-by: Caleb Connolly
---
drivers/gpio/qcom_pmic_gpio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/qcom_pmic_gpio.c b/drivers/gpio/qcom_pmic_gpio.c
index 362d98dbf8cb..0dd3434e9e04 100644
--- a/drivers/gpio/qcom_pmic_gpio.c
+++ b/drivers/gpio/qcom_pmic_gpio.c
@@ -364,8 +364,9 @@ static const struct udevice_id qcom_gpio_ids[] = {
{ .compatible = "qcom,pm8994-gpio" }, /* 22 GPIO's */
{ .compatible = "qcom,pm8998-gpio", .data = QCOM_PMIC_QUIRK_READONLY },
{ .compatible = "qcom,pms405-gpio" },
{ .compatible = "qcom,pm6125-gpio", .data = QCOM_PMIC_QUIRK_READONLY },
+ { .compatible = "qcom,pm8150-gpio", .data = QCOM_PMIC_QUIRK_READONLY },
{ .compatible = "qcom,pm8550-gpio", .data = QCOM_PMIC_QUIRK_READONLY },
{ }
};
--
2.44.0
[PATCH 1/9] gpio: qcom_pmic: add pm6125
As with some other modern PMICs, writing to the GPIOs seems to make the
device reset.
Signed-off-by: Caleb Connolly
---
drivers/gpio/qcom_pmic_gpio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/qcom_pmic_gpio.c b/drivers/gpio/qcom_pmic_gpio.c
index dfb70faf94b4..362d98dbf8cb 100644
--- a/drivers/gpio/qcom_pmic_gpio.c
+++ b/drivers/gpio/qcom_pmic_gpio.c
@@ -363,8 +363,9 @@ static const struct udevice_id qcom_gpio_ids[] = {
{ .compatible = "qcom,pm8916-gpio" },
{ .compatible = "qcom,pm8994-gpio" }, /* 22 GPIO's */
{ .compatible = "qcom,pm8998-gpio", .data = QCOM_PMIC_QUIRK_READONLY },
{ .compatible = "qcom,pms405-gpio" },
+ { .compatible = "qcom,pm6125-gpio", .data = QCOM_PMIC_QUIRK_READONLY },
{ .compatible = "qcom,pm8550-gpio", .data = QCOM_PMIC_QUIRK_READONLY },
{ }
};
--
2.44.0
[PATCH 0/9] qcom: RBx fixes and USB support
This series is a few loosely connected patches to get the RB1 and 2 boards booting from USB with upstream U-Boot, and a few preperatory patches for rb5. Unfortunately the RB5 board requires a regulator on the RPMh peripheral to be turned on for the USB VBUS rail. Support for this will be added in future patches. * Add a few missing compatible strings for sm6115/sm8250 * Fix the femto-v2 HS USB phy used on sm8250 * Fix USB role selection on RB2 (without breaking Linux!) * Pick a value for CONFIG_SYS_LOAD_ADDR that won't cause a null pointer on most boards * Fix EFI booting by generating SMBIOS tables --- Caleb Connolly (9): gpio: qcom_pmic: add pm6125 gpio: qcom_pmic: add pm8150l iommu: qcom-smmu: add qcom generic compatible phy: qcom: snps-femto-v2: drop clocks arm: dts: qrb4210-rb2-u-boot: add u-boot fixups mach-snapdragon: implement ft_board_setup() for USB role selection qcom_defconfig: enable OF_BOARD_SETUP qcom_defconfig: define safe default SYS_LOAD_ADDR qcom_defconfig: generate SMBIOS tables arch/arm/dts/qrb4210-rb2-u-boot.dtsi | 6 ++ arch/arm/mach-snapdragon/of_fixup.c | 20 configs/qcom_defconfig| 5 +++-- drivers/gpio/qcom_pmic_gpio.c | 2 ++ drivers/iommu/qcom-hyp-smmu.c | 1 + drivers/phy/qcom/phy-qcom-snps-femto-v2.c | 14 -- 6 files changed, 32 insertions(+), 16 deletions(-) --- base-commit: d5460b082cd6afd0e07c0ec0e5a82d1af8dc09f7 // Caleb (they/them)
[PATCH 3/3] qcom_defconfig: set SYS_INIT_SP_BSS_OFFSET
Give us lots of room for the appended FDT. Signed-off-by: Caleb Connolly --- configs/qcom_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig index 218a9a769682..7b589f0bf7a7 100644 --- a/configs/qcom_defconfig +++ b/configs/qcom_defconfig @@ -3,8 +3,9 @@ CONFIG_SKIP_LOWLEVEL_INIT=y CONFIG_POSITION_INDEPENDENT=y CONFIG_ARCH_SNAPDRAGON=y CONFIG_DEFAULT_DEVICE_TREE="qcom/sdm845-db845c" CONFIG_SYS_LOAD_ADDR=0x0 +CONFIG_SYS_INIT_SP_BSS_OFFSET=1572864 CONFIG_BUTTON_CMD=y CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_BOOTSTD_FULL=y -- 2.44.0
[PATCH 1/3] mach-snapdragon: use OF_UPSTREAM
Switch to using upstream DT from dts/upstream. Signed-off-by: Caleb Connolly --- MAINTAINERS | 4 arch/arm/Kconfig | 1 + configs/dragonboard410c_defconfig | 2 +- configs/dragonboard820c_defconfig | 2 +- configs/qcom_defconfig| 2 +- 5 files changed, 4 insertions(+), 7 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index c0d2b5138fca..d0a4a28b401d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -605,12 +605,8 @@ M: Neil Armstrong R: Sumit Garg L: u-boot-q...@groups.io S: Maintained T: git https://source.denx.de/u-boot/custodians/u-boot-snapdragon.git -F: arch/arm/dts/msm8*.dtsi -F: arch/arm/dts/pm8???.dtsi -F: arch/arm/dts/pms405.dtsi -F: arch/arm/dts/sdm845.dtsi F: drivers/*/*/pm8???-* F: drivers/gpio/msm_gpio.c F: drivers/mmc/msm_sdhci.c F: drivers/phy/msm8916-usbh-phy.c diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 23ee25269a24..2931c82eb11f 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1088,8 +1088,9 @@ config ARCH_SNAPDRAGON select BOARD_LATE_INIT select OF_BOARD select SAVE_PREV_BL_FDT_ADDR select LINUX_KERNEL_IMAGE_HEADER + imply OF_UPSTREAM imply CMD_DM config ARCH_SOCFPGA bool "Altera SOCFPGA family" diff --git a/configs/dragonboard410c_defconfig b/configs/dragonboard410c_defconfig index 260a8349d3b2..9ef04fd45546 100644 --- a/configs/dragonboard410c_defconfig +++ b/configs/dragonboard410c_defconfig @@ -8,9 +8,9 @@ CONFIG_SYS_MALLOC_LEN=0x802000 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8007fff0 CONFIG_ENV_SIZE=0x2000 CONFIG_ENV_OFFSET=0x0 -CONFIG_DEFAULT_DEVICE_TREE="apq8016-sbc" +CONFIG_DEFAULT_DEVICE_TREE="qcom/apq8016-sbc" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_IDENT_STRING="\nQualcomm-DragonBoard 410C" CONFIG_SYS_LOAD_ADDR=0x8008 CONFIG_REMAKE_ELF=y diff --git a/configs/dragonboard820c_defconfig b/configs/dragonboard820c_defconfig index ebc80eb2a464..f6b2cb09ba31 100644 --- a/configs/dragonboard820c_defconfig +++ b/configs/dragonboard820c_defconfig @@ -6,9 +6,9 @@ CONFIG_TEXT_BASE=0x8008 CONFIG_SYS_MALLOC_LEN=0x804000 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8007fff0 CONFIG_ENV_SIZE=0x4000 -CONFIG_DEFAULT_DEVICE_TREE="apq8096-db820c" +CONFIG_DEFAULT_DEVICE_TREE="qcom/apq8096-db820c" CONFIG_IDENT_STRING="\nQualcomm-DragonBoard 820C" CONFIG_SYS_LOAD_ADDR=0x8008 CONFIG_DISTRO_DEFAULTS=y CONFIG_USE_BOOTARGS=y diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig index ee3ed89cbc8a..218a9a769682 100644 --- a/configs/qcom_defconfig +++ b/configs/qcom_defconfig @@ -1,9 +1,9 @@ CONFIG_ARM=y CONFIG_SKIP_LOWLEVEL_INIT=y CONFIG_POSITION_INDEPENDENT=y CONFIG_ARCH_SNAPDRAGON=y -CONFIG_DEFAULT_DEVICE_TREE="sdm845-db845c" +CONFIG_DEFAULT_DEVICE_TREE="qcom/sdm845-db845c" CONFIG_SYS_LOAD_ADDR=0x0 CONFIG_BUTTON_CMD=y CONFIG_FIT=y CONFIG_FIT_VERBOSE=y -- 2.44.0
[PATCH 0/3] qcom: switch to OF_UPSTREAM
This series does the initial switch to OF_UPSTREAM for Qualcomm platforms. The DT files we have in U-Boot are outdated by now, so drop them and move to upstream. Patch 2 drops all the Qualcomm dts files that are now provided in dts/upstream. As some of the files exceed the 100k size limit by themselves I thought it would be easier to just lump them together rather than trying to split them up. The associated qcom headers will be cleaned up in future patches. --- Caleb Connolly (3): mach-snapdragon: use OF_UPSTREAM arm: dts: drop qcom dts files qcom_defconfig: set SYS_INIT_SP_BSS_OFFSET MAINTAINERS |4 - arch/arm/Kconfig|1 + arch/arm/dts/apq8016-sbc.dts| 729 arch/arm/dts/apq8096-db820c.dts | 1137 -- arch/arm/dts/msm8916-pm8916.dtsi| 157 - arch/arm/dts/msm8916.dtsi | 2702 - arch/arm/dts/msm8996.dtsi | 3884 -- arch/arm/dts/pm8916.dtsi| 178 - arch/arm/dts/pm8994.dtsi| 152 - arch/arm/dts/pm8998.dtsi| 130 - arch/arm/dts/pmi8994.dtsi | 65 - arch/arm/dts/pmi8998.dtsi | 98 - arch/arm/dts/pms405.dtsi| 149 - arch/arm/dts/qcs404-evb-4000.dts| 96 - arch/arm/dts/qcs404-evb.dtsi| 389 -- arch/arm/dts/qcs404.dtsi| 1829 - arch/arm/dts/sdm845-db845c.dts | 1190 -- arch/arm/dts/sdm845-samsung-starqltechn.dts | 460 --- arch/arm/dts/sdm845-wcd9340.dtsi| 86 - arch/arm/dts/sdm845.dtsi| 5752 --- configs/dragonboard410c_defconfig |2 +- configs/dragonboard820c_defconfig |2 +- configs/qcom_defconfig |3 +- 23 files changed, 5 insertions(+), 19190 deletions(-) --- base-commit: d5460b082cd6afd0e07c0ec0e5a82d1af8dc09f7 // Caleb (they/them)
Pull request for tpm-master-18042024
OP-TEE fixes only on this PR, no TPM related ones.
The following changes since commit 2c3fa4b8add3cb6a440184ab67debc6867d383c0:
sandbox: don't call os_close with invalid file descriptor (2024-04-17
17:06:16 -0600)
are available in the Git repository at:
https://source.denx.de/u-boot/custodians/u-boot-tpm/ tags/tpm-master-18042024
for you to fetch changes up to b905599b36e3d8158c5cd045c26278416909b422:
tee: remove common.h inclusion (2024-04-18 16:04:48 +0300)
Igor says:
"The problem initially was in the TEE sandbox driver implementation
(drivers/tee/sandbox.c) and it's limitations, which doesn't
permit to have multiple simultaneous sessions with different TAs.
This is what actually happened in this CI run [1], firstly "optee_rpmb"
cmd was executed (and after execution we had one session open), and
then "scp03", which also makes calls to OP-TEE, however it fails
in sandbox_tee_open_session() because of this check:
if (state->ta) {
printf("A session is already open\n");
return -EBUSY;
}
I had two ways in mind to address that:
1. Close a session on each optee_rpmb cmd invocation.
I don't see any reason to keep this session open, as obviously
there is no other mechanism (tbh, I don't know if DM calls ".remove" for active
devices) to close it automatically before handing over control to
Linux kernel. As a result we might end up with some orphaned sessions
registered in OP-TEE OS core (obvious resource leak).
2. Extend TEE sandbox driver, add support for multiple
simultaneous sessions just to handle the case.
I've chosen the first approach, as IMO it was "kill two birds with one stone",
I could address resource leak in OP-TEE and bypass limitations of
TEE sandbox driver."
Link:
https://lore.kernel.org/u-boot/CAByghJZVRbnFUwJdgU534tvGA+DX2pArf0i7ySik=brxgad...@mail.gmail.com/
The CI https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/20414
showed no problems
Please pull
/Ilias
optee fixes and cleanups
Igor Opaniuk (5):
tee: optee: fix description in Kconfig
cmd: optee_rpmb: close tee session
cmd: optee_rpmb: build cmd for sandbox
test: py: add optee_rpmb tests
tee: remove common.h inclusion
cmd/Kconfig| 4 +++-
cmd/optee_rpmb.c | 23 +--
drivers/tee/broadcom/chimp_optee.c | 3 ++-
drivers/tee/optee/Kconfig | 2 +-
drivers/tee/optee/core.c | 1 -
drivers/tee/optee/i2c.c| 1 -
drivers/tee/optee/rpmb.c | 1 -
drivers/tee/optee/supplicant.c | 2 +-
drivers/tee/sandbox.c | 2 +-
drivers/tee/tee-uclass.c | 1 -
test/py/tests/test_optee_rpmb.py | 20
11 files changed, 45 insertions(+), 15 deletions(-)
create mode 100644 test/py/tests/test_optee_rpmb.py
Re: [PATCH v3 3/4] efi_loader: add an EFI variable with the file contents
On Thu, 18 Apr 2024 at 19:15, Heinrich Schuchardt wrote: > > On 18.04.24 17:59, Ilias Apalodimas wrote: > > On Thu, 18 Apr 2024 at 18:42, Heinrich Schuchardt > > wrote: > >> > >> On 18.04.24 17:36, Ilias Apalodimas wrote: > >>> Hi Mark, > >>> > >>> On Thu, 18 Apr 2024 at 18:15, Mark Kettenis > >>> wrote: > > > From: Ilias Apalodimas > > Date: Thu, 18 Apr 2024 15:54:52 +0300 > > Hi Illias, > > > > > Previous patches enabled SetVariableRT using a RAM backend. > > Although EBBR [0] defines a variable format we can teach userspace tools > > and write the altered variables, it's better if we skip the ABI > > requirements completely. > > > > So let's add a new variable, in its own namespace called "VarToFile" > > which contains a binary dump of the updated RT, BS and, NV variables > > and will be updated when GetVariable is called. > > > > Some adjustments are needed to do that. > > Currently we discard BS-only variables in EBS(). We need to preserve > > those on the RAM backend that exposes the variables. Since BS-only > > variables can't appear at runtime we need to move the memory masking > > checks from efi_var_collect() to efi_get_next_variable_name_mem()/ > > efi_get_variable_mem() and do the filtering at runtime. > > > > We also need an efi_var_collect() variant available at runtime, in order > > to construct the "VarToFile" buffer on the fly. > > > > All users and applications (for linux) have to do when updating a > > variable > > is dd that variable in the file described by "RTStorageVolatile". > > I simehow missed your reply to the issue I raised with picking the > right ESP to write variables back to. > >>> > >>> No worries, I did send v3 quickly myself... > >>> > I'm not convinced that the ESP > that was used to install Linux on is necessarily th right one. In > particular, consider a system with multiple disks, say eMMC and an > NVMe disk. Suppose U-Boot is installed on eMMC and picks the ESP on > that disk to store the EFI variables. > >>> > >>> And who creates ESP on the eMMC? I assume you have one OS installed in > >>> the eMMC and another one in the nvme? > >> > >> E.g. you have a naked NVMe. At first boot there will be an ESP on the > >> installation medium. The installer may create an ESP on the NVMe drive > >> and put GRUB there. > >> > >> Later the user will typically remove the installation module if U-Boot > >> is on SPI flash. > >> > >> U-Boot has no chance to know this beforehand. > >> > >> Best regards > > > > Ok thanks, Heinrich, as you mentioned offline that's what the Ubuntu > > installer does. > > In this case again, neither the DP nor the relative path directly > > solves the problem, since that second ESP doesn't exist to begin with. > > > > Can we get some more info on the installer? When it tries to write > > Boot which ESP is mounted? The 'installer' one or the newly > > created one in the NVME? Because if it's the latter things should > > work. > > The ESP on the NVMe is mounted at /boot/efi. This is where GRUB is > installed as (/boot/efi)/EFI/ubuntu/grubriscv64.efi. Yes but if I understand you correctly the installer will work just fine. Let me try and describe the process in case we are missing something - The installer starts from a USB and contains an ESP which is mounted if I understand you correctly - The installation creates a new ESP - Once the installation is about to end, the new ESP is mounted and grub/shim is copied over. At that point, it will also try to set Boot pointting to shim. But the installer *knows* which ESP it mounted, so it can use that partition to write the updated ubootefi.var Thanks /Ilias > > Best regards > > Heinrich > > >> > >>> > Now I install Linux on the NVMe > disk, which creates an ESP to store its bootloader. With your > proposed changes, Linux will probably end up writing the variables to > the ESP on the NVMe. Now you reboot and U-Boot still reads the EFI > variables from eMMC and you've lost any changes... > >>> > >>> I understand the problem, but my concern is that using a DP just > >>> delegates the problem -- it doesn't solve it. > >>> > >>> To use the 'correct' partition, U-Boot has to *decide* which ESP is > >>> going to be used and inject it in RTVolatileStorage. > >>> But if U-Boot decides about the 'correct' ESP the relative path would > >>> work as well. So what's needed here is a mechanism to correlate the > >>> booted OS with the ESP it will use and force the variable loading from > >>> that file. Am I missing anything? > >>> > >>> /Ilias > > > Linux efivarfs uses a first 4 bytes of the output to represent > > attributes > > in little-endian format. So, storing variables works like this: > > > > $~ efibootmgr -n 0001 > > $~ dd > >
Re: [PATCH] ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM
On Fri, Jan 19, 2024 at 4:36 PM Marek Vasut wrote: > > Linux 6.6.y with KASLR enabled would print the following message on boot: > " > KASLR disabled due to lack of seed > " > Enable the 'kaslrseed' command so a random number seed can be pulled > from CAAM and inserted into the /chosen node 'kaslr-seed' property of > Linux kernel DT before boot, thus letting KASLR work properly. > > Signed-off-by: Marek Vasut > --- > Cc: Fabio Estevam > Cc: Stefano Babic > Cc: u-b...@dh-electronics.com > --- > configs/imx8mp_dhcom_pdk2_defconfig | 2 ++ > configs/imx8mp_dhcom_pdk3_defconfig | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/configs/imx8mp_dhcom_pdk2_defconfig > b/configs/imx8mp_dhcom_pdk2_defconfig > index 4f907ce00d0..23fb6272ad5 100644 > --- a/configs/imx8mp_dhcom_pdk2_defconfig > +++ b/configs/imx8mp_dhcom_pdk2_defconfig > @@ -117,6 +117,7 @@ CONFIG_CMD_BOOTCOUNT=y > CONFIG_CMD_CACHE=y > CONFIG_CMD_TIME=y > CONFIG_CMD_GETTIME=y > +CONFIG_CMD_KASLRSEED=y > CONFIG_CMD_SYSBOOT=y > CONFIG_CMD_UUID=y > CONFIG_CMD_PMIC=y > @@ -223,6 +224,7 @@ CONFIG_DM_REGULATOR_PCA9450=y > CONFIG_SPL_DM_REGULATOR_PCA9450=y > CONFIG_DM_REGULATOR_FIXED=y > CONFIG_DM_REGULATOR_GPIO=y > +CONFIG_DM_RNG=y > CONFIG_DM_RTC=y > CONFIG_RTC_M41T62=y > CONFIG_CONS_INDEX=2 > diff --git a/configs/imx8mp_dhcom_pdk3_defconfig > b/configs/imx8mp_dhcom_pdk3_defconfig > index 9972e2d96b6..0d47c12b1f9 100644 > --- a/configs/imx8mp_dhcom_pdk3_defconfig > +++ b/configs/imx8mp_dhcom_pdk3_defconfig > @@ -119,6 +119,7 @@ CONFIG_CMD_BOOTCOUNT=y > CONFIG_CMD_CACHE=y > CONFIG_CMD_TIME=y > CONFIG_CMD_GETTIME=y > +CONFIG_CMD_KASLRSEED=y > CONFIG_CMD_SYSBOOT=y > CONFIG_CMD_UUID=y > CONFIG_CMD_PMIC=y > @@ -228,6 +229,7 @@ CONFIG_DM_REGULATOR_PCA9450=y > CONFIG_SPL_DM_REGULATOR_PCA9450=y > CONFIG_DM_REGULATOR_FIXED=y > CONFIG_DM_REGULATOR_GPIO=y > +CONFIG_DM_RNG=y > CONFIG_DM_RTC=y > CONFIG_RTC_M41T62=y > CONFIG_CONS_INDEX=2 > -- > 2.43.0 > Hi Marek, Sorry to respond to an old thread but I ran across this when enabling KALSR on my boards. I have noticed when you enable DM_RNG on IMX8M that SPL fails to bind the driver: Couldn't bind rng driver (-96) SEC0: RNG instantiated sec_init failed! Didn't you encounter this as well? It seems to me that we may need to add the ability to disable DM_RNG in the SPL unless I'm missing something. Best Regards, Tim
Re: [PATCH v3 3/4] efi_loader: add an EFI variable with the file contents
On 18.04.24 17:59, Ilias Apalodimas wrote: On Thu, 18 Apr 2024 at 18:42, Heinrich Schuchardt wrote: On 18.04.24 17:36, Ilias Apalodimas wrote: Hi Mark, On Thu, 18 Apr 2024 at 18:15, Mark Kettenis wrote: From: Ilias Apalodimas Date: Thu, 18 Apr 2024 15:54:52 +0300 Hi Illias, Previous patches enabled SetVariableRT using a RAM backend. Although EBBR [0] defines a variable format we can teach userspace tools and write the altered variables, it's better if we skip the ABI requirements completely. So let's add a new variable, in its own namespace called "VarToFile" which contains a binary dump of the updated RT, BS and, NV variables and will be updated when GetVariable is called. Some adjustments are needed to do that. Currently we discard BS-only variables in EBS(). We need to preserve those on the RAM backend that exposes the variables. Since BS-only variables can't appear at runtime we need to move the memory masking checks from efi_var_collect() to efi_get_next_variable_name_mem()/ efi_get_variable_mem() and do the filtering at runtime. We also need an efi_var_collect() variant available at runtime, in order to construct the "VarToFile" buffer on the fly. All users and applications (for linux) have to do when updating a variable is dd that variable in the file described by "RTStorageVolatile". I simehow missed your reply to the issue I raised with picking the right ESP to write variables back to. No worries, I did send v3 quickly myself... I'm not convinced that the ESP that was used to install Linux on is necessarily th right one. In particular, consider a system with multiple disks, say eMMC and an NVMe disk. Suppose U-Boot is installed on eMMC and picks the ESP on that disk to store the EFI variables. And who creates ESP on the eMMC? I assume you have one OS installed in the eMMC and another one in the nvme? E.g. you have a naked NVMe. At first boot there will be an ESP on the installation medium. The installer may create an ESP on the NVMe drive and put GRUB there. Later the user will typically remove the installation module if U-Boot is on SPI flash. U-Boot has no chance to know this beforehand. Best regards Ok thanks, Heinrich, as you mentioned offline that's what the Ubuntu installer does. In this case again, neither the DP nor the relative path directly solves the problem, since that second ESP doesn't exist to begin with. Can we get some more info on the installer? When it tries to write Boot which ESP is mounted? The 'installer' one or the newly created one in the NVME? Because if it's the latter things should work. The ESP on the NVMe is mounted at /boot/efi. This is where GRUB is installed as (/boot/efi)/EFI/ubuntu/grubriscv64.efi. Best regards Heinrich Now I install Linux on the NVMe disk, which creates an ESP to store its bootloader. With your proposed changes, Linux will probably end up writing the variables to the ESP on the NVMe. Now you reboot and U-Boot still reads the EFI variables from eMMC and you've lost any changes... I understand the problem, but my concern is that using a DP just delegates the problem -- it doesn't solve it. To use the 'correct' partition, U-Boot has to *decide* which ESP is going to be used and inject it in RTVolatileStorage. But if U-Boot decides about the 'correct' ESP the relative path would work as well. So what's needed here is a mechanism to correlate the booted OS with the ESP it will use and force the variable loading from that file. Am I missing anything? /Ilias Linux efivarfs uses a first 4 bytes of the output to represent attributes in little-endian format. So, storing variables works like this: $~ efibootmgr -n 0001 $~ dd if=/sys/firmware/efi/efivars/VarToFile-b2ac5fc9-92b7-4acd-aeac-11e818c3130c of=/boot/efi/ubootefi.var skip=4 bs=1 [0] https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage Suggested-by: Ard Biesheuvel # dumping all variables to a variable Co-developed-by: Heinrich Schuchardt # contributed on efi_var_collect_mem() Signed-off-by: Heinrich Schuchardt Signed-off-by: Ilias Apalodimas --- include/efi_variable.h| 16 +++- lib/charset.c | 2 +- lib/efi_loader/efi_runtime.c | 25 + lib/efi_loader/efi_var_common.c | 6 +- lib/efi_loader/efi_var_mem.c | 151 +++--- lib/efi_loader/efi_variable.c | 6 +- lib/efi_loader/efi_variable_tee.c | 5 - 7 files changed, 146 insertions(+), 65 deletions(-) diff --git a/include/efi_variable.h b/include/efi_variable.h index 42a2b7c52bef..223bb9a4a5bd 100644 --- a/include/efi_variable.h +++ b/include/efi_variable.h @@ -271,13 +271,16 @@ const efi_guid_t *efi_auth_var_get_guid(const u16 *name); * * @variable_name_size: size of variable_name buffer in bytes * @variable_name: name of uefi variable's name in u16 + * @mask:bitmask with required attributes of variables to be
[GIT PULL] Please pull u-boot-mpc8xx
Hi Tom, This pull request adds support for temperature sensors et FPGA loading on boards from CS GROUP France. CI: https://source.denx.de/u-boot/custodians/u-boot-mpc8xx/-/pipelines/20416 Thanks Christophe The following changes since commit 2c3fa4b8add3cb6a440184ab67debc6867d383c0: sandbox: don't call os_close with invalid file descriptor (2024-04-17 17:06:16 -0600) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-mpc8xx.git for-2024.07 for you to fetch changes up to 741e30e8c2b837dc92ee2eedec5478afdd83a316: board: cssi: Read and display MCR board address (2024-04-18 15:47:46 +0200) Christophe Leroy (13): board: cssi: Fix SPI nodes in DTS spi: mpc8xx: Add GPIO dependency spi: mpc8xx: Fix transfert when input or output buffer is NULL thermal: Add support for TI LM74 board: cssi: Add support for SPI bus on MCR3000 board board: cssi: add support for reading temperature powerpc: 8xx: Set SDMA configuration register correcly spi: mpc8xx: Allow transfer of more than MAX_BUFFER len spi: mpc8xx: Use 16 bit mode for large transfers with even size spi: mpc8xx: Set up speed as requested board: cssi: Use HAVE_VENDOR_COMMON_LIB logic board: cssi: Load FPGA on MCR3000 board board: cssi: Read and display MCR board address Hugo Dubois (2): board: cssi: Initialise port F on MIAE board: cssi: Properly initialise MAC address for fibre on CMPC885 board Jean-Michel CASAUBON (2): board: cssi: Fix MCR3000 board environment board: cssi: Allow use without HUSH shell arch/powerpc/cpu/mpc8xx/cpu_init.c |6 + arch/powerpc/dts/cmpc885.dts | 18 +- arch/powerpc/dts/cmpcpro.dts | 16 +- arch/powerpc/dts/mcr3000.dts | 41 + board/cssi/cmpc885/Makefile|2 +- board/cssi/cmpc885/cmpc885.c |4 +- board/cssi/cmpc885/cmpc885.env |4 +- board/cssi/cmpcpro/Makefile|2 +- board/cssi/cmpcpro/cmpcpro.env |4 +- board/cssi/common/Makefile |8 + board/cssi/common/common.c | 42 +- board/cssi/mcr3000/Makefile|1 + board/cssi/mcr3000/fpga_code.h | 9778 board/cssi/mcr3000/mcr3000.c | 58 + board/cssi/mcr3000/mcr3000.env |2 +- board/cssi/mcr3000/mcr3000_gpio.c | 109 + configs/CMPC885_defconfig |3 + configs/CMPCPRO_defconfig |3 + configs/MCR3000_defconfig |8 + drivers/spi/Kconfig|2 +- drivers/spi/mpc8xx_spi.c | 113 +- drivers/thermal/Kconfig|6 + drivers/thermal/Makefile |1 + drivers/thermal/ti-lm74.c | 52 + 24 files changed, 10244 insertions(+), 39 deletions(-) create mode 100644 board/cssi/common/Makefile create mode 100644 board/cssi/mcr3000/fpga_code.h create mode 100644 board/cssi/mcr3000/mcr3000_gpio.c create mode 100644 drivers/thermal/ti-lm74.c
Re: [PATCH v3 3/4] efi_loader: add an EFI variable with the file contents
On Thu, 18 Apr 2024 at 18:42, Heinrich Schuchardt wrote: > > On 18.04.24 17:36, Ilias Apalodimas wrote: > > Hi Mark, > > > > On Thu, 18 Apr 2024 at 18:15, Mark Kettenis wrote: > >> > >>> From: Ilias Apalodimas > >>> Date: Thu, 18 Apr 2024 15:54:52 +0300 > >> > >> Hi Illias, > >> > >>> > >>> Previous patches enabled SetVariableRT using a RAM backend. > >>> Although EBBR [0] defines a variable format we can teach userspace tools > >>> and write the altered variables, it's better if we skip the ABI > >>> requirements completely. > >>> > >>> So let's add a new variable, in its own namespace called "VarToFile" > >>> which contains a binary dump of the updated RT, BS and, NV variables > >>> and will be updated when GetVariable is called. > >>> > >>> Some adjustments are needed to do that. > >>> Currently we discard BS-only variables in EBS(). We need to preserve > >>> those on the RAM backend that exposes the variables. Since BS-only > >>> variables can't appear at runtime we need to move the memory masking > >>> checks from efi_var_collect() to efi_get_next_variable_name_mem()/ > >>> efi_get_variable_mem() and do the filtering at runtime. > >>> > >>> We also need an efi_var_collect() variant available at runtime, in order > >>> to construct the "VarToFile" buffer on the fly. > >>> > >>> All users and applications (for linux) have to do when updating a variable > >>> is dd that variable in the file described by "RTStorageVolatile". > >> > >> I simehow missed your reply to the issue I raised with picking the > >> right ESP to write variables back to. > > > > No worries, I did send v3 quickly myself... > > > >> I'm not convinced that the ESP > >> that was used to install Linux on is necessarily th right one. In > >> particular, consider a system with multiple disks, say eMMC and an > >> NVMe disk. Suppose U-Boot is installed on eMMC and picks the ESP on > >> that disk to store the EFI variables. > > > > And who creates ESP on the eMMC? I assume you have one OS installed in > > the eMMC and another one in the nvme? > > E.g. you have a naked NVMe. At first boot there will be an ESP on the > installation medium. The installer may create an ESP on the NVMe drive > and put GRUB there. > > Later the user will typically remove the installation module if U-Boot > is on SPI flash. > > U-Boot has no chance to know this beforehand. > > Best regards Ok thanks, Heinrich, as you mentioned offline that's what the Ubuntu installer does. In this case again, neither the DP nor the relative path directly solves the problem, since that second ESP doesn't exist to begin with. Can we get some more info on the installer? When it tries to write Boot which ESP is mounted? The 'installer' one or the newly created one in the NVME? Because if it's the latter things should work. Thanks /Ilias > > Heinrich > > > > > >> Now I install Linux on the NVMe > >> disk, which creates an ESP to store its bootloader. With your > >> proposed changes, Linux will probably end up writing the variables to > >> the ESP on the NVMe. Now you reboot and U-Boot still reads the EFI > >> variables from eMMC and you've lost any changes... > > > > I understand the problem, but my concern is that using a DP just > > delegates the problem -- it doesn't solve it. > > > > To use the 'correct' partition, U-Boot has to *decide* which ESP is > > going to be used and inject it in RTVolatileStorage. > > But if U-Boot decides about the 'correct' ESP the relative path would > > work as well. So what's needed here is a mechanism to correlate the > > booted OS with the ESP it will use and force the variable loading from > > that file. Am I missing anything? > > > > /Ilias > >> > >>> Linux efivarfs uses a first 4 bytes of the output to represent attributes > >>> in little-endian format. So, storing variables works like this: > >>> > >>> $~ efibootmgr -n 0001 > >>> $~ dd > >>> if=/sys/firmware/efi/efivars/VarToFile-b2ac5fc9-92b7-4acd-aeac-11e818c3130c > >>> of=/boot/efi/ubootefi.var skip=4 bs=1 > >>> > >>> [0] > >>> https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage > >>> > >>> Suggested-by: Ard Biesheuvel # dumping all variables to > >>> a variable > >>> Co-developed-by: Heinrich Schuchardt > >>> # contributed on efi_var_collect_mem() > >>> Signed-off-by: Heinrich Schuchardt > >>> Signed-off-by: Ilias Apalodimas > >>> --- > >>> include/efi_variable.h| 16 +++- > >>> lib/charset.c | 2 +- > >>> lib/efi_loader/efi_runtime.c | 25 + > >>> lib/efi_loader/efi_var_common.c | 6 +- > >>> lib/efi_loader/efi_var_mem.c | 151 +++--- > >>> lib/efi_loader/efi_variable.c | 6 +- > >>> lib/efi_loader/efi_variable_tee.c | 5 - > >>> 7 files changed, 146 insertions(+), 65 deletions(-) > >>> > >>> diff --git a/include/efi_variable.h b/include/efi_variable.h > >>> index 42a2b7c52bef..223bb9a4a5bd 100644 > >>> --- a/include/efi_variable.h > >>> +++
Re: [PATCH v3 3/4] efi_loader: add an EFI variable with the file contents
On 18.04.24 17:36, Ilias Apalodimas wrote: Hi Mark, On Thu, 18 Apr 2024 at 18:15, Mark Kettenis wrote: From: Ilias Apalodimas Date: Thu, 18 Apr 2024 15:54:52 +0300 Hi Illias, Previous patches enabled SetVariableRT using a RAM backend. Although EBBR [0] defines a variable format we can teach userspace tools and write the altered variables, it's better if we skip the ABI requirements completely. So let's add a new variable, in its own namespace called "VarToFile" which contains a binary dump of the updated RT, BS and, NV variables and will be updated when GetVariable is called. Some adjustments are needed to do that. Currently we discard BS-only variables in EBS(). We need to preserve those on the RAM backend that exposes the variables. Since BS-only variables can't appear at runtime we need to move the memory masking checks from efi_var_collect() to efi_get_next_variable_name_mem()/ efi_get_variable_mem() and do the filtering at runtime. We also need an efi_var_collect() variant available at runtime, in order to construct the "VarToFile" buffer on the fly. All users and applications (for linux) have to do when updating a variable is dd that variable in the file described by "RTStorageVolatile". I simehow missed your reply to the issue I raised with picking the right ESP to write variables back to. No worries, I did send v3 quickly myself... I'm not convinced that the ESP that was used to install Linux on is necessarily th right one. In particular, consider a system with multiple disks, say eMMC and an NVMe disk. Suppose U-Boot is installed on eMMC and picks the ESP on that disk to store the EFI variables. And who creates ESP on the eMMC? I assume you have one OS installed in the eMMC and another one in the nvme? E.g. you have a naked NVMe. At first boot there will be an ESP on the installation medium. The installer may create an ESP on the NVMe drive and put GRUB there. Later the user will typically remove the installation module if U-Boot is on SPI flash. U-Boot has no chance to know this beforehand. Best regards Heinrich Now I install Linux on the NVMe disk, which creates an ESP to store its bootloader. With your proposed changes, Linux will probably end up writing the variables to the ESP on the NVMe. Now you reboot and U-Boot still reads the EFI variables from eMMC and you've lost any changes... I understand the problem, but my concern is that using a DP just delegates the problem -- it doesn't solve it. To use the 'correct' partition, U-Boot has to *decide* which ESP is going to be used and inject it in RTVolatileStorage. But if U-Boot decides about the 'correct' ESP the relative path would work as well. So what's needed here is a mechanism to correlate the booted OS with the ESP it will use and force the variable loading from that file. Am I missing anything? /Ilias Linux efivarfs uses a first 4 bytes of the output to represent attributes in little-endian format. So, storing variables works like this: $~ efibootmgr -n 0001 $~ dd if=/sys/firmware/efi/efivars/VarToFile-b2ac5fc9-92b7-4acd-aeac-11e818c3130c of=/boot/efi/ubootefi.var skip=4 bs=1 [0] https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage Suggested-by: Ard Biesheuvel # dumping all variables to a variable Co-developed-by: Heinrich Schuchardt # contributed on efi_var_collect_mem() Signed-off-by: Heinrich Schuchardt Signed-off-by: Ilias Apalodimas --- include/efi_variable.h| 16 +++- lib/charset.c | 2 +- lib/efi_loader/efi_runtime.c | 25 + lib/efi_loader/efi_var_common.c | 6 +- lib/efi_loader/efi_var_mem.c | 151 +++--- lib/efi_loader/efi_variable.c | 6 +- lib/efi_loader/efi_variable_tee.c | 5 - 7 files changed, 146 insertions(+), 65 deletions(-) diff --git a/include/efi_variable.h b/include/efi_variable.h index 42a2b7c52bef..223bb9a4a5bd 100644 --- a/include/efi_variable.h +++ b/include/efi_variable.h @@ -271,13 +271,16 @@ const efi_guid_t *efi_auth_var_get_guid(const u16 *name); * * @variable_name_size: size of variable_name buffer in bytes * @variable_name: name of uefi variable's name in u16 + * @mask:bitmask with required attributes of variables to be collected. + * variables are only collected if all of the required + * attributes match. Use 0 to skip matching * @vendor: vendor's guid * * Return: status code */ efi_status_t __efi_runtime efi_get_next_variable_name_mem(efi_uintn_t *variable_name_size, u16 *variable_name, -efi_guid_t *vendor); +efi_guid_t *vendor, u32 mask); /** * efi_get_variable_mem() - Runtime common code across efi variable * implementations for GetVariable() from @@ -289,12 +292,15 @@ efi_get_next_variable_name_mem(efi_uintn_t
Re: [PATCH v3 3/4] efi_loader: add an EFI variable with the file contents
Hi Mark, On Thu, 18 Apr 2024 at 18:15, Mark Kettenis wrote: > > > From: Ilias Apalodimas > > Date: Thu, 18 Apr 2024 15:54:52 +0300 > > Hi Illias, > > > > > Previous patches enabled SetVariableRT using a RAM backend. > > Although EBBR [0] defines a variable format we can teach userspace tools > > and write the altered variables, it's better if we skip the ABI > > requirements completely. > > > > So let's add a new variable, in its own namespace called "VarToFile" > > which contains a binary dump of the updated RT, BS and, NV variables > > and will be updated when GetVariable is called. > > > > Some adjustments are needed to do that. > > Currently we discard BS-only variables in EBS(). We need to preserve > > those on the RAM backend that exposes the variables. Since BS-only > > variables can't appear at runtime we need to move the memory masking > > checks from efi_var_collect() to efi_get_next_variable_name_mem()/ > > efi_get_variable_mem() and do the filtering at runtime. > > > > We also need an efi_var_collect() variant available at runtime, in order > > to construct the "VarToFile" buffer on the fly. > > > > All users and applications (for linux) have to do when updating a variable > > is dd that variable in the file described by "RTStorageVolatile". > > I simehow missed your reply to the issue I raised with picking the > right ESP to write variables back to. No worries, I did send v3 quickly myself... > I'm not convinced that the ESP > that was used to install Linux on is necessarily th right one. In > particular, consider a system with multiple disks, say eMMC and an > NVMe disk. Suppose U-Boot is installed on eMMC and picks the ESP on > that disk to store the EFI variables. And who creates ESP on the eMMC? I assume you have one OS installed in the eMMC and another one in the nvme? > Now I install Linux on the NVMe > disk, which creates an ESP to store its bootloader. With your > proposed changes, Linux will probably end up writing the variables to > the ESP on the NVMe. Now you reboot and U-Boot still reads the EFI > variables from eMMC and you've lost any changes... I understand the problem, but my concern is that using a DP just delegates the problem -- it doesn't solve it. To use the 'correct' partition, U-Boot has to *decide* which ESP is going to be used and inject it in RTVolatileStorage. But if U-Boot decides about the 'correct' ESP the relative path would work as well. So what's needed here is a mechanism to correlate the booted OS with the ESP it will use and force the variable loading from that file. Am I missing anything? /Ilias > > > Linux efivarfs uses a first 4 bytes of the output to represent attributes > > in little-endian format. So, storing variables works like this: > > > > $~ efibootmgr -n 0001 > > $~ dd > > if=/sys/firmware/efi/efivars/VarToFile-b2ac5fc9-92b7-4acd-aeac-11e818c3130c > > of=/boot/efi/ubootefi.var skip=4 bs=1 > > > > [0] > > https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage > > > > Suggested-by: Ard Biesheuvel # dumping all variables to a > > variable > > Co-developed-by: Heinrich Schuchardt # > > contributed on efi_var_collect_mem() > > Signed-off-by: Heinrich Schuchardt > > Signed-off-by: Ilias Apalodimas > > --- > > include/efi_variable.h| 16 +++- > > lib/charset.c | 2 +- > > lib/efi_loader/efi_runtime.c | 25 + > > lib/efi_loader/efi_var_common.c | 6 +- > > lib/efi_loader/efi_var_mem.c | 151 +++--- > > lib/efi_loader/efi_variable.c | 6 +- > > lib/efi_loader/efi_variable_tee.c | 5 - > > 7 files changed, 146 insertions(+), 65 deletions(-) > > > > diff --git a/include/efi_variable.h b/include/efi_variable.h > > index 42a2b7c52bef..223bb9a4a5bd 100644 > > --- a/include/efi_variable.h > > +++ b/include/efi_variable.h > > @@ -271,13 +271,16 @@ const efi_guid_t *efi_auth_var_get_guid(const u16 > > *name); > > * > > * @variable_name_size: size of variable_name buffer in bytes > > * @variable_name: name of uefi variable's name in u16 > > + * @mask:bitmask with required attributes of variables to be > > collected. > > + * variables are only collected if all of the required > > + * attributes match. Use 0 to skip matching > > * @vendor: vendor's guid > > * > > * Return: status code > > */ > > efi_status_t __efi_runtime > > efi_get_next_variable_name_mem(efi_uintn_t *variable_name_size, u16 > > *variable_name, > > -efi_guid_t *vendor); > > +efi_guid_t *vendor, u32 mask); > > /** > > * efi_get_variable_mem() - Runtime common code across efi variable > > * implementations for GetVariable() from > > @@ -289,12 +292,15 @@ efi_get_next_variable_name_mem(efi_uintn_t > > *variable_name_size, u16 *variable_na > > * @data_size: size of the buffer
Re: [PATCH 2/3] pci: dw_imx: add support for IMX8MM
On Wed, Apr 17, 2024 at 8:04 PM Marek Vasut wrote:
>
> On 4/17/24 10:09 PM, Tim Harvey wrote:
> > Add support for the IMX8MM SoC by adding driver data with the compatible
> > string of the GPR controller.
> >
> > Signed-off-by: Tim Harvey
> > ---
> > drivers/pci/pcie_dw_imx.c | 20 ++--
> > 1 file changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/pcie_dw_imx.c b/drivers/pci/pcie_dw_imx.c
> > index a2ee228224b5..10d926c30645 100644
> > --- a/drivers/pci/pcie_dw_imx.c
> > +++ b/drivers/pci/pcie_dw_imx.c
> > @@ -45,6 +45,10 @@
> > #define IMX8M_GPR_PCIE_CLK_REQ_OVERRIDE_EN BIT(10)
> > #define IMX8M_GPR_PCIE_CLK_REQ_OVERRIDE BIT(11)
> >
> > +struct pcie_chip_info {
> > + const char *gpr;
> > +};
> > +
> > struct pcie_dw_imx {
> > /* Must be first member of the struct */
> > struct pcie_dw dw;
> > @@ -54,6 +58,15 @@ struct pcie_dw_imx {
> > struct reset_ctlapps_reset;
> > struct phy phy;
> > struct udevice *vpcie;
> > + struct pcie_chip_info *info;
> > +};
> > +
> > +static const struct pcie_chip_info imx8mm_chip_info = {
> > + .gpr = "fsl,imx8mm-iomuxc-gpr",
> > +};
> > +
> > +static const struct pcie_chip_info imx8mp_chip_info = {
> > + .gpr = "fsl,imx8mp-iomuxc-gpr",
> > };
> >
> > static void pcie_dw_configure(struct pcie_dw_imx *priv, u32 cap_speed)
> > @@ -246,6 +259,8 @@ static int pcie_dw_imx_of_to_plat(struct udevice *dev)
> > ofnode gpr;
> > int ret;
> >
> > + priv->info = (void *)dev_get_driver_data(dev);
> > +
>
> Does this really have to be cached in priv ?
>
> The priv->info seems used only in this function.
>
Hi Marek,
Good point. I will remove that. Thanks for the review!
Best Regards,
Tim
Re: [PATCH v3 3/4] efi_loader: add an EFI variable with the file contents
> From: Ilias Apalodimas > Date: Thu, 18 Apr 2024 15:54:52 +0300 Hi Illias, > > Previous patches enabled SetVariableRT using a RAM backend. > Although EBBR [0] defines a variable format we can teach userspace tools > and write the altered variables, it's better if we skip the ABI > requirements completely. > > So let's add a new variable, in its own namespace called "VarToFile" > which contains a binary dump of the updated RT, BS and, NV variables > and will be updated when GetVariable is called. > > Some adjustments are needed to do that. > Currently we discard BS-only variables in EBS(). We need to preserve > those on the RAM backend that exposes the variables. Since BS-only > variables can't appear at runtime we need to move the memory masking > checks from efi_var_collect() to efi_get_next_variable_name_mem()/ > efi_get_variable_mem() and do the filtering at runtime. > > We also need an efi_var_collect() variant available at runtime, in order > to construct the "VarToFile" buffer on the fly. > > All users and applications (for linux) have to do when updating a variable > is dd that variable in the file described by "RTStorageVolatile". I simehow missed your reply to the issue I raised with picking the right ESP to write variables back to. I'm not convinced that the ESP that was used to install Linux on is necessarily th right one. In particular, consider a system with multiple disks, say eMMC and an NVMe disk. Suppose U-Boot is installed on eMMC and picks the ESP on that disk to store the EFI variables. Now I install Linux on the NVMe disk, which creates an ESP to store its bootloader. With your proposed changes, Linux will probably end up writing the variables to the ESP on the NVMe. Now you reboot and U-Boot still reads the EFI variables from eMMC and you've lost any changes... > Linux efivarfs uses a first 4 bytes of the output to represent attributes > in little-endian format. So, storing variables works like this: > > $~ efibootmgr -n 0001 > $~ dd > if=/sys/firmware/efi/efivars/VarToFile-b2ac5fc9-92b7-4acd-aeac-11e818c3130c > of=/boot/efi/ubootefi.var skip=4 bs=1 > > [0] > https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage > > Suggested-by: Ard Biesheuvel # dumping all variables to a > variable > Co-developed-by: Heinrich Schuchardt # > contributed on efi_var_collect_mem() > Signed-off-by: Heinrich Schuchardt > Signed-off-by: Ilias Apalodimas > --- > include/efi_variable.h| 16 +++- > lib/charset.c | 2 +- > lib/efi_loader/efi_runtime.c | 25 + > lib/efi_loader/efi_var_common.c | 6 +- > lib/efi_loader/efi_var_mem.c | 151 +++--- > lib/efi_loader/efi_variable.c | 6 +- > lib/efi_loader/efi_variable_tee.c | 5 - > 7 files changed, 146 insertions(+), 65 deletions(-) > > diff --git a/include/efi_variable.h b/include/efi_variable.h > index 42a2b7c52bef..223bb9a4a5bd 100644 > --- a/include/efi_variable.h > +++ b/include/efi_variable.h > @@ -271,13 +271,16 @@ const efi_guid_t *efi_auth_var_get_guid(const u16 > *name); > * > * @variable_name_size: size of variable_name buffer in bytes > * @variable_name: name of uefi variable's name in u16 > + * @mask:bitmask with required attributes of variables to be > collected. > + * variables are only collected if all of the required > + * attributes match. Use 0 to skip matching > * @vendor: vendor's guid > * > * Return: status code > */ > efi_status_t __efi_runtime > efi_get_next_variable_name_mem(efi_uintn_t *variable_name_size, u16 > *variable_name, > -efi_guid_t *vendor); > +efi_guid_t *vendor, u32 mask); > /** > * efi_get_variable_mem() - Runtime common code across efi variable > * implementations for GetVariable() from > @@ -289,12 +292,15 @@ efi_get_next_variable_name_mem(efi_uintn_t > *variable_name_size, u16 *variable_na > * @data_size: size of the buffer to which the variable value > is copied > * @data:buffer to which the variable value is copied > * @timep: authentication time (seconds since start of epoch) > + * @mask:bitmask with required attributes of variables to be > collected. > + * variables are only collected if all of the required > + * attributes match. Use 0 to skip matching > * Return: status code > */ > efi_status_t __efi_runtime > efi_get_variable_mem(const u16 *variable_name, const efi_guid_t *vendor, >u32 *attributes, efi_uintn_t *data_size, void *data, > - u64 *timep); > + u64 *timep, u32 mask); > > /** > * efi_get_variable_runtime() - runtime implementation of GetVariable() > @@ -334,4 +340,10 @@ efi_get_next_variable_name_runtime(efi_uintn_t >
Re: [PATCH] rockchip: nanopi-r4s: Fix ehci usb error
Hi Justin,
On 2024-04-18 03:45, Justin Klaassen wrote:
> The ehci_generic driver always failed with the error:
> Bus usb@fe38: ehci_generic usb@fe38:
> ... Failed to get clocks (ret=-19)
> Port not available.
> Bus usb@fe3c: ehci_generic usb@fe3c:
> ... Failed to get clocks (ret=-19)
> Port not available.
>
> This error is resolved by enabling the CONFIG_PHY_ROCKCHIP_INNO_USB2
> and CONFIG_PHY_ROCKCHIP_TYPEC driver options.
Is your issue also fixed with my series "rockchip: rk3399: Sync DT with
linux v6.8 and update defconfigs" [1] containing patch [2]? A v2 of that
series should hit the mailing list sometime tomorrow.
[1] https://patchwork.ozlabs.org/cover/1918319/
[2] https://patchwork.ozlabs.org/patch/1918346/
>
> The CONFIG_DM_RESET option must also be enabled, otherwise the
> ehci_generic driver will fail with the error:
> Bus usb@fe38: ehci_generic usb@fe38:
> ... Failed to get resets (err=-524)
> probe failed, error -524
> Bus usb@fe3c: ehci_generic usb@fe3c:
> ... Failed to get resets (err=-524)
> probe failed, error -524
>
> Additionally the u2phy1_host device was previously disabled in the
> nanopi-r4s device tree and must be enabled to avoid a crash in the
> ehci_generic driver:
> Bus usb@fe38: USB EHCI 1.00
> Bus usb@fe3c: "Synchronous Abort" handler, esr 0x9610, far 0x0
>
> With these changes the usb ports can now be initialized correctly by
> both the ehci_generic and xhci_generic drivers:
> Bus usb@fe38: USB EHCI 1.00
> Bus usb@fe3c: USB EHCI 1.00
> Bus usb@fe80: Register 2000140 NbrPorts 2
> Starting the controller
> USB XHCI 1.10
> Bus usb@fe90: Register 2000140 NbrPorts 2
> Starting the controller
> USB XHCI 1.10
> scanning bus usb@fe38 for devices... 1 USB Device(s) found
> scanning bus usb@fe3c for devices... 1 USB Device(s) found
> scanning bus usb@fe80 for devices... 1 USB Device(s) found
> scanning bus usb@fe90 for devices... 1 USB Device(s) found
>scanning usb for storage devices... 0 Storage Device(s) found
>
> Signed-off-by: Justin Klaassen
> Cc: Simon Glass
> Cc: Philipp Tomsich
> Cc: Kever Yang
> ---
> arch/arm/dts/rk3399-nanopi-r4s.dts | 2 +-
> configs/nanopi-r4s-rk3399_defconfig | 3 +++
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/rk3399-nanopi-r4s.dts
> b/arch/arm/dts/rk3399-nanopi-r4s.dts
> index cef4d18b599..a992a6ac5e9 100644
> --- a/arch/arm/dts/rk3399-nanopi-r4s.dts
> +++ b/arch/arm/dts/rk3399-nanopi-r4s.dts
> @@ -117,7 +117,7 @@
> };
>
> _host {
> - status = "disabled";
> + phy-supply = <_5v>;
This does not match upstream linux device tree file. If this change is
needed please submit a change to linux kernel, else make a U-Boot
specific change in rk3399-nanopi-r4s-u-boot.dtsi.
Regards,
Jonas
> };
>
> {
> diff --git a/configs/nanopi-r4s-rk3399_defconfig
> b/configs/nanopi-r4s-rk3399_defconfig
> index ea01d323541..d8c34dc48cb 100644
> --- a/configs/nanopi-r4s-rk3399_defconfig
> +++ b/configs/nanopi-r4s-rk3399_defconfig
> @@ -5,6 +5,7 @@ CONFIG_ARCH_ROCKCHIP=y
> CONFIG_NR_DRAM_BANKS=1
> CONFIG_ENV_OFFSET=0x3F8000
> CONFIG_DEFAULT_DEVICE_TREE="rk3399-nanopi-r4s"
> +CONFIG_DM_RESET=y
> CONFIG_ROCKCHIP_RK3399=y
> CONFIG_TARGET_EVB_RK3399=y
> CONFIG_DEBUG_UART_BASE=0xFF1A
> @@ -36,6 +37,8 @@ CONFIG_MMC_SDHCI=y
> CONFIG_MMC_SDHCI_ROCKCHIP=y
> CONFIG_ETH_DESIGNWARE=y
> CONFIG_GMAC_ROCKCHIP=y
> +CONFIG_PHY_ROCKCHIP_INNO_USB2=y
> +CONFIG_PHY_ROCKCHIP_TYPEC=y
> CONFIG_PMIC_RK8XX=y
> CONFIG_REGULATOR_PWM=y
> CONFIG_REGULATOR_RK8XX=y
Re: [PATCH 3/5] mmc: am654_sdhci: Add itap_del_ena[] to store itapdlyena bit
On 4/17/24 6:34 AM, Jaehoon Chung wrote:
Hi,
-Original Message-
From: Judith Mendez
Sent: Tuesday, April 16, 2024 6:28 AM
To: Peng Fan ; Jaehoon Chung ; Tom Rini
Cc: Nitin Yadav ; Simon Glass ;
u-boot@lists.denx.de
Subject: [PATCH 3/5] mmc: am654_sdhci: Add itap_del_ena[] to store itapdlyena
bit
Set itap_del_ena if ITAPDLY is found in DT or if the tuning
algorithm was executed and found the optimal ITAPDLY. Add the
functionality to save ITAPDLYENA that can be referenced later
by storing the bit in array itap_del_ena[].
Signed-off-by: Judith Mendez
---
drivers/mmc/am654_sdhci.c | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/am654_sdhci.c b/drivers/mmc/am654_sdhci.c
index 1dd032e1e36..38f1ad28ec4 100644
--- a/drivers/mmc/am654_sdhci.c
+++ b/drivers/mmc/am654_sdhci.c
@@ -92,6 +92,7 @@ struct am654_sdhci_plat {
bool non_removable;
u32 otap_del_sel[MMC_MODES_END];
u32 itap_del_sel[MMC_MODES_END];
+ u32 itap_del_ena[MMC_MODES_END];
u32 trm_icp;
u32 drv_strength;
u32 strb_sel;
@@ -223,8 +224,10 @@ static int am654_sdhci_setup_dll(struct am654_sdhci_plat
*plat,
}
static void am654_sdhci_write_itapdly(struct am654_sdhci_plat *plat,
- u32 itapdly)
+ u32 itapdly, u32 enable)
{
+ regmap_update_bits(plat->base, PHY_CTRL4, ITAPDLYENA_MASK,
+ enable << ITAPDLYENA_SHIFT);
/* Set ITAPCHGWIN before writing to ITAPDLY */
regmap_update_bits(plat->base, PHY_CTRL4, ITAPCHGWIN_MASK,
1 << ITAPCHGWIN_SHIFT);
@@ -242,7 +245,8 @@ static void am654_sdhci_setup_delay_chain(struct
am654_sdhci_plat *plat,
mask = SELDLYTXCLK_MASK | SELDLYRXCLK_MASK;
regmap_update_bits(plat->base, PHY_CTRL5, mask, val);
- am654_sdhci_write_itapdly(plat, plat->itap_del_sel[mode]);
+ am654_sdhci_write_itapdly(plat, plat->itap_del_sel[mode],
+ plat->itap_del_ena[mode]);
}
static int am654_sdhci_set_ios_post(struct sdhci_host *host)
@@ -443,6 +447,7 @@ static int am654_sdhci_execute_tuning(struct mmc *mmc, u8
opcode)
struct udevice *dev = mmc->dev;
struct am654_sdhci_plat *plat = dev_get_plat(dev);
struct window fail_window[ITAPDLY_LENGTH];
+ int mode = mmc->selected_mode;
u8 curr_pass, itap;
u8 fail_index = 0;
u8 prev_pass = 1;
@@ -450,11 +455,10 @@ static int am654_sdhci_execute_tuning(struct mmc *mmc, u8
opcode)
memset(fail_window, 0, sizeof(fail_window));
/* Enable ITAPDLY */
- regmap_update_bits(plat->base, PHY_CTRL4, ITAPDLYENA_MASK,
- 1 << ITAPDLYENA_SHIFT);
+ plat->itap_del_ena[mode] = 0x1;
0x1 means "enable"? I want to use a macro with meaning.
Sure, can do for V2, thanks.
~ Judith
for (itap = 0; itap < ITAPDLY_LENGTH; itap++) {
- am654_sdhci_write_itapdly(plat, itap);
+ am654_sdhci_write_itapdly(plat, itap, plat->itap_del_ena[mode]);
curr_pass = !mmc_send_tuning(mmc, opcode, NULL);
@@ -478,7 +482,7 @@ static int am654_sdhci_execute_tuning(struct mmc *mmc, u8
opcode)
itap = am654_sdhci_calculate_itap(dev, fail_window, fail_index,
plat->dll_enable);
- am654_sdhci_write_itapdly(plat, itap);
+ am654_sdhci_write_itapdly(plat, itap, plat->itap_del_ena[mode]);
return 0;
}
@@ -515,6 +519,7 @@ static int j721e_4bit_sdhci_set_ios_post(struct sdhci_host
*host)
struct am654_sdhci_plat *plat = dev_get_plat(dev);
int mode = host->mmc->selected_mode;
u32 otap_del_sel;
+ u32 itap_del_ena;
u32 itap_del_sel;
u32 mask, val;
@@ -524,10 +529,11 @@ static int j721e_4bit_sdhci_set_ios_post(struct
sdhci_host *host)
val = (1 << OTAPDLYENA_SHIFT) |
(otap_del_sel << OTAPDLYSEL_SHIFT);
+ itap_del_ena = plat->itap_del_ena[mode];
itap_del_sel = plat->itap_del_sel[mode];
mask |= ITAPDLYENA_MASK | ITAPDLYSEL_MASK;
- val = (1 << ITAPDLYENA_SHIFT) |
+ val = (itap_del_ena << ITAPDLYENA_SHIFT) |
(itap_del_sel << ITAPDLYSEL_SHIFT);
regmap_update_bits(plat->base, PHY_CTRL4, ITAPCHGWIN_MASK,
@@ -599,9 +605,13 @@ static int sdhci_am654_get_otap_delay(struct udevice *dev,
cfg->host_caps &= ~td[i].capability;
}
- if (td[i].itap_binding)
- dev_read_u32(dev, td[i].itap_binding,
->itap_del_sel[i]);
+ if (td[i].itap_binding) {
+ ret = dev_read_u32(dev, td[i].itap_binding,
+ >itap_del_sel[i]);
+
+ if (!ret)
+
Re: [PATCH 2/5] mmc: am654_sdhci: Fix OTAP/ITAP delay values
On 4/17/24 6:28 AM, Jaehoon Chung wrote:
Hi Judith,
-Original Message-
From: Judith Mendez
Sent: Tuesday, April 16, 2024 6:28 AM
To: Peng Fan ; Jaehoon Chung ; Tom Rini
Cc: Nitin Yadav ; Simon Glass ;
u-boot@lists.denx.de
Subject: [PATCH 2/5] mmc: am654_sdhci: Fix OTAP/ITAP delay values
From: Nitin Yadav
U-Boot is failing to boot class U1 UHS SD cards due to incorrect
OTAP and ITAP delay select values. Update OTAP and ITAP delay select
values from DT.
Fixes: c7d106b4eb3 ("mmc: am654_sdhci: Update output tap delay writes")
Signed-off-by: Nitin Yadav
Signed-off-by: Judith Mendez
---
drivers/mmc/am654_sdhci.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/am654_sdhci.c b/drivers/mmc/am654_sdhci.c
index e5ad00e2531..1dd032e1e36 100644
--- a/drivers/mmc/am654_sdhci.c
+++ b/drivers/mmc/am654_sdhci.c
@@ -513,12 +513,27 @@ static int j721e_4bit_sdhci_set_ios_post(struct
sdhci_host *host)
{
struct udevice *dev = host->mmc->dev;
struct am654_sdhci_plat *plat = dev_get_plat(dev);
- u32 otap_del_sel, mask, val;
+ int mode = host->mmc->selected_mode;
+ u32 otap_del_sel;
+ u32 itap_del_sel;
+ u32 mask, val;
+
+ otap_del_sel = plat->otap_del_sel[mode];
- otap_del_sel = plat->otap_del_sel[host->mmc->selected_mode];
mask = OTAPDLYENA_MASK | OTAPDLYSEL_MASK;
- val = (1 << OTAPDLYENA_SHIFT) | (otap_del_sel << OTAPDLYSEL_SHIFT);
+ val = (1 << OTAPDLYENA_SHIFT) |
+ (otap_del_sel << OTAPDLYSEL_SHIFT);
Is there any reason to touch this? And I can't understood this, this val
doesn’t use anywhere.
Because val is resetting the below. It seems same value, right?
This change is syncing with upstream kernel driver.
The second val assignment is supposed to be val |=,
will fix for v2.
+
+ itap_del_sel = plat->itap_del_sel[mode];
+
+ mask |= ITAPDLYENA_MASK | ITAPDLYSEL_MASK;
Can it be set at above?
mask |= OTAPDLYENA_MASK | OTAPDLYSEL_MASK |
ITAPDLYENA_MASK | ITAPDLYSEL_MASK;
This is also syncing with upstream. I am hoping
to leave this as is.
~ Judith
Best Regards,
Jaehoon Chung
+ val = (1 << ITAPDLYENA_SHIFT) |
+ (itap_del_sel << ITAPDLYSEL_SHIFT);
+
+ regmap_update_bits(plat->base, PHY_CTRL4, ITAPCHGWIN_MASK,
+ 1 << ITAPCHGWIN_SHIFT);
regmap_update_bits(plat->base, PHY_CTRL4, mask, val);
+ regmap_update_bits(plat->base, PHY_CTRL4, ITAPCHGWIN_MASK, 0);
regmap_update_bits(plat->base, PHY_CTRL5, CLKBUFSEL_MASK,
plat->clkbuf_sel);
@@ -572,7 +587,7 @@ static int sdhci_am654_get_otap_delay(struct udevice *dev,
* Remove the corresponding capability if an otap-del-sel
* value is not found
*/
- for (i = MMC_HS; i <= MMC_HS_400; i++) {
+ for (i = MMC_LEGACY; i <= MMC_HS_400; i++) {
ret = dev_read_u32(dev, td[i].otap_binding,
>otap_del_sel[i]);
if (ret) {
--
2.43.2
Re: [PATCH 1/5] mmc: am654_sdhci: Add tuning algorithm for delay chain
Hi,
On 4/17/24 6:23 AM, Jaehoon Chung wrote:
-Original Message-
From: Judith Mendez
Sent: Tuesday, April 16, 2024 6:28 AM
To: Peng Fan ; Jaehoon Chung ; Tom Rini
Cc: Nitin Yadav ; Simon Glass ;
u-boot@lists.denx.de
Subject: [PATCH 1/5] mmc: am654_sdhci: Add tuning algorithm for delay chain
Currently the sdhci_am654 driver only supports one tuning
algorithm which should be used only when DLL is enabled. The
ITAPDLY is selected from the largest passing window and the
buffer is viewed as a circular buffer.
The new tuning algorithm should be used when the delay chain
is enabled; the ITAPDLY is selected from the largest passing
window and the buffer is not viewed as a circular buffer.
This implementation is based off of the following paper: [1].
Also add support for multiple failing windows.
[1] https://www.ti.com/lit/an/spract9/spract9.pdf
Fixes: a759abf569d4 ("mmc: am654_sdhci: Add support for software tuning")
Signed-off-by: Judith Mendez
---
drivers/mmc/am654_sdhci.c | 107 +++---
1 file changed, 89 insertions(+), 18 deletions(-)
diff --git a/drivers/mmc/am654_sdhci.c b/drivers/mmc/am654_sdhci.c
index 05595bdac39..e5ad00e2531 100644
--- a/drivers/mmc/am654_sdhci.c
+++ b/drivers/mmc/am654_sdhci.c
@@ -97,6 +97,7 @@ struct am654_sdhci_plat {
u32 strb_sel;
u32 clkbuf_sel;
u32 flags;
+ bool dll_enable;
#define DLL_PRESENT BIT(0)
#define IOMUX_PRESENT BIT(1)
#define FREQSEL_2_BIT BIT(2)
@@ -110,6 +111,12 @@ struct timing_data {
u32 capability;
};
+struct window {
+ u8 start;
+ u8 end;
+ u8 length;
+};
+
static const struct timing_data td[] = {
[MMC_LEGACY]= {"ti,otap-del-sel-legacy",
"ti,itap-del-sel-legacy",
@@ -280,8 +287,11 @@ static int am654_sdhci_set_ios_post(struct sdhci_host
*host)
ret = am654_sdhci_setup_dll(plat, speed);
if (ret)
return ret;
+
+ plat->dll_enable = true;
} else {
am654_sdhci_setup_delay_chain(plat, mode);
+ plat->dll_enable = false;
}
regmap_update_bits(plat->base, PHY_CTRL5, CLKBUFSEL_MASK,
@@ -375,38 +385,99 @@ static void am654_sdhci_write_b(struct sdhci_host *host,
u8 val, int reg)
writeb(val, host->ioaddr + reg);
}
#ifdef MMC_SUPPORTS_TUNING
-#define ITAP_MAX 32
+#define ITAPDLY_LENGTH 32
+#define ITAPDLY_LAST_INDEX (ITAPDLY_LENGTH - 1)
+
+static u32 am654_sdhci_calculate_itap(struct udevice *dev, struct window
+ *fail_window, u8 num_fails, bool circular_buffer)
+{
+ u8 itap = 0, start_fail = 0, end_fail = 0, pass_length = 0;
+ u8 first_fail_start = 0, last_fail_end = 0;
+ struct window pass_window = {0, 0, 0};
+ int prev_fail_end = -1;
+ u8 i;
+
+ if (!num_fails)
+ return ITAPDLY_LAST_INDEX >> 1;
+
+ if (fail_window->length == ITAPDLY_LENGTH) {
+ dev_err(dev, "No passing ITAPDLY, return 0\n");
+ return 0;
+ }
+
+ first_fail_start = fail_window->start;
+ last_fail_end = fail_window[num_fails - 1].end;
+
+ for (i = 0; i < num_fails; i++) {
+ start_fail = fail_window[i].start;
+ end_fail = fail_window[i].end;
+ pass_length = start_fail - (prev_fail_end + 1);
+
+ if (pass_length > pass_window.length) {
+ pass_window.start = prev_fail_end + 1;
+ pass_window.length = pass_length;
+ }
+ prev_fail_end = end_fail;
+ }
+
+ if (!circular_buffer)
+ pass_length = ITAPDLY_LAST_INDEX - last_fail_end;
+ else
+ pass_length = ITAPDLY_LAST_INDEX - last_fail_end +
first_fail_start;
+
+ if (pass_length > pass_window.length) {
+ pass_window.start = last_fail_end + 1;
+ pass_window.length = pass_length;
+ }
+
+ if (!circular_buffer)
+ itap = pass_window.start + (pass_window.length >> 1);
+ else
+ itap = (pass_window.start + (pass_window.length >> 1)) %
ITAPDLY_LENGTH;
+
+ return (itap > ITAPDLY_LAST_INDEX) ? ITAPDLY_LAST_INDEX >> 1 : itap;
+}
+
static int am654_sdhci_execute_tuning(struct mmc *mmc, u8 opcode)
{
struct udevice *dev = mmc->dev;
struct am654_sdhci_plat *plat = dev_get_plat(dev);
- int cur_val, prev_val = 1, fail_len = 0, pass_window = 0, pass_len;
- u32 itap;
+ struct window fail_window[ITAPDLY_LENGTH];
+ u8 curr_pass, itap;
+ u8 fail_index = 0;
+ u8 prev_pass = 1;
+
+ memset(fail_window, 0, sizeof(fail_window));
/* Enable ITAPDLY */
regmap_update_bits(plat->base, PHY_CTRL4, ITAPDLYENA_MASK,
1 << ITAPDLYENA_SHIFT);
- for (itap = 0; itap < ITAP_MAX; itap++) {
+ for (itap = 0;
Re: [PATCH 1/1] mailmap: add entry for AKASHI Takahiro
On Thu, 18 Apr 2024 at 17:11, Heinrich Schuchardt wrote: > > Akashi-san's Linaro email address in not valid anymore. > > Cc: AKASHI Takahiro > Signed-off-by: Heinrich Schuchardt > --- > .mailmap | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/.mailmap b/.mailmap > index 932bd4d9a97..8049856d41c 100644 > --- a/.mailmap > +++ b/.mailmap > @@ -15,6 +15,7 @@ > # Proper Name > # Proper Name Commit Name > > +AKASHI Takahiro > Alexander Graf > Allen Martin > Amanda Baze > -- > 2.43.0 > Acked-by: Ilias Apalodimas
[PATCH 1/1] mailmap: add entry for AKASHI Takahiro
Akashi-san's Linaro email address in not valid anymore. Cc: AKASHI Takahiro Signed-off-by: Heinrich Schuchardt --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index 932bd4d9a97..8049856d41c 100644 --- a/.mailmap +++ b/.mailmap @@ -15,6 +15,7 @@ # Proper Name # Proper Name Commit Name +AKASHI Takahiro Alexander Graf Allen Martin Amanda Baze -- 2.43.0
Re: [PULL] u-boot-sh/master-fdt
On Thu, Apr 18, 2024 at 02:49:54PM +0200, Marek Vasut wrote: > The following changes since commit a712a54dc427708195e6405af4b072d869d0dd8f: > > Merge patch series "configs: ti: Enable basic settings for SystemReady ACS" > (2024-04-17 13:16:12 -0600) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-sh.git master-fdt > > for you to fetch changes up to aad511a488c40393728156333d983c31001aac32: > > ARM: dts: renesas: Switch to using upstream DT (2024-04-18 05:21:26 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH v1] board: toradex: verdin-am62: Remove not needed env variables
From: Francesco Dolcini
Remove not needed variables from environment.
- boot_scripts is not needed, the default value is just fine and
already includes boot.scr
- setup variable used to be executed from some bootscript, however
it's not required and there is no point on having this small helper
here
Signed-off-by: Francesco Dolcini
---
include/configs/verdin-am62.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/configs/verdin-am62.h b/include/configs/verdin-am62.h
index 9d2e37f2d96d..ac44809fdfa5 100644
--- a/include/configs/verdin-am62.h
+++ b/include/configs/verdin-am62.h
@@ -39,12 +39,9 @@
#define CFG_EXTRA_ENV_SETTINGS \
BOOTENV \
MEM_LAYOUT_ENV_SETTINGS \
- "boot_scripts=boot.scr\0" \
"boot_script_dhcp=boot.scr\0" \
"console=ttyS2\0" \
"fdt_board=dev\0" \
- "setup=setenv setupargs console=tty1 console=${console},${baudrate} " \
- "consoleblank=0 earlycon=ns16550a,mmio32,0x0280\0" \
"update_tiboot3=askenv confirm Did you load tiboot3.bin (y/N)?; " \
"if test \"$confirm\" = \"y\"; then " \
"setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt " \
--
2.39.2
[PATCH v1] board: toradex: imx: Remove not needed env variables
From: Francesco Dolcini
Remove not needed variables from environment and include config files.
- setup variable used to be executed from some bootscript, however
it's not required and there is no point on having this small helper
here
- boot_file, kernel_file, ip_dyn variables are not used anywhere
- fdt_fixup variable is just set empty
- defargs, vidargs variables used to be used from some bootscript,
however there is no point on having it here and even old legacy
bootscript can work without them
- removed CONFIG_ENABLE_DDR_TRAINING_DEBUG, this is a leftover from
some copy/paste
On colibri imx6ull/imx7 NAND module, remove consoleblank=0, this is
already the Linux kernel default therefore useless.
Various Linux Kernel command line options removed are not-existing
left-over that applied to some old NXP i.MX downstream branch
Signed-off-by: Francesco Dolcini
---
include/configs/apalis-imx8.h | 2 --
include/configs/apalis_imx6.h | 9 +
include/configs/colibri-imx6ull.h | 10 +++---
include/configs/colibri-imx8x.h | 2 --
include/configs/colibri_imx6.h| 9 +
include/configs/colibri_imx7.h| 11 +++
include/configs/verdin-imx8mm.h | 3 ---
include/configs/verdin-imx8mp.h | 5 -
8 files changed, 8 insertions(+), 43 deletions(-)
diff --git a/include/configs/apalis-imx8.h b/include/configs/apalis-imx8.h
index 845705c86db2..c8ec034fc979 100644
--- a/include/configs/apalis-imx8.h
+++ b/include/configs/apalis-imx8.h
@@ -46,8 +46,6 @@
"fdt_board=eval\0" \
"initrd_addr=0x8380\0" \
"initrd_high=0x\0" \
- "setup=setenv setupargs console=tty1 console=${console},${baudrate} " \
- "consoleblank=0 earlycon\0" \
"update_uboot=askenv confirm Did you load flash.bin resp.
u-boot-dtb.imx (y/N)?; " \
"if test \"$confirm\" = \"y\"; then " \
"setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt " \
diff --git a/include/configs/apalis_imx6.h b/include/configs/apalis_imx6.h
index 8a9f3ef75a7d..0df3917e2009 100644
--- a/include/configs/apalis_imx6.h
+++ b/include/configs/apalis_imx6.h
@@ -64,12 +64,9 @@
#define CFG_EXTRA_ENV_SETTINGS \
BOOTENV \
- "boot_file=zImage\0" \
"boot_script_dhcp=boot.scr\0" \
"console=ttymxc0\0" \
- "defargs=enable_wait_mode=off vmalloc=400M\0" \
"fdt_board=eval\0" \
- "fdt_fixup=;\0" \
MEM_LAYOUT_ENV_SETTINGS \
UBOOT_UPDATE \
"setethupdate=if env exists ethaddr; then; else setenv ethaddr " \
@@ -80,16 +77,12 @@
"|| setenv drive 2; mmc rescan; load ${interface} ${drive}:1" \
" ${loadaddr} flash_blk.img && " \
"source ${loadaddr}\0" \
- "setup=setenv setupargs fec_mac=${ethaddr} " \
- "consoleblank=0 no_console_suspend=1 console=tty1 " \
- "console=${console},${baudrate}n8\0 " \
"setupdate=run setsdupdate || run setusbupdate || run setethupdate\0" \
"setusbupdate=usb start && setenv interface usb; setenv drive 0; " \
"load ${interface} ${drive}:1 ${loadaddr} flash_blk.img && " \
"source ${loadaddr}\0" \
"splashpos=m,m\0" \
- "splashimage=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
- "vidargs=mxc_hdmi.only_cea=1 fbmem=32M\0"
+ "splashimage=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0"
/* Miscellaneous configurable options */
diff --git a/include/configs/colibri-imx6ull.h
b/include/configs/colibri-imx6ull.h
index 561a61ebc03c..7c9d633b68d9 100644
--- a/include/configs/colibri-imx6ull.h
+++ b/include/configs/colibri-imx6ull.h
@@ -48,8 +48,8 @@
"ubiargs=ubi.mtd=ubi root=ubi0:rootfs rw rootfstype=ubifs " \
"ubi.fm_autoconvert=1\0" \
"ubiboot=run setup; " \
- "setenv bootargs ${defargs} ${ubiargs} " \
- "${setupargs} ${vidargs} ${tdxargs}; echo Booting from NAND...;
" \
+ "setenv bootargs ${ubiargs} " \
+ "${setupargs} ${tdxargs}; echo Booting from NAND...; " \
"ubi part ubi &&" \
"ubi read ${kernel_addr_r} kernel && " \
"ubi read ${fdt_addr_r} dtb && " \
@@ -86,11 +86,7 @@
UBOOT_UPDATE \
"boot_script_dhcp=boot.scr\0" \
"console=ttymxc0\0" \
- "defargs=user_debug=30\0" \
"fdt_board=eval-v3\0" \
- "fdt_fixup=;\0" \
- "ip_dyn=yes\0" \
- "kernel_file=zImage\0" \
"setethupdate=if env exists ethaddr; then; else setenv ethaddr " \
"00:14:2d:00:00:00; fi; tftpboot ${loadaddr} " \
"${board}/flash_eth.img && source ${loadaddr}\0" \
@@ -99,7 +95,7 @@
"${board}/flash_blk.img && source ${loadaddr}\0" \
"setup=setenv setupargs " \
"console=tty1 console=${console}" \
- ",${baudrate}n8 ${memargs} ${mtdparts} consoleblank=0\0" \
+
Re: [PATCH v5 0/1] Introduce fastboot oem board command
Hi, On Thu, 18 Apr 2024 13:01:28 +0300, Alexey Romanov wrote: > Changes V1 -> V2 [1]: > - Added an example of using the command as requested > by Sean Anderson [2]. > > Changes V2 -> V3 [3]: > - Rebase over uboot/master. > - Add documentation. > - Remove example added in V2 [1]. > > [...] Thanks, Applied to https://source.denx.de/u-boot/custodians/u-boot-dfu (u-boot-dfu) [1/1] fastboot: introduce 'oem board' subcommand https://source.denx.de/u-boot/custodians/u-boot-dfu/-/commit/b2acf59baf917c3b4002c1b2094ddb46c03ab02e -- Mattijs
[PATCH v3 4/4] efi_selftest: add tests for setvariableRT
Since we support SetVariableRT now add the relevant tests
- Search for the RTStorageVolatile and VarToFile variables after EBS
- Try to update with invalid variales (BS, RT only)
- Try to write a variable bigger than our backend storage
- Write a variable that fits and check VarToFile has been updated
correclty
- Append to the variable and check VarToFile changes
- Try to delete VarToFile which is write protected
- Try to add/delete runtime variables
- Verify VarToFile contains a valid file format
Signed-off-by: Ilias Apalodimas
---
.../efi_selftest_variables_runtime.c | 197 +-
1 file changed, 196 insertions(+), 1 deletion(-)
diff --git a/lib/efi_selftest/efi_selftest_variables_runtime.c
b/lib/efi_selftest/efi_selftest_variables_runtime.c
index 986924b881dd..28b4e9e7afa5 100644
--- a/lib/efi_selftest/efi_selftest_variables_runtime.c
+++ b/lib/efi_selftest/efi_selftest_variables_runtime.c
@@ -10,6 +10,8 @@
*/
#include
+#include
+#include
#define EFI_ST_MAX_DATA_SIZE 16
#define EFI_ST_MAX_VARNAME_SIZE 40
@@ -17,6 +19,8 @@
static struct efi_boot_services *boottime;
static struct efi_runtime_services *runtime;
static const efi_guid_t guid_vendor0 = EFI_GLOBAL_VARIABLE_GUID;
+static const efi_guid_t __efi_runtime_data efi_rt_var_guid =
+ U_BOOT_EFI_RT_VAR_FILE_GUID;
/*
* Setup unit test.
@@ -41,15 +45,18 @@ static int setup(const efi_handle_t img_handle,
static int execute(void)
{
efi_status_t ret;
- efi_uintn_t len;
+ efi_uintn_t len, avail, append_len = 17;
u32 attr;
u8 v[16] = {0x5d, 0xd1, 0x5e, 0x51, 0x5a, 0x05, 0xc7, 0x0c,
0x35, 0x4a, 0xae, 0x87, 0xa5, 0xdf, 0x0f, 0x65,};
+ u8 v2[CONFIG_EFI_VAR_BUF_SIZE];
u8 data[EFI_ST_MAX_DATA_SIZE];
+ u8 data2[CONFIG_EFI_VAR_BUF_SIZE];
u16 varname[EFI_ST_MAX_VARNAME_SIZE];
efi_guid_t guid;
u64 max_storage, rem_storage, max_size;
+ memset(v2, 0x1, sizeof(v2));
ret = runtime->query_variable_info(EFI_VARIABLE_BOOTSERVICE_ACCESS,
_storage, _storage,
_size);
@@ -63,11 +70,199 @@ static int execute(void)
EFI_VARIABLE_RUNTIME_ACCESS,
3, v + 4);
if (IS_ENABLED(CONFIG_EFI_RT_VOLATILE_STORE)) {
+ efi_uintn_t prev_len, delta;
+ struct efi_var_entry *var;
+ struct efi_var_file *hdr;
+
/* At runtime only non-volatile variables may be set. */
if (ret != EFI_INVALID_PARAMETER) {
efi_st_error("SetVariable failed\n");
return EFI_ST_FAILURE;
}
+
+ /* runtime atttribute must be set */
+ ret = runtime->set_variable(u"efi_st_var0", _vendor0,
+ EFI_VARIABLE_BOOTSERVICE_ACCESS |
+ EFI_VARIABLE_NON_VOLATILE,
+ 3, v + 4);
+ if (ret != EFI_INVALID_PARAMETER) {
+ efi_st_error("SetVariable failed\n");
+ return EFI_ST_FAILURE;
+ }
+
+ len = sizeof(data);
+ ret = runtime->get_variable(u"RTStorageVolatile",
+ _rt_var_guid,
+ , , data);
+ if (ret != EFI_SUCCESS) {
+ efi_st_error("GetVariable failed\n");
+ return EFI_ST_FAILURE;
+ }
+
+ len = sizeof(data2);
+ ret = runtime->get_variable(u"VarToFile", _rt_var_guid,
+ , , data2);
+ if (ret != EFI_SUCCESS) {
+ efi_st_error("GetVariable failed\n");
+ return EFI_ST_FAILURE;
+ }
+ /*
+* VarToFile size must change once a variable is inserted
+* Store it now, we'll use it later
+*/
+ prev_len = len;
+ ret = runtime->set_variable(u"efi_st_var0", _vendor0,
+ EFI_VARIABLE_BOOTSERVICE_ACCESS |
+ EFI_VARIABLE_RUNTIME_ACCESS |
+ EFI_VARIABLE_NON_VOLATILE,
+ sizeof(v2),
+ v2);
+ /*
+* This will try to update VarToFile as well and must fail,
+* without changing or deleting VarToFile
+*/
+ if (ret != EFI_OUT_OF_RESOURCES) {
+ efi_st_error("SetVariable failed\n");
+ return EFI_ST_FAILURE;
+
[PATCH v3 3/4] efi_loader: add an EFI variable with the file contents
Previous patches enabled SetVariableRT using a RAM backend.
Although EBBR [0] defines a variable format we can teach userspace tools
and write the altered variables, it's better if we skip the ABI
requirements completely.
So let's add a new variable, in its own namespace called "VarToFile"
which contains a binary dump of the updated RT, BS and, NV variables
and will be updated when GetVariable is called.
Some adjustments are needed to do that.
Currently we discard BS-only variables in EBS(). We need to preserve
those on the RAM backend that exposes the variables. Since BS-only
variables can't appear at runtime we need to move the memory masking
checks from efi_var_collect() to efi_get_next_variable_name_mem()/
efi_get_variable_mem() and do the filtering at runtime.
We also need an efi_var_collect() variant available at runtime, in order
to construct the "VarToFile" buffer on the fly.
All users and applications (for linux) have to do when updating a variable
is dd that variable in the file described by "RTStorageVolatile".
Linux efivarfs uses a first 4 bytes of the output to represent attributes
in little-endian format. So, storing variables works like this:
$~ efibootmgr -n 0001
$~ dd
if=/sys/firmware/efi/efivars/VarToFile-b2ac5fc9-92b7-4acd-aeac-11e818c3130c
of=/boot/efi/ubootefi.var skip=4 bs=1
[0]
https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage
Suggested-by: Ard Biesheuvel # dumping all variables to a
variable
Co-developed-by: Heinrich Schuchardt #
contributed on efi_var_collect_mem()
Signed-off-by: Heinrich Schuchardt
Signed-off-by: Ilias Apalodimas
---
include/efi_variable.h| 16 +++-
lib/charset.c | 2 +-
lib/efi_loader/efi_runtime.c | 25 +
lib/efi_loader/efi_var_common.c | 6 +-
lib/efi_loader/efi_var_mem.c | 151 +++---
lib/efi_loader/efi_variable.c | 6 +-
lib/efi_loader/efi_variable_tee.c | 5 -
7 files changed, 146 insertions(+), 65 deletions(-)
diff --git a/include/efi_variable.h b/include/efi_variable.h
index 42a2b7c52bef..223bb9a4a5bd 100644
--- a/include/efi_variable.h
+++ b/include/efi_variable.h
@@ -271,13 +271,16 @@ const efi_guid_t *efi_auth_var_get_guid(const u16 *name);
*
* @variable_name_size:size of variable_name buffer in bytes
* @variable_name: name of uefi variable's name in u16
+ * @mask: bitmask with required attributes of variables to be
collected.
+ * variables are only collected if all of the required
+ * attributes match. Use 0 to skip matching
* @vendor:vendor's guid
*
* Return: status code
*/
efi_status_t __efi_runtime
efi_get_next_variable_name_mem(efi_uintn_t *variable_name_size, u16
*variable_name,
- efi_guid_t *vendor);
+ efi_guid_t *vendor, u32 mask);
/**
* efi_get_variable_mem() - Runtime common code across efi variable
* implementations for GetVariable() from
@@ -289,12 +292,15 @@ efi_get_next_variable_name_mem(efi_uintn_t
*variable_name_size, u16 *variable_na
* @data_size: size of the buffer to which the variable value is copied
* @data: buffer to which the variable value is copied
* @timep: authentication time (seconds since start of epoch)
+ * @mask: bitmask with required attributes of variables to be
collected.
+ * variables are only collected if all of the required
+ * attributes match. Use 0 to skip matching
* Return: status code
*/
efi_status_t __efi_runtime
efi_get_variable_mem(const u16 *variable_name, const efi_guid_t *vendor,
u32 *attributes, efi_uintn_t *data_size, void *data,
-u64 *timep);
+u64 *timep, u32 mask);
/**
* efi_get_variable_runtime() - runtime implementation of GetVariable()
@@ -334,4 +340,10 @@ efi_get_next_variable_name_runtime(efi_uintn_t
*variable_name_size,
*/
void efi_var_buf_update(struct efi_var_file *var_buf);
+efi_status_t __efi_runtime efi_var_collect_mem(struct efi_var_file *buf,
+ efi_uintn_t *lenp,
+ u32 check_attr_mask);
+
+u32 efi_var_entry_len(struct efi_var_entry *var);
+
#endif
diff --git a/lib/charset.c b/lib/charset.c
index df4f04074852..182c92a50c48 100644
--- a/lib/charset.c
+++ b/lib/charset.c
@@ -387,7 +387,7 @@ int u16_strcasecmp(const u16 *s1, const u16 *s2)
* > 0 if the first different u16 in s1 is greater than the
* corresponding u16 in s2
*/
-int u16_strncmp(const u16 *s1, const u16 *s2, size_t n)
+int __efi_runtime u16_strncmp(const u16 *s1, const u16 *s2, size_t n)
{
int ret = 0;
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index
[PATCH v3 2/4] efi_loader: Add OS notifications for SetVariable at runtime
Previous patches enable SetVariable at runtime using a volatile storage
backend using EFI_RUNTIME_SERVICES_DATA allocared memory. Since there's
no recommendation from the spec on how to notify the OS, add a volatile
EFI variable that contains the filename relative to the ESP. OS'es
can use that file and update it at runtime
$~ efivar -p -n b2ac5fc9-92b7-4acd-aeac-11e818c3130c-RTStorageVolatile
GUID: b2ac5fc9-92b7-4acd-aeac-11e818c3130c
Name: "RTStorageVolatile"
Attributes:
Boot Service Access
Runtime Service Access
Value:
75 62 6f 6f 74 65 66 69 2e 76 61 72 00 |ubootefi.var. |
Reviewed-by: Heinrich Schuchardt
Signed-off-by: Ilias Apalodimas
---
include/efi_loader.h | 4
lib/efi_loader/efi_runtime.c | 19 ---
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index bb51c0281774..69442f4e58de 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -159,6 +159,10 @@ static inline void efi_set_bootdev(const char *dev, const
char *devnr,
#define EFICONFIG_AUTO_GENERATED_ENTRY_GUID \
EFI_GUID(0x8108ac4e, 0x9f11, 0x4d59, \
0x85, 0x0e, 0xe2, 0x1a, 0x52, 0x2c, 0x59, 0xb2)
+#define U_BOOT_EFI_RT_VAR_FILE_GUID \
+ EFI_GUID(0xb2ac5fc9, 0x92b7, 0x4acd, \
+0xae, 0xac, 0x11, 0xe8, 0x18, 0xc3, 0x13, 0x0c)
+
/* Use internal device tree when starting UEFI application */
#define EFI_FDT_USE_INTERNAL NULL
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index dde083b09665..c8f7a88ba8db 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -110,6 +111,7 @@ static __efi_runtime_data efi_uintn_t efi_descriptor_size;
*/
efi_status_t efi_init_runtime_supported(void)
{
+ const efi_guid_t efi_guid_efi_rt_var_file = U_BOOT_EFI_RT_VAR_FILE_GUID;
efi_status_t ret;
struct efi_rt_properties_table *rt_table;
@@ -127,9 +129,20 @@ efi_status_t efi_init_runtime_supported(void)
EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP |
EFI_RT_SUPPORTED_CONVERT_POINTER;
- if (IS_ENABLED(CONFIG_EFI_RT_VOLATILE_STORE))
- rt_table->runtime_services_supported |=
- EFI_RT_SUPPORTED_SET_VARIABLE;
+ if (IS_ENABLED(CONFIG_EFI_RT_VOLATILE_STORE)) {
+ ret = efi_set_variable_int(u"RTStorageVolatile",
+ _guid_efi_rt_var_file,
+ EFI_VARIABLE_BOOTSERVICE_ACCESS |
+ EFI_VARIABLE_RUNTIME_ACCESS |
+ EFI_VARIABLE_READ_ONLY,
+ sizeof(EFI_VAR_FILE_NAME),
+ EFI_VAR_FILE_NAME, false);
+ if (ret != EFI_SUCCESS) {
+ log_err("Failed to set RTStorageVolatile\n");
+ return ret;
+ }
+ rt_table->runtime_services_supported |=
EFI_RT_SUPPORTED_SET_VARIABLE;
+ }
/*
* This value must be synced with efi_runtime_detach_list
--
2.40.1
[PATCH v3 1/4] efi_loader: conditionally enable SetvariableRT
When we store EFI variables on file we don't allow SetVariable at runtime,
since the OS doesn't know how to access or write that file. At the same
time keeping the U-Boot drivers alive in runtime sections and performing
writes from the firmware is dangerous -- if at all possible.
For GetVariable at runtime we copy runtime variables in RAM and expose them
to the OS. Add a Kconfig option and provide SetVariable at runtime using
the same memory backend. The OS will be responsible for syncing the RAM
contents to the file, otherwise any changes made during runtime won't
persist reboots.
It's worth noting that the variable store format is defined in EBBR [0]
and authenticated variables are explicitly prohibited, since they have
to be stored on a medium that's tamper and rollback protected.
- pre-patch
$~ mount | grep efiva
efivarfs on /sys/firmware/efi/efivars type efivarfs
(ro,nosuid,nodev,noexec,relatime)
$~ efibootmgr -n 0001
Could not set BootNext: Read-only file system
- post-patch
$~ mount | grep efiva
efivarfs on /sys/firmware/efi/efivars type efivarfs
(rw,nosuid,nodev,noexec,relatime)
$~ efibootmgr -n 0001
BootNext: 0001
BootCurrent:
BootOrder: ,0001
Boot* debian
HD(1,GPT,bdae5610-3331-4e4d-9466-acb5caf0b4a6,0x800,0x10)/File(EFI\debian\grubaa64.efi)
Boot0001* virtio 0
VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,85001f00)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,16008500){auto_created_boot_option}
$~ efivar -p -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootNext
GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
Name: "BootNext"
Attributes:
Non-Volatile
Boot Service Access
Runtime Service Access
Value:
01 00
FWTS runtime results
Skipped tests are for SetVariable which is now supported
'Passed' test is for QueryVariableInfo which is not yet supported
Test: UEFI miscellaneous runtime service interface tests.
Test for UEFI miscellaneous runtime service interfaces 6 skipped
Stress test for UEFI miscellaneous runtime service i.. 1 skipped
Test GetNextHighMonotonicCount with invalid NULL par.. 1 skipped
Test UEFI miscellaneous runtime services unsupported.. 1 passed
Test: UEFI Runtime service variable interface tests.
Test UEFI RT service get variable interface.1 passed
Test UEFI RT service get next variable name interface. 4 passed
Test UEFI RT service set variable interface.8 passed
Test UEFI RT service query variable info interface. 1 skipped
Test UEFI RT service variable interface stress test.2 passed
Test UEFI RT service set variable interface stress t.. 4 passed
Test UEFI RT service query variable info interface s.. 1 skipped
Test UEFI RT service get variable interface, invalid.. 5 passed
Test UEFI RT variable services unsupported status. 1 passed, 3 skipped
[0]
https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage
Reviewed-by: Heinrich Schuchardt
Signed-off-by: Ilias Apalodimas
---
lib/efi_loader/Kconfig| 16 +++
lib/efi_loader/efi_runtime.c | 4 +
lib/efi_loader/efi_variable.c | 116 --
.../efi_selftest_variables_runtime.c | 14 ++-
4 files changed, 136 insertions(+), 14 deletions(-)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index e13a6f9f4c3a..cc8371a3bb4c 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -62,6 +62,22 @@ config EFI_VARIABLE_FILE_STORE
Select this option if you want non-volatile UEFI variables to be
stored as file /ubootefi.var on the EFI system partition.
+config EFI_RT_VOLATILE_STORE
+ bool "Allow variable runtime services in volatile storage (e.g RAM)"
+ depends on EFI_VARIABLE_FILE_STORE
+ help
+ When EFI variables are stored on file we don't allow SetVariableRT,
+ since the OS doesn't know how to write that file. At he same time
+ we copy runtime variables in DRAM and support GetVariableRT
+
+ Enable this option to allow SetVariableRT on the RAM backend of
+ the EFI variable storage. The OS will be responsible for syncing
+ the RAM contents to the file, otherwise any changes made during
+ runtime won't persist reboots.
+ Authenticated variables are not supported. Note that this will
+ violate the EFI spec since writing auth variables will return
+ EFI_INVALID_PARAMETER
+
config EFI_MM_COMM_TEE
bool "UEFI variables storage service via the trusted world"
depends on OPTEE
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index a61c9a77b13f..dde083b09665 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -127,6 +127,10 @@ efi_status_t efi_init_runtime_supported(void)
[PATCH v3 0/4]
Hi! This is v3 of SetVariable at runtime [0] Nothing changed drastically from v2. A few more test cases have been added, comments/suggestions have been addressed and a bug where deleting a variable by setting 'attributes' to 0 has been fixed. Changes since v2: - Add more selftests checking for variable deletion as well as the VarToFile header format - Use unaligned sized variables on tests - Add a new function to get the variable entry length instead of repurposing efi_var_mem_compare() - Converted VarToFile to RO - Added a few comments requested by Heinrich - Fixed a bug where SetVariable with attributes set to 0 did not delete the variable but returned EFI_INVALID_PARAMETER instead - Run FWTS 'uefitests' and attach the log in patch #1 - Added r-b tags from Heinrich Changes since v1: - Instead of Creating VarToFile at SetVariable, create it on GetVariable. This allows us to get rid of the preallocated RT buffer, since the address is user provided - convert Set/GetVariableRT -> Set/GetVariable at runtime - return EFI_INVALID_PARAM is NV is not set at runtime - Heinrich sent me the efi_var_collect_mem() variant Changes since the RFC: - Return EFI_INVALID_PARAM if attributes are not volatile - Add EFI_WRITE_PROTECTED checks for BS, RT *only* variables - Add 2 EFI variables and allow userspace to write the file - Add selftests I also have a patch enable QueryVariableInfo [1], but I don't want to introduce new patches now. This also needs a few more testcases of its own so I'll send it once we finalize this one. [0] https://lore.kernel.org/u-boot/20240417101928.119115-1-ilias.apalodi...@linaro.org/T/ [1] https://source.denx.de/u-boot/custodians/u-boot-tpm/-/commit/ce35270aaeb93686d7e013f3b028808e8af88cc0 Regards /Ilias Ilias Apalodimas (4): efi_loader: conditionally enable SetvariableRT efi_loader: Add OS notifications for SetVariable at runtime efi_loader: add an EFI variable with the file contents efi_selftest: add tests for setvariableRT include/efi_loader.h | 4 + include/efi_variable.h| 16 +- lib/charset.c | 2 +- lib/efi_loader/Kconfig| 16 ++ lib/efi_loader/efi_runtime.c | 42 lib/efi_loader/efi_var_common.c | 6 +- lib/efi_loader/efi_var_mem.c | 151 - lib/efi_loader/efi_variable.c | 122 -- lib/efi_loader/efi_variable_tee.c | 5 - .../efi_selftest_variables_runtime.c | 211 +- 10 files changed, 495 insertions(+), 80 deletions(-) -- 2.40.1
Re: [PATCH v2 00/11] net: dwc_eth_qos: Clean up STM32 glue code and add STM32MP13xx support
On 4/18/24 1:36 PM, Patrice CHOTARD wrote: On 4/17/24 18:47, Marek Vasut wrote: On 3/26/24 1:07 PM, Marek Vasut wrote: Split off STM32 glue code from the DWMAC driver into separate file, similar to what other SoCs already do, to avoid mixing the ST specifics with generic DWMAC core code. Clean the STM32 DWMAC board code which is currently duplicated in multiple board files, move it into the newly separated glue code, since the code is not board specific, it is only generic DT parsing and generic register programming. Add STM32MP13xx support based on ST downstream patches on top, although that part is mostly rewritten from scratch. Can either of you, Patrice/Patrick, pick this series via ST tree and create a MR for Tom (possibly including the other long outstanding patches too) ? Thanks Hi Marek STM32 pull request will be done tomorrow. Thank you
