Boot from specified partition (or FS) UUID without knowing Device ID
I want to have a fallback boot situation where boot is first tried from one partition, and then from another partition (on a different device) if the first partition isn't available (eg, if the first device fails). Can I boot from a specific FS UUID or a partition UUID without knowing a particular device ID? (I'm not sure if my devices will always be detected in a repeatable order). Can fatload be used with only a partition UUID? Or can I somehow get the dev number from the UUID? Thanks in advance, Tom
Which board to select for "Rasbperry Pi 4B"
I'm guessing that many of U-boot's users are on Raspberry Pi boards? Which board should I select at the board select page: https://www.denx.de/wiki/DULG/BoardSelect -- Thanks! Tom Hale
Single-document documentation format
I'm having a lot of trouble finding the definition of certain commands, eg "fatload": https://www.denx.de/wiki/view/DULG/WebSearch?search=fatload=on=text Is there an updated single page that I can search if I can't work out how to make search work for me? -- Thanks, Tom Hale
Re: [PATCH] test/py: efi_capsule: Handle expected reset after capsule on disk
Hi Simon, Thank you for your reply. 2022年2月18日(金) 2:56 Simon Glass : > > Hi Masami, > > On Wed, 16 Feb 2022 at 18:11, Masami Hiramatsu > wrote: > > > > Hi Simon, > > > > Let me confirm your point. > > So are you concerning the 'real' reset for the capsule update test > > case itself or this patch? > > > > I'm actually learning how the test is working, so please help me to > > understand how I can solve it. > > > > There are 3 environments to run the test, sandbox, Qemu, and a real board. > > If we reset a sandbox, it will continue to run (just restart itself), > > Here you should be able to avoid doing a reset. See > dm_test_sysreset_base() which tests sysreset drivers on sandbox. Would you mean that reset-after-capsule-on-disk itself should not make a reset on sandbox? In dm_test_sysreset_base(), I can see the below code, this means sysreset_request() will not execute real reset, but just mimic the reset, right? state->sysreset_allowed[SYSRESET_WARM] = true; ut_asserteq(-EINPROGRESS, sysreset_request(dev, SYSRESET_WARM)); state->sysreset_allowed[SYSRESET_WARM] = false; > > but Qemu and real board will cause a real reset and it will terminate > > the qemu or stop the board (depends on how it is implemented). Thus, > > if a command or boot process will cause a reset, it will need a > > special care (maybe respawn?). > > Here you need to worry about the surrounding automation logic which > could be tbot of the U-Boot pytest hooks. I suggest you avoid this and > handle it some other way, without reset. Hmm, would you mean adding a runtime flag to sandbox so that it will not does real reset but just showing some token on console like "sandbox fake reset done." ? > > Since the capsule update testcase only runs on sandbox, it will not > > cause real reset. But maybe it is possible to support running on Qemu. > > Maybe, but I don't think you should worry about that, at least for > now. The sandbox test is enough. > > > > > Current my test patch (and capsule update testcase itself) doesn't > > handle the real reset case correctly even on Qemu. The Qemu needs > > spawn a new instance and re-connect the console when the reset > > happens. > > Indeed. > > > > > If so, I think there are 2 issues to be solved. > > 1. change the capsule update testcase runable on Qemu > > 2. change my patch to handle the real reset correctly (not only > > waiting for the next boot, but also respawn it again) > > > > Do I understand correctly? > > I think the best approach is to get your test running on sandbox, with > the faked reset. Don't worry about the other cases as we don't support > them. OK. Thank you, > > Regards, > Simon > > > > > > Thank you, > > > > 2022年2月17日(木) 2:53 Simon Glass : > > > > > > Hi Heinrich, > > > > > > On Wed, 16 Feb 2022 at 10:50, Heinrich Schuchardt > > > wrote: > > > > > > > > On 2/16/22 16:46, Tom Rini wrote: > > > > > On Wed, Feb 16, 2022 at 04:32:40PM +0100, Heinrich Schuchardt wrote: > > > > >> On 2/16/22 16:26, Simon Glass wrote: > > > > >>> Hi Masami, > > > > >>> > > > > >>> On Tue, 15 Feb 2022 at 02:05, Masami Hiramatsu > > > > >>> wrote: > > > > > > > > Since now the capsule_on_disk will restart the u-boot sandbox right > > > > after the capsule update, if CONFIG_EFI_CAPSULE_ON_DISK_EARLY=y, > > > > the > > > > boot with a new capsule file will repeat reboot sequence. On the > > > > other hand, if CONFIG_EFI_CAPSULE_ON_DISK_EARLY=n, the 'env print > > > > -e' > > > > command will execute the capsule update on disk and reboot. > > > > > > > > Thus this update the uboot_console for those 2 cases; > > > > > > > > - restart_uboot(): Add expect_earlyreset optional parameter so > > > > that > > > > it can handle the reboot while booting. > > > > - run_command(): Add wait_for_reboot optional parameter so that > > > > it > > > > can handle the reboot after executing a command. > > > > > > > > And enable those options in the test_capsule_firmware.py test > > > > cases. > > > > > > > > Signed-off-by: Masami Hiramatsu > > > > --- > > > > .../test_efi_capsule/test_capsule_firmware.py | 39 > > > > ++-- > > > > test/py/u_boot_console_base.py | 95 > > > > +++- > > > > test/py/u_boot_console_sandbox.py |6 + > > > > 3 files changed, 102 insertions(+), 38 deletions(-) > > > > >>> > > > > >>> We have a means to avoid actually doing the reset, see the reset > > > > >>> driver. > > > > >> > > > > >> The UEFI specification requires a cold reset after a capsule is > > > > >> updated > > > > >> and before the console is reached. How could the reset driver help to > > > > >> fix the Python tests? > > > > > > > > > > Is this test going to be able to run on qemu, sandbox, real hardware, > > > > > or > > > > > all 3? The tests may well end up having to know
Re: [PATCH RFC *RFC*] dt-bindings: add U-Boot chosen for environment data phandle
On Thu, Feb 17, 2022 at 6:09 AM Rafał Miłecki wrote:
>
> From: Rafał Miłecki
>
> This is RFC and request for a help & discussion.
>
> While reviewing patch for U-Boot env binding it has been mentioned that:
>
> 1. /Processing/ whole DT in U-Boot may be too much work
>Handling flash devices, partitions, their formats & NVMEM may require
>too many U-Boot drivers involved.
>
> 2. It'd be nice to have env data storage devices pointed in chosen
>
> I wrote this hacky PATCH to give a rough idea how it could look like.
>
> Please review this and let me know:
> 1. If solution with chosen + phandles is acceptable
> 2. How to properly name .yaml file
> 3. Where it put it
>
> Signed-off-by: Rafał Miłecki
> ---
> .../devicetree/bindings/u-boot,chosen.yaml| 39 +++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/u-boot,chosen.yaml
>
> diff --git a/Documentation/devicetree/bindings/u-boot,chosen.yaml
> b/Documentation/devicetree/bindings/u-boot,chosen.yaml
> new file mode 100644
> index ..8369da91193d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/u-boot,chosen.yaml
> @@ -0,0 +1,39 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/u-boot,chosen.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: U-Boot setup
> +
> +maintainers:
> + - Rafał Miłecki
> +
> +properties:
> + u-boot,env:
> +$ref: /schemas/types.yaml#/definitions/phandle-array
> +description: |
> + A list of storage volumes containing U-Boot environment data.
> +
> + Env data can be stored on various kinds of storage devices, e.g.:
> + 1. Raw flash partition
> + 2. UBI volume
> +
> +additionalProperties: true
> +
> +examples:
> + - |
> +chosen {
> +u-boot,env = <>;
You should look at the u-boot config support:
https://github.com/devicetree-org/dt-schema/commit/0986f729eff0f40a66e85ab9dfb37681bf025ac4
Re: [PATCH u-boot-mvebu v2 5/5] arm: mvebu: a37xx: Add support for reading Security OTP values
On Thu, 17 Feb 2022 19:50:46 +0100
Pali Rohár wrote:
> It is not possible for the A53 core (on which U-Boot is running) to read it
> directly. For this purpose Marvell defined mbox API for sending OTP
> commands between CM3 and A53 cores.
>
> Implement these Marvell fuse reading mbox commands via U-Boot fuse API.
>
> Banks 0-43 are used for accessing Security OTP (44 rows with 67 bits via 44
> banks and words 0-2).
>
> Note that of the 67 bits, the 3 upper bits are: 1 lock bit and 2
> auxiliary bits (meant for testing during the manufacture of the SOC, as
> I understand it).
>
> Also note that the lock bit and the auxiliary bits are not readable
> via Marvell commands.
>
> With CZ.NIC's commands the lock bit is readable.
>
> Write support is not implemented yet.
>
> Signed-off-by: Pali Rohár
> ---
> arch/arm/mach-mvebu/armada3700/efuse.c | 38 --
> 1 file changed, 36 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-mvebu/armada3700/efuse.c
> b/arch/arm/mach-mvebu/armada3700/efuse.c
> index 03778f17ea49..fcf6edd08ce1 100644
> --- a/arch/arm/mach-mvebu/armada3700/efuse.c
> +++ b/arch/arm/mach-mvebu/armada3700/efuse.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #define OTP_NB_REG_BASE ((void __iomem
> *)MVEBU_REGISTER(0x12600))
> @@ -77,6 +78,40 @@ static void otp_read_parallel(void __iomem *base, u32
> *data, u32 count)
> }
> }
>
> +static int rwtm_otp_read(u8 row, u32 word, u32 *data)
> +{
> + u32 out[3];
> + u32 in[2];
> + int res = -EINVAL;
> +
> + if (word < 2) {
> + /*
> + * MBOX_CMD_OTP_READ_32B command is supported by Marvell
> + * fuse.bin firmware and also by new CZ.NIC wtmi firmware.
> + * This command returns raw bits without ECC corrections.
> + * It does not provide access to the lock bit.
> + */
> + in[0] = row;
> + in[1] = word * 32;
> + res = mbox_do_cmd(MBOX_CMD_OTP_READ_32B, in, 2, out, 2);
> + if (!res)
> + *data = out[0];
> + } else if (word == 2) {
> + /*
> + * MBOX_CMD_OTP_READ command is supported only by CZ.NIC wtmi
> + * firmware and provide
nitpick: *provides
Reviewed-by: Marek Behún
Re: Please pull u-boot-marvell/master
On Thu, Feb 17, 2022 at 04:46:20PM +0100, Stefan Roese wrote: > Hi Tom, > > please pull the next batch of mostly Marvell kwboot & MVEBU > related fixes and enhancement patches: > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH u-boot-mvebu v2 1/5] arm: mvebu: a37xx: Add support for reading NB and SB fuse OTP value
Implement reading NB and SB fuses of Armada 37xx SOC via U-Boot fuse API.
Banks 0-43 are reserved for accessing Security OTP (not implemented yet).
Bank 44 is used for accessing North Bridge OTP (69 bits via words 0-2).
Bank 45 is used for accessing South Bridge OTP (97 bits via words 0-3).
Write support is not implemented yet because it looks like that both North
and South Bridge OTPs are already burned in factory with some data. The
meaning of some bits of North Bridge is documented in WTMI source code.
The meaning of bits in South Bridge is unknown.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
arch/arm/mach-mvebu/Kconfig | 1 +
arch/arm/mach-mvebu/Makefile| 3 +
arch/arm/mach-mvebu/armada3700/Makefile | 1 +
arch/arm/mach-mvebu/armada3700/efuse.c | 136
4 files changed, 141 insertions(+)
create mode 100644 arch/arm/mach-mvebu/armada3700/efuse.c
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index d23cc0c760f1..659c4fe2380a 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -44,6 +44,7 @@ config ARMADA_XP
config ARMADA_3700
bool
select ARM64
+ select HAVE_MVEBU_EFUSE
# Armada 7K and 8K are very similar - use only one Kconfig symbol for both
config ARMADA_8K
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index a5a20877dda6..1b451889d242 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -27,7 +27,10 @@ obj-$(CONFIG_ARMADA_375) +=
../../../drivers/ddr/marvell/axp/xor.o
obj-$(CONFIG_ARMADA_38X) += ../../../drivers/ddr/marvell/a38x/xor.o
obj-$(CONFIG_ARMADA_XP) += ../../../drivers/ddr/marvell/axp/xor.o
obj-$(CONFIG_ARMADA_MSYS) += ../../../drivers/ddr/marvell/axp/xor.o
+
+ifdef CONFIG_ARMADA_38X
obj-$(CONFIG_MVEBU_EFUSE) += efuse.o
+endif
extra-y += kwbimage.cfg
diff --git a/arch/arm/mach-mvebu/armada3700/Makefile
b/arch/arm/mach-mvebu/armada3700/Makefile
index 031b3e854e36..cd74726cc778 100644
--- a/arch/arm/mach-mvebu/armada3700/Makefile
+++ b/arch/arm/mach-mvebu/armada3700/Makefile
@@ -3,3 +3,4 @@
# Copyright (C) 2016 Stefan Roese
obj-y = cpu.o
+obj-$(CONFIG_MVEBU_EFUSE) += efuse.o
diff --git a/arch/arm/mach-mvebu/armada3700/efuse.c
b/arch/arm/mach-mvebu/armada3700/efuse.c
new file mode 100644
index ..03778f17ea49
--- /dev/null
+++ b/arch/arm/mach-mvebu/armada3700/efuse.c
@@ -0,0 +1,136 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) 2017 Marvell International Ltd.
+ * (C) 2021 Pali Rohár
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define OTP_NB_REG_BASE((void __iomem
*)MVEBU_REGISTER(0x12600))
+#define OTP_SB_REG_BASE((void __iomem
*)MVEBU_REGISTER(0x1A200))
+
+#define OTP_CONTROL_OFF0x00
+#define OTP_MODE_BIT BIT(15)
+#define OTP_RPTR_RST_BIT BIT(14)
+#define OTP_POR_B_BITBIT(13)
+#define OTP_PRDT_BIT BIT(3)
+#define OTP_READ_PORT_OFF 0x04
+#define OTP_READ_POINTER_OFF 0x08
+#define OTP_PTR_INC_BIT BIT(8)
+
+static void otp_read_parallel(void __iomem *base, u32 *data, u32 count)
+{
+ u32 regval;
+
+ /* 1. Clear OTP_MODE_NB to parallel mode */
+ regval = readl(base + OTP_CONTROL_OFF);
+ regval &= ~OTP_MODE_BIT;
+ writel(regval, base + OTP_CONTROL_OFF);
+
+ /* 2. Set OTP_POR_B_NB enter normal operation */
+ regval = readl(base + OTP_CONTROL_OFF);
+ regval |= OTP_POR_B_BIT;
+ writel(regval, base + OTP_CONTROL_OFF);
+
+ /* 3. Set OTP_PTR_INC_NB to auto-increment pointer after each read */
+ regval = readl(base + OTP_READ_POINTER_OFF);
+ regval |= OTP_PTR_INC_BIT;
+ writel(regval, base + OTP_READ_POINTER_OFF);
+
+ /* 4. Set OTP_RPTR_RST_NB, then clear the same field */
+ regval = readl(base + OTP_CONTROL_OFF);
+ regval |= OTP_RPTR_RST_BIT;
+ writel(regval, base + OTP_CONTROL_OFF);
+
+ regval = readl(base + OTP_CONTROL_OFF);
+ regval &= ~OTP_RPTR_RST_BIT;
+ writel(regval, base + OTP_CONTROL_OFF);
+
+ /* 5. Toggle OTP_PRDT_NB
+* a. Set OTP_PRDT_NB to 1.
+* b. Clear OTP_PRDT_NB to 0.
+* c. Wait for a minimum of 100 ns.
+* d. Set OTP_PRDT_NB to 1
+*/
+ regval = readl(base + OTP_CONTROL_OFF);
+ regval |= OTP_PRDT_BIT;
+ writel(regval, base + OTP_CONTROL_OFF);
+
+ regval = readl(base + OTP_CONTROL_OFF);
+ regval &= ~OTP_PRDT_BIT;
+ writel(regval, base + OTP_CONTROL_OFF);
+
+ ndelay(100);
+
+ regval = readl(base + OTP_CONTROL_OFF);
+ regval |= OTP_PRDT_BIT;
+ writel(regval, base + OTP_CONTROL_OFF);
+
+ while (count-- > 0) {
+ /* 6. Read the content of OTP 32-bits at a time */
+ ndelay(10);
+ *(data++) = readl(base + OTP_READ_PORT_OFF);
+ }
+}
+
+/*
+ * Banks 0-43 are
[PATCH u-boot-mvebu v2 4/5] arm: mvebu: a37xx: Extend mbox_do_cmd() code
Allow to specify input parameters, define all available mbox commands
supported by CZ.NIC's secure firmware and also Marvell's fuse.bin firmware
and fix parsing response from Marvell OTP commands.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
arch/arm/mach-mvebu/armada3700/mbox.c | 20 ++--
arch/arm/mach-mvebu/include/mach/mbox.h | 19 ++-
board/CZ.NIC/turris_mox/mox_sp.c| 4 ++--
3 files changed, 38 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-mvebu/armada3700/mbox.c
b/arch/arm/mach-mvebu/armada3700/mbox.c
index cb86b967c2eb..eb1f82845f0f 100644
--- a/arch/arm/mach-mvebu/armada3700/mbox.c
+++ b/arch/arm/mach-mvebu/armada3700/mbox.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright (C) 2018 Marek Behun
+ * Copyright (C) 2021 Pali Rohár
*/
#include
@@ -15,6 +16,7 @@
#define RWTM_CMD (RWTM_BASE + 0x40)
#define RWTM_CMD_RETSTATUS (RWTM_BASE + 0x80)
#define RWTM_CMD_STATUS(i) (size_t)(RWTM_BASE + 0x84 + (i) * 4)
+#define MAX_ARGS 16
#define RWTM_HOST_INT_RESET(RWTM_BASE + 0xc8)
#define RWTM_HOST_INT_MASK (RWTM_BASE + 0xcc)
@@ -27,15 +29,27 @@
#define MBOX_STS_ERROR(s) ((s) & (3 << 30))
#define MBOX_STS_VALUE(s) (((s) >> 10) & 0xf)
#define MBOX_STS_CMD(s)((s) & 0x3ff)
+#define MBOX_STS_MARVELL_ERROR(s) ((s) == 0 ? 0 : \
+(s) == 2 ? ETIMEDOUT : \
+(s) == 3 ? EINVAL: \
+(s) == 4 ? ENOSYS: \
+ EIO)
-int mbox_do_cmd(enum mbox_cmd cmd, u32 *out, int nout)
+int mbox_do_cmd(enum mbox_cmd cmd, u32 *in, int nin, u32 *out, int nout)
{
const int tries = 50;
int i;
u32 status;
+ if (nin > MAX_ARGS || nout > MAX_ARGS)
+ return -EINVAL;
+
clrbits_le32(RWTM_HOST_INT_MASK, SP_CMD_COMPLETE);
+ for (i = 0; i < nin; i++)
+ writel(in[i], RWTM_CMD_PARAM(i));
+ for (; i < MAX_ARGS; i++)
+ writel(0x0, RWTM_CMD_PARAM(i));
writel(cmd, RWTM_CMD);
for (i = 0; i < tries; ++i) {
@@ -57,9 +71,11 @@ int mbox_do_cmd(enum mbox_cmd cmd, u32 *out, int nout)
setbits_le32(RWTM_HOST_INT_RESET, SP_CMD_COMPLETE);
if (MBOX_STS_CMD(status) != cmd)
- return -EIO;
+ return -MBOX_STS_MARVELL_ERROR(status);
else if (MBOX_STS_ERROR(status) == MBOX_STS_FAIL)
return -(int)MBOX_STS_VALUE(status);
+ else if (MBOX_STS_ERROR(status) == MBOX_STS_BADCMD)
+ return -ENOSYS;
else if (MBOX_STS_ERROR(status) != MBOX_STS_SUCCESS)
return -EIO;
else
diff --git a/arch/arm/mach-mvebu/include/mach/mbox.h
b/arch/arm/mach-mvebu/include/mach/mbox.h
index 981204935832..f1cb55f2bfe7 100644
--- a/arch/arm/mach-mvebu/include/mach/mbox.h
+++ b/arch/arm/mach-mvebu/include/mach/mbox.h
@@ -1,6 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0+ */
/*
* Copyright (C) 2018 Marek Behun
+ * Copyright (C) 2021 Pali Rohár
*/
#ifndef _MVEBU_MBOX_H
@@ -16,8 +17,24 @@ enum mbox_cmd {
MBOX_CMD_OTP_READ,
MBOX_CMD_OTP_WRITE,
+
+ MBOX_CMD_REBOOT,
+
+ /* OTP read commands supported by Marvell fuse.bin firmware */
+ MBOX_CMD_OTP_READ_1B= 257,
+ MBOX_CMD_OTP_READ_8B,
+ MBOX_CMD_OTP_READ_32B,
+ MBOX_CMD_OTP_READ_64B,
+ MBOX_CMD_OTP_READ_256B,
+
+ /* OTP write commands supported by Marvell fuse.bin firmware */
+ MBOX_CMD_OTP_WRITE_1B = 513,
+ MBOX_CMD_OTP_WRITE_8B,
+ MBOX_CMD_OTP_WRITE_32B,
+ MBOX_CMD_OTP_WRITE_64B,
+ MBOX_CMD_OTP_WRITE_256B,
};
-int mbox_do_cmd(enum mbox_cmd cmd, u32 *in, int nout);
+int mbox_do_cmd(enum mbox_cmd cmd, u32 *in, int nin, u32 *out, int nout);
#endif
diff --git a/board/CZ.NIC/turris_mox/mox_sp.c b/board/CZ.NIC/turris_mox/mox_sp.c
index 4de067bbebbb..93e96b014fca 100644
--- a/board/CZ.NIC/turris_mox/mox_sp.c
+++ b/board/CZ.NIC/turris_mox/mox_sp.c
@@ -19,7 +19,7 @@ const char *mox_sp_get_ecdsa_public_key(void)
if (public_key[0])
return public_key;
- res = mbox_do_cmd(MBOX_CMD_ECDSA_PUB_KEY, out, 16);
+ res = mbox_do_cmd(MBOX_CMD_ECDSA_PUB_KEY, NULL, 0, out, 16);
if (res < 0)
return NULL;
@@ -47,7 +47,7 @@ int mbox_sp_get_board_info(u64 *sn, u8 *mac1, u8 *mac2, int
*bv, int *ram)
u32 out[8];
int res;
- res = mbox_do_cmd(MBOX_CMD_BOARD_INFO, out, 8);
+ res = mbox_do_cmd(MBOX_CMD_BOARD_INFO, NULL, 0, out, 8);
if (res < 0)
return res;
--
2.20.1
[PATCH u-boot-mvebu v2 3/5] arm: mvebu: a37xx: Move generic mbox code to arch/arm/mach-mvebu
Generic A3720 mbox code is currently in Turris Mox specific board file
board/CZ.NIC/turris_mox/mox_sp.c. Move it to board independent arch file
arch/arm/mach-mvebu/armada3700/mbox.c.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
arch/arm/mach-mvebu/armada3700/Makefile | 2 +-
arch/arm/mach-mvebu/armada3700/mbox.c | 67
arch/arm/mach-mvebu/include/mach/mbox.h | 23 +
board/CZ.NIC/turris_mox/mox_sp.c| 69 +
4 files changed, 92 insertions(+), 69 deletions(-)
create mode 100644 arch/arm/mach-mvebu/armada3700/mbox.c
create mode 100644 arch/arm/mach-mvebu/include/mach/mbox.h
diff --git a/arch/arm/mach-mvebu/armada3700/Makefile
b/arch/arm/mach-mvebu/armada3700/Makefile
index cd74726cc778..98350a41e04b 100644
--- a/arch/arm/mach-mvebu/armada3700/Makefile
+++ b/arch/arm/mach-mvebu/armada3700/Makefile
@@ -2,5 +2,5 @@
#
# Copyright (C) 2016 Stefan Roese
-obj-y = cpu.o
+obj-y = cpu.o mbox.o
obj-$(CONFIG_MVEBU_EFUSE) += efuse.o
diff --git a/arch/arm/mach-mvebu/armada3700/mbox.c
b/arch/arm/mach-mvebu/armada3700/mbox.c
new file mode 100644
index ..cb86b967c2eb
--- /dev/null
+++ b/arch/arm/mach-mvebu/armada3700/mbox.c
@@ -0,0 +1,67 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Marek Behun
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define RWTM_BASE (MVEBU_REGISTER(0xb))
+#define RWTM_CMD_PARAM(i) (size_t)(RWTM_BASE + (i) * 4)
+#define RWTM_CMD (RWTM_BASE + 0x40)
+#define RWTM_CMD_RETSTATUS (RWTM_BASE + 0x80)
+#define RWTM_CMD_STATUS(i) (size_t)(RWTM_BASE + 0x84 + (i) * 4)
+
+#define RWTM_HOST_INT_RESET(RWTM_BASE + 0xc8)
+#define RWTM_HOST_INT_MASK (RWTM_BASE + 0xcc)
+#define SP_CMD_COMPLETEBIT(0)
+
+#define MBOX_STS_SUCCESS (0x0 << 30)
+#define MBOX_STS_FAIL (0x1 << 30)
+#define MBOX_STS_BADCMD(0x2 << 30)
+#define MBOX_STS_LATER (0x3 << 30)
+#define MBOX_STS_ERROR(s) ((s) & (3 << 30))
+#define MBOX_STS_VALUE(s) (((s) >> 10) & 0xf)
+#define MBOX_STS_CMD(s)((s) & 0x3ff)
+
+int mbox_do_cmd(enum mbox_cmd cmd, u32 *out, int nout)
+{
+ const int tries = 50;
+ int i;
+ u32 status;
+
+ clrbits_le32(RWTM_HOST_INT_MASK, SP_CMD_COMPLETE);
+
+ writel(cmd, RWTM_CMD);
+
+ for (i = 0; i < tries; ++i) {
+ mdelay(10);
+ if (readl(RWTM_HOST_INT_RESET) & SP_CMD_COMPLETE)
+ break;
+ }
+
+ if (i == tries) {
+ /* if timed out, don't read status */
+ setbits_le32(RWTM_HOST_INT_RESET, SP_CMD_COMPLETE);
+ return -ETIMEDOUT;
+ }
+
+ for (i = 0; i < nout; ++i)
+ out[i] = readl(RWTM_CMD_STATUS(i));
+ status = readl(RWTM_CMD_RETSTATUS);
+
+ setbits_le32(RWTM_HOST_INT_RESET, SP_CMD_COMPLETE);
+
+ if (MBOX_STS_CMD(status) != cmd)
+ return -EIO;
+ else if (MBOX_STS_ERROR(status) == MBOX_STS_FAIL)
+ return -(int)MBOX_STS_VALUE(status);
+ else if (MBOX_STS_ERROR(status) != MBOX_STS_SUCCESS)
+ return -EIO;
+ else
+ return MBOX_STS_VALUE(status);
+}
diff --git a/arch/arm/mach-mvebu/include/mach/mbox.h
b/arch/arm/mach-mvebu/include/mach/mbox.h
new file mode 100644
index ..981204935832
--- /dev/null
+++ b/arch/arm/mach-mvebu/include/mach/mbox.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2018 Marek Behun
+ */
+
+#ifndef _MVEBU_MBOX_H
+#define _MVEBU_MBOX_H
+
+enum mbox_cmd {
+ MBOX_CMD_GET_RANDOM = 1,
+ MBOX_CMD_BOARD_INFO,
+ MBOX_CMD_ECDSA_PUB_KEY,
+ MBOX_CMD_HASH,
+ MBOX_CMD_SIGN,
+ MBOX_CMD_VERIFY,
+
+ MBOX_CMD_OTP_READ,
+ MBOX_CMD_OTP_WRITE,
+};
+
+int mbox_do_cmd(enum mbox_cmd cmd, u32 *in, int nout);
+
+#endif
diff --git a/board/CZ.NIC/turris_mox/mox_sp.c b/board/CZ.NIC/turris_mox/mox_sp.c
index cc57b9f095f7..4de067bbebbb 100644
--- a/board/CZ.NIC/turris_mox/mox_sp.c
+++ b/board/CZ.NIC/turris_mox/mox_sp.c
@@ -8,74 +8,7 @@
#include
#include
#include
-
-#define RWTM_BASE (MVEBU_REGISTER(0xb))
-#define RWTM_CMD_PARAM(i) (size_t)(RWTM_BASE + (i) * 4)
-#define RWTM_CMD (RWTM_BASE + 0x40)
-#define RWTM_CMD_RETSTATUS (RWTM_BASE + 0x80)
-#define RWTM_CMD_STATUS(i) (size_t)(RWTM_BASE + 0x84 + (i) * 4)
-
-#define RWTM_HOST_INT_RESET(RWTM_BASE + 0xc8)
-#define RWTM_HOST_INT_MASK (RWTM_BASE + 0xcc)
-#define SP_CMD_COMPLETEBIT(0)
-
-#define MBOX_STS_SUCCESS (0x0 << 30)
-#define MBOX_STS_FAIL (0x1 << 30)
-#define MBOX_STS_BADCMD(0x2 << 30)
-#define MBOX_STS_LATER (0x3 << 30)
-#define MBOX_STS_ERROR(s) ((s) & (3
[PATCH u-boot-mvebu v2 5/5] arm: mvebu: a37xx: Add support for reading Security OTP values
It is not possible for the A53 core (on which U-Boot is running) to read it
directly. For this purpose Marvell defined mbox API for sending OTP
commands between CM3 and A53 cores.
Implement these Marvell fuse reading mbox commands via U-Boot fuse API.
Banks 0-43 are used for accessing Security OTP (44 rows with 67 bits via 44
banks and words 0-2).
Note that of the 67 bits, the 3 upper bits are: 1 lock bit and 2
auxiliary bits (meant for testing during the manufacture of the SOC, as
I understand it).
Also note that the lock bit and the auxiliary bits are not readable
via Marvell commands.
With CZ.NIC's commands the lock bit is readable.
Write support is not implemented yet.
Signed-off-by: Pali Rohár
---
arch/arm/mach-mvebu/armada3700/efuse.c | 38 --
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mvebu/armada3700/efuse.c
b/arch/arm/mach-mvebu/armada3700/efuse.c
index 03778f17ea49..fcf6edd08ce1 100644
--- a/arch/arm/mach-mvebu/armada3700/efuse.c
+++ b/arch/arm/mach-mvebu/armada3700/efuse.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#define OTP_NB_REG_BASE((void __iomem
*)MVEBU_REGISTER(0x12600))
@@ -77,6 +78,40 @@ static void otp_read_parallel(void __iomem *base, u32 *data,
u32 count)
}
}
+static int rwtm_otp_read(u8 row, u32 word, u32 *data)
+{
+ u32 out[3];
+ u32 in[2];
+ int res = -EINVAL;
+
+ if (word < 2) {
+ /*
+* MBOX_CMD_OTP_READ_32B command is supported by Marvell
+* fuse.bin firmware and also by new CZ.NIC wtmi firmware.
+* This command returns raw bits without ECC corrections.
+* It does not provide access to the lock bit.
+*/
+ in[0] = row;
+ in[1] = word * 32;
+ res = mbox_do_cmd(MBOX_CMD_OTP_READ_32B, in, 2, out, 2);
+ if (!res)
+ *data = out[0];
+ } else if (word == 2) {
+ /*
+* MBOX_CMD_OTP_READ command is supported only by CZ.NIC wtmi
+* firmware and provide access to all bits, including lock bit.
+* But this command does ECC correction of returned bits. So
+* use it only for accessing lock bit.
+*/
+ in[0] = row;
+ res = mbox_do_cmd(MBOX_CMD_OTP_READ, in, 1, out, 3);
+ if (!res)
+ *data = out[2];
+ }
+
+ return res;
+}
+
/*
* Banks 0-43 are used for accessing Security OTP (44 rows with 67 bits via 44
banks and words 0-2)
* Bank 44 is used for accessing North Bridge OTP (69 bits via words 0-2)
@@ -96,8 +131,7 @@ int fuse_read(u32 bank, u32 word, u32 *val)
if (bank <= RWTM_MAX_BANK) {
if (word >= RWTM_ROW_WORDS)
return -EINVAL;
- /* TODO: not implemented yet */
- return -ENOSYS;
+ return rwtm_otp_read(bank, word, val);
} else if (bank == OTP_NB_BANK) {
u32 data[OTP_NB_WORDS];
if (word >= OTP_NB_WORDS)
--
2.20.1
[PATCH u-boot-mvebu v2 0/5] arm: mvebu: a37xx: Add support for reading OTP
Add support for reading NB fuse OTP, SB fuse OTP and Security OTP values via U-Boot fuse API on Armada 37xx boards. Pali Rohár (5): arm: mvebu: a37xx: Add support for reading NB and SB fuse OTP value arm: mvebu: a37xx: Enable fuse command on all Armada 3720 boards arm: mvebu: a37xx: Move generic mbox code to arch/arm/mach-mvebu arm: mvebu: a37xx: Extend mbox_do_cmd() code arm: mvebu: a37xx: Add support for reading Security OTP values arch/arm/mach-mvebu/Kconfig | 1 + arch/arm/mach-mvebu/Makefile| 3 + arch/arm/mach-mvebu/armada3700/Makefile | 3 +- arch/arm/mach-mvebu/armada3700/efuse.c | 170 arch/arm/mach-mvebu/armada3700/mbox.c | 83 ++ arch/arm/mach-mvebu/include/mach/mbox.h | 40 + board/CZ.NIC/turris_mox/mox_sp.c| 73 + configs/mvebu_db-88f3720_defconfig | 2 + configs/mvebu_espressobin-88f3720_defconfig | 2 + configs/turris_mox_defconfig| 2 + configs/uDPU_defconfig | 2 + 11 files changed, 310 insertions(+), 71 deletions(-) create mode 100644 arch/arm/mach-mvebu/armada3700/efuse.c create mode 100644 arch/arm/mach-mvebu/armada3700/mbox.c create mode 100644 arch/arm/mach-mvebu/include/mach/mbox.h -- 2.20.1
[PATCH u-boot-mvebu v2 2/5] arm: mvebu: a37xx: Enable fuse command on all Armada 3720 boards
Allow to read OTP bits via U-Boot fuse command on all Armada 3720 boards. Signed-off-by: Pali Rohár Reviewed-by: Marek Behún --- configs/mvebu_db-88f3720_defconfig | 2 ++ configs/mvebu_espressobin-88f3720_defconfig | 2 ++ configs/turris_mox_defconfig| 2 ++ configs/uDPU_defconfig | 2 ++ 4 files changed, 8 insertions(+) diff --git a/configs/mvebu_db-88f3720_defconfig b/configs/mvebu_db-88f3720_defconfig index b600217692f1..6cc90fa54266 100644 --- a/configs/mvebu_db-88f3720_defconfig +++ b/configs/mvebu_db-88f3720_defconfig @@ -5,6 +5,7 @@ CONFIG_SYS_TEXT_BASE=0x CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_NR_DRAM_BANKS=1 CONFIG_TARGET_MVEBU_ARMADA_37XX=y +CONFIG_MVEBU_EFUSE=y CONFIG_ENV_SIZE=0x1 CONFIG_ENV_OFFSET=0x3f CONFIG_ENV_SECT_SIZE=0x1 @@ -24,6 +25,7 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_ARCH_EARLY_INIT_R=y CONFIG_BOARD_EARLY_INIT_F=y # CONFIG_CMD_FLASH is not set +CONFIG_CMD_FUSE=y CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y diff --git a/configs/mvebu_espressobin-88f3720_defconfig b/configs/mvebu_espressobin-88f3720_defconfig index 4b8206a38f1b..f8196eab82e5 100644 --- a/configs/mvebu_espressobin-88f3720_defconfig +++ b/configs/mvebu_espressobin-88f3720_defconfig @@ -5,6 +5,7 @@ CONFIG_SYS_TEXT_BASE=0x CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_NR_DRAM_BANKS=1 CONFIG_TARGET_MVEBU_ARMADA_37XX=y +CONFIG_MVEBU_EFUSE=y CONFIG_ENV_SIZE=0x1 CONFIG_ENV_OFFSET=0x3F CONFIG_ENV_SECT_SIZE=0x1 @@ -26,6 +27,7 @@ CONFIG_ARCH_EARLY_INIT_R=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_LATE_INIT=y # CONFIG_CMD_FLASH is not set +CONFIG_CMD_FUSE=y CONFIG_CMD_GPIO=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y diff --git a/configs/turris_mox_defconfig b/configs/turris_mox_defconfig index 84a0b4c2b20e..25e417c94562 100644 --- a/configs/turris_mox_defconfig +++ b/configs/turris_mox_defconfig @@ -5,6 +5,7 @@ CONFIG_SYS_TEXT_BASE=0x CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_NR_DRAM_BANKS=2 CONFIG_TARGET_TURRIS_MOX=y +CONFIG_MVEBU_EFUSE=y CONFIG_ENV_SIZE=0x1 CONFIG_ENV_OFFSET=0x18 CONFIG_ENV_SECT_SIZE=0x1 @@ -31,6 +32,7 @@ CONFIG_MISC_INIT_R=y CONFIG_CMD_SHA1SUM=y CONFIG_CMD_CLK=y # CONFIG_CMD_FLASH is not set +CONFIG_CMD_FUSE=y CONFIG_CMD_GPIO=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y diff --git a/configs/uDPU_defconfig b/configs/uDPU_defconfig index b5f2115e6332..7698e080e2a2 100644 --- a/configs/uDPU_defconfig +++ b/configs/uDPU_defconfig @@ -4,6 +4,7 @@ CONFIG_ARCH_MVEBU=y CONFIG_SYS_TEXT_BASE=0x CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_TARGET_MVEBU_ARMADA_37XX=y +CONFIG_MVEBU_EFUSE=y CONFIG_ENV_SIZE=0x1 CONFIG_ENV_OFFSET=0x18 CONFIG_ENV_SECT_SIZE=0x1 @@ -29,6 +30,7 @@ CONFIG_SYS_PROMPT="uDPU>> " # CONFIG_CMD_IMI is not set # CONFIG_CMD_XIMG is not set # CONFIG_CMD_FLASH is not set +CONFIG_CMD_FUSE=y CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y -- 2.20.1
Re: [PATCH u-boot-mvebu 4/5] arm: mvebu: a37xx: Extend mbox_do_cmd() code
On Thu, 17 Feb 2022 18:13:17 +0100 Pali Rohár wrote: > On Thursday 17 February 2022 15:16:33 Marek Behún wrote: > > On Thu, 17 Feb 2022 10:26:18 +0100 > > Pali Rohár wrote: > > > > > Allow to specify input parameters, define all available mbox commands > > > supported by CZ.NIC secure firmware + Marvell fuse.bin firmware and fix > >CZ.NIC's and also Marvell's > > > parsing response from Marvell OTP commands. > > > > > > Signed-off-by: Pali Rohár > > > > ... > > > > > #define MBOX_STS_ERROR(s)((s) & (3 << 30)) > > > #define MBOX_STS_VALUE(s)(((s) >> 10) & 0xf) > > > #define MBOX_STS_CMD(s) ((s) & 0x3ff) > > > +#define MBOX_STS_MARVELL_ERROR(s)((s) == 0 ? 0 : (s) == 2 ? > > > ETIMEDOUT : (s) == 3 ? EINVAL : (s) == 4 ? ENOSYS : EIO) > > > > This is starting to become too complicated for a macro :-( > > It is straightforward switch macro. I can reformat it to be more > readable, e.g.: > > #define MBOX_STS_MARVELL_ERROR(s) ((s) == 0 ? 0 : \ >(s) == 2 ? ETIMEDOUT : \ >(s) == 3 ? EINVAL: \ >(s) == 4 ? ENOSYS: \ > EIO) I would still prefer static functions for such expressions, but this formatting is better then nothing. If you resend with this formatting, you can add my Reviewed-by. Marek
Re: [PATCH u-boot-mvebu 5/5] arm: mvebu: a37xx: Add support for reading Security OTP values
On Thu, 17 Feb 2022 17:50:31 +0100
Pali Rohár wrote:
> On Thursday 17 February 2022 15:31:10 Marek Behún wrote:
> > On Thu, 17 Feb 2022 10:26:19 +0100
> > Pali Rohár wrote:
> >
> > > Only secure CM3 core can access Security OTP. It is not possible via A53
> >
> > It is not possible for the A53 core (on which U-Boot is running) to read
> > it directly.
> >
> > > core on which is running U-Boot. Marvell for this purpose defined mbox
> > > API
> >
> > For this purpose Marvell defined...
> >
> > > for sending OTP commands between CM and A53 cores.
> >^CM3
> >
> > > Implement this Marvell mbox API via U-Boot fuse API.
> >
> > Implement these Marvell fuse reading mbox commands via
> >
> > > Banks 0-43 are used for accessing Security OTP (44 rows with 67 bits via
> > > 44
> > > banks and words 0-2).
> >
> > Note that of the 67 bits, the 3 upper bits are: 1 lock bit and 2
> > auxiliary bits (meant for testing during the manufacture of the SOC, as
> > I understand it).
> >
> > Also note that the lock bit and the auxiliary bits are not readable
> > via Marvell commands.
> >
> > With CZ.NIC's commands the lock bit is readable.
> >
> > > Write support is not implemented yet.
> > >
> > > Signed-off-by: Pali Rohár
> > > ---
> > > arch/arm/mach-mvebu/armada3700/efuse.c | 40 --
> > > 1 file changed, 38 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-mvebu/armada3700/efuse.c
> > > b/arch/arm/mach-mvebu/armada3700/efuse.c
> > > index 03778f17ea49..274d9c72c073 100644
> > > --- a/arch/arm/mach-mvebu/armada3700/efuse.c
> > > +++ b/arch/arm/mach-mvebu/armada3700/efuse.c
> > > @@ -8,6 +8,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > >
> > > #define OTP_NB_REG_BASE ((void __iomem
> > > *)MVEBU_REGISTER(0x12600))
> > > @@ -77,6 +78,42 @@ static void otp_read_parallel(void __iomem *base, u32
> > > *data, u32 count)
> > > }
> > > }
> > >
> > > +static int rwtm_otp_read(u8 row, u32 word, u32 *data)
> > > +{
> > > + u32 out[3];
> > > + u32 in[2];
> > > + int res;
> > > +
> > > + /*
> > > + * MBOX_CMD_OTP_READ_32B command is supported by Marvell fuse.bin
> > > + * firmware and also by new (yet unreleased) CZ.NIC wtmi firmware.
> >
> > Marvell's, CZ.NIC's, and drop the "(yet unreleased)", because you'll
> > need to send another patch that drops it afterwards.
> >
> > > + * But this command does not provide access to lock bit.
> > > + */
> > > + if (word < 2) {
> > > + in[0] = row;
> > > + in[1] = word * 32;
> > > + res = mbox_do_cmd(MBOX_CMD_OTP_READ_32B, in, 2, out, 2);
> > > + if (res != -ENOSYS) {
> > > + if (!res)
> > > + *data = out[0];
> > > + return res;
> > > + }
> > > + /* Fallback for old version of CZ.NIC wtmi firmware. */
> > > + }
> >
> > I am afraid this is not correct, because Marvell's firmware reads the
> > efuse without Error Correction. So it is possible for Marvell's command
> > to return different value than CZ.NIC's command.
> >
> > You need to determine whether CZ.NIC's command is supported, and use it
> > if it is, otherwise use Marvell's command. Or you need to define
> > whether and when the Error Correction is supposed to be used, or
> > something.
>
> Seems that this U-Boot fuse API is low level API, so it probably would
> be better to always read without ECC correction (which is provided by
> Marvell OTP API). As ECC is stored in other bits, it is possible to read
> everything needed for ECC correction via this API.
>
> This could simplify patch: Lock bit read via CZ.NIC API (as there is no
> other API) and other bits read via Marvell API (which is going to be
> supported also by CZ.NIC firmware).
Ok, as long as turris_mox.c reads OTP with Error Correction, fuse can
be kept low level.
Marek
> > But doing what you are doing here can make Turris MOX boards read
> > different values. I know of at least one board where serial number or
> > MAC address needs Error Correction.
> >
> > Marek
Re: [PATCH] test/py: efi_capsule: Handle expected reset after capsule on disk
Hi Masami,
On Wed, 16 Feb 2022 at 18:11, Masami Hiramatsu
wrote:
>
> Hi Simon,
>
> Let me confirm your point.
> So are you concerning the 'real' reset for the capsule update test
> case itself or this patch?
>
> I'm actually learning how the test is working, so please help me to
> understand how I can solve it.
>
> There are 3 environments to run the test, sandbox, Qemu, and a real board.
> If we reset a sandbox, it will continue to run (just restart itself),
Here you should be able to avoid doing a reset. See
dm_test_sysreset_base() which tests sysreset drivers on sandbox.
> but Qemu and real board will cause a real reset and it will terminate
> the qemu or stop the board (depends on how it is implemented). Thus,
> if a command or boot process will cause a reset, it will need a
> special care (maybe respawn?).
Here you need to worry about the surrounding automation logic which
could be tbot of the U-Boot pytest hooks. I suggest you avoid this and
handle it some other way, without reset.
>
> Since the capsule update testcase only runs on sandbox, it will not
> cause real reset. But maybe it is possible to support running on Qemu.
Maybe, but I don't think you should worry about that, at least for
now. The sandbox test is enough.
>
> Current my test patch (and capsule update testcase itself) doesn't
> handle the real reset case correctly even on Qemu. The Qemu needs
> spawn a new instance and re-connect the console when the reset
> happens.
Indeed.
>
> If so, I think there are 2 issues to be solved.
> 1. change the capsule update testcase runable on Qemu
> 2. change my patch to handle the real reset correctly (not only
> waiting for the next boot, but also respawn it again)
>
> Do I understand correctly?
I think the best approach is to get your test running on sandbox, with
the faked reset. Don't worry about the other cases as we don't support
them.
Regards,
Simon
>
> Thank you,
>
> 2022年2月17日(木) 2:53 Simon Glass :
> >
> > Hi Heinrich,
> >
> > On Wed, 16 Feb 2022 at 10:50, Heinrich Schuchardt
> > wrote:
> > >
> > > On 2/16/22 16:46, Tom Rini wrote:
> > > > On Wed, Feb 16, 2022 at 04:32:40PM +0100, Heinrich Schuchardt wrote:
> > > >> On 2/16/22 16:26, Simon Glass wrote:
> > > >>> Hi Masami,
> > > >>>
> > > >>> On Tue, 15 Feb 2022 at 02:05, Masami Hiramatsu
> > > >>> wrote:
> > >
> > > Since now the capsule_on_disk will restart the u-boot sandbox right
> > > after the capsule update, if CONFIG_EFI_CAPSULE_ON_DISK_EARLY=y, the
> > > boot with a new capsule file will repeat reboot sequence. On the
> > > other hand, if CONFIG_EFI_CAPSULE_ON_DISK_EARLY=n, the 'env print -e'
> > > command will execute the capsule update on disk and reboot.
> > >
> > > Thus this update the uboot_console for those 2 cases;
> > >
> > > - restart_uboot(): Add expect_earlyreset optional parameter so
> > > that
> > > it can handle the reboot while booting.
> > > - run_command(): Add wait_for_reboot optional parameter so that it
> > > can handle the reboot after executing a command.
> > >
> > > And enable those options in the test_capsule_firmware.py test cases.
> > >
> > > Signed-off-by: Masami Hiramatsu
> > > ---
> > > .../test_efi_capsule/test_capsule_firmware.py | 39 ++--
> > > test/py/u_boot_console_base.py | 95
> > > +++-
> > > test/py/u_boot_console_sandbox.py |6 +
> > > 3 files changed, 102 insertions(+), 38 deletions(-)
> > > >>>
> > > >>> We have a means to avoid actually doing the reset, see the reset
> > > >>> driver.
> > > >>
> > > >> The UEFI specification requires a cold reset after a capsule is updated
> > > >> and before the console is reached. How could the reset driver help to
> > > >> fix the Python tests?
> > > >
> > > > Is this test going to be able to run on qemu, sandbox, real hardware, or
> > > > all 3? The tests may well end up having to know a bit more, sadly,
> > > > about the type of system they're testing.
> > > >
> > > Currently the test will only run on the sandbox in Gitlab (see usage of
> > > @pytest.mark.boardspec('sandbox') in test/py/tests/test_efi_capsule/).
> >
> > Let me know if you need help reworking this patch to operate on
> > sandbox without a 'real' reset.
> >
> > Regards,
> > Simon
>
>
>
> --
> Masami Hiramatsu
Re: [PATCH] lib: acpi: rename dsdt.c to acpi_write_dsdt.c
Hi Philippe,
On Thu, 17 Feb 2022 at 09:10, Philippe Reynes
wrote:
>
> There is a conflict between the static file
> lib/acpi/dsdt.c and the file dsdt.c generated
> dynamicaly by scripts/Makefile.lib. When a
> mrproper is done, the static file dsdt.c is
> removed. If a build with acpi enabled is
> launched after, the following error is raised:
>
> CC lib/acpi/acpi_table.o
> make[2]: *** No rule to make target 'lib/acpi/dsdt.asl', needed by
> 'lib/acpi/dsdt.c'. Stop.
> scripts/Makefile.build:394: recipe for target 'lib/acpi' failed
>
> To avoid such error, the static file dsdt.c
> is renamed to acpi_write_dsdt.c.
>
> Signed-off-by: Philippe Reynes
> ---
> lib/acpi/Makefile | 2 +-
> lib/acpi/{dsdt.c => acpi_write_dsdt.c} | 0
> 2 files changed, 1 insertion(+), 1 deletion(-)
> rename lib/acpi/{dsdt.c => acpi_write_dsdt.c} (100%)
Reviewed-by: Simon Glass
I would prefer that we change the 'rm' to be deterministic in this
case, as we do with other filenames. One way would be to change the
Makefile.lib rule to:
$(obj)/dsdt_generated.c:$(src)/dsdt.asl
then at least the generated file has a name that distinguishes it.
Regards,
Simon
Re: [PATCH] lib: acpi: rename dsdt.c to acpi_write_dsdt.c
On Thu, 2022-02-17 at 17:10 +0100, Philippe Reynes wrote:
> There is a conflict between the static file
> lib/acpi/dsdt.c and the file dsdt.c generated
> dynamicaly by scripts/Makefile.lib. When a
> mrproper is done, the static file dsdt.c is
> removed. If a build with acpi enabled is
> launched after, the following error is raised:
>
> CC lib/acpi/acpi_table.o
> make[2]: *** No rule to make target 'lib/acpi/dsdt.asl', needed by
> 'lib/acpi/dsdt.c'. Stop.
> scripts/Makefile.build:394: recipe for target 'lib/acpi' failed
>
> To avoid such error, the static file dsdt.c
> is renamed to acpi_write_dsdt.c.
Yep, this also fixes the issue I reported earlier. Thanks!
Reported-by: Marcel Ziswiler
> Signed-off-by: Philippe Reynes
Tested-by: Marcel Ziswiler
> ---
> lib/acpi/Makefile | 2 +-
> lib/acpi/{dsdt.c => acpi_write_dsdt.c} | 0
> 2 files changed, 1 insertion(+), 1 deletion(-)
> rename lib/acpi/{dsdt.c => acpi_write_dsdt.c} (100%)
>
> diff --git a/lib/acpi/Makefile b/lib/acpi/Makefile
> index 956b5a0d72..3f8c817d41 100644
> --- a/lib/acpi/Makefile
> +++ b/lib/acpi/Makefile
> @@ -15,7 +15,7 @@ obj-y += mcfg.o
>
> # Sandbox does not build a .asl file
> ifndef CONFIG_SANDBOX
> -obj-y += dsdt.o
> +obj-y += acpi_write_dsdt.o
> endif
>
> obj-y += facs.o
> diff --git a/lib/acpi/dsdt.c b/lib/acpi/acpi_write_dsdt.c
> similarity index 100%
> rename from lib/acpi/dsdt.c
> rename to lib/acpi/acpi_write_dsdt.c
Re: [PATCH u-boot-mvebu 4/5] arm: mvebu: a37xx: Extend mbox_do_cmd() code
On Thursday 17 February 2022 15:16:33 Marek Behún wrote:
> On Thu, 17 Feb 2022 10:26:18 +0100
> Pali Rohár wrote:
>
> > Allow to specify input parameters, define all available mbox commands
> > supported by CZ.NIC secure firmware + Marvell fuse.bin firmware and fix
>CZ.NIC's and also Marvell's
> > parsing response from Marvell OTP commands.
> >
> > Signed-off-by: Pali Rohár
>
> ...
>
> > #define MBOX_STS_ERROR(s) ((s) & (3 << 30))
> > #define MBOX_STS_VALUE(s) (((s) >> 10) & 0xf)
> > #define MBOX_STS_CMD(s)((s) & 0x3ff)
> > +#define MBOX_STS_MARVELL_ERROR(s) ((s) == 0 ? 0 : (s) == 2 ? ETIMEDOUT :
> > (s) == 3 ? EINVAL : (s) == 4 ? ENOSYS : EIO)
>
> This is starting to become too complicated for a macro :-(
It is straightforward switch macro. I can reformat it to be more
readable, e.g.:
#define MBOX_STS_MARVELL_ERROR(s) ((s) == 0 ? 0 : \
(s) == 2 ? ETIMEDOUT : \
(s) == 3 ? EINVAL: \
(s) == 4 ? ENOSYS: \
EIO)
> What do you think about converting all these to a static function?
> Something like
>
> static int mbox_parse_status(u32 status, u16 *cmd, u32 *value,
>bool marvell)
> {
> ...
> }
>
> >
> > #ifndef _MVEBU_MBOX_H
> > @@ -16,8 +17,24 @@ enum mbox_cmd {
> >
> > MBOX_CMD_OTP_READ,
> > MBOX_CMD_OTP_WRITE,
> > +
> > + MBOX_CMD_REBOOT,
> > +
> > + /* OTP read commands supported by Marvell fuse.bin firmware */
> Marvell's
> > + MBOX_CMD_OTP_READ_1B= 257,
> > + MBOX_CMD_OTP_READ_8B,
> > + MBOX_CMD_OTP_READ_32B,
> > + MBOX_CMD_OTP_READ_64B,
> > + MBOX_CMD_OTP_READ_256B,
> > +
> > + /* OTP write commands supported by Marvell fuse.bin firmware */
>Marvell's
Re: [PATCH] lib: acpi: rename dsdt.c to acpi_write_dsdt.c
On 2/17/22 17:10, Philippe Reynes wrote:
There is a conflict between the static file
lib/acpi/dsdt.c and the file dsdt.c generated
dynamicaly by scripts/Makefile.lib. When a
mrproper is done, the static file dsdt.c is
removed. If a build with acpi enabled is
launched after, the following error is raised:
CC lib/acpi/acpi_table.o
make[2]: *** No rule to make target 'lib/acpi/dsdt.asl', needed by
'lib/acpi/dsdt.c'. Stop.
scripts/Makefile.build:394: recipe for target 'lib/acpi' failed
To avoid such error, the static file dsdt.c
is renamed to acpi_write_dsdt.c.
Reported-by: Heinrich Schuchardt
(https://lists.denx.de/pipermail/u-boot/2022-February/475412.html)
Signed-off-by: Philippe Reynes
Thanks for fixing the issue.
Reviewed: Heinrich Schuchardt
---
lib/acpi/Makefile | 2 +-
lib/acpi/{dsdt.c => acpi_write_dsdt.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename lib/acpi/{dsdt.c => acpi_write_dsdt.c} (100%)
diff --git a/lib/acpi/Makefile b/lib/acpi/Makefile
index 956b5a0d72..3f8c817d41 100644
--- a/lib/acpi/Makefile
+++ b/lib/acpi/Makefile
@@ -15,7 +15,7 @@ obj-y += mcfg.o
# Sandbox does not build a .asl file
ifndef CONFIG_SANDBOX
-obj-y += dsdt.o
+obj-y += acpi_write_dsdt.o
endif
obj-y += facs.o
diff --git a/lib/acpi/dsdt.c b/lib/acpi/acpi_write_dsdt.c
similarity index 100%
rename from lib/acpi/dsdt.c
rename to lib/acpi/acpi_write_dsdt.c
Re: [PATCH u-boot-mvebu 5/5] arm: mvebu: a37xx: Add support for reading Security OTP values
On Thursday 17 February 2022 15:31:10 Marek Behún wrote:
> On Thu, 17 Feb 2022 10:26:19 +0100
> Pali Rohár wrote:
>
> > Only secure CM3 core can access Security OTP. It is not possible via A53
>
> It is not possible for the A53 core (on which U-Boot is running) to read
> it directly.
>
> > core on which is running U-Boot. Marvell for this purpose defined mbox API
>
> For this purpose Marvell defined...
>
> > for sending OTP commands between CM and A53 cores.
>^CM3
>
> > Implement this Marvell mbox API via U-Boot fuse API.
>
> Implement these Marvell fuse reading mbox commands via
>
> > Banks 0-43 are used for accessing Security OTP (44 rows with 67 bits via 44
> > banks and words 0-2).
>
> Note that of the 67 bits, the 3 upper bits are: 1 lock bit and 2
> auxiliary bits (meant for testing during the manufacture of the SOC, as
> I understand it).
>
> Also note that the lock bit and the auxiliary bits are not readable
> via Marvell commands.
>
> With CZ.NIC's commands the lock bit is readable.
>
> > Write support is not implemented yet.
> >
> > Signed-off-by: Pali Rohár
> > ---
> > arch/arm/mach-mvebu/armada3700/efuse.c | 40 --
> > 1 file changed, 38 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-mvebu/armada3700/efuse.c
> > b/arch/arm/mach-mvebu/armada3700/efuse.c
> > index 03778f17ea49..274d9c72c073 100644
> > --- a/arch/arm/mach-mvebu/armada3700/efuse.c
> > +++ b/arch/arm/mach-mvebu/armada3700/efuse.c
> > @@ -8,6 +8,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #define OTP_NB_REG_BASE((void __iomem
> > *)MVEBU_REGISTER(0x12600))
> > @@ -77,6 +78,42 @@ static void otp_read_parallel(void __iomem *base, u32
> > *data, u32 count)
> > }
> > }
> >
> > +static int rwtm_otp_read(u8 row, u32 word, u32 *data)
> > +{
> > + u32 out[3];
> > + u32 in[2];
> > + int res;
> > +
> > + /*
> > +* MBOX_CMD_OTP_READ_32B command is supported by Marvell fuse.bin
> > +* firmware and also by new (yet unreleased) CZ.NIC wtmi firmware.
>
> Marvell's, CZ.NIC's, and drop the "(yet unreleased)", because you'll
> need to send another patch that drops it afterwards.
>
> > +* But this command does not provide access to lock bit.
> > +*/
> > + if (word < 2) {
> > + in[0] = row;
> > + in[1] = word * 32;
> > + res = mbox_do_cmd(MBOX_CMD_OTP_READ_32B, in, 2, out, 2);
> > + if (res != -ENOSYS) {
> > + if (!res)
> > + *data = out[0];
> > + return res;
> > + }
> > + /* Fallback for old version of CZ.NIC wtmi firmware. */
> > + }
>
> I am afraid this is not correct, because Marvell's firmware reads the
> efuse without Error Correction. So it is possible for Marvell's command
> to return different value than CZ.NIC's command.
>
> You need to determine whether CZ.NIC's command is supported, and use it
> if it is, otherwise use Marvell's command. Or you need to define
> whether and when the Error Correction is supposed to be used, or
> something.
Seems that this U-Boot fuse API is low level API, so it probably would
be better to always read without ECC correction (which is provided by
Marvell OTP API). As ECC is stored in other bits, it is possible to read
everything needed for ECC correction via this API.
This could simplify patch: Lock bit read via CZ.NIC API (as there is no
other API) and other bits read via Marvell API (which is going to be
supported also by CZ.NIC firmware).
> But doing what you are doing here can make Turris MOX boards read
> different values. I know of at least one board where serial number or
> MAC address needs Error Correction.
>
> Marek
Re: Re: [PATCH v3 1/1] env: fat: Allow overriding interface, device and partition
On Fri, Feb 18, 2022 at 12:09:46AM +0800, He Yong wrote: > Yes, I have reworked the patch for v4 based on u-boot mainline Thanks! -- Tom signature.asc Description: PGP signature
[PATCH 2/4] arch: arm: dts: bcm6753: add led support
Add a node leds to support the LED IP in the
device tree of the bcm6753.
Signed-off-by: Philippe Reynes
---
arch/arm/dts/bcm6753.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/dts/bcm6753.dtsi b/arch/arm/dts/bcm6753.dtsi
index bcbb8e17da..e88ab095c2 100644
--- a/arch/arm/dts/bcm6753.dtsi
+++ b/arch/arm/dts/bcm6753.dtsi
@@ -197,5 +197,12 @@
status = "disabled";
};
+
+ leds: led-controller@ff803000 {
+ compatible = "brcm,bcm6753-leds";
+ reg = <0xff803000 0x3480>;
+
+ status = "disabled";
+ };
};
};
--
2.17.1
[PATCH 3/4] arch: arm: dts: bcm96753ref: enable led support
Enable the led in the device tree of the refboard bcm96753ref.
It also defines two leds (led_red ad led_green).
Signed-off-by: Philippe Reynes
---
arch/arm/dts/bcm96753ref.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/dts/bcm96753ref.dts b/arch/arm/dts/bcm96753ref.dts
index e27a5b552f..ca15ca5f10 100644
--- a/arch/arm/dts/bcm96753ref.dts
+++ b/arch/arm/dts/bcm96753ref.dts
@@ -78,3 +78,21 @@
brcm,nand-oob-sector-size = <16>;
};
};
+
+ {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ brcm,serial-led-en-pol;
+ brcm,serial-led-data-ppol;
+
+ led@0 {
+ reg = <0>;
+ label = "led_red";
+ };
+
+ led@1 {
+ reg = <1>;
+ label = "led_green";
+ };
+};
--
2.17.1
[PATCH 1/4] drivers: led: led_bcm6753: initial support
Add the support of the LED IP for bcm6357. This
LED IP supports blinking, fading and pulsating,
but for the moment, only blinking is supported.
Signed-off-by: Philippe Reynes
---
drivers/led/Kconfig | 7 +
drivers/led/Makefile | 1 +
drivers/led/led_bcm6753.c | 270 ++
3 files changed, 278 insertions(+)
create mode 100644 drivers/led/led_bcm6753.c
diff --git a/drivers/led/Kconfig b/drivers/led/Kconfig
index cc87fbf395..430d0760ba 100644
--- a/drivers/led/Kconfig
+++ b/drivers/led/Kconfig
@@ -28,6 +28,13 @@ config LED_BCM6358
LED HW controller accessed via MMIO registers.
HW has no blinking capabilities and up to 32 LEDs can be controlled.
+config LED_BCM6753
+ bool "LED Support for BCM6753"
+ depends on LED && ARCH_BCM6753
+ help
+ This option enables support for LEDs connected to the BCM6753
+ HW has blinking and fading capabilities and up to 32 LEDs can be
controlled.
+
config LED_BCM6858
bool "LED Support for BCM6858"
depends on LED && (ARCH_BCM68360 || ARCH_BCM6858 || ARCH_BCM63158)
diff --git a/drivers/led/Makefile b/drivers/led/Makefile
index 8e3ae7f146..2aa2c2173a 100644
--- a/drivers/led/Makefile
+++ b/drivers/led/Makefile
@@ -6,6 +6,7 @@
obj-y += led-uclass.o
obj-$(CONFIG_LED_BCM6328) += led_bcm6328.o
obj-$(CONFIG_LED_BCM6358) += led_bcm6358.o
+obj-$(CONFIG_LED_BCM6753) += led_bcm6753.o
obj-$(CONFIG_LED_BCM6858) += led_bcm6858.o
obj-$(CONFIG_$(SPL_)LED_GPIO) += led_gpio.o
obj-$(CONFIG_LED_CORTINA) += led_cortina.o
diff --git a/drivers/led/led_bcm6753.c b/drivers/led/led_bcm6753.c
new file mode 100644
index 00..a32bd8204f
--- /dev/null
+++ b/drivers/led/led_bcm6753.c
@@ -0,0 +1,270 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2022 Philippe Reynes
+ *
+ * based on:
+ * drivers/led/led_bcm6858.c
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LEDS_MAX 32
+#define LEDS_WAIT 100
+
+/* LED Mode register */
+#define LED_MODE_REG 0x0
+#define LED_MODE_OFF 0
+#define LED_MODE_ON1
+#define LED_MODE_MASK 1
+
+/* LED Controller Global settings register */
+#define CLED_CTRL_REG 0x00
+#define CLED_CTRL_SERIAL_LED_DATA_PPOL BIT(1)
+#define CLED_CTRL_SERIAL_LED_CLK_POL BIT(2)
+#define CLED_CTRL_SERIAL_LED_EN_POLBIT(3)
+#define CLED_CTRL_SERIAL_LED_MSB_FIRST BIT(4)
+#define CLED_CTRL_MASK 0x1E
+/* LED Controller IP LED source select register */
+#define CLED_HW_LED_EN_REG 0x04
+/* Hardware LED Polarity register */
+#define CLED_HW_LED_IP_PPOL_REG0x0c
+/* Soft LED Set Register */
+#define CLED_SW_LED_IP_SET_REG 0x10
+/* Parallel LED Output Polarity Register */
+#define CLED_PLED_OP_PPOL_REG 0x18
+/* LED Channel activate register */
+#define CLED_LED_CH_ACTIVATE_REG 0x1c
+/* LED 0 Config 0 reg */
+#define CLED_LED_0_CONFIG_00x20
+/* Soft LED Clear Register */
+#define CLED_SW_LED_IP_CLEAR_REG 0x444
+/* Soft LED Status Register */
+#define CLED_SW_LED_IP_STATUS_REG 0x448
+
+/* Size of all registers used for the config of one LED */
+#define CLED_CONFIG_SIZE (4 * sizeof(u32))
+
+#define CLED_CONFIG0_MODE 0
+#define CLED_CONFIG0_MODE_MASK (BIT(0) | BIT(1))
+#define CLED_CONFIG0_MODE_STEADY 0
+#define CLED_CONFIG0_MODE_FADING 1
+#define CLED_CONFIG0_MODE_PULSATING2
+
+#define CLED_CONFIG0_FLASH_CTRL_SHIFT 3
+#define CLED_CONFIG0_FLASH_CTRL_MASK (BIT(3) | BIT(4) | BIT(5))
+
+struct bcm6753_led_priv {
+ void __iomem *regs;
+ u8 pin;
+};
+
+/*
+ * The value for flash rate are:
+ * 0 : no blinking
+ * 1 : rate is 25 Hz => 40 ms (period)
+ * 2 : rate is 12.5 Hz => 80 ms (period)
+ * 3 : rate is 6.25 Hz => 160 ms (period)
+ * 4 : rate is 3.125 Hz => 320 ms (period)
+ * 5 : rate is 1.5625 Hz => 640 ms (period)
+ * 6 : rate is 0.7815 Hz => 1280 ms (period)
+ * 7 : rate is 0.390625 Hz => 2560 ms (period)
+ */
+static const int bcm6753_flash_rate[8] = {
+ 0, 40, 80, 160, 320, 640, 1280, 2560
+};
+
+static u32 bcm6753_flash_rate_value(int period_ms)
+{
+ unsigned long value = 7;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(bcm6753_flash_rate); i++) {
+ if (period_ms <= bcm6753_flash_rate[i]) {
+ value = i;
+ break;
+ }
+ }
+
+ return value;
+}
+
+static int bcm6753_led_set_period(struct udevice *dev, int period_ms)
+{
+ struct bcm6753_led_priv *priv = dev_get_priv(dev);
+ u32 offset, shift, value;
+
+ offset = CLED_LED_0_CONFIG_0 + (CLED_CONFIG_SIZE * priv->pin);
+ value = bcm6753_flash_rate_value(period_ms);
+ shift = CLED_CONFIG0_FLASH_CTRL_SHIFT;
+
+ /* set mode steady */
+ clrbits_32(priv->regs + offset,
[PATCH 4/4] configs: bcm96753ref_ram_defconfig: enable led support
Enable the led support on the refboard bcm96753ref. Signed-off-by: Philippe Reynes --- configs/bcm96753ref_ram_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/bcm96753ref_ram_defconfig b/configs/bcm96753ref_ram_defconfig index 4474797e3d..2c4408313a 100644 --- a/configs/bcm96753ref_ram_defconfig +++ b/configs/bcm96753ref_ram_defconfig @@ -58,6 +58,7 @@ CONFIG_CLK=y CONFIG_BCM6345_GPIO=y # CONFIG_INPUT is not set CONFIG_LED=y +CONFIG_LED_BCM6753=y CONFIG_LED_BLINK=y CONFIG_LED_GPIO=y CONFIG_MISC=y -- 2.17.1
[PATCH] lib: acpi: rename dsdt.c to acpi_write_dsdt.c
There is a conflict between the static file
lib/acpi/dsdt.c and the file dsdt.c generated
dynamicaly by scripts/Makefile.lib. When a
mrproper is done, the static file dsdt.c is
removed. If a build with acpi enabled is
launched after, the following error is raised:
CC lib/acpi/acpi_table.o
make[2]: *** No rule to make target 'lib/acpi/dsdt.asl', needed by
'lib/acpi/dsdt.c'. Stop.
scripts/Makefile.build:394: recipe for target 'lib/acpi' failed
To avoid such error, the static file dsdt.c
is renamed to acpi_write_dsdt.c.
Signed-off-by: Philippe Reynes
---
lib/acpi/Makefile | 2 +-
lib/acpi/{dsdt.c => acpi_write_dsdt.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename lib/acpi/{dsdt.c => acpi_write_dsdt.c} (100%)
diff --git a/lib/acpi/Makefile b/lib/acpi/Makefile
index 956b5a0d72..3f8c817d41 100644
--- a/lib/acpi/Makefile
+++ b/lib/acpi/Makefile
@@ -15,7 +15,7 @@ obj-y += mcfg.o
# Sandbox does not build a .asl file
ifndef CONFIG_SANDBOX
-obj-y += dsdt.o
+obj-y += acpi_write_dsdt.o
endif
obj-y += facs.o
diff --git a/lib/acpi/dsdt.c b/lib/acpi/acpi_write_dsdt.c
similarity index 100%
rename from lib/acpi/dsdt.c
rename to lib/acpi/acpi_write_dsdt.c
--
2.17.1
Re:Re: [PATCH v3 1/1] env: fat: Allow overriding interface, device and partition
Yes, I have reworked the patch for v4 based on u-boot mainline At 2022-02-17 23:19:20, "Tom Rini" wrote: >On Thu, Feb 17, 2022 at 10:55:39PM +0800, hyyxohk wrote: > >> For platform which can boot on different device, this allows >> to override interface, device and partition from board code >> >> Signed-off-by: hyyxohk >> --- >> env/fat.c | 34 +++--- >> include/env_internal.h | 20 >> 2 files changed, 39 insertions(+), 15 deletions(-) > >Hi. When submitting patches, especially non-trivial ones, we follow the >Linux Kernel guidelines: >https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst >and require your name to be used in the signed-off-by line, and not a >nickname / pseudonym. Can you please re-submit? Thanks. > >-- >Tom
[PATCH v4 1/1] env: fat: Allow overriding interface, device and partition
For platform which can boot on different device, this allows
to override interface, device and partition from board code
Signed-off-by: He Yong
---
env/fat.c | 34 +++---
include/env_internal.h | 20
2 files changed, 39 insertions(+), 15 deletions(-)
diff --git a/env/fat.c b/env/fat.c
index fdccd6cd2a..6251d9649b 100644
--- a/env/fat.c
+++ b/env/fat.c
@@ -32,7 +32,12 @@
DECLARE_GLOBAL_DATA_PTR;
-static char *env_fat_device_and_part(void)
+__weak const char *env_fat_get_intf(void)
+{
+ return (const char *)CONFIG_ENV_FAT_INTERFACE;
+}
+
+__weak char *env_fat_get_dev_part(void)
{
#ifdef CONFIG_MMC
static char *part_str;
@@ -60,14 +65,15 @@ static int env_fat_save(void)
int dev, part;
int err;
loff_t size;
+ const char *ifname = env_fat_get_intf();
+ const char *dev_and_part = env_fat_get_dev_part();
err = env_export(_new);
if (err)
return err;
- part = blk_get_device_part_str(CONFIG_ENV_FAT_INTERFACE,
- env_fat_device_and_part(),
- _desc, , 1);
+ part = blk_get_device_part_str(ifname, dev_and_part,
+ _desc, , 1);
if (part < 0)
return 1;
@@ -77,8 +83,7 @@ static int env_fat_save(void)
* This printf is embedded in the messages from env_save that
* will calling it. The missing \n is intentional.
*/
- printf("Unable to use %s %d:%d... \n",
- CONFIG_ENV_FAT_INTERFACE, dev, part);
+ printf("Unable to use %s %d:%d...\n", ifname, dev, part);
return 1;
}
@@ -93,8 +98,7 @@ static int env_fat_save(void)
* This printf is embedded in the messages from env_save that
* will calling it. The missing \n is intentional.
*/
- printf("Unable to write \"%s\" from %s%d:%d... \n",
- file, CONFIG_ENV_FAT_INTERFACE, dev, part);
+ printf("Unable to write \"%s\" from %s%d:%d...\n", file,
ifname, dev, part);
return 1;
}
@@ -117,15 +121,16 @@ static int env_fat_load(void)
struct disk_partition info;
int dev, part;
int err1;
+ const char *ifname = env_fat_get_intf();
+ const char *dev_and_part = env_fat_get_dev_part();
#ifdef CONFIG_MMC
- if (!strcmp(CONFIG_ENV_FAT_INTERFACE, "mmc"))
+ if (!strcmp(ifname, "mmc"))
mmc_initialize(NULL);
#endif
- part = blk_get_device_part_str(CONFIG_ENV_FAT_INTERFACE,
- env_fat_device_and_part(),
- _desc, , 1);
+ part = blk_get_device_part_str(ifname, dev_and_part,
+ _desc, , 1);
if (part < 0)
goto err_env_relocate;
@@ -135,8 +140,7 @@ static int env_fat_load(void)
* This printf is embedded in the messages from env_save that
* will calling it. The missing \n is intentional.
*/
- printf("Unable to use %s %d:%d... \n",
- CONFIG_ENV_FAT_INTERFACE, dev, part);
+ printf("Unable to use %s %d:%d...\n", ifname, dev, part);
goto err_env_relocate;
}
@@ -154,7 +158,7 @@ static int env_fat_load(void)
* will calling it. The missing \n is intentional.
*/
printf("Unable to read \"%s\" from %s%d:%d... \n",
- CONFIG_ENV_FAT_FILE, CONFIG_ENV_FAT_INTERFACE, dev,
part);
+ CONFIG_ENV_FAT_FILE, ifname, dev, part);
goto err_env_relocate;
}
diff --git a/include/env_internal.h b/include/env_internal.h
index 07c227ecc0..b704c03363 100644
--- a/include/env_internal.h
+++ b/include/env_internal.h
@@ -245,6 +245,26 @@ const char *env_ext4_get_dev_part(void);
* Return: an enum env_location value on success, or -ve error code.
*/
enum env_location env_get_location(enum env_operation op, int prio);
+
+/**
+ * env_fat_get_intf() - Provide the interface for env in FAT
+ *
+ * It is a weak function allowing board to overidde the default interface for
+ * U-Boot env in FAT: CONFIG_ENV_FAT_INTERFACE
+ *
+ * Return: string of interface, empty if not supported
+ */
+const char *env_fat_get_intf(void);
+
+/**
+ * env_fat_get_dev_part() - Provide the device and partition for env in FAT
+ *
+ * It is a weak function allowing board to overidde the default device and
+ * partition used for U-Boot env in FAT: CONFIG_ENV_FAT_DEVICE_AND_PART
+ *
+ * Return: string of device and partition
+ */
+char *env_fat_get_dev_part(void);
#endif /* DO_DEPS_ONLY */
#endif /* _ENV_INTERNAL_H_ */
--
2.17.1
Re: ARM A53 and initial MMU mapping for EL0/1/2/3 ?
On Thu, 2022-02-17 at 15:13 +, Andre Przywara wrote: > On Fri, 11 Feb 2022 17:00:48 + > Joakim Tjernlund wrote: > > Hi, > > > On Fri, 2022-02-11 at 15:00 +0100, Joakim Tjernlund wrote: > > > On Fri, 2022-02-11 at 01:26 +, Andre Przywara wrote: > > > > On Fri, 11 Feb 2022 00:22:25 + > > > > Joakim Tjernlund wrote: > > > > > > > > > On Thu, 2022-02-10 at 22:43 +, Andre Przywara wrote: > > > > > > On Thu, 10 Feb 2022 21:58:30 + > > > > > > Joakim Tjernlund wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > > On Thu, 2022-02-10 at 10:22 +, Andre Przywara wrote: > > > > > > > > On Wed, 9 Feb 2022 12:03:47 + > > > > > > > > Joakim Tjernlund wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > On Wed, 2022-02-09 at 10:45 +, Andre Przywara wrote: > > > > > > > > > > On Wed, 9 Feb 2022 08:35:04 + > > > > > > > > > > Joakim Tjernlund wrote: > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > On Wed, 2022-02-09 at 00:33 +, Andre Przywara wrote: > > > > > > > > > > > > > > > > > > > > > > > On Tue, 8 Feb 2022 22:05:00 + > > > > > > > > > > > > Joakim Tjernlund wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi Joakim, > > > > > > > > > > > > > > > > > > > > > > > > > Trying to figure out how I should map the MMU for > > > > > > > > > > > > > normal RAM so it acessible > > > > > > > > > > > > > from all ELx security states. > > > > > > > > > > > > > > > > > > > > > > > >^^^ > > > > > > > > > > > > > > > > > > > > > > > > This does not make much sense. U-Boot is typically > > > > > > > > > > > > running in one > > > > > > > > > > > > exception level only, and sets up the page table for > > > > > > > > > > > > exactly that EL. > > > > > > > > > > > > Each EL uses a separate translation regime (with some > > > > > > > > > > > > twists for stage > > > > > > > > > > > > 2 EL2 and combined EL1/0, plus VHE). If you map your > > > > > > > > > > > > memory in EL3, then > > > > > > > > > > > > drop to EL2, the EL3 page tables become irrelevant. > > > > > > > > > > > > > > > > > > > > > > > > So in U-Boot we just set up the page tables for the EL > > > > > > > > > > > > we are running > > > > > > > > > > > > in, and leave the paging for the lower exception levels > > > > > > > > > > > > to be set up at > > > > > > > > > > > > the discretion of our payloads (kernels, hypervisors). > > > > > > > > > > > > > > > > > > > > > > > > Please not that *secure* memory is a separate concept, > > > > > > > > > > > > and handled by > > > > > > > > > > > > external hardware, typically using regions, not page > > > > > > > > > > > > tables. > > > > > > > > > > > > > > > > > > > > > > I am a beginner w.r.t ARM and Secure/Non secure so thank > > > > > > > > > > > you for above. > > > > > > > > > > > > > > > > > > > > > > The problem I have is that I boot a custom SOC into > > > > > > > > > > > u-boot and when u-boot tries > > > > > > > > > > > to boot linux I get an error exception when u-boot calls > > > > > > > > > > > armv8_switch_to_el2 to enter linux. > > > > > > > > > > > > > > > > > > > > So that means that U-Boot runs in EL3, is that the first > > > > > > > > > > and only firmware > > > > > > > > > > that you run? I think the EL3 part of U-Boot is not widely > > > > > > > > > > used and tested > > > > > > > > > > beyond the very few platforms that use it. > > > > > > > > > > > > > > > > > > Yes, u-boot is first firmware and runs in EL3(ATM, may change > > > > > > > > > once initial bringup is complete) > > > > > > > > > Maybe u-boot then lacks some critical init? Do you have an > > > > > > > > > example of a board in u-boot > > > > > > > > > that starts in EL3(from reset) using an A53 cpu? > > > > > > > > > > > > > > > > As you have probably figured out by now, the whole Layerscape > > > > > > > > family uses > > > > > > > > that approach. However most other platforms go with > > > > > > > > Trusted-Firmware as the > > > > > > > > EL3 setup and secure runtime service provider, so the U-Boot > > > > > > > > EL3 code in > > > > > > > > here is not well tested or looked after. For initial bringup it > > > > > > > > might be > > > > > > > > OK, but maybe the problems you run into are due to issues in > > > > > > > > this code. > > > > > > > > > > > > > > > > > > Do you have the exact address that fails? That should be in > > > > > > > > > > ELR, it would > > > > > > > > > > be great if you can pinpoint the exact instruction in > > > > > > > > > > macro.h that fails. > > > > > > > > > > > > > > > > > > Yes, the address is the first address where kernel is loaded > > > > > > > > > and you can branch there without problems. > > > > > > > > > > > > > > > > You mean if you load the kernel and branch to the entry point, > > > > > > > > it starts > >
Please pull u-boot-marvell/master
Hi Tom, please pull the next batch of mostly Marvell kwboot & MVEBU related fixes and enhancement patches: - a37xx: pci: Cleanup and minor fix for root port check (Pali) - pci: mvebu: Ensure that root port is always on root zero bus (Pali) - kwbimage: Fix dumping DATA registers for v0 images (Pali) - kwbimage: Support for parsing extended v0 format (Pali) - a37xx: Fix code and update DTS files to upstream version (Pali) - a37xx: Fix and extend building memory map (Pali) - ddr: marvell: a38x: fix BYTE_HOMOGENEOUS_SPLIT_OUT decision (Marek) - mvebu: Optionally reset board on DDR training failure (Marek) Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=162=results Thanks, Stefan The following changes since commit ab8903a24db11571d634ef255976bb364c3ba64d: configs: Resync with savedefconfig (2022-02-14 22:21:29 +) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-marvell.git for you to fetch changes up to 4b7db75616712606fd6b61a13df38326e41b3301: arm: mvebu: turris_omnia: Reset the board immediately on DDR training failure (2022-02-17 14:17:07 +0100) Marek Behún (3): ddr: marvell: a38x: fix BYTE_HOMOGENEOUS_SPLIT_OUT decision arm: mvebu: spl: Add option to reset the board on DDR training failure arm: mvebu: turris_omnia: Reset the board immediately on DDR training failure Pali Rohár (28): arm: a37xx: pci: Use standard register macros from pci.h arm: a37xx: pci: Cleanup macro names arm: a37xx: pci: Use dev_read_addr() arm: a37xx: pci: Ensure that root port is always on root zero bus tools: kwbimage: Fix dumping DATA registers for v0 images rtc: ds1307: Add bindings for microchip, mcp7940x phy: marvell: a3700: Update compatible string to official DT bindings usb: ehci: ehci-marvell: Update compatible string to official DT bindings watchdog: armada_37xx: Convert to official DT bindings arm: mvebu: turris_mox: Remove hardcoded ethernet node names arm: a37xx: Update sdhci pointers to official DT bindings arm: a37xx: espressobin: Move U-Boot specific partitions node to -u-boot.dtsi arm: a37xx: espressobin: Explicitly enable eMMC node in -u-boot.dtsi arm: a37xx: Update DTS files to version from upstream Linux kernel arm: a37xx: pci: Do not try to access other buses when link is down arm: a37xx: pci: Register controller also when no PCIe card is connected arm: a37xx: pci: Update comment about Command/Direct mode pci: mvebu: Ensure that root port is always on root zero bus arm: mvebu: a37xx: Fix calling build_mem_map() arm: mvebu: a37xx: Map CCI-400 and AP BootROM address space arm: mvebu: a37xx: Fix comment with name of the function tools: kwbimage: Define structures for extended kwbimage v0 headers tools: kwbimage: Fix calculating size of kwbimage v0 header tools: kwbimage: Add support for dumping extended and binary v0 headers tools: kwbimage: Do not show mkimage error message in dumpimage tools: kwbimage: Add support for NAND_BLKSZ and NAND_BADBLK_LOCATION for v0 images tools: kwbimage: Fix help how to extract DDR3 training code tools: kwbimage: Add me as an author of kwbimage arch/arm/dts/armada-371x.dtsi | 38 +- arch/arm/dts/armada-3720-db.dts| 226 +++--- arch/arm/dts/armada-3720-espressobin-u-boot.dtsi | 31 + arch/arm/dts/armada-3720-espressobin.dts | 189 + arch/arm/dts/armada-3720-espressobin.dtsi | 218 ++ arch/arm/dts/armada-3720-turris-mox.dts| 776 +++-- arch/arm/dts/armada-3720-uDPU-u-boot.dtsi | 2 +- arch/arm/dts/armada-3720-uDPU.dts | 218 +++--- arch/arm/dts/armada-372x.dtsi | 43 +- arch/arm/dts/armada-37xx.dtsi | 448 arch/arm/mach-mvebu/Kconfig| 13 + arch/arm/mach-mvebu/armada3700/cpu.c | 29 +- arch/arm/mach-mvebu/spl.c | 7 +- board/CZ.NIC/turris_mox/turris_mox.c | 22 +- configs/turris_omnia_defconfig | 1 + .../marvell/a38x/ddr3_training_centralization.c| 6 +- drivers/pci/pci-aardvark.c | 544 +++ drivers/pci/pci_mvebu.c| 52 +- drivers/phy/marvell/comphy_a3700.c | 2 +- drivers/phy/marvell/comphy_core.c | 3 +- drivers/rtc/ds1307.c | 1 + drivers/usb/host/ehci-marvell.c| 4 +- drivers/watchdog/armada-37xx-wdt.c | 7 +-
Re: [PATCH u-boot-marvell v2 0/7] tools: kwbimage: Support for parsing extended v0 format
On 2/17/22 10:43, Pali Rohár wrote: This patch series extends kwbimage v0 format support by providing ability to dump content of Dove boot images (extension of v0 format). It also fixes recognition of these images in kwboot utility (as it uses macros and inline functions from kwbimage.h header file). Implementation is based on 88AP510 Functional Specifications, Chapter 5.2 Boot Image Format, which is publicly available at: https://web.archive.org/web/20120130172443/https://www.marvell.com/application-processors/armada-500/assets/Armada-510-Functional-Spec.pdf Printing information about image.kwb is possible by: $ ./tools/dumpimage -l image.kwb Dumping image.kwb is possible by commands: $ ./tools/dumpimage -T kwbimage -p -1 -o image.cfg image.kwb $ ./tools/dumpimage -T kwbimage -p 0 -o data.bin image.kwb $ ./tools/dumpimage -T kwbimage -p 1 -o binary1.bin image.kwb $ ./tools/dumpimage -T kwbimage -p 2 -o binary2.bin image.kwb ... (where -p N is Nth binary executable header, e.g. SPL) Dove images contains more sections which in config file begins with line "MATCH ADDRESS 0xaddr MASK 0xmask VALUE 0xval" and means that section is executed only when check ((readl(addr) & mask) == (val & mask)) passes. Support for generating these kind of images is not provided. I hope that this patch series helps somebody else to implement it. Changes in v2: * Implement custom function fls4() as it is not possible to use U-Boot's fls() from asm-generic/bitsops/fls.h file when compling for Mac or Win. Pali Rohár (7): tools: kwbimage: Define structures for extended kwbimage v0 headers tools: kwbimage: Fix calculating size of kwbimage v0 header tools: kwbimage: Add support for dumping extended and binary v0 headers tools: kwbimage: Do not show mkimage error message in dumpimage tools: kwbimage: Add support for NAND_BLKSZ and NAND_BADBLK_LOCATION for v0 images tools: kwbimage: Fix help how to extract DDR3 training code tools: kwbimage: Add me as an author of kwbimage tools/kwbimage.c | 152 ++- tools/kwbimage.h | 116 2 files changed, 244 insertions(+), 24 deletions(-) Applied to u-boot-marvell/master Thanks, Stefan
Re: [PATCH u-boot-marvell v2 2/2] arm: mvebu: turris_omnia: Reset the board immediately on DDR training failure
On 2/17/22 13:54, Marek Behún wrote: From: Marek Behún The state of the current DDR training code for Armada 38x is such that we cannot be sure it will always train successfully - although after the last change we were yet unable to find a board that failed DDR training, from experience in the last 2 years we know that it is possible. The experience also tells us that in many cases the board fails training only sometimes, and after a reset the training is successful. Enable the new option that makes the board reset itself on DDR training failure immediately. Until now we called hang() in such a case, which meant that the board was reset by the MCU after 120 seconds. Signed-off-by: Marek Behún Applied to u-boot-marvell/master Thanks, Stefan --- configs/turris_omnia_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig index d6f70caeaf..010d69adcc 100644 --- a/configs/turris_omnia_defconfig +++ b/configs/turris_omnia_defconfig @@ -11,6 +11,7 @@ CONFIG_NR_DRAM_BANKS=2 CONFIG_SYS_MEMTEST_START=0x0080 CONFIG_SYS_MEMTEST_END=0x00ff CONFIG_TARGET_TURRIS_OMNIA=y +CONFIG_DDR_RESET_ON_TRAINING_FAILURE=y CONFIG_ENV_SIZE=0x1 CONFIG_ENV_OFFSET=0xF CONFIG_ENV_SECT_SIZE=0x1 Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH u-boot-marvell v2 1/2] arm: mvebu: spl: Add option to reset the board on DDR training failure
On 2/17/22 13:54, Marek Behún wrote:
From: Marek Behún
Some boards may occacionally fail DDR training. Currently we hang() in
this case. Add an option that makes the board do an immediate reset in
such a case, so that a new training is tried as soon as possible,
instead of hanging and possibly waiting for watchdog to reset the board.
(If the DDR training fails while booting the image via UART, we will
still hang - it doesn't make sense to reset in such a case, because
after reset the board will try booting from another medium, and the
UART booting utility does not expect that.)
Signed-off-by: Marek Behún
Applied to u-boot-marvell/master
Thanks,
Stefan
---
Changes since v1:
- dont reset if booting via UART, as suggested by Pali
---
arch/arm/mach-mvebu/Kconfig | 13 +
arch/arm/mach-mvebu/spl.c | 7 ++-
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index d23cc0c760..7d487f270b 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -213,6 +213,19 @@ config DDR_LOG_LEVEL
At level 3, rovides the windows margin of each DQ as a results of
DQS centeralization.
+config DDR_RESET_ON_TRAINING_FAILURE
+ bool "Reset the board on DDR training failure instead of hanging"
+ depends on ARMADA_38X || ARMADA_XP
+ help
+ If DDR training fails in SPL, reset the board instead of hanging.
+ Some boards are known to fail DDR training occasionally and an
+ immediate reset may be preferable to waiting until the board is
+ reset by watchdog (if there even is one).
+
+ Note that if booting via UART and the DDR training fails, the
+ device will still hang - it doesn't make sense to reset the board
+ in such a case.
+
config SYS_BOARD
default "clearfog" if TARGET_CLEARFOG
default "helios4" if TARGET_HELIOS4
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 273ecb8bd6..5ad323f9d9 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include
#include
#include
@@ -330,7 +331,11 @@ void board_init_f(ulong dummy)
ret = ddr3_init();
if (ret) {
printf("ddr3_init() failed: %d\n", ret);
- hang();
+ if (IS_ENABLED(CONFIG_DDR_RESET_ON_TRAINING_FAILURE) &&
+ get_boot_device() != BOOT_DEVICE_UART)
+ reset_cpu();
+ else
+ hang();
}
#endif
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH u-boot-marvell] ddr: marvell: a38x: fix BYTE_HOMOGENEOUS_SPLIT_OUT decision
On 2/17/22 01:08, Marek Behún wrote:
From: Marek Behún
In commit 3fc92a215b69 ("ddr: marvell: a38x: fix SPLIT_OUT_MIX state
decision") I ported a cleaned up and changed version of patch
mv_ddr: a380: fix SPLIT_OUT_MIX state decision
In the port we removed checking for BYTE_HOMOGENEOUS_SPLIT_OUT bit,
because:
- the fix seemed to work without it
- the bit was checked for only at one place out of two, while the second
bit, BYTE_SPLIT_OUT_MIX, was checked for in both cases
- without the removal it didn't work on Allied Telesis' x530 board
We recently had a chance to test on more boards, and it seems that the
change needs to be opposite: instead of removing the check for
BYTE_HOMOGENEOUS_SPLIT_OUT from the first if() statement, the check
needs to be added also to the second one - it needs to be at both
places.
With this change all the Turris Omnia boards I have had available to
test seem to work, I didn't encounter not even one failed DDR training.
As last time, I am noting that I do not understand what this code is
actually doing, I haven't studied the DDR training algorithm and
I suspect that no one will be able to explain it to U-Boot contributors,
so we are left with this blind poking in the code with testing whether
it works on several boards and hoping it doesn't break anything for
anyone :-(.
Signed-off-by: Marek Behún
Tested-by: Chris Packham
Reviewed-by: Stefan Roese
Applied to u-boot-marvell/master
Thanks,
Stefan
---
drivers/ddr/marvell/a38x/ddr3_training_centralization.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/ddr/marvell/a38x/ddr3_training_centralization.c
b/drivers/ddr/marvell/a38x/ddr3_training_centralization.c
index 42308b6965..be9f985f22 100644
--- a/drivers/ddr/marvell/a38x/ddr3_training_centralization.c
+++ b/drivers/ddr/marvell/a38x/ddr3_training_centralization.c
@@ -180,7 +180,8 @@ static int ddr3_tip_centralization(u32 dev_num, u32 mode)
[bit_id],
EDGE_1);
if (current_byte_status &
- BYTE_SPLIT_OUT_MIX) {
+ (BYTE_SPLIT_OUT_MIX |
+BYTE_HOMOGENEOUS_SPLIT_OUT)) {
if (cur_start_win[bit_id] >= 64)
cur_start_win[bit_id]
-= 64;
else
@@ -197,7 +198,8 @@ static int ddr3_tip_centralization(u32 dev_num, u32 mode)
EDGE_1);
if (cur_end_win[bit_id] >= 64 &&
(current_byte_status &
-BYTE_SPLIT_OUT_MIX)) {
+(BYTE_SPLIT_OUT_MIX |
+ BYTE_HOMOGENEOUS_SPLIT_OUT))) {
cur_end_win[bit_id] -= 64;
DEBUG_CENTRALIZATION_ENGINE
(DEBUG_LEVEL_INFO,
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH u-boot-marvell] pci: mvebu: Ensure that root port is always on root zero bus
On 2/15/22 11:34, Pali Rohár wrote:
Writing to the PCI_PRIMARY_BUS register of the root port should not change
bus number on which is root port present.
Same change and exactly same fix as was done in commit for pci-aardvark.c.
Fixes: a7b61ab58d5d ("pci: pci_mvebu: Properly configure and use PCI Bridge (PCIe
Root Port)")
Signed-off-by: Pali Rohár
Applied to u-boot-marvell/master
Thanks,
Stefan
---
drivers/pci/pci_mvebu.c | 52 +
1 file changed, 22 insertions(+), 30 deletions(-)
diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
index d99a99bae940..5a0a59a8b9ec 100644
--- a/drivers/pci/pci_mvebu.c
+++ b/drivers/pci/pci_mvebu.c
@@ -78,7 +78,6 @@ struct mvebu_pcie {
bool is_x4;
int devfn;
u32 lane_mask;
- int first_busno;
int sec_busno;
char name[16];
unsigned int mem_target;
@@ -140,12 +139,12 @@ static inline struct mvebu_pcie *hose_to_pcie(struct
pci_controller *hose)
static bool mvebu_pcie_valid_addr(struct mvebu_pcie *pcie,
int busno, int dev, int func)
{
- /* On primary bus is only one PCI Bridge */
- if (busno == pcie->first_busno && (dev != 0 || func != 0))
+ /* On the root bus is only one PCI Bridge */
+ if (busno == 0 && (dev != 0 || func != 0))
return false;
/* Access to other buses is possible when link is up */
- if (busno != pcie->first_busno && !mvebu_pcie_link_up(pcie))
+ if (busno != 0 && !mvebu_pcie_link_up(pcie))
return false;
/* On secondary bus can be only one PCIe device */
@@ -173,15 +172,15 @@ static int mvebu_pcie_read_config(const struct udevice
*bus, pci_dev_t bdf,
}
/*
-* The configuration space of the PCI Bridge on primary (first) bus is
+* The configuration space of the PCI Bridge on the root bus (zero) is
* of Type 0 but the BAR registers (including ROM BAR) don't have the
* same meaning as in the PCIe specification. Therefore do not access
* BAR registers and non-common registers (those which have different
* meaning for Type 0 and Type 1 config space) of the PCI Bridge and
* instead read their content from driver virtual cfgcache[].
*/
- if (busno == pcie->first_busno && ((offset >= 0x10 && offset < 0x34) ||
- (offset >= 0x38 && offset < 0x3c))) {
+ if (busno == 0 && ((offset >= 0x10 && offset < 0x34) ||
+ (offset >= 0x38 && offset < 0x3c))) {
data = pcie->cfgcache[(offset - 0x10) / 4];
debug("(addr,size,val)=(0x%04x, %d, 0x%08x) from cfgcache\n",
offset, size, data);
@@ -190,10 +189,10 @@ static int mvebu_pcie_read_config(const struct udevice
*bus, pci_dev_t bdf,
}
/*
-* PCI bridge is device 0 at primary bus but mvebu has it mapped on
-* secondary bus with device number 1.
+* PCI bridge is device 0 at the root bus (zero) but mvebu has it
+* mapped on secondary bus with device number 1.
*/
- if (busno == pcie->first_busno)
+ if (busno == 0)
addr = PCI_CONF1_EXT_ADDRESS(pcie->sec_busno, 1, 0, offset);
else
addr = PCI_CONF1_EXT_ADDRESS(busno, PCI_DEV(bdf),
PCI_FUNC(bdf), offset);
@@ -216,8 +215,7 @@ static int mvebu_pcie_read_config(const struct udevice
*bus, pci_dev_t bdf,
return -EINVAL;
}
- if (busno == pcie->first_busno &&
- (offset & ~3) == (PCI_HEADER_TYPE & ~3)) {
+ if (busno == 0 && (offset & ~3) == (PCI_HEADER_TYPE & ~3)) {
/*
* Change Header Type of PCI Bridge device to Type 1
* (0x01, used by PCI Bridges) because mvebu reports
@@ -257,10 +255,10 @@ static int mvebu_pcie_write_config(struct udevice *bus,
pci_dev_t bdf,
* config registers are not available, so we write their content only
* into driver virtual cfgcache[].
* And as explained in mvebu_pcie_probe(), mvebu has its own specific
-* way for configuring primary and secondary bus numbers.
+* way for configuring secondary bus number.
*/
- if (busno == pcie->first_busno && ((offset >= 0x10 && offset < 0x34) ||
- (offset >= 0x38 && offset < 0x3c))) {
+ if (busno == 0 && ((offset >= 0x10 && offset < 0x34) ||
+ (offset >= 0x38 && offset < 0x3c))) {
debug("Writing to cfgcache only\n");
data = pcie->cfgcache[(offset - 0x10) / 4];
data = pci_conv_size_to_32(data, value, offset, size);
@@ -270,12 +268,6 @@ static int mvebu_pcie_write_config(struct udevice *bus,
pci_dev_t bdf,
(offset & ~3) == PCI_ROM_ADDRESS1)
data = 0x0;
Re: [PATCH u-boot-mvebu v2 0/3] arm: mvebu: a37xx: Fix and extend building memory map
On 2/16/22 11:18, Pali Rohár wrote: Fix calling build_mem_map() function and extend it to map also CCI-400 and AP BootROM address space. With this change it is possible to access A53 AP BootROM on Armada 3720 from U-Boot and e.g. dump it via U-Boot md command: => md 4000 (Changes in v2: Fixed above dump command) Pali Rohár (3): arm: mvebu: a37xx: Fix calling build_mem_map() arm: mvebu: a37xx: Map CCI-400 and AP BootROM address space arm: mvebu: a37xx: Fix comment with name of the function arch/arm/mach-mvebu/armada3700/cpu.c | 29 1 file changed, 25 insertions(+), 4 deletions(-) Applied to u-boot-marvell/master Thanks, Stefan
Re: [PATCH u-boot-marvell 0/9] arm: a37xx: Fix code and update DTS files to upstream version
On 2/14/22 11:34, Pali Rohár wrote: Fix Armada 3720 drivers and all Armada 3720 boards (DB, uDPU, Mox and Espressobin) to be compatible with DTS files from upstream Linux kernel and update all Armada 3720 DTS files to version which is scheduled for Linux kernel 5.18. DTS patches scheduled for unreleased Linux kernel version 5.18 have only changes which were already in U-Boot DTS files. With this change U-Boot's Armada 3720 DTS board files finally could be used for booting Linux kernel. Tested on Turris Mox. Pali Rohár (9): rtc: ds1307: Add bindings for microchip,mcp7940x phy: marvell: a3700: Update compatible string to official DT bindings usb: ehci: ehci-marvell: Update compatible string to official DT bindings watchdog: armada_37xx: Convert to official DT bindings arm: mvebu: turris_mox: Remove hardcoded ethernet node names arm: a37xx: Update sdhci pointers to official DT bindings arm: a37xx: espressobin: Move U-Boot specific partitions node to -u-boot.dtsi arm: a37xx: espressobin: Explicitly enable eMMC node in -u-boot.dtsi arm: a37xx: Update DTS files to version from upstream Linux kernel arch/arm/dts/armada-371x.dtsi | 38 +- arch/arm/dts/armada-3720-db.dts | 226 +++-- .../dts/armada-3720-espressobin-u-boot.dtsi | 31 + arch/arm/dts/armada-3720-espressobin.dts | 189 + arch/arm/dts/armada-3720-espressobin.dtsi | 218 + arch/arm/dts/armada-3720-turris-mox.dts | 776 -- arch/arm/dts/armada-3720-uDPU-u-boot.dtsi | 2 +- arch/arm/dts/armada-3720-uDPU.dts | 218 ++--- arch/arm/dts/armada-372x.dtsi | 43 +- arch/arm/dts/armada-37xx.dtsi | 448 ++ board/CZ.NIC/turris_mox/turris_mox.c | 22 +- drivers/phy/marvell/comphy_a3700.c| 2 +- drivers/phy/marvell/comphy_core.c | 3 +- drivers/rtc/ds1307.c | 1 + drivers/usb/host/ehci-marvell.c | 4 +- drivers/watchdog/armada-37xx-wdt.c| 7 +- include/dt-bindings/bus/moxtet.h | 16 + 17 files changed, 1575 insertions(+), 669 deletions(-) create mode 100644 arch/arm/dts/armada-3720-espressobin-u-boot.dtsi create mode 100644 arch/arm/dts/armada-3720-espressobin.dtsi create mode 100644 include/dt-bindings/bus/moxtet.h Applied to u-boot-marvell/master Thanks, Stefan
Re: [PATCH] tools: kwbimage: Fix dumping DATA registers for v0 images
On 2/13/22 01:04, Pali Rohár wrote:
End of DATA register section is indicated by zero value in both raddr and
rdata.
So do not stop dumping registers with non-zero address and zero value.
And also print end of DATA registers section.
Fixes: 1a8e6b63e24f ("tools: kwbimage: Dump kwbimage config file on '-p -1'
option")
Signed-off-by: Pali Rohár
Reported-by: Tony Dinh
Tested-by: Tony Dinh
Applied to u-boot-marvell/master
Thanks,
Stefan
---
tools/kwbimage.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 9b63ce80ff4e..99d38cd1cfb2 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -2226,11 +2226,13 @@ static int kwbimage_generate_config(void *ptr, struct
image_tool_params *params)
ehdr0 = (struct ext_hdr_v0 *)(mhdr0 + 1);
if (ehdr0->offset) {
for (regdata = (struct ext_hdr_v0_reg *)((uint8_t *)ptr +
ehdr0->offset);
-(uint8_t *)regdata < (uint8_t *)ptr + header_size &&
regdata->raddr &&
-regdata->rdata;
+(uint8_t *)regdata < (uint8_t *)ptr + header_size
&&
+(regdata->raddr || regdata->rdata);
regdata++)
fprintf(f, "DATA 0x%08x 0x%08x\n",
le32_to_cpu(regdata->raddr),
le32_to_cpu(regdata->rdata));
+ if ((uint8_t *)regdata != (uint8_t *)ptr +
ehdr0->offset)
+ fprintf(f, "DATA 0x0 0x0\n");
}
}
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH u-boot-marvell 4/4] arm: a37xx: pci: Ensure that root port is always on root zero bus
On 2/10/22 14:53, Pali Rohár wrote:
Writing to the PCI_PRIMARY_BUS register of the root port should not change
bus number on which is root port present.
This PCI_PRIMARY_BUS register is used only for correct configuration of
legacy PCI stuff, like forwarding of PCI special cycles between buses.
Aardvark HW does not support PCI special cycles, so it does not have HW
register for PCI_PRIMARY_BUS and therefore it does not matter what is
stored in this register.
So fix this issue and do not use PCI_PRIMARY_BUS register in pci-aardvark.c
driver for moving root bus of the root port.
After this change there is no reason for storing bus number (zero) into
first_busno variable, so remove this variable.
Signed-off-by: Pali Rohár
Fixes: cb056005dc67 ("arm: a37xx: pci: Add support for accessing PCI Bridge on root
bus")
Applied to u-boot-marvell/master
Thanks,
Stefan
---
drivers/pci/pci-aardvark.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/pci/pci-aardvark.c b/drivers/pci/pci-aardvark.c
index 6e65c0e1558c..1eb257ea8b4a 100644
--- a/drivers/pci/pci-aardvark.c
+++ b/drivers/pci/pci-aardvark.c
@@ -151,8 +151,6 @@
* struct pcie_advk - Advk PCIe controller state
*
* @base:The base address of the register space.
- * @first_busno: Bus number of the PCIe root-port.
- * This may vary depending on the PCIe setup.
* @sec_busno: Bus number for the device behind the PCIe root-port.
* @dev: The pointer to PCI uclass device.
* @reset_gpio: GPIO descriptor for PERST.
@@ -162,7 +160,6 @@
*/
struct pcie_advk {
void*base;
- int first_busno;
int sec_busno;
struct udevice *dev;
struct gpio_descreset_gpio;
@@ -194,8 +191,8 @@ static inline uint advk_readl(struct pcie_advk *pcie, uint
reg)
static bool pcie_advk_addr_valid(struct pcie_advk *pcie,
int busno, u8 dev, u8 func)
{
- /* On the primary (local) bus there is only one PCI Bridge */
- if (busno == pcie->first_busno && (dev != 0 || func != 0))
+ /* On the root bus there is only one PCI Bridge */
+ if (busno == 0 && (dev != 0 || func != 0))
return false;
/*
@@ -353,17 +350,17 @@ static int pcie_advk_read_config(const struct udevice
*bus, pci_dev_t bdf,
}
/*
-* The configuration space of the PCI Bridge on primary (first) bus is
+* The configuration space of the PCI Bridge on the root bus (zero) is
* not accessible via PIO transfers like all other PCIe devices. PCI
* Bridge config registers are available directly in Aardvark memory
* space starting at offset zero. The PCI Bridge config space is of
* Type 0, but the BAR registers (including ROM BAR) don't have the same
* meaning as in the PCIe specification. Therefore do not access BAR
* registers and non-common registers (those which have different
-* meaning for Type 0 and Type 1 config space) of the primary PCI Bridge
+* meaning for Type 0 and Type 1 config space) of the PCI Bridge
* and instead read their content from driver virtual cfgcache[].
*/
- if (busno == pcie->first_busno) {
+ if (busno == 0) {
if ((offset >= 0x10 && offset < 0x34) || (offset >= 0x38 && offset
< 0x3c))
data = pcie->cfgcache[(offset - 0x10) / 4];
else
@@ -543,7 +540,7 @@ static int pcie_advk_write_config(struct udevice *bus,
pci_dev_t bdf,
* zero. Type 1 specific registers are not available, so we write their
* content only into driver virtual cfgcache[].
*/
- if (busno == pcie->first_busno) {
+ if (busno == 0) {
if ((offset >= 0x10 && offset < 0x34) ||
(offset >= 0x38 && offset < 0x3c)) {
data = pcie->cfgcache[(offset - 0x10) / 4];
@@ -560,9 +557,6 @@ static int pcie_advk_write_config(struct udevice *bus,
pci_dev_t bdf,
advk_writel(pcie, data, ADVK_ROOT_PORT_PCI_CFG_OFF +
(offset & ~3));
}
- if (offset == PCI_PRIMARY_BUS)
- pcie->first_busno = data & 0xff;
-
if (offset == PCI_SECONDARY_BUS ||
(offset == PCI_PRIMARY_BUS && size != PCI_SIZE_8))
pcie->sec_busno = (data >> 8) & 0xff;
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH u-boot-marvell 2/4] arm: a37xx: pci: Cleanup macro names
On 2/10/22 14:53, Pali Rohár wrote: Remove "PCI_" prefix from all macros which are aardvark specific to not conflict with macros defined in global include file pci.h. Instead add "ADVK_" prefix for them so it is visible that they are aardvark specific. After "ADVK_" prefix append keyword which describes register group, so it would be clear to which register each macro value belongs. Rename some macros for consistency with other macros. Signed-off-by: Pali Rohár Applied to u-boot-marvell/master Thanks, Stefan --- drivers/pci/pci-aardvark.c | 394 ++--- 1 file changed, 192 insertions(+), 202 deletions(-) diff --git a/drivers/pci/pci-aardvark.c b/drivers/pci/pci-aardvark.c index ad4edd715bd6..8e3b13b49ea0 100644 --- a/drivers/pci/pci-aardvark.c +++ b/drivers/pci/pci-aardvark.c @@ -40,113 +40,104 @@ #define ADVK_ROOT_PORT_PCI_EXP_OFF0xc0 #define ADVK_ROOT_PORT_PCI_ERR_OFF0x100 -/* PIO registers base address and register offsets */ -#define PIO_BASE_ADDR 0x4000 -#define PIO_CTRL (PIO_BASE_ADDR + 0x0) -#define PIO_CTRL_TYPE_MASK GENMASK(3, 0) -#define PIO_CTRL_ADDR_WIN_DISABLEBIT(24) -#define PIO_STAT (PIO_BASE_ADDR + 0x4) -#define PIO_COMPLETION_STATUS_SHIFT 7 -#define PIO_COMPLETION_STATUS_MASK GENMASK(9, 7) -#define PIO_COMPLETION_STATUS_OK 0 -#define PIO_COMPLETION_STATUS_UR 1 -#define PIO_COMPLETION_STATUS_CRS2 -#define PIO_COMPLETION_STATUS_CA 4 -#define PIO_NON_POSTED_REQ BIT(10) -#define PIO_ERR_STATUS BIT(11) -#define PIO_ADDR_LS(PIO_BASE_ADDR + 0x8) -#define PIO_ADDR_MS(PIO_BASE_ADDR + 0xc) -#define PIO_WR_DATA(PIO_BASE_ADDR + 0x10) -#define PIO_WR_DATA_STRB (PIO_BASE_ADDR + 0x14) -#define PIO_RD_DATA(PIO_BASE_ADDR + 0x18) -#define PIO_START (PIO_BASE_ADDR + 0x1c) -#define PIO_ISR(PIO_BASE_ADDR + 0x20) - -/* Aardvark Control registers */ -#define CONTROL_BASE_ADDR 0x4800 -#define PCIE_CORE_CTRL0_REG(CONTROL_BASE_ADDR + 0x0) -#define PCIE_GEN_SEL_MSK 0x3 -#define PCIE_GEN_SEL_SHIFT 0x0 -#define SPEED_GEN_10 -#define SPEED_GEN_21 -#define SPEED_GEN_32 -#define IS_RC_MSK 1 -#define IS_RC_SHIFT2 -#define LANE_CNT_MSK 0x18 -#define LANE_CNT_SHIFT 0x3 -#define LANE_COUNT_1 (0 << LANE_CNT_SHIFT) -#define LANE_COUNT_2 (1 << LANE_CNT_SHIFT) -#define LANE_COUNT_4 (2 << LANE_CNT_SHIFT) -#define LANE_COUNT_8 (3 << LANE_CNT_SHIFT) -#define LINK_TRAINING_EN BIT(6) -#define PCIE_CORE_CTRL2_REG(CONTROL_BASE_ADDR + 0x8) -#define PCIE_CORE_CTRL2_RESERVED 0x7 -#define PCIE_CORE_CTRL2_TD_ENABLE BIT(4) -#define PCIE_CORE_CTRL2_STRICT_ORDER_ENABLEBIT(5) -#define PCIE_CORE_CTRL2_ADDRWIN_MAP_ENABLE BIT(6) - -/* PCIe window configuration */ -#define OB_WIN_BASE_ADDR 0x4c00 -#define OB_WIN_BLOCK_SIZE 0x20 -#define OB_WIN_COUNT 8 -#define OB_WIN_REG_ADDR(win, offset) (OB_WIN_BASE_ADDR + \ -OB_WIN_BLOCK_SIZE * (win) + \ -(offset)) -#define OB_WIN_MATCH_LS(win) OB_WIN_REG_ADDR(win, 0x00) -#define OB_WIN_ENABLE BIT(0) -#define OB_WIN_MATCH_MS(win) OB_WIN_REG_ADDR(win, 0x04) -#define OB_WIN_REMAP_LS(win) OB_WIN_REG_ADDR(win, 0x08) -#define OB_WIN_REMAP_MS(win) OB_WIN_REG_ADDR(win, 0x0c) -#define OB_WIN_MASK_LS(win)OB_WIN_REG_ADDR(win, 0x10) -#define OB_WIN_MASK_MS(win)OB_WIN_REG_ADDR(win, 0x14) -#define OB_WIN_ACTIONS(win)OB_WIN_REG_ADDR(win, 0x18) -#define OB_WIN_DEFAULT_ACTIONS (OB_WIN_ACTIONS(OB_WIN_COUNT-1) + 0x4) -#define OB_WIN_FUNC_NUM_MASK GENMASK(31, 24) -#define OB_WIN_FUNC_NUM_SHIFT 24 -#define OB_WIN_FUNC_NUM_ENABLE BIT(23) -#define OB_WIN_BUS_NUM_BITS_MASK GENMASK(22, 20) -#define OB_WIN_BUS_NUM_BITS_SHIFT 20 -#define OB_WIN_MSG_CODE_ENABLE BIT(22) -#define OB_WIN_MSG_CODE_MASK
Re: [PATCH u-boot-marvell 3/4] arm: a37xx: pci: Use dev_read_addr()
On 2/10/22 14:53, Pali Rohár wrote: There is only one base address, so use dev_read_addr() instead of dev_read_addr_index(). Signed-off-by: Pali Rohár Applied to u-boot-marvell/master Thanks, Stefan --- drivers/pci/pci-aardvark.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/pci-aardvark.c b/drivers/pci/pci-aardvark.c index 8e3b13b49ea0..6e65c0e1558c 100644 --- a/drivers/pci/pci-aardvark.c +++ b/drivers/pci/pci-aardvark.c @@ -991,7 +991,7 @@ static int pcie_advk_of_to_plat(struct udevice *dev) struct pcie_advk *pcie = dev_get_priv(dev); /* Get the register base address */ - pcie->base = (void *)dev_read_addr_index(dev, 0); + pcie->base = (void *)dev_read_addr(dev); if ((fdt_addr_t)pcie->base == FDT_ADDR_T_NONE) return -EINVAL; Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH u-boot-marvell 1/4] arm: a37xx: pci: Use standard register macros from pci.h
On 2/10/22 14:53, Pali Rohár wrote:
PCI config space of the aardvark PCIe Root Port is available only in
internal aardvark memory space starting at offset 0x0. PCI Express
registers (PCI_EXP_*) start at offset 0xc0. And Advanced Error Reporting
registers (PCI_ERR_*) start at offset 0x100.
Replace custom aardvark register macros by standard PCI macros from
include/pci.h file with fixed offset.
Some DEVCTL and AER macros are not defined in include/pci.h file, so define
them in the same way as in linux uapi header file pci_regs.h.
Signed-off-by: Pali Rohár
Applied to u-boot-marvell/master
Thanks,
Stefan
---
drivers/pci/pci-aardvark.c | 82 ++
include/pci.h | 24 +++
2 files changed, 54 insertions(+), 52 deletions(-)
diff --git a/drivers/pci/pci-aardvark.c b/drivers/pci/pci-aardvark.c
index 22b6d8b62865..ad4edd715bd6 100644
--- a/drivers/pci/pci-aardvark.c
+++ b/drivers/pci/pci-aardvark.c
@@ -35,28 +35,10 @@
#include
#include
-/* PCIe core registers */
-#define PCIE_CORE_CMD_STATUS_REG 0x4
-#define PCIE_CORE_CMD_IO_ACCESS_EN BIT(0)
-#define PCIE_CORE_CMD_MEM_ACCESS_ENBIT(1)
-#define PCIE_CORE_CMD_MEM_IO_REQ_ENBIT(2)
-#define PCIE_CORE_DEV_REV_REG 0x8
-#define PCIE_CORE_EXP_ROM_BAR_REG 0x30
-#define PCIE_CORE_PCIEXP_CAP_OFF 0xc0
-#define PCIE_CORE_DEV_CTRL_STATS_REG 0xc8
-#define PCIE_CORE_DEV_CTRL_STATS_RELAX_ORDER_DISABLE (0 << 4)
-#define PCIE_CORE_DEV_CTRL_STATS_SNOOP_DISABLE (0 << 11)
-#define PCIE_CORE_DEV_CTRL_STATS_MAX_PAYLOAD_SIZE 0x2
-#define PCIE_CORE_DEV_CTRL_STATS_MAX_PAYLOAD_SIZE_SHIFT5
-#define PCIE_CORE_DEV_CTRL_STATS_MAX_RD_REQ_SIZE 0x2
-#define PCIE_CORE_DEV_CTRL_STATS_MAX_RD_REQ_SIZE_SHIFT 12
-#define PCIE_CORE_LINK_CTRL_STAT_REG 0xd0
-#define PCIE_CORE_LINK_TRAININGBIT(5)
-#define PCIE_CORE_ERR_CAPCTL_REG 0x118
-#define PCIE_CORE_ERR_CAPCTL_ECRC_CHK_TX BIT(5)
-#define PCIE_CORE_ERR_CAPCTL_ECRC_CHK_TX_ENBIT(6)
-#define PCIE_CORE_ERR_CAPCTL_ECRC_CHECKBIT(7)
-#define PCIE_CORE_ERR_CAPCTL_ECRC_CHECK_RCVBIT(8)
+/* PCIe Root Port register offsets */
+#define ADVK_ROOT_PORT_PCI_CFG_OFF 0x0
+#define ADVK_ROOT_PORT_PCI_EXP_OFF 0xc0
+#define ADVK_ROOT_PORT_PCI_ERR_OFF 0x100
/* PIO registers base address and register offsets */
#define PIO_BASE_ADDR 0x4000
@@ -394,7 +376,7 @@ static int pcie_advk_read_config(const struct udevice *bus,
pci_dev_t bdf,
if ((offset >= 0x10 && offset < 0x34) || (offset >= 0x38 && offset
< 0x3c))
data = pcie->cfgcache[(offset - 0x10) / 4];
else
- data = advk_readl(pcie, offset & ~3);
+ data = advk_readl(pcie, ADVK_ROOT_PORT_PCI_CFG_OFF +
(offset & ~3));
if ((offset & ~3) == (PCI_HEADER_TYPE & ~3)) {
/*
@@ -406,14 +388,13 @@ static int pcie_advk_read_config(const struct udevice
*bus, pci_dev_t bdf,
data |= PCI_HEADER_TYPE_BRIDGE << 16;
}
- if ((offset & ~3) == PCIE_CORE_PCIEXP_CAP_OFF + PCI_EXP_RTCTL) {
+ if ((offset & ~3) == ADVK_ROOT_PORT_PCI_EXP_OFF +
PCI_EXP_RTCTL) {
/* CRSSVE bit is stored only in cache */
if (pcie->cfgcrssve)
data |= PCI_EXP_RTCTL_CRSSVE;
}
- if ((offset & ~3) == PCIE_CORE_PCIEXP_CAP_OFF +
-(PCI_EXP_RTCAP & ~3)) {
+ if ((offset & ~3) == ADVK_ROOT_PORT_PCI_EXP_OFF + (PCI_EXP_RTCAP
& ~3)) {
/* CRS is emulated below, so set CRSVIS capability */
data |= PCI_EXP_RTCAP_CRSVIS << 16;
}
@@ -583,9 +564,9 @@ static int pcie_advk_write_config(struct udevice *bus,
pci_dev_t bdf,
data = 0x0;
pcie->cfgcache[(offset - 0x10) / 4] = data;
} else {
- data = advk_readl(pcie, offset & ~3);
+ data = advk_readl(pcie, ADVK_ROOT_PORT_PCI_CFG_OFF +
(offset & ~3));
data = pci_conv_size_to_32(data, value, offset, size);
- advk_writel(pcie, data, offset & ~3);
+ advk_writel(pcie, data, ADVK_ROOT_PORT_PCI_CFG_OFF +
(offset & ~3));
}
if (offset == PCI_PRIMARY_BUS)
@@ -595,7 +576,7 @@ static int pcie_advk_write_config(struct
[PATCH v3 6/6] bsh: imx8mn-smm-s2/pro: Add iMX8MN BSH SMM S2 boards
Introduce BSH SystemMaster (SMM) S2 board family, which consists of:
iMX8MN SMM S2 and iMX8MN SMM S2 PRO boards.
Add support for iMX8MN BSH SMM S2 board:
- 256 MiB DDR3 RAM
- 512MiB Nand
- USBOTG1 peripheral - fastboot.
- 100Mbit Ethernet
Add support for iMX8MN BSH SMM S2 PRO board:
- 512 MiB DDR3 RAM
- 8 GiB eMMC
- USBOTG1 peripheral - fastboot.
- 100Mbit Ethernet
Signed-off-by: Ariel D'Alessandro
Signed-off-by: Michael Trimarchi
---
arch/arm/dts/Makefile | 2 +
arch/arm/dts/imx8mn-bsh-smm-s2-common.dtsi| 423
.../dts/imx8mn-bsh-smm-s2-u-boot-common.dtsi | 225 +
arch/arm/dts/imx8mn-bsh-smm-s2-u-boot.dtsi| 15 +
arch/arm/dts/imx8mn-bsh-smm-s2.dts| 48 +
arch/arm/dts/imx8mn-bsh-smm-s2pro-u-boot.dtsi | 15 +
arch/arm/dts/imx8mn-bsh-smm-s2pro.dts | 80 ++
arch/arm/mach-imx/imx8m/Kconfig | 15 +
board/bsh/imx8mn_smm_s2/Kconfig | 49 +
board/bsh/imx8mn_smm_s2/MAINTAINERS | 8 +
board/bsh/imx8mn_smm_s2/Makefile | 13 +
board/bsh/imx8mn_smm_s2/ddr3l_timing_256m.c | 941 ++
board/bsh/imx8mn_smm_s2/ddr3l_timing_512m.c | 941 ++
board/bsh/imx8mn_smm_s2/imx8mn_smm_s2.c | 23 +
board/bsh/imx8mn_smm_s2/imximage-8mn-ddr3.cfg | 10 +
board/bsh/imx8mn_smm_s2/spl.c | 93 ++
configs/imx8mn_bsh_smm_s2_defconfig | 97 ++
configs/imx8mn_bsh_smm_s2pro_defconfig| 94 ++
doc/board/bsh/imx8mn_bsh_smm_s2.rst | 62 ++
doc/board/bsh/index.rst | 9 +
doc/board/index.rst | 1 +
include/configs/imx8mn_bsh_smm_s2.h | 52 +
include/configs/imx8mn_bsh_smm_s2_common.h| 62 ++
include/configs/imx8mn_bsh_smm_s2pro.h| 35 +
24 files changed, 3313 insertions(+)
create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2-common.dtsi
create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2-u-boot-common.dtsi
create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2-u-boot.dtsi
create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2.dts
create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2pro-u-boot.dtsi
create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2pro.dts
create mode 100644 board/bsh/imx8mn_smm_s2/Kconfig
create mode 100644 board/bsh/imx8mn_smm_s2/MAINTAINERS
create mode 100644 board/bsh/imx8mn_smm_s2/Makefile
create mode 100644 board/bsh/imx8mn_smm_s2/ddr3l_timing_256m.c
create mode 100644 board/bsh/imx8mn_smm_s2/ddr3l_timing_512m.c
create mode 100644 board/bsh/imx8mn_smm_s2/imx8mn_smm_s2.c
create mode 100644 board/bsh/imx8mn_smm_s2/imximage-8mn-ddr3.cfg
create mode 100644 board/bsh/imx8mn_smm_s2/spl.c
create mode 100644 configs/imx8mn_bsh_smm_s2_defconfig
create mode 100644 configs/imx8mn_bsh_smm_s2pro_defconfig
create mode 100644 doc/board/bsh/imx8mn_bsh_smm_s2.rst
create mode 100644 doc/board/bsh/index.rst
create mode 100644 include/configs/imx8mn_bsh_smm_s2.h
create mode 100644 include/configs/imx8mn_bsh_smm_s2_common.h
create mode 100644 include/configs/imx8mn_bsh_smm_s2pro.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 086533b61bb..fc7509e511c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -911,6 +911,8 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mm-venice-gw7902.dtb \
imx8mm-verdin.dtb \
phycore-imx8mm.dtb \
+ imx8mn-bsh-smm-s2.dtb \
+ imx8mn-bsh-smm-s2pro.dtb \
imx8mn-ddr4-evk.dtb \
imx8mq-cm.dtb \
imx8mn-evk.dtb \
diff --git a/arch/arm/dts/imx8mn-bsh-smm-s2-common.dtsi
b/arch/arm/dts/imx8mn-bsh-smm-s2-common.dtsi
new file mode 100644
index 000..184c715bd38
--- /dev/null
+++ b/arch/arm/dts/imx8mn-bsh-smm-s2-common.dtsi
@@ -0,0 +1,423 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 Collabora Ltd.
+ * Copyright 2021 BSH Hausgeraete GmbH
+ */
+
+#include "imx8mn.dtsi"
+
+/ {
+ chosen {
+ stdout-path =
+ };
+
+ fec_supply: fec_supply_en {
+ compatible = "regulator-fixed";
+ regulator-name = "tja1101_en";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = < 20 GPIO_ACTIVE_HIGH>;
+ vin-supply = <_reg>;
+ enable-active-high;
+ };
+
+ usdhc2_pwrseq: usdhc2_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ pinctrl-0 = <_usdhc2_pwrseq>;
+ reset-gpios = < 27 GPIO_ACTIVE_LOW>;
+ };
+};
+
+_0 {
+ cpu-supply = <_reg>;
+};
+
+_1 {
+ cpu-supply = <_reg>;
+};
+
+_2 {
+ cpu-supply = <_reg>;
+};
+
+_3 {
+ cpu-supply = <_reg>;
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_espi2>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_fec1>;
+ phy-mode = "rmii";
+ phy-handle = <>;
+
[PATCH v3 5/6] net: phy: nxp-tja11xx: Add NXP TJA11xx PHY driver
From: Michael Trimarchi
Add driver for the NXP TJA1100 and TJA1101 PHYs. These PHYs are special
BroadRReach 100BaseT1 PHYs used in automotive.
Signed-off-by: Michael Trimarchi
Signed-off-by: Ariel D'Alessandro
---
drivers/net/phy/Kconfig | 5 +
drivers/net/phy/Makefile | 1 +
drivers/net/phy/nxp-tja11xx.c | 277 ++
drivers/net/phy/phy.c | 3 +
include/phy.h | 1 +
5 files changed, 287 insertions(+)
create mode 100644 drivers/net/phy/nxp-tja11xx.c
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 4f8d33ce8fd..8de6130113c 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -211,6 +211,11 @@ config PHY_NXP_C45_TJA11XX
Enable support for NXP C45 TJA11XX PHYs.
Currently supports only the TJA1103 PHY.
+config PHY_NXP_TJA11XX
+ bool "NXP TJA11XX Ethernet PHYs support"
+ help
+ Currently supports the NXP TJA1100 and TJA1101 PHY.
+
config PHY_REALTEK
bool "Realtek Ethernet PHYs support"
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 77f7f606215..7cfbab0b5c8 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_PHY_MICREL_KSZ90X1) += micrel_ksz90x1.o
obj-$(CONFIG_PHY_MESON_GXL) += meson-gxl.o
obj-$(CONFIG_PHY_NATSEMI) += natsemi.o
obj-$(CONFIG_PHY_NXP_C45_TJA11XX) += nxp-c45-tja11xx.o
+obj-$(CONFIG_PHY_NXP_TJA11XX) += nxp-tja11xx.o
obj-$(CONFIG_PHY_REALTEK) += realtek.o
obj-$(CONFIG_PHY_SMSC) += smsc.o
obj-$(CONFIG_PHY_TERANETICS) += teranetics.o
diff --git a/drivers/net/phy/nxp-tja11xx.c b/drivers/net/phy/nxp-tja11xx.c
new file mode 100644
index 000..30dec5e605b
--- /dev/null
+++ b/drivers/net/phy/nxp-tja11xx.c
@@ -0,0 +1,277 @@
+// SPDX-License-Identifier: GPL-2.0
+/* NXP TJA1100 BroadRReach PHY driver
+ *
+ * Copyright (C) 2022 Michael Trimarchi
+ * Copyright (C) 2022 Ariel D'Alessandro
+ * Copyright (C) 2018 Marek Vasut
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define PHY_ID_MASK0xfff0
+#define PHY_ID_TJA1100 0x0180dc40
+#define PHY_ID_TJA1101 0x0180dd00
+
+#define MII_ECTRL 17
+#define MII_ECTRL_LINK_CONTROL BIT(15)
+#define MII_ECTRL_POWER_MODE_MASK GENMASK(14, 11)
+#define MII_ECTRL_POWER_MODE_NO_CHANGE (0x0 << 11)
+#define MII_ECTRL_POWER_MODE_NORMAL(0x3 << 11)
+#define MII_ECTRL_POWER_MODE_STANDBY (0xc << 11)
+#define MII_ECTRL_CABLE_TEST BIT(5)
+#define MII_ECTRL_CONFIG_ENBIT(2)
+#define MII_ECTRL_WAKE_REQUEST BIT(0)
+
+#define MII_CFG1 18
+#define MII_CFG1_MASTER_SLAVE BIT(15)
+#define MII_CFG1_AUTO_OP BIT(14)
+#define MII_CFG1_SLEEP_CONFIRM BIT(6)
+#define MII_CFG1_LED_MODE_MASK GENMASK(5, 4)
+#define MII_CFG1_LED_MODE_LINKUP 0
+#define MII_CFG1_LED_ENABLEBIT(3)
+
+#define MII_CFG2 19
+#define MII_CFG2_SLEEP_REQUEST_TO GENMASK(1, 0)
+#define MII_CFG2_SLEEP_REQUEST_TO_16MS 0x3
+
+#define MII_INTSRC 21
+#define MII_INTSRC_LINK_FAIL BIT(10)
+#define MII_INTSRC_LINK_UP BIT(9)
+#define MII_INTSRC_MASK(MII_INTSRC_LINK_FAIL | \
+MII_INTSRC_LINK_UP)
+#define MII_INTSRC_UV_ERR BIT(3)
+#define MII_INTSRC_TEMP_ERRBIT(1)
+
+#define MII_INTEN 22
+#define MII_INTEN_LINK_FAILBIT(10)
+#define MII_INTEN_LINK_UP BIT(9)
+#define MII_INTEN_UV_ERR BIT(3)
+#define MII_INTEN_TEMP_ERR BIT(1)
+
+#define MII_COMMSTAT 23
+#define MII_COMMSTAT_LINK_UP BIT(15)
+#define MII_COMMSTAT_SQI_STATE GENMASK(7, 5)
+#define MII_COMMSTAT_SQI_MAX 7
+
+#define MII_GENSTAT24
+#define MII_GENSTAT_PLL_LOCKED BIT(14)
+
+#define MII_EXTSTAT25
+#define MII_EXTSTAT_SHORT_DETECT BIT(8)
+#define MII_EXTSTAT_OPEN_DETECTBIT(7)
+#define MII_EXTSTAT_POLARITY_DETECTBIT(6)
+
+#define MII_COMMCFG27
+#define MII_COMMCFG_AUTO_OPBIT(15)
+
+static inline int tja11xx_set_bits(struct phy_device *phydev, u32 regnum,
+ u16 val)
+{
+ return phy_set_bits_mmd(phydev, MDIO_DEVAD_NONE, regnum, val);
+}
+
+static inline int tja11xx_clear_bits(struct phy_device *phydev, u32 regnum,
+u16 val)
+{
+ return phy_clear_bits_mmd(phydev, MDIO_DEVAD_NONE, regnum, val);
+}
+
+static inline int tja11xx_read(struct phy_device *phydev, int regnum)
+{
+ return phy_read(phydev, MDIO_DEVAD_NONE, regnum);
+}
+
+static inline int tja11xx_modify(struct phy_device *phydev, int regnum,
+u16 mask, u16 set)
+{
+ return
[PATCH v3 4/6] net: phy: Add phy_modify() accessor
Add read-modify-write unlocked accessor for accessing a PHY register.
Signed-off-by: Ariel D'Alessandro
---
drivers/net/phy/phy.c | 20
include/phy.h | 2 ++
2 files changed, 22 insertions(+)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 9935e40fcdc..b73361d87d9 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -1105,3 +1105,23 @@ int phy_get_interface_by_name(const char *str)
return -1;
}
+
+/**
+ * phy_modify - Convenience function for modifying a given PHY register
+ * @phydev: the phy_device struct
+ * @devad: The MMD to read from
+ * @regnum: register number to write
+ * @mask: bit mask of bits to clear
+ * @set: new value of bits set in mask to write to @regnum
+ */
+int phy_modify(struct phy_device *phydev, int devad, int regnum, u16 mask,
+ u16 set)
+{
+ int ret;
+
+ ret = phy_read(phydev, devad, regnum);
+ if (ret < 0)
+ return ret;
+
+ return phy_write(phydev, devad, regnum, (ret & ~mask) | set);
+}
diff --git a/include/phy.h b/include/phy.h
index d4035fdef2b..2dd2e02ab5d 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -500,6 +500,8 @@ int phy_config(struct phy_device *phydev);
int phy_shutdown(struct phy_device *phydev);
int phy_register(struct phy_driver *drv);
int phy_set_supported(struct phy_device *phydev, u32 max_speed);
+int phy_modify(struct phy_device *phydev, int devad, int regnum, u16 mask,
+ u16 set);
int genphy_config_aneg(struct phy_device *phydev);
int genphy_restart_aneg(struct phy_device *phydev);
int genphy_update_link(struct phy_device *phydev);
--
2.34.1
[PATCH v3 2/6] phy: nxp-c45-tja11xx: Rename functions to be c45 tja11xx specific
This driver supports NXP C45 TJA11XX PHYs, but there're also other NXP
TJA11XX PHYs. Let's rename functions in this driver to be c45 variant
specific, so further drivers can be introduced adding support for NXP
TJA11XX PHYs.
Signed-off-by: Ariel D'Alessandro
---
drivers/net/phy/nxp-c45-tja11xx.c | 6 +++---
drivers/net/phy/phy.c | 2 +-
include/phy.h | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/phy/nxp-c45-tja11xx.c
b/drivers/net/phy/nxp-c45-tja11xx.c
index f86e31f0d9e..a0f41fab698 100644
--- a/drivers/net/phy/nxp-c45-tja11xx.c
+++ b/drivers/net/phy/nxp-c45-tja11xx.c
@@ -330,7 +330,7 @@ static int nxp_c45_probe(struct phy_device *phydev)
return 0;
}
-static struct phy_driver nxp_tja11xx = {
+static struct phy_driver nxp_c45_tja11xx = {
.name = "NXP C45 TJA1103",
.uid = PHY_ID_TJA_1103,
.mask = 0xf0,
@@ -341,8 +341,8 @@ static struct phy_driver nxp_tja11xx = {
.shutdown = _shutdown,
};
-int phy_nxp_tja11xx_init(void)
+int phy_nxp_c45_tja11xx_init(void)
{
- phy_register(_tja11xx);
+ phy_register(_c45_tja11xx);
return 0;
}
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index c9fc20855ba..9935e40fcdc 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -530,7 +530,7 @@ int phy_init(void)
phy_natsemi_init();
#endif
#ifdef CONFIG_NXP_C45_TJA11XX_PHY
- phy_nxp_tja11xx_init();
+ phy_nxp_c45_tja11xx_init();
#endif
#ifdef CONFIG_PHY_REALTEK
phy_realtek_init();
diff --git a/include/phy.h b/include/phy.h
index c66fd43ea88..d4035fdef2b 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -527,7 +527,7 @@ int phy_micrel_ksz8xxx_init(void);
int phy_micrel_ksz90x1_init(void);
int phy_meson_gxl_init(void);
int phy_natsemi_init(void);
-int phy_nxp_tja11xx_init(void);
+int phy_nxp_c45_tja11xx_init(void);
int phy_realtek_init(void);
int phy_smsc_init(void);
int phy_teranetics_init(void);
--
2.34.1
[PATCH v3 3/6] iopoll: Extend read_poll_timeout macro to support variable parameters
This macro currently supports only one parameter. Based on Linux iopoll,
let's extend read_poll_timeout common API to allow multiple variable
parameters.
Signed-off-by: Ariel D'Alessandro
---
arch/arm/mach-socfpga/reset_manager_s10.c | 20 +++-
drivers/mmc/rockchip_sdhci.c | 9 +
include/linux/iopoll.h| 12 ++--
3 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-socfpga/reset_manager_s10.c
b/arch/arm/mach-socfpga/reset_manager_s10.c
index d2337bd4d62..f47fec10a0c 100644
--- a/arch/arm/mach-socfpga/reset_manager_s10.c
+++ b/arch/arm/mach-socfpga/reset_manager_s10.c
@@ -80,9 +80,9 @@ void socfpga_bridges_reset(int enable)
~0);
/* Poll until all idleack to 0 */
- read_poll_timeout(readl, socfpga_get_sysmgr_addr() +
- SYSMGR_SOC64_NOC_IDLEACK, reg, !reg, 1000,
- 30);
+ read_poll_timeout(readl, reg, !reg, 1000, 30,
+ socfpga_get_sysmgr_addr() +
+ SYSMGR_SOC64_NOC_IDLEACK);
} else {
/* set idle request to all bridges */
writel(~0,
@@ -93,18 +93,20 @@ void socfpga_bridges_reset(int enable)
writel(1, socfpga_get_sysmgr_addr() + SYSMGR_SOC64_NOC_TIMEOUT);
/* Poll until all idleack to 1 */
- read_poll_timeout(readl, socfpga_get_sysmgr_addr() +
- SYSMGR_SOC64_NOC_IDLEACK, reg,
+ read_poll_timeout(readl, reg,
reg == (SYSMGR_NOC_H2F_MSK |
SYSMGR_NOC_LWH2F_MSK),
- 1000, 30);
+ 1000, 30,
+ socfpga_get_sysmgr_addr() +
+ SYSMGR_SOC64_NOC_IDLEACK);
/* Poll until all idlestatus to 1 */
- read_poll_timeout(readl, socfpga_get_sysmgr_addr() +
- SYSMGR_SOC64_NOC_IDLESTATUS, reg,
+ read_poll_timeout(readl, reg,
reg == (SYSMGR_NOC_H2F_MSK |
SYSMGR_NOC_LWH2F_MSK),
- 1000, 30);
+ 1000, 30,
+ socfpga_get_sysmgr_addr() +
+ SYSMGR_SOC64_NOC_IDLESTATUS);
/* Reset all bridges (except NOR DDR scheduler & F2S) */
setbits_le32(socfpga_get_rstmgr_addr() + RSTMGR_SOC64_BRGMODRST,
diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c
index 278473899c7..87f14b0ee9c 100644
--- a/drivers/mmc/rockchip_sdhci.c
+++ b/drivers/mmc/rockchip_sdhci.c
@@ -146,8 +146,8 @@ static void rk3399_emmc_phy_power_on(struct
rockchip_emmc_phy *phy, u32 clock)
/* REN Enable on STRB Line for HS400 */
writel(RK_CLRSETBITS(0, 1 << 9), >emmcphy_con[2]);
- read_poll_timeout(readl, >emmcphy_status, dllrdy,
- PHYCTRL_DLL_LOCK_WO_TMOUT(dllrdy), 1, 5000);
+ read_poll_timeout(readl, dllrdy, PHYCTRL_DLL_LOCK_WO_TMOUT(dllrdy), 1,
+ 5000, >emmcphy_status);
}
static void rk3399_emmc_phy_power_off(struct rockchip_emmc_phy *phy)
@@ -235,8 +235,9 @@ static int rk3568_sdhci_emmc_set_clock(struct sdhci_host
*host, unsigned int clo
DWCMSHC_EMMC_DLL_START;
sdhci_writel(host, extra, DWCMSHC_EMMC_DLL_CTRL);
- ret = read_poll_timeout(readl, host->ioaddr +
DWCMSHC_EMMC_DLL_STATUS0,
- val, DLL_LOCK_WO_TMOUT(val), 1, 500);
+ ret = read_poll_timeout(readl, val, DLL_LOCK_WO_TMOUT(val), 1,
+ 500,
+ host->ioaddr +
DWCMSHC_EMMC_DLL_STATUS0);
if (ret)
return ret;
diff --git a/include/linux/iopoll.h b/include/linux/iopoll.h
index 30cdea0cdc1..0ee2bddaa83 100644
--- a/include/linux/iopoll.h
+++ b/include/linux/iopoll.h
@@ -14,11 +14,11 @@
/**
* read_poll_timeout - Periodically poll an address until a condition is met
or a timeout occurs
* @op: accessor function (takes @addr as its only argument)
- * @addr: Address to poll
* @val: Variable to read the value into
* @cond: Break condition (usually involving @val)
* @sleep_us: Maximum time to sleep in us
* @timeout_us: Timeout in us, 0 means never timeout
+ * @args: arguments for @op poll
*
* Returns 0 on success and -ETIMEDOUT upon a timeout. In either
* case, the last read value at @addr is stored in @val.
@@ -26,15 +26,15 @@
* When available, you'll probably want to use one of the specialized
* macros defined below rather than this macro
[PATCH v3 1/6] imx8m: add regs used by GPMI
From: Michael Trimarchi Add regs used by GPMI Signed-off-by: Michael Trimarchi Signed-off-by: Ariel D'Alessandro Reviewed-by: Fabio Estevam --- arch/arm/include/asm/arch-imx8m/imx-regs.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h b/arch/arm/include/asm/arch-imx8m/imx-regs.h index 45d95a7c197..fb665412465 100644 --- a/arch/arm/include/asm/arch-imx8m/imx-regs.h +++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h @@ -58,6 +58,13 @@ #define SRC_DDRC_RCR_ADDR 0x30391000 #define SRC_DDRC2_RCR_ADDR 0x30391004 +#define APBH_DMA_ARB_BASE_ADDR 0x3300 +#define APBH_DMA_ARB_END_ADDR 0x33007FFF +#define MXS_APBH_BASE APBH_DMA_ARB_BASE_ADDR + +#define MXS_GPMI_BASE (APBH_DMA_ARB_BASE_ADDR + 0x02000) +#define MXS_BCH_BASE (APBH_DMA_ARB_BASE_ADDR + 0x04000) + #define DDRC_DDR_SS_GPR0 0x3d00 #define DDRC_IPS_BASE_ADDR(X) (0x3d40 + ((X) * 0x200)) #define DDR_CSD1_BASE_ADDR 0x4000 -- 2.34.1
[PATCH v3 0/6] imx8mn-smm-s2/pro: Add iMX8MN BSH SMM S2 boards
Introduce BSH SystemMaster (SMM) S2 board family, which consists of: iMX8MN SMM S2 and iMX8MN SMM S2 PRO boards. This patchset also adds support for NXP TJA11xx Ethernet PHYs. Changes in v3: * Added nxp-c45-tja11xx driver. * Added ethernet support to iMX8MN BSH SMM S2 boards. Changes in v2: * Properly added MAINTAINERS entry. * Fixed binman configuration. * Picked device tree from kernel. * Removed CONFIG_SPL_BUILD anti-pattern in board config. * Removed downstream stuff in bootargs. * Added board documentation. Ariel D'Alessandro (4): phy: nxp-c45-tja11xx: Rename functions to be c45 tja11xx specific iopoll: Extend read_poll_timeout macro to support variable parameters net: phy: Add phy_modify() accessor bsh: imx8mn-smm-s2/pro: Add iMX8MN BSH SMM S2 boards Michael Trimarchi (2): imx8m: add regs used by GPMI net: phy: nxp-tja11xx: Add NXP TJA11xx PHY driver arch/arm/dts/Makefile | 2 + arch/arm/dts/imx8mn-bsh-smm-s2-common.dtsi| 423 .../dts/imx8mn-bsh-smm-s2-u-boot-common.dtsi | 225 + arch/arm/dts/imx8mn-bsh-smm-s2-u-boot.dtsi| 15 + arch/arm/dts/imx8mn-bsh-smm-s2.dts| 48 + arch/arm/dts/imx8mn-bsh-smm-s2pro-u-boot.dtsi | 15 + arch/arm/dts/imx8mn-bsh-smm-s2pro.dts | 80 ++ arch/arm/include/asm/arch-imx8m/imx-regs.h| 7 + arch/arm/mach-imx/imx8m/Kconfig | 15 + arch/arm/mach-socfpga/reset_manager_s10.c | 20 +- board/bsh/imx8mn_smm_s2/Kconfig | 49 + board/bsh/imx8mn_smm_s2/MAINTAINERS | 8 + board/bsh/imx8mn_smm_s2/Makefile | 13 + board/bsh/imx8mn_smm_s2/ddr3l_timing_256m.c | 941 ++ board/bsh/imx8mn_smm_s2/ddr3l_timing_512m.c | 941 ++ board/bsh/imx8mn_smm_s2/imx8mn_smm_s2.c | 23 + board/bsh/imx8mn_smm_s2/imximage-8mn-ddr3.cfg | 10 + board/bsh/imx8mn_smm_s2/spl.c | 93 ++ configs/imx8mn_bsh_smm_s2_defconfig | 97 ++ configs/imx8mn_bsh_smm_s2pro_defconfig| 94 ++ doc/board/bsh/imx8mn_bsh_smm_s2.rst | 62 ++ doc/board/bsh/index.rst | 9 + doc/board/index.rst | 1 + drivers/mmc/rockchip_sdhci.c | 9 +- drivers/net/phy/Kconfig | 5 + drivers/net/phy/Makefile | 1 + drivers/net/phy/nxp-c45-tja11xx.c | 6 +- drivers/net/phy/nxp-tja11xx.c | 277 ++ drivers/net/phy/phy.c | 23 + include/configs/imx8mn_bsh_smm_s2.h | 52 + include/configs/imx8mn_bsh_smm_s2_common.h| 62 ++ include/configs/imx8mn_bsh_smm_s2pro.h| 35 + include/linux/iopoll.h| 12 +- include/phy.h | 3 + 34 files changed, 3654 insertions(+), 22 deletions(-) create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2-common.dtsi create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2-u-boot-common.dtsi create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2-u-boot.dtsi create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2.dts create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2pro-u-boot.dtsi create mode 100644 arch/arm/dts/imx8mn-bsh-smm-s2pro.dts create mode 100644 board/bsh/imx8mn_smm_s2/Kconfig create mode 100644 board/bsh/imx8mn_smm_s2/MAINTAINERS create mode 100644 board/bsh/imx8mn_smm_s2/Makefile create mode 100644 board/bsh/imx8mn_smm_s2/ddr3l_timing_256m.c create mode 100644 board/bsh/imx8mn_smm_s2/ddr3l_timing_512m.c create mode 100644 board/bsh/imx8mn_smm_s2/imx8mn_smm_s2.c create mode 100644 board/bsh/imx8mn_smm_s2/imximage-8mn-ddr3.cfg create mode 100644 board/bsh/imx8mn_smm_s2/spl.c create mode 100644 configs/imx8mn_bsh_smm_s2_defconfig create mode 100644 configs/imx8mn_bsh_smm_s2pro_defconfig create mode 100644 doc/board/bsh/imx8mn_bsh_smm_s2.rst create mode 100644 doc/board/bsh/index.rst create mode 100644 drivers/net/phy/nxp-tja11xx.c create mode 100644 include/configs/imx8mn_bsh_smm_s2.h create mode 100644 include/configs/imx8mn_bsh_smm_s2_common.h create mode 100644 include/configs/imx8mn_bsh_smm_s2pro.h -- 2.34.1
Re: [PATCH v3 1/1] env: fat: Allow overriding interface, device and partition
On Thu, Feb 17, 2022 at 10:55:39PM +0800, hyyxohk wrote: > For platform which can boot on different device, this allows > to override interface, device and partition from board code > > Signed-off-by: hyyxohk > --- > env/fat.c | 34 +++--- > include/env_internal.h | 20 > 2 files changed, 39 insertions(+), 15 deletions(-) Hi. When submitting patches, especially non-trivial ones, we follow the Linux Kernel guidelines: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst and require your name to be used in the signed-off-by line, and not a nickname / pseudonym. Can you please re-submit? Thanks. -- Tom signature.asc Description: PGP signature
Re:Re: Re: [PATCH v1 1/1] env: fat: Allow overriding interface, device and partition
sorry i just saw the email I have reworked the patch for v3 based on u-boot mainline At 2022-02-11 23:05:47, "Simon Glass" wrote: >Hi, > >On Sat, 29 Jan 2022 at 01:26, 何勇 wrote: >> >> Hi: >> Override the env_fat_get_dev_part function in the board file, you can >> load env from sdcard or emmc without modifying any configuration >> of u-boot, it is very useful for building wic firmware by yocto. >> >> it has been done under env/ext4.c > >I cannot see it. Can you please point me to the line number in that file? > >Do you have an English-text name you could use for the patch? > >Regards, >Simon > > >> >> >> >> >> >> >> >> At 2022-01-27 23:05:57, "Simon Glass" wrote: >> >Hi, >> > >> >On Thu, 30 Dec 2021 at 07:50, hyyxohk wrote: >> >> >> >> For platform which can boot on different device, this allows >> >> to override interface, device and partition from board code. >> >> >> >> Signed-off-by: hyyxohk >> >> --- >> >> env/fat.c | 30 +- >> >> include/env_internal.h | 20 >> >> 2 files changed, 37 insertions(+), 13 deletions(-) >> >> >> > >> >What is this feature used for? >> > >> >Regards, >> >Simon >> >[..]
Re: ARM A53 and initial MMU mapping for EL0/1/2/3 ?
On Fri, 11 Feb 2022 17:00:48 + Joakim Tjernlund wrote: Hi, > On Fri, 2022-02-11 at 15:00 +0100, Joakim Tjernlund wrote: > > On Fri, 2022-02-11 at 01:26 +, Andre Przywara wrote: > > > On Fri, 11 Feb 2022 00:22:25 + > > > Joakim Tjernlund wrote: > > > > > > > On Thu, 2022-02-10 at 22:43 +, Andre Przywara wrote: > > > > > On Thu, 10 Feb 2022 21:58:30 + > > > > > Joakim Tjernlund wrote: > > > > > > > > > > Hi, > > > > > > > > > > > On Thu, 2022-02-10 at 10:22 +, Andre Przywara wrote: > > > > > > > On Wed, 9 Feb 2022 12:03:47 + > > > > > > > Joakim Tjernlund wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > On Wed, 2022-02-09 at 10:45 +, Andre Przywara wrote: > > > > > > > > > On Wed, 9 Feb 2022 08:35:04 + > > > > > > > > > Joakim Tjernlund wrote: > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > On Wed, 2022-02-09 at 00:33 +, Andre Przywara wrote: > > > > > > > > > > > > > > > > > > > > > On Tue, 8 Feb 2022 22:05:00 + > > > > > > > > > > > Joakim Tjernlund wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Joakim, > > > > > > > > > > > > > > > > > > > > > > > Trying to figure out how I should map the MMU for > > > > > > > > > > > > normal RAM so it acessible > > > > > > > > > > > > from all ELx security states. > > > > > > > > > > > > > > > > > > > > > >^^^ > > > > > > > > > > > > > > > > > > > > > > This does not make much sense. U-Boot is typically > > > > > > > > > > > running in one > > > > > > > > > > > exception level only, and sets up the page table for > > > > > > > > > > > exactly that EL. > > > > > > > > > > > Each EL uses a separate translation regime (with some > > > > > > > > > > > twists for stage > > > > > > > > > > > 2 EL2 and combined EL1/0, plus VHE). If you map your > > > > > > > > > > > memory in EL3, then > > > > > > > > > > > drop to EL2, the EL3 page tables become irrelevant. > > > > > > > > > > > > > > > > > > > > > > So in U-Boot we just set up the page tables for the EL we > > > > > > > > > > > are running > > > > > > > > > > > in, and leave the paging for the lower exception levels > > > > > > > > > > > to be set up at > > > > > > > > > > > the discretion of our payloads (kernels, hypervisors). > > > > > > > > > > > > > > > > > > > > > > Please not that *secure* memory is a separate concept, > > > > > > > > > > > and handled by > > > > > > > > > > > external hardware, typically using regions, not page > > > > > > > > > > > tables. > > > > > > > > > > > > > > > > > > > > I am a beginner w.r.t ARM and Secure/Non secure so thank > > > > > > > > > > you for above. > > > > > > > > > > > > > > > > > > > > The problem I have is that I boot a custom SOC into u-boot > > > > > > > > > > and when u-boot tries > > > > > > > > > > to boot linux I get an error exception when u-boot calls > > > > > > > > > > armv8_switch_to_el2 to enter linux. > > > > > > > > > > > > > > > > > > So that means that U-Boot runs in EL3, is that the first and > > > > > > > > > only firmware > > > > > > > > > that you run? I think the EL3 part of U-Boot is not widely > > > > > > > > > used and tested > > > > > > > > > beyond the very few platforms that use it. > > > > > > > > > > > > > > > > Yes, u-boot is first firmware and runs in EL3(ATM, may change > > > > > > > > once initial bringup is complete) > > > > > > > > Maybe u-boot then lacks some critical init? Do you have an > > > > > > > > example of a board in u-boot > > > > > > > > that starts in EL3(from reset) using an A53 cpu? > > > > > > > > > > > > > > As you have probably figured out by now, the whole Layerscape > > > > > > > family uses > > > > > > > that approach. However most other platforms go with > > > > > > > Trusted-Firmware as the > > > > > > > EL3 setup and secure runtime service provider, so the U-Boot EL3 > > > > > > > code in > > > > > > > here is not well tested or looked after. For initial bringup it > > > > > > > might be > > > > > > > OK, but maybe the problems you run into are due to issues in this > > > > > > > code. > > > > > > > > > > > > > > > > Do you have the exact address that fails? That should be in > > > > > > > > > ELR, it would > > > > > > > > > be great if you can pinpoint the exact instruction in macro.h > > > > > > > > > that fails. > > > > > > > > > > > > > > > > Yes, the address is the first address where kernel is loaded > > > > > > > > and you can branch there without problems. > > > > > > > > > > > > > > You mean if you load the kernel and branch to the entry point, it > > > > > > > starts > > > > > > > running, but crashes as soon as it realises that in runs in EL3? > > > > > > > > > > > > > > > It is the eret instruction(last insn in macro > > > > > > > > armv8_switch_to_el2_m) that fails. > > > > > > > > > > > > > > Interesting.
[RFC PATCH v2 8/8] configs: synquacer: Add FWU support for DeveloperBox
Enable FWU Multi-Bank support for DeveloperBox SynQuacer platform. This also enables fwu_metadata_read command and "reboot soon after update" option. Signed-off-by: Masami Hiramatsu --- configs/synquacer_developerbox_defconfig |7 +++ 1 file changed, 7 insertions(+) diff --git a/configs/synquacer_developerbox_defconfig b/configs/synquacer_developerbox_defconfig index 692919e1f5..3bd875c797 100644 --- a/configs/synquacer_developerbox_defconfig +++ b/configs/synquacer_developerbox_defconfig @@ -95,3 +95,10 @@ CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y CONFIG_EFI_CAPSULE_ON_DISK=y CONFIG_EFI_IGNORE_OSINDICATIONS=y CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y +CONFIG_EFI_SECURE_BOOT=y +CONFIG_FWU_MULTI_BANK_UPDATE=y +CONFIG_FWU_MULTI_BANK_UPDATE_SF=y +CONFIG_FWU_MULTI_BANK_UPDATE_GPT_BLK=n +CONFIG_CMD_FWU_METADATA=y +CONFIG_FWU_REBOOT_AFTER_UPDATE=y +CONFIG_FWU_INIT_BROKEN_METADATA=y
[RFC PATCH v2 7/8] FWU: synquacer: Initialize broken metadata
Since the FWU metadata is not initialized at the installation,
if it is broken, it should be initialized. Usually, the FWU
metadata is not covered by capsule update, so it is safe to
initialize the metadata portion if it seems broken.
But for the production device, usually firmware will be installed
with initialized metadata, and the broken metadata means the
device can be compromized. In that case, build U-Boot without
this option.
Signed-off-by: Masami Hiramatsu
---
board/socionext/developerbox/Kconfig| 12 ++
board/socionext/developerbox/fwu_plat.c | 60 +++
2 files changed, 72 insertions(+)
diff --git a/board/socionext/developerbox/Kconfig
b/board/socionext/developerbox/Kconfig
index 4120098cab..9fbe8d1e74 100644
--- a/board/socionext/developerbox/Kconfig
+++ b/board/socionext/developerbox/Kconfig
@@ -44,4 +44,16 @@ config FWU_NUM_BANKS
config FWU_NUM_IMAGES_PER_BANK
default 1
+config FWU_INIT_BROKEN_METADATA
+ bool "Initialize FWU metadata if broken"
+ select BOARD_LATE_INIT
+ default n
+ help
+ Initialize FWU metadata if the metadata is broken.
+ This option is only for the development environment, since if the
+ metadata is broken, it means someone may compromize it. In that case
+ the production device must be bricked.
+ But for the development environment, or initial installation of the
+ FWU multi-bank update firmware, this will be useful.
+
endif
diff --git a/board/socionext/developerbox/fwu_plat.c
b/board/socionext/developerbox/fwu_plat.c
index cbbbd58bc0..1892f79660 100644
--- a/board/socionext/developerbox/fwu_plat.c
+++ b/board/socionext/developerbox/fwu_plat.c
@@ -176,3 +176,63 @@ void fwu_plat_get_bootidx(void *boot_idx)
else
*bootidx = devbox_plat_metadata->boot_index;
}
+
+#ifdef CONFIG_FWU_INIT_BROKEN_METADATA
+
+static void devbox_init_fwu_mdata(void)
+{
+ const efi_guid_t null_guid = NULL_GUID;
+ struct fwu_image_bank_info *bank;
+ struct fwu_mdata *metadata;
+ int i, j, ret;
+
+ metadata = memalign(ARCH_DMA_MINALIGN, sizeof(*metadata));
+ if (!metadata) {
+ log_err("Failed to allocate initial metadata.\n");
+ return;
+ }
+
+ metadata->version = 1;
+ metadata->active_index = 0;
+ metadata->previous_active_index = 0;
+
+ /*
+* Since the DeveloperBox doesn't use GPT, both of
+* fwu_image_entry::location_uuid and
+* fwu_img_bank_info::image_uuid are null GUID.
+*/
+ for (i = 0; i < CONFIG_FWU_NUM_IMAGES_PER_BANK; i++) {
+ guidcpy(>img_entry[i].image_type_uuid,
+ _fip_image_type_guid);
+ guidcpy(>img_entry[i].location_uuid,
+ _guid);
+ bank = metadata->img_entry[i].img_bank_info;
+
+ for (j = 0; j < CONFIG_FWU_NUM_BANKS; j++) {
+ guidcpy([j].image_uuid, _guid);
+ bank[j].accepted = (j == 0) ? 1 : 0;
+ bank[j].reserved = 0;
+ }
+ }
+
+ ret = fwu_update_mdata(metadata);
+ if (ret < 0)
+ log_err("Failed to initialize FWU metadata\n");
+ else
+ log_err("Initialized FWU metadata\n");
+ free(metadata);
+}
+
+int board_late_init(void)
+{
+ struct fwu_mdata *metadata;
+
+ if (fwu_get_mdata() < 0) {
+ // Initialize FWU metadata if broken
+ log_err("Unable to get a valid metadata. Initialize it.\n");
+ devbox_init_fwu_mdata();
+ }
+ return 0;
+}
+
+#endif
[RFC PATCH v2 5/8] FWU: Add FWU metadata access driver for SPI flash
For the platform which doesn't have GPT partitions for the firmware
but on SPI flash, the FWU metadata is stored on SPI flash as raw
image at specific offset. This driver gives the access methods
for those metadata information on the SPI flash.
Signed-off-by: Masami Hiramatsu
---
drivers/fwu-mdata/Kconfig|9 +
drivers/fwu-mdata/Makefile |1
drivers/fwu-mdata/fwu_mdata_sf.c | 294 ++
include/fwu.h|2
4 files changed, 306 insertions(+)
create mode 100644 drivers/fwu-mdata/fwu_mdata_sf.c
diff --git a/drivers/fwu-mdata/Kconfig b/drivers/fwu-mdata/Kconfig
index d5edef19d6..9bed3e9c1e 100644
--- a/drivers/fwu-mdata/Kconfig
+++ b/drivers/fwu-mdata/Kconfig
@@ -14,3 +14,12 @@ config FWU_MDATA_GPT_BLK
help
Enable support for accessing FWU Metadata on GPT partitioned
block devices.
+
+config FWU_MDATA_SF
+ bool "Enable FWU Multi Bank Update for SPI Flash"
+ depends on DM_FWU_MDATA
+ help
+ Enable FWU Multi Bank Update for SPI flash driver. This
+ driver does not depend on GPT. Instead, the platform must
+ provide some APIs and define the offset of the primary and
+ the secondary metadata.
diff --git a/drivers/fwu-mdata/Makefile b/drivers/fwu-mdata/Makefile
index 12a5b4fe04..f8db25ab69 100644
--- a/drivers/fwu-mdata/Makefile
+++ b/drivers/fwu-mdata/Makefile
@@ -5,3 +5,4 @@
obj-$(CONFIG_DM_FWU_MDATA) += fwu-mdata-uclass.o
obj-$(CONFIG_FWU_MDATA_GPT_BLK) += fwu_mdata_gpt_blk.o
+obj-$(CONFIG_FWU_MDATA_SF) += fwu_mdata_sf.o
diff --git a/drivers/fwu-mdata/fwu_mdata_sf.c b/drivers/fwu-mdata/fwu_mdata_sf.c
new file mode 100644
index 00..010528b91a
--- /dev/null
+++ b/drivers/fwu-mdata/fwu_mdata_sf.c
@@ -0,0 +1,294 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2021, Linaro Limited
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+struct fwu_mdata_sf_priv {
+ struct spi_flash *sf;
+ u32 pri_offset;
+ u32 sec_offset;
+};
+
+static int sf_load_data(struct spi_flash *sf, u32 offs, u32 size, void **data)
+{
+ int ret;
+
+ *data = memalign(ARCH_DMA_MINALIGN, size);
+ if (!*data)
+ return -ENOMEM;
+
+ ret = spi_flash_read(sf, offs, size, *data);
+ if (ret < 0) {
+ free(*data);
+ *data = NULL;
+ }
+
+ return ret;
+}
+
+static int sf_save_data(struct spi_flash *sf, u32 offs, u32 size, void *data)
+{
+ u32 sect_size, nsect;
+ void *buf;
+ int ret;
+
+ sect_size = sf->mtd.erasesize;
+ nsect = DIV_ROUND_UP(size, sect_size);
+ ret = spi_flash_erase(sf, offs, nsect * sect_size);
+ if (ret < 0)
+ return ret;
+
+ buf = memalign(ARCH_DMA_MINALIGN, size);
+ if (!buf)
+ return -ENOMEM;
+ memcpy(buf, data, size);
+
+ ret = spi_flash_write(sf, offs, size, buf);
+
+ free(buf);
+
+ return ret;
+}
+
+static int fwu_sf_load_mdata(struct spi_flash *sf, struct fwu_mdata **mdata,
u32 offs, bool primary)
+{
+ int ret;
+
+ ret = sf_load_data(sf, offs, sizeof(struct fwu_mdata), (void **)mdata);
+
+ if (ret >= 0) {
+ ret = fwu_verify_mdata(*mdata, primary);
+ if (ret < 0) {
+ free(*mdata);
+ *mdata = NULL;
+ }
+ }
+
+ return ret;
+}
+
+static int fwu_sf_load_primary_mdata(struct fwu_mdata_sf_priv *sf_priv,
+struct fwu_mdata **mdata)
+{
+ return fwu_sf_load_mdata(sf_priv->sf, mdata, sf_priv->pri_offset, true);
+}
+
+static int fwu_sf_load_secondary_mdata(struct fwu_mdata_sf_priv *sf_priv,
+ struct fwu_mdata **mdata)
+{
+ return fwu_sf_load_mdata(sf_priv->sf, mdata, sf_priv->sec_offset,
false);
+}
+
+static int fwu_sf_save_primary_mdata(struct fwu_mdata_sf_priv *sf_priv,
+struct fwu_mdata *mdata)
+{
+ return sf_save_data(sf_priv->sf, sf_priv->pri_offset,
+ sizeof(struct fwu_mdata), mdata);
+}
+
+static int fwu_sf_save_secondary_mdata(struct fwu_mdata_sf_priv *sf_priv,
+ struct fwu_mdata *mdata)
+{
+ return sf_save_data(sf_priv->sf, sf_priv->sec_offset,
+ sizeof(struct fwu_mdata), mdata);
+}
+
+static int fwu_sf_get_valid_mdata(struct fwu_mdata_sf_priv *sf_priv,
+ struct fwu_mdata **mdata)
+{
+ if (fwu_sf_load_primary_mdata(sf_priv, mdata) == 0)
+ return 0;
+
+ log_err("Failed to load/verify primary mdata. Try secondary.\n");
+
+ if (fwu_sf_load_secondary_mdata(sf_priv, mdata) == 0)
+ return 0;
+
+ log_err("Failed to load/verify secondary mdata.\n");
+
+
[RFC PATCH v2 6/8] FWU: synquacer: Add FWU Multi bank update support for DeveloperBox
The DeveloperBox platform can support the FWU Multi bank
update. SCP firmware will switch the boot mode by DSW3-4
and load the Multi bank update supported TF-A BL2 from
0x60 offset on the SPI flash. Thus it can co-exist
with the legacy boot mode (legacy U-Boot or EDK2).
Signed-off-by: Masami Hiramatsu
---
.../dts/synquacer-sc2a11-developerbox-u-boot.dtsi |7 +
board/socionext/developerbox/Kconfig | 12 +
board/socionext/developerbox/Makefile |1
board/socionext/developerbox/fwu_plat.c| 178
include/configs/synquacer.h| 10 +
5 files changed, 207 insertions(+), 1 deletion(-)
create mode 100644 board/socionext/developerbox/fwu_plat.c
diff --git a/arch/arm/dts/synquacer-sc2a11-developerbox-u-boot.dtsi
b/arch/arm/dts/synquacer-sc2a11-developerbox-u-boot.dtsi
index 095727e03c..d2078da8b8 100644
--- a/arch/arm/dts/synquacer-sc2a11-developerbox-u-boot.dtsi
+++ b/arch/arm/dts/synquacer-sc2a11-developerbox-u-boot.dtsi
@@ -23,7 +23,7 @@
active_clk_edges;
chipselect_num = <1>;
- spi-flash@0 {
+ spi_flash: spi-flash@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "jedec,spi-nor";
@@ -114,6 +114,11 @@
optee {
status = "okay";
};
+ fwu-mdata {
+ compatible = "u-boot,fwu-mdata-sf";
+ fwu-mdata-store = <_flash>;
+ mdata-offsets = <0x50 0x53>;
+ };
};
};
diff --git a/board/socionext/developerbox/Kconfig
b/board/socionext/developerbox/Kconfig
index c181d26a44..4120098cab 100644
--- a/board/socionext/developerbox/Kconfig
+++ b/board/socionext/developerbox/Kconfig
@@ -32,4 +32,16 @@ config SYS_CONFIG_NAME
default "synquacer"
endif
+
+config FWU_MULTI_BANK_UPDATE
+ select FWU_MDATA_SF
+ select DM_SPI_FLASH
+ select DM_FWU_MDATA
+
+config FWU_NUM_BANKS
+ default 6
+
+config FWU_NUM_IMAGES_PER_BANK
+ default 1
+
endif
diff --git a/board/socionext/developerbox/Makefile
b/board/socionext/developerbox/Makefile
index 4a46de995a..9b80ee38e7 100644
--- a/board/socionext/developerbox/Makefile
+++ b/board/socionext/developerbox/Makefile
@@ -7,3 +7,4 @@
#
obj-y := developerbox.o
+obj-$(CONFIG_FWU_MULTI_BANK_UPDATE) += fwu_plat.o
diff --git a/board/socionext/developerbox/fwu_plat.c
b/board/socionext/developerbox/fwu_plat.c
new file mode 100644
index 00..cbbbd58bc0
--- /dev/null
+++ b/board/socionext/developerbox/fwu_plat.c
@@ -0,0 +1,178 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2021, Linaro Limited
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+/* SPI Flash accessors */
+static struct spi_flash *plat_spi_flash;
+
+static int __plat_sf_get_flash(void)
+{
+ struct udevice *new;
+ int ret;
+
+ //TODO: define platform spi-flash somewhere.
+ ret = spi_flash_probe_bus_cs(CONFIG_SF_DEFAULT_BUS,
CONFIG_SF_DEFAULT_CS,
+CONFIG_SF_DEFAULT_SPEED,
CONFIG_SF_DEFAULT_MODE,
+);
+ if (ret)
+ return ret;
+
+ plat_spi_flash = dev_get_uclass_priv(new);
+ return 0;
+}
+
+static int plat_sf_get_flash(struct spi_flash **flash)
+{
+ int ret = 0;
+
+ if (!plat_spi_flash)
+ ret = __plat_sf_get_flash();
+
+ *flash = plat_spi_flash;
+
+ return ret;
+}
+
+static int sf_load_data(u32 offs, u32 size, void **data)
+{
+ struct spi_flash *flash;
+ int ret;
+
+ ret = plat_sf_get_flash();
+ if (ret < 0)
+ return ret;
+
+ *data = memalign(ARCH_DMA_MINALIGN, size);
+ if (!*data)
+ return -ENOMEM;
+
+ ret = spi_flash_read(flash, offs, size, *data);
+ if (ret < 0) {
+ free(*data);
+ *data = NULL;
+ }
+
+ return ret;
+}
+
+/* Platform dependent GUIDs */
+
+/* The GUID for the SNI FIP image type GUID */
+#define FWU_IMAGE_TYPE_DEVBOX_FIP_GUID \
+ EFI_GUID(0x7d6dc310, 0x52ca, 0x43b8, 0xb7, 0xb9, \
+0xf9, 0xd6, 0xc5, 0x01, 0xd1, 0x08)
+
+#define PLAT_METADATA_OFFSET 0x51
+#define PLAT_METADATA_SIZE (sizeof(struct devbox_metadata))
+
+struct __packed devbox_metadata {
+ u32 boot_index;
+ u32 boot_count;
+} *devbox_plat_metadata;
+
+static const efi_guid_t devbox_fip_image_type_guid =
FWU_IMAGE_TYPE_DEVBOX_FIP_GUID;
+
+int fwu_plat_get_image_alt_num(efi_guid_t image_type_id, u32 update_bank,
+ int *alt_no)
+{
+ /* DeveloperBox FWU Multi bank only supports FIP image. */
+ if (guidcmp(_type_id, _fip_image_type_guid))
+
[RFC PATCH v2 4/8] dt/bindings: firmware: Add FWU metadata on SPI flash binding
Add a devicetree-binding YAML file for the FWU metadata on SPI
Flash without GPT.
Signed-off-by: Masami Hiramatsu
---
.../firmware/fwu-mdata-sf.yaml | 38
1 file changed, 38 insertions(+)
create mode 100644 doc/device-tree-bindings/firmware/fwu-mdata-sf.yaml
diff --git a/doc/device-tree-bindings/firmware/fwu-mdata-sf.yaml
b/doc/device-tree-bindings/firmware/fwu-mdata-sf.yaml
new file mode 100644
index 00..3d8726231f
--- /dev/null
+++ b/doc/device-tree-bindings/firmware/fwu-mdata-sf.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/u-boot,fwu-mdata-sf.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: FWU metadata on SPI Flash without GPT
+
+maintainers:
+ - Masami Hiramatsu
+
+properties:
+ compatible:
+items:
+ - const: u-boot,fwu-mdata-sf
+
+ fwu-mdata-store:
+maxItems: 1
+description: Phandle of the SPI NOR flash device which contains the FWU
medatata.
+
+ mdata-offsets:
+minItems: 2
+description: Offsets of the primary and secondary FWU metadata in the NOR
flash.
+
+required:
+ - compatible
+ - fwu-mdata-store
+ - mdata-offsets
+
+additionalProperties: false
+
+examples:
+ - |
+fwu-mdata {
+compatible = "u-boot,fwu-mdata-sf";
+fwu-mdata-store = <>;
+mdata-offsets = <0x50 0x53>;
+};
[RFC PATCH v2 3/8] synquacer: Update for TBBR based new FIP layout
This changes SPI NOR flash partition layout for TBBR and
also make the U-Boot as position independent executable
again because BL33 is loaded on the memory.
With enabling TBBR, TF-A BL2 loads all BL3x images from
FIP image, and the U-Boot image is added to the FIP image
as BL33, and loaded to memory when boot instead of XIP
on SPI NOR flash. To avoid mixing up with the legacy images,
this new FIP image is stored on unused area (0x60-) and
the U-Boot env vars are also stored at 0x58 so that
it will not break existing EDK2 area.
Signed-off-by: Masami Hiramatsu
---
.../dts/synquacer-sc2a11-developerbox-u-boot.dtsi | 26 ++--
configs/synquacer_developerbox_defconfig |5 ++--
include/configs/synquacer.h|4 +--
3 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/arch/arm/dts/synquacer-sc2a11-developerbox-u-boot.dtsi
b/arch/arm/dts/synquacer-sc2a11-developerbox-u-boot.dtsi
index 7a56116d6f..095727e03c 100644
--- a/arch/arm/dts/synquacer-sc2a11-developerbox-u-boot.dtsi
+++ b/arch/arm/dts/synquacer-sc2a11-developerbox-u-boot.dtsi
@@ -56,7 +56,7 @@
};
partition@18 {
- label = "FIP-TFA";
+ label = "LegacyFIP";
reg = <0x18 0x78000>;
};
@@ -66,18 +66,28 @@
};
partition@20 {
- label = "U-Boot";
- reg = <0x20 0x10>;
+ label = "EDK2";
+ reg = <0x20 0x20>;
};
- partition@30 {
- label = "UBoot-Env";
- reg = <0x30 0x10>;
+ partition@40 {
+ label = "EDK2-Env";
+ reg = <0x40 0x10>;
};
partition@50 {
- label = "Ex-OPTEE";
- reg = <0x50 0x20>;
+ label = "Metadata";
+ reg = <0x50 0x8>;
+ };
+
+ partition@58 {
+ label = "UBoot-Env";
+ reg = <0x58 0x8>;
+ };
+
+ partition@60 {
+ label = "FIP";
+ reg = <0x60 0x40>;
};
};
};
diff --git a/configs/synquacer_developerbox_defconfig
b/configs/synquacer_developerbox_defconfig
index 4fb0fba441..692919e1f5 100644
--- a/configs/synquacer_developerbox_defconfig
+++ b/configs/synquacer_developerbox_defconfig
@@ -1,9 +1,10 @@
CONFIG_ARM=y
CONFIG_ARCH_SYNQUACER=y
-CONFIG_SYS_TEXT_BASE=0x0820
+CONFIG_POSITION_INDEPENDENT=y
+CONFIG_SYS_TEXT_BASE=0
CONFIG_SYS_MALLOC_LEN=0x100
CONFIG_ENV_SIZE=0x3
-CONFIG_ENV_OFFSET=0x30
+CONFIG_ENV_OFFSET=0x58
CONFIG_ENV_SECT_SIZE=0x1
CONFIG_DM_GPIO=y
CONFIG_DEFAULT_DEVICE_TREE="synquacer-sc2a11-developerbox"
diff --git a/include/configs/synquacer.h b/include/configs/synquacer.h
index 3d099b4f11..1b6e6d011e 100644
--- a/include/configs/synquacer.h
+++ b/include/configs/synquacer.h
@@ -52,9 +52,7 @@
/* #define CONFIG_SYS_PCI_64BIT1 */
#define DEFAULT_DFU_ALT_INFO "dfu_alt_info=" \
- "mtd nor1=u-boot.bin raw 20 10;"\
- "fip.bin raw 18 78000;" \
- "optee.bin raw 50 10\0"
+ "mtd nor1=fip.bin raw 60 40\0"
/* Distro boot settings */
#ifndef CONFIG_SPL_BUILD
[RFC PATCH v2 2/8] FWU: Free metadata copy if gpt_get_mdata() failed
It is better if a function which returns an error then release
all allocated memory resources. This simplifies the mind model
and less chance to forgot to free memory and double free.
Signed-off-by: Masami Hiramatsu
---
drivers/fwu-mdata/fwu-mdata-uclass.c | 24 ++--
drivers/fwu-mdata/fwu_mdata_gpt_blk.c | 49 ++---
2 files changed, 36 insertions(+), 37 deletions(-)
diff --git a/drivers/fwu-mdata/fwu-mdata-uclass.c
b/drivers/fwu-mdata/fwu-mdata-uclass.c
index b98eda3789..c1cd77243f 100644
--- a/drivers/fwu-mdata/fwu-mdata-uclass.c
+++ b/drivers/fwu-mdata/fwu-mdata-uclass.c
@@ -79,12 +79,12 @@ int fwu_verify_mdata(struct fwu_mdata *mdata, bool pri_part)
int fwu_get_active_index(u32 *active_idx)
{
int ret;
- struct fwu_mdata *mdata = NULL;
+ struct fwu_mdata *mdata;
ret = fwu_get_mdata();
if (ret < 0) {
log_err("Unable to get valid FWU metadata\n");
- goto out;
+ return ret;
}
/*
@@ -96,8 +96,6 @@ int fwu_get_active_index(u32 *active_idx)
log_err("Active index value read is incorrect\n");
ret = -EINVAL;
}
-
-out:
free(mdata);
return ret;
@@ -115,17 +113,17 @@ out:
int fwu_update_active_index(u32 active_idx)
{
int ret;
- struct fwu_mdata *mdata = NULL;
+ struct fwu_mdata *mdata;
if (active_idx > CONFIG_FWU_NUM_BANKS - 1) {
log_err("Active index value to be updated is incorrect\n");
- return -1;
+ return -EINVAL;
}
ret = fwu_get_mdata();
if (ret < 0) {
log_err("Unable to get valid FWU metadata\n");
- goto out;
+ return ret;
}
/*
@@ -144,8 +142,6 @@ int fwu_update_active_index(u32 active_idx)
log_err("Failed to update FWU metadata partitions\n");
ret = -EIO;
}
-
-out:
free(mdata);
return ret;
@@ -225,12 +221,12 @@ int fwu_revert_boot_index(void)
{
int ret;
u32 cur_active_index;
- struct fwu_mdata *mdata = NULL;
+ struct fwu_mdata *mdata;
ret = fwu_get_mdata();
if (ret < 0) {
log_err("Unable to get valid FWU metadata\n");
- goto out;
+ return ret;
}
/*
@@ -250,8 +246,6 @@ int fwu_revert_boot_index(void)
log_err("Failed to update FWU metadata partitions\n");
ret = -EIO;
}
-
-out:
free(mdata);
return ret;
@@ -277,14 +271,14 @@ static int fwu_set_clear_image_accept(efi_guid_t
*img_type_id,
{
int ret, i;
u32 nimages;
- struct fwu_mdata *mdata = NULL;
+ struct fwu_mdata *mdata;
struct fwu_image_entry *img_entry;
struct fwu_image_bank_info *img_bank_info;
ret = fwu_get_mdata();
if (ret < 0) {
log_err("Unable to get valid FWU metadata\n");
- goto out;
+ return ret;
}
nimages = CONFIG_FWU_NUM_IMAGES_PER_BANK;
diff --git a/drivers/fwu-mdata/fwu_mdata_gpt_blk.c
b/drivers/fwu-mdata/fwu_mdata_gpt_blk.c
index 9170c3f6af..a32195db2e 100644
--- a/drivers/fwu-mdata/fwu_mdata_gpt_blk.c
+++ b/drivers/fwu-mdata/fwu_mdata_gpt_blk.c
@@ -177,18 +177,9 @@ static int fwu_gpt_update_mdata(struct udevice * dev,
struct fwu_mdata *mdata)
return 0;
}
-static int gpt_get_mdata(struct blk_desc *desc, struct fwu_mdata **mdata)
+static int gpt_get_mdata_part(struct blk_desc *desc, struct fwu_mdata **mdata,
u16 part)
{
int ret;
- u16 primary_mpart = 0, secondary_mpart = 0;
-
- ret = gpt_get_mdata_partitions(desc, _mpart,
- _mpart);
-
- if (ret < 0) {
- log_err("Error getting the FWU metadata partitions\n");
- return -ENODEV;
- }
*mdata = malloc(sizeof(struct fwu_mdata));
if (!*mdata) {
@@ -196,28 +187,42 @@ static int gpt_get_mdata(struct blk_desc *desc, struct
fwu_mdata **mdata)
return -ENOMEM;
}
- ret = gpt_read_mdata(desc, *mdata, primary_mpart);
+ ret = gpt_read_mdata(desc, *mdata, part);
if (ret < 0) {
log_err("Failed to read the FWU metadata from the device\n");
- return -EIO;
+ ret = -EIO;
+ } else {
+ ret = fwu_verify_mdata(*mdata, 1);
+ if (!ret)
+ return 0;
}
+ free(*mdata);
+
+ return ret;
+}
- ret = fwu_verify_mdata(*mdata, 1);
+static int gpt_get_mdata(struct blk_desc *desc, struct fwu_mdata **mdata)
+{
+ int ret;
+ u16 primary_mpart = 0, secondary_mpart = 0;
+
+ ret = gpt_get_mdata_partitions(desc, _mpart,
+ _mpart);
+
+ if (ret < 0) {
+
[RFC PATCH v2 1/8] FWU: Calculate CRC32 in fwu_update_mdata()
To avoid calculating crc32 in several places, do it in
fwu_update_mdata(). This also ensures the mdata crc32
is always sane.
Signed-off-by: Masami Hiramatsu
---
drivers/fwu-mdata/fwu-mdata-uclass.c | 33 ++---
1 file changed, 10 insertions(+), 23 deletions(-)
diff --git a/drivers/fwu-mdata/fwu-mdata-uclass.c
b/drivers/fwu-mdata/fwu-mdata-uclass.c
index 64b3051ecf..b98eda3789 100644
--- a/drivers/fwu-mdata/fwu-mdata-uclass.c
+++ b/drivers/fwu-mdata/fwu-mdata-uclass.c
@@ -115,7 +115,6 @@ out:
int fwu_update_active_index(u32 active_idx)
{
int ret;
- void *buf;
struct fwu_mdata *mdata = NULL;
if (active_idx > CONFIG_FWU_NUM_BANKS - 1) {
@@ -136,14 +135,6 @@ int fwu_update_active_index(u32 active_idx)
mdata->previous_active_index = mdata->active_index;
mdata->active_index = active_idx;
- /*
-* Calculate the crc32 for the updated FWU metadata
-* and put the updated value in the FWU metadata crc32
-* field
-*/
- buf = >version;
- mdata->crc32 = crc32(0, buf, sizeof(*mdata) - sizeof(u32));
-
/*
* Now write this updated FWU metadata to both the
* FWU metadata partitions
@@ -233,7 +224,6 @@ int fwu_mdata_check(void)
int fwu_revert_boot_index(void)
{
int ret;
- void *buf;
u32 cur_active_index;
struct fwu_mdata *mdata = NULL;
@@ -251,14 +241,6 @@ int fwu_revert_boot_index(void)
mdata->active_index = mdata->previous_active_index;
mdata->previous_active_index = cur_active_index;
- /*
-* Calculate the crc32 for the updated FWU metadata
-* and put the updated value in the FWU metadata crc32
-* field
-*/
- buf = >version;
- mdata->crc32 = crc32(0, buf, sizeof(*mdata) - sizeof(u32));
-
/*
* Now write this updated FWU metadata to both the
* FWU metadata partitions
@@ -293,7 +275,6 @@ out:
static int fwu_set_clear_image_accept(efi_guid_t *img_type_id,
u32 bank, u8 action)
{
- void *buf;
int ret, i;
u32 nimages;
struct fwu_mdata *mdata = NULL;
@@ -316,10 +297,6 @@ static int fwu_set_clear_image_accept(efi_guid_t
*img_type_id,
else
img_bank_info->accepted = 0;
- buf = >version;
- mdata->crc32 = crc32(0, buf, sizeof(*mdata) -
-sizeof(u32));
-
ret = fwu_update_mdata(mdata);
goto out;
}
@@ -425,6 +402,16 @@ int fwu_update_mdata(struct fwu_mdata *mdata)
return -ENOSYS;
}
+ if (!mdata)
+ return -EINVAL;
+ /*
+* Calculate the crc32 for the updated FWU metadata
+* and put the updated value in the FWU metadata crc32
+* field
+*/
+ mdata->crc32 = crc32(0, (const unsigned char *)>version,
+sizeof(*mdata) - sizeof(u32));
+
return ops->update_mdata(dev, mdata);
}
[RFC PATCH v2 0/8] FWU: Add FWU Multi Bank Update for DeveloerBox
Hi, Here is the 2nd version of RFC series of patches for the FWU Multi Bank Update support for the DeveloperBox platform. This series depends on Sughosh's Multi Bank Update v4 [1]. [1] https://lore.kernel.org/all/20220207182001.31270-1-sughosh.g...@linaro.org/T/#u Unlike the STM32MP board, DeveloperBox (SynQuacer) loads the firmware from SPI NOR flash. Thus it doesn't use GPT partitions to store the firmware banks and the FWU metadata. Instead, it stores those data at fixed address areas on SPI NOR flash. I carefully chose the areas which doesn't overlap the previous firmware and EDK2. This adds FWU metadata SF driver for this FWU multi bank support on SPI flash without GPT. This is identified by "u-boot,fwu-mdata-sf". The last patch adds the DT bindings in YAML. Since there is no GPT, the location GUID for images and the image GUID for banks are Null GUID. I will fix this with uuid property for fixed-partition devicetree afterwards. And the SynQuacer also does not have any non-volatile register. Thus this allocates the platform defined boot index on the SPI flash too. NOTE: To use this series, you also need to update SCP firmware[2] and TF-A[3] on the DeveloperBox. Those are under cleaning up. [2] https://git.linaro.org/people/masami.hiramatsu/SCP-firmware.git/ [3] https://git.linaro.org/people/masami.hiramatsu/arm-trusted-firmware.git/ Thank you, --- Masami Hiramatsu (8): FWU: Calculate CRC32 in fwu_update_mdata() FWU: Free metadata copy if gpt_get_mdata() failed synquacer: Update for TBBR based new FIP layout dt/bindings: firmware: Add FWU metadata on SPI flash binding FWU: Add FWU metadata access driver for SPI flash FWU: synquacer: Add FWU Multi bank update support for DeveloperBox FWU: synquacer: Initialize broken metadata configs: synquacer: Add FWU support for DeveloperBox .../dts/synquacer-sc2a11-developerbox-u-boot.dtsi | 33 ++ board/socionext/developerbox/Kconfig | 24 ++ board/socionext/developerbox/Makefile |1 board/socionext/developerbox/fwu_plat.c| 238 configs/synquacer_developerbox_defconfig | 12 + .../firmware/fwu-mdata-sf.yaml | 38 +++ drivers/fwu-mdata/Kconfig |9 + drivers/fwu-mdata/Makefile |1 drivers/fwu-mdata/fwu-mdata-uclass.c | 57 +--- drivers/fwu-mdata/fwu_mdata_gpt_blk.c | 49 ++- drivers/fwu-mdata/fwu_mdata_sf.c | 294 include/configs/synquacer.h| 14 + include/fwu.h |2 13 files changed, 698 insertions(+), 74 deletions(-) create mode 100644 board/socionext/developerbox/fwu_plat.c create mode 100644 doc/device-tree-bindings/firmware/fwu-mdata-sf.yaml create mode 100644 drivers/fwu-mdata/fwu_mdata_sf.c -- Masami Hiramatsu
[PATCH v3 1/1] env: fat: Allow overriding interface, device and partition
For platform which can boot on different device, this allows
to override interface, device and partition from board code
Signed-off-by: hyyxohk
---
env/fat.c | 34 +++---
include/env_internal.h | 20
2 files changed, 39 insertions(+), 15 deletions(-)
diff --git a/env/fat.c b/env/fat.c
index fdccd6cd2a..6251d9649b 100644
--- a/env/fat.c
+++ b/env/fat.c
@@ -32,7 +32,12 @@
DECLARE_GLOBAL_DATA_PTR;
-static char *env_fat_device_and_part(void)
+__weak const char *env_fat_get_intf(void)
+{
+ return (const char *)CONFIG_ENV_FAT_INTERFACE;
+}
+
+__weak char *env_fat_get_dev_part(void)
{
#ifdef CONFIG_MMC
static char *part_str;
@@ -60,14 +65,15 @@ static int env_fat_save(void)
int dev, part;
int err;
loff_t size;
+ const char *ifname = env_fat_get_intf();
+ const char *dev_and_part = env_fat_get_dev_part();
err = env_export(_new);
if (err)
return err;
- part = blk_get_device_part_str(CONFIG_ENV_FAT_INTERFACE,
- env_fat_device_and_part(),
- _desc, , 1);
+ part = blk_get_device_part_str(ifname, dev_and_part,
+ _desc, , 1);
if (part < 0)
return 1;
@@ -77,8 +83,7 @@ static int env_fat_save(void)
* This printf is embedded in the messages from env_save that
* will calling it. The missing \n is intentional.
*/
- printf("Unable to use %s %d:%d... \n",
- CONFIG_ENV_FAT_INTERFACE, dev, part);
+ printf("Unable to use %s %d:%d...\n", ifname, dev, part);
return 1;
}
@@ -93,8 +98,7 @@ static int env_fat_save(void)
* This printf is embedded in the messages from env_save that
* will calling it. The missing \n is intentional.
*/
- printf("Unable to write \"%s\" from %s%d:%d... \n",
- file, CONFIG_ENV_FAT_INTERFACE, dev, part);
+ printf("Unable to write \"%s\" from %s%d:%d...\n", file,
ifname, dev, part);
return 1;
}
@@ -117,15 +121,16 @@ static int env_fat_load(void)
struct disk_partition info;
int dev, part;
int err1;
+ const char *ifname = env_fat_get_intf();
+ const char *dev_and_part = env_fat_get_dev_part();
#ifdef CONFIG_MMC
- if (!strcmp(CONFIG_ENV_FAT_INTERFACE, "mmc"))
+ if (!strcmp(ifname, "mmc"))
mmc_initialize(NULL);
#endif
- part = blk_get_device_part_str(CONFIG_ENV_FAT_INTERFACE,
- env_fat_device_and_part(),
- _desc, , 1);
+ part = blk_get_device_part_str(ifname, dev_and_part,
+ _desc, , 1);
if (part < 0)
goto err_env_relocate;
@@ -135,8 +140,7 @@ static int env_fat_load(void)
* This printf is embedded in the messages from env_save that
* will calling it. The missing \n is intentional.
*/
- printf("Unable to use %s %d:%d... \n",
- CONFIG_ENV_FAT_INTERFACE, dev, part);
+ printf("Unable to use %s %d:%d...\n", ifname, dev, part);
goto err_env_relocate;
}
@@ -154,7 +158,7 @@ static int env_fat_load(void)
* will calling it. The missing \n is intentional.
*/
printf("Unable to read \"%s\" from %s%d:%d... \n",
- CONFIG_ENV_FAT_FILE, CONFIG_ENV_FAT_INTERFACE, dev,
part);
+ CONFIG_ENV_FAT_FILE, ifname, dev, part);
goto err_env_relocate;
}
diff --git a/include/env_internal.h b/include/env_internal.h
index 07c227ecc0..b704c03363 100644
--- a/include/env_internal.h
+++ b/include/env_internal.h
@@ -245,6 +245,26 @@ const char *env_ext4_get_dev_part(void);
* Return: an enum env_location value on success, or -ve error code.
*/
enum env_location env_get_location(enum env_operation op, int prio);
+
+/**
+ * env_fat_get_intf() - Provide the interface for env in FAT
+ *
+ * It is a weak function allowing board to overidde the default interface for
+ * U-Boot env in FAT: CONFIG_ENV_FAT_INTERFACE
+ *
+ * Return: string of interface, empty if not supported
+ */
+const char *env_fat_get_intf(void);
+
+/**
+ * env_fat_get_dev_part() - Provide the device and partition for env in FAT
+ *
+ * It is a weak function allowing board to overidde the default device and
+ * partition used for U-Boot env in FAT: CONFIG_ENV_FAT_DEVICE_AND_PART
+ *
+ * Return: string of device and partition
+ */
+char *env_fat_get_dev_part(void);
#endif /* DO_DEPS_ONLY */
#endif /* _ENV_INTERNAL_H_ */
--
2.17.1
Re: [PATCH u-boot-mvebu 5/5] arm: mvebu: a37xx: Add support for reading Security OTP values
On Thu, 17 Feb 2022 10:26:19 +0100
Pali Rohár wrote:
> Only secure CM3 core can access Security OTP. It is not possible via A53
It is not possible for the A53 core (on which U-Boot is running) to read
it directly.
> core on which is running U-Boot. Marvell for this purpose defined mbox API
For this purpose Marvell defined...
> for sending OTP commands between CM and A53 cores.
^CM3
> Implement this Marvell mbox API via U-Boot fuse API.
Implement these Marvell fuse reading mbox commands via
> Banks 0-43 are used for accessing Security OTP (44 rows with 67 bits via 44
> banks and words 0-2).
Note that of the 67 bits, the 3 upper bits are: 1 lock bit and 2
auxiliary bits (meant for testing during the manufacture of the SOC, as
I understand it).
Also note that the lock bit and the auxiliary bits are not readable
via Marvell commands.
With CZ.NIC's commands the lock bit is readable.
> Write support is not implemented yet.
>
> Signed-off-by: Pali Rohár
> ---
> arch/arm/mach-mvebu/armada3700/efuse.c | 40 --
> 1 file changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-mvebu/armada3700/efuse.c
> b/arch/arm/mach-mvebu/armada3700/efuse.c
> index 03778f17ea49..274d9c72c073 100644
> --- a/arch/arm/mach-mvebu/armada3700/efuse.c
> +++ b/arch/arm/mach-mvebu/armada3700/efuse.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #define OTP_NB_REG_BASE ((void __iomem
> *)MVEBU_REGISTER(0x12600))
> @@ -77,6 +78,42 @@ static void otp_read_parallel(void __iomem *base, u32
> *data, u32 count)
> }
> }
>
> +static int rwtm_otp_read(u8 row, u32 word, u32 *data)
> +{
> + u32 out[3];
> + u32 in[2];
> + int res;
> +
> + /*
> + * MBOX_CMD_OTP_READ_32B command is supported by Marvell fuse.bin
> + * firmware and also by new (yet unreleased) CZ.NIC wtmi firmware.
Marvell's, CZ.NIC's, and drop the "(yet unreleased)", because you'll
need to send another patch that drops it afterwards.
> + * But this command does not provide access to lock bit.
> + */
> + if (word < 2) {
> + in[0] = row;
> + in[1] = word * 32;
> + res = mbox_do_cmd(MBOX_CMD_OTP_READ_32B, in, 2, out, 2);
> + if (res != -ENOSYS) {
> + if (!res)
> + *data = out[0];
> + return res;
> + }
> + /* Fallback for old version of CZ.NIC wtmi firmware. */
> + }
I am afraid this is not correct, because Marvell's firmware reads the
efuse without Error Correction. So it is possible for Marvell's command
to return different value than CZ.NIC's command.
You need to determine whether CZ.NIC's command is supported, and use it
if it is, otherwise use Marvell's command. Or you need to define
whether and when the Error Correction is supposed to be used, or
something.
But doing what you are doing here can make Turris MOX boards read
different values. I know of at least one board where serial number or
MAC address needs Error Correction.
Marek
Re: [PATCH u-boot-mvebu 4/5] arm: mvebu: a37xx: Extend mbox_do_cmd() code
On Thu, 17 Feb 2022 10:26:18 +0100
Pali Rohár wrote:
> Allow to specify input parameters, define all available mbox commands
> supported by CZ.NIC secure firmware + Marvell fuse.bin firmware and fix
CZ.NIC's and also Marvell's
> parsing response from Marvell OTP commands.
>
> Signed-off-by: Pali Rohár
...
> #define MBOX_STS_ERROR(s)((s) & (3 << 30))
> #define MBOX_STS_VALUE(s)(((s) >> 10) & 0xf)
> #define MBOX_STS_CMD(s) ((s) & 0x3ff)
> +#define MBOX_STS_MARVELL_ERROR(s)((s) == 0 ? 0 : (s) == 2 ? ETIMEDOUT :
> (s) == 3 ? EINVAL : (s) == 4 ? ENOSYS : EIO)
This is starting to become too complicated for a macro :-(
What do you think about converting all these to a static function?
Something like
static int mbox_parse_status(u32 status, u16 *cmd, u32 *value,
bool marvell)
{
...
}
>
> #ifndef _MVEBU_MBOX_H
> @@ -16,8 +17,24 @@ enum mbox_cmd {
>
> MBOX_CMD_OTP_READ,
> MBOX_CMD_OTP_WRITE,
> +
> + MBOX_CMD_REBOOT,
> +
> + /* OTP read commands supported by Marvell fuse.bin firmware */
Marvell's
> + MBOX_CMD_OTP_READ_1B= 257,
> + MBOX_CMD_OTP_READ_8B,
> + MBOX_CMD_OTP_READ_32B,
> + MBOX_CMD_OTP_READ_64B,
> + MBOX_CMD_OTP_READ_256B,
> +
> + /* OTP write commands supported by Marvell fuse.bin firmware */
Marvell's
Re: [PATCH u-boot-mvebu 3/5] arm: mvebu: a37xx: Move generic mbox code to arch/arm/mach-mvebu
On Thu, 17 Feb 2022 10:26:17 +0100 Pali Rohár wrote: > Generic A3720 mbox code is currently in Turris Mox specific board file > board/CZ.NIC/turris_mox/mox_sp.c. Move it to board independent arch file > arch/arm/mach-mvebu/armada3700/mbox.c. Reviewed-by: Marek Behún
Re: [PATCH u-boot-mvebu 2/5] arm: mvebu: a37xx: Enable fuse command on all Armada 3720 boards
On Thu, 17 Feb 2022 10:26:16 +0100 Pali Rohár wrote: > Allows to read OTP bits via U-Boot fuse command on all Armada 3720 boards. ^Allow (we use present simple in commit messages) otherwise Reviewed-by: Marek Behún
Re: [PATCH u-boot-mvebu 1/5] arm: mvebu: a37xx: Add support for reading NB and SB fuse OTP value
On Thu, 17 Feb 2022 10:26:15 +0100 Pali Rohár wrote: > Implement it via U-Boot fuse API. nitpick: In commit messages I prefer not to refer to commit title, i.e. instead of Implement it via U-Boot fuse API. I would write Implement reading NB and SB fuses of Armada 37xx SOC via U-Boot fuse API. as the first sentence. > > Banks 0-43 are reserved for accessing Security OTP (not implemented yet). > Bank 44 is used for accessing North Bridge OTP (69 bits via words 0-2). > Bank 45 is used for accessing South Bridge OTP (97 bits via words 0-3). > > Write support is not implemented yet as it looks like that both North ^because/since > and South Bridge OTPs are already burned in factory with some data. Meaning ^The meaning > of some bits of North Bridge are documented in WTMI source code. Meaning of ^is (or meaningS are) ^The meaning of > bits in South Bridge is unknown. Otherwise Reviewed-by: Marek Behún
Re: [PATCH V3 16/16] include: configs: Update env for selecting right dtb
On Wed, Feb 09, 2022 at 03:07:01PM +0530, Sinthu Raja wrote: > From: Sinthu Raja > > Now that single defconfig can be used for booting J721E EVM and > SK, default device tree will not work for selecting dtb for > kernel. Update the findfdt env to select right dtb based on > board_name env variable. > > Signed-off-by: Sinthu Raja Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH V3 15/16] configs: j721e_evm: Store env in MMC FAT partition
On Wed, Feb 09, 2022 at 03:07:00PM +0530, Sinthu Raja wrote: > From: Sinthu Raja > > Enable defconfigs relevant for storing env on FAT partion of MMC. > > Signed-off-by: Sinthu Raja Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH V3 10/16] arm: dts: k3-j721e-sk: Add initial A72 specific dts support
On Wed, Feb 09, 2022 at 03:06:55PM +0530, Sinthu Raja wrote: > From: Sinthu Raja > > J721E Starter Kit (SK)[1] is a low cost, small form factor board designed > for TI’s J721E SoC. TI’s J721E SoC comprises of dual core A72, high > performance vision accelerators, video codec accelerators, latest C71x > and C66x DSP, high bandwidth real-time IPs for capture and display, GPU, > dedicated safety island and security accelerators. The SoC is power > optimized to provide best in class performance for industrial and > automotive applications. > > J721E SK supports the following interfaces: > * 4 GB LPDDR4 RAM > * x1 Gigabit Ethernet interface > * x1 USB 3.0 Type-C port > * x3 USB 3.0 Type-A ports > * x1 PCIe M.2 E Key > * x1 PCIe M.2 M Key > * 512 Mbit OSPI flash > * x2 CSI2 Camera interface (RPi and TI Camera connector) > * 40-pin Raspberry Pi GPIO header > > Add A72 specific dts for J721E-SK. > > [1] https://www.ti.com/tool/SK-TDA4VM > > Signed-off-by: Sinthu Raja Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH V3 14/16] configs: j721e_evm_a72: Align OSPI partitions on erase block boundary
On Wed, Feb 09, 2022 at 03:06:59PM +0530, Sinthu Raja wrote: > From: Sinthu Raja > > S28HS512T on TI SK has sector size of 256KB, so update OSPI partition > to align on 256KB sector size. Since the sector size for MT35XU512ABA > on EVM is 128KB, partitions will remain aligned for EVM. > > Also, now since the sector size is 256KB ospi.env.backup will collide > with ospi.sysfw, so move ospi.env.backup to the padding space (0x7C) > before ospi.rootfs partition. > > Signed-off-by: Sinthu Raja Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH V3 13/16] configs: j721e_evm_a72: Add SK dtb as part of DTB FIT
On Wed, Feb 09, 2022 at 03:06:58PM +0530, Sinthu Raja wrote: > From: Sinthu Raja > > Add k3-j721e-sk dtb along with other dtbs inside DTB FIT image. > > Signed-off-by: Sinthu Raja Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH V3 12/16] configs: j721e_evm_r5: Enable support for building multiple dtbs into FIT
On Wed, Feb 09, 2022 at 03:06:57PM +0530, Sinthu Raja wrote: > From: Sinthu Raja > > Enable configs for building multiple dtbs into a single fit image > and load the right dtb for next stage. This will help to use same > defconfig for both J721E EVM and SK boards. > > Signed-off-by: Sinthu Raja Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH V3 11/16] arm: dts: k3-j721e-r5-sk: Add initial R5 specific dts support for j721e-sk
On Wed, Feb 09, 2022 at 03:06:56PM +0530, Sinthu Raja wrote: > From: Sinthu Raja > > Add R5 specific dts for J721E-SK > > Signed-off-by: Sinthu Raja Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH V3 09/16] arm: dts: k3-j721e-r5-common-proc-board: Do not use power-domains for I2C
On Wed, Feb 09, 2022 at 03:06:54PM +0530, Sinthu Raja wrote: > From: Sinthu Raja > > Board ID I2C EEPROM will be probed before SYSFW is available. > So drop the power-domains property for wakup_i2c0 on which > board ID EEPROM is connected. > > Signed-off-by: Sinthu Raja Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH V3 08/16] arm: j721e: Add support for selecting DT based on board name
On Wed, Feb 09, 2022 at 03:06:53PM +0530, Sinthu Raja wrote: > From: Sinthu Raja > > Enable support for selecting DTB from FIT within SPL based on the > board name read from EEPROM. This will help to use single defconfig > for both EVM and SK. > > Signed-off-by: Sinthu Raja Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH V3 07/16] board: ti: j721e: Add support for detecting multiple device trees
On Wed, Feb 09, 2022 at 03:06:52PM +0530, Sinthu Raja wrote: > From: Sinthu Raja > > Update the board_fit_config_name_match() to choose the right dtb > based on the board name read from EEPROM. > > Also restrict multpile EEPROM reads by verifying if EEPROM is already > read. > > Signed-off-by: Sinthu Raja Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH V3 06/16] board: ti: j721e: Disable probing of daughtercards
On Wed, Feb 09, 2022 at 03:06:51PM +0530, Sinthu Raja wrote: > From: Sinthu Raja > > j721e-sk doesn't have any daughter cards, so disable daughter > card probing inside board_late_init() and spl_board_init() for > j721e-sk. > > Signed-off-by: Sinthu Raja Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH V3 05/16] board: ti: j721e: Add support to update board_name for j721e-sk
On Wed, Feb 09, 2022 at 03:06:50PM +0530, Sinthu Raja wrote: > From: Sinthu Raja > > Update setup_board_eeprom_env() to choose the right board name > for j721e-sk. > > Signed-off-by: Sinthu Raja Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH V3 03/16] board: ti: j721e: Guard functions with right #ifdef to avoid build warnings
On Wed, Feb 09, 2022 at 03:06:48PM +0530, Sinthu Raja wrote: > From: Sinthu Raja > > board_late_init(), setup_board_eeprom_env() and setup_serial() is > called only under CONFIG_BOARD_LATE_INIT, so guard these functions > with the same. Also, reorder these functions to place it under > single #ifdef > > Signed-off-by: Sinthu Raja Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH V3 04/16] board: ti: j721e: Enable support for reading EEPROM at next alternate address
On Wed, Feb 09, 2022 at 03:06:49PM +0530, Sinthu Raja wrote: > From: Sinthu Raja > > J721E EVM has EEPROM populated at 0x50. J721E SK has EEPROM populated > at next address 0x51 in order to be compatible with RPi. So start > looking for TI specific EEPROM at 0x50, if not found look for EEPROM at > 0x51. > > Signed-off-by: Sinthu Raja Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH V3 02/16] drivers: power: regulator: tps65941_regulator: Add support for 3Phase buck
On Wed, Feb 09, 2022 at 03:06:47PM +0530, Sinthu Raja wrote: > From: Sinthu Raja > > Buck regulator 1, 2 and 3 of TPS6594132 on j721e-sk is in 3 Phase > confguration, in-order to support this, add configuring 3 Phase buck > in tps65941 while driver probing. > > Signed-off-by: Sinthu Raja > Acked-by: Jaehoon Chung Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH V3 01/16] drivers: power: pmic: Add support for tps659412 PMIC
On Wed, Feb 09, 2022 at 03:06:46PM +0530, Sinthu Raja wrote: > From: Sinthu Raja > > Since TPS659412 and TPS659413 are both software compatible, > add a compatible string for the same inside tps65941.c. > > Signed-off-by: Sinthu Raja > Acked-by: Jaehoon Chung Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] arm: dts: k3-j721e-r5-sk: Update R5 DT to pick the new DDR config
On Tue, Nov 02, 2021 at 07:59:45PM +0530, Sinthu Raja wrote: > From: Sinthu Raja > > A new lpddr4 configuration is introduced for J7 SK with 4266 MTs data > rate. Therefore, update the R5 DTS file to point to the new DDR config > file. > > Signed-off-by: Sinthu Raja Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] arm: dts: k3-j721e-sk: EMIF tool update to 0.6.1 with 4266MTs for lpddr4
On Tue, Nov 02, 2021 at 07:59:44PM +0530, Sinthu Raja wrote: > From: Sinthu Raja > > EMIF tool for J721E SK is now updated to 0.6.1 that includes > * Updated write DQ training pattern to enable user pattern and clock > pattern (from 0x7 to 0x6). > * Updated IO drive strength to 40-80-80 Ohms. > > J721E SK uses the lpddr4 configuration of 4266 MTs data rate which is > the same as J721E EVM but facing random failures. As the tool update is > specific to the SK board, add a new lpddr4 config of 4266 MTs. > > Signed-off-by: Kevin Scholz > Signed-off-by: Sinthu Raja Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-usb/master
On Wed, Feb 16, 2022 at 08:27:15PM +0100, Marek Vasut wrote: > The following changes since commit ab8903a24db11571d634ef255976bb364c3ba64d: > > configs: Resync with savedefconfig (2022-02-14 22:21:29 +) > > are available in the Git repository at: > > git://source.denx.de/u-boot-usb.git master > > for you to fetch changes up to d5daa02d8d9e7c403a3339db1966e8413e64e408: > > usb: xhci: reset endpoint on USB stall (2022-02-16 17:11:31 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH 5/5] arm64: zynqmp: Fix debug uart initialization
The commit 0dba45864b2a ("arm: Init the debug UART") calls
debug_uart_init() from crt0.S but it won't work because SOC is not
configured yet. That's why create board_debug_uart_init() which calls
psu_init() via new psu_uboot_init() earlier before the first access to UART
in SPL. In full U-Boot call psu_uboot_init() only when
CONFIG_ZYNQMP_PSU_INIT_ENABLED is enabled.
Signed-off-by: Michal Simek
---
arch/arm/Kconfig | 1 +
.../mach-zynqmp/include/mach/psu_init_gpl.h | 1 +
arch/arm/mach-zynqmp/spl.c| 12 ++-
board/xilinx/zynqmp/zynqmp.c | 32 +--
4 files changed, 35 insertions(+), 11 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c5b21cd06e79..5e237d86211a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1199,6 +1199,7 @@ config ARCH_ZYNQMP
select ARM64
select CLK
select DM
+ select DEBUG_UART_BOARD_INIT if SPL && DEBUG_UART
select DM_ETH if NET
select DM_MAILBOX
select DM_MMC if MMC
diff --git a/arch/arm/mach-zynqmp/include/mach/psu_init_gpl.h
b/arch/arm/mach-zynqmp/include/mach/psu_init_gpl.h
index e37acda2f89e..434a7fa20e43 100644
--- a/arch/arm/mach-zynqmp/include/mach/psu_init_gpl.h
+++ b/arch/arm/mach-zynqmp/include/mach/psu_init_gpl.h
@@ -22,5 +22,6 @@ void prog_reg(unsigned long addr, unsigned long mask,
int psu_init(void);
unsigned long psu_post_config_data(void);
+int psu_uboot_init(void);
#endif /* _PSU_INIT_GPL_H_ */
diff --git a/arch/arm/mach-zynqmp/spl.c b/arch/arm/mach-zynqmp/spl.c
index 6b836cbff2d7..b428fd53121a 100644
--- a/arch/arm/mach-zynqmp/spl.c
+++ b/arch/arm/mach-zynqmp/spl.c
@@ -19,9 +19,19 @@
#include
#include
+#if defined(CONFIG_DEBUG_UART_BOARD_INIT)
+void board_debug_uart_init(void)
+{
+ psu_uboot_init();
+}
+#endif
+
void board_init_f(ulong dummy)
{
- board_early_init_f();
+#if !defined(CONFIG_DEBUG_UART_BOARD_INIT)
+ psu_uboot_init();
+#endif
+
board_early_init_r();
#ifdef CONFIG_SPL_ZYNQMP_DRAM_ECC_INIT
zynqmp_ecc_init();
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 3a10ed859d2c..70b3c81f1284 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -313,10 +313,8 @@ static char *zynqmp_get_silicon_idcode_name(void)
}
#endif
-#if defined(CONFIG_BOARD_EARLY_INIT_F)
-int board_early_init_f(void)
+int __maybe_unused psu_uboot_init(void)
{
-#if defined(CONFIG_ZYNQMP_PSU_INIT_ENABLED)
int ret;
ret = psu_init();
@@ -336,16 +334,30 @@ int board_early_init_f(void)
/* Delay is required for clocks to be propagated */
udelay(100);
-#endif
+
+ return 0;
+}
-#ifdef CONFIG_DEBUG_UART
- /* Uart debug for sure */
- debug_uart_init();
- puts("Debug uart enabled\n"); /* or printch() */
-#endif
+#if !defined(CONFIG_SPL_BUILD)
+# if defined(CONFIG_DEBUG_UART_BOARD_INIT)
+void board_debug_uart_init(void)
+{
+# if defined(CONFIG_ZYNQMP_PSU_INIT_ENABLED)
+ psu_uboot_init();
+# endif
+}
+# endif
- return 0;
+# if defined(CONFIG_BOARD_EARLY_INIT_F)
+int board_early_init_f(void)
+{
+ int ret = 0;
+# if defined(CONFIG_ZYNQMP_PSU_INIT_ENABLED) &&
!defined(CONFIG_DEBUG_UART_BOARD_INIT)
+ ret = psu_uboot_init();
+# endif
+ return ret;
}
+# endif
#endif
static int multi_boot(void)
--
2.35.0
[PATCH 4/5] ARM: zynq: Fix debug uart initialization
The commit 0dba45864b2a ("arm: Init the debug UART") calls
debug_uart_init() from crt0.S but it won't work because SOC is not
configured yet. That's why create board_debug_uart_init() which calls
ps7_init() earlier before the first access to UART.
Signed-off-by: Michal Simek
---
arch/arm/Kconfig | 1 +
arch/arm/mach-zynq/spl.c | 15 +--
board/xilinx/zynq/board.c | 7 +++
3 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ae5002c9e4d1..c5b21cd06e79 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1157,6 +1157,7 @@ config ARCH_ZYNQ
select CLK
select CLK_ZYNQ
select CPU_V7A
+ select DEBUG_UART_BOARD_INIT if SPL && DEBUG_UART
select DM
select DM_ETH if NET
select DM_MMC if MMC
diff --git a/arch/arm/mach-zynq/spl.c b/arch/arm/mach-zynq/spl.c
index b1a5184b6898..fea1c9b12ad1 100644
--- a/arch/arm/mach-zynq/spl.c
+++ b/arch/arm/mach-zynq/spl.c
@@ -16,17 +16,20 @@
#include
#include
+#if defined(CONFIG_DEBUG_UART_BOARD_INIT)
+void board_debug_uart_init(void)
+{
+ ps7_init();
+}
+#endif
+
void board_init_f(ulong dummy)
{
+#if !defined(CONFIG_DEBUG_UART_BOARD_INIT)
ps7_init();
+#endif
arch_cpu_init();
-
-#ifdef CONFIG_DEBUG_UART
- /* Uart debug for sure */
- debug_uart_init();
- puts("Debug uart enabled\n"); /* or printch() */
-#endif
}
#ifdef CONFIG_SPL_BOARD_INIT
diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
index ad6fca9c..26ef0488358d 100644
--- a/board/xilinx/zynq/board.c
+++ b/board/xilinx/zynq/board.c
@@ -25,6 +25,13 @@
DECLARE_GLOBAL_DATA_PTR;
+#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_DEBUG_UART_BOARD_INIT)
+void board_debug_uart_init(void)
+{
+ /* Add initialization sequence if UART is not configured */
+}
+#endif
+
int board_init(void)
{
if (IS_ENABLED(CONFIG_SPL_BUILD))
--
2.35.0
[PATCH 2/5] arm64: zynqmp: Build psu_spl_init for SPL all the time
ZYNQMP_PSU_INIT_ENABLED specifically saying that has connection to full U-Boot not SPL that's why build psu_spl_init for SPL all the time. Also disable ZYNQMP_PSU_INIT_ENABLED because it ends up in situation that psu_init() is called twice which is wrong. By default only SPL should call it. Signed-off-by: Michal Simek --- arch/arm/mach-zynqmp/Makefile| 2 +- configs/xilinx_zynqmp_virt_defconfig | 1 - 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/mach-zynqmp/Makefile b/arch/arm/mach-zynqmp/Makefile index eb6c5112b375..4f9f6b56a98a 100644 --- a/arch/arm/mach-zynqmp/Makefile +++ b/arch/arm/mach-zynqmp/Makefile @@ -6,6 +6,6 @@ obj-y += clk.o obj-y += cpu.o obj-$(CONFIG_MP) += mp.o -obj-$(CONFIG_SPL_BUILD) += spl.o handoff.o +obj-$(CONFIG_SPL_BUILD) += spl.o handoff.o psu_spl_init.o obj-$(CONFIG_SPL_ZYNQMP_DRAM_ECC_INIT) += ecc_spl_init.o obj-$(CONFIG_ZYNQMP_PSU_INIT_ENABLED) += psu_spl_init.o diff --git a/configs/xilinx_zynqmp_virt_defconfig b/configs/xilinx_zynqmp_virt_defconfig index 9b1880867867..def7696b3d34 100644 --- a/configs/xilinx_zynqmp_virt_defconfig +++ b/configs/xilinx_zynqmp_virt_defconfig @@ -20,7 +20,6 @@ CONFIG_CMD_FRU=y CONFIG_PMUFW_INIT_FILE="/mnt/disk/som/pmufw.bin" CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE="/mnt/disk/u-boot/pmu_obj.bin" CONFIG_ZYNQMP_USB=y -CONFIG_ZYNQMP_PSU_INIT_ENABLED=y CONFIG_AHCI=y CONFIG_DISTRO_DEFAULTS=y CONFIG_SYS_LOAD_ADDR=0x800 -- 2.35.0
[PATCH 3/5] arm64: zynqmp: Fix dependencies around ZYNQMP_PSU_INIT_ENABLED
ZYNQMP_PSU_INIT_ENABLED is called only when BOARD_EARLY_INIT_F is defined
that's why cover this dependency in Kconfig.
board_early_init_f() is only part related to
CONFIG_ZYNQMP_PSU_INIT_ENABLED which is disabled now that's why disable
BOARD_EARLY_INIT_F and also build board_early_init_f() only when
CONFIG_BOARD_EARLY_INIT_F is enabled.
Signed-off-by: Michal Simek
---
arch/arm/mach-zynqmp/Kconfig | 1 +
board/xilinx/zynqmp/zynqmp.c | 2 ++
configs/xilinx_zynqmp_virt_defconfig | 1 -
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-zynqmp/Kconfig b/arch/arm/mach-zynqmp/Kconfig
index f8b5906039d1..66045067d2fe 100644
--- a/arch/arm/mach-zynqmp/Kconfig
+++ b/arch/arm/mach-zynqmp/Kconfig
@@ -140,6 +140,7 @@ config DEFINE_TCM_OCM_MMAP
config ZYNQMP_PSU_INIT_ENABLED
bool "Include psu_init"
+ select BOARD_EARLY_INIT_F
help
Include psu_init to full u-boot. SPL include psu_init by default.
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 242e143cbfd7..3a10ed859d2c 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -313,6 +313,7 @@ static char *zynqmp_get_silicon_idcode_name(void)
}
#endif
+#if defined(CONFIG_BOARD_EARLY_INIT_F)
int board_early_init_f(void)
{
#if defined(CONFIG_ZYNQMP_PSU_INIT_ENABLED)
@@ -345,6 +346,7 @@ int board_early_init_f(void)
return 0;
}
+#endif
static int multi_boot(void)
{
diff --git a/configs/xilinx_zynqmp_virt_defconfig
b/configs/xilinx_zynqmp_virt_defconfig
index def7696b3d34..3bb54c86ca00 100644
--- a/configs/xilinx_zynqmp_virt_defconfig
+++ b/configs/xilinx_zynqmp_virt_defconfig
@@ -30,7 +30,6 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x1000
# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
CONFIG_USE_PREBOOT=y
CONFIG_PREBOOT="run scsi_init;usb start"
-CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_BOARD_EARLY_INIT_R=y
CONFIG_SPL_STACK_R=y
CONFIG_SPL_FPGA=y
--
2.35.0
[PATCH 1/5] xilinx: Enable OF_BOARD for zynq and zynqmp boards
The commit 985503439762 ("fdt: Don't call board_fdt_blob_setup() without
OF_BOARD") forced to enable OF_BOARD for platforms which provide DT
externally. Zynq/ZynqMP boards are using this feature for a long time
that's why there is a need to enable it by default.
Also code expects to return error in case of error that's why also fill it.
Signed-off-by: Michal Simek
---
board/xilinx/common/board.c | 3 ++-
configs/xilinx_zynq_virt_defconfig | 1 +
configs/xilinx_zynqmp_virt_defconfig | 1 +
3 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 6fce23197a48..0068cb879263 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -319,7 +319,7 @@ __maybe_unused int xilinx_read_eeprom(void)
return 0;
}
-#if defined(CONFIG_OF_BOARD) || defined(CONFIG_OF_SEPARATE)
+#if defined(CONFIG_OF_BOARD)
void *board_fdt_blob_setup(int *err)
{
void *fdt_blob;
@@ -355,6 +355,7 @@ void *board_fdt_blob_setup(int *err)
debug("DTB is also not passed via %p\n", fdt_blob);
+ *err = -EINVAL;
return NULL;
}
#endif
diff --git a/configs/xilinx_zynq_virt_defconfig
b/configs/xilinx_zynq_virt_defconfig
index b19a7884ef47..5d180455f8d5 100644
--- a/configs/xilinx_zynq_virt_defconfig
+++ b/configs/xilinx_zynq_virt_defconfig
@@ -59,6 +59,7 @@ CONFIG_CMD_MTDPARTS=y
CONFIG_CMD_MTDPARTS_SPREAD=y
CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES=y
CONFIG_CMD_UBI=y
+CONFIG_OF_BOARD=y
CONFIG_OF_LIST="zynq-zc702 zynq-zc706 zynq-zc770-xm010 zynq-zc770-xm011
zynq-zc770-xm011-x16 zynq-zc770-xm012 zynq-zc770-xm013 zynq-cc108 zynq-microzed
zynq-minized zynq-picozed zynq-zed zynq-zturn zynq-zturn-v5 zynq-zybo
zynq-zybo-z7 zynq-dlc20-rev1.0"
CONFIG_ENV_IS_NOWHERE=y
CONFIG_ENV_IS_IN_FAT=y
diff --git a/configs/xilinx_zynqmp_virt_defconfig
b/configs/xilinx_zynqmp_virt_defconfig
index dfe65cb401e7..9b1880867867 100644
--- a/configs/xilinx_zynqmp_virt_defconfig
+++ b/configs/xilinx_zynqmp_virt_defconfig
@@ -84,6 +84,7 @@ CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES=y
CONFIG_CMD_UBI=y
CONFIG_PARTITION_TYPE_GUID=y
CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_BOARD=y
CONFIG_OF_LIST="avnet-ultra96-rev1 zynqmp-a2197-revA zynqmp-e-a2197-00-revA
zynqmp-g-a2197-00-revA zynqmp-m-a2197-01-revA zynqmp-m-a2197-02-revA
zynqmp-m-a2197-03-revA zynqmp-p-a2197-00-revA zynqmp-zc1232-revA
zynqmp-zc1254-revA zynqmp-zc1751-xm015-dc1 zynqmp-zc1751-xm016-dc2
zynqmp-zc1751-xm017-dc3 zynqmp-zc1751-xm018-dc4 zynqmp-zc1751-xm019-dc5
zynqmp-zcu100-revC zynqmp-zcu102-rev1.1 zynqmp-zcu102-rev1.0 zynqmp-zcu102-revA
zynqmp-zcu102-revB zynqmp-zcu104-revA zynqmp-zcu104-revC zynqmp-zcu106-revA
zynqmp-zcu111-revA zynqmp-zcu1275-revA zynqmp-zcu1275-revB zynqmp-zcu1285-revA
zynqmp-zcu208-revA zynqmp-zcu216-revA zynqmp-topic-miamimp-xilinx-xdp-v1r1
zynqmp-sm-k26-revA zynqmp-smk-k26-revA zynqmp-dlc21-revA"
CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names interrupt-parent
interrupts iommus power-domains"
CONFIG_ENV_IS_NOWHERE=y
--
2.35.0
[PATCH 0/5] xilinx: Fix issues in v2022.04-rc1/2
Hi,
I found that two commits which were recently merged to u-boot are breaking
especially Xilinx ZynqMP boards.
The commit 985503439762 ("fdt: Don't call board_fdt_blob_setup()
and commit 0dba45864b2a ("arm: Init the debug UART") requires changes in
platform to get u-boot work as worked before.
Thanks,
Michal
Michal Simek (5):
xilinx: Enable OF_BOARD for zynq and zynqmp boards
arm64: zynqmp: Build psu_spl_init for SPL all the time
arm64: zynqmp: Fix dependencies around ZYNQMP_PSU_INIT_ENABLED
ARM: zynq: Fix debug uart initialization
arm64: zynqmp: Fix debug uart initialization
arch/arm/Kconfig | 2 ++
arch/arm/mach-zynq/spl.c | 15 +
arch/arm/mach-zynqmp/Kconfig | 1 +
arch/arm/mach-zynqmp/Makefile | 2 +-
.../mach-zynqmp/include/mach/psu_init_gpl.h | 1 +
arch/arm/mach-zynqmp/spl.c| 12 ++-
board/xilinx/common/board.c | 3 +-
board/xilinx/zynq/board.c | 7
board/xilinx/zynqmp/zynqmp.c | 32 +--
configs/xilinx_zynq_virt_defconfig| 1 +
configs/xilinx_zynqmp_virt_defconfig | 3 +-
11 files changed, 59 insertions(+), 20 deletions(-)
--
2.35.0
Re: [PATCH 7/7] microblaze: exception: drop user exception support
Hi Michal, On 2/15/22 14:16, Michal Simek wrote: [Please note: This e-mail is from an EXTERNAL e-mail address] On 2/13/22 09:09, Ovidiu Panait wrote: A user exception is triggered by inserting a bralid/brki jump to "C_BASE_VECTORS+0x8" in the software flow. Because u-boot microblaze code does not deal with MMU-related features such as user-mode/privileged-mode separation, there are no code sequences that call into the user exception handler. It seems there is no real usecase for having user exception support in u-boot, so drop the code that installs the nop handler. U-Boot still supports to run user code on the top of u-boot which doesn't need to handle these kind of exceptions. That's why it is good to jump to this code and let you know about it. Thanks for the feedback, this patch should just be ignored then. The rest of this series I think it's still a good addition to the microblaze exception code. Ovidiu M
Re: [PATCH u-boot-marvell v2 2/2] arm: mvebu: turris_omnia: Reset the board immediately on DDR training failure
On Thursday 17 February 2022 13:54:43 Marek Behún wrote: > From: Marek Behún > > The state of the current DDR training code for Armada 38x is such that > we cannot be sure it will always train successfully - although after the > last change we were yet unable to find a board that failed DDR training, > from experience in the last 2 years we know that it is possible. > > The experience also tells us that in many cases the board fails training > only sometimes, and after a reset the training is successful. > > Enable the new option that makes the board reset itself on DDR training > failure immediately. Until now we called hang() in such a case, which > meant that the board was reset by the MCU after 120 seconds. > > Signed-off-by: Marek Behún Reviewed-by: Pali Rohár > --- > configs/turris_omnia_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig > index d6f70caeaf..010d69adcc 100644 > --- a/configs/turris_omnia_defconfig > +++ b/configs/turris_omnia_defconfig > @@ -11,6 +11,7 @@ CONFIG_NR_DRAM_BANKS=2 > CONFIG_SYS_MEMTEST_START=0x0080 > CONFIG_SYS_MEMTEST_END=0x00ff > CONFIG_TARGET_TURRIS_OMNIA=y > +CONFIG_DDR_RESET_ON_TRAINING_FAILURE=y > CONFIG_ENV_SIZE=0x1 > CONFIG_ENV_OFFSET=0xF > CONFIG_ENV_SECT_SIZE=0x1 > -- > 2.34.1 >
Re: [PATCH u-boot-marvell v2 2/2] arm: mvebu: turris_omnia: Reset the board immediately on DDR training failure
On 2/17/22 13:54, Marek Behún wrote: From: Marek Behún The state of the current DDR training code for Armada 38x is such that we cannot be sure it will always train successfully - although after the last change we were yet unable to find a board that failed DDR training, from experience in the last 2 years we know that it is possible. The experience also tells us that in many cases the board fails training only sometimes, and after a reset the training is successful. Enable the new option that makes the board reset itself on DDR training failure immediately. Until now we called hang() in such a case, which meant that the board was reset by the MCU after 120 seconds. Signed-off-by: Marek Behún Reviewed-by: Stefan Roese Thanks, Stefan --- configs/turris_omnia_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig index d6f70caeaf..010d69adcc 100644 --- a/configs/turris_omnia_defconfig +++ b/configs/turris_omnia_defconfig @@ -11,6 +11,7 @@ CONFIG_NR_DRAM_BANKS=2 CONFIG_SYS_MEMTEST_START=0x0080 CONFIG_SYS_MEMTEST_END=0x00ff CONFIG_TARGET_TURRIS_OMNIA=y +CONFIG_DDR_RESET_ON_TRAINING_FAILURE=y CONFIG_ENV_SIZE=0x1 CONFIG_ENV_OFFSET=0xF CONFIG_ENV_SECT_SIZE=0x1 Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH u-boot-marvell v2 1/2] arm: mvebu: spl: Add option to reset the board on DDR training failure
On 2/17/22 13:54, Marek Behún wrote:
From: Marek Behún
Some boards may occacionally fail DDR training. Currently we hang() in
this case. Add an option that makes the board do an immediate reset in
such a case, so that a new training is tried as soon as possible,
instead of hanging and possibly waiting for watchdog to reset the board.
(If the DDR training fails while booting the image via UART, we will
still hang - it doesn't make sense to reset in such a case, because
after reset the board will try booting from another medium, and the
UART booting utility does not expect that.)
Signed-off-by: Marek Behún
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
Changes since v1:
- dont reset if booting via UART, as suggested by Pali
---
arch/arm/mach-mvebu/Kconfig | 13 +
arch/arm/mach-mvebu/spl.c | 7 ++-
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index d23cc0c760..7d487f270b 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -213,6 +213,19 @@ config DDR_LOG_LEVEL
At level 3, rovides the windows margin of each DQ as a results of
DQS centeralization.
+config DDR_RESET_ON_TRAINING_FAILURE
+ bool "Reset the board on DDR training failure instead of hanging"
+ depends on ARMADA_38X || ARMADA_XP
+ help
+ If DDR training fails in SPL, reset the board instead of hanging.
+ Some boards are known to fail DDR training occasionally and an
+ immediate reset may be preferable to waiting until the board is
+ reset by watchdog (if there even is one).
+
+ Note that if booting via UART and the DDR training fails, the
+ device will still hang - it doesn't make sense to reset the board
+ in such a case.
+
config SYS_BOARD
default "clearfog" if TARGET_CLEARFOG
default "helios4" if TARGET_HELIOS4
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 273ecb8bd6..5ad323f9d9 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include
#include
#include
@@ -330,7 +331,11 @@ void board_init_f(ulong dummy)
ret = ddr3_init();
if (ret) {
printf("ddr3_init() failed: %d\n", ret);
- hang();
+ if (IS_ENABLED(CONFIG_DDR_RESET_ON_TRAINING_FAILURE) &&
+ get_boot_device() != BOOT_DEVICE_UART)
+ reset_cpu();
+ else
+ hang();
}
#endif
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH u-boot-marvell v2 1/2] arm: mvebu: spl: Add option to reset the board on DDR training failure
On Thursday 17 February 2022 13:54:42 Marek Behún wrote:
> From: Marek Behún
>
> Some boards may occacionally fail DDR training. Currently we hang() in
> this case. Add an option that makes the board do an immediate reset in
> such a case, so that a new training is tried as soon as possible,
> instead of hanging and possibly waiting for watchdog to reset the board.
>
> (If the DDR training fails while booting the image via UART, we will
> still hang - it doesn't make sense to reset in such a case, because
> after reset the board will try booting from another medium, and the
> UART booting utility does not expect that.)
>
> Signed-off-by: Marek Behún
Reviewed-by: Pali Rohár
> ---
> Changes since v1:
> - dont reset if booting via UART, as suggested by Pali
> ---
> arch/arm/mach-mvebu/Kconfig | 13 +
> arch/arm/mach-mvebu/spl.c | 7 ++-
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> index d23cc0c760..7d487f270b 100644
> --- a/arch/arm/mach-mvebu/Kconfig
> +++ b/arch/arm/mach-mvebu/Kconfig
> @@ -213,6 +213,19 @@ config DDR_LOG_LEVEL
> At level 3, rovides the windows margin of each DQ as a results of
> DQS centeralization.
>
> +config DDR_RESET_ON_TRAINING_FAILURE
> + bool "Reset the board on DDR training failure instead of hanging"
> + depends on ARMADA_38X || ARMADA_XP
> + help
> + If DDR training fails in SPL, reset the board instead of hanging.
> + Some boards are known to fail DDR training occasionally and an
> + immediate reset may be preferable to waiting until the board is
> + reset by watchdog (if there even is one).
> +
> + Note that if booting via UART and the DDR training fails, the
> + device will still hang - it doesn't make sense to reset the board
> + in such a case.
> +
> config SYS_BOARD
> default "clearfog" if TARGET_CLEARFOG
> default "helios4" if TARGET_HELIOS4
> diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
> index 273ecb8bd6..5ad323f9d9 100644
> --- a/arch/arm/mach-mvebu/spl.c
> +++ b/arch/arm/mach-mvebu/spl.c
> @@ -4,6 +4,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -330,7 +331,11 @@ void board_init_f(ulong dummy)
> ret = ddr3_init();
> if (ret) {
> printf("ddr3_init() failed: %d\n", ret);
> - hang();
> + if (IS_ENABLED(CONFIG_DDR_RESET_ON_TRAINING_FAILURE) &&
> + get_boot_device() != BOOT_DEVICE_UART)
> + reset_cpu();
> + else
> + hang();
> }
> #endif
>
> --
> 2.34.1
>
[PATCH V2] dt-bindings: nvmem: add U-Boot environment variables binding
From: Rafał Miłecki
U-Boot uses environment variables for storing device setup data. It
usually needs to be accessed by a bootloader, kernel and often
user-space.
This binding allows describing environment data located in a raw flash
partition. It's treated as NVMEM device and can be reused later for
other storage devices.
Using DT should be cleaner than hardcoding & duplicating such info in
multiple places. Bootloader & kernel can share DTS and user-space can
try reading it too or just have correct data exposed by a kernel.
A custom "compatible" string allows system to automatically load
relevant NVMEM driver but phandle can be also used for reading raw
location.
Signed-off-by: Rafał Miłecki
---
V2: Update descriptions to don't make this binding MTD (flash partition)
specific. Mention multiple possible storage ways.
---
.../devicetree/bindings/nvmem/u-boot,env.yaml | 66 +++
MAINTAINERS | 5 ++
2 files changed, 71 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
diff --git a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
new file mode 100644
index ..a53e34152c97
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/u-boot,env.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: U-Boot environment variables
+
+description: |
+ U-Boot uses environment variables to store device parameters and
+ configuration. They may be used for booting process, setup or keeping end
user
+ info.
+
+ Data is stored using U-Boot specific formats (variant specific header and NUL
+ separated key-value pairs).
+
+ Environment data can be stored on various storage entities, e.g.:
+ 1. Raw flash partition
+ 2. UBI volume
+
+ This binding allows marking storage device (as containing env data) and
+ specifying used format.
+
+ Right now only flash partition case is covered but it may be extended to e.g.
+ UBI volumes in the future.
+
+maintainers:
+ - Rafał Miłecki
+
+allOf:
+ - $ref: nvmem.yaml#
+
+properties:
+ compatible:
+oneOf:
+ - description: A standalone env data block
+const: u-boot,env
+ - description: Two redundant blocks with active one flagged
+const: u-boot,env-redundant-bool
+ - description: Two redundant blocks with active having higher counter
+const: u-boot,env-redundant-count
+
+ reg:
+maxItems: 1
+
+unevaluatedProperties: false
+
+examples:
+ - |
+partitions {
+compatible = "fixed-partitions";
+#address-cells = <1>;
+#size-cells = <1>;
+
+partition@0 {
+reg = <0x0 0x4>;
+label = "u-boot";
+read-only;
+};
+
+env: partition@4 {
+compatible = "u-boot,env";
+reg = <0x4 0x1>;
+label = "u-boot-env";
+};
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 66aa3a589f6a..55c56ce82856 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19905,6 +19905,11 @@ W: http://linuxtv.org
T: git git://linuxtv.org/media_tree.git
F: drivers/media/pci/tw686x/
+U-BOOT ENVIRONMENT VARIABLES
+M: Rafał Miłecki
+S: Maintained
+F: Documentation/devicetree/bindings/nvmem/u-boot,env.yaml
+
UACCE ACCELERATOR FRAMEWORK
M: Zhangfei Gao
M: Zhou Wang
--
2.34.1
[PATCH u-boot-marvell v2 2/2] arm: mvebu: turris_omnia: Reset the board immediately on DDR training failure
From: Marek Behún The state of the current DDR training code for Armada 38x is such that we cannot be sure it will always train successfully - although after the last change we were yet unable to find a board that failed DDR training, from experience in the last 2 years we know that it is possible. The experience also tells us that in many cases the board fails training only sometimes, and after a reset the training is successful. Enable the new option that makes the board reset itself on DDR training failure immediately. Until now we called hang() in such a case, which meant that the board was reset by the MCU after 120 seconds. Signed-off-by: Marek Behún --- configs/turris_omnia_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig index d6f70caeaf..010d69adcc 100644 --- a/configs/turris_omnia_defconfig +++ b/configs/turris_omnia_defconfig @@ -11,6 +11,7 @@ CONFIG_NR_DRAM_BANKS=2 CONFIG_SYS_MEMTEST_START=0x0080 CONFIG_SYS_MEMTEST_END=0x00ff CONFIG_TARGET_TURRIS_OMNIA=y +CONFIG_DDR_RESET_ON_TRAINING_FAILURE=y CONFIG_ENV_SIZE=0x1 CONFIG_ENV_OFFSET=0xF CONFIG_ENV_SECT_SIZE=0x1 -- 2.34.1
