Re: [PATCH v2 1/2] mmc: Check for device with a seq number equal to num before checking against index

[Aswath Govindraju]

Hi Ricardo,

On 07/07/21 4:39 am, Ricardo Salveti wrote:
> Hi Aswath,
> 
> On Thu, Mar 25, 2021 at 4:19 AM Aswath Govindraju  wrote:
>>
>> First check if there is an alias for the device tree node defined with the
>> given num before checking against device index.
>>
>> Signed-off-by: Aswath Govindraju 
>> Reviewed-by: Lokesh Vutla 
>> Reviewed-by: Jaehoon Chung 
>> ---
>>  drivers/mmc/mmc.c | 8 +---
>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>> index b4c8e7f293bd..1e83007286b2 100644
>> --- a/drivers/mmc/mmc.c
>> +++ b/drivers/mmc/mmc.c
>> @@ -3052,9 +3052,11 @@ int mmc_init_device(int num)
>> struct mmc *m;
>> int ret;
>>
>> -   ret = uclass_get_device(UCLASS_MMC, num, );
>> -   if (ret)
>> -   return ret;
>> +   if (uclass_get_device_by_seq(UCLASS_MMC, num, )) {
>> +   ret = uclass_get_device(UCLASS_MMC, num, );
>> +   if (ret)
>> +   return ret;
>> +   }
> 
> uclass_get_device_by_seq returns 0 if OK and -ve on error, so I
> believe this check is incorrect and we never end up calling
> uclass_get_device on the working path.
> 

Yes, as you mentioned uclass_get_device_by_seq() returns 0 if OK and -ve
on error is correct. However, the intention of this check here, is to
only call uclass_get_device() when uclass_get_device_by_seq() returns an
error.

uclass_get_device_by_seq() returns the device only if it is able find a
active device with matching sequence number "num" or will try to find a
device that is requesting this number. As this function also returns the
device we need not call uclass_get_device() again. Only on failure for
find a device with matching sequence number do we call uclass_get_device().

So, I believe the above mentioned check is correct.

> While bisecting to try to debug why my zynqmp-based device is unable
> to boot u-boot, I stopped at this patch (merged as part of
> v2021.07-rc1).
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 1e83007286b..56556353f8e 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -3052,11 +3052,13 @@ int mmc_init_device(int num)
> struct mmc *m;
> int ret;
> 
> -   if (uclass_get_device_by_seq(UCLASS_MMC, num, )) {
> -   ret = uclass_get_device(UCLASS_MMC, num, );
> -   if (ret)
> -   return ret;
> -   }
> +   ret = uclass_get_device_by_seq(UCLASS_MMC, num, );
> +   if (ret)
> +   return ret;
> +
> +   ret = uclass_get_device(UCLASS_MMC, num, );
> +   if (ret)
> +   return ret;
> 
> m = mmc_get_mmc_dev(dev);
> if (!m)
> 

In the above method, the device is being fetched twice and I believe
that this method is incorrect.

> This is enough for it to work correctly again, but I just wanted to
> reply back here first before submitting as I'm surprised nobody
> reported this issue before.
> 

If making this change got it work correctly again. I believe there might
have been a error in assigning aliases for mmc devices in the device
tree. As only after this patch are aliases being read for mmc class of
devices from the device tree.

Thanks,
Aswath

> Can you verify on your target hardware if this is indeed working as intended?
> 
> Thanks,
> 

Re: [PATCH v2 9/9] board: phytec: imx8mp-phycore: Switch to binman

[Jagan Teki]

On Tue, Jul 6, 2021 at 5:54 PM Teresa Remmet  wrote:
>
> Hello Jagan,
>
> Am Montag, den 05.07.2021, 11:01 +0530 schrieb Jagan Teki:
> > On Fri, Jul 2, 2021 at 4:49 PM Teresa Remmet 
> > wrote:
> > > Use now binman for image creation.
> > >
> > > Signed-off-by: Teresa Remmet 
> > > ---
> > >  .../imx8mp-phyboard-pollux-rdk-u-boot.dtsi| 105
> > > ++
> > >  arch/arm/mach-imx/imx8m/Kconfig   |   1 +
> > >  .../phytec/phycore_imx8mp/imximage-8mp-sd.cfg |  10 ++
> > >  configs/phycore-imx8mp_defconfig  |   4 +-
> > >  4 files changed, 118 insertions(+), 2 deletions(-)
> > >  create mode 100644 board/phytec/phycore_imx8mp/imximage-8mp-sd.cfg
> > >
> > > diff --git a/arch/arm/dts/imx8mp-phyboard-pollux-rdk-u-boot.dtsi
> > > b/arch/arm/dts/imx8mp-phyboard-pollux-rdk-u-boot.dtsi
> > > index dbc48dfb4841..2b8e77cb27c5 100644
> > > --- a/arch/arm/dts/imx8mp-phyboard-pollux-rdk-u-boot.dtsi
> > > +++ b/arch/arm/dts/imx8mp-phyboard-pollux-rdk-u-boot.dtsi
> > > @@ -7,6 +7,10 @@
> > >  #include "imx8mp-u-boot.dtsi"
> > >
> > >  / {
> > > +   binman: binman {
> > > +   multiple-images;
> > > +   };
> > > +
> > > wdt-reboot {
> > > compatible = "wdt-reboot";
> > > wdt = <>;
> > > @@ -81,3 +85,104 @@
> > >   {
> > > u-boot,dm-spl;
> > >  };
> > > +
> > > + {
> > > +u-boot-spl-ddr {
> > > +   filename = "u-boot-spl-ddr.bin";
> > > +   pad-byte = <0xff>;
> > > +   align-size = <4>;
> > > +   align = <4>;
> > > +
> > > +   u-boot-spl {
> > > +   align-end = <4>;
> > > +   };
> > > +
> > > +   blob_1: blob-ext@1 {
> > > +   filename =
> > > "lpddr4_pmu_train_1d_imem_202006.bin";
> > > +   size = <0x8000>;
> > > +   };
> > > +
> > > +   blob_2: blob-ext@2 {
> > > +   filename =
> > > "lpddr4_pmu_train_1d_dmem_202006.bin";
> > > +   size = <0x4000>;
> > > +   };
> > > +
> > > +   blob_3: blob-ext@3 {
> > > +   filename =
> > > "lpddr4_pmu_train_2d_imem_202006.bin";
> > > +   size = <0x8000>;
> > > +   };
> > > +
> > > +   blob_4: blob-ext@4 {
> > > +   filename =
> > > "lpddr4_pmu_train_2d_dmem_202006.bin";
> > > +   size = <0x4000>;
> > > +   };
> > > +   };
> > > +
> > > +   flash {
> > > +   mkimage {
> > > +   args = "-n spl/u-boot-spl.cfgout -T
> > > imx8mimage -e 0x92";
> > > +
> > > +   blob {
> > > +   filename = "u-boot-spl-ddr.bin";
> > > +   };
> > > +   };
> > > +   };
> > > +
> > > +   itb {
> > > +   filename = "u-boot.itb";
> > > +
> > > +   fit {
> > > +   description = "Configuration to load ATF
> > > before U-Boot";
> > > +   #address-cells = <1>;
> > > +   fit,external-offset =
> > > ;
> > > +
> > > +   images {
> > > +   uboot {
> > > +   description = "U-Boot (64-
> > > bit)";
> > > +   type = "standalone";
> > > +   arch = "arm64";
> > > +   compression = "none";
> > > +   load =
> > > ;
> > > +
> > > +   uboot_blob: blob-ext {
> > > +   filename = "u-boot-
> > > nodtb.bin";
> > > +   };
> > > +   };
> > > +
> > > +   atf {
> > > +   description = "ARM Trusted
> > > Firmware";
> > > +   type = "firmware";
> > > +   arch = "arm64";
> > > +   compression = "none";
> > > +   load = <0x97>;
> > > +   entry = <0x97>;
> > > +
> > > +   atf_blob: blob-ext {
> > > +   filename =
> > > "bl31.bin";
> > > +   };
> > > +   };
> > > +
> > > +   fdt {
> > > +   description = "NAME";
> > > +   type = "flat_dt";
> > > +   compression = "none";
> > > +
> > > +   uboot_fdt_blob: blob-ext {
> > > +  

Re: [PULL] u-boot-riscv/master

[Tianrui Wei]

Hi Tom, Leo,

Apologies for making that mistake, and many many thanks for merging our 
patches! We’ve already fixed the problem with another patch.

Many thanks,
Tianrui

-Original Message-
From: Tom Rini 
Date: Wednesday, July 7, 2021 at 3:52 AM
To: Leo Liang 
Cc: u-boot@lists.denx.de , r...@andestech.com 
, Tianrui Wei 
Subject: Re: [PULL] u-boot-riscv/master
On Wed, Jul 07, 2021 at 12:02:05AM +0800, Leo Liang wrote:

> Hi Tom,
>
> The following changes since commit 1311dd37ecf476be041d0452d4ee38619aadd5de:
>
>   Merge branch '2021-07-01-update-CI-containers' (2021-07-05 15:29:44 -0400)
>
> are available in the Git repository at:
>
>   
> g...@source.denx.de:u-boot/custodians/u-boot-riscv.git
>
> for you to fetch changes up to 4b4159d0f31ca3e0174ccfdce9a24a1fe3671829:
>
>   board: sifive: support spl multi-dtb on unmatched board (2021-07-06 
> 20:24:26 +0800)
>
> CI result shows no issue: 
> https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/8081
>

Please note:
w+(openpiton_riscv64 openpiton_riscv64_spl) 
arch/riscv/dts/openpiton-riscv64.dtb: Warning (ranges_format): /soc:ranges: 
empty "ranges" property but its #address-cells (1) differs from / (2)
w+(openpiton_riscv64 openpiton_riscv64_spl) 
arch/riscv/dts/openpiton-riscv64.dtb: Warning (ranges_format): /soc:ranges: 
empty "ranges" property but its #size-cells (1) differs from / (2)

need to be fixed in a follow up PR (and the relevant dts files should be
added to the board MAINTAINER file too).  That said, applied to
u-boot/master, thanks!

--
Tom

[PATCH] riscv: dts: add OpenPiton RISC-V board dts support

[Tianrui Wei]

Previous device tree for OpenPitonemits a warning during compilation,
thus was rejected by Tom. This commit fixes the previous warning and
adds dts to the OpenPiton RISC-V board and added the device tree to
MAINTAINER file.

Signed-off-by: Tianrui Wei 
Reported-by: Tom Rini 
---
 arch/riscv/dts/openpiton-riscv64.dts | 4 ++--
 board/openpiton/riscv64/MAINTAINERS  | 3 ++-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/dts/openpiton-riscv64.dts 
b/arch/riscv/dts/openpiton-riscv64.dts
index 45951e1236..abc6016a0b 100644
--- a/arch/riscv/dts/openpiton-riscv64.dts
+++ b/arch/riscv/dts/openpiton-riscv64.dts
@@ -80,8 +80,8 @@
};
 
soc {
-   #address-cells = <1>;
-   #size-cells = <1>;
+   #address-cells = <2>;
+   #size-cells = <2>;
compatible = "openpiton,chipset", "simple-bus";
ranges;
 
diff --git a/board/openpiton/riscv64/MAINTAINERS 
b/board/openpiton/riscv64/MAINTAINERS
index f91c000c83..f80f5b0495 100644
--- a/board/openpiton/riscv64/MAINTAINERS
+++ b/board/openpiton/riscv64/MAINTAINERS
@@ -1,8 +1,9 @@
 Openpiton BOARD
-M: Tianrui Wei
+M: Tianrui Wei 
 S: Maintained
 F: board/openpiton/riscv64/
 F: include/configs/openpiton-riscv64.h
 F: configs/openpiton_riscv64_defconfig
 F: configs/openpiton_riscv64_spl_defconfig
 F:  drivers/mmc/piton_mmc.c
+F:  arch/riscv/dts/openpiton-riscv64.dts
-- 
2.32.0

Re: QEMU NUMA and U-Boot

[Heinrich Schuchardt]

Am 7. Juli 2021 05:18:20 MESZ schrieb Heinrich Schuchardt :
>Am 7. Juli 2021 03:44:35 MESZ schrieb AKASHI Takahiro
>:
>>François,
>>
>>On Tue, Jul 06, 2021 at 08:10:08PM +0200, Heinrich Schuchardt wrote:
>>> On 7/6/21 6:13 PM, François Ozog wrote:
>>> > Hi Heinrich, U-Boot 2021-07rc5 does not take into account memory
>>> > description when using Qemu 5.2 NUMA configuration to adapt memory
>>map
>>> > (kernel_addr_r...):
>>> > 
>>> >         -smp 4 \
>>> >           -m 8G,slots=2,maxmem=16G \
>>> >          -object memory-backend-ram,size=4G,id=m0 \
>>> >          -object memory-backend-ram,size=4G,id=m1 \
>>> >          -numa node,cpus=0-1,nodeid=0,memdev=m0 \
>>> >          -numa node,cpus=2-3,nodeid=1,memdev=m1
>>> > 
>>> > kernel_addr_r is still 0x404 and thus you can't use it to
>>bootefi.
>>> > 
>>> > fdt addr 0x13ede6de0; fdt print
>>> > 
>>> > Displays fdt while I think it should not.
>>> > 
>>> > If I load the kernel at dram.start, the load works but not boot
>>> > 
>>> > U-Boot 2021.07 (Jul 06 2021 - 13:26:43 +)
>>> > 
>>> > 
>>> > DRAM:4 GiB
>>> > 
>>> > Flash: 64 MiB
>>> > 
>>> > Loading Environment from Flash... OK
>>> > 
>>> > In:pl011@900
>>> > 
>>> > Out: pl011@900
>>> > 
>>> > Err: pl011@900
>>> > 
>>> > Net: eth0: virtio-net#32
>>> > 
>>> > Hit any key to stop autoboot:0
>>> > 
>>> > =>
>>> > 
>>> > => bdinfo
>>> > 
>>> > boot_params = 0x
>>> > 
>>> > DRAM bank = 0x
>>> > 
>>> > -> start= 0x00014000
>>> > 
>>> > -> size = 0x0001
>>> > 
>>> > flashstart= 0x
>>> > 
>>> > flashsize = 0x0400
>>> > 
>>> > flashoffset = 0x000bc990
>>> > 
>>> > baudrate= 115200 bps
>>> > 
>>> > relocaddr = 0x00013ff27000
>>> > 
>>> > reloc off = 0x00013ff27000
>>> > 
>>> > Build = 64-bit
>>> > 
>>> > current eth = virtio-net#32
>>> > 
>>> > ethaddr = 52:52:52:52:52:52
>>> > 
>>> > IP addr = 
>>> > 
>>> > fdt_blob= 0x00013ede6de0
>>> > 
>>> > new_fdt = 0x00013ede6de0
>>> > 
>>> > fdt_size= 0x0010
>>> > 
>>> > lmb_dump_all:
>>> > 
>>> > memory.cnt= 0x1
>>> > 
>>> > memory.reg[0x0].base = 0x14000
>>> > 
>>> > .size = 0x1
>>> > 
>>> > 
>>> > reserved.cnt= 0x0
>>> > 
>>> > arch_number = 0x
>>> > 
>>> > TLB addr= 0x00013fff
>>> > 
>>> > irq_sp= 0x00013ede6dd0
>>> > 
>>> > sp start= 0x00013ede6dd0
>>> > 
>>> > Early malloc usage: 3a8 / 2000
>>> > 
>>> > => load virtio 0:1 0x14000 /oskit.efi
>>> > 
>>> > 853424 bytes read in 1 ms (813.9 MiB/s)
>>> > 
>>> > => bootefi0x14000 0x13ede6dd0
>>> > 
>>> > ERROR: Failed to register WaitForKey event
>>> > 
>>> > Setting OsIndications failed
>>> > 
>>> > Error: Cannot initialize UEFI sub-system, r = 9
>>> > 
>>> > 
>>> > I think there is a need to calculate memory map based on previous
>>> > firmware (TFA, QEMU can be considered as previous frimware)
>>information
>>> > (DT or blob_list).
>>> > 
>>> > What do you think ?
>>> > 
>>> > Cheers
>>> > 
>>> > FF
>>> > 
>>> > --
>>> > 
>>> > François-Frédéric Ozog | /Director Business Development/
>>> > T: +33.67221.6485
>>> > francois.o...@linaro.org 
>>| Skype: ffozog
>>> > 
>>> > 
>>> 
>>> The kernel load address is hard coded here:
>>> include/configs/qemu-arm.h:41:  "kernel_addr_r=0x4040\0" \
>>> 
>>> bdinfo shows:
>>> DRAM start = 0x14000
>>> DRAM size  = 0x1
>>> 
>>> fdt addr $fdt_addr
>>> fdt printf
>>> 
>>> shows two memory areas. One at 4000, one at 14000.
>>
>>(This shows that U-Boot receives a correct memory map via dtb.)
>>
>>Is this a NUMA machine, isn't it? Why should we care of which
>>memory region be used here? Please note that this is a virtual
>machine,
>>there is no practical difference between two regions.
>>
>>The root problem is that U-Boot did not recognize there were two
>>memory regions. We can fix this issue in either way:
>>
>>1)
>>diff --git a/configs/qemu_arm64_defconfig
>>b/configs/qemu_arm64_defconfig
>>index f6e586627a8e..b70ffae8bf6e 100644
>>--- a/configs/qemu_arm64_defconfig
>>+++ b/configs/qemu_arm64_defconfig
>>@@ -1,7 +1,7 @@
>> CONFIG_ARM=y
>> CONFIG_POSITION_INDEPENDENT=y
>> CONFIG_ARCH_QEMU=y
>>-CONFIG_NR_DRAM_BANKS=1
>>+CONFIG_NR_DRAM_BANKS=2
>> CONFIG_ENV_SIZE=0x4
>> CONFIG_ENV_SECT_SIZE=0x4
>> CONFIG_AHCI=y
>>
>>2)
>>diff --git a/lib/fdtdec.c b/lib/fdtdec.c
>>index 4b097fb588ed..4067ea2dead6 100644
>>--- a/lib/fdtdec.c
>>+++ b/lib/fdtdec.c
>>@@ -,7 +,7 @@ int fdtdec_setup_memory_banksize(void)
>>return -EINVAL;
>>}
>> 
>>-   for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
>>+   for (bank = 0; ; bank++) {
>>ret = ofnode_read_resource(mem, reg++, );
>>if (ret < 0) {
>>reg = 0;
>>
>>   (fdtdec_setup_memory_banksize() is called in dram_init_banksize().)
>>
>>
>>(2) seems much better, but I don't know why we had to use
>>CONFIG_NR_DRAM_BANKS here.

Re: QEMU NUMA and U-Boot

[Heinrich Schuchardt]

Am 7. Juli 2021 05:18:20 MESZ schrieb Heinrich Schuchardt :
>Am 7. Juli 2021 03:44:35 MESZ schrieb AKASHI Takahiro
>:
>>François,
>>
>>On Tue, Jul 06, 2021 at 08:10:08PM +0200, Heinrich Schuchardt wrote:
>>> On 7/6/21 6:13 PM, François Ozog wrote:
>>> > Hi Heinrich, U-Boot 2021-07rc5 does not take into account memory
>>> > description when using Qemu 5.2 NUMA configuration to adapt memory
>>map
>>> > (kernel_addr_r...):
>>> > 
>>> >         -smp 4 \
>>> >           -m 8G,slots=2,maxmem=16G \
>>> >          -object memory-backend-ram,size=4G,id=m0 \
>>> >          -object memory-backend-ram,size=4G,id=m1 \
>>> >          -numa node,cpus=0-1,nodeid=0,memdev=m0 \
>>> >          -numa node,cpus=2-3,nodeid=1,memdev=m1
>>> > 
>>> > kernel_addr_r is still 0x404 and thus you can't use it to
>>bootefi.
>>> > 
>>> > fdt addr 0x13ede6de0; fdt print
>>> > 
>>> > Displays fdt while I think it should not.
>>> > 
>>> > If I load the kernel at dram.start, the load works but not boot
>>> > 
>>> > U-Boot 2021.07 (Jul 06 2021 - 13:26:43 +)
>>> > 
>>> > 
>>> > DRAM:4 GiB
>>> > 
>>> > Flash: 64 MiB
>>> > 
>>> > Loading Environment from Flash... OK
>>> > 
>>> > In:pl011@900
>>> > 
>>> > Out: pl011@900
>>> > 
>>> > Err: pl011@900
>>> > 
>>> > Net: eth0: virtio-net#32
>>> > 
>>> > Hit any key to stop autoboot:0
>>> > 
>>> > =>
>>> > 
>>> > => bdinfo
>>> > 
>>> > boot_params = 0x
>>> > 
>>> > DRAM bank = 0x
>>> > 
>>> > -> start= 0x00014000
>>> > 
>>> > -> size = 0x0001
>>> > 
>>> > flashstart= 0x
>>> > 
>>> > flashsize = 0x0400
>>> > 
>>> > flashoffset = 0x000bc990
>>> > 
>>> > baudrate= 115200 bps
>>> > 
>>> > relocaddr = 0x00013ff27000
>>> > 
>>> > reloc off = 0x00013ff27000
>>> > 
>>> > Build = 64-bit
>>> > 
>>> > current eth = virtio-net#32
>>> > 
>>> > ethaddr = 52:52:52:52:52:52
>>> > 
>>> > IP addr = 
>>> > 
>>> > fdt_blob= 0x00013ede6de0
>>> > 
>>> > new_fdt = 0x00013ede6de0
>>> > 
>>> > fdt_size= 0x0010
>>> > 
>>> > lmb_dump_all:
>>> > 
>>> > memory.cnt= 0x1
>>> > 
>>> > memory.reg[0x0].base = 0x14000
>>> > 
>>> > .size = 0x1
>>> > 
>>> > 
>>> > reserved.cnt= 0x0
>>> > 
>>> > arch_number = 0x
>>> > 
>>> > TLB addr= 0x00013fff
>>> > 
>>> > irq_sp= 0x00013ede6dd0
>>> > 
>>> > sp start= 0x00013ede6dd0
>>> > 
>>> > Early malloc usage: 3a8 / 2000
>>> > 
>>> > => load virtio 0:1 0x14000 /oskit.efi
>>> > 
>>> > 853424 bytes read in 1 ms (813.9 MiB/s)
>>> > 
>>> > => bootefi0x14000 0x13ede6dd0
>>> > 
>>> > ERROR: Failed to register WaitForKey event
>>> > 
>>> > Setting OsIndications failed
>>> > 
>>> > Error: Cannot initialize UEFI sub-system, r = 9
>>> > 
>>> > 
>>> > I think there is a need to calculate memory map based on previous
>>> > firmware (TFA, QEMU can be considered as previous frimware)
>>information
>>> > (DT or blob_list).
>>> > 
>>> > What do you think ?
>>> > 
>>> > Cheers
>>> > 
>>> > FF
>>> > 
>>> > --
>>> > 
>>> > François-Frédéric Ozog | /Director Business Development/
>>> > T: +33.67221.6485
>>> > francois.o...@linaro.org 
>>| Skype: ffozog
>>> > 
>>> > 
>>> 
>>> The kernel load address is hard coded here:
>>> include/configs/qemu-arm.h:41:  "kernel_addr_r=0x4040\0" \
>>> 
>>> bdinfo shows:
>>> DRAM start = 0x14000
>>> DRAM size  = 0x1
>>> 
>>> fdt addr $fdt_addr
>>> fdt printf
>>> 
>>> shows two memory areas. One at 4000, one at 14000.
>>
>>(This shows that U-Boot receives a correct memory map via dtb.)
>>
>>Is this a NUMA machine, isn't it? Why should we care of which
>>memory region be used here? Please note that this is a virtual
>machine,
>>there is no practical difference between two regions.
>>
>>The root problem is that U-Boot did not recognize there were two
>>memory regions. We can fix this issue in either way:
>>
>>1)
>>diff --git a/configs/qemu_arm64_defconfig
>>b/configs/qemu_arm64_defconfig
>>index f6e586627a8e..b70ffae8bf6e 100644
>>--- a/configs/qemu_arm64_defconfig
>>+++ b/configs/qemu_arm64_defconfig
>>@@ -1,7 +1,7 @@
>> CONFIG_ARM=y
>> CONFIG_POSITION_INDEPENDENT=y
>> CONFIG_ARCH_QEMU=y
>>-CONFIG_NR_DRAM_BANKS=1
>>+CONFIG_NR_DRAM_BANKS=2
>> CONFIG_ENV_SIZE=0x4
>> CONFIG_ENV_SECT_SIZE=0x4
>> CONFIG_AHCI=y
>>
>>2)
>>diff --git a/lib/fdtdec.c b/lib/fdtdec.c
>>index 4b097fb588ed..4067ea2dead6 100644
>>--- a/lib/fdtdec.c
>>+++ b/lib/fdtdec.c
>>@@ -,7 +,7 @@ int fdtdec_setup_memory_banksize(void)
>>return -EINVAL;
>>}
>> 
>>-   for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
>>+   for (bank = 0; ; bank++) {
>>ret = ofnode_read_resource(mem, reg++, );
>>if (ret < 0) {
>>reg = 0;
>>
>>   (fdtdec_setup_memory_banksize() is called in dram_init_banksize().)
>>
>>
>>(2) seems much better, but I don't know why we had to use
>>CONFIG_NR_DRAM_BANKS here.

Re: [PATCH v6 4/5] mtd: spi-nor-ids: Add XTX XT25F128B

[Chris Morgan]

On Wed, Jun 30, 2021 at 09:31:34PM +0800, Jon Lin wrote:
> From: Chris Morgan 
> 
> Adds support for XT25F128B used on Odroid Go Advance. Unfortunately
> this chip uses a continuation code which I cannot seem to parse, so
> there are possibly going to be collisions with chips that use the same
> manufacturer/ID.
> 
> Signed-off-by: Chris Morgan 
> Signed-off-by: Jon Lin 
> ---
> 
> (no changes since v1)
> 
>  drivers/mtd/spi/Kconfig   | 6 ++
>  drivers/mtd/spi/spi-nor-ids.c | 8 
>  2 files changed, 14 insertions(+)
> 
> diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
> index f8db8e5213..8c797d1e03 100644
> --- a/drivers/mtd/spi/Kconfig
> +++ b/drivers/mtd/spi/Kconfig
> @@ -162,6 +162,12 @@ config SPI_FLASH_XMC
> Add support for various XMC (Wuhan Xinxin Semiconductor
> Manufacturing Corp.) SPI flash chips (XM25xxx)
>  
> +config SPI_FLASH_XTX
> + bool "XTX SPI flash support"
> + help
> +   Add support for various XTX (XTX Technology Limited)
> +   SPI flash chips (XT25xxx).
> +
>  endif
>  
>  config SPI_FLASH_USE_4K_SECTORS
> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> index 2b57797954..bdecb3b837 100644
> --- a/drivers/mtd/spi/spi-nor-ids.c
> +++ b/drivers/mtd/spi/spi-nor-ids.c
> @@ -336,6 +336,14 @@ const struct flash_info spi_nor_ids[] = {
>   /* XMC (Wuhan Xinxin Semiconductor Manufacturing Corp.) */
>   { INFO("XM25QH64A", 0x207017, 0, 64 * 1024, 128, SECT_4K | 
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
>   { INFO("XM25QH128A", 0x207018, 0, 64 * 1024, 256, SECT_4K | 
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> +#endif
> +#ifdef CONFIG_SPI_FLASH_XTX
> + /* XTX Technology (Shenzhen) Limited */
> + {
> + INFO("xt25f128b", 0x0b4018, 0, 64 * 1024, 256,
> +  SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
> +  SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)

Upon closer inspection of the datasheet, I'm almost certain the
SPI_NOR_HAS_LOCK or the SPI_NOR_HAS_TB doesn't need to be set here.
While the chip I think has these features, the bits are different than
what is expected by these flags. I've been testing the Linux and U-boot
drivers without these flags with no problems.

> + },
>  #endif
>   { },
>  };
> -- 
> 2.17.1
> 
> 
> 

Re: [PATCH v6 1/5] spi: rockchip_sfc: add support for Rockchip SFC

[Chris Morgan]

On Wed, Jun 30, 2021 at 09:31:31PM +0800, Jon Lin wrote:
> From: Chris Morgan 
> 
> This patch adds support for the Rockchip serial flash controller
> found on the PX30 SoC. It should work for versions 3-5 of the SFC
> IP, however I am only able to test it on v3.
> 
> This is adapted from the WIP SPI-MEM driver for the SFC on mainline
> Linux. Note that the main difference between this and earlier versions
> of the driver is that this one does not support DMA. In testing
> the performance difference (performing a dual mode read on a 128Mb
> chip) is negligible. DMA, if used, must also be disabled in SPL
> mode when using A-TF anyway.
> 
> Signed-off-by: Chris Morgan 
> Signed-off-by: Jon Lin 
> ---
> 
> Changes in v6:
> - Fix dma transfer logic
> - Fix the error of the way to wait for dma transfer finished status
> 
> Changes in v5:
> - Support dma transfer
> - Add CONFIG_IS_ENABLED(CLK) limitation
> - Support spinand devices
> - Support SFC ver4 ver5
> - Using "rockchip, sfc" as compatible id
> - Get clock from the index to compatible with those case which's
>   clock-names is not parsed
> 
> Changes in v4:
> - None
> 
> Changes in v3:
> - Added "rockchip_sfc_adjust_op_work()" function from proposed Linux
>   driver to fix potential issue on hardware. Note I never noticed
>   this issue while testing, so I cannot test if it fixed any specific
>   issue for me.
> - Updated of-compatible string back to "rockchip,sfc" to match what
>   is currently proposed for upstream driver. The hardware itself
>   has multiple versions but a register is present in the hardware that
>   is read by the driver to set version specific functionality.
> - Updated px30.dtsi and rk3266-odroid-go2.dts device-trees so that
>   sfc nodes match what is in upstream.
> 
> Changes in v2:
> - Resending due to glitch with patch file truncating final two lines
>   on patch 1/5 and incorrect patch version number on patch 5/5.
> 
> Changes in v1:
> - Reworked code to utilize spi-mem framework, and based it closely
>   off of work in progress code for mainline Linux.
> - Removed DMA, as it didn't offer much performance benefit for
>   booting (in my test cases), added complexity to the code, and
>   interfered with A-TF.
> - Updated the names of the bindings to match the work in progress
>   Linux code.
> - Moved alias to u-boot specific device-tree for Odroid Go Advance.
>   Alias is updated with the spi0 node pointing to the SFC to
>   help the sf command as well as facilitate booting from the SFC.
> - Note 2 below no longer applies, as rebasing this off of upstream
>   code should allow the device to work for NAND, and by utilizing
>   the spi-mem framework it no longer has to extract the parameters
> 
>  drivers/spi/Kconfig|   8 +
>  drivers/spi/Makefile   |   1 +
>  drivers/spi/rockchip_sfc.c | 643 +
>  3 files changed, 652 insertions(+)
>  create mode 100644 drivers/spi/rockchip_sfc.c
> 
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 1494c91763..bef36f2931 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -312,6 +312,14 @@ config RENESAS_RPC_SPI
> on Renesas RCar Gen3 SoCs. This uses driver model and requires a
> device tree binding to operate.
>  
> +config ROCKCHIP_SFC
> + bool "Rockchip SFC Driver"
> + help
> +   Enable the Rockchip SFC Driver for SPI NOR flash. This device is
> +   a limited purpose SPI controller for driving NOR flash on certain
> +   Rockchip SoCs. This uses driver model and requires a device tree
> +   binding to operate.
> +
>  config ROCKCHIP_SPI
>   bool "Rockchip SPI driver"
>   help
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index cfe4fae1d4..f02e84b5f1 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -52,6 +52,7 @@ obj-$(CONFIG_PIC32_SPI) += pic32_spi.o
>  obj-$(CONFIG_PL022_SPI) += pl022_spi.o
>  obj-$(CONFIG_SPI_QUP) += spi-qup.o
>  obj-$(CONFIG_RENESAS_RPC_SPI) += renesas_rpc_spi.o
> +obj-$(CONFIG_ROCKCHIP_SFC) += rockchip_sfc.o
>  obj-$(CONFIG_ROCKCHIP_SPI) += rk_spi.o
>  obj-$(CONFIG_SANDBOX_SPI) += sandbox_spi.o
>  obj-$(CONFIG_SPI_SIFIVE) += spi-sifive.o
> diff --git a/drivers/spi/rockchip_sfc.c b/drivers/spi/rockchip_sfc.c
> new file mode 100644
> index 00..2d86f136f2
> --- /dev/null
> +++ b/drivers/spi/rockchip_sfc.c
> @@ -0,0 +1,643 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Rockchip Serial Flash Controller Driver
> + *
> + * Copyright (c) 2017-2021, Rockchip Inc.
> + * Author: Shawn Lin 
> + *  Chris Morgan 
> + *  Jon Lin 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* System control */
> +#define SFC_CTRL 0x0
> +#define  SFC_CTRL_PHASE_SEL_NEGETIVE BIT(1)
> +#define  SFC_CTRL_CMD_BITS_SHIFT 8
> +#define  SFC_CTRL_ADDR_BITS_SHIFT10
> +#define  SFC_CTRL_DATA_BITS_SHIFT12
> +

Re: QEMU NUMA and U-Boot

[Heinrich Schuchardt]

Am 7. Juli 2021 03:44:35 MESZ schrieb AKASHI Takahiro 
:
>François,
>
>On Tue, Jul 06, 2021 at 08:10:08PM +0200, Heinrich Schuchardt wrote:
>> On 7/6/21 6:13 PM, François Ozog wrote:
>> > Hi Heinrich, U-Boot 2021-07rc5 does not take into account memory
>> > description when using Qemu 5.2 NUMA configuration to adapt memory
>map
>> > (kernel_addr_r...):
>> > 
>> >         -smp 4 \
>> >           -m 8G,slots=2,maxmem=16G \
>> >          -object memory-backend-ram,size=4G,id=m0 \
>> >          -object memory-backend-ram,size=4G,id=m1 \
>> >          -numa node,cpus=0-1,nodeid=0,memdev=m0 \
>> >          -numa node,cpus=2-3,nodeid=1,memdev=m1
>> > 
>> > kernel_addr_r is still 0x404 and thus you can't use it to
>bootefi.
>> > 
>> > fdt addr 0x13ede6de0; fdt print
>> > 
>> > Displays fdt while I think it should not.
>> > 
>> > If I load the kernel at dram.start, the load works but not boot
>> > 
>> > U-Boot 2021.07 (Jul 06 2021 - 13:26:43 +)
>> > 
>> > 
>> > DRAM:4 GiB
>> > 
>> > Flash: 64 MiB
>> > 
>> > Loading Environment from Flash... OK
>> > 
>> > In:pl011@900
>> > 
>> > Out: pl011@900
>> > 
>> > Err: pl011@900
>> > 
>> > Net: eth0: virtio-net#32
>> > 
>> > Hit any key to stop autoboot:0
>> > 
>> > =>
>> > 
>> > => bdinfo
>> > 
>> > boot_params = 0x
>> > 
>> > DRAM bank = 0x
>> > 
>> > -> start= 0x00014000
>> > 
>> > -> size = 0x0001
>> > 
>> > flashstart= 0x
>> > 
>> > flashsize = 0x0400
>> > 
>> > flashoffset = 0x000bc990
>> > 
>> > baudrate= 115200 bps
>> > 
>> > relocaddr = 0x00013ff27000
>> > 
>> > reloc off = 0x00013ff27000
>> > 
>> > Build = 64-bit
>> > 
>> > current eth = virtio-net#32
>> > 
>> > ethaddr = 52:52:52:52:52:52
>> > 
>> > IP addr = 
>> > 
>> > fdt_blob= 0x00013ede6de0
>> > 
>> > new_fdt = 0x00013ede6de0
>> > 
>> > fdt_size= 0x0010
>> > 
>> > lmb_dump_all:
>> > 
>> > memory.cnt= 0x1
>> > 
>> > memory.reg[0x0].base = 0x14000
>> > 
>> > .size = 0x1
>> > 
>> > 
>> > reserved.cnt= 0x0
>> > 
>> > arch_number = 0x
>> > 
>> > TLB addr= 0x00013fff
>> > 
>> > irq_sp= 0x00013ede6dd0
>> > 
>> > sp start= 0x00013ede6dd0
>> > 
>> > Early malloc usage: 3a8 / 2000
>> > 
>> > => load virtio 0:1 0x14000 /oskit.efi
>> > 
>> > 853424 bytes read in 1 ms (813.9 MiB/s)
>> > 
>> > => bootefi0x14000 0x13ede6dd0
>> > 
>> > ERROR: Failed to register WaitForKey event
>> > 
>> > Setting OsIndications failed
>> > 
>> > Error: Cannot initialize UEFI sub-system, r = 9
>> > 
>> > 
>> > I think there is a need to calculate memory map based on previous
>> > firmware (TFA, QEMU can be considered as previous frimware)
>information
>> > (DT or blob_list).
>> > 
>> > What do you think ?
>> > 
>> > Cheers
>> > 
>> > FF
>> > 
>> > --
>> > 
>> > François-Frédéric Ozog | /Director Business Development/
>> > T: +33.67221.6485
>> > francois.o...@linaro.org 
>| Skype: ffozog
>> > 
>> > 
>> 
>> The kernel load address is hard coded here:
>> include/configs/qemu-arm.h:41:  "kernel_addr_r=0x4040\0" \
>> 
>> bdinfo shows:
>> DRAM start = 0x14000
>> DRAM size  = 0x1
>> 
>> fdt addr $fdt_addr
>> fdt printf
>> 
>> shows two memory areas. One at 4000, one at 14000.
>
>(This shows that U-Boot receives a correct memory map via dtb.)
>
>Is this a NUMA machine, isn't it? Why should we care of which
>memory region be used here? Please note that this is a virtual machine,
>there is no practical difference between two regions.
>
>The root problem is that U-Boot did not recognize there were two
>memory regions. We can fix this issue in either way:
>
>1)
>diff --git a/configs/qemu_arm64_defconfig
>b/configs/qemu_arm64_defconfig
>index f6e586627a8e..b70ffae8bf6e 100644
>--- a/configs/qemu_arm64_defconfig
>+++ b/configs/qemu_arm64_defconfig
>@@ -1,7 +1,7 @@
> CONFIG_ARM=y
> CONFIG_POSITION_INDEPENDENT=y
> CONFIG_ARCH_QEMU=y
>-CONFIG_NR_DRAM_BANKS=1
>+CONFIG_NR_DRAM_BANKS=2
> CONFIG_ENV_SIZE=0x4
> CONFIG_ENV_SECT_SIZE=0x4
> CONFIG_AHCI=y
>
>2)
>diff --git a/lib/fdtdec.c b/lib/fdtdec.c
>index 4b097fb588ed..4067ea2dead6 100644
>--- a/lib/fdtdec.c
>+++ b/lib/fdtdec.c
>@@ -,7 +,7 @@ int fdtdec_setup_memory_banksize(void)
>return -EINVAL;
>}
> 
>-   for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
>+   for (bank = 0; ; bank++) {
>ret = ofnode_read_resource(mem, reg++, );
>if (ret < 0) {
>reg = 0;
>
>   (fdtdec_setup_memory_banksize() is called in dram_init_banksize().)
>
>
>(2) seems much better, but I don't know why we had to use
>CONFIG_NR_DRAM_BANKS here.
>
>In this case, other occurrences of CONFIG_NR_DRAM_BANKS in this file
>should be replaced with a variable for it. 
>
>> Your use case is well beyond the typical U-Boot usage. So I guess it
>> will be up to Linaro to provide the necessary patches:
>> 
>> 

Re: QEMU NUMA and U-Boot

[AKASHI Takahiro]

François,

On Tue, Jul 06, 2021 at 08:10:08PM +0200, Heinrich Schuchardt wrote:
> On 7/6/21 6:13 PM, François Ozog wrote:
> > Hi Heinrich, U-Boot 2021-07rc5 does not take into account memory
> > description when using Qemu 5.2 NUMA configuration to adapt memory map
> > (kernel_addr_r...):
> > 
> >         -smp 4 \
> >           -m 8G,slots=2,maxmem=16G \
> >          -object memory-backend-ram,size=4G,id=m0 \
> >          -object memory-backend-ram,size=4G,id=m1 \
> >          -numa node,cpus=0-1,nodeid=0,memdev=m0 \
> >          -numa node,cpus=2-3,nodeid=1,memdev=m1
> > 
> > kernel_addr_r is still 0x404 and thus you can't use it to bootefi.
> > 
> > fdt addr 0x13ede6de0; fdt print
> > 
> > Displays fdt while I think it should not.
> > 
> > If I load the kernel at dram.start, the load works but not boot
> > 
> > U-Boot 2021.07 (Jul 06 2021 - 13:26:43 +)
> > 
> > 
> > DRAM:4 GiB
> > 
> > Flash: 64 MiB
> > 
> > Loading Environment from Flash... OK
> > 
> > In:pl011@900
> > 
> > Out: pl011@900
> > 
> > Err: pl011@900
> > 
> > Net: eth0: virtio-net#32
> > 
> > Hit any key to stop autoboot:0
> > 
> > =>
> > 
> > => bdinfo
> > 
> > boot_params = 0x
> > 
> > DRAM bank = 0x
> > 
> > -> start= 0x00014000
> > 
> > -> size = 0x0001
> > 
> > flashstart= 0x
> > 
> > flashsize = 0x0400
> > 
> > flashoffset = 0x000bc990
> > 
> > baudrate= 115200 bps
> > 
> > relocaddr = 0x00013ff27000
> > 
> > reloc off = 0x00013ff27000
> > 
> > Build = 64-bit
> > 
> > current eth = virtio-net#32
> > 
> > ethaddr = 52:52:52:52:52:52
> > 
> > IP addr = 
> > 
> > fdt_blob= 0x00013ede6de0
> > 
> > new_fdt = 0x00013ede6de0
> > 
> > fdt_size= 0x0010
> > 
> > lmb_dump_all:
> > 
> > memory.cnt= 0x1
> > 
> > memory.reg[0x0].base = 0x14000
> > 
> > .size = 0x1
> > 
> > 
> > reserved.cnt= 0x0
> > 
> > arch_number = 0x
> > 
> > TLB addr= 0x00013fff
> > 
> > irq_sp= 0x00013ede6dd0
> > 
> > sp start= 0x00013ede6dd0
> > 
> > Early malloc usage: 3a8 / 2000
> > 
> > => load virtio 0:1 0x14000 /oskit.efi
> > 
> > 853424 bytes read in 1 ms (813.9 MiB/s)
> > 
> > => bootefi0x14000 0x13ede6dd0
> > 
> > ERROR: Failed to register WaitForKey event
> > 
> > Setting OsIndications failed
> > 
> > Error: Cannot initialize UEFI sub-system, r = 9
> > 
> > 
> > I think there is a need to calculate memory map based on previous
> > firmware (TFA, QEMU can be considered as previous frimware) information
> > (DT or blob_list).
> > 
> > What do you think ?
> > 
> > Cheers
> > 
> > FF
> > 
> > --
> > 
> > François-Frédéric Ozog | /Director Business Development/
> > T: +33.67221.6485
> > francois.o...@linaro.org  | Skype: ffozog
> > 
> > 
> 
> The kernel load address is hard coded here:
> include/configs/qemu-arm.h:41:  "kernel_addr_r=0x4040\0" \
> 
> bdinfo shows:
> DRAM start = 0x14000
> DRAM size  = 0x1
> 
> fdt addr $fdt_addr
> fdt printf
> 
> shows two memory areas. One at 4000, one at 14000.

(This shows that U-Boot receives a correct memory map via dtb.)

Is this a NUMA machine, isn't it? Why should we care of which
memory region be used here? Please note that this is a virtual machine,
there is no practical difference between two regions.

The root problem is that U-Boot did not recognize there were two
memory regions. We can fix this issue in either way:

1)
diff --git a/configs/qemu_arm64_defconfig b/configs/qemu_arm64_defconfig
index f6e586627a8e..b70ffae8bf6e 100644
--- a/configs/qemu_arm64_defconfig
+++ b/configs/qemu_arm64_defconfig
@@ -1,7 +1,7 @@
 CONFIG_ARM=y
 CONFIG_POSITION_INDEPENDENT=y
 CONFIG_ARCH_QEMU=y
-CONFIG_NR_DRAM_BANKS=1
+CONFIG_NR_DRAM_BANKS=2
 CONFIG_ENV_SIZE=0x4
 CONFIG_ENV_SECT_SIZE=0x4
 CONFIG_AHCI=y

2)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 4b097fb588ed..4067ea2dead6 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -,7 +,7 @@ int fdtdec_setup_memory_banksize(void)
return -EINVAL;
}
 
-   for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
+   for (bank = 0; ; bank++) {
ret = ofnode_read_resource(mem, reg++, );
if (ret < 0) {
reg = 0;

   (fdtdec_setup_memory_banksize() is called in dram_init_banksize().)


(2) seems much better, but I don't know why we had to use
CONFIG_NR_DRAM_BANKS here.

In this case, other occurrences of CONFIG_NR_DRAM_BANKS in this file
should be replaced with a variable for it. 

> Your use case is well beyond the typical U-Boot usage. So I guess it
> will be up to Linaro to provide the necessary patches:
> 
> * determine the active CPU
> * determine the RAM assigned to the active CPU according
>   to the numa-node-id in the device-tree
> * make sure that U-Boot only uses the memory of the active CPU
>   internally
> * make sure that the UEFI memory map contains 

[PATCH] xilinx: zynqmp: increase CONFIG_SYS_SPL_MALLOC_SIZE to 16MB

[Ricardo Salveti]

commit 03f1f78a9b44 ("spl: fit: Prefer a malloc()'d buffer for loading
images")' changed the way buffer allocation worked for SPL to a more
flexible method.

For xilinx zynqmp the 1MB buffer is not necessarily enough when dealing
with complex fit images (e.g. containing FPGA/TF-A/OP-TEE/U-Boot
proper), which can easily reach up to 10MB, so increase the default
CONFIG_SYS_SPL_MALLOC_SIZE size to 16MB to cover more advanced
scenarios.

Signed-off-by: Ricardo Salveti 
---
 include/configs/xilinx_zynqmp.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h
index cadaf1a9631..bfe8a204279 100644
--- a/include/configs/xilinx_zynqmp.h
+++ b/include/configs/xilinx_zynqmp.h
@@ -261,7 +261,7 @@
 #endif
 
 #define CONFIG_SYS_SPL_MALLOC_START0x2000
-#define CONFIG_SYS_SPL_MALLOC_SIZE 0x10
+#define CONFIG_SYS_SPL_MALLOC_SIZE 0x100
 
 #ifdef CONFIG_SPL_SYS_MALLOC_SIMPLE
 # error "Disable CONFIG_SPL_SYS_MALLOC_SIMPLE. Full malloc needs to be used"
-- 
2.32.0

Re: [PATCH v2 1/2] mmc: Check for device with a seq number equal to num before checking against index

[Ricardo Salveti]

Hi Aswath,

On Thu, Mar 25, 2021 at 4:19 AM Aswath Govindraju  wrote:
>
> First check if there is an alias for the device tree node defined with the
> given num before checking against device index.
>
> Signed-off-by: Aswath Govindraju 
> Reviewed-by: Lokesh Vutla 
> Reviewed-by: Jaehoon Chung 
> ---
>  drivers/mmc/mmc.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index b4c8e7f293bd..1e83007286b2 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -3052,9 +3052,11 @@ int mmc_init_device(int num)
> struct mmc *m;
> int ret;
>
> -   ret = uclass_get_device(UCLASS_MMC, num, );
> -   if (ret)
> -   return ret;
> +   if (uclass_get_device_by_seq(UCLASS_MMC, num, )) {
> +   ret = uclass_get_device(UCLASS_MMC, num, );
> +   if (ret)
> +   return ret;
> +   }

uclass_get_device_by_seq returns 0 if OK and -ve on error, so I
believe this check is incorrect and we never end up calling
uclass_get_device on the working path.

While bisecting to try to debug why my zynqmp-based device is unable
to boot u-boot, I stopped at this patch (merged as part of
v2021.07-rc1).

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 1e83007286b..56556353f8e 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -3052,11 +3052,13 @@ int mmc_init_device(int num)
struct mmc *m;
int ret;

-   if (uclass_get_device_by_seq(UCLASS_MMC, num, )) {
-   ret = uclass_get_device(UCLASS_MMC, num, );
-   if (ret)
-   return ret;
-   }
+   ret = uclass_get_device_by_seq(UCLASS_MMC, num, );
+   if (ret)
+   return ret;
+
+   ret = uclass_get_device(UCLASS_MMC, num, );
+   if (ret)
+   return ret;

m = mmc_get_mmc_dev(dev);
if (!m)

This is enough for it to work correctly again, but I just wanted to
reply back here first before submitting as I'm surprised nobody
reported this issue before.

Can you verify on your target hardware if this is indeed working as intended?

Thanks,
-- 
Ricardo Salveti

RFC: Devices for files and partitions

[Simon Glass]

Hi,

At present U-Boot avoids the concept of 'opening' a file. Being in a
bootloader environment, it is normally better to take the action
immediately and avoid any caching, for example, since there is no
background task to clean up afterwards.

Having said that, the concept of a file is quite useful, for example
to write the output of a command to a file, or to open a file and read
it a line at a time.

Another case has come to light in that EFI wants to access files using
a file handle. This currently uses parallel data structures and does
not map very well in U-Boot.

Finally, partitions has a similar issue, where defining them as a
device can have benefits, e.g. to specify the device to use directly,
rather than with the 'type dev:part' approach, perhaps providing them
in the devicetree, etc.

For the above reasons, I propose that we implement, as an option,
support for files and partitions within driver model.

Regards,
Simon

Re: [PATCH] serial: serial_msm: Ensure BAM/single character mode are disabled

[Tom Rini]

On Mon, Jun 28, 2021 at 10:40:09AM +0200, Stephan Gerhold wrote:

> At the moment, the U-Boot serial_msm driver does not initialize the
> UART_DM_DMEN register with the required value. Usually this does not
> cause any problems, because there is Qualcomm's LK bootloader running
> before U-Boot which initializes the register with the correct value.
> 
> It's important that this register is initialized correctly, because
> the U-Boot driver does not make use of the BAM/DMA or single character
> mode functionality of the UART controller. A different bootloader
> before U-Boot might initialize the register differently.
> 
> For example, on DragonBoard 410c U-Boot can also be installed to the
> "aboot" partition (replacing LK entirely). In this case U-Boot is
> loaded directly by SBL, which seems to use the single-character mode
> for some reason. In single character mode there is always just one
> char in the FIFO, instead of the 4 characters expected by
> msm_serial_fetch(). It also causes issues with "earlycon" later in
> the Linux kernel, which tries to output 4 chars at once,
> but only the first char will be written.
> 
> This causes early UART log in Linux to be corrupted like this:
> 
> [ 00ano:ameoi .Q1B[ 00ac _idaM00080oo'ahani-lcle._20). 15NdNii 5 
> SPMSJ20:U2
> [ 00rkoolmsamel
> [ 00Fw ]elamletopsioble
> [ 00ore
> 
> instead of
> 
> [0.00] Booting Linux on physical CPU 0x00 [0x410fd030]
> [0.00] Machine model: Qualcomm Technologies, Inc. APQ 8016 SBC
> [0.00] earlycon: msm_serial_dm0 at MMIO 0x078b 
> (options '')
> [0.00] printk: bootconsole [msm_serial_dm0] enabled
> 
> Make sure to initialize UART_DM_DMEN correctly to fix this issue
> when loading U-Boot directly after SBL (instead of through LK).
> 
> There is no functional difference when loading U-Boot through LK
> since LK also initializes UART_DM_DMEN to 0x0. [1]
> 
> [1]: 
> https://git.linaro.org/landing-teams/working/qualcomm/lk.git/tree/platform/msm_shared/uart_dm.c?h=dragonboard410c-LA.BR.1.2.7-03810-8x16.0-linaro3#n203
> 
> Cc: Ramon Fried 
> Signed-off-by: Stephan Gerhold 
> Reviewed-by: Ramon Fried 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] arm: dts: db410c: Add missing cd-gpios for SD card detection

[Tom Rini]

On Sun, Jun 27, 2021 at 01:06:15PM +0200, Stephan Gerhold wrote:

> It looks like SD card detection is broken at the moment for DB410c.
> The eMMC is detected correctly, but the SD card is not.
> 
> This is probably similar to the issue fixed in commit 850514740358
> ("mmc: msm_sdhci: Use mmc_of_parse for setting host_caps") for eMMC,
> except that the SD card does not have a property like "non-removable"
> that skips the card detection.
> 
> The SDHCI on DB410c cannot detect itself if a SD card is inserted,
> so add the necessary cd-gpios to make SD card detection work again.
> 
> While at it, fix the #gpio-cells for the soc_gpios to avoid DTC
> warnings - the soc_gpios are actually already used with two cells
> for the gpio-leds so this was just wrong all the time.
> 
> Cc: Ramon Fried 
> Signed-off-by: Stephan Gerhold 
> Reviewed-by: Ramon Fried 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 2/2] arm: snapdragon: Fix typo in clk_bcr_update()

[Tom Rini]

On Sun, Jun 20, 2021 at 10:34:35AM +0800, Sheep Sun wrote:

> Fix typo in clock-snapdragon.c
> 
> Signed-off-by: Sheep Sun 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/2] arm: snapdragon: Use correct GICC register on APQ8016

[Tom Rini]

On Sun, Jun 20, 2021 at 10:34:34AM +0800, Sheep Sun wrote:

> The GICC register used by u-boot is 0x0a20c000, which is actually a GICC
> for WCNSS, the WLAN processor. U-boot runs on the Application Processor,
> therefore it should use APCS GICC instead. Hence, correct it with APCS GICC
> register address.
> 
> Signed-off-by: Sheep Sun 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 1/8] lpc32xx: Kconfig: switch to CONFIG_CONS_INDEX

[Tom Rini]

On Thu, Jun 10, 2021 at 10:37:02PM -0400, Trevor Woerner wrote:

> There's nothing special or unique to the lpc32xx that requires its own config
> parameter for specifying the console uart index. Therefore instead of using
> the lpc32xx-specific CONFIG_SYS_LPC32XX_UART include parameter, use the
> already-available CONFIG_CONS_INDEX from Kconfig.
> 
> Signed-off-by: Trevor Woerner 
> Reviewed-by: Simon Glass 

For the series, applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v5 01/13] ata: ahci-pci: Use scsi_ops to initialize ops

[Tom Rini]

On Fri, Jun 04, 2021 at 06:43:23PM +0900, Masami Hiramatsu wrote:

> Without this fix, scsi-scan will cause a synchronous abort
> when accessing ops->scan.
> 
> Signed-off-by: Masami Hiramatsu 
> Reviewed-by: Simon Glass 

For the entire series, applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] arm: iproc: Add higher speed configurations

[Tom Rini]

On Fri, Jun 04, 2021 at 02:25:36PM +1200, Chris Packham wrote:

> Add support for 1.3GHz, 1.35GHz and 1.4GHz parts. This is based on
> equivalent code in Broadcom's LDK 5.0.6.
> 
> Signed-off-by: Chris Packham 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] ARM: integrator: Drop PCI support

[Tom Rini]

On Sat, May 15, 2021 at 02:44:19PM +0200, Linus Walleij wrote:

> We didn't convert the Integrator to use DM for PCI in
> time, and we don't use it either so let's just drop
> PCI support from the Integrator.
> 
> Signed-off-by: Linus Walleij 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] mpc8379erdb: enable DM_USB DM_PCI DM_ETH

[Tom Rini]

On Tue, May 11, 2021 at 02:18:02PM -0400, si...@writeme.com wrote:

> From: Sinan Akman 
> 
> Signed-off-by: Sinan Akman 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/3] power: pmic: Add driver for ST-Ericsson AB8500 via PRCMU

[Jaehoon Chung]

On 7/6/21 5:52 PM, Stephan Gerhold wrote:
> On Tue, Jul 06, 2021 at 10:08:03AM +0900, Jaehoon Chung wrote:
>> On 7/6/21 1:28 AM, Stephan Gerhold wrote:
>>> All devices based on ST-Ericsson Ux500 use a PMIC similar to AB8500
>>> (Analog Baseband). There is AB8500, AB8505, AB9540 and AB8540
>>> although in practice only AB8500 and AB8505 are relevant since the
>>> platforms with AB9540 and AB8540 were cancelled and never used in
>>> production.
>>>
>>> In general, the AB8500 PMIC uses I2C as control interface, where the
>>> different register banks are represented as separate I2C devices.
>>> However, in practice AB8500 is always connected to a special I2C bus
>>> on the DB8500 SoC that is controlled by the power/reset/clock
>>> management unit (PRCMU) firmware.
>>>
>>> Add a simple driver that allows reading/writing registers of the
>>> AB8500 PMIC. The driver directly accesses registers from the PRCMU
>>> parent device (represented by syscon in U-Boot). Abstracting it
>>> further (e.g. with the i2c uclass) would not provide any advantage
>>> because the PRCMU I2C bus is always just connected to AB8500 and
>>> vice-versa.
>>>
>>> The ab8500.h header is mostly taken as-is from Linux (with some
>>> minor adjustments) to allow using similar code in both Linux and
>>> U-Boot.
>>>
>>> Cc: Linus Walleij 
>>> Signed-off-by: Stephan Gerhold 
>>> ---
>>>
>>>  drivers/power/pmic/Kconfig  |  10 ++
>>>  drivers/power/pmic/Makefile |   1 +
>>>  drivers/power/pmic/ab8500.c | 258 
>>>  include/power/ab8500.h  | 125 +
>>>  4 files changed, 394 insertions(+)
>>>  create mode 100644 drivers/power/pmic/ab8500.c
>>>  create mode 100644 include/power/ab8500.h
>>>
>>> diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
>>> index 583fd3ddcd..fd6648b313 100644
>>> --- a/drivers/power/pmic/Kconfig
>>> +++ b/drivers/power/pmic/Kconfig
>>> @@ -31,6 +31,16 @@ config SPL_PMIC_CHILDREN
>>> to call your regulator code (e.g. see rk8xx.c for direct functions
>>> for use in SPL).
>>>  
>>> +config PMIC_AB8500
>>> +   bool "Enable driver for ST-Ericsson AB8500 PMIC via PRCMU"
>>> +   depends on DM_PMIC
>>> +   select REGMAP
>>> +   select SYSCON
>>> +   help
>>> + Enable support for the ST-Ericsson AB8500 (Analog Baseband) PMIC.
>>> + It connects with the ST-Ericsson DB8500 SoC via an I2C bus managed by
>>> + the power/reset/clock management unit (PRCMU) firmware.
>>> +
>>>  config PMIC_ACT8846
>>> bool "Enable support for the active-semi 8846 PMIC"
>>> depends on DM_PMIC && DM_I2C
>>> diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
>>> index 89099fde57..5d1a97e5f6 100644
>>> --- a/drivers/power/pmic/Makefile
>>> +++ b/drivers/power/pmic/Makefile
>>> @@ -15,6 +15,7 @@ obj-$(CONFIG_$(SPL_)DM_PMIC_PFUZE100) += pfuze100.o
>>>  obj-$(CONFIG_$(SPL_)DM_PMIC_PCA9450) += pca9450.o
>>>  obj-$(CONFIG_PMIC_S2MPS11) += s2mps11.o
>>>  obj-$(CONFIG_DM_PMIC_SANDBOX) += sandbox.o i2c_pmic_emul.o
>>> +obj-$(CONFIG_PMIC_AB8500) += ab8500.o
>>>  obj-$(CONFIG_PMIC_ACT8846) += act8846.o
>>>  obj-$(CONFIG_PMIC_AS3722) += as3722.o as3722_gpio.o
>>>  obj-$(CONFIG_PMIC_MAX8997) += max8997.o
>>> diff --git a/drivers/power/pmic/ab8500.c b/drivers/power/pmic/ab8500.c
>>> new file mode 100644
>>> index 00..a87a3b497c
>>> --- /dev/null
>>> +++ b/drivers/power/pmic/ab8500.c
>>> @@ -0,0 +1,258 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * Copyright (C) 2019 Stephan Gerhold
>>> + *
>>> + * Adapted from old U-Boot and Linux kernel implementation:
>>> + * Copyright (C) STMicroelectronics 2009
>>> + * Copyright (C) ST-Ericsson SA 2010
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +/* CPU mailbox registers */
>>> +#define PRCM_MBOX_CPU_VAL  0x0fc
>>> +#define PRCM_MBOX_CPU_SET  0x100
>>> +#define PRCM_MBOX_CPU_CLR  0x104
>>> +
>>> +#define PRCM_ARM_IT1_CLR   0x48C
>>> +#define PRCM_ARM_IT1_VAL   0x494
>>> +
>>> +#define PRCM_TCDM_RANGE2
>>> +#define PRCM_REQ_MB5   0xE44
>>> +#define PRCM_ACK_MB5   0xDF4
>>> +#define _PRCM_MBOX_HEADER  0xFE8
>>> +#define PRCM_MBOX_HEADER_REQ_MB5   (_PRCM_MBOX_HEADER + 0x5)
>>> +#define PRCMU_I2C_MBOX_BIT BIT(5)
>>> +
>>> +/* Mailbox 5 Requests */
>>> +#define PRCM_REQ_MB5_I2C_SLAVE_OP  (PRCM_REQ_MB5 + 0x0)
>>> +#define PRCM_REQ_MB5_I2C_HW_BITS   (PRCM_REQ_MB5 + 0x1)
>>> +#define PRCM_REQ_MB5_I2C_REG   (PRCM_REQ_MB5 + 0x2)
>>> +#define PRCM_REQ_MB5_I2C_VAL   (PRCM_REQ_MB5 + 0x3)
>>> +#define PRCMU_I2C(bank)(((bank) << 1) | BIT(6))
>>> +#define PRCMU_I2C_WRITE0
>>> +#define PRCMU_I2C_READ 1
>>> +#define PRCMU_I2C_STOP_EN  BIT(3)
>>> +
>>> +/* Mailbox 5 ACKs */
>>> +#define PRCM_ACK_MB5_I2C_STATUS  

Re: [PATCH 1/8] imx8mm: Fix USB reg addresses for i.MX8MM

[Marek Vasut]

On 7/6/21 6:11 PM, Tim Harvey wrote:

On Sun, Jul 4, 2021 at 12:25 PM Marek Vasut  wrote:


On 7/4/21 5:35 PM, Fabio Estevam wrote:

Hi Marek,


Hi,


On Sat, Jul 3, 2021 at 10:04 PM Marek Vasut  wrote:


Retrieving the USB base addresses from DT would be preferred, yes, but
the current code does not do that.


I implemented exactly that in mx6_parse_dt_addrs() , see:
4dcfa3bcbcb ("usb: ehci-mx6: Parse USB PHY and MISC offsets from DT")


We are talking about USB_BASE_ADDR, right?


All of the addresses used by the driver, I am trying hard to get rid of
all that hard-coding in the driver. They should be parsed out of DT.



Marek,

I agree with trying to get rid of all the hard-coding but not all of
us are using SPL_DM_USB. I'm not sure how to best tell who is not
using DM in the SPL.


You should be able to use PLATDATA in SPL.

The current situation in the driver is total chaos, that must be fixed. 
So, I would say in SPL -> PLATDATA , U-Boot -> DM/DT .



I know I ran into issues as I'm supporting a
family of boards with the same U-Boot and could not find a way to
switch dt's early in the SPL after I've detected via EEPROM what board
I have.


Right, the platdata should help here. Then you don't need DT.

Re: [PULL] u-boot-riscv/master

[Tom Rini]

On Wed, Jul 07, 2021 at 12:02:05AM +0800, Leo Liang wrote:

> Hi Tom,
> 
> The following changes since commit 1311dd37ecf476be041d0452d4ee38619aadd5de:
> 
>   Merge branch '2021-07-01-update-CI-containers' (2021-07-05 15:29:44 -0400)
> 
> are available in the Git repository at:
> 
>   g...@source.denx.de:u-boot/custodians/u-boot-riscv.git 
> 
> for you to fetch changes up to 4b4159d0f31ca3e0174ccfdce9a24a1fe3671829:
> 
>   board: sifive: support spl multi-dtb on unmatched board (2021-07-06 
> 20:24:26 +0800)
> 
> CI result shows no issue: 
> https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/8081
> 

Please note:
w+(openpiton_riscv64 openpiton_riscv64_spl) 
arch/riscv/dts/openpiton-riscv64.dtb: Warning (ranges_format): /soc:ranges: 
empty "ranges" property but its #address-cells (1) differs from / (2)
w+(openpiton_riscv64 openpiton_riscv64_spl) 
arch/riscv/dts/openpiton-riscv64.dtb: Warning (ranges_format): /soc:ranges: 
empty "ranges" property but its #size-cells (1) differs from / (2)

need to be fixed in a follow up PR (and the relevant dts files should be
added to the board MAINTAINER file too).  That said, applied to
u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PULL] u-boot-network/network_master

[Tom Rini]

On Tue, Jul 06, 2021 at 10:41:44AM +0300, Ramon Fried wrote:

> Hi Tom,
> 
> Please pull the latest patches in u-boot-net tree.
> It contains scattered commits to the network tree.
> 
> The following changes since commit 1311dd37ecf476be041d0452d4ee38619aadd5de:
> 
>   Merge branch '2021-07-01-update-CI-containers' (2021-07-05 15:29:44 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-net.git
> 
> for you to fetch changes up to 036e3622bf8394ff229ea0d348aa9a9a60e2c27a:
> 
>   net: dwc_eth_qos: cosmetic: remove unused define
> EQOS_DESCRIPTOR_ALIGN (2021-07-06 05:22:41 +0300)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] cmd: ums: Enable by default for sunxi

[Sean Anderson]

On 7/6/21 12:11 PM, Maxime Ripard wrote:

On Tue, Jul 06, 2021 at 04:57:32PM +0100, Andre Przywara wrote:

On Tue, 6 Jul 2021 19:56:24 +0530
Jagan Teki  wrote:

Hi Jagan,

thanks for the response!

> On Tue, Jul 6, 2021 at 4:53 AM Andre Przywara  wrote:
> >
> > The ums command (presenting a U-Boot block device as a USB mass storage
> > device) is very useful for accessing eMMC devices via USB-OTG.
> >
> > At the moment we enable USB fastboot by default for Allwinner devices,
> > so it makes sense to do the same with USB mass storage, which is
> > actually more versatile and can be accessed on any USB host easily.
> >
> > Signed-off-by: Andre Przywara 
> > ---
> >  cmd/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > index a9fb4eead29..7b1c96910a8 100644
> > --- a/cmd/Kconfig
> > +++ b/cmd/Kconfig
> > @@ -1347,6 +1347,7 @@ config CMD_USB_MASS_STORAGE
> > bool "UMS usb mass storage"
> > select USB_FUNCTION_MASS_STORAGE
> > depends on BLK && USB_GADGET
> > +   default y if ARCH_SUNXI && USB_MUSB_GADGET
>
> UMS or any secondary-emmc accessible are considered in production
> u-boot config instead of mainline u-boot since we have fastboot
> already available for this kind of purpose. This might be one of the
> reason not conisidered UMS by default till now, atleast on Allwinner.

Well, I consider fastboot inferior to UMS. I understand that
Android phone hackers use it all the time, but I think having a block
device is far more versatile - you can partition it as you like, create
and populate a filesystem, dd an image to it, extract or update
firmware, etc. - most without extra software, even on Windows or Mac.
I think fastboot offers a reboot command, but are there other killer
reasons for it?


During manufacturing it is very convenient to be able to run arbitrary
commands with ACMD/UCMD, or particular commands like partconf. Fastboot
also allows loading things directly to ram, which is nice for loading a
ramdisk/kernel when you don't have network/mass storage.

There is also no way to stop UMS other than by yanking the cord or by
hitting Ctrl-C (though I am working on this).


And having the ums command in addition to fastboot does

not hurt, both would still work.


fastboot abstracts away the storage medium, whereas UMS doesn't. You
cannot run UMS on a NAND or SPI-NOR, while this causes no issue at all
to fastboot.

Similarly, UMS exposes the whole partition to the host. You then need to
have a driver for that FS on that machine, otherwise you just can't
access it.


You can expose just one partition like

ums 0 mmc 0:2

you can also expose multiple partitions like

ums 0 mmc 0:1,0:2,0.1,0.2

--Sean


Sure, it's convenient, but it's far from being ubiquitous and the silver
bullet you claim it is.


So are there any real arguments for not adding ums as well? I am not
sure many people tweak their config, so I would like to offer a decent
out-of-the-box experience, even for casual users.


As usual, we also have to balance that with the size limit, but I'm not
sure it's an issue these days?

Maxime

Re: QEMU NUMA and U-Boot

[Heinrich Schuchardt]

On 7/6/21 6:13 PM, François Ozog wrote:

Hi Heinrich, U-Boot 2021-07rc5 does not take into account memory
description when using Qemu 5.2 NUMA configuration to adapt memory map
(kernel_addr_r...):

        -smp 4 \
          -m 8G,slots=2,maxmem=16G \
         -object memory-backend-ram,size=4G,id=m0 \
         -object memory-backend-ram,size=4G,id=m1 \
         -numa node,cpus=0-1,nodeid=0,memdev=m0 \
         -numa node,cpus=2-3,nodeid=1,memdev=m1

kernel_addr_r is still 0x404 and thus you can't use it to bootefi.

fdt addr 0x13ede6de0; fdt print

Displays fdt while I think it should not.

If I load the kernel at dram.start, the load works but not boot

U-Boot 2021.07 (Jul 06 2021 - 13:26:43 +)


DRAM:4 GiB

Flash: 64 MiB

Loading Environment from Flash... OK

In:pl011@900

Out: pl011@900

Err: pl011@900

Net: eth0: virtio-net#32

Hit any key to stop autoboot:0

=>

=> bdinfo

boot_params = 0x

DRAM bank = 0x

-> start= 0x00014000

-> size = 0x0001

flashstart= 0x

flashsize = 0x0400

flashoffset = 0x000bc990

baudrate= 115200 bps

relocaddr = 0x00013ff27000

reloc off = 0x00013ff27000

Build = 64-bit

current eth = virtio-net#32

ethaddr = 52:52:52:52:52:52

IP addr = 

fdt_blob= 0x00013ede6de0

new_fdt = 0x00013ede6de0

fdt_size= 0x0010

lmb_dump_all:

memory.cnt= 0x1

memory.reg[0x0].base = 0x14000

.size = 0x1


reserved.cnt= 0x0

arch_number = 0x

TLB addr= 0x00013fff

irq_sp= 0x00013ede6dd0

sp start= 0x00013ede6dd0

Early malloc usage: 3a8 / 2000

=> load virtio 0:1 0x14000 /oskit.efi

853424 bytes read in 1 ms (813.9 MiB/s)

=> bootefi0x14000 0x13ede6dd0

ERROR: Failed to register WaitForKey event

Setting OsIndications failed

Error: Cannot initialize UEFI sub-system, r = 9


I think there is a need to calculate memory map based on previous
firmware (TFA, QEMU can be considered as previous frimware) information
(DT or blob_list).

What do you think ?

Cheers

FF

--

François-Frédéric Ozog | /Director Business Development/
T: +33.67221.6485
francois.o...@linaro.org  | Skype: ffozog




The kernel load address is hard coded here:
include/configs/qemu-arm.h:41:  "kernel_addr_r=0x4040\0" \

bdinfo shows:
DRAM start = 0x14000
DRAM size  = 0x1

fdt addr $fdt_addr
fdt printf

shows two memory areas. One at 4000, one at 14000.

Your use case is well beyond the typical U-Boot usage. So I guess it
will be up to Linaro to provide the necessary patches:

* determine the active CPU
* determine the RAM assigned to the active CPU according
  to the numa-node-id in the device-tree
* make sure that U-Boot only uses the memory of the active CPU
  internally
* make sure that the UEFI memory map contains a compliant description
* possibly, dynamically set up the environment variables

+CC Tuomas Tynkkynen (maintainer for qemu_arm64_defconfig)

Best regards

Heinrich

Re: [PATCH] rk3399: Add basic support for helios64

[Dennis Gilmore]

I have been working on an updated version, I have cleaned up the
config a lot as well as done some work to make the -u-boot.dtsi file
smaller 
https://pagure.io/u-boot/c/2472db2eff8ba0fb262a0d0264aa9d9c7b3eca32?branch=helios64
is my current WIP patch, I have built it on top of updating the base
rk3399 dtsi files to the versions in Linux 5.13
https://pagure.io/u-boot/c/64980d20f7e728afd659d0cfce2127bbf9f2e5ee?branch=helios64

The helios64 dts file in my patch includes the patches I sent to the
Linux kernel 
https://patchwork.kernel.org/project/linux-rockchip/patch/20210701004043.18585-1-dgilm...@redhat.com/
https://patchwork.kernel.org/project/linux-rockchip/patch/20210701004043.18585-2-dgilm...@redhat.com/
https://patchwork.kernel.org/project/linux-rockchip/patch/20210701004043.18585-3-dgilm...@redhat.com/
https://patchwork.kernel.org/project/linux-rockchip/patch/20210701004043.18585-4-dgilm...@redhat.com/

Dennis

On Fri, Jun 25, 2021 at 4:32 AM Florian Klink  wrote:
>
> >It boots fine with current Fedora IoT 34 nightlies, but kernel crashes are
> >very regular (sometimes recoverable, sometimes not), which looks to me like
> >the same problem that Armbian builds have, logs seem to point to an issue
> >with the dmc frequency.
> >I've compiled an excerpt of interesting looking logs from a couple of boots
> >here (you should be able to comment on the doc as well):
> >https://hackmd.io/@lorbus/SyXTj0lXu
> >
> >Please take a look and let me know what you think.
>
> I've been running eb607cd4957fb0ef97beb2a8293478be6a54240a from
> git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git
> (which is 5.13-rc1, plus a whole bunch of helios64 and more generic
> rk3399 fixes).
>
> The system comes up. I couldn't immediately trigger any of the kernel
> crashes (except one that regularly occurs on shutdown/reboot), which I
> added to the hackmd document.
>
> I think most of the kernel issues are a concern of refining the dtb in
> the kernel itself, though, not an uboot issue per se, so not sure if
> this should block the inclusion of this patch into u-boot, which seems
> to work file (once there's a version with SPDX headers everywhere)
>
> Florian
>
> On 21-03-08 17:29:23, Christian Glombek wrote:
> >I've looked into this a bit over the weekend - my current WIP patch can be
> >found here:
> >https://src.fedoraproject.org/fork/lorbus/rpms/uboot-tools/blob/helios64/f/0001-arm-Add-support-for-Kobol-Helios64-board.patch
> >
> >It's essentially the entire devicetree used in Armbian, only that I had to
> >remove the gpio{1,2,4} initialization since `gpio-hog` doesn't appear to
> >work with upstream u-boot.
> >It boots fine with current Fedora IoT 34 nightlies, but kernel crashes are
> >very regular (sometimes recoverable, sometimes not), which looks to me like
> >the same problem that Armbian builds have, logs seem to point to an issue
> >with the dmc frequency.
> >I've compiled an excerpt of interesting looking logs from a couple of boots
> >here (you should be able to comment on the doc as well):
> >https://hackmd.io/@lorbus/SyXTj0lXu
> >
> >Please take a look and let me know what you think.
> >
> >Best regards,
> >Christian
>
> --
> Florian Klink

[PATCH v2] pci: imx: use reset-gpios if defined by device-tree

[Tim Harvey]

If reset-gpio is defined by device-tree use that if
CONFIG_PCIE_IMX_PERST_GPIO is not defined.

Note that after this the following boards which define
CONFIG_PCIE_IMX_PERST_GPIO in their board header file as well as their
device-tree should be able to remove CONFIG_PCIE_IMX_PERST_GPIO without
consequence:
 - mx6sabresd
 - mx6sxsabresd
 - novena
 - tbs2910
 - vining_2000

Note that the ge_bx50v3 board uses CONFIG_PCIE_IMX_PERST_GPIO and does
not have reset-gpios defined it it's pcie node in the dt thus removing
CONFIG_PCIE_IMX_PERST_GPIO globally can't be done until that board adds
reset-gpios.

Cc: Ian Ray  (maintainer:GE BX50V3 BOARD)
Cc: Sebastian Reichel  (maintainer:GE BX50V3 
BOARD)
Cc: Fabio Estevam  (maintainer:MX6SABRESD BOARD)
Cc: Marek Vasut  (maintainer:NOVENA BOARD)
Cc: Soeren Moch  (maintainer:TBS2910 BOARD)
Cc: Silvio Fricke  (maintainer:VINING_2000 BOARD)
Signed-off-by: Tim Harvey 
---
v2:
 - pass gpio_desc and active_high to imx6_pcie_toggle_reset to
   imx6_pcie_toggle_reset
 - move reset logic to imx6_pcie_toggle_reset to avoid code change for
   boards using CONFIG_PCIE_IMX_PERST_GPIO
 - rename gpio_active_high to reset_active_high
 - change assertion delay and post delay to match use of
   CONFIG_PCIE_IMX_PERST_GPIO codepath
---
 arch/arm/include/asm/arch-mx6/sys_proto.h |  3 ++-
 board/gateworks/gw_ventana/gw_ventana.c   |  2 +-
 drivers/pci/pcie_imx.c| 29 +++
 3 files changed, 27 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx6/sys_proto.h 
b/arch/arm/include/asm/arch-mx6/sys_proto.h
index 1e5fa1a75e..c49759af92 100644
--- a/arch/arm/include/asm/arch-mx6/sys_proto.h
+++ b/arch/arm/include/asm/arch-mx6/sys_proto.h
@@ -7,6 +7,7 @@
 #ifndef __SYS_PROTO_IMX6_
 #define __SYS_PROTO_IMX6_
 
+#include 
 #include 
 #include 
 
@@ -18,7 +19,7 @@
   USBPHY_PWD_RXPWDRX))
 
 int imx6_pcie_toggle_power(void);
-int imx6_pcie_toggle_reset(void);
+int imx6_pcie_toggle_reset(struct gpio_desc *gpio, bool active_high);
 
 enum ldo_reg {
LDO_ARM,
diff --git a/board/gateworks/gw_ventana/gw_ventana.c 
b/board/gateworks/gw_ventana/gw_ventana.c
index 5d47ca4537..47cce497fe 100644
--- a/board/gateworks/gw_ventana/gw_ventana.c
+++ b/board/gateworks/gw_ventana/gw_ventana.c
@@ -372,7 +372,7 @@ int power_init_board(void)
return 0;
 }
 
-int imx6_pcie_toggle_reset(void)
+int imx6_pcie_toggle_reset(struct gpio_desc *gpio, bool active_high)
 {
if (board_type < GW_UNKNOWN) {
uint pin = gpio_cfg[board_type].pcie_rst;
diff --git a/drivers/pci/pcie_imx.c b/drivers/pci/pcie_imx.c
index 73875e00db..7b46fdb89a 100644
--- a/drivers/pci/pcie_imx.c
+++ b/drivers/pci/pcie_imx.c
@@ -100,6 +100,8 @@
 struct imx_pcie_priv {
void __iomem*dbi_base;
void __iomem*cfg_base;
+   struct gpio_descreset_gpio;
+   boolreset_active_high;
 };
 
 /*
@@ -541,7 +543,7 @@ __weak int imx6_pcie_toggle_power(void)
return 0;
 }
 
-__weak int imx6_pcie_toggle_reset(void)
+__weak int imx6_pcie_toggle_reset(struct gpio_desc *gpio, bool active_high)
 {
/*
 * See 'PCI EXPRESS BASE SPECIFICATION, REV 3.0, SECTION 6.6.1'
@@ -579,12 +581,20 @@ __weak int imx6_pcie_toggle_reset(void)
mdelay(20);
gpio_free(CONFIG_PCIE_IMX_PERST_GPIO);
 #else
-   puts("WARNING: Make sure the PCIe #PERST line is connected!\n");
+   if (dm_gpio_is_valid(gpio)) {
+   /* Assert PERST# for 20ms then de-assert */
+   dm_gpio_set_value(gpio, active_high ? 0 : 1);
+   mdelay(20);
+   dm_gpio_set_value(gpio, active_high ? 1 : 0);
+   mdelay(20);
+   } else {
+   puts("WARNING: Make sure the PCIe #PERST line is connected!\n");
+   }
 #endif
return 0;
 }
 
-static int imx6_pcie_deassert_core_reset(void)
+static int imx6_pcie_deassert_core_reset(struct imx_pcie_priv *priv)
 {
struct iomuxc *iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR;
 
@@ -612,7 +622,7 @@ static int imx6_pcie_deassert_core_reset(void)
setbits_le32(_regs->gpr[1], IOMUXC_GPR1_REF_SSP_EN);
 #endif
 
-   imx6_pcie_toggle_reset();
+   imx6_pcie_toggle_reset(>reset_gpio, priv->reset_active_high);
 
return 0;
 }
@@ -625,7 +635,7 @@ static int imx_pcie_link_up(struct imx_pcie_priv *priv)
 
imx6_pcie_assert_core_reset(priv, false);
imx6_pcie_init_phy();
-   imx6_pcie_deassert_core_reset();
+   imx6_pcie_deassert_core_reset(priv);
 
imx_pcie_regions_setup(priv);
 
@@ -787,6 +797,15 @@ static int imx_pcie_dm_probe(struct udevice *dev)
 {
struct imx_pcie_priv *priv = dev_get_priv(dev);
 
+   /* if PERST# valid from dt then assert it */
+   gpio_request_by_name(dev, "reset-gpio", 0, >reset_gpio,
+GPIOD_IS_OUT);
+   priv->reset_active_high = dev_read_bool(dev, 

Re: [PATCH] pci: imx: use reset-gpios if defined by device-tree

[Tim Harvey]

On Sat, Jul 3, 2021 at 4:35 AM Soeren Moch  wrote:
>
> Hi Tim,
>
> On 01.07.21 19:34, Tim Harvey wrote:
> > If reset-gpio is defined by device-tree use that instead of a
> > board-specific function to toggle PCI reset.
> For me it looks like this: There is a common function that handles the
> reset. The only exception being your boards, which override this
> function to use a reset gpio dependent on the board type, fine. If you
> want to change the reset handling for your boards to a more common
> approach, why not extending the common function instead of adding an
> alternative code path?
> > The presense of 'reset-gpio' in the device-tree will override calling
> > the weak imx6_pcie_toggle_reset function therefore I've Cc'd all the
> > board maintainers who rely on that function here as I would like to
> > remove that function completely.
>
> I would prefer to keep this function for now and extend it:
> if CONFIG_PCIE_IMX_PERST_GPIO is defined, just use it. If not, try to
> use the gpio from the DT, if this also fails, complain as it is done now
> (or maybe fail completely).
> Or copy the CONFIG_PCIE_IMX_PERST_GPIO (if available) into the private
> struct in pci_init_board()/ imx_pcie_dm_probe() and simplify
> imx6_pcie_toggle_reset() to just use that value. Not sure what looks
> more elegant in the end.
>
> > The only user of a board-specific weak
> > imx6_pcie_toggle_reset is gwventana which I am the maintainer for and
> > once this patch is accepted I will be able to remove that use case and
> > would then like to remove the use of CONFIG_PCIE_IMX_PERST_GPIO
> > completely.
>
> I would see this clean-up in broader context. If we just want to rely on
> DT reset-gpio, we should remove all the non-DM code from the driver,
> together with the CONFIG_PCIE_IMX_PERST_GPIO option. I did not check, if
> any non-DM users of this driver still exist.
> >
> > I would have preferred implementing this without changing the codepath
> > for the users of CONFIG_PCIE_IMX_PERST_GPIO but that would require
> > passing in the imx_pcie_priv struct to imx6_pcie_toggle_reset which
> > creates a chicken-and-egg scenario as that's currently a weak function
> > for boards to override.
>
> I don't see any problem in changing the signature of
> imx6_pcie_toggle_reset(). You are the only external user of this
> function now, and after the changes no external user will remain.
>

Soeren,

I agree I can do this in a cleaner way. I will change
imx6_pcie_toggle_reset() to pass in the gpio_desc and use it
CONFIG_PCIE_IMX_PERST_GPIO is not defined, then I will remove my
board's override of imx6_pcie_toggle_reset.

Best regards,

Tim





> Regards,
> Soeren
> >
> > Cc: Ian Ray  (maintainer:GE BX50V3 BOARD)
> > Cc: Sebastian Reichel  (maintainer:GE 
> > BX50V3 BOARD)
> > Cc: Fabio Estevam  (maintainer:MX6SABRESD BOARD)
> > Cc: Marek Vasut  (maintainer:NOVENA BOARD)
> > Cc: Soeren Moch  (maintainer:TBS2910 BOARD)
> > Cc: Silvio Fricke  (maintainer:VINING_2000 BOARD)
> > Signed-off-by: Tim Harvey 
> > ---
> >  drivers/pci/pcie_imx.c | 24 +---
> >  1 file changed, 21 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/pci/pcie_imx.c b/drivers/pci/pcie_imx.c
> > index 73875e00db..c28951655d 100644
> > --- a/drivers/pci/pcie_imx.c
> > +++ b/drivers/pci/pcie_imx.c
> > @@ -100,6 +100,8 @@
> >  struct imx_pcie_priv {
> >   void __iomem*dbi_base;
> >   void __iomem*cfg_base;
> > + struct gpio_descreset_gpio;
> > + boolgpio_active_high;
> >  };
> >
> >  /*
> > @@ -584,7 +586,7 @@ __weak int imx6_pcie_toggle_reset(void)
> >   return 0;
> >  }
> >
> > -static int imx6_pcie_deassert_core_reset(void)
> > +static int imx6_pcie_deassert_core_reset(struct imx_pcie_priv *priv)
> >  {
> >   struct iomuxc *iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR;
> >
> > @@ -612,7 +614,14 @@ static int imx6_pcie_deassert_core_reset(void)
> >   setbits_le32(_regs->gpr[1], IOMUXC_GPR1_REF_SSP_EN);
> >  #endif
> >
> > - imx6_pcie_toggle_reset();
> > + if (dm_gpio_is_valid(>reset_gpio)) {
> > + /* Assert PERST# for 50ms then de-assert */
> > + dm_gpio_set_value(>reset_gpio, priv->gpio_active_high ? 
> > 0 : 1);
> > + mdelay(50);
> > + dm_gpio_set_value(>reset_gpio, priv->gpio_active_high ? 
> > 1 : 0);
> > + } else {
> > + imx6_pcie_toggle_reset();
> > + }
> >
> >   return 0;
> >  }
> > @@ -625,7 +634,7 @@ static int imx_pcie_link_up(struct imx_pcie_priv *priv)
> >
> >   imx6_pcie_assert_core_reset(priv, false);
> >   imx6_pcie_init_phy();
> > - imx6_pcie_deassert_core_reset();
> > + imx6_pcie_deassert_core_reset(priv);
> >
> >   imx_pcie_regions_setup(priv);
> >
> > @@ -787,6 +796,15 @@ static int imx_pcie_dm_probe(struct udevice *dev)
> >  {
> >   struct imx_pcie_priv *priv = dev_get_priv(dev);
> >
> > + /* if PERST# valid from dt then assert it */
> > +

[PATCH 2/6] binman: Support multithreading for building images

[Simon Glass]

Some images may take a while to build, e.g. if they are large and use slow
compression. Support compiling sections in parallel to speed things up.

Signed-off-by: Simon Glass 
---

 tools/binman/binman.rst   | 18 ++
 tools/binman/cmdline.py   |  4 
 tools/binman/control.py   |  4 
 tools/binman/etype/section.py | 36 ---
 tools/binman/ftest.py | 33 
 tools/binman/image.py |  3 +++
 tools/binman/state.py | 23 ++
 7 files changed, 114 insertions(+), 7 deletions(-)

diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
index bc635aa00a5..09e7b571982 100644
--- a/tools/binman/binman.rst
+++ b/tools/binman/binman.rst
@@ -1142,6 +1142,22 @@ adds a -v option to the call to binman::
make BINMAN_VERBOSE=5
 
 
+Building sections in parallel
+-
+
+By default binman uses multiprocessing to speed up compilation of large images.
+This works at a section level, with one thread for each entry in the section.
+This can speed things up if the entries are large and use compression.
+
+This feature can be disabled with the '-T' flag, which defaults to a suitable
+value for your machine. This depends on the Python version, e.g on v3.8 it uses
+12 threads on an 8-core machine. See ConcurrentFutures_ for more details.
+
+The special value -T0 selects single-threaded mode, useful for debugging during
+development, since dealing with exceptions and problems in threads is more
+difficult. This avoids any use of ThreadPoolExecutor.
+
+
 History / Credits
 -
 
@@ -1190,3 +1206,5 @@ Some ideas:
 --
 Simon Glass 
 7/7/2016
+
+.. _ConcurrentFutures: 
https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.ThreadPoolExecutor
diff --git a/tools/binman/cmdline.py b/tools/binman/cmdline.py
index 95f9ba27fbd..d6156df408b 100644
--- a/tools/binman/cmdline.py
+++ b/tools/binman/cmdline.py
@@ -32,6 +32,10 @@ controlled by a description in the board device tree.'''
 default=False, help='Display the README file')
 parser.add_argument('--toolpath', type=str, action='append',
 help='Add a path to the directories containing tools')
+parser.add_argument('-T', '--threads', type=int,
+  default=None, help='Number of threads to use (0=single-thread)')
+parser.add_argument('--test-section-timeout', action='store_true',
+  help='Use a zero timeout for section multi-threading (for testing)')
 parser.add_argument('-v', '--verbosity', default=1,
 type=int, help='Control verbosity: 0=silent, 1=warnings, 2=notices, '
 '3=info, 4=detail, 5=debug')
diff --git a/tools/binman/control.py b/tools/binman/control.py
index f57e34d..b2113b6e64f 100644
--- a/tools/binman/control.py
+++ b/tools/binman/control.py
@@ -628,9 +628,13 @@ def Binman(args):
 tools.PrepareOutputDir(args.outdir, args.preserve)
 tools.SetToolPaths(args.toolpath)
 state.SetEntryArgs(args.entry_arg)
+state.SetThreads(args.threads)
 
 images = PrepareImagesAndDtbs(dtb_fname, args.image,
   args.update_fdt, use_expanded)
+if args.test_section_timeout:
+# Set the first image to timeout, used in testThreadTimeout()
+images[list(images.keys())[0]].test_section_timeout = True
 missing = False
 for image in images.values():
 missing |= ProcessImage(image, args.update_fdt, args.map,
diff --git a/tools/binman/etype/section.py b/tools/binman/etype/section.py
index c3bac026c14..92d3f3add4c 100644
--- a/tools/binman/etype/section.py
+++ b/tools/binman/etype/section.py
@@ -9,10 +9,12 @@ images to be created.
 """
 
 from collections import OrderedDict
+import concurrent.futures
 import re
 import sys
 
 from binman.entry import Entry
+from binman import state
 from dtoc import fdt_util
 from patman import tools
 from patman import tout
@@ -525,15 +527,43 @@ class Entry_section(Entry):
 def GetEntryContents(self):
 """Call ObtainContents() for each entry in the section
 """
+def _CheckDone(entry):
+if not entry.ObtainContents():
+next_todo.append(entry)
+return entry
+
 todo = self._entries.values()
 for passnum in range(3):
+threads = state.GetThreads()
 next_todo = []
-for entry in todo:
-if not entry.ObtainContents():
-next_todo.append(entry)
+
+if threads == 0:
+for entry in todo:
+_CheckDone(entry)
+else:
+with concurrent.futures.ThreadPoolExecutor(
+max_workers=threads) as executor:
+future_to_data = {
+entry: executor.submit(_CheckDone, entry)
+

[PATCH 6/6] binman: Add basic support for debugging performance

[Simon Glass]

One of binman's attributes is that it is extremely fast, at least for a
Python program. Add some simple timing around operations that might take
a while, such as reading an image and compressing it. This should help
to maintain the performance as new features are added.

This is for debugging purposes only.

Signed-off-by: Simon Glass 
---

 tools/binman/control.py|  3 ++
 tools/binman/etype/blob.py |  5 +++
 tools/binman/ftest.py  |  8 +
 tools/binman/state.py  | 72 ++
 4 files changed, 88 insertions(+)

diff --git a/tools/binman/control.py b/tools/binman/control.py
index b2113b6e64f..dcba02ff7f8 100644
--- a/tools/binman/control.py
+++ b/tools/binman/control.py
@@ -646,6 +646,9 @@ def Binman(args):
 
 if missing:
 tout.Warning("\nSome images are invalid")
+
+# Use this to debug the time take to pack the image
+#state.TimingShow()
 finally:
 tools.FinaliseOutputDir()
 finally:
diff --git a/tools/binman/etype/blob.py b/tools/binman/etype/blob.py
index 018f8c9a319..fae86ca3ec0 100644
--- a/tools/binman/etype/blob.py
+++ b/tools/binman/etype/blob.py
@@ -6,6 +6,7 @@
 #
 
 from binman.entry import Entry
+from binman import state
 from dtoc import fdt_util
 from patman import tools
 from patman import tout
@@ -59,8 +60,12 @@ class Entry_blob(Entry):
 the data in chunks and avoid reading it all at once. For now
 this seems like an unnecessary complication.
 """
+state.TimingStart('read')
 indata = tools.ReadFile(self._pathname)
+state.TimingAccum('read')
+state.TimingStart('compress')
 data = self.CompressData(indata)
+state.TimingAccum('compress')
 self.SetContents(data)
 return True
 
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index ceaa6a8737c..d93361778ec 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -4634,6 +4634,14 @@ class TestFunctional(unittest.TestCase):
 self.assertIn("Node '/binman/section@0': Timed out obtaining contents",
   str(e.exception))
 
+def testTiming(self):
+"""Test output of timing information"""
+data = self._DoReadFile('055_sections.dts')
+with test_util.capture_sys_output() as (stdout, stderr):
+state.TimingShow()
+self.assertIn('read:', stdout.getvalue())
+self.assertIn('compress:', stdout.getvalue())
+
 
 if __name__ == "__main__":
 unittest.main()
diff --git a/tools/binman/state.py b/tools/binman/state.py
index 809429fbd9d..17d72cadecb 100644
--- a/tools/binman/state.py
+++ b/tools/binman/state.py
@@ -5,8 +5,10 @@
 # Holds and modifies the state information held by binman
 #
 
+from collections import defaultdict
 import hashlib
 import re
+import time
 import threading
 
 from dtoc import fdt
@@ -60,6 +62,27 @@ allow_entry_contraction = False
 # Number of threads to use for binman (None means machine-dependent)
 num_threads = None
 
+
+class Timing:
+"""Holds information about an operation that is being timed
+
+Properties:
+name: Operation name (only one of each name is stored)
+start: Start time of operation in seconds (None if not start)
+accum:: Amount of time spent on this operation so far, in seconds
+"""
+def __init__(self, name):
+self.name = name
+self.start = None # cause an error if TimingStart() is not called
+self.accum = 0.0
+
+
+# Holds timing info for each name:
+#key: name of Timing info (Timing.name)
+#value: Timing object
+timing_info = {}
+
+
 def GetFdtForEtype(etype):
 """Get the Fdt object for a particular device-tree entry
 
@@ -444,3 +467,52 @@ def GetThreads():
 Number of threads to use (None for default, 0 for single-threaded)
 """
 return num_threads
+
+def GetTiming(name):
+"""Get the timing info for a particular operation
+
+The object is created if it does not already exist.
+
+Args:
+name: Operation name to get
+
+Returns:
+Timing object for the current thread
+"""
+threaded_name = '%s:%d' % (name, threading.get_ident())
+timing = timing_info.get(threaded_name)
+if not timing:
+timing = Timing(threaded_name)
+timing_info[threaded_name] = timing
+return timing
+
+def TimingStart(name):
+"""Start the timer for an operation
+
+Args:
+name: Operation name to start
+"""
+timing = GetTiming(name)
+timing.start = time.monotonic()
+
+def TimingAccum(name):
+"""Stop and accumlate the time for an operation
+
+This measures the time since the last TimingStart() and adds that to the
+accumulated time.
+
+Args:
+name: Operation name to start
+"""
+timing = GetTiming(name)
+timing.accum += time.monotonic() - timing.start
+
+def TimingShow():
+"""Show all timing information"""
+duration = 

[PATCH 3/6] binman: Split node-reading out from constructor in files

[Simon Glass]

The constructor should not read the node information. Move it to the
ReadNode() method instead. This allows this etype to be subclassed.

Signed-off-by: Simon Glass 
---

 tools/binman/etype/files.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/binman/etype/files.py b/tools/binman/etype/files.py
index 5db36abef0b..9b04a496a85 100644
--- a/tools/binman/etype/files.py
+++ b/tools/binman/etype/files.py
@@ -34,6 +34,9 @@ class Entry_files(Entry_section):
 from binman import state
 
 super().__init__(section, etype, node)
+
+def ReadNode(self):
+super().ReadNode()
 self._pattern = fdt_util.GetString(self._node, 'pattern')
 if not self._pattern:
 self.Raise("Missing 'pattern' property")
-- 
2.32.0.93.g670b81a890-goog

[PATCH 5/6] patman: Use bytearray instead of string

[Simon Glass]

If the process outputs a lot of data on stdout this can be quite slow,
since the bytestring is regenerated each time. Use a bytearray instead.

Signed-off-by: Simon Glass 
---

 tools/patman/cros_subprocess.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/patman/cros_subprocess.py b/tools/patman/cros_subprocess.py
index efd0a5aaf72..fdd51386856 100644
--- a/tools/patman/cros_subprocess.py
+++ b/tools/patman/cros_subprocess.py
@@ -169,11 +169,11 @@ class Popen(subprocess.Popen):
 self.stdin.close()
 if self.stdout:
 read_set.append(self.stdout)
-stdout = b''
+stdout = bytearray()
 if self.stderr and self.stderr != self.stdout:
 read_set.append(self.stderr)
-stderr = b''
-combined = b''
+stderr = bytearray()
+combined = bytearray()
 
 input_offset = 0
 while read_set or write_set:
-- 
2.32.0.93.g670b81a890-goog

[PATCH 4/6] binman: Use bytearray instead of string

[Simon Glass]

This is faster if data is being concatenated. Update the section and
collection etypes.

Signed-off-by: Simon Glass 
---

 tools/binman/etype/collection.py | 2 +-
 tools/binman/etype/section.py| 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/binman/etype/collection.py b/tools/binman/etype/collection.py
index 1625575fe98..442b40b48b3 100644
--- a/tools/binman/etype/collection.py
+++ b/tools/binman/etype/collection.py
@@ -40,7 +40,7 @@ class Entry_collection(Entry):
 """
 # Join up all the data
 self.Info('Getting contents, required=%s' % required)
-data = b''
+data = bytearray()
 for entry_phandle in self.content:
 entry_data = self.section.GetContentsByPhandle(entry_phandle, self,
required)
diff --git a/tools/binman/etype/section.py b/tools/binman/etype/section.py
index 92d3f3add4c..e2949fc9163 100644
--- a/tools/binman/etype/section.py
+++ b/tools/binman/etype/section.py
@@ -166,7 +166,7 @@ class Entry_section(Entry):
 pad_byte = (entry._pad_byte if isinstance(entry, Entry_section)
 else self._pad_byte)
 
-data = b''
+data = bytearray()
 # Handle padding before the entry
 if entry.pad_before:
 data += tools.GetBytes(self._pad_byte, entry.pad_before)
@@ -200,7 +200,7 @@ class Entry_section(Entry):
 Returns:
 Contents of the section (bytes)
 """
-section_data = b''
+section_data = bytearray()
 
 for entry in self._entries.values():
 entry_data = entry.GetData(required)
-- 
2.32.0.93.g670b81a890-goog

[PATCH 0/6] binman: Support compressing files in parallel

[Simon Glass]

When building an image with large files it makes sense to compress them in
parallel. This series adds support for this as well a few other
performance-related tweaks. It also includes support for timing of
the different types of operation (e.g. compression), for debugging
purposes.


Simon Glass (6):
  binman: Put compressed data into separate files
  binman: Support multithreading for building images
  binman: Split node-reading out from constructor in files
  binman: Use bytearray instead of string
  patman: Use bytearray instead of string
  binman: Add basic support for debugging performance

 tools/binman/binman.rst  | 18 ++
 tools/binman/cmdline.py  |  4 ++
 tools/binman/control.py  |  7 +++
 tools/binman/etype/blob.py   |  5 ++
 tools/binman/etype/collection.py |  2 +-
 tools/binman/etype/files.py  |  3 +
 tools/binman/etype/section.py| 40 --
 tools/binman/ftest.py| 41 --
 tools/binman/image.py|  3 +
 tools/binman/state.py| 95 
 tools/patman/cros_subprocess.py  |  6 +-
 tools/patman/tools.py|  9 ++-
 12 files changed, 218 insertions(+), 15 deletions(-)

-- 
2.32.0.93.g670b81a890-goog

[PATCH 1/6] binman: Put compressed data into separate files

[Simon Glass]

At present compression uses the same temporary file for all invocations.
With multithreading this causes the data to become corrupted. Use a
different filename each time.

Signed-off-by: Simon Glass 
---

 tools/patman/tools.py | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/patman/tools.py b/tools/patman/tools.py
index ec95a543bd9..877e37cd8da 100644
--- a/tools/patman/tools.py
+++ b/tools/patman/tools.py
@@ -466,6 +466,9 @@ def Compress(indata, algo, with_header=True):
 This requires 'lz4' and 'lzma_alone' tools. It also requires an output
 directory to be previously set up, by calling PrepareOutputDir().
 
+Care is taken to use unique temporary files so that this function can be
+called from multiple threads.
+
 Args:
 indata: Input data to compress
 algo: Algorithm to use ('none', 'gzip', 'lz4' or 'lzma')
@@ -475,14 +478,16 @@ def Compress(indata, algo, with_header=True):
 """
 if algo == 'none':
 return indata
-fname = GetOutputFilename('%s.comp.tmp' % algo)
+fname = tempfile.NamedTemporaryFile(prefix='%s.comp.tmp' % algo,
+dir=outdir).name
 WriteFile(fname, indata)
 if algo == 'lz4':
 data = Run('lz4', '--no-frame-crc', '-B4', '-5', '-c', fname,
binary=True)
 # cbfstool uses a very old version of lzma
 elif algo == 'lzma':
-outfname = GetOutputFilename('%s.comp.otmp' % algo)
+outfname = tempfile.NamedTemporaryFile(prefix='%s.comp.otmp' % algo,
+   dir=outdir).name
 Run('lzma_alone', 'e', fname, outfname, '-lc1', '-lp0', '-pb0', '-d8')
 data = ReadFile(outfname)
 elif algo == 'gzip':
-- 
2.32.0.93.g670b81a890-goog

[PATCH] gpio: mcp230xx: Introduce new driver

[Sebastian Reichel]

Introduce driver for I2C based MCP230xx GPIO chips, which are
quite common and already well supported by the Linux kernel.

Signed-off-by: Sebastian Reichel 
---
 drivers/gpio/Kconfig |  10 ++
 drivers/gpio/Makefile|   1 +
 drivers/gpio/mcp230xx_gpio.c | 235 +++
 3 files changed, 246 insertions(+)
 create mode 100644 drivers/gpio/mcp230xx_gpio.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index de4dc51d4b48..f93e736639bb 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -179,6 +179,16 @@ config LPC32XX_GPIO
help
  Support for the LPC32XX GPIO driver.
 
+config MCP230XX_GPIO
+   bool "MCP230XX GPIO driver"
+   depends on DM
+   help
+ Support for Microchip's MCP230XX I2C connected GPIO devices.
+ The following chips are supported:
+  - MCP23008
+  - MCP23017
+  - MCP23018
+
 config MSCC_SGPIO
bool "Microsemi Serial GPIO driver"
depends on DM_GPIO && SOC_VCOREIII
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 8541ba0b0aec..00ffcc753534 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_KIRKWOOD_GPIO)   += kw_gpio.o
 obj-$(CONFIG_KONA_GPIO)+= kona_gpio.o
 obj-$(CONFIG_MARVELL_GPIO) += mvgpio.o
 obj-$(CONFIG_MARVELL_MFP)  += mvmfp.o
+obj-$(CONFIG_MCP230XX_GPIO)+= mcp230xx_gpio.o
 obj-$(CONFIG_MXC_GPIO) += mxc_gpio.o
 obj-$(CONFIG_MXS_GPIO) += mxs_gpio.o
 obj-$(CONFIG_PCA953X)  += pca953x.o
diff --git a/drivers/gpio/mcp230xx_gpio.c b/drivers/gpio/mcp230xx_gpio.c
new file mode 100644
index ..44def86ca7d9
--- /dev/null
+++ b/drivers/gpio/mcp230xx_gpio.c
@@ -0,0 +1,235 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2021, Collabora Ltd.
+ * Copyright (C) 2021, General Electric Company
+ * Author(s): Sebastian Reichel 
+ */
+
+#define LOG_CATEGORY UCLASS_GPIO
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+enum mcp230xx_type {
+   UNKNOWN = 0,
+   MCP23008,
+   MCP23017,
+   MCP23018,
+};
+
+#define MCP230XX_IODIR 0x00
+#define MCP230XX_GPPU 0x06
+#define MCP230XX_GPIO 0x09
+#define MCP230XX_OLAT 0x0a
+
+#define BANKSIZE 8
+
+static int mcp230xx_read(struct udevice *dev, uint reg, uint offset)
+{
+   struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+   int bank = offset / BANKSIZE;
+   int mask = 1 << (offset % BANKSIZE);
+   int shift = (uc_priv->gpio_count / BANKSIZE) - 1;
+   int ret;
+
+   ret = dm_i2c_reg_read(dev, (reg << shift) + bank);
+   if (ret < 0)
+   return ret;
+   return !!(ret & mask);
+}
+
+static int mcp230xx_write(struct udevice *dev, uint reg, uint offset, bool val)
+{
+   struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+   int bank = offset / BANKSIZE;
+   int mask = 1 << (offset % BANKSIZE);
+   int shift = (uc_priv->gpio_count / BANKSIZE) - 1;
+   int regval;
+
+   regval = dm_i2c_reg_read(dev, (reg << shift) + bank);
+   if (regval  < 0)
+   return regval;
+
+   regval &= ~mask;
+   if (val)
+   regval |= mask;
+
+   return dm_i2c_reg_write(dev, (reg << shift) + bank, regval);
+}
+
+static int mcp230xx_get_value(struct udevice *dev, uint offset)
+{
+   int ret;
+
+   ret = mcp230xx_read(dev, MCP230XX_GPIO, offset);
+   if (ret < 0) {
+   dev_err(dev, "%s error: %d\n", __func__, ret);
+   return ret;
+   }
+
+   return ret;
+}
+
+static int mcp230xx_set_value(struct udevice *dev, uint offset, int val)
+{
+   int ret;
+
+   ret = mcp230xx_write(dev, MCP230XX_GPIO, offset, val);
+   if (ret < 0) {
+   dev_err(dev, "%s error: %d\n", __func__, ret);
+   return ret;
+   }
+
+   return ret;
+}
+
+static int mcp230xx_get_flags(struct udevice *dev, unsigned int offset,
+ ulong *flags)
+{
+   int direction, pullup;
+
+   pullup = mcp230xx_read(dev, MCP230XX_GPPU, offset);
+   if (pullup < 0) {
+   dev_err(dev, "%s error: %d\n", __func__, pullup);
+   return pullup;
+   }
+
+   direction = mcp230xx_read(dev, MCP230XX_IODIR, offset);
+   if (direction < 0) {
+   dev_err(dev, "%s error: %d\n", __func__, direction);
+   return direction;
+   }
+
+   *flags = direction ? GPIOD_IS_IN : GPIOD_IS_OUT;
+
+   if (pullup)
+   *flags |= GPIOD_PULL_UP;
+
+   return 0;
+}
+
+static int mcp230xx_set_flags(struct udevice *dev, uint offset, ulong flags)
+{
+   int direction = !(flags & GPIOD_IS_OUT);
+   int pullup = !!(flags & GPIOD_PULL_UP);
+   ulong supported_mask;
+   int ret;
+
+   /* Note: active-low is ignored (handled by core) */
+   supported_mask = GPIOD_ACTIVE_LOW | GPIOD_IS_IN | GPIOD_IS_OUT | 
GPIOD_PULL_UP;
+  

Re: [PATCH 1/2] w1: w1-gpio: claim the gpio with correct initial flag

[Eugen.Hristev]

On 6/23/21 5:20 PM, Eugen Hristev wrote:
> gpio_request_by_name should be called with proper flags.
> The 0 value flag is invalid, and causes bad initialization of the gpio.
> 
> Signed-off-by: Eugen Hristev 
> ---
>   drivers/w1/w1-gpio.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/w1/w1-gpio.c b/drivers/w1/w1-gpio.c
> index 3b0ead6f6d..9346f810ce 100644
> --- a/drivers/w1/w1-gpio.c
> +++ b/drivers/w1/w1-gpio.c
> @@ -156,7 +156,7 @@ static int w1_gpio_of_to_plat(struct udevice *dev)
>   struct w1_gpio_pdata *pdata = dev_get_plat(dev);
>   int ret;
>   
> - ret = gpio_request_by_name(dev, "gpios", 0, >gpio, 0);
> + ret = gpio_request_by_name(dev, "gpios", 0, >gpio, GPIOD_IS_IN);
>   if (ret < 0)
>   printf("Error claiming GPIO %d\n", ret);
>   
> 

Applied both to u-boot-atmel/master

Re: [PATCH 1/8] imx8mm: Fix USB reg addresses for i.MX8MM

[Tim Harvey]

On Sun, Jul 4, 2021 at 12:25 PM Marek Vasut  wrote:
>
> On 7/4/21 5:35 PM, Fabio Estevam wrote:
> > Hi Marek,
>
> Hi,
>
> > On Sat, Jul 3, 2021 at 10:04 PM Marek Vasut  wrote:
> >
> >>> Retrieving the USB base addresses from DT would be preferred, yes, but
> >>> the current code does not do that.
> >>
> >> I implemented exactly that in mx6_parse_dt_addrs() , see:
> >> 4dcfa3bcbcb ("usb: ehci-mx6: Parse USB PHY and MISC offsets from DT")
> >
> > We are talking about USB_BASE_ADDR, right?
>
> All of the addresses used by the driver, I am trying hard to get rid of
> all that hard-coding in the driver. They should be parsed out of DT.
>

Marek,

I agree with trying to get rid of all the hard-coding but not all of
us are using SPL_DM_USB. I'm not sure how to best tell who is not
using DM in the SPL. I know I ran into issues as I'm supporting a
family of boards with the same U-Boot and could not find a way to
switch dt's early in the SPL after I've detected via EEPROM what board
I have.

Tim

> > imx6/imx7/imxrt provide the USB_BASE_ADDR as define.
>
> That's only because they still need to be fully converted, someone needs
> to write the PHY driver for those. For MX8M, the NOP PHY driver is used.
>
> > If we remove the imx6 definition from 
> > arch/arm/include/asm/arch-mx6/imx-regs.h
> > the ehci-mx6: driver fails to build.
> >
> > I didn't want to change ehci-mx6 in this aspect, so that's why I used
> > Frieder's patch that passes
> > USB_BASE_ADDR via define for i.MX8MM too.
> >
> > Is this an acceptable solution?
>
> No, let's not do that, because that exactly un-does the attempt to get
> rid of these hard-coded addresses. Please parse the address out of DT.
> And if you run into something which might still need hard-coded
> addresses, please fix it.
>
> The ehci-mx6 is bad, let's not make it worse, lets fix it instead.
>
> >>> Without providing these defines:
> >>>
> >>> drivers/usb/host/ehci-mx6.c:254:62: error: ‘USB_BASE_ADDR’ undeclared
> >>> (first use in this function); did you mean ‘SRC_BASE_ADDR’?
> >>> 254 |  struct usbnc_regs *usbnc = (struct usbnc_regs
> >>> *)(uintptr_t)(USB_BASE_ADDR +
> >>
> >> I suspect you need CONFIG_PHY for mx8m .
> >
> > CONFIG_PHY is already selected by imx8mm_evk_defconfig.
>
> USBNC is iMX7 specific , so you cannot hit that error on iMX8M, there is
> #elif defined(CONFIG_MX7) around it.

Re: [PATCH] cmd: ums: Enable by default for sunxi

[Maxime Ripard]

On Tue, Jul 06, 2021 at 04:57:32PM +0100, Andre Przywara wrote:
> On Tue, 6 Jul 2021 19:56:24 +0530
> Jagan Teki  wrote:
> 
> Hi Jagan,
> 
> thanks for the response!
> 
> > On Tue, Jul 6, 2021 at 4:53 AM Andre Przywara  
> > wrote:
> > >
> > > The ums command (presenting a U-Boot block device as a USB mass storage
> > > device) is very useful for accessing eMMC devices via USB-OTG.
> > >
> > > At the moment we enable USB fastboot by default for Allwinner devices,
> > > so it makes sense to do the same with USB mass storage, which is
> > > actually more versatile and can be accessed on any USB host easily.
> > >
> > > Signed-off-by: Andre Przywara 
> > > ---
> > >  cmd/Kconfig | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > > index a9fb4eead29..7b1c96910a8 100644
> > > --- a/cmd/Kconfig
> > > +++ b/cmd/Kconfig
> > > @@ -1347,6 +1347,7 @@ config CMD_USB_MASS_STORAGE
> > > bool "UMS usb mass storage"
> > > select USB_FUNCTION_MASS_STORAGE
> > > depends on BLK && USB_GADGET
> > > +   default y if ARCH_SUNXI && USB_MUSB_GADGET
> > 
> > UMS or any secondary-emmc accessible are considered in production
> > u-boot config instead of mainline u-boot since we have fastboot
> > already available for this kind of purpose. This might be one of the
> > reason not conisidered UMS by default till now, atleast on Allwinner.
> 
> Well, I consider fastboot inferior to UMS. I understand that
> Android phone hackers use it all the time, but I think having a block
> device is far more versatile - you can partition it as you like, create
> and populate a filesystem, dd an image to it, extract or update
> firmware, etc. - most without extra software, even on Windows or Mac.
> I think fastboot offers a reboot command, but are there other killer
> reasons for it? And having the ums command in addition to fastboot does
> not hurt, both would still work.

fastboot abstracts away the storage medium, whereas UMS doesn't. You
cannot run UMS on a NAND or SPI-NOR, while this causes no issue at all
to fastboot.

Similarly, UMS exposes the whole partition to the host. You then need to
have a driver for that FS on that machine, otherwise you just can't
access it.

Sure, it's convenient, but it's far from being ubiquitous and the silver
bullet you claim it is.

> So are there any real arguments for not adding ums as well? I am not
> sure many people tweak their config, so I would like to offer a decent
> out-of-the-box experience, even for casual users.

As usual, we also have to balance that with the size limit, but I'm not
sure it's an issue these days?

Maxime


signature.asc
Description: PGP signature

Re: [RFC PATCH 02/28] cli: Add LIL shell

[Kostas Michalopoulos]

On 7/6/2021 6:43 PM, Tom Rini wrote:

I don't know if it's right either.  But drawing on my comment just now
and above about complex boot scripts, I also don't know if "it's sh but
quirky and incomplete, WHY DOESN'T THIS WORK RIGHT" is better than "It's
TCL?  I don't know that, let me hit stackoverflow and do a little
reading" as would be the common experience.  Especially if we document
up-front what the quirks we have are.


I think the same would happen with Tcl and LIL. LIL might look similar 
to Tcl (and it is inspired by it), but it doesn't have the same syntax. 
A big difference comes from how variables are parsed with LIL allowing 
more variables symbols than Tcl without requiring escaping which affects 
some uses like expr, so e.g. in Tcl this


set a 10 ; set b 20 ; expr $a+$b

will give back 30 however in LIL will give back 20. This is because Tcl 
parses "$a+$b" as "$a" "+" "$b" whereas LIL parses it as "$a+" "$b", 
evaluates "$a+" as an empty string (there isn't any "a+" variable), "$b" 
as 20 and then just runs expr with the single argument "20".


Kostas

[PULL] u-boot-riscv/master

[Leo Liang]

Hi Tom,

The following changes since commit 1311dd37ecf476be041d0452d4ee38619aadd5de:

  Merge branch '2021-07-01-update-CI-containers' (2021-07-05 15:29:44 -0400)

are available in the Git repository at:

  g...@source.denx.de:u-boot/custodians/u-boot-riscv.git 

for you to fetch changes up to 4b4159d0f31ca3e0174ccfdce9a24a1fe3671829:

  board: sifive: support spl multi-dtb on unmatched board (2021-07-06 20:24:26 
+0800)

CI result shows no issue: 
https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/8081


Dimitri John Ledkov (1):
  riscv: sifive: Set default fdtfile names

Green Wan (1):
  drivers: clk: sifive: fu740-prci: replace 'pciaux' with 'pcieaux'

Tianrui Wei (2):
  board: riscv: add openpiton-riscv64 SoC support
  mmc: openpiton: add piton_mmc driver

Zong Li (6):
  board: sifive: unmatched: add initial support for a platform ID EEPROM
  riscv: sifive: fu740: kconfig: Enable support for Opencores I2C controller
  riscv: sifive: fu740: Support i2c in spl
  board: sifive: Add an interface to get PCB revision
  riscv: dts: add dts for unmatched rev1
  board: sifive: support spl multi-dtb on unmatched board

 arch/riscv/Kconfig |4 +
 arch/riscv/cpu/fu740/Kconfig   |3 +
 arch/riscv/dts/Makefile|3 +-
 arch/riscv/dts/fu740-c000-u-boot.dtsi  |4 +
 .../dts/fu740-hifive-unmatched-a00-ddr-rev1.dtsi   | 1489 
 .../dts/hifive-unmatched-a00-rev1-u-boot.dtsi  |7 +
 arch/riscv/dts/hifive-unmatched-a00-rev1.dts   |4 +
 arch/riscv/dts/openpiton-riscv64.dts   |  153 ++
 arch/riscv/include/asm/arch-fu740/eeprom.h |   15 +
 board/openpiton/riscv64/Kconfig|   40 +
 board/openpiton/riscv64/MAINTAINERS|8 +
 board/openpiton/riscv64/Makefile   |5 +
 board/openpiton/riscv64/openpiton-riscv64.c|   33 +
 board/sifive/unmatched/Kconfig |1 +
 board/sifive/unmatched/Makefile|1 +
 .../sifive/unmatched/hifive-platform-i2c-eeprom.c  |  574 
 board/sifive/unmatched/spl.c   |   28 +-
 configs/openpiton_riscv64_defconfig|   76 +
 configs/openpiton_riscv64_spl_defconfig|   87 ++
 configs/sifive_unleashed_defconfig |1 +
 configs/sifive_unmatched_defconfig |5 +
 doc/board/index.rst|1 +
 doc/board/openpiton/index.rst  |9 +
 doc/board/openpiton/riscv64.rst|  376 +
 drivers/clk/sifive/fu740-prci.c|6 +-
 drivers/mmc/Kconfig|9 +
 drivers/mmc/Makefile   |1 +
 drivers/mmc/piton_mmc.c|  161 +++
 include/configs/openpiton-riscv64.h|   61 +
 include/configs/sifive-unleashed.h |1 +
 include/configs/sifive-unmatched.h |7 +
 31 files changed, 3167 insertions(+), 6 deletions(-)
 create mode 100644 arch/riscv/dts/fu740-hifive-unmatched-a00-ddr-rev1.dtsi
 create mode 100644 arch/riscv/dts/hifive-unmatched-a00-rev1-u-boot.dtsi
 create mode 100644 arch/riscv/dts/hifive-unmatched-a00-rev1.dts
 create mode 100644 arch/riscv/dts/openpiton-riscv64.dts
 create mode 100644 arch/riscv/include/asm/arch-fu740/eeprom.h
 create mode 100644 board/openpiton/riscv64/Kconfig
 create mode 100644 board/openpiton/riscv64/MAINTAINERS
 create mode 100644 board/openpiton/riscv64/Makefile
 create mode 100644 board/openpiton/riscv64/openpiton-riscv64.c
 create mode 100644 board/sifive/unmatched/hifive-platform-i2c-eeprom.c
 create mode 100644 configs/openpiton_riscv64_defconfig
 create mode 100644 configs/openpiton_riscv64_spl_defconfig
 create mode 100644 doc/board/openpiton/index.rst
 create mode 100644 doc/board/openpiton/riscv64.rst
 create mode 100644 drivers/mmc/piton_mmc.c
 create mode 100644 include/configs/openpiton-riscv64.h

 Best regards,
 Leo

Re: [RFC PATCH 05/28] cli: lil: Rename some functions to be more like TCL

[Kostas Michalopoulos]

On 7/6/2021 6:33 PM, Tom Rini wrote:

Mature?  And still without consequent error checking?  And done,
i.  e. this will never be fixed?


Intentional design by upstream, and then for the actual problem part
(error checking, test suite), Sean is saying he'll fix it, and has
started on it.


To clarify, the intentional design aspect is for the language (e.g. 
giving garbage to "expr"). The library does need better memory alloc 
checks (this is the main thing missing because i never had to use LIL on 
an environment without virtual memory... or where malloc would ever 
practically fail), though IIRC there aren't any other cases where 
failure could happen and isn't checked. Similarly i do plan on 
implementing a proper test suite (currently there is a shell script that 
runs all the examples in the source code - many examples were made to 
expose previous bugs - with two different implementations which can be 
used to find regressions in subsequent releases and differences between 
implementations, but the examples do not exhaust the code paths the 
parser could take) at some point - the latter is more likely to happen 
soon than the former.


The same applies with LIL being "done" (well, mostly done) - this is 
about the language, not the implementation which (as i mentioned in 
another email) does need improvements, especially around performance 
(which is also a reason i need to implement better automated tests).


Kostas

Re: [U-Boot] [PATCH v3 13/20] spl: nand: sunxi: use PIO instead of DMA

[Miquel Raynal]

Hi Maxime,

Maxime Ripard  wrote on Thu, 24 Jun 2021 14:05:40
+0200:

> Hi Miquel,
> 
> On Wed, Feb 28, 2018 at 08:51:55PM +0100, Miquel Raynal wrote:
> > SPL support was first written to support only the earlier generations of
> > Allwinner SoCs, and was only really enabled on the A13 / GR8. However,
> > those old SoCs had a DMA engine that has been replaced since the A31 by
> > another DMA controller that is no longer compatible.
> > 
> > Since the code directly uses that DMA controller, it cannot operate
> > properly on the later SoCs, while the NAND controller has not changed.
> > 
> > There's two paths forward, the first one would have been to add support
> > for that DMA controller too, the second to just remove the DMA usage
> > entirely and rely on PIO.
> > 
> > The later has been chosen because CPU overload at this stage is not an
> > issue and it makes the driver more generic, and easier to understand.
> > 
> > Signed-off-by: Miquel Raynal 
> > Acked-by: Boris Brezillon   
> 
> I'm a bit late to the party, but this bricks the CHIP Pro too. While
> U-Boot proper seems to be flashed properly (re-reading it from the NAND
> after flashing brings up the same CRC than the original image), the SPL
> will only read 0s.
> 
> The transfer does complete though, so maybe it's just the copy from the
> SRAM to the main memory that doesn't work?
> 
> The offset looks correct though, so I'm not sure.

Strange... I really have no idea what's going on here and especially I
don't have any suitable board with me these days to troubleshoot this.

Sorry for not being helpful at all on this one :-)

Thanks,
Miquèl

Re: [PATCH] cmd: ums: Enable by default for sunxi

[Andre Przywara]

On Tue, 6 Jul 2021 19:56:24 +0530
Jagan Teki  wrote:

Hi Jagan,

thanks for the response!

> On Tue, Jul 6, 2021 at 4:53 AM Andre Przywara  wrote:
> >
> > The ums command (presenting a U-Boot block device as a USB mass storage
> > device) is very useful for accessing eMMC devices via USB-OTG.
> >
> > At the moment we enable USB fastboot by default for Allwinner devices,
> > so it makes sense to do the same with USB mass storage, which is
> > actually more versatile and can be accessed on any USB host easily.
> >
> > Signed-off-by: Andre Przywara 
> > ---
> >  cmd/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > index a9fb4eead29..7b1c96910a8 100644
> > --- a/cmd/Kconfig
> > +++ b/cmd/Kconfig
> > @@ -1347,6 +1347,7 @@ config CMD_USB_MASS_STORAGE
> > bool "UMS usb mass storage"
> > select USB_FUNCTION_MASS_STORAGE
> > depends on BLK && USB_GADGET
> > +   default y if ARCH_SUNXI && USB_MUSB_GADGET
> 
> UMS or any secondary-emmc accessible are considered in production
> u-boot config instead of mainline u-boot since we have fastboot
> already available for this kind of purpose. This might be one of the
> reason not conisidered UMS by default till now, atleast on Allwinner.

Well, I consider fastboot inferior to UMS. I understand that
Android phone hackers use it all the time, but I think having a block
device is far more versatile - you can partition it as you like, create
and populate a filesystem, dd an image to it, extract or update
firmware, etc. - most without extra software, even on Windows or Mac.
I think fastboot offers a reboot command, but are there other killer
reasons for it? And having the ums command in addition to fastboot does
not hurt, both would still work.
So are there any real arguments for not adding ums as well? I am not
sure many people tweak their config, so I would like to offer a decent
out-of-the-box experience, even for casual users.

Thanks,
Andre

Re: [PATCH v4 0/5] stm32mp: Enable OP-TEE and TZC support in SPL

[Alex G.]

On 7/6/21 10:45 AM, Tom Rini wrote:

On Tue, Jul 06, 2021 at 10:18:44AM -0500, Alex G. wrote:


On 5/31/21 12:43 PM, Alexandru Gagniuc wrote:

The purpose of this series is to allow booting an OP-TEE image from
SPL, by corectly configuring the TrustZone (TZC) memory regions.


Any chance we could have this hit the merge window?


For clarity, does this series depend on anything that's not already
merged?


Negative. This series can be applied standalone.

Alex

Re: [RFC PATCH 02/28] cli: Add LIL shell

[Tom Rini]

On Tue, Jul 06, 2021 at 08:57:23AM -0600, Simon Glass wrote:
> Hi Michael,
> 
> On Tue, 6 Jul 2021 at 01:53, Michael Nazzareno Trimarchi
>  wrote:
> >
> > On Tue, Jul 6, 2021 at 9:46 AM Wolfgang Denk  wrote:
> > >
> > > Dear Sean,
> > >
> > > In message  you wrote:
> > > >
> > > > >>> foo() {   proc foo {first second} {
> > > > >>>   echo $1 $2  echo $first $second
> > > > >>> } }
> > > >
> > > > This is not possible. We only have eval (run) as of today. I view adding
> > > > functions as one of the most important usability improvements we can
> > > > make.
> > >
> > > Again:  this is not an issue with hush as is, but only with our
> > > resource-limited port of a nearly 20 year old version of it.
> > >
> > > Updating to a current version would fix this, in an almost 100%
> > > backward compatible way.
> >
> > Agree on this. There is another email about the LIL and how is right now
> > maintained and if the solutions that we have already in place can be just
> > updated, I don't find any valid reason to change it but update
> > seems more straightforward.
> 
> Would you be interested in taking this on? It has been talked about
> for some years...

To repeat myself, someone posting the patches to update (or more likely,
replace as a new Kconfig option and I'd be fine with a "pick old or new"
as a starting point) is the main gating factor on using a new version of
hush.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 0/5] stm32mp: Enable OP-TEE and TZC support in SPL

[Tom Rini]

On Tue, Jul 06, 2021 at 10:18:44AM -0500, Alex G. wrote:

> On 5/31/21 12:43 PM, Alexandru Gagniuc wrote:
> > The purpose of this series is to allow booting an OP-TEE image from
> > SPL, by corectly configuring the TrustZone (TZC) memory regions.
> 
> Any chance we could have this hit the merge window?

For clarity, does this series depend on anything that's not already
merged?

-- 
Tom


signature.asc
Description: PGP signature

Re: [RFC PATCH 02/28] cli: Add LIL shell

[Tom Rini]

On Tue, Jul 06, 2021 at 09:44:20AM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20210705191058.GB9516@bill-the-cat> you wrote:
> > 
> > > > foo=bar set foo bar
> > > > echo $foo   echo $foo
> > > >
> > > > if [ 1 -gt 2 ]; thenif {1 > 2} {
> > > > echo a  echo a
> > > > else} {
> > > > echo b  echo b
> > > > fi  }
> > > >
> > > > foo() { proc foo {first second} {
> > > > echo $1 $2  echo $first $second
> > > > }   }
> > > >
> > > > for file in $(ls *.c); do   foreach file [glob *.c] {
> > > > echo $file  echo $file
> > > > done}
> > > >
> > > > fact() {
> > > > if [ $1 -eq 0 ]; then
> > > > echo 1
> > > > else
> > > > echo $(($1 * $(fact $(($1 - 1)
> > > > fi
> > > > }
> > > >
> > > > proc fact {n} {
> > > > if {$n} {
> > > > expr {$n * [fact [expr 
> > > > {$n - 1}]]}
> > > > } {
> > > > return 1
> > > > }
> > > > }
> > > >
> > > > Hopefully this gives you a bit of a feel for the basic differences.
> > 
> > Which of these things, from each column, can you do in the context of
> > U-Boot?  That's important too.
> 
> Well, with a current version of hush we can do:
> 
> -> foo=bar
> -> echo $foo
> bar
> 
> -> if [ 1 -gt 2 ]; then
> >   echo a
> > else
> >   echo b
> > fi
> b
> 
> -> foo() {
> >   echo $1 $2
> > }
> -> foo bar baz
> bar baz
> 
> -> for file in $(ls *.c); do
> > echo $file
> > done
> ls: cannot access '*.c': No such file or directory
> 
> -> fact() {
> >   if [ $1 -eq 0 ]; then
> >   echo 1
> >   else
> >   echo $(($1 * $(fact $(($1 - 1)
> >   fi
> > }
> -> fact 4
> 24
> 
> 
> Oh, in the contect of U-Boot?  Well, there are of course
> limitations, but not because of the shell, but because of the fact
> that we have no concept of files, for example.
> 
> But another command interpreter will not fix this.

Yes, clearly the file based examples won't work either way, as-is.  I
was asking for what things can be done today with the implementations we
have now.

I'm pretty confident that exactly zero people have written complex
U-Boot scripts and then been happy about the experience.

> > This is I think the hard question.  A draw of the current shell is that
> > it it looks and acts like bash/sh/etc, for at least basic operations.
> > That's something that's comfortable to a large audience.  That has
> > disadvantages when people want to start doing something complex.  Sean
> > has shown that several times and he's not the only one.  LIL being
> > tcl'ish is not.
> 
> Tcl is a horror of a language for anything that is above trivial
> level.

TCL has its fans.  csh has it's fans.  The question isn't what's the
best desktop shell or general scripting language, but what's the most
useful in our environment an use cases.

> Do you really think that replacing standard shell syntax with Tcl is
> "something that's comfortable to a large audience"?  I seriously
> doubt that.

I don't know if it's right either.  But drawing on my comment just now
and above about complex boot scripts, I also don't know if "it's sh but
quirky and incomplete, WHY DOESN'T THIS WORK RIGHT" is better than "It's
TCL?  I don't know that, let me hit stackoverflow and do a little
reading" as would be the common experience.  Especially if we document
up-front what the quirks we have are.

> > Something that has "sh" syntax but also clear to the user errors when
> > trying to do something not supported would also be interesting to see.
> > It seems like a lot of the frustration from users with our shell is that
> > it's not clear where the line between "this is an sh-like shell" and
> > "no, not like that" is.
> 
> Did you run some tests on the version of hush as comes with recent
> busybox releases?  Which of our user's requirements does it fail to
> meet?

It fails to meet the requirement of having been ported to U-Boot.  I'd
joke that perhaps you can bootefi busybox, but a quick search says
that particular trick looks to still just be for python
(https://lwn.net/Articles/641244/).

-- 
Tom


signature.asc
Description: PGP signature

Re: [RFC PATCH 05/28] cli: lil: Rename some functions to be more like TCL

[Tom Rini]

On Tue, Jul 06, 2021 at 09:52:56AM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20210705185141.GA9516@bill-the-cat> you wrote:
> > 
> > I think I want to try and address this.  While with "hush" we have
> > something that's in heavy active development outside of U-Boot, with LIL
> > we have something that's mature and "done".
> 
> Mature?  And still without consequent error checking?  And done,
> i.  e. this will never be fixed?

Intentional design by upstream, and then for the actual problem part
(error checking, test suite), Sean is saying he'll fix it, and has
started on it.

> > Tracking an active outside development is HARD and requires
> > constant resync.
> 
> Based on that logic we should stop supporting Linux, and stop using
> DTs or file systems - all of these are under "active outside
> development".
> 
> This is a bogus argiment.

Alright, go and update our Kbuild integration to be in sync with current
Linux.  Or just v5.0.  I'd suggest picking up the metadata_csum support
patch but someone did say they'd try and update that (off-list) so that
ext4 filesystem made with default options in the last 5 years (not
exaggerating) work.  I'm not even going to talk about the various level
of out of sync our DTs files are but I do have some hope there will be
more re-syncs especially as it comes to more light that the DT U-Boot
uses can just be the DT the OS gets.  Then tell me it's easy to keep
this stuff in sync.  Because we certainly don't want to just
fork-and-forget again, right?  Because that's why we have both crazy
parse bugs as well as lack of now old-and-expected features.

OK, snark aside, I'm very serious here, any "we'll just import ..."
needs to have a plan to keep it up to date, or be easy enough to do such
that I can set a monthly reminder to check for and do the update.  Every
area where we don't do this is a set of problems waiting to get worse,
as we can see with the hush shell right now as it's one of the oldest
things we stopped syncing with.

> > Look at the last few
> > LIL releases.  That could be easily re-worked in to our fork if needed.
> > I see that as a positive, not a negative.
> 
> OK, this is your opinion.  Mine differs.
> 
> Please consider this as a full NAK from me when when you think of it
> as a _replacement_ (even an optional one) of the standard shell. If
> you like, have it added as an _additional_ command, of course fully
> optional and without impact on the rest of U-Boot if not
> intentionally selected.

Any new cli for U-Boot won't be a default build as a command for a long
while after it's merged.  I'm not sure how much past that point it would
further need to be to become the default cli.  And I'll even repeat what
I said elsewhere about how an sh syntax is a good user feature.  But I
really think we want a shell environment that is not actively adding new
features is a good thing, for the default.  Just how much stuff should
we be doing or need to be doing before we hand things over to the OS?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] smbios: Try CONFIG_SYS_ options before using "Unknow" as a value

[Simon Glass]

Hi Ilias,

On Mon, 5 Jul 2021 at 11:31, Ilias Apalodimas
 wrote:
>
> Simon, Bin,
>
> As Heinrich points out some of the CONFIG_SYS_* values are not representing
> the devices properly. Maybe it's a better idea to only check the .dts?
> If the values are missing we can pop a runtime warning and keep using
> 'Unknown'.

I think we should pick one of two options:

1. Fail if we don't have the info
2. Try to use CONFIG_SYS_... as the old code did

As mentioned earlier, I actually prefer 1, since then it means boards
must add the info in the DT (probably) which indicates that someone
has actually thought about it.

But if we go with 2, we may as well go all the way, and use all the
info at our disposal.

>
> On Mon, Jul 05, 2021 at 09:29:57AM -0600, Simon Glass wrote:
> > On Mon, 5 Jul 2021 at 02:49, Ilias Apalodimas
> >  wrote:
> > >
> > > SMBIOS entries for manufacturer and board can't be empty, as the spec
> > > explicitly requires a value.
> > > Instead of passing "Unknown" and "Unknown product" for the manufacturer 
> > > and
> > > product name if the .dts options are missing, try to use CONFIG_SYS_VENDOR
> > > and CONFIG_SYS_BOARD respectively.  If those are not found either warn the
> > > user at runtime and use "Unknown" for both entries.
> > >
> > > Signed-off-by: Ilias Apalodimas 
> > > ---
> > >  lib/smbios.c | 14 --
> > >  1 file changed, 8 insertions(+), 6 deletions(-)
> >
> > Reviewed-by: Simon Glass 
> >
> > I'm not quite sure what this is based on, but perhaps the code changed
> > without me noticing.
> >
> > How about adding some tests for this code?
>
> How? The only valid test we can do is that the values we expect are not "".
> But as the code is right now it will always replace "" with "Unknown"

I just mean we need unit tests for generation of smbios tablesit
is complicated enough.

Regards,
Simon

Re: [RFC PATCH 05/28] cli: lil: Rename some functions to be more like TCL

[Simon Glass]

Hi Wolfgang,

On Tue, 6 Jul 2021 at 01:53, Wolfgang Denk  wrote:
>
> Dear Tom,
>
> In message <20210705185141.GA9516@bill-the-cat> you wrote:
> >
> > I think I want to try and address this.  While with "hush" we have
> > something that's in heavy active development outside of U-Boot, with LIL
> > we have something that's mature and "done".
>
> Mature?  And still without consequent error checking?  And done,
> i.  e. this will never be fixed?
>
>
> > Tracking an active outside development is HARD and requires
> > constant resync.
>
> Based on that logic we should stop supporting Linux, and stop using
> DTs or file systems - all of these are under "active outside
> development".
>
> This is a bogus argiment.
>
>
> > Look at the last few
> > LIL releases.  That could be easily re-worked in to our fork if needed.
> > I see that as a positive, not a negative.
>
> OK, this is your opinion.  Mine differs.
>
> Please consider this as a full NAK from me when when you think of it
> as a _replacement_ (even an optional one) of the standard shell. If
> you like, have it added as an _additional_ command, of course fully
> optional and without impact on the rest of U-Boot if not
> intentionally selected.

That seems reasonable to me. There is certainly interest in these
threads in reporting hush, perhaps with a goal of upstreaming the
U-Boot-specific changes back to busybox. But so far no one has done
it...

Regards,
Simon

[PATCH 2/2] ARM: dts: stm32mp15: remove mmc alias

[Patrick Delaunay]

Remove the mmc alias no more required as the sequence number
of mmc device is used for boot_instance.

Signed-off-by: Patrick Delaunay 
---

 arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 1 -
 arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 2 --
 2 files changed, 3 deletions(-)

diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi 
b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
index 6787619290..7dcc96c19c 100644
--- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
@@ -10,7 +10,6 @@
 / {
aliases {
i2c3 = 
-   mmc0 = 
usb0 = _hs;
};
config {
diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi 
b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
index f3002e995b..46a43371bd 100644
--- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
@@ -10,8 +10,6 @@
 / {
aliases {
i2c3 = 
-   mmc0 = 
-   mmc1 = 
};
 
config {
-- 
2.25.1

[PATCH 1/2] stm32mp: use device sequence number in boot_instance variable

[Patrick Delaunay]

Use the device sequence number in boot_instance variable
and no more the SDMMC instance provided by ROM code/TF-A.

After this patch we don't need to define the mmc alias in
device tree, for example:
  mmc0 = 
  mmc1 = 
  mmc2 = 
to have a correct mapping between the ROM code boot device =
"${boot_device}${boot_instance}" and the MMC device in U-Boot.

With this patch the 'mmc0' device (used in mmc commands) is
always used when only one instance sdmmc is activated in device
tree, even if it is only the sdmmc2 or sdmmc3.

Signed-off-by: Patrick Delaunay 
---
Dependancy with [1] to have correct 'mmc' node name (sdmmc@ => mmc@)
from kernel "ARM: dts: stm32: Rename mmc controller nodes to mmc@"

[1] "arm: dts: stm32mp15: alignment with v5.13"
http://patchwork.ozlabs.org/project/uboot/list/?series=251100=*


 arch/arm/mach-stm32mp/cpu.c| 16 +-
 arch/arm/mach-stm32mp/include/mach/stm32.h |  4 +++
 board/st/stm32mp1/stm32mp1.c   | 35 +-
 3 files changed, 46 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
index 592bfd413d..f6ed2ce0e4 100644
--- a/arch/arm/mach-stm32mp/cpu.c
+++ b/arch/arm/mach-stm32mp/cpu.c
@@ -483,6 +483,11 @@ static void setup_boot_mode(void)
STM32_UART7_BASE,
STM32_UART8_BASE
};
+   const u32 sdmmc_addr[] = {
+   STM32_SDMMC1_BASE,
+   STM32_SDMMC2_BASE,
+   STM32_SDMMC3_BASE
+   };
char cmd[60];
u32 boot_ctx = readl(TAMP_BOOT_CONTEXT);
u32 boot_mode =
@@ -525,7 +530,16 @@ static void setup_boot_mode(void)
break;
case BOOT_FLASH_SD:
case BOOT_FLASH_EMMC:
-   sprintf(cmd, "%d", instance);
+   if (instance > ARRAY_SIZE(sdmmc_addr))
+   break;
+   /* search associated sdmmc node in devicetree */
+   sprintf(cmd, "mmc@%x", sdmmc_addr[instance]);
+   if (uclass_get_device_by_name(UCLASS_MMC, cmd, )) {
+   printf("mmc%d = %s not found in device tree!\n",
+  instance, cmd);
+   break;
+   }
+   sprintf(cmd, "%d", dev_seq(dev));
env_set("boot_device", "mmc");
env_set("boot_instance", cmd);
break;
diff --git a/arch/arm/mach-stm32mp/include/mach/stm32.h 
b/arch/arm/mach-stm32mp/include/mach/stm32.h
index 5fdb893b0e..c11a9903f2 100644
--- a/arch/arm/mach-stm32mp/include/mach/stm32.h
+++ b/arch/arm/mach-stm32mp/include/mach/stm32.h
@@ -32,6 +32,10 @@
 #define STM32_UART7_BASE   0x40018000
 #define STM32_UART8_BASE   0x40019000
 
+#define STM32_SDMMC1_BASE  0x58005000
+#define STM32_SDMMC2_BASE  0x58007000
+#define STM32_SDMMC3_BASE  0x48004000
+
 #define STM32_SYSRAM_BASE  0x2FFC
 #define STM32_SYSRAM_SIZE  SZ_256K
 
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 18b8870269..2faf5c81b4 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -841,6 +841,31 @@ const char *env_ext4_get_intf(void)
}
 }
 
+int mmc_get_boot(void)
+{
+   struct udevice *dev;
+   u32 boot_mode = get_bootmode();
+   unsigned int instance = (boot_mode & TAMP_BOOT_INSTANCE_MASK) - 1;
+   char cmd[20];
+   const u32 sdmmc_addr[] = {
+   STM32_SDMMC1_BASE,
+   STM32_SDMMC2_BASE,
+   STM32_SDMMC3_BASE
+   };
+
+   if (instance > ARRAY_SIZE(sdmmc_addr))
+   return 0;
+
+   /* search associated sdmmc node in devicetree */
+   snprintf(cmd, sizeof(cmd), "mmc@%x", sdmmc_addr[instance]);
+   if (uclass_get_device_by_name(UCLASS_MMC, cmd, )) {
+   log_err("mmc%d = %s not found in device tree!\n", instance, 
cmd);
+   return 0;
+   }
+
+   return dev_seq(dev);
+};
+
 const char *env_ext4_get_dev_part(void)
 {
static char *const env_dev_part =
@@ -854,22 +879,16 @@ const char *env_ext4_get_dev_part(void)
if (strlen(env_dev_part) > 0)
return env_dev_part;
 
-   u32 bootmode = get_bootmode();
-
-   return dev_part[(bootmode & TAMP_BOOT_INSTANCE_MASK) - 1];
+   return dev_part[mmc_get_boot()];
 }
 
 int mmc_get_env_dev(void)
 {
-   u32 bootmode;
-
if (CONFIG_SYS_MMC_ENV_DEV >= 0)
return CONFIG_SYS_MMC_ENV_DEV;
 
-   bootmode = get_bootmode();
-
/* use boot instance to select the correct mmc device identifier */
-   return (bootmode & TAMP_BOOT_INSTANCE_MASK) - 1;
+   return mmc_get_boot();
 }
 
 #if defined(CONFIG_OF_BOARD_SETUP)
-- 
2.25.1

Re: [PATCH v4 0/5] stm32mp: Enable OP-TEE and TZC support in SPL

[Alex G.]

On 5/31/21 12:43 PM, Alexandru Gagniuc wrote:

The purpose of this series is to allow booting an OP-TEE image from
SPL, by corectly configuring the TrustZone (TZC) memory regions.


Any chance we could have this hit the merge window?

Alex

[PATCH] rockchip: rk3328: fix booting error for nanopi-r2s

[jason416]

devices can not boot properly during SPL stage by
using microSD card which model is SDSQUNC-032G-ZN6MA.

U-Boot SPL 2021.04 (Jul 02 2021 - 19:50:12 +)
Trying to boot from MMC1
mmc_load_image_raw_sector: mmc block read error
SPL: failed to boot from all boot devices

change dts and config to support booting from ultra
high speed microSD card on nanopi-r2s.

Signed-off-by: jason416 
---
 arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi | 4 
 arch/arm/dts/rk3328-nanopi-r2s.dts | 2 +-
 configs/nanopi-r2s-rk3328_defconfig| 4 
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi 
b/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi
index 9e2ced1541..d5469748a2 100644
--- a/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi
@@ -33,6 +33,10 @@
u-boot,dm-spl;
 };
 
+_io_sdio {
+   u-boot,dm-spl;
+};
+
  {
snps,reset-gpio = < RK_PC2 GPIO_ACTIVE_LOW>;
snps,reset-active-low;
diff --git a/arch/arm/dts/rk3328-nanopi-r2s.dts 
b/arch/arm/dts/rk3328-nanopi-r2s.dts
index 5445c5cb3d..452e4764e6 100644
--- a/arch/arm/dts/rk3328-nanopi-r2s.dts
+++ b/arch/arm/dts/rk3328-nanopi-r2s.dts
@@ -323,7 +323,7 @@
bus-width = <4>;
cap-sd-highspeed;
disable-wp;
-   pinctrl-0 = <_clk>, <_cmd>, <_dectn>, 
<_bus4>;
+   pinctrl-0 = <_clk>, <_cmd>, <_dectn>, 
<_bus4>, <_gpio>;
pinctrl-names = "default";
sd-uhs-sdr12;
sd-uhs-sdr25;
diff --git a/configs/nanopi-r2s-rk3328_defconfig 
b/configs/nanopi-r2s-rk3328_defconfig
index 52996266a1..a7969bd7ab 100644
--- a/configs/nanopi-r2s-rk3328_defconfig
+++ b/configs/nanopi-r2s-rk3328_defconfig
@@ -56,6 +56,10 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
 CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MMC_IO_VOLTAGE=y
+CONFIG_SPL_MMC_IO_VOLTAGE=y
+CONFIG_MMC_UHS_SUPPORT=y
+CONFIG_SPL_MMC_UHS_SUPPORT=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_SF_DEFAULT_SPEED=2000
-- 
2.17.1

[PATCH v2] tools: Use a single target-independent config to enable OpenSSL

[Alexandru Gagniuc]

Host tool features, such as mkimage's ability to sign FIT images were
enabled or disabled based on the target configuration. However, this
misses the point of a target-agnostic host tool.

A target's ability to verify FIT signatures is independent of
mkimage's ability to create those signatures. In fact, u-boot's build
system doesn't sign images. The target code can be successfully built
without relying on any ability to sign such code.

Conversely, mkimage's ability to sign images does not require that
those images will only work on targets which support FIT verification.
Linking mkimage cryptographic features to target support for FIT
verification is misguided.

Without loss of generality, we can say that host features are and
should be independent of target features.

While we prefer that a host tool always supports the same feature set,
we recognize the following
  - some users prefer to build u-boot without a dependency on OpenSSL.
  - some distros prefer to ship mkimage without linking to OpenSSL

To allow these use cases, introduce a host-only Kconfig which is used
to select or deselect libcrypto support. Some mkimage features or some
host tools might not be available, but this shouldn't affect the
u-boot build.

I also considered setting the default of this config based on
FIT_SIGNATURE. While it would preserve the old behaviour it's also
contrary to the goals of this change. I decided to enable it by
default, so that the default build yields the most feature-complete
mkimage.

Signed-off-by: Alexandru Gagniuc 
---
Changes since v1:
  * Drop the verb "_USE_" from the Kconfig option name

 tools/Kconfig  | 11 +++
 tools/Makefile | 46 ++
 2 files changed, 41 insertions(+), 16 deletions(-)

diff --git a/tools/Kconfig b/tools/Kconfig
index b2f5012240..d6f82cd949 100644
--- a/tools/Kconfig
+++ b/tools/Kconfig
@@ -9,4 +9,15 @@ config MKIMAGE_DTC_PATH
  some cases the system dtc may not support all required features
  and the path to a different version should be given here.
 
+config TOOLS_LIBCRYPTO
+   bool "Use OpenSSL's libcrypto library for host tools"
+   default y
+   help
+ Cryptographic signature, verification, and encryption of images is
+ provided by host tools using OpenSSL's libcrypto. Select 'n' here if
+ you wish to build host tools without OpenSSL. mkimage will not have
+ the ability to sign images.
+ This selection does not affect target features, such as runtime FIT
+ signature verification.
+
 endmenu
diff --git a/tools/Makefile b/tools/Makefile
index 722355e984..e250e6f4b6 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -3,6 +3,25 @@
 # (C) Copyright 2000-2006
 # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
 
+# A note on target vs host configuration:
+#
+# Host tools can be used across multiple targets, or different configurations
+# of the same target. Thus, host tools must be able to handle any combination
+# of target configurations. To prevent having different variations of the same
+# tool, the tool build options may not depend on target configuration.
+#
+# Some linux distributions package these utilities as u-boot-tools, and it
+# would be unmaintainable to have a different tool variation for each
+# arch or configuration.
+#
+# A couple of simple rules:
+#
+# 1) Do not use target CONFIG_* options to enable or disable features in host
+#tools. Only use the configs from tools/Kconfig
+# 2) It's okay to use target configs to disable building specific tools.
+#That's as long as the features of those tools aren't modified.
+#
+
 # Enable all the config-independent tools
 ifneq ($(HOST_TOOLS_ALL),)
 CONFIG_ARCH_KIRKWOOD = y
@@ -53,30 +72,30 @@ hostprogs-y += mkenvimage
 mkenvimage-objs := mkenvimage.o os_support.o lib/crc32.o
 
 hostprogs-y += dumpimage mkimage
-hostprogs-$(CONFIG_FIT_SIGNATURE) += fit_info fit_check_sign
+hostprogs-$(CONFIG_TOOLS_LIBCRYPTO) += fit_info fit_check_sign
 
 hostprogs-$(CONFIG_CMD_BOOTEFI_SELFTEST) += file2include
 
 FIT_OBJS-$(CONFIG_FIT) := fit_common.o fit_image.o image-host.o 
common/image-fit.o
-FIT_SIG_OBJS-$(CONFIG_FIT_SIGNATURE) := image-sig-host.o common/image-fit-sig.o
-FIT_CIPHER_OBJS-$(CONFIG_FIT_CIPHER) := common/image-cipher.o
+FIT_SIG_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := image-sig-host.o 
common/image-fit-sig.o
+FIT_CIPHER_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := common/image-cipher.o
 
 # The following files are synced with upstream DTC.
 # Use synced versions from scripts/dtc/libfdt/.
 LIBFDT_OBJS := $(addprefix libfdt/, fdt.o fdt_ro.o fdt_wip.o fdt_sw.o fdt_rw.o 
\
fdt_strerror.o fdt_empty_tree.o fdt_addresses.o fdt_overlay.o)
 
-RSA_OBJS-$(CONFIG_FIT_SIGNATURE) := $(addprefix lib/rsa/, \
+RSA_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/rsa/, \
rsa-sign.o rsa-verify.o \
rsa-mod-exp.o)
 

Re: [RFC PATCH 02/28] cli: Add LIL shell

[Simon Glass]

Hi Michael,

On Tue, 6 Jul 2021 at 01:53, Michael Nazzareno Trimarchi
 wrote:
>
> On Tue, Jul 6, 2021 at 9:46 AM Wolfgang Denk  wrote:
> >
> > Dear Sean,
> >
> > In message  you wrote:
> > >
> > > >>> foo() {   proc foo {first second} {
> > > >>>   echo $1 $2  echo $first $second
> > > >>> } }
> > >
> > > This is not possible. We only have eval (run) as of today. I view adding
> > > functions as one of the most important usability improvements we can
> > > make.
> >
> > Again:  this is not an issue with hush as is, but only with our
> > resource-limited port of a nearly 20 year old version of it.
> >
> > Updating to a current version would fix this, in an almost 100%
> > backward compatible way.
>
> Agree on this. There is another email about the LIL and how is right now
> maintained and if the solutions that we have already in place can be just
> updated, I don't find any valid reason to change it but update
> seems more straightforward.

Would you be interested in taking this on? It has been talked about
for some years...

Regards,
Simon

[PATCH 3/4] mmc: arm_pl180_mmci: Simplify code using mmc_of_parse()

[Stephan Gerhold]

Simplify the code a bit by using the common mmc_of_parse() function
instead of duplicating the device tree parsing code. We can still get
a default value for cfg->f_max by assigning it before calling
mmc_of_parse().

Another advantage of this refactoring is that we parse more properties
now, e.g. "non-removable" can be used to disable CD entirely.

Signed-off-by: Stephan Gerhold 
---

 drivers/mmc/arm_pl180_mmci.c | 19 ---
 1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index e632eed03f..809b86570a 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -424,7 +424,6 @@ static int arm_pl180_mmc_probe(struct udevice *dev)
struct pl180_mmc_host *host = dev_get_priv(dev);
struct mmc_config *cfg = >cfg;
struct clk clk;
-   u32 bus_width;
u32 periphid;
int ret;
 
@@ -457,24 +456,14 @@ static int arm_pl180_mmc_probe(struct udevice *dev)
cfg->voltages = VOLTAGE_WINDOW_SD;
cfg->host_caps = 0;
cfg->f_min = host->clock_in / (2 * (SDI_CLKCR_CLKDIV_INIT_V1 + 1));
-   cfg->f_max = dev_read_u32_default(dev, "max-frequency", MMC_CLOCK_MAX);
+   cfg->f_max = MMC_CLOCK_MAX;
cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 
gpio_request_by_name(dev, "cd-gpios", 0, >cd_gpio, GPIOD_IS_IN);
 
-   bus_width = dev_read_u32_default(dev, "bus-width", 1);
-   switch (bus_width) {
-   case 8:
-   cfg->host_caps |= MMC_MODE_8BIT;
-   /* Hosts capable of 8-bit transfers can also do 4 bits */
-   case 4:
-   cfg->host_caps |= MMC_MODE_4BIT;
-   break;
-   case 1:
-   break;
-   default:
-   dev_err(dev, "Invalid bus-width value %u\n", bus_width);
-   }
+   ret = mmc_of_parse(dev, cfg);
+   if (ret)
+   return ret;
 
arm_pl180_mmc_init(host);
mmc->priv = host;
-- 
2.32.0

[PATCH 0/4] Add support for eMMC on ST-Ericsson Ux500(v2)

[Stephan Gerhold]

This patch series adds support for the eMMC on ST-Ericsson Ux500:

  1. Some minor fixes+cleanup for the arm_pl180_mmci driver.
  3. Add the necessary configuration for ST-Ericsson Ux500v2.

This was tested on the u8500 "stemmy" board that is already present
in U-Boot.


Stephan Gerhold (4):
  mmc: arm_pl180_mmci: Don't bind to all arm,primecell devices
  mmc: arm_pl180_mmci: Simplify code using dev_read_addr_ptr()
  mmc: arm_pl180_mmci: Simplify code using mmc_of_parse()
  mmc: arm_pl180_mmci: Add configuration for ST-Ericsson Ux500v2

 drivers/mmc/arm_pl180_mmci.c | 48 
 drivers/mmc/arm_pl180_mmci.h |  1 +
 2 files changed, 22 insertions(+), 27 deletions(-)

-- 
2.32.0

[PATCH 2/4] mmc: arm_pl180_mmci: Simplify code using dev_read_addr_ptr()

[Stephan Gerhold]

Simplify the code a bit by using dev_read_addr_ptr() instead of
dev_read_addr(). This avoids having to cast explicitly to void*.

Signed-off-by: Stephan Gerhold 
---

 drivers/mmc/arm_pl180_mmci.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index 5d1ee64356..e632eed03f 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -526,14 +526,11 @@ static const struct dm_mmc_ops arm_pl180_dm_mmc_ops = {
 static int arm_pl180_mmc_of_to_plat(struct udevice *dev)
 {
struct pl180_mmc_host *host = dev_get_priv(dev);
-   fdt_addr_t addr;
 
-   addr = dev_read_addr(dev);
-   if (addr == FDT_ADDR_T_NONE)
+   host->base = dev_read_addr_ptr(dev);
+   if (!host->base)
return -EINVAL;
 
-   host->base = (void *)addr;
-
return 0;
 }
 
-- 
2.32.0

[PATCH 4/4] mmc: arm_pl180_mmci: Add configuration for ST-Ericsson Ux500v2

[Stephan Gerhold]

For the eMMC on ST-Ericsson Ux500v2 we need slightly different
configuration values. Use the existing switch statement to match
the peripheral ID of Ux500v2 (0x10480180) and override the necessary
values to make the eMMC work on devices with ST-Ericsson Ux500.

Cc: Linus Walleij 
Signed-off-by: Stephan Gerhold 
---

 drivers/mmc/arm_pl180_mmci.c | 22 +++---
 drivers/mmc/arm_pl180_mmci.h |  1 +
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index 809b86570a..f99b5f997e 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -443,22 +443,30 @@ static int arm_pl180_mmc_probe(struct udevice *dev)
SDI_CLKCR_HWFC_EN;
host->clock_in = clk_get_rate();
 
+   cfg->name = dev->name;
+   cfg->voltages = VOLTAGE_WINDOW_SD;
+   cfg->host_caps = 0;
+   cfg->f_min = host->clock_in / (2 * (SDI_CLKCR_CLKDIV_INIT_V1 + 1));
+   cfg->f_max = MMC_CLOCK_MAX;
+   cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
+
periphid = dev_read_u32_default(dev, "arm,primecell-periphid", 0);
switch (periphid) {
case STM32_MMCI_ID: /* stm32 variant */
host->version2 = false;
break;
+   case UX500V2_MMCI_ID:
+   host->pwr_init = SDI_PWR_OPD | SDI_PWR_PWRCTRL_ON;
+   host->clkdiv_init = SDI_CLKCR_CLKDIV_INIT_V2 | SDI_CLKCR_CLKEN |
+   SDI_CLKCR_HWFC_EN;
+   cfg->voltages = VOLTAGE_WINDOW_MMC;
+   cfg->f_min = host->clock_in / (2 + SDI_CLKCR_CLKDIV_INIT_V2);
+   host->version2 = true;
+   break;
default:
host->version2 = true;
}
 
-   cfg->name = dev->name;
-   cfg->voltages = VOLTAGE_WINDOW_SD;
-   cfg->host_caps = 0;
-   cfg->f_min = host->clock_in / (2 * (SDI_CLKCR_CLKDIV_INIT_V1 + 1));
-   cfg->f_max = MMC_CLOCK_MAX;
-   cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
-
gpio_request_by_name(dev, "cd-gpios", 0, >cd_gpio, GPIOD_IS_IN);
 
ret = mmc_of_parse(dev, cfg);
diff --git a/drivers/mmc/arm_pl180_mmci.h b/drivers/mmc/arm_pl180_mmci.h
index 61ee96a112..15c29beadb 100644
--- a/drivers/mmc/arm_pl180_mmci.h
+++ b/drivers/mmc/arm_pl180_mmci.h
@@ -142,6 +142,7 @@
 #define SDI_FIFO_BURST_SIZE8
 
 #define STM32_MMCI_ID  0x00880180
+#define UX500V2_MMCI_ID0x10480180
 
 struct sdi_registers {
u32 power;  /* 0x00*/
-- 
2.32.0

[PATCH 1/4] mmc: arm_pl180_mmci: Don't bind to all arm, primecell devices

[Stephan Gerhold]

The arm,primecell compatible is used for lots of different types
of devices, e.g. I2C, SPI, coresight, ... We really should not bind
the MMC driver to all of them.

Looking through the device trees in U-Boot there seems to be always
a second compatible string for the pl180 device, either arm,pl180
(already listed) or arm,pl18x. Add the "arm,pl18x" compatible to the
list but remove the generic "arm,primecell".

Note that on Linux these compatibles cannot be found in drivers
because AMBA/primecell devices are matched based on their peripheral ID
instead of the compatible.

This fixes the following error messages when booting the ST-Ericsson
U8500 "stemmy" board with the arm_pl180_mmci driver enabled:

  MMC:   ptm@801ae000 - probe failed: -38
  ptm@801af000 - probe failed: -38
  funnel@801a6000 - probe failed: -38
  tpiu@8019 - probe failed: -38
  etb@801a4000 - probe failed: -38

Cc: Patrice Chotard 
Fixes: 6f41d1a17e20 ("mmc: arm_pl180_mmci: Sync compatible with kernel")
Signed-off-by: Stephan Gerhold 
---

 drivers/mmc/arm_pl180_mmci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index b2d1b4f9aa..5d1ee64356 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -539,7 +539,7 @@ static int arm_pl180_mmc_of_to_plat(struct udevice *dev)
 
 static const struct udevice_id arm_pl180_mmc_match[] = {
{ .compatible = "arm,pl180" },
-   { .compatible = "arm,primecell" },
+   { .compatible = "arm,pl18x" },
{ /* sentinel */ }
 };
 
-- 
2.32.0

Re: [RFC PATCH 02/28] cli: Add LIL shell

[Tom Rini]

On Tue, Jul 06, 2021 at 09:46:43AM +0200, Wolfgang Denk wrote:
> Dear Sean,
> 
> In message  you wrote:
> >
> > >>> foo() { proc foo {first second} {
> > >>> echo $1 $2  echo $first $second
> > >>> }   }
> >
> > This is not possible. We only have eval (run) as of today. I view adding
> > functions as one of the most important usability improvements we can
> > make.
> 
> Again:  this is not an issue with hush as is, but only with our
> resource-limited port of a nearly 20 year old version of it.
> 
> Updating to a current version would fix this, in an almost 100%
> backward compatible way.

Let us cut to the chase then.  Who is going to port a modern version of
hush over to U-Boot, and maintain it?  If we fork and forget again,
we'll be in a bad place once again in 2-3 years.

-- 
Tom


signature.asc
Description: PGP signature

[PATCH 4/4] arm64: rk3399: r4s: disabled i2c4 bus during the system boot process

[Xiaobo Tian]

Data transmission on the I2C4 bus is not required during the system boot 
process,
so it is disabled

Signed-off-by: Xiaobo Tian 
---
 arch/arm/dts/rk3399-nanopi-r4s.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/rk3399-nanopi-r4s.dts 
b/arch/arm/dts/rk3399-nanopi-r4s.dts
index 042c73ca17..e5f57dd51a 100644
--- a/arch/arm/dts/rk3399-nanopi-r4s.dts
+++ b/arch/arm/dts/rk3399-nanopi-r4s.dts
@@ -69,6 +69,10 @@
status = "disabled";
 };
 
+ {
+   status = "disabled";
+};
+
  {
lan_led: led-1 {
gpios = < RK_PA1 GPIO_ACTIVE_HIGH>;
-- 
2.32.0

[PATCH 3/4] arm64: rk3399: r4s: Remove undesirable MAC address fetching methods for ethernet

[Xiaobo Tian]

Remove the recommended MAC address from the network card.
NanoPi R4S has a EEPROM attached to the 2nd I2C bus (U92), which stores the MAC 
address.

Signed-off-by: Xiaobo Tian 
---
 arch/arm/dts/rk3399-nanopi-r4s.dts | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/arch/arm/dts/rk3399-nanopi-r4s.dts 
b/arch/arm/dts/rk3399-nanopi-r4s.dts
index f663bc87a5..042c73ca17 100644
--- a/arch/arm/dts/rk3399-nanopi-r4s.dts
+++ b/arch/arm/dts/rk3399-nanopi-r4s.dts
@@ -17,10 +17,6 @@
model = "FriendlyElec NanoPi R4S";
compatible = "friendlyarm,nanopi-r4s", "rockchip,rk3399";
 
-   aliases {
-   ethernet1 = 
-   };
-
vdd_5v: vdd-5v {
compatible = "regulator-fixed";
regulator-name = "vdd_5v";
@@ -95,17 +91,6 @@
max-link-speed = <1>;
num-lanes = <1>;
vpcie3v3-supply = <_sys>;
-
-   pcie@0 {
-   reg = <0x 0 0 0 0>;
-   #address-cells = <3>;
-   #size-cells = <2>;
-
-   r8169: pcie@0,0 {
-   reg = <0x00 0 0 0 0>;
-   local-mac-address = [ 00 00 00 00 00 00 ];
-   };
-   };
 };
 
  {
-- 
2.32.0

[PATCH 2/4] arm64: rk3399: r4s: Inheritance uses the sdmmc definition in dtsi

[Xiaobo Tian]

The host-index-min property is invalid,
so it inherits from the sdmmc definition in dtsi.

Signed-off-by: Xiaobo Tian 
---
 arch/arm/dts/rk3399-nanopi-r4s.dts | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/dts/rk3399-nanopi-r4s.dts 
b/arch/arm/dts/rk3399-nanopi-r4s.dts
index 7470c26820..f663bc87a5 100644
--- a/arch/arm/dts/rk3399-nanopi-r4s.dts
+++ b/arch/arm/dts/rk3399-nanopi-r4s.dts
@@ -116,10 +116,6 @@
status = "disabled";
 };
 
- {
-   host-index-min = <1>;
-};
-
 _host {
phy-supply = <_5v>;
 };
-- 
2.32.0

[PATCH 1/4] arm64: rk3399: r4s: correct the LEDS label name

[Xiaobo Tian]

Correct the LEDS label name and remove the board type prefix,
which is actually unnecessary here, removes the redefined system status LED pin.

Signed-off-by: Xiaobo Tian 
---
 arch/arm/dts/rk3399-nanopi-r4s.dts | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/rk3399-nanopi-r4s.dts 
b/arch/arm/dts/rk3399-nanopi-r4s.dts
index 6f2cf17bf1..7470c26820 100644
--- a/arch/arm/dts/rk3399-nanopi-r4s.dts
+++ b/arch/arm/dts/rk3399-nanopi-r4s.dts
@@ -76,18 +76,17 @@
  {
lan_led: led-1 {
gpios = < RK_PA1 GPIO_ACTIVE_HIGH>;
-   label = "nanopi-r4s:green:lan";
+   label = "green:lan";
};
 
wan_led: led-2 {
gpios = < RK_PA0 GPIO_ACTIVE_HIGH>;
-   label = "nanopi-r4s:green:wan";
+   label = "green:wan";
};
 };
 
 _gpio {
rockchip,pins =
-   <0 RK_PB5 RK_FUNC_GPIO _pull_none>,
<1 RK_PA0 RK_FUNC_GPIO _pull_none>,
<1 RK_PA1 RK_FUNC_GPIO _pull_none>;
 };
-- 
2.32.0

Re: [PATCH] sandbox: Support signal handling only when requested

[Simon Glass]

Hi Heinrich,

On Mon, 5 Jul 2021 at 11:31, Heinrich Schuchardt  wrote:
>
> On 7/4/21 10:15 PM, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Sun, 6 Jun 2021 at 15:35, Heinrich Schuchardt  wrote:
> >>
> >> Am 6. Juni 2021 20:07:31 MESZ schrieb Sean Anderson :
> >>> On 6/6/21 1:57 PM, Heinrich Schuchardt wrote:
>  On 6/6/21 7:52 PM, Sean Anderson wrote:
> > On 6/6/21 1:28 PM, Heinrich Schuchardt wrote:
> >> On 6/6/21 6:44 PM, Simon Glass wrote:
> >>> Hi Heinrich,
> >>>
> >>> On Mon, 22 Mar 2021 at 18:56, Simon Glass 
> >>> wrote:
> 
>  Hi Heinrich,
> 
>  On Mon, 22 Mar 2021 at 23:02, Heinrich Schuchardt
>   wrote:
> >
> > On 22.03.21 06:21, Simon Glass wrote:
> >> At present if sandbox crashes it prints a message and tries to
> >> exit. But
> >> with the recently introduced signal handler, it often seems to
> >>> get
> >> stuck
> >> in a loop until the stack overflows:
> >>
> >> Segmentation violation
> >>
> >> Segmentation violation
> >>
> >> Segmentation violation
> >>
> >> Segmentation violation
> >>
> >> Segmentation violation
> >>
> >> Segmentation violation
> >>
> >> Segmentation violation
> >> ...
> >
> > Hello Simon,
> >
> > do you have a reproducible example? I never have seen this.
> 
>  https://source.denx.de/u-boot/custodians/u-boot-dm/-/jobs/242433
> 
>  You need to run that commit with pytest though...it does not
> >>> happen
>  when run directly.
> 
>  BTW this sems to expose some rather nasty bug in dlmalloc or how
> >>> it is
>  used. I notice that as soon as the first test is run, the 'top'
> >>> value
>  in dlmalloc is outside the range of the malloc pool, which seems
>  wrong. I wonder if there is something broken with how
>  dm_test_pre_run() and dm_test_post_run() work.
> 
> >
> > Corrupting gd could cause an endless recursive loop, as these
> >>> lines
> > follow printing the observed string:
> >
> >   printf("pc = 0x%lx, ", pc);
> >   printf("pc_reloc =0x%lx\n\n", pc - gd->reloc_off);
> 
>  Yes I suspect printf() is dead.
> 
> >
> > If we remove SA_NODEFER from the signal mask in
> >>> arch/sandbox/cpu/os.c,
> > recursion cannot occur anymore. If a segmentation violation
> >>> occurs
> > inside the handler it will be delegated to the default handler.
> >
> > Furthermore we could consider removing the signal handler at the
> >>> start
> > of os_signal_action().
> 
>  The issue is that if you get a segfault you really don't know if
> >>> you
>  can continue and do anything else.
> 
>  What is the goal with the signal handler? I don't think the user
> >>> can
>  do anything about it.
> >>
> >> Hello Simon,
> >>
> >> the signal handler prints out the crash location and this makes
> >> analyzing problems much easier. It proved valuable to me several
> >>> times.
> >
> > Can't you just rerun with gdb?
> 
>  This would require that the problem is easily reproducible which may
> >>> not
>  be the case.
> >>>
> >>> Hm, perhaps you could keep track of how many times we've tried to catch
> >>> a signal, and bail if this is the second time around. E.g. something
> >>> like
> >>>
> >>
> >> Removing SA_NODEFER from the signal mask will let the OS kick in if an 
> >> exception occurs in a signal handler.
> >>
> >> No counter is needed.
> >
> > Yes that is correct.
> >
> > However I am still going to apply this patch, since I would prefer
> > that the default behaviour is to exit with a signal, rather than
> > continue. It indicates some sort of error (except if we are running a
> > strange test), so it seems wrong to try to continue. It may produce
> > other issues and sandbox is in an unknown state.
> >
> > I am happy to discuss another way / patch for doing what you need.
>
>
> Your patch is not needed to exit if a signal occurs.
> If the U-Boot sandbox resets or exits is controlled by SANDBOX_CRASH_RESET.
>
> As said, to solve your problem just remove SA_NODEFER from the signal mask.

Perhaps we should discuss this on a contributor call. This thread is
getting too long...!

Regards,
Simon

[PATCH] rockchip: rk3328: fix booting error for nanopi-r2s

[Adam Lee]

>From 29cf326e24b657180e4cf90ded2366d49f33e88e Mon Sep 17 00:00:00 2001
From: jason416 
Date: Mon, 5 Jul 2021 23:22:29 +0800
Subject: [PATCH] rockchip: rk3328: fix booting error for nanopi-r2s

devices can not boot properly during SPL stage by
using microSD card which model is SDSQUNC-032G-ZN6MA.

U-Boot SPL 2021.04 (Jul 02 2021 - 19:50:12 +)
Trying to boot from MMC1
mmc_load_image_raw_sector: mmc block read error
SPL: failed to boot from all boot devices

change dts and config to support booting from ultra
high speed microSD card on nanopi-r2s.

Signed-off-by: jason416 
---
 arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi | 4 
 arch/arm/dts/rk3328-nanopi-r2s.dts | 2 +-
 configs/nanopi-r2s-rk3328_defconfig| 4 
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi b/arch/arm/dts
/rk3328-nanopi-r2s-u-boot.dtsi
index 9e2ced1541..d5469748a2 100644
--- a/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi
@@ -33,6 +33,10 @@
  u-boot,dm-spl;
 };

+_io_sdio {
+ u-boot,dm-spl;
+};
+
  {
  snps,reset-gpio = < RK_PC2 GPIO_ACTIVE_LOW>;
  snps,reset-active-low;
diff --git a/arch/arm/dts/rk3328-nanopi-r2s.dts b/arch/arm/dts/rk3328-nanopi
-r2s.dts
index 5445c5cb3d..452e4764e6 100644
--- a/arch/arm/dts/rk3328-nanopi-r2s.dts
+++ b/arch/arm/dts/rk3328-nanopi-r2s.dts
@@ -323,7 +323,7 @@
  bus-width = <4>;
  cap-sd-highspeed;
  disable-wp;
- pinctrl-0 = <_clk>, <_cmd>, <_dectn>, <_bus4>;
+ pinctrl-0 = <_clk>, <_cmd>, <_dectn>,
<_bus4>, <_gpio>;
  pinctrl-names = "default";
  sd-uhs-sdr12;
  sd-uhs-sdr25;
diff --git a/configs/nanopi-r2s-rk3328_defconfig b/configs/nanopi
-r2s-rk3328_defconfig
index 52996266a1..a7969bd7ab 100644
--- a/configs/nanopi-r2s-rk3328_defconfig
+++ b/configs/nanopi-r2s-rk3328_defconfig
@@ -56,6 +56,10 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
 CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MMC_IO_VOLTAGE=y
+CONFIG_SPL_MMC_IO_VOLTAGE=y
+CONFIG_MMC_UHS_SUPPORT=y
+CONFIG_SPL_MMC_UHS_SUPPORT=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_SF_DEFAULT_SPEED=2000
-- 
2.17.1

Re: [PATCH] cmd: ums: Enable by default for sunxi

[Jagan Teki]

On Tue, Jul 6, 2021 at 4:53 AM Andre Przywara  wrote:
>
> The ums command (presenting a U-Boot block device as a USB mass storage
> device) is very useful for accessing eMMC devices via USB-OTG.
>
> At the moment we enable USB fastboot by default for Allwinner devices,
> so it makes sense to do the same with USB mass storage, which is
> actually more versatile and can be accessed on any USB host easily.
>
> Signed-off-by: Andre Przywara 
> ---
>  cmd/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index a9fb4eead29..7b1c96910a8 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -1347,6 +1347,7 @@ config CMD_USB_MASS_STORAGE
> bool "UMS usb mass storage"
> select USB_FUNCTION_MASS_STORAGE
> depends on BLK && USB_GADGET
> +   default y if ARCH_SUNXI && USB_MUSB_GADGET

UMS or any secondary-emmc accessible are considered in production
u-boot config instead of mainline u-boot since we have fastboot
already available for this kind of purpose. This might be one of the
reason not conisidered UMS by default till now, atleast on Allwinner.

Thanks,
Jagan.

Re: [PATCH 3/3] sunxi: OrangePi Zero 2: Enable SPI booting

[Jagan Teki]

On Tue, Jul 6, 2021 at 4:35 AM Andre Przywara  wrote:
>
> The OrangePi Zero 2 board comes with 2MB of SPI flash, from which the
> BROM is supposed to be able to boot from.
>
> Enable the SPL code responsible for finding and loading U-Boot proper and
> friends, so that u-boot-sunxi-with-spl.bin can be written into the flash.
>
> Signed-off-by: Andre Przywara 
> ---

Reviewed-by: Jagan Teki 

Re: [PATCH 2/3] sunxi: SPL SPI: Add SPI boot support for the Allwinner H616 SoC

[Jagan Teki]

On Tue, Jul 6, 2021 at 4:35 AM Andre Przywara  wrote:
>
> The H616 SoC uses the same SPI IP as the H6, also shares the same clocks
> and reset bits.
> The only real difference is a slight change in the pin assignment: the
> H6 uses PC5, the H616 PC4 instead. This makes for a small change in
> our spi0_pinmux_setup() routine.
>
> Apart from that, just extend the H6 #ifdef guards to also cover the H616,
> using the shared CONFIG_SUN50I_GEN_H6 symbol.
> Also use this symbol for the Kconfig dependency.
>
> Signed-off-by: Andre Przywara 
> ---

Reviewed-by: Jagan Teki 

Re: [PATCH 1/3] sunxi: SPL SPI: Allow larger SPL

[Jagan Teki]

On Tue, Jul 6, 2021 at 4:35 AM Andre Przywara  wrote:
>
> The more recent Allwinner SoCs BootROMs can actually load SPL images
> larger than 32KB. We use this on the H616 to fit the extra code needed
> for the PMIC into the image, and have provisions in board.c to respect
> that larger SPL size when booting from MMC.
>
> However the sunxi SPL SPI loader has a hardcoded load offset of 32KB,
> which will fail on the H616.
>
> To fix this, use the same algorithm we use for MMC: if the SPL size is
> smaller than 32KB, we use 32KB, otherwise we expect the U-Boot payload
> directly after the SPL code.
>
> This prepares for SPI booting with larger SPLs like on the H616.
>
> Signed-off-by: Andre Przywara 
> ---

Reviewed-by: Jagan Teki 

[PATCH 6/6] MIPS: malta: enable PCI driver model

[Daniel Schwierzeck]

Enable DM_PCI and DM_ETH on MIPS Malta.

Signed-off-by: Daniel Schwierzeck 

---

 arch/mips/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index e54801673b..6b1f10d9a0 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -14,8 +14,11 @@ choice
 
 config TARGET_MALTA
bool "Support malta"
+   select BOARD_EARLY_INIT_R
select DM
select DM_SERIAL
+   select DM_PCI
+   select DM_ETH
select DYNAMIC_IO_PORT_BASE
select MIPS_CM
select MIPS_INSERT_BOOT_CONFIG
@@ -23,6 +26,7 @@ config TARGET_MALTA
select MIPS_L2_CACHE
select OF_CONTROL
select OF_ISA_BUS
+   select PCI_MAP_SYSTEM_MEMORY
select ROM_EXCEPTION_VECTORS
select SUPPORTS_BIG_ENDIAN
select SUPPORTS_CPU_MIPS32_R1
-- 
2.32.0

[PATCH 5/6] MIPS: malta: add support for PCI driver model

[Daniel Schwierzeck]

As almost all peripherals are connected via PCI dependent on the
used core card, PCI setup is always required. Thus run pci_init()
including PCI scanning and probing and core card specific setups
in board_early_init_r().

Also prepare support for dynamically managing the status of the
different PCI DT nodes dependent on used core card via option
CONFIG_OF_BOARD_FIXUP. Before this feature can be enabled,
the call order of the fix_fdt() init hook in board_init_f
needs to be changed. Otherwise rw_fdt_blob points to a read-only
NOR flash address. Thus this options needs to stay disabled
until the board_init_f problem could be solved. This breaks
running the default U-Boot image on real HW using the FPGA core
card but Qemu emulation still works. Currently Qemu is more
important as MIPS CI tests depend on Malta and the deadline
for PCI DM conversion will be enforced soon.

Signed-off-by: Daniel Schwierzeck 
---

 board/imgtec/malta/malta.c | 84 +-
 1 file changed, 83 insertions(+), 1 deletion(-)

diff --git a/board/imgtec/malta/malta.c b/board/imgtec/malta/malta.c
index c04f727961..e78d5a7fbc 100644
--- a/board/imgtec/malta/malta.c
+++ b/board/imgtec/malta/malta.c
@@ -4,7 +4,8 @@
  * Copyright (C) 2013 Imagination Technologies
  */
 
-#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -24,6 +25,9 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#define MALTA_GT_PATH   "/pci0@1be0"
+#define MALTA_MSC_PATH  "/pci0@1bd0"
+
 enum core_card {
CORE_UNKNOWN,
CORE_LV,
@@ -120,10 +124,12 @@ int checkboard(void)
return 0;
 }
 
+#if !IS_ENABLED(CONFIG_DM_ETH)
 int board_eth_init(struct bd_info *bis)
 {
return pci_eth_init(bis);
 }
+#endif
 
 void _machine_restart(void)
 {
@@ -167,6 +173,81 @@ int misc_init_r(void)
return 0;
 }
 
+#if IS_ENABLED(CONFIG_OF_BOARD_FIXUP)
+/*
+ * TODO: currently doesn't work because rw_fdt_blob points to a
+ * NOR flash address. This needs some changes in board_init_f.
+ */
+int board_fix_fdt(void *rw_fdt_blob)
+{
+   int node = -1;
+
+   switch (malta_sys_con()) {
+   case SYSCON_GT64120:
+   node =  fdt_path_offset(rw_fdt_blob, MALTA_GT_PATH);
+   break;
+   default:
+   case SYSCON_MSC01:
+   node =  fdt_path_offset(rw_fdt_blob, MALTA_MSC_PATH);
+   break;
+   }
+
+   return fdt_status_okay(rw_fdt_blob, node);
+}
+#endif
+
+#if IS_ENABLED(CONFIG_DM_PCI)
+int board_early_init_r(void)
+{
+   struct udevice *dev;
+   u32 val32;
+   u8 val8;
+   int ret;
+
+   pci_init();
+
+   ret = dm_pci_find_device(PCI_VENDOR_ID_INTEL,
+PCI_DEVICE_ID_INTEL_82371AB_0, 0, );
+   if (ret)
+   panic("Failed to find PIIX4 PCI bridge\n");
+
+   /* setup PCI interrupt routing */
+   dm_pci_write_config8(dev, PCI_CFG_PIIX4_PIRQRCA, 10);
+   dm_pci_write_config8(dev, PCI_CFG_PIIX4_PIRQRCB, 10);
+   dm_pci_write_config8(dev, PCI_CFG_PIIX4_PIRQRCC, 11);
+   dm_pci_write_config8(dev, PCI_CFG_PIIX4_PIRQRCD, 11);
+
+   /* mux SERIRQ onto SERIRQ pin */
+   dm_pci_read_config32(dev, PCI_CFG_PIIX4_GENCFG, );
+   val32 |= PCI_CFG_PIIX4_GENCFG_SERIRQ;
+   dm_pci_write_config32(dev, PCI_CFG_PIIX4_GENCFG, val32);
+
+   /* enable SERIRQ - Linux currently depends upon this */
+   dm_pci_read_config8(dev, PCI_CFG_PIIX4_SERIRQC, );
+   val8 |= PCI_CFG_PIIX4_SERIRQC_EN | PCI_CFG_PIIX4_SERIRQC_CONT;
+   dm_pci_write_config8(dev, PCI_CFG_PIIX4_SERIRQC, val8);
+
+   ret = dm_pci_find_device(PCI_VENDOR_ID_INTEL,
+PCI_DEVICE_ID_INTEL_82371AB, 0, );
+   if (ret)
+   panic("Failed to find PIIX4 IDE controller\n");
+
+   /* enable bus master & IO access */
+   val32 |= PCI_COMMAND_MASTER | PCI_COMMAND_IO;
+   dm_pci_write_config32(dev, PCI_COMMAND, val32);
+
+   /* set latency */
+   dm_pci_write_config8(dev, PCI_LATENCY_TIMER, 0x40);
+
+   /* enable IDE/ATA */
+   dm_pci_write_config32(dev, PCI_CFG_PIIX4_IDETIM_PRI,
+ PCI_CFG_PIIX4_IDETIM_IDE);
+   dm_pci_write_config32(dev, PCI_CFG_PIIX4_IDETIM_SEC,
+ PCI_CFG_PIIX4_IDETIM_IDE);
+
+   return 0;
+}
+#else
 void pci_init_board(void)
 {
pci_dev_t bdf;
@@ -231,3 +312,4 @@ void pci_init_board(void)
pci_write_config_dword(bdf, PCI_CFG_PIIX4_IDETIM_SEC,
   PCI_CFG_PIIX4_IDETIM_IDE);
 }
+#endif
-- 
2.32.0

[PATCH 4/6] MIPS: malta: add DT bindings for PCI host controller

[Daniel Schwierzeck]

Add DT binding for GT64120 and MSC01 PCI controllers. Only
GT64120 is enabled by default to support Qemu. The MSC01 node
will be dynamically enabled by Malta board code dependent
on the plugged core card.

Signed-off-by: Daniel Schwierzeck 
---

 arch/mips/dts/mti,malta.dts | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/mips/dts/mti,malta.dts b/arch/mips/dts/mti,malta.dts
index d339229c2a..ef47a340bb 100644
--- a/arch/mips/dts/mti,malta.dts
+++ b/arch/mips/dts/mti,malta.dts
@@ -29,4 +29,32 @@
u-boot,dm-pre-reloc;
};
};
+
+   pci0@1bd0 {
+   compatible = "mips,pci-msc01";
+   device_type = "pci";
+   reg = <0x1bd0 0x2000>;
+
+   #address-cells = <3>;
+   #size-cells = <2>;
+   bus-range = <0x0 0x0>;
+   ranges = <0x0100 0 0x 0x 0 0x80 
/* I/O */
+ 0x0200 0 0x1000 0xb000 0 0x1000   
/* MEM */>;
+
+   status = "disabled";
+   };
+
+   pci0@1be0 {
+   compatible = "marvell,pci-gt64120";
+   device_type = "pci";
+   reg = <0x1be0 0x2000>;
+
+   #address-cells = <3>;
+   #size-cells = <2>;
+   bus-range = <0x0 0x0>;
+   ranges = <0x0100 0 0x 0x 0 0x2  
/* I/O */
+ 0x0200 0 0x1000 0x1000 0 0x800
/* MEM */>;
+
+   status = "okay";
+   };
 };
-- 
2.32.0

[PATCH 3/6] pci: msc01: convert to driver model

[Daniel Schwierzeck]

This driver is currently only used on MIPS Malta boards.

Signed-off-by: Daniel Schwierzeck 
---

 drivers/pci/pci_msc01.c | 70 -
 1 file changed, 69 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pci_msc01.c b/drivers/pci/pci_msc01.c
index 04838200a8..ad203c86d0 100644
--- a/drivers/pci/pci_msc01.c
+++ b/drivers/pci/pci_msc01.c
@@ -4,7 +4,7 @@
  * Author: Paul Burton 
  */
 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -62,6 +62,7 @@ static int msc01_config_access(struct msc01_pci_controller 
*msc01,
return 0;
 }
 
+#if !IS_ENABLED(CONFIG_DM_PCI)
 static int msc01_read_config_dword(struct pci_controller *hose, pci_dev_t dev,
   int where, u32 *value)
 {
@@ -123,3 +124,70 @@ void msc01_pci_init(void *base, unsigned long sys_bus, 
unsigned long sys_phys,
pci_register_hose(hose);
hose->last_busno = pci_hose_scan(hose);
 }
+#else
+static int msc01_pci_read_config(const struct udevice *dev, pci_dev_t bdf,
+uint where, ulong *val, enum pci_size_t size)
+{
+   struct msc01_pci_controller *msc01 = dev_get_priv(dev);
+   u32 data = 0;
+
+   if (msc01_config_access(msc01, PCI_ACCESS_READ, bdf, where, )) {
+   *val = pci_get_ff(size);
+   return 0;
+   }
+
+   *val = pci_conv_32_to_size(data, where, size);
+   return 0;
+}
+
+static int msc01_pci_write_config(struct udevice *dev, pci_dev_t bdf,
+ uint where, ulong val, enum pci_size_t size)
+{
+   struct msc01_pci_controller *msc01 = dev_get_priv(dev);
+   u32 data = 0;
+
+   if (size == PCI_SIZE_32) {
+   data = val;
+   } else {
+   u32 old;
+
+   if (msc01_config_access(msc01, PCI_ACCESS_READ, bdf, where, 
))
+   return 0;
+
+   data = pci_conv_size_to_32(old, val, where, size);
+   }
+
+   msc01_config_access(msc01, PCI_ACCESS_WRITE, bdf, where, );
+   return 0;
+}
+
+static int msc01_pci_probe(struct udevice *dev)
+{
+   struct msc01_pci_controller *msc01 = dev_get_priv(dev);
+
+   msc01->base = dev_remap_addr(dev);
+   if (!msc01->base)
+   return -EINVAL;
+
+   return 0;
+}
+
+static const struct dm_pci_ops msc01_pci_ops = {
+   .read_config= msc01_pci_read_config,
+   .write_config   = msc01_pci_write_config,
+};
+
+static const struct udevice_id msc01_pci_ids[] = {
+   { .compatible = "mips,pci-msc01" },
+   { }
+};
+
+U_BOOT_DRIVER(msc01_pci) = {
+   .name   = "msc01_pci",
+   .id = UCLASS_PCI,
+   .of_match   = msc01_pci_ids,
+   .ops= _pci_ops,
+   .probe  = msc01_pci_probe,
+   .priv_auto  = sizeof(struct msc01_pci_controller),
+};
+#endif
-- 
2.32.0

[PATCH 1/6] dm: pci: add option to map virtual system memory base address

[Daniel Schwierzeck]

On MIPS the DRAM start address respectively CONFIG_SYS_SDRAM_BASE
is still used as a virtual, CPU-mapped address instead of being used
as physical address. Converting all MIPS boards and generic MIPS code
to fix that is not trivial. Due to the approaching deadline for
PCI DM conversion, this workaround is required for MIPS boards with
PCI support until the CONFIG_SYS_SDRAM_BASE issue could be solved.

Add a compile-time option to let the PCI uclass core optionally map
the DRAM address to a physical address when adding the PCI region
of type PCI_REGION_SYS_MEMORY.

Signed-off-by: Daniel Schwierzeck 
---

 drivers/pci/Kconfig  | 13 +
 drivers/pci/pci-uclass.c |  9 ++---
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index b2b7b253f8..02c34077e2 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -54,6 +54,19 @@ config PCI_REGION_MULTI_ENTRY
  region type. This helps to add support for SoC's like OcteonTX/TX2
  where every peripheral is on the PCI bus.
 
+config PCI_MAP_SYSTEM_MEMORY
+   bool "Map local system memory from a virtual base address"
+   depends on PCI || DM_PCI
+   depends on MIPS
+   default n
+   help
+ Say Y if base address of system memory is being used as a virtual 
address
+ instead of a physical address (e.g. on MIPS). The PCI core will then 
remap
+ the virtual memory base address to a physical address when adding the 
PCI
+ region of type PCI_REGION_SYS_MEMORY.
+ This should only be required on MIPS where CONFIG_SYS_SDRAM_BASE is 
still
+ being used as virtual address.
+
 config PCI_SRIOV
bool "Enable Single Root I/O Virtualization support for PCI"
depends on PCI || DM_PCI
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 22a033e632..1e2ed5426e 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -998,10 +998,13 @@ static void decode_regions(struct pci_controller *hose, 
ofnode parent_node,
 
for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) {
if (bd->bi_dram[i].size) {
+   phys_addr_t start = bd->bi_dram[i].start;
+
+   if (IS_ENABLED(CONFIG_PCI_MAP_SYSTEM_MEMORY))
+   start = virt_to_phys((void 
*)(uintptr_t)bd->bi_dram[i].start);
+
pci_set_region(hose->regions + hose->region_count++,
-  bd->bi_dram[i].start,
-  bd->bi_dram[i].start,
-  bd->bi_dram[i].size,
+  start, start, bd->bi_dram[i].size,
   PCI_REGION_MEM | PCI_REGION_SYS_MEMORY);
}
}
-- 
2.32.0

[PATCH 2/6] pci: gt64120: convert to driver model

[Daniel Schwierzeck]

This driver is currently only used on MIPS Malta boards.

Signed-off-by: Daniel Schwierzeck 
---

 drivers/pci/pci_gt64120.c | 72 ++-
 1 file changed, 71 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pci_gt64120.c b/drivers/pci/pci_gt64120.c
index 80f11fedd1..973815928b 100644
--- a/drivers/pci/pci_gt64120.c
+++ b/drivers/pci/pci_gt64120.c
@@ -8,7 +8,7 @@
  *Maciej W. Rozycki 
  */
 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -114,6 +114,7 @@ static int gt_config_access(struct gt64120_pci_controller 
*gt,
return 0;
 }
 
+#if !IS_ENABLED(CONFIG_DM_PCI)
 static int gt_read_config_dword(struct pci_controller *hose, pci_dev_t dev,
int where, u32 *value)
 {
@@ -175,3 +176,72 @@ void gt64120_pci_init(void *regs, unsigned long sys_bus, 
unsigned long sys_phys,
pci_register_hose(hose);
hose->last_busno = pci_hose_scan(hose);
 }
+#else
+static int gt64120_pci_read_config(const struct udevice *dev, pci_dev_t bdf,
+  uint where, ulong *val,
+  enum pci_size_t size)
+{
+   struct gt64120_pci_controller *gt = dev_get_priv(dev);
+   u32 data = 0;
+
+   if (gt_config_access(gt, PCI_ACCESS_READ, bdf, where, )) {
+   *val = pci_get_ff(size);
+   return 0;
+   }
+
+   *val = pci_conv_32_to_size(data, where, size);
+   return 0;
+}
+
+static int gt64120_pci_write_config(struct udevice *dev, pci_dev_t bdf,
+   uint where, ulong val,
+   enum pci_size_t size)
+{
+   struct gt64120_pci_controller *gt = dev_get_priv(dev);
+   u32 data = 0;
+
+   if (size == PCI_SIZE_32) {
+   data = val;
+   } else {
+   u32 old;
+
+   if (gt_config_access(gt, PCI_ACCESS_READ, bdf, where, ))
+   return 0;
+
+   data = pci_conv_size_to_32(old, val, where, size);
+   }
+
+   gt_config_access(gt, PCI_ACCESS_WRITE, bdf, where, );
+   return 0;
+}
+
+static int gt64120_pci_probe(struct udevice *dev)
+{
+   struct gt64120_pci_controller *gt = dev_get_priv(dev);
+
+   gt->regs = dev_remap_addr(dev);
+   if (!gt->regs)
+   return -EINVAL;
+
+   return 0;
+}
+
+static const struct dm_pci_ops gt64120_pci_ops = {
+   .read_config= gt64120_pci_read_config,
+   .write_config   = gt64120_pci_write_config,
+};
+
+static const struct udevice_id gt64120_pci_ids[] = {
+   { .compatible = "marvell,pci-gt64120" },
+   { }
+};
+
+U_BOOT_DRIVER(gt64120_pci) = {
+   .name   = "gt64120_pci",
+   .id = UCLASS_PCI,
+   .of_match   = gt64120_pci_ids,
+   .ops= _pci_ops,
+   .probe  = gt64120_pci_probe,
+   .priv_auto  = sizeof(struct gt64120_pci_controller),
+};
+#endif
-- 
2.32.0

[PATCH 0/6] Convert MIPS Malta boards to PCI DM

[Daniel Schwierzeck]

This series converts the PCI host controller drivers used by MIPS
Malta and the board-specific PCI setup code to PCI driver model.
Because the AMD PCNET driver is already converted to ETH driver
model, simply enable CONFIG_DM_ETH as well.

A patch in PCI uclass core is currently required for MIPS wanting
to use PCI DM (except Octeon MIPS64) due to CONFIG_SYS_SDRAM_BASE
being used as a virtual address on all MIPS boards.

The series for now is only tested with Qemu and the GT64120 PCI
controller. The Malta Qemu tests are already covered by U-Boot CI
Support for the MSC01 controller is prepared. The used PCI controller
depends on the plugged core card (Qemu emulates the CoreLV card with
GT64120).

Dynamic selection of the according PCI DT nodes via CONFIG_OF_BOARD_FIXUP
is prepared but not yet enabled. This requires fixing of the call order of
fix_fdt() in board_init_f, otherwise the passed-in rw_fdt_blob pointer
will point to a read-only NOR flash address. I'll send a separate
RFC patch for this.

I'll send a cleanup series for removing non-DM code after the merge
windows has closed and the PCI DM conversion deadline has been
enforced.



Daniel Schwierzeck (6):
  dm: pci: add option to map virtual system memory base address
  pci: gt64120: convert to driver model
  pci: msc01: convert to driver model
  MIPS: malta: add DT bindings for PCI host controller
  MIPS: malta: add support for PCI driver model
  MIPS: malta: enable PCI driver model

 arch/mips/Kconfig   |  4 ++
 arch/mips/dts/mti,malta.dts | 28 +
 board/imgtec/malta/malta.c  | 84 -
 drivers/pci/Kconfig | 13 ++
 drivers/pci/pci-uclass.c|  9 ++--
 drivers/pci/pci_gt64120.c   | 72 ++-
 drivers/pci/pci_msc01.c | 70 ++-
 7 files changed, 274 insertions(+), 6 deletions(-)

-- 
2.32.0

Re: [ANN] U-Boot v2021.07 released

[Trevor Woerner]

On Tue, Jul 6, 2021 at 9:06 AM Tom Rini  wrote:

> On Tue, Jul 06, 2021 at 02:41:45AM -0400, Trevor Woerner wrote:
> > On Mon, Jul 5, 2021 at 11:13 AM Tom Rini  wrote:
> >
> > > It is release day and here is the v2021.07 release.
> > >
> > > The merge window is once again open and I plan to tag -rc1 on Monday,
> > > July 26th, bi-weekly -rcs thereafter and final release on October 4th,
> > > 2021.
> > >
> > > I am merging the next branch to master shortly and will send a separate
> > > email when that is done.
> > >
> >
> > Is there something I forgot to do in order to get my lpc32xx series in?
> > https://patchwork.ozlabs.org/project/uboot/list/?series=248264
>
> A good question.  I had hoped to get a chance to pickup platform stuff
> for next, but did not.  My plan right now is:
> - General CI updates (now in)
> - Update to gcc-11/clang-11 (I know clang-12 is out, but, one step at a
>   time) which I'm testing now.
> - Platform updates
> - Kick-around how USB_HOST is used, to deal with the DM_USB migration
>   deadline warning for Nokia N900
> - Platform removals
>

Great, thanks for the update :-)

Re: [ANN] U-Boot v2021.07 released

[Tom Rini]

On Tue, Jul 06, 2021 at 02:41:45AM -0400, Trevor Woerner wrote:
> On Mon, Jul 5, 2021 at 11:13 AM Tom Rini  wrote:
> 
> > It is release day and here is the v2021.07 release.
> >
> > The merge window is once again open and I plan to tag -rc1 on Monday,
> > July 26th, bi-weekly -rcs thereafter and final release on October 4th,
> > 2021.
> >
> > I am merging the next branch to master shortly and will send a separate
> > email when that is done.
> >
> 
> Is there something I forgot to do in order to get my lpc32xx series in?
> https://patchwork.ozlabs.org/project/uboot/list/?series=248264

A good question.  I had hoped to get a chance to pickup platform stuff
for next, but did not.  My plan right now is:
- General CI updates (now in)
- Update to gcc-11/clang-11 (I know clang-12 is out, but, one step at a
  time) which I'm testing now.
- Platform updates
- Kick-around how USB_HOST is used, to deal with the DM_USB migration
  deadline warning for Nokia N900
- Platform removals

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 9/9] board: phytec: imx8mp-phycore: Switch to binman

[Teresa Remmet]

Hello Jagan,

Am Montag, den 05.07.2021, 11:01 +0530 schrieb Jagan Teki:
> On Fri, Jul 2, 2021 at 4:49 PM Teresa Remmet 
> wrote:
> > Use now binman for image creation.
> > 
> > Signed-off-by: Teresa Remmet 
> > ---
> >  .../imx8mp-phyboard-pollux-rdk-u-boot.dtsi| 105
> > ++
> >  arch/arm/mach-imx/imx8m/Kconfig   |   1 +
> >  .../phytec/phycore_imx8mp/imximage-8mp-sd.cfg |  10 ++
> >  configs/phycore-imx8mp_defconfig  |   4 +-
> >  4 files changed, 118 insertions(+), 2 deletions(-)
> >  create mode 100644 board/phytec/phycore_imx8mp/imximage-8mp-sd.cfg
> > 
> > diff --git a/arch/arm/dts/imx8mp-phyboard-pollux-rdk-u-boot.dtsi
> > b/arch/arm/dts/imx8mp-phyboard-pollux-rdk-u-boot.dtsi
> > index dbc48dfb4841..2b8e77cb27c5 100644
> > --- a/arch/arm/dts/imx8mp-phyboard-pollux-rdk-u-boot.dtsi
> > +++ b/arch/arm/dts/imx8mp-phyboard-pollux-rdk-u-boot.dtsi
> > @@ -7,6 +7,10 @@
> >  #include "imx8mp-u-boot.dtsi"
> > 
> >  / {
> > +   binman: binman {
> > +   multiple-images;
> > +   };
> > +
> > wdt-reboot {
> > compatible = "wdt-reboot";
> > wdt = <>;
> > @@ -81,3 +85,104 @@
> >   {
> > u-boot,dm-spl;
> >  };
> > +
> > + {
> > +u-boot-spl-ddr {
> > +   filename = "u-boot-spl-ddr.bin";
> > +   pad-byte = <0xff>;
> > +   align-size = <4>;
> > +   align = <4>;
> > +
> > +   u-boot-spl {
> > +   align-end = <4>;
> > +   };
> > +
> > +   blob_1: blob-ext@1 {
> > +   filename =
> > "lpddr4_pmu_train_1d_imem_202006.bin";
> > +   size = <0x8000>;
> > +   };
> > +
> > +   blob_2: blob-ext@2 {
> > +   filename =
> > "lpddr4_pmu_train_1d_dmem_202006.bin";
> > +   size = <0x4000>;
> > +   };
> > +
> > +   blob_3: blob-ext@3 {
> > +   filename =
> > "lpddr4_pmu_train_2d_imem_202006.bin";
> > +   size = <0x8000>;
> > +   };
> > +
> > +   blob_4: blob-ext@4 {
> > +   filename =
> > "lpddr4_pmu_train_2d_dmem_202006.bin";
> > +   size = <0x4000>;
> > +   };
> > +   };
> > +
> > +   flash {
> > +   mkimage {
> > +   args = "-n spl/u-boot-spl.cfgout -T
> > imx8mimage -e 0x92";
> > +
> > +   blob {
> > +   filename = "u-boot-spl-ddr.bin";
> > +   };
> > +   };
> > +   };
> > +
> > +   itb {
> > +   filename = "u-boot.itb";
> > +
> > +   fit {
> > +   description = "Configuration to load ATF
> > before U-Boot";
> > +   #address-cells = <1>;
> > +   fit,external-offset =
> > ;
> > +
> > +   images {
> > +   uboot {
> > +   description = "U-Boot (64-
> > bit)";
> > +   type = "standalone";
> > +   arch = "arm64";
> > +   compression = "none";
> > +   load =
> > ;
> > +
> > +   uboot_blob: blob-ext {
> > +   filename = "u-boot-
> > nodtb.bin";
> > +   };
> > +   };
> > +
> > +   atf {
> > +   description = "ARM Trusted
> > Firmware";
> > +   type = "firmware";
> > +   arch = "arm64";
> > +   compression = "none";
> > +   load = <0x97>;
> > +   entry = <0x97>;
> > +
> > +   atf_blob: blob-ext {
> > +   filename =
> > "bl31.bin";
> > +   };
> > +   };
> > +
> > +   fdt {
> > +   description = "NAME";
> > +   type = "flat_dt";
> > +   compression = "none";
> > +
> > +   uboot_fdt_blob: blob-ext {
> > +   filename = "u-
> > boot.dtb";
> > +   };
> > +   };
> > +   };
> > +
> > +   configurations {
> > +   default = "conf";
> > +
> > +   conf {
> > +  

Re: [PATCH 6/6] board: sifive: support spl multi-dtb on unmatched board

[Leo Liang]

On Wed, Jun 30, 2021 at 11:23:50PM +0800, Zong Li wrote:
> There are two revisions of unmatched board with different DDR timing,
> we'd like to support multi-dtb mechanism in SPL, then it selects the
> right DTB at runtime according to PCB revision in I2C EEPROM.
> 
> Signed-off-by: Zong Li 
> ---
>  board/sifive/unmatched/spl.c   | 28 ++--
>  configs/sifive_unmatched_defconfig |  4 
>  2 files changed, 30 insertions(+), 2 deletions(-)

Reviewed-by: Leo Yu-Chi Liang 

Re: [PATCH 5/6] riscv: dts: add dts for unmatched rev1

[Leo Liang]

On Wed, Jun 30, 2021 at 11:23:49PM +0800, Zong Li wrote:
> The difference between unmatched rev3 and rev1 is DDR timing, the rev3
> uses 1866 MT/s for 16GiB, and rev1 uses 2133 MT/s for 8GiB.
> 
> Signed-off-by: Zong Li 
> ---
>  arch/riscv/dts/Makefile   |2 +-
>  .../fu740-hifive-unmatched-a00-ddr-rev1.dtsi  | 1489 +
>  .../dts/hifive-unmatched-a00-rev1-u-boot.dtsi |7 +
>  arch/riscv/dts/hifive-unmatched-a00-rev1.dts  |4 +
>  4 files changed, 1501 insertions(+), 1 deletion(-)
>  create mode 100644 arch/riscv/dts/fu740-hifive-unmatched-a00-ddr-rev1.dtsi
>  create mode 100644 arch/riscv/dts/hifive-unmatched-a00-rev1-u-boot.dtsi
>  create mode 100644 arch/riscv/dts/hifive-unmatched-a00-rev1.dts

Reviewed-by: Leo Yu-Chi Liang 

Re: [PATCH 4/6] board: sifive: Add an interface to get PCB revision

[Leo Liang]

On Wed, Jun 30, 2021 at 11:23:48PM +0800, Zong Li wrote:
> There are different DDR parameter settings for different board
> revisions. Add a new interface to get the PCB revision to determine
> which DT should be selected at runtime.
> 
> Signed-off-by: Zong Li 
> ---
>  arch/riscv/include/asm/arch-fu740/eeprom.h| 15 +
>  .../unmatched/hifive-platform-i2c-eeprom.c| 32 +++
>  2 files changed, 47 insertions(+)
>  create mode 100644 arch/riscv/include/asm/arch-fu740/eeprom.h

Reviewed-by: Leo Yu-Chi Liang 

Re: [PATCH 3/6] riscv: sifive: fu740: Support i2c in spl

[Leo Liang]

On Wed, Jun 30, 2021 at 11:23:47PM +0800, Zong Li wrote:
> Enable SPL_I2C_SUPPORT for fu740, and add 'u-boot,dm-spl' property in
> i2c node.
> 
> Signed-off-by: Zong Li 
> ---
>  arch/riscv/cpu/fu740/Kconfig  | 1 +
>  arch/riscv/dts/fu740-c000-u-boot.dtsi | 4 
>  2 files changed, 5 insertions(+)

Reviewed-by: Leo Yu-Chi Liang 

Re: [PATCH 2/6] riscv: sifive: fu740: kconfig: Enable support for Opencores I2C controller

[Leo Liang]

On Wed, Jun 30, 2021 at 11:23:46PM +0800, Zong Li wrote:
> Enable the Opencores I2C controller on FU740
> 
> Signed-off-by: Zong Li 
> ---
>  arch/riscv/cpu/fu740/Kconfig   | 2 ++
>  board/sifive/unmatched/Kconfig | 1 +
>  2 files changed, 3 insertions(+)
>

Reviewed-by: Leo Yu-Chi Liang 

Re: [PATCH 1/6] board: sifive: unmatched: add initial support for a platform ID EEPROM

[Leo Liang]

On Wed, Jun 30, 2021 at 11:23:45PM +0800, Zong Li wrote:
> Add initial support for the PCB description EEPROM for SiFive HiFive
> Unmatched boards.
> 
> This implementation is refactored based on Paul Walmsley's porting and
> adopt the suggestions from David Abdurachmanov.
> 
> Signed-off-by: Paul Walmsley 
> Signed-off-by: David Abdurachmanov 
> Signed-off-by: Zong Li 
> ---
>  board/sifive/unmatched/Makefile   |   1 +
>  .../unmatched/hifive-platform-i2c-eeprom.c| 542 ++
>  include/configs/sifive-unmatched.h|   6 +
>  3 files changed, 549 insertions(+)
>  create mode 100644 board/sifive/unmatched/hifive-platform-i2c-eeprom.c

Reviewed-by: Leo Yu-Chi Liang 

Re: [PATCH v2 4/9] board: phytec: phycore_imx8mp: Change debug UART

[Teresa Remmet]

Hello Heiko,

Am Montag, den 05.07.2021, 06:58 +0200 schrieb Heiko Schocher:
> Hello Teresa,
> 
> On 02.07.21 13:19, Teresa Remmet wrote:
> > With the first redesign the debug UART had changed from
> > UART2 to UART1.
> > As the first hardware revision is considered as alpha and
> > will not be supported in future. The old setup will not
> > be preserved.
> > 
> > Signed-off-by: Teresa Remmet 
> > ---
> >  arch/arm/dts/imx8mp-phyboard-pollux-rdk-u-boot.dtsi | 4 ++--
> >  board/phytec/phycore_imx8mp/spl.c   | 6 +++---
> >  include/configs/phycore_imx8mp.h| 4 ++--
> >  3 files changed, 7 insertions(+), 7 deletions(-)
> 
> Your patch
> "[PATCH v2 3/9] arm: dts: imx8mp-phyboard-pollux: Sync dts files with
> kernel"
> 
> changed uart2 to uart1 in arch/arm/dts/imx8mp-phyboard-pollux-rdk.dts
> 
> May this part should be done also in this patch?

yes, this would make the uart change more atomic and not separated over
2 patches. I will update this in v3.

Thanks,
Teresa

> 
> Beside of this:
> 
> Reviewed-by: Heiko Schocher 
> 
> bye,
> Heiko

[PATCH v2] dm: core: fix no null pointer detection in ofnode_get_addr_size_index()

[chenguanqiao]

From: Chen Guanqiao 

Fixed a defect of a null pointer being discovered by Coverity Scan:
   CID 331544:  Null pointer dereferences  (REVERSE_INULL)
   Null-checking "size" suggests that it may be null, but it has already been
   dereferenced on all paths leading to the check.

Signed-off-by: Chen Guanqiao 
---
 drivers/core/ofnode.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index eeeccfb446..dda6c76e83 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -329,7 +329,8 @@ static fdt_addr_t __ofnode_get_addr_size_index(ofnode node, 
int index,
 {
int na, ns;
 
-   *size = FDT_SIZE_T_NONE;
+   if (size)
+   *size = FDT_SIZE_T_NONE;
 
if (ofnode_is_np(node)) {
const __be32 *prop_val;
@@ -340,6 +341,7 @@ static fdt_addr_t __ofnode_get_addr_size_index(ofnode node, 
int index,
  );
if (!prop_val)
return FDT_ADDR_T_NONE;
+
if (size)
*size = size64;
 
@@ -359,8 +361,6 @@ static fdt_addr_t __ofnode_get_addr_size_index(ofnode node, 
int index,
  index, na, ns, size,
  translate);
}
-
-   return FDT_ADDR_T_NONE;
 }
 
 fdt_addr_t ofnode_get_addr_size_index(ofnode node, int index, fdt_size_t *size)
-- 
2.27.0

[PATCH 00/22] Various fixes and enhancements

[Simon Glass]

This series includes a number of fixes and enhancements related to
enabling verified boot on Chromium OS:

- bloblist support for resizing and a few minor fixes
- iteration through block devices
- a few cros_ec improvements
- sandbox SDL2 fixes and support for launching the VPL executable
- minor test and dm fixes
- show boot error when SPL fails to find next phase

It is based on the VPL series:

   http://patchwork.ozlabs.org/project/uboot/list/?series=242761


Simon Glass (22):
  dm: core: Add logging for DM_SEQ_ALIAS
  dm: Support lzma in the flashmap
  test: Allow CONFIG_SPL_LOAD_FIT to be disabled
  test: Add DM_DMA to be disabled
  test: Avoid a build error with SPL
  Makefile: Avoid rebuilding .dtb files each time
  sandbox: Support executables for more phases
  sandbox: Add work-around for SDL2 display
  sandbox: Use hinting with the display
  sandbox: Adjust the bloblist default address
  cros_ec: Allow reading the battery-charge state
  cros_ec: Drop cros_ec_entering_mode()
  cros_ec: Support the full-size vboot context
  cros_ec: Use standard calls for recovery-request checking
  bloblist: Support resizing a blob
  bloblist: Tidy up a few API comments
  bloblist: Correct condition in bloblist_addrec()
  image: Allow @ in node names when not using signatures
  spl: Provide more information on boot failure
  sandbox: mmc: Support fixed MMC devices
  blk: Support iteration
  log: Allow padding of the function name

 arch/sandbox/cpu/os.c  |  63 +-
 arch/sandbox/cpu/sdl.c |  26 +++-
 arch/sandbox/cpu/spl.c |  18 ++-
 arch/sandbox/dts/test.dts  |   1 +
 arch/sandbox/include/asm/spl.h |  13 ++
 common/Kconfig |  10 +-
 common/bloblist.c  |  73 ++-
 common/image-fit.c |   2 +-
 common/log_console.c   |   2 +-
 common/spl/Kconfig |  10 ++
 common/spl/spl.c   |  48 +---
 doc/arch/sandbox.rst   |   2 +-
 drivers/block/blk-uclass.c |  49 
 drivers/core/device.c  |   4 +-
 drivers/core/of_extra.c|   2 +
 drivers/misc/cros_ec.c |  28 +++--
 drivers/misc/cros_ec_sandbox.c |  29 +++--
 drivers/mmc/sandbox_mmc.c  |  24 +++-
 include/blk.h  |  56 +
 include/bloblist.h |  23 +++-
 include/cros_ec.h  |  17 ++-
 include/os.h   |   5 +-
 include/spl.h  |  33 +
 scripts/Makefile.lib   |   2 +-
 test/Makefile  |   2 +
 test/bloblist.c| 215 +
 test/dm/blk.c  |  55 +
 test/dm/core.c |   2 +
 test/image/spl_load.c  |   6 +-
 test/log/log_test.c|  16 +--
 test/test-main.c   |   2 +-
 31 files changed, 724 insertions(+), 114 deletions(-)

-- 
2.32.0.93.g670b81a890-goog

[PATCH] rockchip: rk3328: fix booting error for nanopi-r2s

[jason416]

devices can not boot properly during SPL stage by
using microSD card which model is SDSQUNC-032G-ZN6MA.

U-Boot SPL 2021.04 (Jul 02 2021 - 19:50:12 +)
Trying to boot from MMC1
mmc_load_image_raw_sector: mmc block read error
SPL: failed to boot from all boot devices

change dts and config to support booting from ultra
high speed microSD card on nanopi-r2s.

Signed-off-by: jason416 
---
 arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi | 4 
 arch/arm/dts/rk3328-nanopi-r2s.dts | 2 +-
 configs/nanopi-r2s-rk3328_defconfig| 4 
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi 
b/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi
index 9e2ced1541..d5469748a2 100644
--- a/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi
@@ -33,6 +33,10 @@
u-boot,dm-spl;
 };
 
+_io_sdio {
+   u-boot,dm-spl;
+};
+
  {
snps,reset-gpio = < RK_PC2 GPIO_ACTIVE_LOW>;
snps,reset-active-low;
diff --git a/arch/arm/dts/rk3328-nanopi-r2s.dts 
b/arch/arm/dts/rk3328-nanopi-r2s.dts
index 5445c5cb3d..452e4764e6 100644
--- a/arch/arm/dts/rk3328-nanopi-r2s.dts
+++ b/arch/arm/dts/rk3328-nanopi-r2s.dts
@@ -323,7 +323,7 @@
bus-width = <4>;
cap-sd-highspeed;
disable-wp;
-   pinctrl-0 = <_clk>, <_cmd>, <_dectn>, 
<_bus4>;
+   pinctrl-0 = <_clk>, <_cmd>, <_dectn>, 
<_bus4>, <_gpio>;
pinctrl-names = "default";
sd-uhs-sdr12;
sd-uhs-sdr25;
diff --git a/configs/nanopi-r2s-rk3328_defconfig 
b/configs/nanopi-r2s-rk3328_defconfig
index 52996266a1..a7969bd7ab 100644
--- a/configs/nanopi-r2s-rk3328_defconfig
+++ b/configs/nanopi-r2s-rk3328_defconfig
@@ -56,6 +56,10 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
 CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MMC_IO_VOLTAGE=y
+CONFIG_SPL_MMC_IO_VOLTAGE=y
+CONFIG_MMC_UHS_SUPPORT=y
+CONFIG_SPL_MMC_UHS_SUPPORT=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_SF_DEFAULT_SPEED=2000
-- 
2.17.1

[PATCH 6/6] ARM: dts: uniphier: Add support for Akebi96

[Kunihiko Hayashi]

Add the device tree for Akebi96. Akebi96 is a 96boards certified
development board based on UniPhier LD20.
( https://www.96boards.org/product/akebi96/ )

Signed-off-by: Masami Hiramatsu 
Signed-off-by: Kunihiko Hayashi 
---
 arch/arm/dts/Makefile  |   1 +
 arch/arm/dts/uniphier-ld20-akebi96.dts | 189 +
 2 files changed, 190 insertions(+)
 create mode 100644 arch/arm/dts/uniphier-ld20-akebi96.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9fb3868..ff50727 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -250,6 +250,7 @@ dtb-$(CONFIG_ARCH_UNIPHIER_LD11) += \
uniphier-ld11-global.dtb \
uniphier-ld11-ref.dtb
 dtb-$(CONFIG_ARCH_UNIPHIER_LD20) += \
+   uniphier-ld20-akebi96.dtb \
uniphier-ld20-global.dtb \
uniphier-ld20-ref.dtb
 dtb-$(CONFIG_ARCH_UNIPHIER_LD4) += \
diff --git a/arch/arm/dts/uniphier-ld20-akebi96.dts 
b/arch/arm/dts/uniphier-ld20-akebi96.dts
new file mode 100644
index 000..aa159a1
--- /dev/null
+++ b/arch/arm/dts/uniphier-ld20-akebi96.dts
@@ -0,0 +1,189 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+//
+// Device Tree Source for Akebi96 Development Board
+//
+// Derived from uniphier-ld20-global.dts.
+//
+// Copyright (C) 2015-2017 Socionext Inc.
+// Copyright (C) 2019-2020 Linaro Ltd.
+
+/dts-v1/;
+#include 
+#include "uniphier-ld20.dtsi"
+
+/ {
+   model = "Akebi96";
+   compatible = "socionext,uniphier-ld20-akebi96",
+"socionext,uniphier-ld20";
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   i2c0 = 
+   i2c1 = 
+   i2c2 = 
+   i2c3 = 
+   i2c4 = 
+   i2c5 = 
+   spi0 = 
+   spi1 = 
+   spi2 = 
+   spi3 = 
+   ethernet0 = 
+   };
+
+   memory@8000 {
+   device_type = "memory";
+   reg = <0 0x8000 0 0xc000>;
+   };
+
+   framebuffer@c000 {
+   compatible = "simple-framebuffer";
+   reg = <0 0xc000 0 0x0200>;
+   width = <1920>;
+   height = <1080>;
+   stride = <7680>;
+   format = "a8r8g8b8";
+   };
+
+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   memory@c000 {
+   reg = <0 0xc000 0 0x0200>;
+   no-map;
+   };
+   };
+
+   sound {
+   compatible = "audio-graph-card";
+   label = "UniPhier LD20";
+   dais = <_port0
+   _spdif_port0>;
+   };
+
+   spdif-out {
+   compatible = "linux,spdif-dit";
+   #sound-dai-cells = <0>;
+
+   port@0 {
+   spdif_tx: endpoint {
+   remote-endpoint = <_hiecout1>;
+   };
+   };
+   };
+
+   comp-spdif-out {
+   compatible = "linux,spdif-dit";
+   #sound-dai-cells = <0>;
+
+   port@0 {
+   comp_spdif_tx: endpoint {
+   remote-endpoint = <_spdif_hiecout1>;
+   };
+   };
+   };
+
+   firmware {
+   optee {
+   compatible = "linaro,optee-tz";
+   method = "smc";
+   };
+   };
+};
+
+ {
+   status = "okay";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   usb-over-spi@0 {
+   compatible = "maxim,max3421-udc";
+   reg = <0>;
+   spi-max-frequency = <1250>;
+   interrupt-parent = <>;
+   interrupt-names = "udc";
+   interrupts = <0 2>;
+   };
+};
+
+ {
+   /* Onboard USB-UART */
+   status = "okay";
+};
+
+ {
+   /* LS connector UART1 */
+   status = "okay";
+};
+
+ {
+   /* LS connector UART0 */
+   status = "okay";
+};
+
+_hiecout1 {
+   remote-endpoint = <_tx>;
+};
+
+_spdif_hiecout1 {
+   remote-endpoint = <_spdif_tx>;
+};
+
+ {
+   /* LS connector I2C0 */
+   status = "okay";
+};
+
+ {
+   /* LS connector I2C1 */
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   phy-handle = <>;
+};
+
+ {
+   ethphy: ethernet-phy@0 {
+   reg = <0>;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   /* IRQs for Max3421 */
+   xirq0 {
+   gpio-hog;
+   gpios = ;
+   input;
+   };
+   xirq10 {
+   gpio-hog;
+   gpios = ;
+   input;
+   };
+};
+
+_aout1 {
+ 

[PATCH 4/6] pci: uniphier: Add UniPhier PCIe controller driver

[Kunihiko Hayashi]

Add PCIe driver for UniPhier SoCs. This PCIe controller is based on
Synopsys DesignWare Core IP.

This version doesn't apply common DW functions because supported
controller doesn't have unroll version of iATU.

Signed-off-by: Kunihiko Hayashi 
---
 drivers/pci/Kconfig |  10 ++
 drivers/pci/Makefile|   1 +
 drivers/pci/pcie_uniphier.c | 424 
 3 files changed, 435 insertions(+)
 create mode 100644 drivers/pci/pcie_uniphier.c

diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index b2b7b25..6b35455 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -328,4 +328,14 @@ config PCI_BRCMSTB
  on Broadcom set-top-box (STB) SoCs.
  This driver currently supports only BCM2711 SoC and RC mode
  of the controller.
+
+config PCIE_UNIPHIER
+   bool "Socionext UniPhier PCIe driver"
+   depends on DM_PCI
+   depends on ARCH_UNIPHIER
+   select PHY_UNIPHIER_PCIE
+   help
+ Say Y here if you want to enable PCIe controller support on
+ UniPhier SoCs.
+
 endif
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index c742bb2..73dee64 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -55,3 +55,4 @@ obj-$(CONFIG_PCI_BRCMSTB) += pcie_brcmstb.o
 obj-$(CONFIG_PCI_OCTEONTX) += pci_octeontx.o
 obj-$(CONFIG_PCIE_OCTEON) += pcie_octeon.o
 obj-$(CONFIG_PCIE_DW_SIFIVE) += pcie_dw_sifive.o
+obj-$(CONFIG_PCIE_UNIPHIER) += pcie_uniphier.o
diff --git a/drivers/pci/pcie_uniphier.c b/drivers/pci/pcie_uniphier.c
new file mode 100644
index 000..f2edea9
--- /dev/null
+++ b/drivers/pci/pcie_uniphier.c
@@ -0,0 +1,424 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * pcie_uniphier.c - Socionext UniPhier PCIe driver
+ * Copyright 2019-2021 Socionext, Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* DBI registers */
+#define PCIE_LINK_STATUS_REG   0x0080
+#define PCIE_LINK_STATUS_WIDTH_MASKGENMASK(25, 20)
+#define PCIE_LINK_STATUS_SPEED_MASKGENMASK(19, 16)
+
+#define PCIE_MISC_CONTROL_1_OFF0x08BC
+#define PCIE_DBI_RO_WR_EN  BIT(0)
+
+/* DBI iATU registers */
+#define PCIE_ATU_VIEWPORT  0x0900
+#define PCIE_ATU_REGION_INBOUNDBIT(31)
+#define PCIE_ATU_REGION_OUTBOUND   0
+#define PCIE_ATU_REGION_INDEX_MASK GENMASK(3, 0)
+
+#define PCIE_ATU_CR1   0x0904
+#define PCIE_ATU_TYPE_MEM  0
+#define PCIE_ATU_TYPE_IO   2
+#define PCIE_ATU_TYPE_CFG0 4
+#define PCIE_ATU_TYPE_CFG1 5
+
+#define PCIE_ATU_CR2   0x0908
+#define PCIE_ATU_ENABLEBIT(31)
+#define PCIE_ATU_MATCH_MODEBIT(30)
+#define PCIE_ATU_BAR_NUM_MASK  GENMASK(10, 8)
+
+#define PCIE_ATU_LOWER_BASE0x090C
+#define PCIE_ATU_UPPER_BASE0x0910
+#define PCIE_ATU_LIMIT 0x0914
+#define PCIE_ATU_LOWER_TARGET  0x0918
+#define PCIE_ATU_BUS(x)FIELD_PREP(GENMASK(31, 24), x)
+#define PCIE_ATU_DEV(x)FIELD_PREP(GENMASK(23, 19), x)
+#define PCIE_ATU_FUNC(x)   FIELD_PREP(GENMASK(18, 16), x)
+#define PCIE_ATU_UPPER_TARGET  0x091C
+
+/* Link Glue registers */
+#define PCL_PINCTRL0   0x002c
+#define PCL_PERST_PLDN_REGEN   BIT(12)
+#define PCL_PERST_NOE_REGENBIT(11)
+#define PCL_PERST_OUT_REGENBIT(8)
+#define PCL_PERST_PLDN_REGVAL  BIT(4)
+#define PCL_PERST_NOE_REGVAL   BIT(3)
+#define PCL_PERST_OUT_REGVAL   BIT(0)
+
+#define PCL_MODE   0x8000
+#define PCL_MODE_REGEN BIT(8)
+#define PCL_MODE_REGVALBIT(0)
+
+#define PCL_APP_READY_CTRL 0x8008
+#define PCL_APP_LTSSM_ENABLE   BIT(0)
+
+#define PCL_APP_PM00x8078
+#define PCL_SYS_AUX_PWR_DETBIT(8)
+
+#define PCL_STATUS_LINK0x8140
+#define PCL_RDLH_LINK_UP   BIT(1)
+#define PCL_XMLH_LINK_UP   BIT(0)
+
+#define LINK_UP_TIMEOUT_MS 100
+
+struct uniphier_pcie_priv {
+   void *base;
+   void *dbi_base;
+   void *cfg_base;
+   fdt_size_t cfg_size;
+   struct fdt_resource link_res;
+   struct fdt_resource dbi_res;
+   struct fdt_resource cfg_res;
+
+   struct clk clk;
+   struct reset_ctl rst;
+   struct phy phy;
+
+   struct pci_region io;
+   struct pci_region mem;
+};
+
+static int pcie_dw_get_link_speed(struct uniphier_pcie_priv *priv)
+{
+   u32 val = readl(priv->dbi_base + PCIE_LINK_STATUS_REG);
+
+   return FIELD_GET(PCIE_LINK_STATUS_SPEED_MASK, val);
+}
+
+static int pcie_dw_get_link_width(struct uniphier_pcie_priv *priv)
+{
+   u32 val = readl(priv->dbi_base + PCIE_LINK_STATUS_REG);
+
+   

[PATCH 5/6] configs: uniphier: Enable CONFIG_SYS_PCI_64BIT

[Kunihiko Hayashi]

Enable CONFIG_SYS_PCI_64BIT to allow 64bit access to PCI space.

Signed-off-by: Kunihiko Hayashi 
---
 include/configs/uniphier.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h
index bad4e41..12028e5 100644
--- a/include/configs/uniphier.h
+++ b/include/configs/uniphier.h
@@ -210,4 +210,6 @@
 
 #define CONFIG_SPL_PAD_TO  0x2
 
+#define CONFIG_SYS_PCI_64BIT
+
 #endif /* __CONFIG_UNIPHIER_H__ */
-- 
2.7.4

[PATCH 3/6] phy: socionext: Add UniPhier PCIe PHY driver

[Kunihiko Hayashi]

Add PCIe PHY driver support for Pro5, LD20 and PXs3 SoCs.

Signed-off-by: Kunihiko Hayashi 
---
 drivers/Kconfig   |  2 ++
 drivers/Makefile  |  1 +
 drivers/phy/socionext/Kconfig | 12 +++
 drivers/phy/socionext/Makefile|  6 
 drivers/phy/socionext/phy-uniphier-pcie.c | 59 +++
 5 files changed, 80 insertions(+)
 create mode 100644 drivers/phy/socionext/Kconfig
 create mode 100644 drivers/phy/socionext/Makefile
 create mode 100644 drivers/phy/socionext/phy-uniphier-pcie.c

diff --git a/drivers/Kconfig b/drivers/Kconfig
index b1ada1c..c9c812b 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -80,6 +80,8 @@ source "drivers/phy/allwinner/Kconfig"
 
 source "drivers/phy/marvell/Kconfig"
 
+source "drivers/phy/socionext/Kconfig"
+
 source "drivers/pinctrl/Kconfig"
 
 source "drivers/power/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index 3510dab..4081289 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -96,6 +96,7 @@ obj-$(CONFIG_PCH) += pch/
 obj-y += phy/allwinner/
 obj-y += phy/marvell/
 obj-y += phy/rockchip/
+obj-y += phy/socionext/
 obj-y += rtc/
 obj-y += scsi/
 obj-y += sound/
diff --git a/drivers/phy/socionext/Kconfig b/drivers/phy/socionext/Kconfig
new file mode 100644
index 000..bcd579e
--- /dev/null
+++ b/drivers/phy/socionext/Kconfig
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# PHY drivers for Socionext platforms.
+#
+
+config PHY_UNIPHIER_PCIE
+   bool "UniPhier PCIe PHY driver"
+   depends on PHY && ARCH_UNIPHIER
+   imply REGMAP
+   help
+ Enable this to support PHY implemented in PCIe controller
+ on UniPhier SoCs.
diff --git a/drivers/phy/socionext/Makefile b/drivers/phy/socionext/Makefile
new file mode 100644
index 000..5484360
--- /dev/null
+++ b/drivers/phy/socionext/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for the phy drivers.
+#
+
+obj-$(CONFIG_PHY_UNIPHIER_PCIE)+= phy-uniphier-pcie.o
diff --git a/drivers/phy/socionext/phy-uniphier-pcie.c 
b/drivers/phy/socionext/phy-uniphier-pcie.c
new file mode 100644
index 000..d352c4c
--- /dev/null
+++ b/drivers/phy/socionext/phy-uniphier-pcie.c
@@ -0,0 +1,59 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * phy_uniphier_pcie.c - Socionext UniPhier PCIe PHY driver
+ * Copyright 2019-2021 Socionext, Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* SG */
+#define SG_USBPCIESEL  0x590
+#define SG_USBPCIESEL_PCIE BIT(0)
+
+struct uniphier_pciephy_priv {
+   int dummy;
+};
+
+static int uniphier_pciephy_init(struct phy *phy)
+{
+   return 0;
+}
+
+static int uniphier_pciephy_probe(struct udevice *dev)
+{
+   struct regmap *regmap;
+
+   regmap = syscon_regmap_lookup_by_phandle(dev,
+"socionext,syscon");
+   if (!IS_ERR(regmap))
+   regmap_update_bits(regmap, SG_USBPCIESEL,
+  SG_USBPCIESEL_PCIE, SG_USBPCIESEL_PCIE);
+
+   return 0;
+}
+
+static struct phy_ops uniphier_pciephy_ops = {
+   .init = uniphier_pciephy_init,
+};
+
+static const struct udevice_id uniphier_pciephy_ids[] = {
+   { .compatible = "socionext,uniphier-pro5-pcie-phy" },
+   { .compatible = "socionext,uniphier-ld20-pcie-phy" },
+   { .compatible = "socionext,uniphier-pxs3-pcie-phy" },
+   { }
+};
+
+U_BOOT_DRIVER(uniphier_pcie_phy) = {
+   .name   = "uniphier-pcie-phy",
+   .id = UCLASS_PHY,
+   .of_match   = uniphier_pciephy_ids,
+   .ops= _pciephy_ops,
+   .probe  = uniphier_pciephy_probe,
+   .priv_auto  = sizeof(struct uniphier_pciephy_priv),
+};
-- 
2.7.4