[PATCH 1/1] efi_loader: check return value of part_get_info()

[Heinrich Schuchardt]

part_get_info() may return an error code. Check it.
Update function description of dp_part_node().

Addresses-Coverity-ID: 184067 ("Unchecked return value")
Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_device_path.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index 71923b1127..04ebb449ca 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -843,12 +843,17 @@ static unsigned dp_part_size(struct blk_desc *desc, int 
part)
  * @bufbuffer to which the device path is written
  * @desc   block device descriptor
  * @part   partition number, 0 identifies a block device
+ *
+ * Return: pointer to position after the node
  */
 static void *dp_part_node(void *buf, struct blk_desc *desc, int part)
 {
struct disk_partition info;
+   int ret;
 
-   part_get_info(desc, part, &info);
+   ret = part_get_info(desc, part, &info);
+   if (ret < 0)
+   return buf;
 
if (desc->part_type == PART_TYPE_ISO) {
struct efi_device_path_cdrom_path *cddp = buf;
-- 
2.39.2

Re: [RESEND PATCH v1 1/4] riscv: t-head: licheepi4a: initial support added

[Guo Ren]

On Fri, May 26, 2023 at 8:41 PM Yixun Lan  wrote:
>
> Add support for Sipeed's Lichee Pi 4A board which based on
> T-HEAD's TH1520 SoC, only minimal device tree and serial onsole are enabled,
> so it's capable of chain booting from T-HEAD's vendor u-boot.
>
> Reviewed-by: Wei Fu 
> Signed-off-by: Yixun Lan 
> ---
>  arch/riscv/Kconfig   |  5 
>  board/thead/th1520_lpi4a/Kconfig | 42 
>  board/thead/th1520_lpi4a/MAINTAINERS |  7 +
>  board/thead/th1520_lpi4a/Makefile|  5 
>  board/thead/th1520_lpi4a/board.c | 14 ++
>  include/configs/th1520_lpi4a.h   | 22 +++
>  6 files changed, 95 insertions(+)
>  create mode 100644 board/thead/th1520_lpi4a/Kconfig
>  create mode 100644 board/thead/th1520_lpi4a/MAINTAINERS
>  create mode 100644 board/thead/th1520_lpi4a/Makefile
>  create mode 100644 board/thead/th1520_lpi4a/board.c
>  create mode 100644 include/configs/th1520_lpi4a.h
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index f6ed05906a..419b6171a9 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -27,6 +27,10 @@ config TARGET_SIFIVE_UNMATCHED
>  config TARGET_STARFIVE_VISIONFIVE2
> bool "Support StarFive VisionFive2 Board"
>
> +config TARGET_TH1520_LPI4A
> +   bool "Support Sipeed's TH1520 Lichee PI 4A Board"
> +   select SYS_CACHE_SHIFT_6
> +
>  config TARGET_SIPEED_MAIX
> bool "Support Sipeed Maix Board"
> select SYS_CACHE_SHIFT_6
> @@ -66,6 +70,7 @@ source "board/emulation/qemu-riscv/Kconfig"
>  source "board/microchip/mpfs_icicle/Kconfig"
>  source "board/sifive/unleashed/Kconfig"
>  source "board/sifive/unmatched/Kconfig"
> +source "board/thead/th1520_lpi4a/Kconfig"
>  source "board/openpiton/riscv64/Kconfig"
>  source "board/sipeed/maix/Kconfig"
>  source "board/starfive/visionfive2/Kconfig"
> diff --git a/board/thead/th1520_lpi4a/Kconfig 
> b/board/thead/th1520_lpi4a/Kconfig
> new file mode 100644
> index 00..622246127c
> --- /dev/null
> +++ b/board/thead/th1520_lpi4a/Kconfig
> @@ -0,0 +1,42 @@
> +if TARGET_TH1520_LPI4A
> +
> +config ARCH_THEAD
> +   bool
> +   default y
> +
> +config SYS_BOARD
> +   default "th1520_lpi4a"
> +
> +config SYS_VENDOR
> +   default "thead"
> +
> +config SYS_CPU
> +   default "generic"
> +
> +config SYS_CONFIG_NAME
> +   default "th1520_lpi4a"
> +
> +config TEXT_BASE
> +   default 0x01b0 if SPL
> +   default 0x01c0 if !RISCV_SMODE
> +   default 0x01c0 if RISCV_SMODE
> +
> +config SPL_TEXT_BASE
> +   default 0x0800
> +
> +config SPL_OPENSBI_LOAD_ADDR
> +   default 0x8000
> +
> +config BOARD_SPECIFIC_OPTIONS
> +   def_bool y
> +   select ARCH_EARLY_INIT_R
> +   imply CPU
> +   imply CPU_RISCV
> +   imply RISCV_TIMER if RISCV_SMODE
> +   imply CMD_CPU
> +   imply SMP
> +   imply SUPPORT_OF_CONTROL
> +   imply OF_CONTROL
> +   imply OF_REAL
> +
> +endif
> diff --git a/board/thead/th1520_lpi4a/MAINTAINERS 
> b/board/thead/th1520_lpi4a/MAINTAINERS
> new file mode 100644
> index 00..36c7ab7cc3
> --- /dev/null
> +++ b/board/thead/th1520_lpi4a/MAINTAINERS
> @@ -0,0 +1,7 @@
> +Lichee PI 4A
> +M: Wei Fu 
> +M: Yixun Lan 
> +S: Maintained
> +F: board/thead/th1520_lpi4a/
> +F: configs/th1520_lpi4a_defconfig
> +F: doc/board/thead/lpi4a.rst
> diff --git a/board/thead/th1520_lpi4a/Makefile 
> b/board/thead/th1520_lpi4a/Makefile
> new file mode 100644
> index 00..9671b3bbb0
> --- /dev/null
> +++ b/board/thead/th1520_lpi4a/Makefile
> @@ -0,0 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright (c) 2023, Yixun Lan 
> +
> +obj-y += board.o
> diff --git a/board/thead/th1520_lpi4a/board.c 
> b/board/thead/th1520_lpi4a/board.c
> new file mode 100644
> index 00..378bab098b
> --- /dev/null
> +++ b/board/thead/th1520_lpi4a/board.c
> @@ -0,0 +1,14 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2023, Yixun Lan 
> + *
> + */
> +
> +#include 
> +
> +int board_init(void)
> +{
> +   enable_caches();
> +
> +   return 0;
> +}
> diff --git a/include/configs/th1520_lpi4a.h b/include/configs/th1520_lpi4a.h
> new file mode 100644
> index 00..87496a52c4
> --- /dev/null
> +++ b/include/configs/th1520_lpi4a.h
> @@ -0,0 +1,22 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (c) 2023 Yixun Lan 
> + *
> + */
> +
> +#ifndef __TH1520_LPI4A_H
> +#define __TH1520_LPI4A_H
> +
> +#include 
> +
> +#define CFG_SYS_SDRAM_BASE 0x
> +
> +#define UART_BASE  0xffe7014000
> +#define UART_REG_WIDTH  32
why couldn't we get it from dts? just like opensbi.

> +
> +/* Environment options */
> +
> +#define CFG_EXTRA_ENV_SETTINGS \
> +   "PS1=[LPi4A]# \0"
> +
> +#endif /* __TH1520_LPI4A_H */
> --
> 2.40.0
>


-- 
Best Regards
 Guo Ren

Re: [RESEND PATCH v1 2/4] riscv: dts: t-head: Add basic device tree for Sipeed Lichee PI 4A board

[Guo Ren]

Sorry, why we need dts here? If we put dts here, we could delete the
one in Linux.

We shouldn't put it with two places, that would be bad for maintanice.

On Fri, May 26, 2023 at 8:41 PM Yixun Lan  wrote:
>
> Only add basic support for CPU, PLIC UART and Timer.
>
> Reviewed-by: Wei Fu 
> Signed-off-by: Yixun Lan 
> ---
>  arch/riscv/dts/Makefile |   1 +
>  arch/riscv/dts/th1520-lichee-module-4a.dtsi |  34 ++
>  arch/riscv/dts/th1520-lichee-pi-4a.dts  |  32 ++
>  arch/riscv/dts/th1520.dtsi  | 435 
>  4 files changed, 502 insertions(+)
>  create mode 100644 arch/riscv/dts/th1520-lichee-module-4a.dtsi
>  create mode 100644 arch/riscv/dts/th1520-lichee-pi-4a.dts
>  create mode 100644 arch/riscv/dts/th1520.dtsi
>
> diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
> index 79a58694f5..72fd815a40 100644
> --- a/arch/riscv/dts/Makefile
> +++ b/arch/riscv/dts/Makefile
> @@ -9,6 +9,7 @@ dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) += 
> hifive-unmatched-a00.dtb
>  dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb
>  dtb-$(CONFIG_TARGET_STARFIVE_VISIONFIVE2) += 
> jh7110-starfive-visionfive-2-v1.3b.dtb
>  dtb-$(CONFIG_TARGET_STARFIVE_VISIONFIVE2) += 
> jh7110-starfive-visionfive-2-v1.2a.dtb
> +dtb-$(CONFIG_TARGET_TH1520_LPI4A) += th1520-lichee-pi-4a.dtb
>  include $(srctree)/scripts/Makefile.dts
>
>  targets += $(dtb-y)
> diff --git a/arch/riscv/dts/th1520-lichee-module-4a.dtsi 
> b/arch/riscv/dts/th1520-lichee-module-4a.dtsi
> new file mode 100644
> index 00..dc00e3dfa0
> --- /dev/null
> +++ b/arch/riscv/dts/th1520-lichee-module-4a.dtsi
> @@ -0,0 +1,34 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2023 Jisheng Zhang 
> + */
> +
> +/dts-v1/;
> +
> +#include "th1520.dtsi"
> +
> +/ {
> +   model = "Sipeed Lichee Module 4A";
> +   compatible = "sipeed,lichee-module-4a", "thead,th1520";
> +
> +   memory@0 {
> +   device_type = "memory";
> +   reg = <0x0 0x 0x2 0x>;
> +   };
> +};
> +
> +&osc {
> +   clock-frequency = <2400>;
> +};
> +
> +&osc_32k {
> +   clock-frequency = <32768>;
> +};
> +
> +&apb_clk {
> +   clock-frequency = <6250>;
> +};
> +
> +&uart_sclk {
> +   clock-frequency = <1>;
> +};
> diff --git a/arch/riscv/dts/th1520-lichee-pi-4a.dts 
> b/arch/riscv/dts/th1520-lichee-pi-4a.dts
> new file mode 100644
> index 00..a1248b2ee3
> --- /dev/null
> +++ b/arch/riscv/dts/th1520-lichee-pi-4a.dts
> @@ -0,0 +1,32 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2023 Jisheng Zhang 
> + */
> +
> +#include "th1520-lichee-module-4a.dtsi"
> +
> +/ {
> +   model = "Sipeed Lichee Pi 4A";
> +   compatible = "sipeed,lichee-pi-4a", "sipeed,lichee-module-4a", 
> "thead,th1520";
> +
> +   aliases {
> +   gpio0 = &gpio0;
> +   gpio1 = &gpio1;
> +   gpio2 = &gpio2;
> +   gpio3 = &gpio3;
> +   serial0 = &uart0;
> +   serial1 = &uart1;
> +   serial2 = &uart2;
> +   serial3 = &uart3;
> +   serial4 = &uart4;
> +   serial5 = &uart5;
> +   };
> +
> +   chosen {
> +   stdout-path = "serial0:115200n8";
> +   };
> +};
> +
> +&uart0 {
> +   status = "okay";
> +};
> diff --git a/arch/riscv/dts/th1520.dtsi b/arch/riscv/dts/th1520.dtsi
> new file mode 100644
> index 00..f62a62da6e
> --- /dev/null
> +++ b/arch/riscv/dts/th1520.dtsi
> @@ -0,0 +1,435 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2021 Alibaba Group Holding Limited.
> + * Copyright (C) 2023 Jisheng Zhang 
> + */
> +
> +#include 
> +
> +/ {
> +   compatible = "thead,th1520";
> +   #address-cells = <2>;
> +   #size-cells = <2>;
> +
> +   cpus: cpus {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   timebase-frequency = <300>;
> +
> +   c910_0: cpu@0 {
> +   compatible = "thead,c910", "riscv";
> +   device_type = "cpu";
> +   riscv,isa = "rv64imafdc";
> +   reg = <0>;
> +   i-cache-block-size = <64>;
> +   i-cache-size = <65536>;
> +   i-cache-sets = <512>;
> +   d-cache-block-size = <64>;
> +   d-cache-size = <65536>;
> +   d-cache-sets = <512>;
> +   next-level-cache = <&l2_cache>;
> +   mmu-type = "riscv,sv39";
> +
> +   cpu0_intc: interrupt-controller {
> +   compatible = "riscv,cpu-intc";
> +   interrupt-controller;
> +   #interrupt-cells = <1>;
> +   };
> +   };
> +
> +   c910_1: cpu@1 {
> +   compatible = 

Re: [RFC PATCH 10/17] clk: sunxi: Add support for the D1 CCU

[Sam Edwards]

Hey Andre,

On 5/26/23 16:07, Andre Przywara wrote:

So with "no success" you are referring to the patch below? Which is the
Linux patch ported to U-Boot? And does that mean that the Linux patch
works, but the U-Boot version doesn't?


Yes, the diff below is what I've been trying to use. It's not the Linux 
patch ported to U-Boot; I was trying to get it to work (wondering if 
there was something I was missing, like power control) when Maksim 
pointed out the Linux patch. I haven't tried the latter at all.


My "no success" is Linux stalling indefinitely at:
[0.123090] smp: Bringing up secondary CPUs ...


The PRCM is routinely not documented in the user manuals, IIUC
Allwinner provides separate documents for that (but not to us).
So far this was all reverse engineered from either BSP code or
some disassembly. Is there any indication in the BSP source code as to
how this is supposed to work? And maybe there is no separate power
control for the second core?


The user manual strongly suggests that power is enabled by default, so I 
may not need to touch PRCM after all. I also checked (and 
double-checked) the raw disassembly of my resulting `psci_cpu_on` and it 
does look like all of the correct registers are being hit.


I don't have any BSP source code suggesting anything otherwise. I do 
have an OP-TEE binary, which doesn't appear to try anything more than 
the kernel patch (and my current PSCI implementation) does.



And have you checked that the PSCI runtime code is correctly hooked up
in U-Boot? I have to check what's really needed, but the whole code
needs to be linked to secure SRAM, IIRC.


I'm about 80% sure the PSCI code is properly callable. I've toyed with 
the kernel a little bit to test this. I get a "bad mode" panic if U-Boot 
doesn't register the SMC vector, and PSCI_RET_NOT_SUPPORTED if I call 
unused function IDs, so I think U-Boot is able to get called and return 
just fine.


The OP-TEE binary also doesn't appear to try to relocate itself into any 
kind of particular RAM location. It just runs where it loads from DRAM. 
I take this to mean U-Boot's "in-situ" secure segment case is 
appropriate here, and no specific linking is needed.


The one thing I'm not very sure about at the moment is whether 
`psci_cpu_entry` is properly handling the newly-awakened second core. 
I'll keep debugging.



We don't need #ifdef's, you can use normal C "if" statements:


I'll try to follow that approach then.


This just requires to have all symbols defined all the time


Egh, gross, this means some code that shouldn't be used for a particular 
target can slip by the compiler's diagnostics unnoticed (such as when 
this happened with SUNXI_R_PIO_BASE). I wish there was a better way.



Sure. I actually removed most of the symbols there, as we don't need
them, but can surely add the ones you found for PSCI. Do you need
I2C in the SPL (looking at SUNXI_R_TWI_BASE)?


I'm not sure yet: my target does have an EEPROM on TWI2, which might 
eventually be used to store a board revision (and therefore which 
determines the FDT that the SPL should load), but I'm also considering 
overlays for other versions that are applied within main U-Boot.


But I can't fit much more in SPL anyway. The text section there is 
already up to 0x6ec0 (without SPI or NAND yet), and with third-party 
tooling assuming U-Boot at offset 0x8000, I can't very easily allocate 
more room to it. I might have to figure out what more to clear out here.


But anyway I only filled in that address because I came across the 
correct value in Allwinner's fork of U-Boot and noted it down before I 
forgot.


Cheers,
Sam

[PATCH 1/1] am65x_gp_evm: Support for ECC DDR with DMA priming

[Ben Roytburd]

>From e019ed98623c8c8388bef3082002d27d5ec9de40 Mon Sep 17 00:00:00 2001
From: broytburd 
Date: Fri, 26 May 2023 09:14:14 -0700
Subject: [PATCH 1/1] am65x_gp_evm: Support for ECC DDR with DMA priming

Add support for configuring DDR4 memory on AM65x_GP_EVM SR1.0 with
ECC. Add register writes and memory priming function for
DDR initialization. Priming done using dma_memcpy from MSMC SRAM, bugfix
required for k3 udma driver to prevent dereferencing a null pointer
within unprimed DDR space.

Signed-off-by: broytburd 
Cc: Tom Rini 
---
arch/arm/dts/k3-am654-base-board.dts |  5 +-
drivers/dma/ti/k3-udma.c |  9 +++-
drivers/ram/k3-am654-ddrss.c | 74 +++-
3 files changed, 81 insertions(+), 7 deletions(-)

diff --git a/arch/arm/dts/k3-am654-base-board.dts 
b/arch/arm/dts/k3-am654-base-board.dts
index cfbcebfa37..bd54c84359 100644
--- a/arch/arm/dts/k3-am654-base-board.dts
+++ b/arch/arm/dts/k3-am654-base-board.dts
@@ -20,9 +20,8 @@

   memory@8000 {
 device_type = "memory";
- /* 4G RAM */
- reg = <0x 0x8000 0x 
0x8000>,
-   <0x0008 0x8000 0x 
0x8000>;
+/* 2G RAM */
+reg = <0x 0x8000 0x 
0x8000>;
  };

   reserved-memory {
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 05c3a4311c..461162ab6c 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -1044,8 +1044,8 @@ static int udma_alloc_tchan_sci_req(struct udma_chan *uc)
static int udma_alloc_rchan_sci_req(struct udma_chan *uc)
{
  struct udma_dev *ud = uc->ud;
-  int fd_ring = k3_nav_ringacc_get_ring_id(uc->rflow->fd_ring);
-  int rx_ring = k3_nav_ringacc_get_ring_id(uc->rflow->r_ring);
+ int fd_ring = 0;
+ int rx_ring = 0;
  int tc_ring = k3_nav_ringacc_get_ring_id(uc->tchan->tc_ring);
  struct ti_sci_msg_rm_udmap_rx_ch_cfg req = { 0 };
  struct ti_sci_msg_rm_udmap_flow_cfg flow_req = { 0 };
@@ -1053,6 +1053,11 @@ static int udma_alloc_rchan_sci_req(struct udma_chan *uc)
  u32 mode;
  int ret;

+ if (!uc->rflow) {
+fd_ring = 
k3_nav_ringacc_get_ring_id(uc->rflow->fd_ring);
+rx_ring = 
k3_nav_ringacc_get_ring_id(uc->rflow->r_ring);
+ }
+
  if (uc->config.pkt_mode)
 mode = TI_SCI_RM_UDMAP_CHAN_TYPE_PKT_PBRR;
  else
diff --git a/drivers/ram/k3-am654-ddrss.c b/drivers/ram/k3-am654-ddrss.c
index b8338f84a3..6f28cb856f 100644
--- a/drivers/ram/k3-am654-ddrss.c
+++ b/drivers/ram/k3-am654-ddrss.c
@@ -9,6 +9,7 @@
#include 
#include 
#include 
+#include 
#include 
#include 
#include 
@@ -24,7 +25,20 @@ u32 wait_on_value(u32 read_bit_mask, u32 match_value, void 
*read_addr,
#define LDELAY 1

 /* DDRSS PHY configuration register fixed values */
-#define DDRSS_DDRPHY_RANKIDR_RANK0  0
+#define DDRSS_DDRPHY_RANKIDR_RANK0 0x
+#define DDRSS_DDRPHY_RANKIDR_RANK1 0x00010001
+
+/* Amount of DDR we wish to prime */
+#define DATA_BYTES 0x8000
+
+/* Amount of MSMC memory we will use to prime */
+#define MSMC_BYTES 0x2000
+
+/* Base address of DDR */
+static u32 *ddr_ptr = (uint32_t *)0x8000;
+
+/* Base address of MSMC */
+static u32 *msmc_ptr = (uint32_t *)0x6000;

 /**
  * struct am654_ddrss_desc - Description of ddrss integration.
@@ -49,6 +63,15 @@ struct am654_ddrss_desc {
  struct ddrss_params params;
};

+/**
+ * am654_prime_ecc(struct am654_ddrss_desc *ddrss) - Prime ECC
+ *
+ * Write a specified pattern to our entire DDR so that ECC timing
+ * parameters can be calibrated
+ *
+ */
+static int am654_prime_ecc(struct am654_ddrss_desc *ddrss);
+
static inline u32 ddrss_readl(void __iomem *addr, unsigned int offset)
{
  return readl(addr + offset);
@@ -172,6 +195,11 @@ static void am654_ddrss_ctrl_configuration(struct 
am654_ddrss_desc *ddrss)
  ddrss_ctl_writel(DDRSS_DDRCTL_ADDRMAP10, map->ddrctl_addrmap10);
  ddrss_ctl_writel(DDRSS_DDRCTL_ADDRMAP11, map->ddrctl_addrmap11);

+ ddrss_ctl_writel(DDRSS_DDRCTL_DQMAP0, map->ddrctl_dqmap0);
+ ddrss_ctl_writel(DDRSS_DDRCTL_DQMAP1, map->ddrctl_dqmap1);
+ ddrss_ctl_writel(DDRSS_DDRCTL_DQMAP4, map->ddrctl_dqmap4);
+ ddrss_ctl_writel(DDRSS_DDRCTL_DQMAP5, map->ddrctl_dqmap5);
+
  ddrss_ctl_writel(DDRSS_DDRCTL_ODTCFG, reg->ddrctl_odtcfg);
  ddrss_ctl_writel(DDRSS_DDRCTL_ODTMAP, reg->ddrctl_odtmap);

@@ -287,12 +315,14 @@ static void am654_ddrss_phy_configuration(struct 
am654_ddrss_desc *ddrss)
  ddrss_phy_writel(DDRSS_DDRPHY_DX1GCR4, cfg->ddrphy_dx1gcr4);
  ddrs

Re: [PATCH v5 1/3] Move bootorder and bootoption apis to lib

[Raymond Mao]

Hi Heinrich,

On Fri, 26 May 2023 at 03:18, Heinrich Schuchardt 
wrote:

> On 5/26/23 00:04, Raymond Mao wrote:
> > Rename and move bootorder and bootoption apis from cmd to lib
> > for re-use between eficonfig and bootmgr
> >
> > Signed-off-by: Raymond Mao 
>
> The commit message says that this patch does not change the code!
> But there are code changes, e.g.
>
> <   for (i = 0; i < count; i++)
> <   free(opt[i].lo);
> ---
>  >   for (i = 0; i < count; i++) {
>  >   if (opt[i].lo)
>  >   free(opt[i].lo);
>  >   }
>
> Please, provide a patch that only renames and moves the functions as
> indicated in the commit message. Please, avoid reformatting as that
> makes checking the diff hard.
>
> Besides, the 'if' that you introduced is superfluous as free() already
> checks for NULL.
>
[RM] It is a leftover line during debugging. I will clean it all up.

>
> > ---
> > Changes in v2
> > - Ignore EFI_NOT_FOUND returned from
> >efi_bootmgr_update_media_device_boot_option which means no boot
> >options scanned.
> > Changes in v3
> > - Split the patch into moving and renaming functions and
> >individual patches for each changed functionality
> > Changes in v4
> > - Revert the change of introducing a bool parameter when updating
> >the boot option. Use short-form of device path by default
> > Changes in v5
> > - Move function call of efi_bootmgr_update_media_device_boot_option()
> >from efi_init_variables() to efi_init_obj_list()
> > - Add warning log when a short-form device path doesn't exist
>
> This change history does not match changes in patch 1/3. Please, use a
> cover-letter to describe the series and overall changes.
>
[RM] I catched all changes of the complete patch set here. I will separate
them
for each patch respectively.

>
> >
> >   cmd/bootmenu.c   |   2 +-
> >   cmd/eficonfig.c  | 408 +--
> >   include/efi_config.h |   5 -
> >   include/efi_loader.h |  11 +
> >   lib/efi_loader/efi_bootmgr.c | 380 
> >   lib/efi_loader/efi_helper.c  |  25 +++
> >   6 files changed, 423 insertions(+), 408 deletions(-)
> >
> > diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
> > index 6baeedc69f..01daddca7b 100644
> > --- a/cmd/bootmenu.c
> > +++ b/cmd/bootmenu.c
> > @@ -351,7 +351,7 @@ static struct bootmenu_data *bootmenu_create(int
> delay)
> >* UEFI specification requires booting from removal media
> using
> >* a architecture-specific default image name such as
> BOOTAA64.EFI.
> >*/
> > - efi_ret = eficonfig_generate_media_device_boot_option();
> > + efi_ret = efi_bootmgr_update_media_device_boot_option();
> >   if (efi_ret != EFI_SUCCESS && efi_ret != EFI_NOT_FOUND)
> >   goto cleanup;
> >
> > diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
> > index 720f52b48b..82a80306f4 100644
> > --- a/cmd/eficonfig.c
> > +++ b/cmd/eficonfig.c
> > @@ -1134,43 +1134,6 @@ out:
> >   return ret;
> >   }
> >
> > -/**
> > - * eficonfig_get_unused_bootoption() - get unused "Boot" index
> > - *
> > - * @buf: pointer to the buffer to store boot option variable name
> > - * @buf_size:buffer size
> > - * @index:   pointer to store the index in the BootOrder variable
> > - * Return:   status code
> > - */
> > -efi_status_t eficonfig_get_unused_bootoption(u16 *buf, efi_uintn_t
> buf_size,
> > -  unsigned int *index)
> > -{
> > - u32 i;
> > - efi_status_t ret;
> > - efi_uintn_t size;
> > -
> > - if (buf_size < u16_strsize(u"Boot"))
> > - return EFI_BUFFER_TOO_SMALL;
> > -
> > - for (i = 0; i <= 0x; i++) {
> > - size = 0;
> > - efi_create_indexed_name(buf, buf_size, "Boot", i);
> > - ret = efi_get_variable_int(buf, &efi_global_variable_guid,
> > -NULL, &size, NULL, NULL);
> > - if (ret == EFI_BUFFER_TOO_SMALL)
> > - continue;
> > - else
> > - break;
> > - }
> > -
> > - if (i > 0x)
> > - return EFI_OUT_OF_RESOURCES;
> > -
> > - *index = i;
> > -
> > - return EFI_SUCCESS;
> > -}
> > -
> >   /**
> >* eficonfig_set_boot_option() - set boot option
> >*
> > @@ -1208,46 +1171,6 @@ static efi_status_t eficonfig_set_boot_option(u16
> *varname, struct efi_device_pa
> >   return ret;
> >   }
> >
> > -/**
> > - * eficonfig_append_bootorder() - append new boot option in BootOrder
> variable
> > - *
> > - * @index:   "Boot" index to append to BootOrder variable
> > - * Return:   status code
> > - */
> > -efi_status_t eficonfig_append_bootorder(u16 index)
> > -{
> > - u16 *bootorder;
> > - efi_status_t ret;
> > - u16 *new_bootorder = NULL;

Re: [RFC PATCH 10/17] clk: sunxi: Add support for the D1 CCU

[Andre Przywara]

On Fri, 26 May 2023 14:22:29 -0600
Sam Edwards  wrote:

Hi Sam,

> On 5/26/23 13:27, Maksim Kiselev wrote:
> > 
> > There is a Linux patch that allows to bring up the second core.
> > https://github.com/szemzoa/awboot/blob/6ea4ae4ad7a558ad952fefee1942e260aea1a69f/linux/second_core_support_in_platsmp.patch#L10
> > 
> > I think this could be useful for adding PSCI support for T113.  
> 
> I'm a little surprised that apparently all that is necessary is to set 
> the entry point and deassert reset. I've been trying essentially that so 
> far with no success (entirely possible I made a mistake somewhere). 

So with "no success" you are referring to the patch below? Which is the
Linux patch ported to U-Boot? And does that mean that the Linux patch
works, but the U-Boot version doesn't?

> Perhaps this patch assumes that power to the core is enabled before 
> kernel boot? I haven't yet figured out what in the PRCM I need to poke 
> to get power to the core, and the PRCM for this chip is not well-documented.

The PRCM is routinely not documented in the user manuals, IIUC
Allwinner provides separate documents for that (but not to us).
So far this was all reverse engineered from either BSP code or
some disassembly. Is there any indication in the BSP source code as to
how this is supposed to work? And maybe there is no separate power
control for the second core?

And have you checked that the PSCI runtime code is correctly hooked up
in U-Boot? I have to check what's really needed, but the whole code
needs to be linked to secure SRAM, IIRC.

> On 5/26/23 04:50, Andre Przywara wrote:
>  > I checked the manuals, and it seems the required bits are documented,
>  > but IIRC they differ from the other (much older) 32-bit parts. So it
>  > would require some refactoring of the existing sunxi PSCI code to
>  > accommodate the T113.  
> 
> Yeah, I decided to factor out the register-manipulating bits to a 
> handful of sunxi_cpu_set_* functions, which can be switched out to suit 
> the specific SoC in use. psci.c is growing way too many #ifdef branches, 
> so I might refactor this yet again to the "weak symbols with strong 
> overrides in e.g. psci-r528.c" pattern, unless you find that pattern 
> particularly distasteful.

We don't need #ifdef's, you can use normal C "if" statements:

static void __secure sunxi_set_entry_address(void *entry)
{
if (IS_ENABLED(CONFIG_MACH_SUN8I_R528))
writel((u32)entry,
SUNXI_R_CPUCFG_BASE + SUN8I_R528_SOFT_ENTRY);
else 
writel((u32)entry,
SUNXI_SRAMC_BASE + SUN8I_R40_SRAMC_SOFT_ENTRY_REG0);
}

"Dead code elimination" in modern compilers will remove everything
that's not needed, if this can be figured out at compile time (try it!).

This just requires to have all symbols defined all the time, but there
is no reason to protect #define's with #ifdef's either, as it doesn't
hurt to have unused preprocessor symbols. Or you define shared names
(SUNXI_ENTRY_ADDRESS_BASE), depending on Kconfig symbols.
arch/arm/mach-sunxi/spl_spi_sunxi.c makes use of those techniques
extensively, have a look there for inspiration (like static functions
to return base addresses: spi0_base_address(), this will be optimised
away completely).

> I have my WIP diff below. Before inclusion, I'll split it into multiple 
> patches (refactoring -> adding R528 support) but it's definitely not 
> ready for that yet. However if you could, it would help if you checked 
> my changes to cpu_sunxi_ncat2.h and squashed them into your own series 
> if they look good to you.

Sure. I actually removed most of the symbols there, as we don't need
them, but can surely add the ones you found for PSCI. Do you need
I2C in the SPL (looking at SUNXI_R_TWI_BASE)?

Thanks,
Andre

> ---
> diff --git a/arch/arm/cpu/armv7/sunxi/psci.c 
> b/arch/arm/cpu/armv7/sunxi/psci.c
> index e1d3638b5c..02c5c56c86 100644
> --- a/arch/arm/cpu/armv7/sunxi/psci.c
> +++ b/arch/arm/cpu/armv7/sunxi/psci.c
> @@ -38,6 +38,8 @@
>   #define SUN8I_R40_PWR_CLAMP(cpu)(0x120 + (cpu) * 0x4)
>   #define SUN8I_R40_SRAMC_SOFT_ENTRY_REG0 (0xbc)
> 
> +#define SUN8I_R528_SOFT_ENTRY(0x1c8)
> +
>   static void __secure cp15_write_cntp_tval(u32 tval)
>   {
>   asm volatile ("mcr p15, 0, %0, c14, c2, 0" : : "r" (tval));
> @@ -125,6 +127,13 @@ static void __secure sunxi_set_entry_address(void 
> *entry)
>   writel((u32)entry,
>  SUNXI_SRAMC_BASE + SUN8I_R40_SRAMC_SOFT_ENTRY_REG0);
>   }
> +#elif defined CONFIG_MACH_SUN8I_R528
> +/* secondary core entry address is programmed differently on R528 */
> +static void __secure sunxi_set_entry_address(void *entry)
> +{
> + writel((u32)entry,
> +SUNXI_R_CPUCFG_BASE + SUN8I_R528_SOFT_ENTRY);
> +}
>   #else
>   static void __secure sunxi_set_entry_address(void *entry)
>   {
> @@ -155,6 +164,10 @@ static void __secure sunxi_cpu_set_power(int cpu, 
> bool on)
>   

[PATCH v6 3/3] Load option with short device path for boot vars

[Raymond Mao]

The boot variables automatically generated for removable medias
should be with short form of device path without device nodes.
This is a requirement for the case that a removable media is
plugged into a different port but is still able to work with the
existing boot variables.

Signed-off-by: Raymond Mao 
---
Changes in v2
- Ignore EFI_NOT_FOUND returned from
  efi_bootmgr_update_media_device_boot_option which means no boot
  options scanned.
Changes in v3
- Split the patch into moving and renaming functions and
  individual patches for each changed functionality
Changes in v4
- Revert v2 change of introducing a bool parameter when updating
  the boot option. Use short-form of device path by default
Changes in v5
- Add warning log when a short-form device path doesn't exist
Changes in v6
- Revert v5 change and use original device path if short-form does
  not exist

 lib/efi_loader/efi_bootmgr.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index 48cd5f0636..7d0b4f3f90 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -371,6 +371,7 @@ static efi_status_t 
efi_bootmgr_enumerate_boot_option(struct eficonfig_media_boo
struct efi_load_option lo;
char buf[BOOTMENU_DEVICE_NAME_MAX];
struct efi_device_path *device_path;
+   struct efi_device_path *short_dp;
 
ret = efi_search_protocol(volume_handles[i], 
&efi_guid_device_path, &handler);
if (ret != EFI_SUCCESS)
@@ -387,6 +388,11 @@ static efi_status_t 
efi_bootmgr_enumerate_boot_option(struct eficonfig_media_boo
p = dev_name;
utf8_utf16_strncpy(&p, buf, strlen(buf));
 
+   /* prefer to short form device path */
+   short_dp = efi_dp_shorten(device_path);
+   if (short_dp)
+   device_path = short_dp;
+
lo.label = dev_name;
lo.attributes = LOAD_OPTION_ACTIVE;
lo.file_path = device_path;
-- 
2.25.1

[PATCH v6 2/3] Boot var automatic management for removable medias

[Raymond Mao]

Changes for complying to EFI spec §3.5.1.1
'Removable Media Boot Behavior'.
Boot variables can be automatically generated during a removable
media is probed. At the same time, unused boot variables will be
detected and removed.

Signed-off-by: Raymond Mao 
---
Changes in v3
- Split the patch into moving and renaming functions and
  individual patches for each changed functionality
Changes in v5
- Move function call of efi_bootmgr_update_media_device_boot_option()
  from efi_init_variables() to efi_init_obj_list()
Changes in v6
- Revert unrelated changes

 lib/efi_loader/efi_disk.c  | 7 +++
 lib/efi_loader/efi_setup.c | 5 +
 2 files changed, 12 insertions(+)

diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index d2256713a8..ca5f07f2ec 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -687,6 +687,13 @@ int efi_disk_probe(void *ctx, struct event *event)
return -1;
}
 
+   /* only do the boot option management when UEFI sub-system is 
initialized */
+   if (efi_obj_list_initialized == EFI_SUCCESS) {
+   ret = efi_bootmgr_update_media_device_boot_option();
+   if (ret != EFI_SUCCESS && ret != EFI_NOT_FOUND)
+   return -1;
+   }
+
return 0;
 }
 
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index 58d4e13402..4686374995 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -245,6 +245,11 @@ efi_status_t efi_init_obj_list(void)
if (ret != EFI_SUCCESS)
goto out;
 
+   /* update boot option after variable service initialized */
+   ret = efi_bootmgr_update_media_device_boot_option();
+   if (ret != EFI_SUCCESS && ret != EFI_NOT_FOUND)
+   goto out;
+
/* Define supported languages */
ret = efi_init_platform_lang();
if (ret != EFI_SUCCESS)
-- 
2.25.1

[PATCH v6 1/3] Move bootorder and bootoption apis to lib

[Raymond Mao]

Rename and move bootorder and bootoption apis from cmd to lib
for re-use between eficonfig and bootmgr

Signed-off-by: Raymond Mao 
---
Changes in v3
- Split the patch into moving and renaming functions and
  individual patches for each changed functionality
Changes in v6
- Revert v3 changes in function
  efi_bootmgr_update_media_device_boot_option and
  efi_bootmgr_delete_invalid_boot_option

 cmd/bootmenu.c   |   2 +-
 cmd/eficonfig.c  | 408 +--
 include/efi_config.h |   5 -
 include/efi_loader.h |  11 +
 lib/efi_loader/efi_bootmgr.c | 375 
 lib/efi_loader/efi_helper.c  |  25 +++
 6 files changed, 418 insertions(+), 408 deletions(-)

diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
index 6baeedc69f..01daddca7b 100644
--- a/cmd/bootmenu.c
+++ b/cmd/bootmenu.c
@@ -351,7 +351,7 @@ static struct bootmenu_data *bootmenu_create(int delay)
 * UEFI specification requires booting from removal media using
 * a architecture-specific default image name such as 
BOOTAA64.EFI.
 */
-   efi_ret = eficonfig_generate_media_device_boot_option();
+   efi_ret = efi_bootmgr_update_media_device_boot_option();
if (efi_ret != EFI_SUCCESS && efi_ret != EFI_NOT_FOUND)
goto cleanup;
 
diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
index 720f52b48b..82a80306f4 100644
--- a/cmd/eficonfig.c
+++ b/cmd/eficonfig.c
@@ -1134,43 +1134,6 @@ out:
return ret;
 }
 
-/**
- * eficonfig_get_unused_bootoption() - get unused "Boot" index
- *
- * @buf:   pointer to the buffer to store boot option variable name
- * @buf_size:  buffer size
- * @index: pointer to store the index in the BootOrder variable
- * Return: status code
- */
-efi_status_t eficonfig_get_unused_bootoption(u16 *buf, efi_uintn_t buf_size,
-unsigned int *index)
-{
-   u32 i;
-   efi_status_t ret;
-   efi_uintn_t size;
-
-   if (buf_size < u16_strsize(u"Boot"))
-   return EFI_BUFFER_TOO_SMALL;
-
-   for (i = 0; i <= 0x; i++) {
-   size = 0;
-   efi_create_indexed_name(buf, buf_size, "Boot", i);
-   ret = efi_get_variable_int(buf, &efi_global_variable_guid,
-  NULL, &size, NULL, NULL);
-   if (ret == EFI_BUFFER_TOO_SMALL)
-   continue;
-   else
-   break;
-   }
-
-   if (i > 0x)
-   return EFI_OUT_OF_RESOURCES;
-
-   *index = i;
-
-   return EFI_SUCCESS;
-}
-
 /**
  * eficonfig_set_boot_option() - set boot option
  *
@@ -1208,46 +1171,6 @@ static efi_status_t eficonfig_set_boot_option(u16 
*varname, struct efi_device_pa
return ret;
 }
 
-/**
- * eficonfig_append_bootorder() - append new boot option in BootOrder variable
- *
- * @index: "Boot" index to append to BootOrder variable
- * Return: status code
- */
-efi_status_t eficonfig_append_bootorder(u16 index)
-{
-   u16 *bootorder;
-   efi_status_t ret;
-   u16 *new_bootorder = NULL;
-   efi_uintn_t last, size, new_size;
-
-   /* append new boot option */
-   bootorder = efi_get_var(u"BootOrder", &efi_global_variable_guid, &size);
-   last = size / sizeof(u16);
-   new_size = size + sizeof(u16);
-   new_bootorder = calloc(1, new_size);
-   if (!new_bootorder) {
-   ret = EFI_OUT_OF_RESOURCES;
-   goto out;
-   }
-   memcpy(new_bootorder, bootorder, size);
-   new_bootorder[last] = index;
-
-   ret = efi_set_variable_int(u"BootOrder", &efi_global_variable_guid,
-  EFI_VARIABLE_NON_VOLATILE |
-  EFI_VARIABLE_BOOTSERVICE_ACCESS |
-  EFI_VARIABLE_RUNTIME_ACCESS,
-  new_size, new_bootorder, false);
-   if (ret != EFI_SUCCESS)
-   goto out;
-
-out:
-   free(bootorder);
-   free(new_bootorder);
-
-   return ret;
-}
-
 /**
  * create_boot_option_entry() - create boot option entry
  *
@@ -1619,7 +1542,7 @@ static efi_status_t 
eficonfig_process_add_boot_option(void *data)
if (!bo)
return EFI_OUT_OF_RESOURCES;
 
-   ret = eficonfig_get_unused_bootoption(varname, sizeof(varname), 
&bo->boot_index);
+   ret = efi_bootmgr_get_unused_bootoption(varname, sizeof(varname), 
&bo->boot_index);
if (ret != EFI_SUCCESS)
return ret;
 
@@ -1627,7 +1550,7 @@ static efi_status_t 
eficonfig_process_add_boot_option(void *data)
if (ret != EFI_SUCCESS)
goto out;
 
-   ret = eficonfig_append_bootorder((u16)bo->boot_index);
+   ret = efi_bootmgr_append_bootorder((u16)bo->boot_index);
if (ret != EFI_SUCCESS)
goto out;
 
@@ 

[PATCH v6 0/3] Boot variables management for removable media

[Raymond Mao]

Major changes:
1.Rename and move bootorder and bootoption apis from cmd to lib
  for re-use between eficonfig and bootmgr
2.Changes for complying to EFI spec §3.5.1.1
  'Removable Media Boot Behavior'.
  Boot variables can be automatically generated during a removable
  media is probed. At the same time, unused boot variables will be
  detected and removed.
3.The boot variables automatically generated for removable medias
  should be with short form of device path without device nodes.
  This is a requirement for the case that a removable media is
  plugged into a different port but is still able to work with the
  existing boot variables.

Raymond Mao (3):
  Move bootorder and bootoption apis to lib
  Boot var automatic management for removable medias
  Load option with short device path for boot vars

 cmd/bootmenu.c   |   2 +-
 cmd/eficonfig.c  | 408 +--
 include/efi_config.h |   5 -
 include/efi_loader.h |  11 +
 lib/efi_loader/efi_bootmgr.c | 381 
 lib/efi_loader/efi_disk.c|   7 +
 lib/efi_loader/efi_helper.c  |  25 +++
 lib/efi_loader/efi_setup.c   |   5 +
 8 files changed, 436 insertions(+), 408 deletions(-)

-- 
2.25.1

Re: [RFC PATCH 10/17] clk: sunxi: Add support for the D1 CCU

[Sam Edwards]

Hi folks,

On 5/26/23 13:27, Maksim Kiselev wrote:


There is a Linux patch that allows to bring up the second core.
https://github.com/szemzoa/awboot/blob/6ea4ae4ad7a558ad952fefee1942e260aea1a69f/linux/second_core_support_in_platsmp.patch#L10

I think this could be useful for adding PSCI support for T113.


I'm a little surprised that apparently all that is necessary is to set 
the entry point and deassert reset. I've been trying essentially that so 
far with no success (entirely possible I made a mistake somewhere). 
Perhaps this patch assumes that power to the core is enabled before 
kernel boot? I haven't yet figured out what in the PRCM I need to poke 
to get power to the core, and the PRCM for this chip is not well-documented.


On 5/26/23 04:50, Andre Przywara wrote:
> I checked the manuals, and it seems the required bits are documented,
> but IIRC they differ from the other (much older) 32-bit parts. So it
> would require some refactoring of the existing sunxi PSCI code to
> accommodate the T113.

Yeah, I decided to factor out the register-manipulating bits to a 
handful of sunxi_cpu_set_* functions, which can be switched out to suit 
the specific SoC in use. psci.c is growing way too many #ifdef branches, 
so I might refactor this yet again to the "weak symbols with strong 
overrides in e.g. psci-r528.c" pattern, unless you find that pattern 
particularly distasteful.


I have my WIP diff below. Before inclusion, I'll split it into multiple 
patches (refactoring -> adding R528 support) but it's definitely not 
ready for that yet. However if you could, it would help if you checked 
my changes to cpu_sunxi_ncat2.h and squashed them into your own series 
if they look good to you.


Cheers,
Sam

---
diff --git a/arch/arm/cpu/armv7/sunxi/psci.c 
b/arch/arm/cpu/armv7/sunxi/psci.c

index e1d3638b5c..02c5c56c86 100644
--- a/arch/arm/cpu/armv7/sunxi/psci.c
+++ b/arch/arm/cpu/armv7/sunxi/psci.c
@@ -38,6 +38,8 @@
 #define SUN8I_R40_PWR_CLAMP(cpu)   (0x120 + (cpu) * 0x4)
 #define SUN8I_R40_SRAMC_SOFT_ENTRY_REG0(0xbc)

+#define SUN8I_R528_SOFT_ENTRY  (0x1c8)
+
 static void __secure cp15_write_cntp_tval(u32 tval)
 {
asm volatile ("mcr p15, 0, %0, c14, c2, 0" : : "r" (tval));
@@ -125,6 +127,13 @@ static void __secure sunxi_set_entry_address(void 
*entry)

writel((u32)entry,
   SUNXI_SRAMC_BASE + SUN8I_R40_SRAMC_SOFT_ENTRY_REG0);
 }
+#elif defined CONFIG_MACH_SUN8I_R528
+/* secondary core entry address is programmed differently on R528 */
+static void __secure sunxi_set_entry_address(void *entry)
+{
+   writel((u32)entry,
+  SUNXI_R_CPUCFG_BASE + SUN8I_R528_SOFT_ENTRY);
+}
 #else
 static void __secure sunxi_set_entry_address(void *entry)
 {
@@ -155,6 +164,10 @@ static void __secure sunxi_cpu_set_power(int cpu, 
bool on)

   (void *)cpucfg + SUN8I_R40_PWROFF,
   on, cpu);
 }
+#elif defined CONFIG_MACH_SUN8I_R528
+static void __secure sunxi_cpu_set_power(int __always_unused cpu, bool 
__always_unused on)

+{
+}
 #else /* ! CONFIG_MACH_SUN7I && ! CONFIG_MACH_SUN8I_R40 */
 static void __secure sunxi_cpu_set_power(int cpu, bool on)
 {
@@ -166,30 +179,91 @@ static void __secure sunxi_cpu_set_power(int cpu, 
bool on)

 }
 #endif /* CONFIG_MACH_SUN7I */

-void __secure sunxi_cpu_power_off(u32 cpuid)
+#ifdef CONFIG_MACH_SUN8I_R528
+#define C0_RST_CTRL0x
+#define C0_CTRL_REG0   0x0010
+#define C0_CPU_STATUS  0x0080
+
+#define C0_BIT_WFI 16
+
+static void __secure sunxi_cpu_set_reset(int cpu, bool active)
+{
+   if (active)
+   clrbits_le32(SUNXI_CPUX_BASE + C0_RST_CTRL, BIT(cpu));
+   else
+   setbits_le32(SUNXI_CPUX_BASE + C0_RST_CTRL, BIT(cpu));
+}
+
+static void __secure sunxi_cpu_set_locking(int cpu, bool lock)
+{
+   /* TODO: I don't know what this is or how to do it */
+}
+
+static bool __secure sunxi_cpu_poll_wfi(int cpu)
+{
+   return !!(readl(SUNXI_CPUX_BASE + C0_CPU_STATUS) & BIT(C0_BIT_WFI + 
cpu));
+}
+
+static void __secure sunxi_cpu_invalidate_cache(int cpu)
+{
+   clrbits_le32(SUNXI_CPUX_BASE + C0_CTRL_REG0, BIT(cpu));
+}
+#else /* ! CONFIG_MACH_SUN8I_R528 */
+static void __secure sunxi_cpu_set_reset(int cpu, bool active)
+{
+   struct sunxi_cpucfg_reg *cpucfg =
+   (struct sunxi_cpucfg_reg *)SUNXI_CPUCFG_BASE;
+
+   writel(active ? 0b00 : 0b11, &cpucfg->cpu[cpu].rst);
+}
+
+static void __secure sunxi_cpu_set_locking(int cpu, bool lock)
 {
struct sunxi_cpucfg_reg *cpucfg =
(struct sunxi_cpucfg_reg *)SUNXI_CPUCFG_BASE;
+
+   if (lock)
+   clrbits_le32(&cpucfg->dbg_ctrl1, BIT(cpu));
+   else
+   setbits_le32(&cpucfg->dbg_ctrl1, BIT(cpu));
+}
+
+static bool __secure sunxi_cpu_poll_wfi(int cpu)
+{
+   struct sunxi_cpucfg_reg *cpucfg =
+   (struct sunxi_cpucfg_reg *)SUNXI_CPUCFG_BASE;
+
+   return !!(readl(&cpucfg->cpu[cpu].statu

Re: [RFC PATCH 10/17] clk: sunxi: Add support for the D1 CCU

[Maksim Kiselev]

Hi Sam, Andre,

On Thu, 25 May 2023 18:34:45 -0600 Sam Edwards  wrote:


PS: Do you have any plans for PSCI support, so we can get the second
core up too? I'd like to patch that in and include it in your series
once my available time permits. Just thought I'd check that you/someone
wasn't working on it already. :)
Let me join the PSCI discussion. This is not news, but maybe someone 
else didn't know it :)


There is a Linux patch that allows to bring up the second core.
https://github.com/szemzoa/awboot/blob/6ea4ae4ad7a558ad952fefee1942e260aea1a69f/linux/second_core_support_in_platsmp.patch#L10

I think this could be useful for adding PSCI support for T113.

On 26.05.2023 13:50, Andre Przywara wrote:

I checked the manuals, and it seems the required bits are documented,
but IIRC they differ from the other (much older) 32-bit parts. So it
would require some refactoring of the existing sunxi PSCI code to
accommodate the T113.
For some reason, these registers 0x070005C0, 0x070005C4, 0x070005C8 do 
not have a detailed description in the user manual.

Only there are some notes in the paragraph '3.4.2.3 NON_CPU0 Boot Process' .

Re: [PATCH v1] common/memsize.c: Fix get_ram_size() when cache is enabled

[Tom Rini]

On Thu, May 25, 2023 at 03:01:13PM +0200, Francesco Dolcini wrote:

> From: Emanuele Ghidoli 
> 
> Ensure that every write is flushed to memory and afterward reads are
> from memory.
> Since the algorithm rely on the fact that accessing to not existent
> memory lead to write at addr / 2 without this modification accesses
> to aliased (not physically present) addresses are cached and
> wrong size is returned.
> 
> This was discovered while working on a TI AM625 based board
> where cache is normally enabled, see commit c02712a74849 ("arm: mach-k3: 
> Enable dcache in SPL").
> 
> Signed-off-by: Emanuele Ghidoli 
> Signed-off-by: Francesco Dolcini 
> ---
>  common/memsize.c | 14 ++
>  1 file changed, 14 insertions(+)

Ah, interesting.  Have you put this through a full CI loop via Azure
for example, since this is common code?  That's my real concern here,
thanks.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v5 3/3] Load option with short device path for boot vars

[Raymond Mao]

Hi Heinrich,

Will keep the device path as-is if no short-term returns in v6 patch

On Fri, 26 May 2023 at 03:14, Heinrich Schuchardt 
wrote:

> On 5/26/23 00:04, Raymond Mao wrote:
> > The boot variables automatically generated for removable medias
> > should be with short form of device path without device nodes.
> > This is a requirement for the case that a removable media is
> > plugged into a different port but is still able to work with the
> > existing boot variables.
> >
> > Signed-off-by: Raymond Mao 
> > ---
> > Changes in v2
> > - Ignore EFI_NOT_FOUND returned from
> >efi_bootmgr_update_media_device_boot_option which means no boot
> >options scanned.
> > Changes in v3
> > - Split the patch into moving and renaming functions and
> >individual patches for each changed functionality
> > Changes in v4
> > - Revert the change of introducing a bool parameter when updating
> >the boot option. Use short-form of device path by default
> > Changes in v5
> > - Move function call of efi_bootmgr_update_media_device_boot_option()
> >from efi_init_variables() to efi_init_obj_list()
> > - Add warning log when a short-form device path doesn't exist
> >
> >   lib/efi_loader/efi_bootmgr.c | 7 +++
> >   1 file changed, 7 insertions(+)
> >
> > diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> > index c329428973..67e833141f 100644
> > --- a/lib/efi_loader/efi_bootmgr.c
> > +++ b/lib/efi_loader/efi_bootmgr.c
> > @@ -387,6 +387,13 @@ static efi_status_t
> efi_bootmgr_enumerate_boot_option(struct eficonfig_media_boo
> >   p = dev_name;
> >   utf8_utf16_strncpy(&p, buf, strlen(buf));
> >
> > + /* use short form device path */
> > + device_path = efi_dp_shorten(device_path);
> > + if (!device_path) {
> > + log_warning("No short-form device path for device
> %s, skip it\n", buf);
> > + continue;
>
> efi_dp_shorten() returns NULL if the device-path contains neither of
> - a USB WWI node
> - a hard drive node, HD()
> - a file path node
>
> Why should we skip a device with a simple file protocol here if it does
> not contain one of the above nodes?
>
> The warning makes no sense at all.
>
> Best regards
>
> Heinrich
>
> > + }
> > +
> >   lo.label = dev_name;
> >   lo.attributes = LOAD_OPTION_ACTIVE;
> >   lo.file_path = device_path;
>
>

Re: [PATCH v5 2/3] Boot var automatic management for removable medias

[Raymond Mao]

Hi Heinrich,

On Fri, 26 May 2023 at 03:17, Heinrich Schuchardt 
wrote:

> On 5/26/23 00:04, Raymond Mao wrote:
> > Changes for complying to EFI spec §3.5.1.1
> > 'Removable Media Boot Behavior'.
> > Boot variables can be automatically generated during a removable
> > media is probed. At the same time, unused boot variables will be
> > detected and removed.
> >
> > Signed-off-by: Raymond Mao 
> > ---
> > Changes in v2
> > - Ignore EFI_NOT_FOUND returned from
> >efi_bootmgr_update_media_device_boot_option which means no boot
> >options scanned.
> > Changes in v3
> > - Split the patch into moving and renaming functions and
> >individual patches for each changed functionality
> > Changes in v4
> > - Revert the change of introducing a bool parameter when updating
> >the boot option. Use short-form of device path by default
> > Changes in v5
> > - Move function call of efi_bootmgr_update_media_device_boot_option()
> >from efi_init_variables() to efi_init_obj_list()
> > - Add warning log when a short-form device path doesn't exist
>
> This change history does not reflect this patch. Please, describe
> overall changes in the cover-letter and individual changes in the
> respective patch.
>
[RM] I catched all changes of the complete patch set here. I will separate
them
for each patch respectively.

>
> >
> >   lib/efi_loader/efi_disk.c | 7 +++
> >   lib/efi_loader/efi_setup.c| 5 +
> >   lib/efi_loader/efi_variable.c | 1 -
> >   3 files changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> > index d2256713a8..ca5f07f2ec 100644
> > --- a/lib/efi_loader/efi_disk.c
> > +++ b/lib/efi_loader/efi_disk.c
> > @@ -687,6 +687,13 @@ int efi_disk_probe(void *ctx, struct event *event)
> >   return -1;
> >   }
> >
> > + /* only do the boot option management when UEFI sub-system is
> initialized */
> > + if (efi_obj_list_initialized == EFI_SUCCESS) {
> > + ret = efi_bootmgr_update_media_device_boot_option();
> > + if (ret != EFI_SUCCESS && ret != EFI_NOT_FOUND)
> > + return -1;
> > + }
> > +
> >   return 0;
> >   }
> >
> > diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
> > index 58d4e13402..4686374995 100644
> > --- a/lib/efi_loader/efi_setup.c
> > +++ b/lib/efi_loader/efi_setup.c
> > @@ -245,6 +245,11 @@ efi_status_t efi_init_obj_list(void)
> >   if (ret != EFI_SUCCESS)
> >   goto out;
> >
> > + /* update boot option after variable service initialized */
> > + ret = efi_bootmgr_update_media_device_boot_option();
> > + if (ret != EFI_SUCCESS && ret != EFI_NOT_FOUND)
> > + goto out;
> > +
> >   /* Define supported languages */
> >   ret = efi_init_platform_lang();
> >   if (ret != EFI_SUCCESS)
> > diff --git a/lib/efi_loader/efi_variable.c
> b/lib/efi_loader/efi_variable.c
> > index be95ed44e6..1529fffd1d 100644
> > --- a/lib/efi_loader/efi_variable.c
> > +++ b/lib/efi_loader/efi_variable.c
> > @@ -476,6 +476,5 @@ efi_status_t efi_init_variables(void)
> >   log_err("Invalid EFI variable seed\n");
> >   }
> >
> > -
>
> Please, avoid unrelated changes.
>
[RM] Will revert this line change.

>
> Best regards
>
> Heinrich
>
> >   return efi_init_secure_state();
> >   }
>
>

Re: [PATCH v4 1/3] Move bootorder and bootoption apis to lib

[Raymond Mao]

Hi Heinrich,

On Fri, 26 May 2023 at 03:07, Heinrich Schuchardt 
wrote:

> On 5/23/23 21:18, Raymond Mao wrote:
> > Rename and move bootorder and bootoption apis from cmd to lib
> > for re-use between eficonfig and bootmgr
> >
> > Signed-off-by: Raymond Mao 
>
> The commit message says that this patch does not change the code!
> But there are code changes, e.g.
>
> <   for (i = 0; i < count; i++)
> <   free(opt[i].lo);
> ---
>  >   for (i = 0; i < count; i++) {
>  >   if (opt[i].lo)
>  >   free(opt[i].lo);
>  >   }
>
> Please, provide a patch that only renames and moves the functions as
> indicated in the commit message. Please, avoid reformatting as that
> makes checking the diff hard.
>
> Besides, the 'if' that you introduced is superfluous as free() already
> checks for NULL.
>
[RM] It is a leftover line during debugging. I will clean it all up.

>
> > ---
> > Changes in v2
> > - Ignore EFI_NOT_FOUND returned from
> >efi_bootmgr_update_media_device_boot_option which means no boot
> >options scanned.
> > Changes in v3
> > - Split the patch into moving and renaming functions and
> >individual patches for each changed functionality
> > Changes in v4
> > - Revert the change of introducing a bool parameter when updating
> >the boot option. Use short-form of device path by default
>
> Is this really a change in this patch?
>
> Using a cover-letter for the overall description would be helpful for
> future submissions.
>
[RM] I catched all changes of the complete patch set here. I will separate
them
for each patch respectively.

>
>  git format-patch --cover-letter
>
> Another comment below.
>
> >
> >   cmd/bootmenu.c   |   2 +-
> >   cmd/eficonfig.c  | 408 +--
> >   include/efi_config.h |   5 -
> >   include/efi_loader.h |  11 +
> >   lib/efi_loader/efi_bootmgr.c | 380 
> >   lib/efi_loader/efi_helper.c  |  25 +++
> >   6 files changed, 423 insertions(+), 408 deletions(-)
> >
> > diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
> > index 6baeedc69f..01daddca7b 100644
> > --- a/cmd/bootmenu.c
> > +++ b/cmd/bootmenu.c
> > @@ -351,7 +351,7 @@ static struct bootmenu_data *bootmenu_create(int
> delay)
> >* UEFI specification requires booting from removal media
> using
> >* a architecture-specific default image name such as
> BOOTAA64.EFI.
> >*/
> > - efi_ret = eficonfig_generate_media_device_boot_option();
> > + efi_ret = efi_bootmgr_update_media_device_boot_option();
> >   if (efi_ret != EFI_SUCCESS && efi_ret != EFI_NOT_FOUND)
> >   goto cleanup;
> >
> > diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
> > index 720f52b48b..82a80306f4 100644
> > --- a/cmd/eficonfig.c
> > +++ b/cmd/eficonfig.c
> > @@ -1134,43 +1134,6 @@ out:
> >   return ret;
> >   }
> >
> > -/**
> > - * eficonfig_get_unused_bootoption() - get unused "Boot" index
> > - *
> > - * @buf: pointer to the buffer to store boot option variable name
> > - * @buf_size:buffer size
> > - * @index:   pointer to store the index in the BootOrder variable
> > - * Return:   status code
> > - */
> > -efi_status_t eficonfig_get_unused_bootoption(u16 *buf, efi_uintn_t
> buf_size,
> > -  unsigned int *index)
> > -{
> > - u32 i;
> > - efi_status_t ret;
> > - efi_uintn_t size;
> > -
> > - if (buf_size < u16_strsize(u"Boot"))
> > - return EFI_BUFFER_TOO_SMALL;
> > -
> > - for (i = 0; i <= 0x; i++) {
> > - size = 0;
> > - efi_create_indexed_name(buf, buf_size, "Boot", i);
> > - ret = efi_get_variable_int(buf, &efi_global_variable_guid,
> > -NULL, &size, NULL, NULL);
> > - if (ret == EFI_BUFFER_TOO_SMALL)
> > - continue;
> > - else
> > - break;
> > - }
> > -
> > - if (i > 0x)
> > - return EFI_OUT_OF_RESOURCES;
> > -
> > - *index = i;
> > -
> > - return EFI_SUCCESS;
> > -}
> > -
> >   /**
> >* eficonfig_set_boot_option() - set boot option
> >*
> > @@ -1208,46 +1171,6 @@ static efi_status_t eficonfig_set_boot_option(u16
> *varname, struct efi_device_pa
> >   return ret;
> >   }
> >
> > -/**
> > - * eficonfig_append_bootorder() - append new boot option in BootOrder
> variable
> > - *
> > - * @index:   "Boot" index to append to BootOrder variable
> > - * Return:   status code
> > - */
> > -efi_status_t eficonfig_append_bootorder(u16 index)
> > -{
> > - u16 *bootorder;
> > - efi_status_t ret;
> > - u16 *new_bootorder = NULL;
> > - efi_uintn_t last, size, new_size;
> > -
> > - /* append new boot option */
> > - bootorder = efi_get_var(u"BootOrder", &efi

[PATCH] I2C: cdns: Fix broken retry mechanism on arbitration lost.

[Andrea Merello]

In the current implementation, in case of I2C arbitration lost, a retry is
attempted; the message counter and pointer are reset to the original values
and the I2C xfer process is restart from the beginning.

However the message counter and message pointer are respectively
decremented and incremented by one before attempting any transfer, causing
the 1st transfer not to be actually retried (in case of a single transfer,
nothing is actually retried at all).

This patch fixes this: in case of retry, the 1st transfer is also retried.

Tested on a ZynqMP Kria board, with upstream older u-boot, but the involved
file and underlying logic seem basically the same.

Signed-off-by: Andrea Merello 
---
 drivers/i2c/i2c-cdns.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/i2c-cdns.c b/drivers/i2c/i2c-cdns.c
index 1a89207206..935b2ac637 100644
--- a/drivers/i2c/i2c-cdns.c
+++ b/drivers/i2c/i2c-cdns.c
@@ -444,7 +444,7 @@ static int cdns_i2c_xfer(struct udevice *dev, struct 
i2c_msg *msg,

debug("i2c_xfer: %d messages\n", nmsgs);
for (u8 retry = 0; retry < CDNS_I2C_ARB_LOST_MAX_RETRIES &&
-nmsgs > 0; nmsgs--, msg++) {
+nmsgs > 0;) {
debug("i2c_xfer: chip=0x%x, len=0x%x\n", msg->addr, msg->len);
if (msg->flags & I2C_M_RD) {
ret = cdns_i2c_read_data(i2c_bus, msg->addr, msg->buf,
@@ -461,7 +461,8 @@ static int cdns_i2c_xfer(struct udevice *dev, struct 
i2c_msg *msg,
   retry);
continue;
}
-
+   nmsgs--;
+   msg++;
if (ret) {
debug("i2c_write: error sending\n");
return -EREMOTEIO;
--
2.17.1

Re: USB mass storage gadget on SAMA5D2

[admin LI]

Hi Mihai,

Thanks for your reply, although it's meaningless.

As I said, what we need is block level access to eMMC, in order to modify
partition table or access files of rootfs, SAM-BA can't do it.

Besides SAM-BA can only be launched when eMMC is empty, no way to launch
SAM-BA from u-Boot unless erase bootstrap.

I've also tested with a SD card on SAMA5D27-WLSOM1-EK, which failed with
the same symptom (support case 01275010)
To reduce unknown factors we can use this platform for testing.

Regards,
Zixun

On Fri, May 26, 2023 at 3:20 PM  wrote:

> Hi Zixun,
>
> I recommend to use sam-ba in order to flash the eMMC partitions: boot1,
> boot2, user0.
> sam-ba download links:
>
> https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/SoftwareLibraries/Firmware/sam-ba_v3.7-linux_x86_64.tar.gz
>
> https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/SoftwareLibraries/Firmware/sam-ba_v3.7-win32.zip
>
> For writing the bootstrap binary into boot1 partition, run the following
> command:
>
> sam-ba -p serial -d sama5d2:0:1 -a sdmmc:0:1:1:8:4 -c writeboot:boot.bin
> -c enablebootpartition:1
>
> For help please run:
>
> sam-ba -p serial -d sama5d2 -a sdmmc:help
>
> Syntax:
> sdmmc:[]:[]:[]:[]:[]
> Parameters:
> instance   SDMMC controller number
> ioset  SDMMC I/O set
> partition  Partition number (0=user partition, x>0=boot partition x)
> bus_width  Data bus width (0=controller max, 1=1-bit, 4=4-bit, 8=8-bit)
> voltages   Supported voltages (bitfield: 1=1.8V, 2=3.0V, 4=3.3V)
>
> Regards,
> Mihai
>
>
> --
> *From:* admin LI 
> *Sent:* Friday, May 26, 2023 15:13
> *To:* Cristian Birsan - M91496 
> *Cc:* eugen.hris...@collabora.com ;
> lu...@denx.de ; ma...@denx.de ;
> u-boot@lists.denx.de ; Mihai Sain - M19926 <
> mihai.s...@microchip.com>
> *Subject:* Re: USB mass storage gadget on SAMA5D2
>
> You don't often get email from ad...@hifiphile.com. Learn why this is
> important 
> EXTERNAL EMAIL: Do not click links or open attachments unless you know
> the content is safe
> Hi Cristian,
>
> > What are you trying to achieve ? If you want to just program the eMMC
> you can do it easily with SAM-BA[1].
> On our board the MPU boot from the eMMC boot partition, by exposing the
> whole user partition as a block device we can modify the target system
> easily, like modifying the partition table.
>
> I've tested the gadget works well in Linux, but it's not possible to
> expose the whole disk.
>
> For reference I've implemented at91bootstrap eMMC boot partition support,
> both at91bootstrap and U-Boot are inside the boot partition.
> https://github.com/linux4sam/at91bootstrap/pull/163
> https://github.com/linux4sam/at91bootstrap/pull/164
>
> Regards,
> Zixun
>
> On Thu, May 25, 2023 at 7:16 PM  wrote:
>
> Hi,
>
> On 5/22/23 12:00, admin LI wrote:
> >
> >
> > I think there may be some racing in the driver. (Purely assumption as a
> tinyusb maintainer)
> > If I enable DBG_ALL in atmel_usba_udc.h, the block device is enermurated
> although with I/O error.
>
> What are you trying to achieve ? If you want to just program the eMMC you
> can do it easily with SAM-BA[1].
>
> The mass storage gadget works well in Linux kernel. You can have a look at
> the driver we have in the kernel
> here[2].
>
>
> [1]
> https://www.microchip.com/en-us/development-tool/SAM-BA-In-system-Programmer
> [2]
> https://github.com/linux4microchip/linux/blob/linux-6.1-mchp/drivers/usb/gadget/udc/atmel_usba_udc.c
>
> Regards,
> Cristian
>
> >
> > [1337613.189788] usb 1-1: new high-speed USB device number 7 using
> xhci_hcd
> > [1337613.674551] usb 1-1: New USB device found, idVendor=dead,
> idProduct=beef, bcdDevice= 2.17
> > [1337613.674565] usb 1-1: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> > [1337613.674568] usb 1-1: Product: USB download gadget
> > [1337613.674572] usb 1-1: Manufacturer: U-Boot
> > [1337613.866033] usb-storage 1-1:1.0: USB Mass Storage device detected
> > [1337613.866645] scsi host0: usb-storage 1-1:1.0
> > [1337614.997803] scsi 0:0:0:0: Direct-Access LinuxUMS disk 0
>    PQ: 0 ANSI: 2
> > [1337615.230004] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337615.706637] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337616.183308] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337616.659937] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337617.140086] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337617.616632] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337618.073323] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337618.549927] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337619.026540] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337619.499944] usb 1-1: res

Re: [PATCH v4 00/23] Migration to using binman for bootloader

[Neha Malcom Francis]

Hi Simon, Tom

Please keep this series on hold for v5, for a few board configuration fixes.

On 18/05/23 19:56, Neha Malcom Francis wrote:

This series aims to eliminate the use of additional custom repositories
such as k3-image-gen (K3 Image Generation) repo and core-secdev-k3 (K3
Security Development Tools) that was plumbed into the U-Boot build flow
to generate boot images for TI K3 platform devices. And instead, we move
towards using binman that aligns better with the community standard build
flow.

This series uses binman for all K3 platforms supported on U-Boot currently;
both HS (High Security, both SE and FS) and GP (General Purpose) devices.

Background on using k3-image-gen:
* TI K3 devices require a SYSFW (System Firmware) image consisting
of a signed system firmware image and board configuration binaries,
this is needed to bring up system firmware during U-Boot R5 SPL
startup.
* Board configuration data contain board-specific information
such as resource management, power management and security.

Background on using core-secdev-k3:
* Contains resources to sign x509 certificates for HS devices

Series intends to use binman to take over the packaging and signing for
the R5 bootloader images tiboot3.bin (and sysfw.itb, for non-combined
boot flow) instead of k3-image-gen.

Series also packages the A72/A53 bootloader images (tispl.bin and
u-boot.img) using ATF, OPTEE and DM (Device Manager)

Changes in v4:
- added support for iot2050
- documentation fixes
- move to using self.Raise in ti-board-config etype
- introduced common k3-binman.dtsi (further reduction in code
  duplication can be targetted, this as first step)

Changes in v3:
- added support for HS-FS devices
- added support for AM68-sk
- added back dropped documentation patch
- changed prefix for SYSFW and DM files to expected directory
  name
- extended test coverage to 100%
- documentation fixes
- corrected formatting changes

Changes in v2:
- removed all external scripts
- created ti-board-config etype to support generation of board
  config binaries
- created ti-secure and ti-secure-rom etypes to handle signing
  instead of using external TI_SECURE_DEV_PKG
- updated openssl btool to support x509 certificate generation
- dropped Makefile changes to obtain external binary components,
  moving to using BINMAN_INDIRS to achieve the same

CI/CD passes 100% (with series rebased on -master, current series based
on -next) [1]

v1: 
https://patchwork.ozlabs.org/project/uboot/cover/20230120101903.179959-1-n-fran...@ti.com/
v2: 
https://patchwork.ozlabs.org/project/uboot/cover/20230404121342.446935-1-n-fran...@ti.com/

[1] https://github.com/u-boot/u-boot/pull/291

Kamlesh Gurudasani (1):
   configs: am64x: Enable TI_SECURE_DEV options

Neha Malcom Francis (20):
   binman: ti-board-config: Add support for TI board config binaries
   binman: ti-secure: Add support for TI signing
   arm: dts: k3: Add support for packaging sysfw.itb and tiboot3.bin
   j721e: schema: yaml: Add general schema and J721E board config files
   j721e: dts: binman: Package tiboot3.bin, sysfw.itb, tispl.bin,
 u-boot.img
   j7200: yaml: Add J7200 board config files
   j7200: dts: binman: Package tiboot3.bin, tispl.bin, u-boot.img
   am65x: yaml: Add AM65x board config files
   am65: dts: binman: Package tiboot3.bin, sysfw.itb, tispl.bin,
 u-boot.img
   am64x: yaml: Add board configs for AM64x
   am64x: dts: binman: Package tiboot3.bin, tispl.bin u-boot.img
   j721s2: yaml: Add board configs for J721S2
   j721s2: dts: binman: Package tiboot3.bin, tispl.bin and u-boot.img
   am62: yaml: Add board configs for AM62
   am625: dts: binman: Package tiboot3.bin, tispl.bin and u-boot.img
   am62a: yaml: Add board configs for AM62ax
   am62a: dts: binman: Package tiboot3.bin, tispl.bin, u-boot.img
   arm: k3-am65x-iot2050: Use binman for tispl.bin for iot2050
   k3: tools: config.mk: Update makefile and remove scripts
   doc: board: ti: Update documentation for binman flow

Tom Rini (2):
   buildman: Create a requirements.txt file
   CI: Make use of buildman requirements.txt

  .azure-pipelines.yml  |4 +
  .gitlab-ci.yml|4 +
  arch/arm/dts/k3-am625-r5-sk.dts   |1 +
  arch/arm/dts/k3-am625-sk-binman.dtsi  |  462 +++
  arch/arm/dts/k3-am625-sk-u-boot.dtsi  |2 +
  arch/arm/dts/k3-am62a-sk-binman.dtsi  |  461 +++
  arch/arm/dts/k3-am62a7-r5-sk.dts  |1 +
  arch/arm/dts/k3-am62a7-sk.dts |1 +
  arch/arm/dts/k3-am642-evm-u-boot.dtsi |2 +
  arch/arm/dts/k3-am642-r5-evm.dts  |1 +
  arch/arm/dts/k3-am64x-binman.dtsi |  514 +++
  arch/arm/dts/k3-am65-iot2050-boot-image.dtsi  |   76 +-
  

Re: USB mass storage gadget on SAMA5D2

[Mihai.Sain]

Hi Zixun,

I recommend to use sam-ba in order to flash the eMMC partitions: boot1, boot2, 
user0.
sam-ba download links:
https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/SoftwareLibraries/Firmware/sam-ba_v3.7-linux_x86_64.tar.gz
https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductDocuments/SoftwareLibraries/Firmware/sam-ba_v3.7-win32.zip

For writing the bootstrap binary into boot1 partition, run the following 
command:

sam-ba -p serial -d sama5d2:0:1 -a sdmmc:0:1:1:8:4 -c writeboot:boot.bin -c 
enablebootpartition:1

For help please run:

sam-ba -p serial -d sama5d2 -a sdmmc:help

Syntax: sdmmc:[]:[]:[]:[]:[]
Parameters:
instance   SDMMC controller number
ioset  SDMMC I/O set
partition  Partition number (0=user partition, x>0=boot partition x)
bus_width  Data bus width (0=controller max, 1=1-bit, 4=4-bit, 8=8-bit)
voltages   Supported voltages (bitfield: 1=1.8V, 2=3.0V, 4=3.3V)

Regards,
Mihai


From: admin LI 
Sent: Friday, May 26, 2023 15:13
To: Cristian Birsan - M91496 
Cc: eugen.hris...@collabora.com ; lu...@denx.de 
; ma...@denx.de ; u-boot@lists.denx.de 
; Mihai Sain - M19926 
Subject: Re: USB mass storage gadget on SAMA5D2

You don't often get email from ad...@hifiphile.com. Learn why this is 
important
EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe
Hi Cristian,

> What are you trying to achieve ? If you want to just program the eMMC you can 
> do it easily with SAM-BA[1].
On our board the MPU boot from the eMMC boot partition, by exposing the whole 
user partition as a block device we can modify the target system easily, like 
modifying the partition table.

I've tested the gadget works well in Linux, but it's not possible to expose the 
whole disk.

For reference I've implemented at91bootstrap eMMC boot partition support, both 
at91bootstrap and U-Boot are inside the boot partition.
https://github.com/linux4sam/at91bootstrap/pull/163
https://github.com/linux4sam/at91bootstrap/pull/164

Regards,
Zixun

On Thu, May 25, 2023 at 7:16 PM 
mailto:cristian.bir...@microchip.com>> wrote:
Hi,

On 5/22/23 12:00, admin LI wrote:
>
>
> I think there may be some racing in the driver. (Purely assumption as a 
> tinyusb maintainer)
> If I enable DBG_ALL in atmel_usba_udc.h, the block device is enermurated 
> although with I/O error.

What are you trying to achieve ? If you want to just program the eMMC you can 
do it easily with SAM-BA[1].

The mass storage gadget works well in Linux kernel. You can have a look at the 
driver we have in the kernel
here[2].


[1] https://www.microchip.com/en-us/development-tool/SAM-BA-In-system-Programmer
[2] 
https://github.com/linux4microchip/linux/blob/linux-6.1-mchp/drivers/usb/gadget/udc/atmel_usba_udc.c

Regards,
Cristian

>
> [1337613.189788] usb 1-1: new high-speed USB device number 7 using xhci_hcd
> [1337613.674551] usb 1-1: New USB device found, idVendor=dead, 
> idProduct=beef, bcdDevice= 2.17
> [1337613.674565] usb 1-1: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=0
> [1337613.674568] usb 1-1: Product: USB download gadget
> [1337613.674572] usb 1-1: Manufacturer: U-Boot
> [1337613.866033] usb-storage 1-1:1.0: USB Mass Storage device detected
> [1337613.866645] scsi host0: usb-storage 1-1:1.0
> [1337614.997803] scsi 0:0:0:0: Direct-Access LinuxUMS disk 0   
>  PQ: 0 ANSI: 2
> [1337615.230004] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337615.706637] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337616.183308] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337616.659937] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337617.140086] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337617.616632] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337618.073323] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337618.549927] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337619.026540] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337619.499944] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337619.976679] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337620.453285] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337620.916597] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337621.393267] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337621.869676] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337622.346597] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337622.823361] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337623.293287] usb 1-1: reset high-speed USB device number 7 using xhci_hcd
> [1337623.635357] sd 0:0:0:0: [sda] Read Capacity(10) f

Re: Fit Signature booting without public key

[Tom Rini]

On Fri, May 26, 2023 at 02:22:38PM +0530, Manorit Chawdhry wrote:
> Hi Tom,
> 
> On 10:05-20230525, Tom Rini wrote:
> > On Thu, May 25, 2023 at 11:21:44AM +0530, Manorit Chawdhry wrote:
> > > Hi Tom,
> > > 
> > > On 11:30-20230516, Tom Rini wrote:
> > > > On Tue, May 16, 2023 at 12:11:24PM +0530, Manorit Chawdhry wrote:
> > > > 
> > > > > Hi All,
> > > > > 
> > > > > I recently came upon a discussion that had happened a while back [0].
> > > > > I want to continue the discussion as I believe the issue still 
> > > > > persists
> > > > > and the checks around fit signature booting are still the same, that
> > > > > allows booting the fit without changing the uboot dtb.
> > > > > 
> > > > > Allowing the signed fit image without this seems to be a bypass that 
> > > > > is
> > > > > available and should not be allowed without any gate to it for people
> > > > > who'd like to enforce these signing checks. Let me know if there is a
> > > > > config already available for it and if not, are there any plans to
> > > > > enable such a config in future. Would like to hear your opinions on
> > > > > this as I believe this should be fixed as soon as possible.
> > > > > 
> > > > > [0]: 
> > > > > https://u-boot.denx.narkive.com/dEClg9dW/signed-fit-image-boots-without-public-key
> > > > 
> > > > Yes, can you please reproduce the issue in question on the current tree,
> > > > with a supported platform and provide the defconfig and steps you used
> > > > for this issue? Thanks.
> > > > 
> > > > -- 
> > > 
> > > I've created a branch with some custom patches to make the fitimage
> > > booting currently, please try with the branch and the fitimage that are
> > > also committed [0].
> > > 
> > > The devices that I've tested this with is j721e-hs-evm, the defconfig to
> > > use for the builds are j721e_evm_r5_defconfig and
> > > j721e_evm_a72_defconfig. Although not synced up with the latest changes
> > > but for reference the SDK documentation can help if required [1].
> > > 
> > > Attached the logs for reference with the signed fitimage and an unsigned
> > > uboot without any modifications[2].
> > > 
> > > [0]: https://github.com/manorit2001/u-boot/tree/fit-image-poc
> > > [1]: 
> > > https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacinto7/08_06_00_11/exports/docs/linux/Foundational_Components/U-Boot/UG-General-Info.html
> > > [2]: https://gist.github.com/manorit2001/3c49cfc19bf937783efb75fd4cddc58f
> > 
> > I don't see the problem there, but please go and investigate what
> > problem you're seeing.  The intention is that yes, with the appropriate
> > CONFIG settings, you can set U-Boot to only boot signed FIT
> > configurations and unsigned ones should not boot.
> > 
> 
> It boots with an unsigned fit too btw for reference [0]. The whole
> logic behind the authentication is that uboot stores the public key that
> is used for verification of the signed fit but apparantely if I haven't
> kept the public key in uboot dtb the fit images still boot whether
> signed or unsigned as that check is not guarded by anything if you see
> in the codebase[1].
> 
> [0]: https://gist.github.com/manorit2001/80c9242641141ac5bce0e335ea8a9f1a
> [1]: 
> https://github.com/u-boot/u-boot/blob/6dcee70692601bd3296c86ac07d0317bf06d2b7b/boot/image-fit-sig.c#L491-L496

Alright, please let us know what you find as indeed if you've set all
the right options it's not supposed to boot unsigned images.

-- 
Tom


signature.asc
Description: PGP signature

[RESEND PATCH v1 4/4] doc: t-head: lpi4a: document Lichee PI 4A board

[Yixun Lan]

Reviewed-by: Wei Fu 
Signed-off-by: Yixun Lan 
---
 doc/board/index.rst   |   1 +
 doc/board/thead/index.rst |   9 +++
 doc/board/thead/lpi4a.rst | 112 ++
 3 files changed, 122 insertions(+)
 create mode 100644 doc/board/thead/index.rst
 create mode 100644 doc/board/thead/lpi4a.rst

diff --git a/doc/board/index.rst b/doc/board/index.rst
index 9ef25b1091..aadc90af89 100644
--- a/doc/board/index.rst
+++ b/doc/board/index.rst
@@ -45,6 +45,7 @@ Board-specific doc
starfive/index
ste/index
tbs/index
+   thead/index
ti/index
toradex/index
variscite/index
diff --git a/doc/board/thead/index.rst b/doc/board/thead/index.rst
new file mode 100644
index 00..41566d3a36
--- /dev/null
+++ b/doc/board/thead/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+T-HEAD
+
+
+.. toctree::
+   :maxdepth: 1
+
+   lpi4a
diff --git a/doc/board/thead/lpi4a.rst b/doc/board/thead/lpi4a.rst
new file mode 100644
index 00..3764e732af
--- /dev/null
+++ b/doc/board/thead/lpi4a.rst
@@ -0,0 +1,112 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Sipeed's Lichee PI 4A based on T-HEAD TH1520 SoC
+
+
+TH1520 RISC-V SoC
+-
+The TH1520 is 4+2 core 64-bit RISC-V SoC from Alibaba T-HEAD, it's capable of
+running highest CPU frequency at 2.5 GHz, integrate Imagination GPU for 
graphics,
+also with 4 TOPS NPU for AI acceleration.
+
+Mainline support
+
+
+The support for following drivers are already enabled:
+
+1. ns16550 UART Driver.
+
+Building
+
+
+1. Add the RISC-V toolchain to your PATH.
+2. Setup ARCH & cross compilation environment variable:
+
+.. code-block:: none
+
+   export CROSS_COMPILE=
+
+The U-Boot is capable of running in M-Mode, so we can directly build it.
+
+.. code-block:: console
+
+   cd 
+   make th1520_lpi4a_defconfig
+   make
+
+This will generate u-boot-dtb.bin
+
+Booting
+~~~
+
+Currently, we rely on vendor u-boot to initialize the clock, pinctrl subsystem,
+and chain load the mainline u-boot image either via tftp or emmc storage,
+then bootup from it.
+
+Sample boot log from Lichee PI 4A board via tftp
+~~~
+
+.. code-block:: none
+
+   brom_ver 8
+   [APP][E] protocol_connect failed, exit.
+
+   U-Boot SPL 2020.01-00016-g8c870a6be8 (May 20 2023 - 01:04:49 +)
+   FM[1] lpddr4x dualrank freq=3733 64bit dbi_off=n sdram init
+   ddr initialized, jump to uboot
+   image has no header
+
+
+   U-Boot 2020.01-00016-g8c870a6be8 (May 20 2023 - 01:04:49 +)
+
+   CPU:   rv64imafdcvsu
+   Model: T-HEAD c910 light
+   DRAM:  8 GiB
+   C910 CPU FREQ: 750MHz
+   AHB2_CPUSYS_HCLK FREQ: 250MHz
+   AHB3_CPUSYS_PCLK FREQ: 125MHz
+   PERISYS_AHB_HCLK FREQ: 250MHz
+   PERISYS_APB_PCLK FREQ: 62MHz
+   GMAC PLL POSTDIV FREQ: 1000MHZ
+   DPU0 PLL POSTDIV FREQ: 1188MHZ
+   DPU1 PLL POSTDIV FREQ: 1188MHZ
+   MMC:   sdhci@ffe708: 0, sd@ffe709: 1
+   Loading Environment from MMC... OK
+   Error reading output register
+   Warning: cannot get lcd-en GPIO
+   LCD panel cannot be found : -121
+   splash screen startup cost 16 ms
+   In:serial
+   Out:   serial
+   Err:   serial
+   Net:
+   Warning: ethernet@ffe707 using MAC address from ROM
+   eth0: ethernet@ffe707ethernet@ffe707:0 is connected to 
ethernet@ffe707.  Reconnecting to ethernet@ffe706
+
+   Warning: ethernet@ffe706 (eth1) using random MAC address - 
42:25:d4:16:5f:fc
+   , eth1: ethernet@ffe706
+   Hit any key to stop autoboot:  2
+   ethernet@ffe706 Waiting for PHY auto negotiation to complete.. done
+   Speed: 1000, full duplex
+   Using ethernet@ffe707 device
+   TFTP from server 192.168.8.50; our IP address is 192.168.8.45
+   Filename 'u-boot-dtb.bin'.
+   Load address: 0x1c0
+   Loading: * #
+8 MiB/s
+   done
+   Bytes transferred = 376686 (5bf6e hex)
+   ## Starting application at 0x01C0 ...
+
+U-Boot 2023.07-rc2-4-g1befbe31c1 (May 23 2023 - 18:40:01 +0800)
+
+CPU:   rv64imafdc
+Model: Sipeed Lichee Pi 4A
+DRAM:  8 GiB
+Core:  13 devices, 6 uclasses, devicetree: separate
+Loading Environment from ... OK
+In:serial@ffe7014000
+Out:   serial@ffe7014000
+Err:   serial@ffe7014000
+Model: Sipeed Lichee Pi 4A
+LPI4A=>
-- 
2.40.0

[RESEND PATCH v1 2/4] riscv: dts: t-head: Add basic device tree for Sipeed Lichee PI 4A board

[Yixun Lan]

Only add basic support for CPU, PLIC UART and Timer.

Reviewed-by: Wei Fu 
Signed-off-by: Yixun Lan 
---
 arch/riscv/dts/Makefile |   1 +
 arch/riscv/dts/th1520-lichee-module-4a.dtsi |  34 ++
 arch/riscv/dts/th1520-lichee-pi-4a.dts  |  32 ++
 arch/riscv/dts/th1520.dtsi  | 435 
 4 files changed, 502 insertions(+)
 create mode 100644 arch/riscv/dts/th1520-lichee-module-4a.dtsi
 create mode 100644 arch/riscv/dts/th1520-lichee-pi-4a.dts
 create mode 100644 arch/riscv/dts/th1520.dtsi

diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
index 79a58694f5..72fd815a40 100644
--- a/arch/riscv/dts/Makefile
+++ b/arch/riscv/dts/Makefile
@@ -9,6 +9,7 @@ dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) += 
hifive-unmatched-a00.dtb
 dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb
 dtb-$(CONFIG_TARGET_STARFIVE_VISIONFIVE2) += 
jh7110-starfive-visionfive-2-v1.3b.dtb
 dtb-$(CONFIG_TARGET_STARFIVE_VISIONFIVE2) += 
jh7110-starfive-visionfive-2-v1.2a.dtb
+dtb-$(CONFIG_TARGET_TH1520_LPI4A) += th1520-lichee-pi-4a.dtb
 include $(srctree)/scripts/Makefile.dts
 
 targets += $(dtb-y)
diff --git a/arch/riscv/dts/th1520-lichee-module-4a.dtsi 
b/arch/riscv/dts/th1520-lichee-module-4a.dtsi
new file mode 100644
index 00..dc00e3dfa0
--- /dev/null
+++ b/arch/riscv/dts/th1520-lichee-module-4a.dtsi
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2023 Jisheng Zhang 
+ */
+
+/dts-v1/;
+
+#include "th1520.dtsi"
+
+/ {
+   model = "Sipeed Lichee Module 4A";
+   compatible = "sipeed,lichee-module-4a", "thead,th1520";
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x 0x2 0x>;
+   };
+};
+
+&osc {
+   clock-frequency = <2400>;
+};
+
+&osc_32k {
+   clock-frequency = <32768>;
+};
+
+&apb_clk {
+   clock-frequency = <6250>;
+};
+
+&uart_sclk {
+   clock-frequency = <1>;
+};
diff --git a/arch/riscv/dts/th1520-lichee-pi-4a.dts 
b/arch/riscv/dts/th1520-lichee-pi-4a.dts
new file mode 100644
index 00..a1248b2ee3
--- /dev/null
+++ b/arch/riscv/dts/th1520-lichee-pi-4a.dts
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2023 Jisheng Zhang 
+ */
+
+#include "th1520-lichee-module-4a.dtsi"
+
+/ {
+   model = "Sipeed Lichee Pi 4A";
+   compatible = "sipeed,lichee-pi-4a", "sipeed,lichee-module-4a", 
"thead,th1520";
+
+   aliases {
+   gpio0 = &gpio0;
+   gpio1 = &gpio1;
+   gpio2 = &gpio2;
+   gpio3 = &gpio3;
+   serial0 = &uart0;
+   serial1 = &uart1;
+   serial2 = &uart2;
+   serial3 = &uart3;
+   serial4 = &uart4;
+   serial5 = &uart5;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+&uart0 {
+   status = "okay";
+};
diff --git a/arch/riscv/dts/th1520.dtsi b/arch/riscv/dts/th1520.dtsi
new file mode 100644
index 00..f62a62da6e
--- /dev/null
+++ b/arch/riscv/dts/th1520.dtsi
@@ -0,0 +1,435 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021 Alibaba Group Holding Limited.
+ * Copyright (C) 2023 Jisheng Zhang 
+ */
+
+#include 
+
+/ {
+   compatible = "thead,th1520";
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   cpus: cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   timebase-frequency = <300>;
+
+   c910_0: cpu@0 {
+   compatible = "thead,c910", "riscv";
+   device_type = "cpu";
+   riscv,isa = "rv64imafdc";
+   reg = <0>;
+   i-cache-block-size = <64>;
+   i-cache-size = <65536>;
+   i-cache-sets = <512>;
+   d-cache-block-size = <64>;
+   d-cache-size = <65536>;
+   d-cache-sets = <512>;
+   next-level-cache = <&l2_cache>;
+   mmu-type = "riscv,sv39";
+
+   cpu0_intc: interrupt-controller {
+   compatible = "riscv,cpu-intc";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   };
+   };
+
+   c910_1: cpu@1 {
+   compatible = "thead,c910", "riscv";
+   device_type = "cpu";
+   riscv,isa = "rv64imafdc";
+   reg = <1>;
+   i-cache-block-size = <64>;
+   i-cache-size = <65536>;
+   i-cache-sets = <512>;
+   d-cache-block-size = <64>;
+   d-cache-size = <65536>;
+   d-cache-sets = <512>;
+   next-level-cache = <&l2_cache>;
+  

[RESEND PATCH v1 3/4] configs: th1520_lpi4a_defconfig: Add initial config

[Yixun Lan]

Add basic config for Sipeed Lichee PI 4A board which make it capable of
booting into serial console.

Reviewed-by: Wei Fu 
Signed-off-by: Yixun Lan 
---
 configs/th1520_lpi4a_defconfig | 82 ++
 1 file changed, 82 insertions(+)
 create mode 100644 configs/th1520_lpi4a_defconfig

diff --git a/configs/th1520_lpi4a_defconfig b/configs/th1520_lpi4a_defconfig
new file mode 100644
index 00..710ec6abf5
--- /dev/null
+++ b/configs/th1520_lpi4a_defconfig
@@ -0,0 +1,82 @@
+CONFIG_RISCV=y
+CONFIG_SYS_MALLOC_LEN=0x80
+CONFIG_SYS_MALLOC_F_LEN=0x3000
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8020
+CONFIG_DEFAULT_DEVICE_TREE="th1520-lichee-pi-4a"
+CONFIG_SYS_PROMPT="LPI4A=> "
+CONFIG_SYS_LOAD_ADDR=0x8020
+# CONFIG_SMP is not set
+CONFIG_TARGET_TH1520_LPI4A=y
+CONFIG_ARCH_RV64I=y
+CONFIG_OF_BOARD_FIXUP=y
+CONFIG_SYS_BOOT_GET_CMDLINE=y
+CONFIG_SYS_BOOT_GET_KBD=y
+CONFIG_FIT=y
+# CONFIG_FIT_FULL_CHECK is not set
+# CONFIG_FIT_PRINT is not set
+# CONFIG_BOOTSTD is not set
+# CONFIG_LEGACY_IMAGE_FORMAT is not set
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_BOOTARGS_SUBST=y
+CONFIG_BOOTCOMMAND=""
+CONFIG_DEFAULT_FDT_FILE="thead/th1520-lichee-pi-4a.dtb"
+CONFIG_LOG=y
+CONFIG_DISPLAY_CPUINFO=y
+CONFIG_DISPLAY_BOARDINFO=y
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SYS_CBSIZE=256
+CONFIG_SYS_PBSIZE=276
+CONFIG_CMD_CONFIG=y
+CONFIG_CMD_LICENSE=y
+CONFIG_CMD_BOOTZ=y
+# CONFIG_BOOTM_NETBSD is not set
+# CONFIG_BOOTM_PLAN9 is not set
+# CONFIG_BOOTM_RTEMS is not set
+# CONFIG_BOOTM_VXWORKS is not set
+CONFIG_SYS_BOOTM_LEN=0x400
+CONFIG_CMD_BOOTMENU=y
+# CONFIG_CMD_ELF is not set
+# CONFIG_CMD_IMI is not set
+# CONFIG_CMD_XIMG is not set
+# CONFIG_CMD_EXPORTENV is not set
+# CONFIG_CMD_IMPORTENV is not set
+# CONFIG_CMD_EDITENV is not set
+# CONFIG_CMD_SAVEENV is not set
+# CONFIG_CMD_CRC32 is not set
+# CONFIG_CMD_MEMORY is not set
+# CONFIG_CMD_LZMADEC is not set
+# CONFIG_CMD_UNLZ4 is not set
+# CONFIG_CMD_UNZIP is not set
+# CONFIG_CMD_LOADB is not set
+# CONFIG_CMD_LOADS is not set
+# CONFIG_CMD_ITEST is not set
+# CONFIG_CMD_SOURCE is not set
+# CONFIG_CMD_SETEXPR is not set
+# CONFIG_CMD_SLEEP is not set
+CONFIG_PARTITION_TYPE_GUID=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_VERSION_VARIABLE=y
+# CONFIG_NET is not set
+# CONFIG_BLOCK_CACHE is not set
+# CONFIG_GPIO is not set
+# CONFIG_I2C is not set
+# CONFIG_INPUT is not set
+# CONFIG_DM_MMC is not set
+# CONFIG_MTD is not set
+# CONFIG_POWER is not set
+CONFIG_SYS_NS16550=y
+CONFIG_RISCV_TIMER=y
+CONFIG_AES=y
+CONFIG_BLAKE2=y
+CONFIG_SHA512=y
+CONFIG_LZ4=y
+CONFIG_LZMA=y
+CONFIG_LZO=y
+CONFIG_ZLIB_UNCOMPRESS=y
+CONFIG_BZIP2=y
+CONFIG_ZSTD=y
+CONFIG_LIB_RATIONAL=y
+# CONFIG_EFI_LOADER is not set
+# CONFIG_LMB_USE_MAX_REGIONS is not set
-- 
2.40.0

[RESEND PATCH v1 1/4] riscv: t-head: licheepi4a: initial support added

[Yixun Lan]

Add support for Sipeed's Lichee Pi 4A board which based on
T-HEAD's TH1520 SoC, only minimal device tree and serial onsole are enabled,
so it's capable of chain booting from T-HEAD's vendor u-boot.

Reviewed-by: Wei Fu 
Signed-off-by: Yixun Lan 
---
 arch/riscv/Kconfig   |  5 
 board/thead/th1520_lpi4a/Kconfig | 42 
 board/thead/th1520_lpi4a/MAINTAINERS |  7 +
 board/thead/th1520_lpi4a/Makefile|  5 
 board/thead/th1520_lpi4a/board.c | 14 ++
 include/configs/th1520_lpi4a.h   | 22 +++
 6 files changed, 95 insertions(+)
 create mode 100644 board/thead/th1520_lpi4a/Kconfig
 create mode 100644 board/thead/th1520_lpi4a/MAINTAINERS
 create mode 100644 board/thead/th1520_lpi4a/Makefile
 create mode 100644 board/thead/th1520_lpi4a/board.c
 create mode 100644 include/configs/th1520_lpi4a.h

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index f6ed05906a..419b6171a9 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -27,6 +27,10 @@ config TARGET_SIFIVE_UNMATCHED
 config TARGET_STARFIVE_VISIONFIVE2
bool "Support StarFive VisionFive2 Board"
 
+config TARGET_TH1520_LPI4A
+   bool "Support Sipeed's TH1520 Lichee PI 4A Board"
+   select SYS_CACHE_SHIFT_6
+
 config TARGET_SIPEED_MAIX
bool "Support Sipeed Maix Board"
select SYS_CACHE_SHIFT_6
@@ -66,6 +70,7 @@ source "board/emulation/qemu-riscv/Kconfig"
 source "board/microchip/mpfs_icicle/Kconfig"
 source "board/sifive/unleashed/Kconfig"
 source "board/sifive/unmatched/Kconfig"
+source "board/thead/th1520_lpi4a/Kconfig"
 source "board/openpiton/riscv64/Kconfig"
 source "board/sipeed/maix/Kconfig"
 source "board/starfive/visionfive2/Kconfig"
diff --git a/board/thead/th1520_lpi4a/Kconfig b/board/thead/th1520_lpi4a/Kconfig
new file mode 100644
index 00..622246127c
--- /dev/null
+++ b/board/thead/th1520_lpi4a/Kconfig
@@ -0,0 +1,42 @@
+if TARGET_TH1520_LPI4A
+
+config ARCH_THEAD
+   bool
+   default y
+
+config SYS_BOARD
+   default "th1520_lpi4a"
+
+config SYS_VENDOR
+   default "thead"
+
+config SYS_CPU
+   default "generic"
+
+config SYS_CONFIG_NAME
+   default "th1520_lpi4a"
+
+config TEXT_BASE
+   default 0x01b0 if SPL
+   default 0x01c0 if !RISCV_SMODE
+   default 0x01c0 if RISCV_SMODE
+
+config SPL_TEXT_BASE
+   default 0x0800
+
+config SPL_OPENSBI_LOAD_ADDR
+   default 0x8000
+
+config BOARD_SPECIFIC_OPTIONS
+   def_bool y
+   select ARCH_EARLY_INIT_R
+   imply CPU
+   imply CPU_RISCV
+   imply RISCV_TIMER if RISCV_SMODE
+   imply CMD_CPU
+   imply SMP
+   imply SUPPORT_OF_CONTROL
+   imply OF_CONTROL
+   imply OF_REAL
+
+endif
diff --git a/board/thead/th1520_lpi4a/MAINTAINERS 
b/board/thead/th1520_lpi4a/MAINTAINERS
new file mode 100644
index 00..36c7ab7cc3
--- /dev/null
+++ b/board/thead/th1520_lpi4a/MAINTAINERS
@@ -0,0 +1,7 @@
+Lichee PI 4A
+M: Wei Fu 
+M: Yixun Lan 
+S: Maintained
+F: board/thead/th1520_lpi4a/
+F: configs/th1520_lpi4a_defconfig
+F: doc/board/thead/lpi4a.rst
diff --git a/board/thead/th1520_lpi4a/Makefile 
b/board/thead/th1520_lpi4a/Makefile
new file mode 100644
index 00..9671b3bbb0
--- /dev/null
+++ b/board/thead/th1520_lpi4a/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (c) 2023, Yixun Lan 
+
+obj-y += board.o
diff --git a/board/thead/th1520_lpi4a/board.c b/board/thead/th1520_lpi4a/board.c
new file mode 100644
index 00..378bab098b
--- /dev/null
+++ b/board/thead/th1520_lpi4a/board.c
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2023, Yixun Lan 
+ *
+ */
+
+#include 
+
+int board_init(void)
+{
+   enable_caches();
+
+   return 0;
+}
diff --git a/include/configs/th1520_lpi4a.h b/include/configs/th1520_lpi4a.h
new file mode 100644
index 00..87496a52c4
--- /dev/null
+++ b/include/configs/th1520_lpi4a.h
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2023 Yixun Lan 
+ *
+ */
+
+#ifndef __TH1520_LPI4A_H
+#define __TH1520_LPI4A_H
+
+#include 
+
+#define CFG_SYS_SDRAM_BASE 0x
+
+#define UART_BASE  0xffe7014000
+#define UART_REG_WIDTH  32
+
+/* Environment options */
+
+#define CFG_EXTRA_ENV_SETTINGS \
+   "PS1=[LPi4A]# \0"
+
+#endif /* __TH1520_LPI4A_H */
-- 
2.40.0

[RESEND PATCH v1 0/4] riscv: Initial support for Lichee PI 4A board

[Yixun Lan]

Sipeed's Lichee PI 4A board is based on T-HEAD's TH1520 SoC which consists of
quad core XuanTie C910 CPU, plus one C906 CPU and one E902 CPU.

In this series, the UART, basic device tree, CPU, PLIC are enabled, making it
capable of running in serial console mode.

Please note that, we rely on pre shipped vendor u-boot which run in M-Mode to
chain load this mainline u-boot either via eMMC storage or from tftp, thus the
pinctrl and clock setting are not implemented in this series, which certainly
can be improved later accordingly.

Also the device tree is coming from kernel which is submitted by Jisheng Zhang 
in
his patch V2 [1], it's still under review, so may change in the future.


[1] https://lore.kernel.org/all/20230518184541.2627-1-jszh...@kernel.org

Yixun Lan (4):
  riscv: t-head: licheepi4a: initial support added
  riscv: dts: t-head: Add basic device tree for Sipeed Lichee PI 4A
board
  configs: th1520_lpi4a_defconfig: Add initial config
  doc: t-head: lpi4a: document Lichee PI 4A board

 arch/riscv/Kconfig  |   5 +
 arch/riscv/dts/Makefile |   1 +
 arch/riscv/dts/th1520-lichee-module-4a.dtsi |  34 ++
 arch/riscv/dts/th1520-lichee-pi-4a.dts  |  32 ++
 arch/riscv/dts/th1520.dtsi  | 435 
 board/thead/th1520_lpi4a/Kconfig|  42 ++
 board/thead/th1520_lpi4a/MAINTAINERS|   7 +
 board/thead/th1520_lpi4a/Makefile   |   5 +
 board/thead/th1520_lpi4a/board.c|  14 +
 configs/th1520_lpi4a_defconfig  |  82 
 doc/board/index.rst |   1 +
 doc/board/thead/index.rst   |   9 +
 doc/board/thead/lpi4a.rst   | 112 +
 include/configs/th1520_lpi4a.h  |  22 +
 14 files changed, 801 insertions(+)
 create mode 100644 arch/riscv/dts/th1520-lichee-module-4a.dtsi
 create mode 100644 arch/riscv/dts/th1520-lichee-pi-4a.dts
 create mode 100644 arch/riscv/dts/th1520.dtsi
 create mode 100644 board/thead/th1520_lpi4a/Kconfig
 create mode 100644 board/thead/th1520_lpi4a/MAINTAINERS
 create mode 100644 board/thead/th1520_lpi4a/Makefile
 create mode 100644 board/thead/th1520_lpi4a/board.c
 create mode 100644 configs/th1520_lpi4a_defconfig
 create mode 100644 doc/board/thead/index.rst
 create mode 100644 doc/board/thead/lpi4a.rst
 create mode 100644 include/configs/th1520_lpi4a.h

-- 
2.40.0

Re: USB mass storage gadget on SAMA5D2

[admin LI]

Hi Cristian,

> What are you trying to achieve ? If you want to just program the eMMC you
can do it easily with SAM-BA[1].
On our board the MPU boot from the eMMC boot partition, by exposing the
whole user partition as a block device we can modify the target system
easily, like modifying the partition table.

I've tested the gadget works well in Linux, but it's not possible to expose
the whole disk.

For reference I've implemented at91bootstrap eMMC boot partition support,
both at91bootstrap and U-Boot are inside the boot partition.
https://github.com/linux4sam/at91bootstrap/pull/163
https://github.com/linux4sam/at91bootstrap/pull/164

Regards,
Zixun

On Thu, May 25, 2023 at 7:16 PM  wrote:

> Hi,
>
> On 5/22/23 12:00, admin LI wrote:
> >
> >
> > I think there may be some racing in the driver. (Purely assumption as a
> tinyusb maintainer)
> > If I enable DBG_ALL in atmel_usba_udc.h, the block device is enermurated
> although with I/O error.
>
> What are you trying to achieve ? If you want to just program the eMMC you
> can do it easily with SAM-BA[1].
>
> The mass storage gadget works well in Linux kernel. You can have a look at
> the driver we have in the kernel
> here[2].
>
>
> [1]
> https://www.microchip.com/en-us/development-tool/SAM-BA-In-system-Programmer
> [2]
> https://github.com/linux4microchip/linux/blob/linux-6.1-mchp/drivers/usb/gadget/udc/atmel_usba_udc.c
>
> Regards,
> Cristian
>
> >
> > [1337613.189788] usb 1-1: new high-speed USB device number 7 using
> xhci_hcd
> > [1337613.674551] usb 1-1: New USB device found, idVendor=dead,
> idProduct=beef, bcdDevice= 2.17
> > [1337613.674565] usb 1-1: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> > [1337613.674568] usb 1-1: Product: USB download gadget
> > [1337613.674572] usb 1-1: Manufacturer: U-Boot
> > [1337613.866033] usb-storage 1-1:1.0: USB Mass Storage device detected
> > [1337613.866645] scsi host0: usb-storage 1-1:1.0
> > [1337614.997803] scsi 0:0:0:0: Direct-Access LinuxUMS disk 0
>    PQ: 0 ANSI: 2
> > [1337615.230004] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337615.706637] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337616.183308] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337616.659937] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337617.140086] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337617.616632] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337618.073323] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337618.549927] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337619.026540] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337619.499944] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337619.976679] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337620.453285] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337620.916597] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337621.393267] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337621.869676] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337622.346597] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337622.823361] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337623.293287] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337623.635357] sd 0:0:0:0: [sda] Read Capacity(10) failed: Result:
> hostbyte=DID_ERROR driverbyte=DRIVER_OK
> > [1337623.635369] sd 0:0:0:0: [sda] Sense not available.
> > [1337623.635376] sd 0:0:0:0: [sda] 0 512-byte logical blocks: (0 B/0 B)
> > [1337623.635379] sd 0:0:0:0: [sda] 0-byte physical blocks
> > [1337623.756597] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337624.233274] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337624.709945] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337625.186639] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337625.663266] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337626.136617] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337626.478078] sd 0:0:0:0: [sda] Write Protect is off
> > [1337626.478088] sd 0:0:0:0: [sda] Mode Sense: 00 00 00 00
> > [1337626.599928] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337627.076606] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337627.553276] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337628.029936] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337628.499858] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337628.973267] usb 1-1: reset high-speed USB device number 7 using
> xhci_hcd
> > [1337629.313

Re: [PATCH v4 1/7] dt-bindings: clock: Add StarFive JH7110 PLL clock generator

[Conor Dooley]

On Fri, May 26, 2023 at 09:34:32AM +0200, Torsten Duwe wrote:
> On Wed, 24 May 2023 11:19:48 +0100
> Conor Dooley  wrote:
> 
> > On Wed, May 24, 2023 at 05:00:02PM +0800, Xingyu Wu wrote:
> > > On 2023/5/23 19:28, Conor Dooley wrote:
> > > > On Tue, May 23, 2023 at 01:10:06PM +0200, Torsten Duwe wrote:
> > > >> On Tue, 23 May 2023 09:28:39 +0100
> > > >> Conor Dooley  wrote:
> > > >> 
> > > >> > On Tue, May 23, 2023 at 10:56:43AM +0800, Xingyu Wu wrote:
> > > >> > > On 2023/5/19 22:16, Conor Dooley wrote:
> > > >> > > > On Fri, May 19, 2023 at 03:57:33PM +0200, Torsten Duwe
> > > >> > > > wrote:
> > > >> > > >> On Fri, May 12, 2023 at 10:20:30AM +0800, Xingyu Wu wrote:
> [...]
> 
> > > >> > > Because PLL driver is separated from SYSCRG drivers in
> > > >> > > Linux, the numbering starts from 0. But in Uboot, the PLL
> > > >> > > driver is included in the SYSCRG driver, and the number
> > > >> > > follows the SYSCRG.
> > > >> > 
> > > >> > Unfortunately, how you choose to construct your drivers has
> > > >> > nothing to do with this.
> 
> Exactly. As I wrote (quote below), the PLLx frequencies are controlled
> by the I/O block SYS_SYSCON (starting there at offset 0x18), according
> to the public datasheets. All(?) other clocks are derived from those in
> the *_CRG units. That *is* the hardware to be described, in *the* (one
> and only!) DT. U-Boot, and any OS, are free to reorganise their driver
> framework around that, but the hardware description is quite clear.

The dt-binding that is in this series specifies that the pll clock
controller is a child of the syscon:
https://lore.kernel.org/linux-riscv/20230512022036.97987-1-xingyu...@starfivetech.com/T/#Z2e.:..:20230512022036.97987-6-xingyu.wu::40starfivetech.com:1soc:starfive:starfive::2cjh7110-syscon.yaml

That seems correct to me & U-Boot's devicetree is not compliant.

> > > >> > These defines/numbers appear in the dts and are part of the DT
> > > >> > ABI. The same dts is supposed to work for Linux & U-Boot.
> > > >> 
> > > >> The JH7110 has 6 blocks of 64k iomem in that functional area:
> > > >> {SYS,STG,AON} x {CRG,SYSCON}. None of these has 190 clocks.
> > > >> The good news: the current DTS, as proposed here and in U-Boot
> > > >> master, provides nodes for all 6 entities. The bad news is that
> > > >> the clock assignments to those nodes and their numbering is
> > > >> messed up.
> > > >> 
> > > >> AFAICT PLL{0,1,2} _are_ generated in SYS_SYSCON and thus U-Boot
> > > >> gets it wrong, in addition to the erroneous DTS.
> > > > 
> > > > The numbers are kinda hocus-pocus anyway, they are just made up
> > > > since the clock numbering usually isn't something with a nice TRM
> > > > to go and reference (unlike interrupts which usually are
> > > > documented in that way). It is very helpful to make them aligned
> > > > some register/bit positions or, but that is not required.
> > > > IOW U-Boot is not wrong per se to use 190 instead of 0, but it is
> > > > wrong to have different numbers in both places.
> 
> U-Boot reuses the Common Clock Framework from Linux, and I'm not sure
> whether the clock IDs need to be unique in order for the appropriate
> clock to be found.

Unique within the clock controller, otherwise it is impossible to tell
the difference between <&cctrl 1> and <&cctrl 1> apart! (The same
follows even with increased #clock-cells, something must be unique).
That's besides the point of this particular issue though.

> But that would be the only restriction, if it
> applies. Even then, each driver could register a clock with its own,
> arbitrarily chosen base offset with the CCF, so each CRG unit could
> still have its own clocks enumerated starting with 0 in the DTB.
> 
> > > > It sounds like you're saying that (and I have not looked) the
> > > > U-Boot dts actually has structural difference w.r.t. what
> > > > provides which clock? If so, that'll need to be fixed
> > > > independently of the numbering problem.
> 
> > > 
> > > Oh, unfortunately, the 7110 can not support to mix the uboot dtb
> > > and linux dtb up.
> > 
> > What does "cannot support" mean? It's normal and desirable for the
> 
> IMHO "desirable" is too weak.

Yeah, agreed. I just don't like being prescriptive about what happens in
projects that I do not maintain things for I guess.

> > same dtb to be usable for both. The Linux kernel's dt-bindings are
> > used for multiple projects, not just Linux - it'd be silly for
> > U-Boot, FreeBSD etc etc to go off and each have their open set of
> > (incompatible) bindings.
> > 
> > > If boot the Linux and should use the linux dtb instead of the uboot
> > > dtb. Because all clock ids and reset ids in Linux and Uboot are
> > > different include PLL, and some modules can work in Linux but not
> > > in uboot.
> [...]
> > 
> > > I suggest to boot Linux with its own linux dtb.
> 
> This is a fragile band-aid, to be used only as a last resort. It
> creates more problems than it solves. Your DTB will then match your
> kernel, but whether it 

rk3328: No partition table found issue

[Belisko Marek]

Hi,

I'm using 2022.01 on rockpi-e and having an issue that some SDcards cannot
seem to have issue with accessing partitions. I have the same image flashed
on 2 SD cards. One boots fine and other one shows:

## Executing script at 0050
Saving Environment to MMC... Writing to redundant MMC(1)... OK
** No partition table - mmc 1 **

whole log:
U-Boot 2022.01 (Jan 10 2022 - 18:46:34 +)

Model: Radxa ROCK Pi E
DRAM:  510 MiB
PMIC:  RK8050 (on=0x40, off=0x00)
MMC:   mmc@ff50: 1, mmc@ff52: 0
Loading Environment from MMC... *** Warning - bad CRC, using default
environment

In:serial@ff13
Out:   serial@ff13
Err:   serial@ff13
Model: Radxa ROCK Pi E
Net:   Could not get PHY for ethernet@ff54: addr -1
No ethernet found.

Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found U-Boot script /boot.scr
355 bytes read in 3 ms (115.2 KiB/s)
## Executing script at 0050
Saving Environment to MMC... Writing to redundant MMC(1)... OK
** No partition table - mmc 1 **
Couldn't find partition mmc 1:2
Can't set block device
Wrong Image Format for bootm command

Is there maybe in newer u-boot some fix for this problem?

Thanks and BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

[PATCH 0/4] riscv: Initial support for Lichee PI 4A board

[Yixun Lan]

Sipeed's Lichee PI 4A board is based on T-HEAD's TH1520 SoC which consists of
quad core XuanTie C910 CPU, plus one C906 CPU and one E902 CPU.

In this series, the UART, basic device tree, CPU, PLIC are enabled, making it
capable of running in serial console mode.

Please note that, we rely on pre shipped vendor u-boot which run in M-Mode to
chain load this mainline u-boot either via eMMC storage or from tftp, thus the
pinctrl and clock setting are not implemented in this series, which certainly
can be improved later accordingly.

Also the device tree is coming from kernel which is submitted by Jisheng Zhang 
in
his patch V2 [1], it's still under review, so may change in the future.


[1] https://lore.kernel.org/all/20230518184541.2627-1-jszh...@kernel.org

Yixun Lan (4):
  riscv: t-head: licheepi4a: initial support added
  riscv: dts: t-head: Add basic device tree for Sipeed Lichee PI 4A
board
  configs: th1520_lpi4a_defconfig: Add initial config
  doc: t-head: lpi4a: document Lichee PI 4A board

 arch/riscv/Kconfig  |   5 +
 arch/riscv/dts/Makefile |   1 +
 arch/riscv/dts/th1520-lichee-module-4a.dtsi |  34 ++
 arch/riscv/dts/th1520-lichee-pi-4a.dts  |  32 ++
 arch/riscv/dts/th1520.dtsi  | 435 
 board/thead/th1520_lpi4a/Kconfig|  42 ++
 board/thead/th1520_lpi4a/MAINTAINERS|   7 +
 board/thead/th1520_lpi4a/Makefile   |   5 +
 board/thead/th1520_lpi4a/board.c|  14 +
 configs/th1520_lpi4a_defconfig  |  82 
 doc/board/index.rst |   1 +
 doc/board/thead/index.rst   |   9 +
 doc/board/thead/lpi4a.rst   | 112 +
 include/configs/th1520_lpi4a.h  |  22 +
 14 files changed, 801 insertions(+)
 create mode 100644 arch/riscv/dts/th1520-lichee-module-4a.dtsi
 create mode 100644 arch/riscv/dts/th1520-lichee-pi-4a.dts
 create mode 100644 arch/riscv/dts/th1520.dtsi
 create mode 100644 board/thead/th1520_lpi4a/Kconfig
 create mode 100644 board/thead/th1520_lpi4a/MAINTAINERS
 create mode 100644 board/thead/th1520_lpi4a/Makefile
 create mode 100644 board/thead/th1520_lpi4a/board.c
 create mode 100644 configs/th1520_lpi4a_defconfig
 create mode 100644 doc/board/thead/index.rst
 create mode 100644 doc/board/thead/lpi4a.rst
 create mode 100644 include/configs/th1520_lpi4a.h

-- 
2.40.0

Re: [RFC PATCH 08/17] sunxi: introduce NCAT2 generation model

[Andre Przywara]

On Thu, 25 May 2023 21:25:57 +0300
Maksim Kiselev  wrote:

Hi Maksim,

> Could you please include this fix for i2c in the next version of this 
> series.
> 
> diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
> index 93bbc6916e..d088ea75b9 100644
> --- a/drivers/i2c/mvtwsi.c
> +++ b/drivers/i2c/mvtwsi.c
> @@ -124,7 +124,7 @@ enum mvtwsi_ctrl_register_fields {
>    * on other platforms, it is a normal r/w bit, which is cleared by 
> writing 0.
>    */
> 
> -#if defined(CONFIG_SUNXI_GEN_SUN6I) || defined(CONFIG_SUN50I_GEN_H6)
> +#if defined(CONFIG_SUNXI_GEN_SUN6I) || defined(CONFIG_SUN50I_GEN_H6) || 
> defined(CONFIG_SUNXI_GEN_NCAT2)

Ah, thanks for pointing this out, I never really tried I2C, I think.
So those code lines are of course hideous to begin with, but it's a
nightmare to fix this properly (by looking at the DT compatible
string), and we might need it for the SPL anyway, so would need
something like this anyway.
So I will just go ahead and add this to this patch.

Thanks for the report!

Cheers,
Andre

>   #define    MVTWSI_CONTROL_CLEAR_IFLG   0x0008
>   #else
>   #define    MVTWSI_CONTROL_CLEAR_IFLG   0x
> 

Re: [RFC PATCH 10/17] clk: sunxi: Add support for the D1 CCU

[Andre Przywara]

On Thu, 25 May 2023 18:34:45 -0600
Sam Edwards  wrote:

Hi Sam,

thanks for staying on this!

> On 12/5/22 17:45, Andre Przywara wrote:
> > +static struct ccu_clk_gate d1_gates[] = {
> > +   [CLK_BUS_MMC0]  = GATE(0x84c, BIT(0)),
> > +   [CLK_BUS_MMC1]  = GATE(0x84c, BIT(1)),
> > +   [CLK_BUS_MMC2]  = GATE(0x84c, BIT(2)),
> > +   [CLK_BUS_UART0] = GATE(0x90c, BIT(0)),
> > +   [CLK_BUS_UART1] = GATE(0x90c, BIT(1)),
> > +   [CLK_BUS_UART2] = GATE(0x90c, BIT(2)),
> > +   [CLK_BUS_UART3] = GATE(0x90c, BIT(3)),
> > +   [CLK_BUS_UART4] = GATE(0x90c, BIT(4)),
> > +   [CLK_BUS_UART5] = GATE(0x90c, BIT(5)),
> > +   [CLK_BUS_I2C0]  = GATE(0x91c, BIT(0)),
> > +   [CLK_BUS_I2C1]  = GATE(0x91c, BIT(1)),
> > +   [CLK_BUS_I2C2]  = GATE(0x91c, BIT(2)),
> > +   [CLK_BUS_I2C3]  = GATE(0x91c, BIT(3)),
> > +   [CLK_SPI0]  = GATE(0x940, BIT(31)),
> > +   [CLK_SPI1]  = GATE(0x944, BIT(31)),
> > +   [CLK_BUS_SPI0]  = GATE(0x96c, BIT(0)),
> > +   [CLK_BUS_SPI1]  = GATE(0x96c, BIT(1)),
> > +
> > +   [CLK_BUS_EMAC]  = GATE(0x97c, BIT(0)),
> > +
> > +   [CLK_USB_OHCI0] = GATE(0xa70, BIT(31)),
> > +   [CLK_USB_OHCI1] = GATE(0xa74, BIT(31)),
> > +   [CLK_BUS_OHCI0] = GATE(0xa8c, BIT(0)),
> > +   [CLK_BUS_OHCI1] = GATE(0xa8c, BIT(1)),
> > +   [CLK_BUS_EHCI0] = GATE(0xa8c, BIT(4)),
> > +   [CLK_BUS_EHCI1] = GATE(0xa8c, BIT(5)),
> > +   [CLK_BUS_OTG]   = GATE(0xa8c, BIT(8)),
> > +   [CLK_BUS_LRADC] = GATE(0xa9c, BIT(0)),
> > +
> > +   [CLK_RISCV] = GATE(0xd04, BIT(31)),
> > +};  
> 
> Would it be reasonable to add (possibly one for APB1 also):
> [CLK_APB0] = GATE_DUMMY,
> 
> ...in order to suppress this warning at init:
> sunxi_set_gate: (CLK#24) unhandled

Yeah, seems like we are working in lockstep, as I found and fixed the
very same issue in the very same way on Wednesday ;-)

> As I understand it, CLK_APB0 is only for speed control and doesn't have 
> a gate, but since the FDT references it, other drivers are asking the 
> clock driver to ungate it, resulting in that (safe-to-ignore) warning.

The APB0 bus transports register accesses to a certain subset of "low
speed" peripherals, Those peripherals include the clock control unit
(CCU) itself, and the GPIO registers, so it's quite essential for
normal operation. CLK_APB0 is the clock driving that bus, and as it's
controlled via the CCU, you just cannot turn that off. Check "Figure
3-3 System bus tree" in the manual.

Linux never really touches that clock (for said reasons), and Allwinner
recommends a certain frequency, which we set up in the SPL.

So to not boil the ocean here for something that doesn't need control
anyway, we just introduced those "dummy gates", to appease U-Boot's
clock framework and avoid that warning.

Long story short: you did everything right ;-)

> PS: Do you have any plans for PSCI support, so we can get the second 
> core up too? I'd like to patch that in and include it in your series 
> once my available time permits. Just thought I'd check that you/someone 
> wasn't working on it already. :)

I checked the manuals, and it seems the required bits are documented,
but IIRC they differ from the other (much older) 32-bit parts. So it
would require some refactoring of the existing sunxi PSCI code to
accommodate the T113.
That's not really a problem, but I didn't find time yet to tackle this,
so if you want to beat me on it: be my guest.
For the basic operation SMP is not essential, so I don't want to let
that hold back the T113 U-Boot support in general. The plan is to have
an extra patch on top for PSCI, and merge that when it's ready - which
could be together with the basic support, if we get it done on time.

Cheers,
Andre

Re: Fit Signature booting without public key

[Manorit Chawdhry]

Hi Tom,

On 10:05-20230525, Tom Rini wrote:
> On Thu, May 25, 2023 at 11:21:44AM +0530, Manorit Chawdhry wrote:
> > Hi Tom,
> > 
> > On 11:30-20230516, Tom Rini wrote:
> > > On Tue, May 16, 2023 at 12:11:24PM +0530, Manorit Chawdhry wrote:
> > > 
> > > > Hi All,
> > > > 
> > > > I recently came upon a discussion that had happened a while back [0].
> > > > I want to continue the discussion as I believe the issue still persists
> > > > and the checks around fit signature booting are still the same, that
> > > > allows booting the fit without changing the uboot dtb.
> > > > 
> > > > Allowing the signed fit image without this seems to be a bypass that is
> > > > available and should not be allowed without any gate to it for people
> > > > who'd like to enforce these signing checks. Let me know if there is a
> > > > config already available for it and if not, are there any plans to
> > > > enable such a config in future. Would like to hear your opinions on
> > > > this as I believe this should be fixed as soon as possible.
> > > > 
> > > > [0]: 
> > > > https://u-boot.denx.narkive.com/dEClg9dW/signed-fit-image-boots-without-public-key
> > > 
> > > Yes, can you please reproduce the issue in question on the current tree,
> > > with a supported platform and provide the defconfig and steps you used
> > > for this issue? Thanks.
> > > 
> > > -- 
> > 
> > I've created a branch with some custom patches to make the fitimage
> > booting currently, please try with the branch and the fitimage that are
> > also committed [0].
> > 
> > The devices that I've tested this with is j721e-hs-evm, the defconfig to
> > use for the builds are j721e_evm_r5_defconfig and
> > j721e_evm_a72_defconfig. Although not synced up with the latest changes
> > but for reference the SDK documentation can help if required [1].
> > 
> > Attached the logs for reference with the signed fitimage and an unsigned
> > uboot without any modifications[2].
> > 
> > [0]: https://github.com/manorit2001/u-boot/tree/fit-image-poc
> > [1]: 
> > https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacinto7/08_06_00_11/exports/docs/linux/Foundational_Components/U-Boot/UG-General-Info.html
> > [2]: https://gist.github.com/manorit2001/3c49cfc19bf937783efb75fd4cddc58f
> 
> I don't see the problem there, but please go and investigate what
> problem you're seeing.  The intention is that yes, with the appropriate
> CONFIG settings, you can set U-Boot to only boot signed FIT
> configurations and unsigned ones should not boot.
> 

It boots with an unsigned fit too btw for reference [0]. The whole
logic behind the authentication is that uboot stores the public key that
is used for verification of the signed fit but apparantely if I haven't
kept the public key in uboot dtb the fit images still boot whether
signed or unsigned as that check is not guarded by anything if you see
in the codebase[1].

[0]: https://gist.github.com/manorit2001/80c9242641141ac5bce0e335ea8a9f1a
[1]: 
https://github.com/u-boot/u-boot/blob/6dcee70692601bd3296c86ac07d0317bf06d2b7b/boot/image-fit-sig.c#L491-L496

Regards,
Manorit

> -- 
> Tom

Re: [PATCH v4 3/3] Load option with short device path for boot vars

[Ilias Apalodimas]

On Fri, 26 May 2023 at 09:30, Heinrich Schuchardt  wrote:
>
> On 5/25/23 09:12, Ilias Apalodimas wrote:
> > Hi Raymond,
> >
> > On Tue, May 23, 2023 at 12:18:22PM -0700, Raymond Mao wrote:
> >> The boot variables automatically generated for removable medias
> >> should be with short form of device path without device nodes.
> >> This is a requirement for the case that a removable media is
> >> plugged into a different port but is still able to work with the
> >> existing boot variables.
> >>
> >> Signed-off-by: Raymond Mao 
> >> ---
> >> Changes in v2
> >> - Ignore EFI_NOT_FOUND returned from
> >>efi_bootmgr_update_media_device_boot_option which means no boot
> >>options scanned.
> >> Changes in v3
> >> - Split the patch into moving and renaming functions and
> >>individual patches for each changed functionality
> >> Changes in v4
> >> - Revert the change of introducing a bool parameter when updating
> >>the boot option. Use short-form of device path by default
> >>
> >>   lib/efi_loader/efi_bootmgr.c | 5 +
> >>   1 file changed, 5 insertions(+)
> >>
> >> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> >> index c329428973..336b9d2d8f 100644
> >> --- a/lib/efi_loader/efi_bootmgr.c
> >> +++ b/lib/efi_loader/efi_bootmgr.c
> >> @@ -387,6 +387,11 @@ static efi_status_t 
> >> efi_bootmgr_enumerate_boot_option(struct eficonfig_media_boo
> >>  p = dev_name;
> >>  utf8_utf16_strncpy(&p, buf, strlen(buf));
>
> At this point of the code device_path contains the device-path of a
> device with a simple file protocol.
>
> >>
> >> +/* use short form device path */
> >> +device_path = efi_dp_shorten(device_path);
> >> +if (!device_path)
> >
> > One nit here.  I think we should print a warning if shortening the path
> > fails.  Heinrich are you ok with this?  I think not falling back and adding
> > the long form DP is fine.
>
> efi_dp_shorten() returns NULL if the device-path contains neither of
> - a USB WWI node
> - a hard drive node, HD()
> - a file path node
>
> Why should we skip a device with a simple file protocol here if it does
> not contain one of the above nodes?

Ah fair enough  I missed that on efi_dp_shorten().  We should just add
the original device path.

Thanks
/Ilias

Thanks
/Lias
>
> Best regards
>
> Heinrich
>
> >
> > Thanks
> > /Ilias
> >> +continue;
> >> +
> >>  lo.label = dev_name;
> >>  lo.attributes = LOAD_OPTION_ACTIVE;
> >>  lo.file_path = device_path;
> >> --
> >> 2.25.1
> >>
>

Re: [PATCH v4 00/11] Add ethernet driver for StarFive JH7110 SoC

[Torsten Duwe]

On Thu, 25 May 2023 17:36:26 +0800
Yanhong Wang  wrote:
[...]
> The main difference between StarFive VisionFive 2 1.2A and 1.3B is 
> gmac, but the difference in gmac is not defined in DT, but reads the 
> PCB version from EEPROM, and then dynamically configures the
> difference of gmac according to different PCB versions, which is
> compatible with 1.2A and 1.3B versions, which is more user-friendly.

Big ACK from me so far, it is overdue to clean the duplication mess that
is currently in master.

> The PHY and MAC driver has been tested on the StarFive VisionFive 2
> 1.2A and 1.3B boards and works normally.

But for a complete test I'd like to see the respectively correct DTB
passed to the OS, and that requires the other issue (base / clock
support and single DT) to be resolved first.

Thanks!

Torsten

Re: [PATCH v4 1/7] dt-bindings: clock: Add StarFive JH7110 PLL clock generator

[Torsten Duwe]

On Wed, 24 May 2023 11:19:48 +0100
Conor Dooley  wrote:

> On Wed, May 24, 2023 at 05:00:02PM +0800, Xingyu Wu wrote:
> > On 2023/5/23 19:28, Conor Dooley wrote:
> > > On Tue, May 23, 2023 at 01:10:06PM +0200, Torsten Duwe wrote:
> > >> On Tue, 23 May 2023 09:28:39 +0100
> > >> Conor Dooley  wrote:
> > >> 
> > >> > On Tue, May 23, 2023 at 10:56:43AM +0800, Xingyu Wu wrote:
> > >> > > On 2023/5/19 22:16, Conor Dooley wrote:
> > >> > > > On Fri, May 19, 2023 at 03:57:33PM +0200, Torsten Duwe
> > >> > > > wrote:
> > >> > > >> On Fri, May 12, 2023 at 10:20:30AM +0800, Xingyu Wu wrote:
[...]

> > >> > > Because PLL driver is separated from SYSCRG drivers in
> > >> > > Linux, the numbering starts from 0. But in Uboot, the PLL
> > >> > > driver is included in the SYSCRG driver, and the number
> > >> > > follows the SYSCRG.
> > >> > 
> > >> > Unfortunately, how you choose to construct your drivers has
> > >> > nothing to do with this.

Exactly. As I wrote (quote below), the PLLx frequencies are controlled
by the I/O block SYS_SYSCON (starting there at offset 0x18), according
to the public datasheets. All(?) other clocks are derived from those in
the *_CRG units. That *is* the hardware to be described, in *the* (one
and only!) DT. U-Boot, and any OS, are free to reorganise their driver
framework around that, but the hardware description is quite clear.

> > >> > These defines/numbers appear in the dts and are part of the DT
> > >> > ABI. The same dts is supposed to work for Linux & U-Boot.
> > >> 
> > >> The JH7110 has 6 blocks of 64k iomem in that functional area:
> > >> {SYS,STG,AON} x {CRG,SYSCON}. None of these has 190 clocks.
> > >> The good news: the current DTS, as proposed here and in U-Boot
> > >> master, provides nodes for all 6 entities. The bad news is that
> > >> the clock assignments to those nodes and their numbering is
> > >> messed up.
> > >> 
> > >> AFAICT PLL{0,1,2} _are_ generated in SYS_SYSCON and thus U-Boot
> > >> gets it wrong, in addition to the erroneous DTS.
> > > 
> > > The numbers are kinda hocus-pocus anyway, they are just made up
> > > since the clock numbering usually isn't something with a nice TRM
> > > to go and reference (unlike interrupts which usually are
> > > documented in that way). It is very helpful to make them aligned
> > > some register/bit positions or, but that is not required.
> > > IOW U-Boot is not wrong per se to use 190 instead of 0, but it is
> > > wrong to have different numbers in both places.

U-Boot reuses the Common Clock Framework from Linux, and I'm not sure
whether the clock IDs need to be unique in order for the appropriate
clock to be found. But that would be the only restriction, if it
applies. Even then, each driver could register a clock with its own,
arbitrarily chosen base offset with the CCF, so each CRG unit could
still have its own clocks enumerated starting with 0 in the DTB.

> > > It sounds like you're saying that (and I have not looked) the
> > > U-Boot dts actually has structural difference w.r.t. what
> > > provides which clock? If so, that'll need to be fixed
> > > independently of the numbering problem.

> > 
> > Oh, unfortunately, the 7110 can not support to mix the uboot dtb
> > and linux dtb up.
> 
> What does "cannot support" mean? It's normal and desirable for the

IMHO "desirable" is too weak.

> same dtb to be usable for both. The Linux kernel's dt-bindings are
> used for multiple projects, not just Linux - it'd be silly for
> U-Boot, FreeBSD etc etc to go off and each have their open set of
> (incompatible) bindings.
> 
> > If boot the Linux and should use the linux dtb instead of the uboot
> > dtb. Because all clock ids and reset ids in Linux and Uboot are
> > different include PLL, and some modules can work in Linux but not
> > in uboot.
[...]
> 
> > I suggest to boot Linux with its own linux dtb.

This is a fragile band-aid, to be used only as a last resort. It
creates more problems than it solves. Your DTB will then match your
kernel, but whether it describes the actual hardware is a game of
chance. Doesn't the VisionFive2 have an RPi connector... ?

One of the IMO few valid use cases of adding a DTB to the kernel
at boot is OpenWRT, when you build an OS Image for a particular piece
of hardware you have at hand.

> I suggest to make sure that you can use the same dtb for both.

Interestingly enough, U-Boot already has the PLL driver in a separate
file. I have a half-baked patch here that moves the sys_syscon DT
matching into that file...

Torsten

Re: [PATCH v5 2/3] Boot var automatic management for removable medias

[Heinrich Schuchardt]

On 5/26/23 00:04, Raymond Mao wrote:

Changes for complying to EFI spec §3.5.1.1
'Removable Media Boot Behavior'.
Boot variables can be automatically generated during a removable
media is probed. At the same time, unused boot variables will be
detected and removed.

Signed-off-by: Raymond Mao 
---
Changes in v2
- Ignore EFI_NOT_FOUND returned from
   efi_bootmgr_update_media_device_boot_option which means no boot
   options scanned.
Changes in v3
- Split the patch into moving and renaming functions and
   individual patches for each changed functionality
Changes in v4
- Revert the change of introducing a bool parameter when updating
   the boot option. Use short-form of device path by default
Changes in v5
- Move function call of efi_bootmgr_update_media_device_boot_option()
   from efi_init_variables() to efi_init_obj_list()
- Add warning log when a short-form device path doesn't exist


This change history does not reflect this patch. Please, describe
overall changes in the cover-letter and individual changes in the
respective patch.



  lib/efi_loader/efi_disk.c | 7 +++
  lib/efi_loader/efi_setup.c| 5 +
  lib/efi_loader/efi_variable.c | 1 -
  3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index d2256713a8..ca5f07f2ec 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -687,6 +687,13 @@ int efi_disk_probe(void *ctx, struct event *event)
return -1;
}

+   /* only do the boot option management when UEFI sub-system is 
initialized */
+   if (efi_obj_list_initialized == EFI_SUCCESS) {
+   ret = efi_bootmgr_update_media_device_boot_option();
+   if (ret != EFI_SUCCESS && ret != EFI_NOT_FOUND)
+   return -1;
+   }
+
return 0;
  }

diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index 58d4e13402..4686374995 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -245,6 +245,11 @@ efi_status_t efi_init_obj_list(void)
if (ret != EFI_SUCCESS)
goto out;

+   /* update boot option after variable service initialized */
+   ret = efi_bootmgr_update_media_device_boot_option();
+   if (ret != EFI_SUCCESS && ret != EFI_NOT_FOUND)
+   goto out;
+
/* Define supported languages */
ret = efi_init_platform_lang();
if (ret != EFI_SUCCESS)
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index be95ed44e6..1529fffd1d 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -476,6 +476,5 @@ efi_status_t efi_init_variables(void)
log_err("Invalid EFI variable seed\n");
}

-


Please, avoid unrelated changes.

Best regards

Heinrich


return efi_init_secure_state();
  }

Re: [PATCH v5 3/3] Load option with short device path for boot vars

[Heinrich Schuchardt]

On 5/26/23 00:04, Raymond Mao wrote:

The boot variables automatically generated for removable medias
should be with short form of device path without device nodes.
This is a requirement for the case that a removable media is
plugged into a different port but is still able to work with the
existing boot variables.

Signed-off-by: Raymond Mao 
---
Changes in v2
- Ignore EFI_NOT_FOUND returned from
   efi_bootmgr_update_media_device_boot_option which means no boot
   options scanned.
Changes in v3
- Split the patch into moving and renaming functions and
   individual patches for each changed functionality
Changes in v4
- Revert the change of introducing a bool parameter when updating
   the boot option. Use short-form of device path by default
Changes in v5
- Move function call of efi_bootmgr_update_media_device_boot_option()
   from efi_init_variables() to efi_init_obj_list()
- Add warning log when a short-form device path doesn't exist

  lib/efi_loader/efi_bootmgr.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index c329428973..67e833141f 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -387,6 +387,13 @@ static efi_status_t 
efi_bootmgr_enumerate_boot_option(struct eficonfig_media_boo
p = dev_name;
utf8_utf16_strncpy(&p, buf, strlen(buf));

+   /* use short form device path */
+   device_path = efi_dp_shorten(device_path);
+   if (!device_path) {
+   log_warning("No short-form device path for device %s, skip 
it\n", buf);
+   continue;


efi_dp_shorten() returns NULL if the device-path contains neither of
- a USB WWI node
- a hard drive node, HD()
- a file path node

Why should we skip a device with a simple file protocol here if it does
not contain one of the above nodes?

The warning makes no sense at all.

Best regards

Heinrich


+   }
+
lo.label = dev_name;
lo.attributes = LOAD_OPTION_ACTIVE;
lo.file_path = device_path;

Re: [PATCH v5 1/3] Move bootorder and bootoption apis to lib

[Heinrich Schuchardt]

On 5/26/23 00:04, Raymond Mao wrote:

Rename and move bootorder and bootoption apis from cmd to lib
for re-use between eficonfig and bootmgr

Signed-off-by: Raymond Mao 


The commit message says that this patch does not change the code!
But there are code changes, e.g.

<   for (i = 0; i < count; i++)
<   free(opt[i].lo);
---
>   for (i = 0; i < count; i++) {
>   if (opt[i].lo)
>   free(opt[i].lo);
>   }

Please, provide a patch that only renames and moves the functions as
indicated in the commit message. Please, avoid reformatting as that
makes checking the diff hard.

Besides, the 'if' that you introduced is superfluous as free() already
checks for NULL.


---
Changes in v2
- Ignore EFI_NOT_FOUND returned from
   efi_bootmgr_update_media_device_boot_option which means no boot
   options scanned.
Changes in v3
- Split the patch into moving and renaming functions and
   individual patches for each changed functionality
Changes in v4
- Revert the change of introducing a bool parameter when updating
   the boot option. Use short-form of device path by default
Changes in v5
- Move function call of efi_bootmgr_update_media_device_boot_option()
   from efi_init_variables() to efi_init_obj_list()
- Add warning log when a short-form device path doesn't exist


This change history does not match changes in patch 1/3. Please, use a
cover-letter to describe the series and overall changes.



  cmd/bootmenu.c   |   2 +-
  cmd/eficonfig.c  | 408 +--
  include/efi_config.h |   5 -
  include/efi_loader.h |  11 +
  lib/efi_loader/efi_bootmgr.c | 380 
  lib/efi_loader/efi_helper.c  |  25 +++
  6 files changed, 423 insertions(+), 408 deletions(-)

diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
index 6baeedc69f..01daddca7b 100644
--- a/cmd/bootmenu.c
+++ b/cmd/bootmenu.c
@@ -351,7 +351,7 @@ static struct bootmenu_data *bootmenu_create(int delay)
 * UEFI specification requires booting from removal media using
 * a architecture-specific default image name such as 
BOOTAA64.EFI.
 */
-   efi_ret = eficonfig_generate_media_device_boot_option();
+   efi_ret = efi_bootmgr_update_media_device_boot_option();
if (efi_ret != EFI_SUCCESS && efi_ret != EFI_NOT_FOUND)
goto cleanup;

diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
index 720f52b48b..82a80306f4 100644
--- a/cmd/eficonfig.c
+++ b/cmd/eficonfig.c
@@ -1134,43 +1134,6 @@ out:
return ret;
  }

-/**
- * eficonfig_get_unused_bootoption() - get unused "Boot" index
- *
- * @buf:   pointer to the buffer to store boot option variable name
- * @buf_size:  buffer size
- * @index: pointer to store the index in the BootOrder variable
- * Return: status code
- */
-efi_status_t eficonfig_get_unused_bootoption(u16 *buf, efi_uintn_t buf_size,
-unsigned int *index)
-{
-   u32 i;
-   efi_status_t ret;
-   efi_uintn_t size;
-
-   if (buf_size < u16_strsize(u"Boot"))
-   return EFI_BUFFER_TOO_SMALL;
-
-   for (i = 0; i <= 0x; i++) {
-   size = 0;
-   efi_create_indexed_name(buf, buf_size, "Boot", i);
-   ret = efi_get_variable_int(buf, &efi_global_variable_guid,
-  NULL, &size, NULL, NULL);
-   if (ret == EFI_BUFFER_TOO_SMALL)
-   continue;
-   else
-   break;
-   }
-
-   if (i > 0x)
-   return EFI_OUT_OF_RESOURCES;
-
-   *index = i;
-
-   return EFI_SUCCESS;
-}
-
  /**
   * eficonfig_set_boot_option() - set boot option
   *
@@ -1208,46 +1171,6 @@ static efi_status_t eficonfig_set_boot_option(u16 
*varname, struct efi_device_pa
return ret;
  }

-/**
- * eficonfig_append_bootorder() - append new boot option in BootOrder variable
- *
- * @index: "Boot" index to append to BootOrder variable
- * Return: status code
- */
-efi_status_t eficonfig_append_bootorder(u16 index)
-{
-   u16 *bootorder;
-   efi_status_t ret;
-   u16 *new_bootorder = NULL;
-   efi_uintn_t last, size, new_size;
-
-   /* append new boot option */
-   bootorder = efi_get_var(u"BootOrder", &efi_global_variable_guid, &size);
-   last = size / sizeof(u16);
-   new_size = size + sizeof(u16);
-   new_bootorder = calloc(1, new_size);
-   if (!new_bootorder) {
-   ret = EFI_OUT_OF_RESOURCES;
-   goto out;
-   }
-   memcpy(new_bootorder, bootorder, size);
-   new_bootorder[last] = index;
-
-   ret = efi_set_variable_int(u"BootOrder", &efi_global_variable_guid,
-  EFI_VARIABLE_NON_VOLATILE |
-  

Re: [PATCH v2] PCI: zynqmp: Add ZynqMP NWL PCIe root port driver

[Stefan Roese]

Hi Michal,

On 5/25/23 17:53, Michal Simek wrote:



On 5/25/23 11:49, Stefan Roese wrote:

This patch adds the PCIe controller driver for the Xilinx / AMD ZynqMP
NWL PCIe Bridge as root port. The driver source is partly copied from
the Linux PCI driver and modified to enable usage in U-Boot (e.g.
simplified and interrupt support removed).

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
Cc: Pali Rohár 
Cc: Bin Meng 
Cc: Michal Simek 
---
v2:
- Remove some unused members from struct nwl_pcie
- Fix usage of dev_seq() in nwl_pcie_config_address()
- Remove writing to PCI_PRIMARY_BUS reg as this is done by the
   common U-Boot PCI code later

  MAINTAINERS   |   1 +
  drivers/pci/Kconfig   |   7 +
  drivers/pci/Makefile  |   1 +
  drivers/pci/pcie-xilinx-nwl.c | 352 ++
  4 files changed, 361 insertions(+)
  create mode 100644 drivers/pci/pcie-xilinx-nwl.c


Tested-by: Michal Simek 
Acked-by: Michal Simek 


Thanks for testing.


I am happy to take this via my tree if you like.


Please do so.

We should also enable this driver by default in 
xilinx_zynqmp_virt_defconfig and likely any pcie driver to be able to 
test it.


Perfect. Please do this.


I used e1000 based card and it works as expected.


Good.

Thanks,
Stefan

Re: [PATCH v4 1/3] Move bootorder and bootoption apis to lib

[Heinrich Schuchardt]

On 5/23/23 21:18, Raymond Mao wrote:

Rename and move bootorder and bootoption apis from cmd to lib
for re-use between eficonfig and bootmgr

Signed-off-by: Raymond Mao 


The commit message says that this patch does not change the code!
But there are code changes, e.g.

<   for (i = 0; i < count; i++)
<   free(opt[i].lo);
---
>   for (i = 0; i < count; i++) {
>   if (opt[i].lo)
>   free(opt[i].lo);
>   }

Please, provide a patch that only renames and moves the functions as
indicated in the commit message. Please, avoid reformatting as that
makes checking the diff hard.

Besides, the 'if' that you introduced is superfluous as free() already
checks for NULL.


---
Changes in v2
- Ignore EFI_NOT_FOUND returned from
   efi_bootmgr_update_media_device_boot_option which means no boot
   options scanned.
Changes in v3
- Split the patch into moving and renaming functions and
   individual patches for each changed functionality
Changes in v4
- Revert the change of introducing a bool parameter when updating
   the boot option. Use short-form of device path by default


Is this really a change in this patch?

Using a cover-letter for the overall description would be helpful for
future submissions.

git format-patch --cover-letter

Another comment below.



  cmd/bootmenu.c   |   2 +-
  cmd/eficonfig.c  | 408 +--
  include/efi_config.h |   5 -
  include/efi_loader.h |  11 +
  lib/efi_loader/efi_bootmgr.c | 380 
  lib/efi_loader/efi_helper.c  |  25 +++
  6 files changed, 423 insertions(+), 408 deletions(-)

diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
index 6baeedc69f..01daddca7b 100644
--- a/cmd/bootmenu.c
+++ b/cmd/bootmenu.c
@@ -351,7 +351,7 @@ static struct bootmenu_data *bootmenu_create(int delay)
 * UEFI specification requires booting from removal media using
 * a architecture-specific default image name such as 
BOOTAA64.EFI.
 */
-   efi_ret = eficonfig_generate_media_device_boot_option();
+   efi_ret = efi_bootmgr_update_media_device_boot_option();
if (efi_ret != EFI_SUCCESS && efi_ret != EFI_NOT_FOUND)
goto cleanup;

diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
index 720f52b48b..82a80306f4 100644
--- a/cmd/eficonfig.c
+++ b/cmd/eficonfig.c
@@ -1134,43 +1134,6 @@ out:
return ret;
  }

-/**
- * eficonfig_get_unused_bootoption() - get unused "Boot" index
- *
- * @buf:   pointer to the buffer to store boot option variable name
- * @buf_size:  buffer size
- * @index: pointer to store the index in the BootOrder variable
- * Return: status code
- */
-efi_status_t eficonfig_get_unused_bootoption(u16 *buf, efi_uintn_t buf_size,
-unsigned int *index)
-{
-   u32 i;
-   efi_status_t ret;
-   efi_uintn_t size;
-
-   if (buf_size < u16_strsize(u"Boot"))
-   return EFI_BUFFER_TOO_SMALL;
-
-   for (i = 0; i <= 0x; i++) {
-   size = 0;
-   efi_create_indexed_name(buf, buf_size, "Boot", i);
-   ret = efi_get_variable_int(buf, &efi_global_variable_guid,
-  NULL, &size, NULL, NULL);
-   if (ret == EFI_BUFFER_TOO_SMALL)
-   continue;
-   else
-   break;
-   }
-
-   if (i > 0x)
-   return EFI_OUT_OF_RESOURCES;
-
-   *index = i;
-
-   return EFI_SUCCESS;
-}
-
  /**
   * eficonfig_set_boot_option() - set boot option
   *
@@ -1208,46 +1171,6 @@ static efi_status_t eficonfig_set_boot_option(u16 
*varname, struct efi_device_pa
return ret;
  }

-/**
- * eficonfig_append_bootorder() - append new boot option in BootOrder variable
- *
- * @index: "Boot" index to append to BootOrder variable
- * Return: status code
- */
-efi_status_t eficonfig_append_bootorder(u16 index)
-{
-   u16 *bootorder;
-   efi_status_t ret;
-   u16 *new_bootorder = NULL;
-   efi_uintn_t last, size, new_size;
-
-   /* append new boot option */
-   bootorder = efi_get_var(u"BootOrder", &efi_global_variable_guid, &size);
-   last = size / sizeof(u16);
-   new_size = size + sizeof(u16);
-   new_bootorder = calloc(1, new_size);
-   if (!new_bootorder) {
-   ret = EFI_OUT_OF_RESOURCES;
-   goto out;
-   }
-   memcpy(new_bootorder, bootorder, size);
-   new_bootorder[last] = index;
-
-   ret = efi_set_variable_int(u"BootOrder", &efi_global_variable_guid,
-  EFI_VARIABLE_NON_VOLATILE |
-  EFI_VARIABLE_BOOTSERVICE_ACCESS |
-  EFI_VARIABLE_RUNTIME_ACCESS,
-