[PATCH] configs: Layerscape: Remove the 'fdt_addr' env

[Zhiqiang Hou]

From: Hou Zhiqiang 

On Layerscape platforms, the DTB is loaded from boot filesystem,
per the fdt_addr description in doc/README.distro, it must be
removed.

And on many platforms, like ls1046a, ls1088a, ls2088a and lx216xa,
the 'fdt_addr' pointed address is not accessible.
And with the current EFI boot process, since the EFI_LOADER and
CMD_BOOTEFI_BOOTMGR are enabled by default, if the EFI boot
components are not deployed in the boot filesystem, it will try
to get DTB at address 'fdt_addr' and then result in "SError" or
"Synchronous Abort":

Error log on ls1046ardb:
=> run distro_bootcmd 
switch to partitions #0, OK 
mmc0 is current device 
Scanning mmc 0:1...  
libfdt fdt_check_header(): FDT_ERR_BADMAGIC 
Scanning disk es...@156.blk...  
Found 5 disks 
No EFI system partition 
"Error" handler, esr 0xbf00 
elr: 820704f4 lr : 820080d4 (reloc) 
elr: fbd914f4 lr : fbd290d4 
x0 : 64f0 x1 : edfe0dd0 
x2 :  x3 :  
x4 : fbc2ee1a x5 : 000f 
x6 :  x7 : 0008 
x8 : 0010 x9 : 0008 
x10: 0044 x11: 00080220 
x12: fbdaa748 x13: fbda70f8 
x14: fbd21d20 x15: fbc194e8 
x16: fbd70fc8 x17:  
x18: fbc1cdb0 x19: fbd21bf0 
x20: 64f0 x21: fbda6fb8 
x22: 0018 x23: 0018 
x24: fbde6344 x25:  
x26:  x27: 
x28: fbc53660 x29: fbc19220 

Code: 7a419060 1a9f3000 a8c17bfd d65f03c0 (12800100)

Resetting CPU ...

Signed-off-by: Hou Zhiqiang 
---
 include/configs/ls1012a2g5rdb.h  | 1 -
 include/configs/ls1012afrdm.h| 2 +-
 include/configs/ls1012afrwy.h| 1 -
 include/configs/ls1012aqds.h | 1 -
 include/configs/ls1012ardb.h | 1 -
 include/configs/ls1021atsn.h | 3 +--
 include/configs/ls1021atwr.h | 4 +---
 include/configs/ls1028aqds.h | 3 +--
 include/configs/ls1028ardb.h | 3 +--
 include/configs/ls1043a_common.h | 1 -
 include/configs/ls1046a_common.h | 1 -
 include/configs/ls1088ardb.h | 2 --
 include/configs/ls2080ardb.h | 2 --
 include/configs/lx2160a_common.h | 1 -
 14 files changed, 5 insertions(+), 21 deletions(-)

diff --git a/include/configs/ls1012a2g5rdb.h b/include/configs/ls1012a2g5rdb.h
index 44f9da7306..d9ff011bac 100644
--- a/include/configs/ls1012a2g5rdb.h
+++ b/include/configs/ls1012a2g5rdb.h
@@ -29,7 +29,6 @@
 #define CONFIG_EXTRA_ENV_SETTINGS  \
"verify=no\0"   \
"initrd_high=0x\0"  \
-   "fdt_addr=0x00f0\0" \
"kernel_addr=0x0100\0"  \
"kernelheader_addr=0x80\0"  \
"scriptaddr=0x8000\0"   \
diff --git a/include/configs/ls1012afrdm.h b/include/configs/ls1012afrdm.h
index 2711f651d7..c7fdd10cf5 100644
--- a/include/configs/ls1012afrdm.h
+++ b/include/configs/ls1012afrdm.h
@@ -1,6 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
 /*
  * Copyright 2016 Freescale Semiconductor, Inc.
+ * Copyright 2021 NXP
  */
 
 #ifndef __LS1012ARDB_H__
@@ -24,7 +25,6 @@
 #define CONFIG_EXTRA_ENV_SETTINGS  \
"verify=no\0"   \
"fdt_high=0x\0" \
-   "fdt_addr=0x00f0\0" \
"kernel_addr=0x0100\0"  \
"scriptaddr=0x8000\0"   \
"fdtheader_addr_r=0x8010\0" \
diff --git a/include/configs/ls1012afrwy.h b/include/configs/ls1012afrwy.h
index f8b386125c..7ffca56d72 100644
--- a/include/configs/ls1012afrwy.h
+++ b/include/configs/ls1012afrwy.h
@@ -41,7 +41,6 @@
 #define CONFIG_EXTRA_ENV_SETTINGS  \
"verify=no\0"   \
"initrd_high=0x\0"  \
-   "fdt_addr=0x00f0\0" \
"kernel_addr=0x0100\0"  \
"kernel_size_sd=0x16000\0"  \
"kernelhdr_size_sd=0x10\0"  \
diff --git a/include/configs/ls1012aqds.h b/include/configs/ls1012aqds.h
index 3e5fdadc40..d0bfd3e494 100644
--- a/include/configs/ls1012aqds.h
+++ b/include/configs/ls1012aqds.h
@@ -101,7 +101,6 @@
 #undef CONFIG_EXTRA_ENV_SETTINGS
 #define CONFIG_EXTRA_ENV_SETTINGS  \
"verify=no\0"   \
-   "fdt_addr=0x00f0\0" \
"kernel_addr=0x0100\0"  \
"kernelheader_addr=0x60\0"  \
"scriptaddr=0x8000\0"   \
diff --git a/include/configs/ls1012ardb.h b/include/configs/ls1012ardb.h
index c8a2f

Re: [PATCH] configs: Layerscape: Remove the 'fdt_addr' env

[Wolfgang Denk]

Dear Zhiqiang Hou,

In message <20210812072846.39305-1-zhiqiang@nxp.com> you wrote:

> diff --git a/include/configs/ls1012afrdm.h b/include/configs/ls1012afrdm.h
> index 2711f651d7..c7fdd10cf5 100644
> --- a/include/configs/ls1012afrdm.h
> +++ b/include/configs/ls1012afrdm.h
> @@ -1,6 +1,7 @@
>  /* SPDX-License-Identifier: GPL-2.0+ */
>  /*
>   * Copyright 2016 Freescale Semiconductor, Inc.
> + * Copyright 2021 NXP
>   */
>  
>  #ifndef __LS1012ARDB_H__
> @@ -24,7 +25,6 @@
>  #define CONFIG_EXTRA_ENV_SETTINGS\
>   "verify=no\0"   \
>   "fdt_high=0x\0" \
> - "fdt_addr=0x00f0\0" \
>   "kernel_addr=0x0100\0"  \
>   "scriptaddr=0x8000\0"   \
>   "fdtheader_addr_r=0x8010\0" \
> diff --git a/include/configs/ls1012afrwy.h b/include/configs/ls1012afrwy.h

Adding or - like here, even worse - removing just a few lines of
data definitions is certainly nothing where you can claim a
copyright on.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
HR Manager to job candidate "I see you've had no  computer  training.
Although  that  qualifies  you  for upper management, it means you're
under-qualified for our entry level positions."

RE: [PATCH] configs: Layerscape: Remove the 'fdt_addr' env

[Z.Q. Hou]

Hello Wolfgang,

> -Original Message-
> From: Wolfgang Denk 
> Sent: 2021年8月12日 15:24
> To: Z.Q. Hou 
> Cc: u-boot@lists.denx.de; Priyanka Jain ;
> ykau...@suse.de; feste...@gmail.com; tr...@konsulko.com
> Subject: Re: [PATCH] configs: Layerscape: Remove the 'fdt_addr' env
> 
> Dear Zhiqiang Hou,
> 
> In message <20210812072846.39305-1-zhiqiang@nxp.com> you wrote:
> 
> > diff --git a/include/configs/ls1012afrdm.h
> > b/include/configs/ls1012afrdm.h index 2711f651d7..c7fdd10cf5 100644
> > --- a/include/configs/ls1012afrdm.h
> > +++ b/include/configs/ls1012afrdm.h
> > @@ -1,6 +1,7 @@
> >  /* SPDX-License-Identifier: GPL-2.0+ */
> >  /*
> >   * Copyright 2016 Freescale Semiconductor, Inc.
> > + * Copyright 2021 NXP
> >   */
> >
> >  #ifndef __LS1012ARDB_H__
> > @@ -24,7 +25,6 @@
> >  #define CONFIG_EXTRA_ENV_SETTINGS  \
> > "verify=no\0"   \
> > "fdt_high=0x\0" \
> > -   "fdt_addr=0x00f0\0" \
> > "kernel_addr=0x0100\0"  \
> > "scriptaddr=0x8000\0"   \
> > "fdtheader_addr_r=0x8010\0" \
> > diff --git a/include/configs/ls1012afrwy.h
> > b/include/configs/ls1012afrwy.h
> 
> Adding or - like here, even worse - removing just a few lines of data
> definitions is certainly nothing where you can claim a copyright on.
> 
 
It's NXP's legal check policy.

Thanks,
Zhiqiang

> Best regards,
> 
> Wolfgang Denk
> 
> --
> DENX Software Engineering GmbH,  Managing Director: Wolfgang
> Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> HR Manager to job candidate "I see you've had no  computer  training.
> Although  that  qualifies  you  for upper management, it means you're
> under-qualified for our entry level positions."

Pull request: u-boot-rockchip-20210812

[Kever Yang]

Hi Tom,

Please pull the rockchip updates/fixes:
- Add Rockchip SFC driver support;
- DTS sync from kernel;
- emmc hs400 support for rk3399;
- Fix for spinore bootdevice and MMC boot order;

CI:
https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/8670

Thanks,
- Kever

The following changes since commit 3e5b62f7740530e6f3a2e989f4c361a9d52b:

  configs: Resync with savedefconfig (2021-08-10 15:08:46 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-rockchip.git 
tags/u-boot-rockchip-20210812

for you to fetch changes up to 60df49d22d2586f50bba11eaa59a55f2baa4671f:

  rockchip: px30: Support configure SFC (2021-08-12 09:34:11 +0800)


Alex Bee (1):
  rockchip: Fix MMC boot order

Artem Lapkin (1):
  rk3399: boot_devices fix spinor node name

Chris Morgan (5):
  spi: rockchip_sfc: add support for Rockchip SFC
  rockchip: px30: Add support for using SFC
  rockchip: px30: add the serial flash controller
  mtd: spi-nor-ids: Add XTX XT25F128B
  rockchip: px30: add support for SFC for Odroid Go Advance

Johan Gunnarsson (1):
  rockchip: Fix u-boot-rockchip.bin build

Johan Jonker (5):
  rockchip: rk3188-cru-common: sync clock dt-binding header from Linux
  ARM: dts: rockchip: update rk3xxx.dtsi
  rockchip: rk3188-power: sync power domain dt-binding header from Linux
  ARM: dts: rockchip: update rk3188.dtsi
  ARM: dts: rockchip: update rk3188-radxarock.dts

Jon Lin (1):
  rockchip: px30: Support configure SFC

Peter Robinson (3):
  arm: dts: sync the Rockhip 3399 SoCs from Linux
  arm: dts: sync the Rockhip 3328 SoCs from Linux
  arm: dts: sync the Rockhip 3368 SoCs from Linux

Xiaobo Tian (3):
  arm64: rk3399: r4s: correct the LEDS label name
  arm64: rk3399: r4s: Inheritance uses the sdmmc definition in dtsi
  arm64: rk3399: r4s: Remove undesirable MAC address fetching methods for 
ethernet

Yifeng Zhao (3):
  mmc: rockchip_sdhci: add phy and clock config for rk3399
  mmc: rockchip_sdhci: Add support for RK3568
  rockchip: config: evb-rk3399: add hs400 and SDMA support

 arch/arm/Kconfig  |   2 +-
 arch/arm/dts/px30.dtsi|  38 ++
 arch/arm/dts/rk3188-radxarock-u-boot.dtsi |  38 +-
 arch/arm/dts/rk3188-radxarock.dts |  88 ++--
 arch/arm/dts/rk3188-u-boot.dtsi   |  13 +
 arch/arm/dts/rk3188.dtsi  | 480 +--
 arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi|  17 +
 arch/arm/dts/rk3326-odroid-go2.dts|  16 +
 arch/arm/dts/rk3328-evb.dts   |  23 +-
 arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi|   2 +-
 arch/arm/dts/rk3328-nanopi-r2s.dts|  51 +-
 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi|   2 +-
 arch/arm/dts/rk3328-roc-cc.dts|  41 +-
 arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi |   4 +-
 arch/arm/dts/rk3328-rock-pi-e.dts | 439 ++---
 arch/arm/dts/rk3328-rock64-u-boot.dtsi|   2 +-
 arch/arm/dts/rk3328-rock64.dts|  72 +--
 arch/arm/dts/rk3328.dtsi  | 109 +++--
 arch/arm/dts/rk3368-geekbox.dts   |  70 +--
 arch/arm/dts/rk3368-lion-haikou.dts   |   4 +
 arch/arm/dts/rk3368-lion.dtsi |  21 +-
 arch/arm/dts/rk3368-px5-evb.dts   | 178 +++
 arch/arm/dts/rk3368.dtsi  |  65 ++-
 arch/arm/dts/rk3399-evb.dts   |   4 +
 arch/arm/dts/rk3399-ficus.dts |  29 +-
 arch/arm/dts/rk3399-firefly.dts   | 178 ++-
 arch/arm/dts/rk3399-gru.dtsi  |  14 +-
 arch/arm/dts/rk3399-khadas-edge.dtsi  |  40 +-
 arch/arm/dts/rk3399-leez-p710.dts |  14 +-
 arch/arm/dts/rk3399-nanopc-t4.dts |   1 +
 arch/arm/dts/rk3399-nanopi-r4s.dts| 135 +++---
 arch/arm/dts/rk3399-nanopi4.dtsi  |  18 +-
 arch/arm/dts/rk3399-opp.dtsi  |  40 +-
 arch/arm/dts/rk3399-orangepi.dts  |  72 ++-
 arch/arm/dts/rk3399-pinebook-pro.dts  | 120 +++--
 arch/arm/dts/rk3399-puma-haikou.dts   |  10 +-
 arch/arm/dts/rk3399-puma.dtsi |  61 +--
 arch/arm/dts/rk3399-roc-pc-mezzanine.dts  |  22 +-
 arch/arm/dts/rk3399-roc-pc.dtsi   |  59 ++-
 arch/arm/dts/rk3399-rock-pi-4.dtsi|  29 +-
 arch/arm/dts/rk3399-rock-pi-4a.dts|   2 +-
 arch/arm/dts/rk3399-rock-pi-4b.dts|   6 +-
 arch/arm/dts/rk3399-rock-pi-4c.dts|   6 +-
 arch/arm/dts/rk3399-rock960.dts   |  82 ++--
 arch/arm/dts/rk3399-rock960.dtsi  |  10 +-
 arch/arm/dts/rk3399-rockpro64.dtsi|  95 +++-
 arch/arm/dts/rk3399.dtsi  | 269 ++-
 arch/arm/dts/rk3399pro-vmarc-som.dtsi |  12 +-
 arch/arm/dts

Re: [PATCH v3 0/3] arm64: Add optimized memset/memcpy/memove functions

[Stefan Roese]

On 11.08.21 16:28, Stefan Roese wrote:

On 11.08.21 16:25, Tom Rini wrote:

On Wed, Aug 11, 2021 at 04:02:39PM +0200, Stefan Roese wrote:


On an NXP LX2160 based platform it has been noticed, that the currently
implemented memset/memcpy functions for aarch64 are suboptimal.
Especially the memset() for clearing the NXP MC firmware memory is very
expensive (time-wise).

By using optimized functions, a speedup of ~ factor 6 has been measured.


To be clear, you re-measured with the cache check code added, and this
is the speed up?


I forgot doing this. BTW: I was wrong with factor ~6. From my notices,
it is ~ factor 4 using the optimized memset() version.

I'll follow-up on this mail with some measurements for all affected
functions, using small and large sizes. Hopefully tomorrow.


Here the numbers:

Current original version:
-
memset() 32 Bytes, 16M times:
time: 0.446 seconds

memset() 16MiB, 256 times:
time: 1.076 seconds

memcpy() 512MiB:
time: 0.224 seconds

New optimized version:
--
memset() 32 Bytes, 16M times:
time: 0.287 seconds

memset() 16MiB, 256 times:
time: 0.292 seconds

memcpy() 512MiB:
time: 0.222 seconds

Summary:
The optimized memcpy is nearly identical to the original one. But the
optimized memset is much faster, for small and big sizes. Small sizes
factor ~1.6 and big sizes factor ~3.7.

Note: These measurements were done on the NXP LX2160ARDB board.

Thanks,
Stefan

Re: [PATCH] configs: Layerscape: Remove the 'fdt_addr' env

[Wolfgang Denk]

Dear "Z.Q. Hou",

In message 

 you wrote:
> 
> > Adding or - like here, even worse - removing just a few lines of data
> > definitions is certainly nothing where you can claim a copyright on.
> > 
>  
> It's NXP's legal check policy.

Maybe, but that's not how copyright works.  You cannot claim any
copyright on trivial changes.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Imitation is the sincerest form of plagarism.

[PATCH] rockchip: rk33xx: Drop ROCKCHIP_USB2_PHY on boards without it

[Peter Robinson]

The 64 bit rk33xx chips don't have the ROCKCHIP_USB2_PHY IP so
drop the configs as they were likely copied over from other
boards during enablement.

Signed-off-by: Peter Robinson 
---
 configs/lion-rk3368_defconfig | 1 -
 configs/nanopc-t4-rk3399_defconfig| 1 -
 configs/roc-pc-mezzanine-rk3399_defconfig | 1 -
 configs/roc-pc-rk3399_defconfig   | 1 -
 configs/rock-pi-n10-rk3399pro_defconfig   | 1 -
 5 files changed, 5 deletions(-)

diff --git a/configs/lion-rk3368_defconfig b/configs/lion-rk3368_defconfig
index 5f7d101814..90a2878e50 100644
--- a/configs/lion-rk3368_defconfig
+++ b/configs/lion-rk3368_defconfig
@@ -94,7 +94,6 @@ CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_GENERIC=y
 CONFIG_USB_DWC2=y
-CONFIG_ROCKCHIP_USB2_PHY=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_DWC2_OTG=y
 CONFIG_SPL_TINY_MEMSET=y
diff --git a/configs/nanopc-t4-rk3399_defconfig 
b/configs/nanopc-t4-rk3399_defconfig
index a94f428def..62833c386b 100644
--- a/configs/nanopc-t4-rk3399_defconfig
+++ b/configs/nanopc-t4-rk3399_defconfig
@@ -51,7 +51,6 @@ CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_GENERIC=y
 CONFIG_USB_DWC3=y
-CONFIG_ROCKCHIP_USB2_PHY=y
 CONFIG_USB_KEYBOARD=y
 CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_ASIX=y
diff --git a/configs/roc-pc-mezzanine-rk3399_defconfig 
b/configs/roc-pc-mezzanine-rk3399_defconfig
index 8d0f57021b..6aa47490c1 100644
--- a/configs/roc-pc-mezzanine-rk3399_defconfig
+++ b/configs/roc-pc-mezzanine-rk3399_defconfig
@@ -69,7 +69,6 @@ CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_GENERIC=y
 CONFIG_USB_DWC3=y
 CONFIG_USB_DWC3_GENERIC=y
-CONFIG_ROCKCHIP_USB2_PHY=y
 CONFIG_USB_KEYBOARD=y
 CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_ASIX=y
diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig
index 4e5c90439d..b03ee3664f 100644
--- a/configs/roc-pc-rk3399_defconfig
+++ b/configs/roc-pc-rk3399_defconfig
@@ -66,7 +66,6 @@ CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_GENERIC=y
 CONFIG_USB_DWC3=y
 CONFIG_USB_DWC3_GENERIC=y
-CONFIG_ROCKCHIP_USB2_PHY=y
 CONFIG_USB_KEYBOARD=y
 CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_ASIX=y
diff --git a/configs/rock-pi-n10-rk3399pro_defconfig 
b/configs/rock-pi-n10-rk3399pro_defconfig
index e5df6779de..17442a0d84 100644
--- a/configs/rock-pi-n10-rk3399pro_defconfig
+++ b/configs/rock-pi-n10-rk3399pro_defconfig
@@ -60,7 +60,6 @@ CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_GENERIC=y
 CONFIG_USB_DWC3=y
 CONFIG_USB_DWC3_GENERIC=y
-CONFIG_ROCKCHIP_USB2_PHY=y
 CONFIG_USB_KEYBOARD=y
 # CONFIG_USB_KEYBOARD_FN_KEYS is not set
 CONFIG_USB_GADGET=y
-- 
2.31.1

Re: [PATCH 2/3] Add fdt network helper functions

[Tony Dinh]

Hi Stefan,

On Wed, Aug 11, 2021 at 11:15 PM Stefan Roese  wrote:
>
> Hi Tony,
>
> a few nits...
>
> On 06.08.21 06:49, Tony Dinh wrote:
> > Add fdt network helper functions common/fdt_support_net.c
> >
> > Signed-off-by: Tony Dinh 
> > ---
> >
> >   common/fdt_support_net.c | 46 
> >   1 file changed, 46 insertions(+)
> >   create mode 100644 common/fdt_support_net.c
> >
> > diff --git a/common/fdt_support_net.c b/common/fdt_support_net.c
> > new file mode 100644
> > index 00..06fa2175b4
> > --- /dev/null
> > +++ b/common/fdt_support_net.c
> > @@ -0,0 +1,46 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2021 Tony Dinh 
> > + */
> > +
> > +#include 
>
> Including "common.h" is deprecated. Please remove it and include the
> missing other headers instead (if any).
>
> > +#include 
> > +#include 
> > +#include 
> > +#include 
>
> Sorting would be good as well.
>
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +int fdt_get_phy_addr(const char *path)
> > +{
> > + const void *fdt = gd->fdt_blob;
> > + const u32 *reg;
> > + const u32 *val;
> > + int node, phandle, addr;
> > +
> > + /* Find the node by its full path */
> > + node = fdt_path_offset(fdt, path);
> > + if (node >= 0) {
> > + /* Look up phy-handle */
> > + val = fdt_getprop(fdt, node, "phy-handle", NULL);
> > + if (!val)
> > + /* Look up phy (deprecated property for phy handle) */
> > + val = fdt_getprop(fdt, node, "phy", NULL);
>
> Above is a multi-line statement which is better included in
> parentheses.
>
> And I personally would add an empty line here.
>
> > + if (val) {
> > + phandle = fdt32_to_cpu(*val);
> > + if (!phandle)
> > + return -1;
>
> Could you instead of returning "-1" return some matching error code
> defines?
>
> And I personally would add an empty line here.
>
> > + /* Follow it to its node */
> > + node = fdt_node_offset_by_phandle(fdt, phandle);
> > + if (node) {
> > + /* Look up reg */
> > + reg = fdt_getprop(fdt, node, "reg", NULL);
> > + if (reg) {
> > + addr = fdt32_to_cpu(*reg);
> > + return addr;
> > + }
> > + }
> > + }
> > + }
> > + return -1;
>
> Again, please change to some matching error define here.
>

Will do all of the above and send in the V2 patch, after Ramon and Joe
had any feedback.

Thanks,
Tony

> Thanks,
> Stefan

Re: EFI from usb HDD

[AKASHI Takahiro]

On Fri, Jul 30, 2021 at 08:22:18AM +0200, Michal Simek wrote:
> 
> 
> On 7/30/21 7:33 AM, AKASHI Takahiro wrote:
> > On Fri, Jul 30, 2021 at 06:41:01AM +0200, Michal Simek wrote:
> >>
> >>
> >> On 7/30/21 4:35 AM, AKASHI Takahiro wrote:
> >>> On Thu, Jul 29, 2021 at 04:09:32PM +0200, Michal Simek wrote:
>  Hi,
> 
>  On 6/10/21 2:59 PM, AKASHI Takahiro wrote:
> > On Thu, Jun 10, 2021 at 02:31:46PM +0200, Michal Simek wrote:
> >>
> >>
> >> On 6/10/21 12:51 PM, Heinrich Schuchardt wrote:
> >>> On 6/10/21 12:04 PM, Michal Simek wrote:
>  Hi,
> 
>  On 6/10/21 11:47 AM, Heinrich Schuchardt wrote:
> > On 6/10/21 10:44 AM, Michal Simek wrote:
> >> Hi,
> >>
> >> I am playing with booting from USB via EFI. And I see very weird
> >> behavior. I have burnt image with grub to USB flashdisk and I have
> >> tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria board.
> >> On zcu102 grub is going to boot menu and everything is working 
> >> fine as
> >> expected.
> >> On zcu104 and SOM Kria I am able to get grub not to menu. When I 
> >> list
> >> partitions in grub I see that only SDs are listed:
> >> grub> ls
> >> (hd0) (hd0,msdos1) (hd1) (hd1,msdos1)
> >
> > Hello Michal,
> >
> > thanks for sharing your observations.
> >
> > What devices do hd0 and hd1 relate to?
> >
> >>
> >> On zcu102(working board) I also see usb(gpt) partitions and SD.
> >> grub> ls
> >> (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1)
> >>
> >
> > GPT and MBR partitioning are independent of the device type.
> >
> >>
> >> On zcu104 I see one more error message
> >> "PE image measurement failed"
> >
> > This is related to CONFIG_EFI_TCG2_PROTOCOL=y. Do you have a TPMv2? 
> > This
> > will not stop disk enumeration.
> >
> >> But I can't see it on SOM.
> >>
> >> U-Boot image is just the same for all boards. I am using generic
> >> xilinx_zynqmp_virt_defconfig.
> >>
> >> When I compare DT description for USB between zcu102 and zcu104 
> >> they
> >> are
> >> the same. SOM doesn't have usb enabled by default (but I enabled 
> >> it)
> >> but
> >> grub starts which means that communication with USB is fine.
> >>
> >> It is based on my latest patches available here.
> >> u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch)
> >>
> >> Also when I list usb I see all partitions just fine.
> >> ZynqMP> part list usb 0
> >>
> >> Partition Map for USB device 0  --   Partition Type: EFI
> >>
> >> Part    Start LBA   End LBA Name
> >>   Attributes
> >>   Type GUID
> >>   Partition GUID
> >>     1 0x0800  0x001007fe  "Microsoft basic data"
> >>   attrs:  0x
> >>   type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
> >>   type:   data
> >>   guid:   0e7f8b3d-296b-4720-be9d-c4687d3c4a77
> >>     2 0x00100800  0x001197fe  "Microsoft basic data"
> >>   attrs:  0x
> >>   type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
> >>   type:   data
> >>   guid:   8892eddc-231a-4e6e-a5e1-c310f4482fb7
> >>
> >>
> >> Do you have any idea why on one system is working fine to get to 
> >> menu
> >> and on others there is an issue to get all partitions even u-boot 
> >> is
> >> able to see them and can work with them.
> >>
> >> Thanks,
> >> Michal
> >>
> >
> > Where is the GRUB binary? - If it is in EFI/boot/bootaa64.efi, it 
> > could
> > be that the USB sub-system is simply not initialized yet when the 
> > boot
> > manager is called by distroboot.
> >
> > For testing partition detection in the UEFI sub-system it is enough
> > to run
> >
> >  efidebug devices
> >
> > Until yesterday we had a problem with partition numbers >= 10, cf.
> >
> > efi_loader: partition numbers are hexadecimal
> > https://source.denx.de/u-boot/u-boot/-/commit/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f
> >
> >
> >
> > Block devices are enumerated in efi_disk_register(). Please, try to 
> > add
> > debug output there to elucidate the problem.
> 
>  I found where the problem is. First of all zcu102 didn't use the same
>  image as others (it wasn't 

[PATCH 1/1] cmd: enable CONFIG_CMD_EFIDEBUG by default

[Heinrich Schuchardt]

The efidebug command is needed to manage UEFI boot options.
To display them fully CONFIG_HEXDUMP is needed.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index ffef3cc76c..30a291fa3b 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1732,7 +1732,9 @@ config CMD_CLS
 config CMD_EFIDEBUG
bool "efidebug - display/configure UEFI environment"
depends on EFI_LOADER
+   default y
select EFI_DEVICE_PATH_TO_TEXT
+   imply HEXDUMP
default n
help
  Enable the 'efidebug' command which provides a subset of UEFI
-- 
2.31.1

回复: [PATCH V1] arm: add initial support for the Phytium Pomelo Board

[Nicholas zheng]

Is this structure describing some hardware register layout? Or some
interface with the firmware?
Then please use explicit types: uint8_t, uint16_t, ...

I want to use uint8_t,but checkpatch.pl showed “Prefer kernel type 'u8' over 
'uint8_t'”.So I don't know which is better.
Thanks.

发件人: Andre Przywara 
发送时间: 2021年7月23日 19:03
收件人: nicholas_zh...@outlook.com 
抄送: tr...@konsulko.com ; bharat.go...@broadcom.com 
; rayagonda.kokata...@broadcom.com 
; ja...@amarulasolutions.com 
; feste...@gmail.com ; 
patrick.delau...@foss.st.com ; 
thar...@gateworks.com ; pbrobin...@gmail.com 
; h...@denx.de ; lokeshvu...@ti.com 
; d-gerl...@ti.com ; u-boot@lists.denx.de 
; robh...@kernel.org 
主题: Re: [PATCH V1] arm: add initial support for the Phytium Pomelo Board

On Mon, 19 Jul 2021 17:46:41 +0800
nicholas_zh...@outlook.com wrote:

Hi,

as Peter already mentioned, this should be [PATCH v2], the next
version [PATCH v3], and so on. And please don't resend the same email
(and they are identical, I diffed them) without any comments as to why.
If you want to ping people, reply to your own email.

Now for the technical part:

> From: weichangzheng 
>
> This adds platform code and the device tree for the Phytium Pomelo Board.
> The initial support comprises the UART and the PCIE.
>
> Signed-off-by: weichangzheng 
> Changes since v1:
> - updated to DT
> ---
>  arch/arm/Kconfig |   8 ++
>  arch/arm/dts/Makefile|   1 +
>  arch/arm/dts/phytium-pomelo.dts  | 113 +
>  board/phytium/pomelo/Kconfig |  12 +++
>  board/phytium/pomelo/MAINTAINERS |   8 ++
>  board/phytium/pomelo/Makefile|  14 +++
>  board/phytium/pomelo/cpu.h   |  73 ++
>  board/phytium/pomelo/ddr.c   | 164 +++
>  board/phytium/pomelo/pcie.c  |  61 
>  board/phytium/pomelo/pll.c   |  75 ++
>  board/phytium/pomelo/pomelo.c| 120 ++
>  board/phytium/pomelo/sec.c   |  40 
>  configs/pomelo_defconfig |  36 +++
>  include/configs/pomelo.h |  45 +
>  14 files changed, 770 insertions(+)
>  create mode 100644 arch/arm/dts/phytium-pomelo.dts
>  create mode 100644 board/phytium/pomelo/Kconfig
>  create mode 100644 board/phytium/pomelo/MAINTAINERS
>  create mode 100644 board/phytium/pomelo/Makefile
>  create mode 100644 board/phytium/pomelo/cpu.h
>  create mode 100644 board/phytium/pomelo/ddr.c
>  create mode 100644 board/phytium/pomelo/pcie.c
>  create mode 100644 board/phytium/pomelo/pll.c
>  create mode 100644 board/phytium/pomelo/pomelo.c
>  create mode 100644 board/phytium/pomelo/sec.c
>  create mode 100644 configs/pomelo_defconfig
>  create mode 100644 include/configs/pomelo.h
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 0448787b8b..0afbb86640 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1818,6 +1818,13 @@ config TARGET_DURIAN
>  Support for durian platform.
>  It has 2GB Sdram, uart and pcie.
>
> +config TARGET_POMELO
> + bool "Support Phytium Pomelo Platform"
> + select ARM64

You should use this stanza here to select more of U-Boot features (see
below).

> + help
> + Support for pomelo platform.
> + It has 2GB Sdram, uart and pcie.
> +
>  config TARGET_PRESIDIO_ASIC
>bool "Support Cortina Presidio ASIC Platform"
>select ARM64
> @@ -2038,6 +2045,7 @@ source "board/toradex/colibri_pxa270/Kconfig"
>  source "board/variscite/dart_6ul/Kconfig"
>  source "board/vscom/baltos/Kconfig"
>  source "board/phytium/durian/Kconfig"
> +source "board/phytium/pomelo/Kconfig"
>  source "board/xen/xenguest_arm64/Kconfig"
>  source "board/keymile/Kconfig"
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 9fb38682e6..45d0340bd3 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1107,6 +1107,7 @@ dtb-$(CONFIG_TARGET_MX53PPD) += imx53-ppd.dtb
>  dtb-$(CONFIG_TARGET_TOTAL_COMPUTE) += total_compute.dtb
>
>  dtb-$(CONFIG_TARGET_DURIAN) += phytium-durian.dtb
> +dtb-$(CONFIG_TARGET_POMELO) += phytium-pomelo.dtb
>
>  dtb-$(CONFIG_TARGET_PRESIDIO_ASIC) += ca-presidio-engboard.dtb
>
> diff --git a/arch/arm/dts/phytium-pomelo.dts b/arch/arm/dts/phytium-pomelo.dts
> new file mode 100644
> index 00..3869475902
> --- /dev/null
> +++ b/arch/arm/dts/phytium-pomelo.dts
> @@ -0,0 +1,113 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * dts file for Phytium Pomelo board
> + * Copyright (C) 2021, Phytium Ltd.
> + * lixinde 
> + * weichangzheng   
> + */
> +/dts-v1/;
> +
> +/ {
> + model = "Phytium Pomelo";
> + compatible = "phytium,pomelo";
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + cpus {
> + #address-cells = <0x2>;
> + #size-cells = <0x0>;
> +
> + cpu0: cpu@0 {
> + devic

[PATCH v8 0/5] rockchip_sfc: add support for Rockchip SFC

[Jon Lin]

Changes in v8:
- Move speed operation to set_speed logic
- Use read_poll
- Change debug to dev_dbg
- Simply exec_op dma logic
- Change to use tx single line to make a good compatible

Changes in v7:
- Make sfc-use-dma configurable
- Make px30 SFC clock configurable

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
- px30 use "rockchip, sfc" as compatible id

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

Chris Morgan (4):
  spi: rockchip_sfc: add support for Rockchip SFC
  rockchip: px30: Add support for using SFC
  rockchip: px30: add the serial flash controller
  rockchip: px30: add support for SFC for Odroid Go Advance

Jon Lin (1):
  rockchip: px30: Support configure SFC

 arch/arm/dts/px30.dtsi |  38 ++
 arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi |  17 +
 arch/arm/dts/rk3326-odroid-go2.dts |  16 +
 arch/arm/mach-rockchip/px30/px30.c |  64 ++
 drivers/clk/rockchip/clk_px30.c|  32 +
 drivers/spi/Kconfig|   8 +
 drivers/spi/Makefile   |   1 +
 drivers/spi/rockchip_sfc.c | 646 +
 8 files changed, 822 insertions(+)
 create mode 100644 drivers/spi/rockchip_sfc.c

-- 
2.17.1

[PATCH v8 2/5] rockchip: px30: Add support for using SFC

[Jon Lin]

From: Chris Morgan 

This patch adds support for setting the correct pin configuration
for the Rockchip Serial Flash Controller found on the PX30.

Signed-off-by: Chris Morgan 
Signed-off-by: Jon Lin 
---

(no changes since v1)

 arch/arm/mach-rockchip/px30/px30.c | 64 ++
 1 file changed, 64 insertions(+)

diff --git a/arch/arm/mach-rockchip/px30/px30.c 
b/arch/arm/mach-rockchip/px30/px30.c
index 6fcef63c1b..be70d30cc8 100644
--- a/arch/arm/mach-rockchip/px30/px30.c
+++ b/arch/arm/mach-rockchip/px30/px30.c
@@ -51,6 +51,57 @@ struct mm_region *mem_map = px30_mem_map;
 
 #define QOS_PRIORITY_LEVEL(h, l)   h) & 3) << 8) | ((l) & 3))
 
+/* GRF_GPIO1AL_IOMUX */
+enum {
+   GPIO1A3_SHIFT   = 12,
+   GPIO1A3_MASK= 0xf << GPIO1A3_SHIFT,
+   GPIO1A3_GPIO= 0,
+   GPIO1A3_FLASH_D3,
+   GPIO1A3_EMMC_D3,
+   GPIO1A3_SFC_SIO3,
+
+   GPIO1A2_SHIFT   = 8,
+   GPIO1A2_MASK= 0xf << GPIO1A2_SHIFT,
+   GPIO1A2_GPIO= 0,
+   GPIO1A2_FLASH_D2,
+   GPIO1A2_EMMC_D2,
+   GPIO1A2_SFC_SIO2,
+
+   GPIO1A1_SHIFT   = 4,
+   GPIO1A1_MASK= 0xf << GPIO1A1_SHIFT,
+   GPIO1A1_GPIO= 0,
+   GPIO1A1_FLASH_D1,
+   GPIO1A1_EMMC_D1,
+   GPIO1A1_SFC_SIO1,
+
+   GPIO1A0_SHIFT   = 0,
+   GPIO1A0_MASK= 0xf << GPIO1A0_SHIFT,
+   GPIO1A0_GPIO= 0,
+   GPIO1A0_FLASH_D0,
+   GPIO1A0_EMMC_D0,
+   GPIO1A0_SFC_SIO0,
+};
+
+/* GRF_GPIO1AH_IOMUX */
+enum {
+   GPIO1A4_SHIFT   = 0,
+   GPIO1A4_MASK= 0xf << GPIO1A4_SHIFT,
+   GPIO1A4_GPIO= 0,
+   GPIO1A4_FLASH_D4,
+   GPIO1A4_EMMC_D4,
+   GPIO1A4_SFC_CSN0,
+};
+
+/* GRF_GPIO1BL_IOMUX */
+enum {
+   GPIO1B1_SHIFT   = 4,
+   GPIO1B1_MASK= 0xf << GPIO1B1_SHIFT,
+   GPIO1B1_GPIO= 0,
+   GPIO1B1_FLASH_RDY,
+   GPIO1B1_EMMC_CLKOUT,
+   GPIO1B1_SFC_CLK,
+};
+
 /* GRF_GPIO1BH_IOMUX */
 enum {
GPIO1B7_SHIFT   = 12,
@@ -193,6 +244,19 @@ int arch_cpu_init(void)
 GPIO1D4_SDMMC_D2 << GPIO1D4_SHIFT);
 #endif
 
+#ifdef CONFIG_ROCKCHIP_SFC
+   rk_clrsetreg(&grf->gpio1al_iomux,
+GPIO1A3_MASK | GPIO1A2_MASK | GPIO1A1_MASK | GPIO1A0_MASK,
+GPIO1A3_SFC_SIO3 << GPIO1A3_SHIFT |
+GPIO1A2_SFC_SIO2 << GPIO1A2_SHIFT |
+GPIO1A1_SFC_SIO1 << GPIO1A1_SHIFT |
+GPIO1A0_SFC_SIO0 << GPIO1A0_SHIFT);
+   rk_clrsetreg(&grf->gpio1ah_iomux, GPIO1A4_MASK,
+GPIO1A4_SFC_CSN0 << GPIO1A4_SHIFT);
+   rk_clrsetreg(&grf->gpio1bl_iomux, GPIO1B1_MASK,
+GPIO1B1_SFC_CLK << GPIO1B1_SHIFT);
+#endif
+
 #endif
 
/* Enable PD_VO (default disable at reset) */
-- 
2.17.1

[PATCH v8 4/5] rockchip: px30: add support for SFC for Odroid Go Advance

[Jon Lin]

From: Chris Morgan 

The Odroid Go Advance uses a Rockchip Serial Flash Controller with an
XT25F128B SPI NOR flash chip. This adds support for both. Note that
while both the controller and chip support quad mode, only two lines
are connected to the chip. Changing the pinctrl to bus2 and setting tx
and rx lines to 2 for this reason.

Signed-off-by: Chris Morgan 
Signed-off-by: Jon Lin 
---

Changes in v8:
- Change to use tx single line to make a good compatible

 arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi | 17 +
 arch/arm/dts/rk3326-odroid-go2.dts | 16 
 2 files changed, 33 insertions(+)

diff --git a/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi 
b/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
index 00767d2abd..741e8dd935 100644
--- a/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
+++ b/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
@@ -7,6 +7,15 @@
chosen {
u-boot,spl-boot-order = &sdmmc;
};
+
+   aliases {
+   i2c0 = &i2c0;
+   i2c1 = &i2c1;
+   mmc0 = &sdmmc;
+   serial1 = &uart1;
+   serial2 = &uart2;
+   spi0 = &sfc;
+   };
 };
 
 &cru {
@@ -57,6 +66,14 @@
u-boot,spl-fifo-mode;
 };
 
+&sfc {
+   u-boot,dm-pre-reloc;
+};
+
+&spi_flash {
+   u-boot,dm-pre-reloc;
+};
+
 &uart1 {
clock-frequency = <2400>;
u-boot,dm-pre-reloc;
diff --git a/arch/arm/dts/rk3326-odroid-go2.dts 
b/arch/arm/dts/rk3326-odroid-go2.dts
index 8cd4688c49..57e7f409d8 100644
--- a/arch/arm/dts/rk3326-odroid-go2.dts
+++ b/arch/arm/dts/rk3326-odroid-go2.dts
@@ -617,6 +617,22 @@
status = "okay";
 };
 
+&sfc {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&sfc_clk &sfc_cs &sfc_bus2>;
+   status = "okay";
+
+   spi_flash: xt25f128b@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <10800>;
+   spi-rx-bus-width = <2>;
+   spi-tx-bus-width = <1>;
+   };
+};
+
 &tsadc {
status = "okay";
 };
-- 
2.17.1

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

[Jon Lin]

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 v8:
- Move speed operation to set_speed logic
- Use read_poll
- Change debug to dev_dbg
- Simply exec_op dma logic

Changes in v7:
- Make sfc-use-dma configurable

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 | 646 +
 3 files changed, 655 insertions(+)
 create mode 100644 drivers/spi/rockchip_sfc.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 5c2a60a214..e12699bec7 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -319,6 +319,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 216e72c60f..d2f24bccef 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_PL022_SPI) += pl022_spi.o
 obj-$(CONFIG_SPI_QUP) += spi-qup.o
 obj-$(CONFIG_SPI_MXIC) += spi-mxic.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..8173724ecd
--- /dev/null
+++ b/drivers/spi/rockchip_sfc.c
@@ -0,0 +1,646 @@
+// 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 
+#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_SHIFT  10
+#define  SFC_CTRL_DATA_BITS_SHIFT  12
+
+/* Interrupt mask */
+#define SFC_IMR0x4
+#define  SFC_IMR_RX_FULL

[PATCH v8 3/5] rockchip: px30: add the serial flash controller

[Jon Lin]

From: Chris Morgan 

Add the serial flash controller to the devicetree for the PX30.

Signed-off-by: Chris Morgan 
Signed-off-by: Jon Lin 
---

(no changes since v5)

Changes in v5:
- px30 use "rockchip, sfc" as compatible id

 arch/arm/dts/px30.dtsi | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/arch/arm/dts/px30.dtsi b/arch/arm/dts/px30.dtsi
index b6c79e7ed3..aaa8ae2235 100644
--- a/arch/arm/dts/px30.dtsi
+++ b/arch/arm/dts/px30.dtsi
@@ -960,6 +960,18 @@
status = "disabled";
};
 
+   sfc: sfc@ff3a {
+   compatible = "rockchip,sfc";
+   reg = <0x0 0xff3a 0x0 0x4000>;
+   interrupts = ;
+   clocks = <&cru SCLK_SFC>, <&cru HCLK_SFC>;
+   clock-names = "clk_sfc", "hclk_sfc";
+   pinctrl-names = "default";
+   pinctrl-0 = <&sfc_clk &sfc_cs &sfc_bus4>;
+   power-domains = <&power PX30_PD_MMC_NAND>;
+   status = "disabled";
+   };
+
gpu: gpu@ff40 {
compatible = "rockchip,px30-mali", "arm,mali-bifrost";
reg = <0x0 0xff40 0x0 0x4000>;
@@ -1926,6 +1938,32 @@
};
};
 
+   serial_flash {
+   sfc_bus4: sfc-bus4 {
+   rockchip,pins =
+   <1 RK_PA0 3 &pcfg_pull_none>,
+   <1 RK_PA1 3 &pcfg_pull_none>,
+   <1 RK_PA2 3 &pcfg_pull_none>,
+   <1 RK_PA3 3 &pcfg_pull_none>;
+   };
+
+   sfc_bus2: sfc-bus2 {
+   rockchip,pins =
+   <1 RK_PA0 3 &pcfg_pull_none>,
+   <1 RK_PA1 3 &pcfg_pull_none>;
+   };
+
+   sfc_cs: sfc-cs {
+   rockchip,pins =
+   <1 RK_PA4 3 &pcfg_pull_none>;
+   };
+
+   sfc_clk: sfc-clk {
+   rockchip,pins =
+   <1 RK_PB1 3 &pcfg_pull_none>;
+   };
+   };
+
lcdc {
lcdc_rgb_dclk_pin: lcdc-rgb-dclk-pin {
rockchip,pins =
-- 
2.17.1

[PATCH v8 5/5] rockchip: px30: Support configure SFC

[Jon Lin]

Make px30 SFC clock configurable

Signed-off-by: Jon Lin 
Reviewed-by: Jagan Teki 
---

(no changes since v7)

Changes in v7:
- Make px30 SFC clock configurable

 drivers/clk/rockchip/clk_px30.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/clk/rockchip/clk_px30.c b/drivers/clk/rockchip/clk_px30.c
index 6b746f4c65..a49b6f19f4 100644
--- a/drivers/clk/rockchip/clk_px30.c
+++ b/drivers/clk/rockchip/clk_px30.c
@@ -581,6 +581,32 @@ static ulong px30_mmc_set_clk(struct px30_clk_priv *priv,
return px30_mmc_get_clk(priv, clk_id);
 }
 
+static ulong px30_sfc_get_clk(struct px30_clk_priv *priv, uint clk_id)
+{
+   struct px30_cru *cru = priv->cru;
+   u32 div, con;
+
+   con = readl(&cru->clksel_con[22]);
+   div = (con & SFC_DIV_CON_MASK) >> SFC_DIV_CON_SHIFT;
+
+   return DIV_TO_RATE(priv->gpll_hz, div);
+}
+
+static ulong px30_sfc_set_clk(struct px30_clk_priv *priv,
+ ulong clk_id, ulong set_rate)
+{
+   struct px30_cru *cru = priv->cru;
+   int src_clk_div;
+
+   src_clk_div = DIV_ROUND_UP(priv->gpll_hz, set_rate);
+   rk_clrsetreg(&cru->clksel_con[22],
+SFC_PLL_SEL_MASK | SFC_DIV_CON_MASK,
+0 << SFC_PLL_SEL_SHIFT |
+(src_clk_div - 1) << SFC_DIV_CON_SHIFT);
+
+   return px30_sfc_get_clk(priv, clk_id);
+}
+
 static ulong px30_pwm_get_clk(struct px30_clk_priv *priv, ulong clk_id)
 {
struct px30_cru *cru = priv->cru;
@@ -1192,6 +1218,9 @@ static ulong px30_clk_get_rate(struct clk *clk)
case SCLK_EMMC_SAMPLE:
rate = px30_mmc_get_clk(priv, clk->id);
break;
+   case SCLK_SFC:
+   rate = px30_sfc_get_clk(priv, clk->id);
+   break;
case SCLK_I2C0:
case SCLK_I2C1:
case SCLK_I2C2:
@@ -1271,6 +1300,9 @@ static ulong px30_clk_set_rate(struct clk *clk, ulong 
rate)
case SCLK_EMMC:
ret = px30_mmc_set_clk(priv, clk->id, rate);
break;
+   case SCLK_SFC:
+   ret = px30_sfc_set_clk(priv, clk->id, rate);
+   break;
case SCLK_I2C0:
case SCLK_I2C1:
case SCLK_I2C2:
-- 
2.17.1

Re: [PATCH v4 07/10] watchdog: wdt-uclass.c: handle all DM watchdogs in watchdog_reset()

[Tom Rini]

On Thu, Aug 12, 2021 at 08:40:21AM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20210811124318.GT858@bill-the-cat> you wrote:
> > 
> > > This argument fits on all types or effors: they are supposed to
> > > never ever happen - at least in theory; in reality they do, and more
> > > often than we like.
> > > 
> > > And a proper error message is mandatory for correct error handling.
> > 
> > Error messages are a fine line to walk.  We've got to have been very
> > badly corrupted to go down this error path.  There's going to be lots of
> > other error messages popping out.  Saving a bit of .text is good.  It
> > makes it easier to justify spending a little .text later.
> 
> Letting errors slip through unnoticed when there is a trival way to
> at least inform the user of the problem is simply unacceptable.
> 
> Please do not let U-Boot degrade into such a crappy piece of code.
> 
> There are tons of other places where we don't even mention code
> size, so if you want to save on that, there are many bette4r places
> to save than error handling.

Alright, lets take a look at what kind of area of the code we're talking
about.  uclass_get is a pretty fundamental thing.  If that fails, your
system is on fire.  Things are massively corrupt.  Lets look at other
existing callers to see what happens.  Most callers check the return
code, like you need to, and pass it up the chain to deal with.  We have
a few board specific ones such as
board/Marvell/octeontx2/board.c::board_quiesce_devices() that is also
conceptually like the x530 case in the next part of the series.  That
does print on failure.  The rest of the ones that print an error message
are about commands and it's somewhat helpful there.

So yes, return codes need to be checked and passed.  But no, not every
single error path needs to print to the user along every part of an
error path either.

> > And here I agree, catch an error code, pass the error code back to the
> > caller.  That's far more important than making sure that every error
> > code we catch logs a message by default every time.
> 
> It does not matter where the error is reported - in the called
> function, or in some caller firther up the call tree.  But it _must_
> be reportet at least once.
> 
> So if we don't issue an error message here, we need to check and fix
> the callers, too.

That would be the next patch in the series where the BSP author isn't
currently checking the return value, and this series doesn't change
that.  Perhaps it should, and CC the maintainer.  But I think has been
said a few times over the course of this series, what exactly is one
going to do about the failure?  Getting specific for a moment, if you're
in the case of "shutdown the watchdog" and the watchdog doesn't shutdown
like you want it to, do you hang and hope the watchdog is alive to kick
things still?  hang and lock the system?  Figure the system is on fire
anyhow but add another message to the failure spew?

Again, I think the change that's needed to this patch is to make it
return the error code to the caller.  Let the caller decide.  And make
sure to CC the board maintainer on the next go-round so they can chime
in about that.

-- 
Tom


signature.asc
Description: PGP signature

[RFC PATCH v8 0/6] rockchip_sfc: add support for Rockchip SFC

[Jon Lin]

Changes in v8:
- Move speed operation to set_speed logic
- Use read_poll
- Change debug to dev_dbg
- Simply exec_op dma logic
- Change to use tx single line to make a good compatible
- Change spiflash dts node

Changes in v7:
- Make sfc-use-dma configurable
- Make px30 SFC clock configurable

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
- px30 use "rockchip, sfc" as compatible id

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

Chris Morgan (4):
  spi: rockchip_sfc: add support for Rockchip SFC
  rockchip: px30: Add support for using SFC
  rockchip: px30: add the serial flash controller
  rockchip: px30: add support for SFC for Odroid Go Advance

Jon Lin (1):
  rockchip: px30: Support configure SFC

Tom Rini (1):
  CI: Update to LLVM-12

 .azure-pipelines.yml   |   4 +-
 .gitlab-ci.yml |   4 +-
 arch/arm/dts/px30.dtsi |  38 ++
 arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi |  17 +
 arch/arm/dts/rk3326-odroid-go2.dts |  16 +
 arch/arm/mach-rockchip/px30/px30.c |  64 ++
 drivers/clk/rockchip/clk_px30.c|  32 +
 drivers/spi/Kconfig|   8 +
 drivers/spi/Makefile   |   1 +
 drivers/spi/rockchip_sfc.c | 646 +
 tools/docker/Dockerfile|   6 +-
 11 files changed, 829 insertions(+), 7 deletions(-)
 create mode 100644 drivers/spi/rockchip_sfc.c

-- 
2.17.1

[RFC PATCH v8 1/6] CI: Update to LLVM-12

[Jon Lin]

From: Tom Rini 

The current stable release of LLVM is 12, update to that.  While at it,
fix that we had not correctly upgraded to LLVM 11 previously.

Signed-off-by: Tom Rini 
Signed-off-by: Jon Lin 
---

(no changes since v1)

 .azure-pipelines.yml| 4 ++--
 .gitlab-ci.yml  | 4 ++--
 tools/docker/Dockerfile | 6 +++---
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index c088e1ac99..0cf73025f7 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -2,7 +2,7 @@ variables:
   windows_vm: vs2017-win2016
   ubuntu_vm: ubuntu-18.04
   macos_vm: macOS-10.15
-  ci_runner_image: trini/u-boot-gitlab-ci-runner:focal-20210609-06Jul2021
+  ci_runner_image: trini/u-boot-gitlab-ci-runner:focal-20210723-04Aug2021
   # Add '-u 0' options for Azure pipelines, otherwise we get "permission
   # denied" error when it tries to "useradd -m -u 1001 vsts_azpcontainer",
   # since our $(ci_runner_image) user is not root.
@@ -183,7 +183,7 @@ jobs:
   TEST_PY_BD: "sandbox"
 sandbox_clang:
   TEST_PY_BD: "sandbox"
-  OVERRIDE: "-O clang-10"
+  OVERRIDE: "-O clang-12"
 sandbox_spl:
   TEST_PY_BD: "sandbox_spl"
   TEST_PY_TEST_SPEC: "test_ofplatdata or test_handoff or test_spl"
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 86026a15f9..ffdeaae5a8 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -2,7 +2,7 @@
 
 # Grab our configured image.  The source for this is found at:
 # https://source.denx.de/u-boot/gitlab-ci-runner
-image: trini/u-boot-gitlab-ci-runner:focal-20210609-06Jul2021
+image: trini/u-boot-gitlab-ci-runner:focal-20210723-04Aug2021
 
 # We run some tests in different order, to catch some failures quicker.
 stages:
@@ -178,7 +178,7 @@ sandbox test.py:
 sandbox with clang test.py:
   variables:
 TEST_PY_BD: "sandbox"
-OVERRIDE: "-O clang-10"
+OVERRIDE: "-O clang-12"
   <<: *buildman_and_testpy_dfn
 
 sandbox_spl test.py:
diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile
index ced4457ab2..0195456dfe 100644
--- a/tools/docker/Dockerfile
+++ b/tools/docker/Dockerfile
@@ -2,7 +2,7 @@
 # This Dockerfile is used to build an image containing basic stuff to be used
 # to build U-Boot and run our test suites.
 
-FROM ubuntu:focal-20210609
+FROM ubuntu:focal-20210723
 MAINTAINER Tom Rini 
 LABEL Description=" This image is for building U-Boot inside a container"
 
@@ -12,7 +12,7 @@ ENV DEBIAN_FRONTEND=noninteractive
 # Add LLVM repository
 RUN apt-get update && apt-get install -y gnupg2 wget xz-utils && rm -rf 
/var/lib/apt/lists/*
 RUN wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key | apt-key add -
-RUN echo deb http://apt.llvm.org/focal/ llvm-toolchain-focal-11 main | tee 
/etc/apt/sources.list.d/llvm.list
+RUN echo deb http://apt.llvm.org/focal/ llvm-toolchain-focal-12 main | tee 
/etc/apt/sources.list.d/llvm.list
 
 # Manually install the kernel.org "Crosstool" based toolchains for gcc-11.1.0
 RUN wget -O - 
https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/11.1.0/x86_64-gcc-11.1.0-nolibc-aarch64-linux.tar.xz
 | tar -C /opt -xJ
@@ -39,7 +39,7 @@ RUN apt-get update && apt-get install -y \
binutils-dev \
bison \
build-essential \
-   clang-10 \
+   clang-12 \
coreutils \
cpio \
cppcheck \
-- 
2.17.1

[RFC PATCH v8 2/6] spi: rockchip_sfc: add support for Rockchip SFC

[Jon Lin]

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 v8:
- Move speed operation to set_speed logic
- Use read_poll
- Change debug to dev_dbg
- Simply exec_op dma logic

Changes in v7:
- Make sfc-use-dma configurable

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 | 646 +
 3 files changed, 655 insertions(+)
 create mode 100644 drivers/spi/rockchip_sfc.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 5c2a60a214..e12699bec7 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -319,6 +319,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 216e72c60f..d2f24bccef 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_PL022_SPI) += pl022_spi.o
 obj-$(CONFIG_SPI_QUP) += spi-qup.o
 obj-$(CONFIG_SPI_MXIC) += spi-mxic.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..8173724ecd
--- /dev/null
+++ b/drivers/spi/rockchip_sfc.c
@@ -0,0 +1,646 @@
+// 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 
+#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_SHIFT  10
+#define  SFC_CTRL_DATA_BITS_SHIFT  12
+
+/* Interrupt mask */
+#define SFC_IMR0x4
+#define  SFC_IMR_RX_FULL

[RFC PATCH v8 3/6] rockchip: px30: Add support for using SFC

[Jon Lin]

From: Chris Morgan 

This patch adds support for setting the correct pin configuration
for the Rockchip Serial Flash Controller found on the PX30.

Signed-off-by: Chris Morgan 
Signed-off-by: Jon Lin 
Reviewed-by: Kever Yang 
---

(no changes since v1)

 arch/arm/mach-rockchip/px30/px30.c | 64 ++
 1 file changed, 64 insertions(+)

diff --git a/arch/arm/mach-rockchip/px30/px30.c 
b/arch/arm/mach-rockchip/px30/px30.c
index 6fcef63c1b..be70d30cc8 100644
--- a/arch/arm/mach-rockchip/px30/px30.c
+++ b/arch/arm/mach-rockchip/px30/px30.c
@@ -51,6 +51,57 @@ struct mm_region *mem_map = px30_mem_map;
 
 #define QOS_PRIORITY_LEVEL(h, l)   h) & 3) << 8) | ((l) & 3))
 
+/* GRF_GPIO1AL_IOMUX */
+enum {
+   GPIO1A3_SHIFT   = 12,
+   GPIO1A3_MASK= 0xf << GPIO1A3_SHIFT,
+   GPIO1A3_GPIO= 0,
+   GPIO1A3_FLASH_D3,
+   GPIO1A3_EMMC_D3,
+   GPIO1A3_SFC_SIO3,
+
+   GPIO1A2_SHIFT   = 8,
+   GPIO1A2_MASK= 0xf << GPIO1A2_SHIFT,
+   GPIO1A2_GPIO= 0,
+   GPIO1A2_FLASH_D2,
+   GPIO1A2_EMMC_D2,
+   GPIO1A2_SFC_SIO2,
+
+   GPIO1A1_SHIFT   = 4,
+   GPIO1A1_MASK= 0xf << GPIO1A1_SHIFT,
+   GPIO1A1_GPIO= 0,
+   GPIO1A1_FLASH_D1,
+   GPIO1A1_EMMC_D1,
+   GPIO1A1_SFC_SIO1,
+
+   GPIO1A0_SHIFT   = 0,
+   GPIO1A0_MASK= 0xf << GPIO1A0_SHIFT,
+   GPIO1A0_GPIO= 0,
+   GPIO1A0_FLASH_D0,
+   GPIO1A0_EMMC_D0,
+   GPIO1A0_SFC_SIO0,
+};
+
+/* GRF_GPIO1AH_IOMUX */
+enum {
+   GPIO1A4_SHIFT   = 0,
+   GPIO1A4_MASK= 0xf << GPIO1A4_SHIFT,
+   GPIO1A4_GPIO= 0,
+   GPIO1A4_FLASH_D4,
+   GPIO1A4_EMMC_D4,
+   GPIO1A4_SFC_CSN0,
+};
+
+/* GRF_GPIO1BL_IOMUX */
+enum {
+   GPIO1B1_SHIFT   = 4,
+   GPIO1B1_MASK= 0xf << GPIO1B1_SHIFT,
+   GPIO1B1_GPIO= 0,
+   GPIO1B1_FLASH_RDY,
+   GPIO1B1_EMMC_CLKOUT,
+   GPIO1B1_SFC_CLK,
+};
+
 /* GRF_GPIO1BH_IOMUX */
 enum {
GPIO1B7_SHIFT   = 12,
@@ -193,6 +244,19 @@ int arch_cpu_init(void)
 GPIO1D4_SDMMC_D2 << GPIO1D4_SHIFT);
 #endif
 
+#ifdef CONFIG_ROCKCHIP_SFC
+   rk_clrsetreg(&grf->gpio1al_iomux,
+GPIO1A3_MASK | GPIO1A2_MASK | GPIO1A1_MASK | GPIO1A0_MASK,
+GPIO1A3_SFC_SIO3 << GPIO1A3_SHIFT |
+GPIO1A2_SFC_SIO2 << GPIO1A2_SHIFT |
+GPIO1A1_SFC_SIO1 << GPIO1A1_SHIFT |
+GPIO1A0_SFC_SIO0 << GPIO1A0_SHIFT);
+   rk_clrsetreg(&grf->gpio1ah_iomux, GPIO1A4_MASK,
+GPIO1A4_SFC_CSN0 << GPIO1A4_SHIFT);
+   rk_clrsetreg(&grf->gpio1bl_iomux, GPIO1B1_MASK,
+GPIO1B1_SFC_CLK << GPIO1B1_SHIFT);
+#endif
+
 #endif
 
/* Enable PD_VO (default disable at reset) */
-- 
2.17.1

[RFC PATCH v8 4/6] rockchip: px30: add the serial flash controller

[Jon Lin]

From: Chris Morgan 

Add the serial flash controller to the devicetree for the PX30.

Signed-off-by: Chris Morgan 
Signed-off-by: Jon Lin 
Reviewed-by: Kever Yang 
---

(no changes since v5)

Changes in v5:
- px30 use "rockchip, sfc" as compatible id

 arch/arm/dts/px30.dtsi | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/arch/arm/dts/px30.dtsi b/arch/arm/dts/px30.dtsi
index b6c79e7ed3..aaa8ae2235 100644
--- a/arch/arm/dts/px30.dtsi
+++ b/arch/arm/dts/px30.dtsi
@@ -960,6 +960,18 @@
status = "disabled";
};
 
+   sfc: sfc@ff3a {
+   compatible = "rockchip,sfc";
+   reg = <0x0 0xff3a 0x0 0x4000>;
+   interrupts = ;
+   clocks = <&cru SCLK_SFC>, <&cru HCLK_SFC>;
+   clock-names = "clk_sfc", "hclk_sfc";
+   pinctrl-names = "default";
+   pinctrl-0 = <&sfc_clk &sfc_cs &sfc_bus4>;
+   power-domains = <&power PX30_PD_MMC_NAND>;
+   status = "disabled";
+   };
+
gpu: gpu@ff40 {
compatible = "rockchip,px30-mali", "arm,mali-bifrost";
reg = <0x0 0xff40 0x0 0x4000>;
@@ -1926,6 +1938,32 @@
};
};
 
+   serial_flash {
+   sfc_bus4: sfc-bus4 {
+   rockchip,pins =
+   <1 RK_PA0 3 &pcfg_pull_none>,
+   <1 RK_PA1 3 &pcfg_pull_none>,
+   <1 RK_PA2 3 &pcfg_pull_none>,
+   <1 RK_PA3 3 &pcfg_pull_none>;
+   };
+
+   sfc_bus2: sfc-bus2 {
+   rockchip,pins =
+   <1 RK_PA0 3 &pcfg_pull_none>,
+   <1 RK_PA1 3 &pcfg_pull_none>;
+   };
+
+   sfc_cs: sfc-cs {
+   rockchip,pins =
+   <1 RK_PA4 3 &pcfg_pull_none>;
+   };
+
+   sfc_clk: sfc-clk {
+   rockchip,pins =
+   <1 RK_PB1 3 &pcfg_pull_none>;
+   };
+   };
+
lcdc {
lcdc_rgb_dclk_pin: lcdc-rgb-dclk-pin {
rockchip,pins =
-- 
2.17.1

[RFC PATCH v8 1/5] spi: rockchip_sfc: add support for Rockchip SFC

[Jon Lin]

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 v8:
- Move speed operation to set_speed logic
- Use read_poll
- Change debug to dev_dbg
- Simply exec_op dma logic

Changes in v7:
- Make sfc-use-dma configurable

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 | 646 +
 3 files changed, 655 insertions(+)
 create mode 100644 drivers/spi/rockchip_sfc.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 5c2a60a214..e12699bec7 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -319,6 +319,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 216e72c60f..d2f24bccef 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_PL022_SPI) += pl022_spi.o
 obj-$(CONFIG_SPI_QUP) += spi-qup.o
 obj-$(CONFIG_SPI_MXIC) += spi-mxic.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..8173724ecd
--- /dev/null
+++ b/drivers/spi/rockchip_sfc.c
@@ -0,0 +1,646 @@
+// 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 
+#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_SHIFT  10
+#define  SFC_CTRL_DATA_BITS_SHIFT  12
+
+/* Interrupt mask */
+#define SFC_IMR0x4
+#define  SFC_IMR_RX_FULL

[RFC PATCH v8 0/5] rockchip_sfc: add support for Rockchip SFC

[Jon Lin]

Changes in v8:
- Move speed operation to set_speed logic
- Use read_poll
- Change debug to dev_dbg
- Simply exec_op dma logic
- Change to use tx single line to make a good compatible
- Change spiflash dts node

Changes in v7:
- Make sfc-use-dma configurable
- Make px30 SFC clock configurable

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
- px30 use "rockchip, sfc" as compatible id

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

Chris Morgan (4):
  spi: rockchip_sfc: add support for Rockchip SFC
  rockchip: px30: Add support for using SFC
  rockchip: px30: add the serial flash controller
  rockchip: px30: add support for SFC for Odroid Go Advance

Jon Lin (1):
  rockchip: px30: Support configure SFC

 arch/arm/dts/px30.dtsi |  38 ++
 arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi |  17 +
 arch/arm/dts/rk3326-odroid-go2.dts |  16 +
 arch/arm/mach-rockchip/px30/px30.c |  64 ++
 drivers/clk/rockchip/clk_px30.c|  32 +
 drivers/spi/Kconfig|   8 +
 drivers/spi/Makefile   |   1 +
 drivers/spi/rockchip_sfc.c | 646 +
 8 files changed, 822 insertions(+)
 create mode 100644 drivers/spi/rockchip_sfc.c

-- 
2.17.1

[RFC PATCH v8 4/5] rockchip: px30: add support for SFC for Odroid Go Advance

[Jon Lin]

From: Chris Morgan 

The Odroid Go Advance uses a Rockchip Serial Flash Controller with an
XT25F128B SPI NOR flash chip. This adds support for both. Note that
while both the controller and chip support quad mode, only two lines
are connected to the chip. Changing the pinctrl to bus2 and setting tx
and rx lines to 2 for this reason.

Signed-off-by: Chris Morgan 
Signed-off-by: Jon Lin 
---

Changes in v8:
- Change to use tx single line to make a good compatible
- Change spiflash dts node

 arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi | 17 +
 arch/arm/dts/rk3326-odroid-go2.dts | 16 
 2 files changed, 33 insertions(+)

diff --git a/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi 
b/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
index 00767d2abd..0990005a15 100644
--- a/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
+++ b/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
@@ -7,6 +7,15 @@
chosen {
u-boot,spl-boot-order = &sdmmc;
};
+
+   aliases {
+   i2c0 = &i2c0;
+   i2c1 = &i2c1;
+   mmc0 = &sdmmc;
+   serial1 = &uart1;
+   serial2 = &uart2;
+   spi0 = &sfc;
+   };
 };
 
 &cru {
@@ -57,6 +66,14 @@
u-boot,spl-fifo-mode;
 };
 
+&sfc {
+   u-boot,dm-pre-reloc;
+};
+
+&{/sfc@ff3a/flash@0} {
+   u-boot,dm-pre-reloc;
+};
+
 &uart1 {
clock-frequency = <2400>;
u-boot,dm-pre-reloc;
diff --git a/arch/arm/dts/rk3326-odroid-go2.dts 
b/arch/arm/dts/rk3326-odroid-go2.dts
index 8cd4688c49..3866cc6612 100644
--- a/arch/arm/dts/rk3326-odroid-go2.dts
+++ b/arch/arm/dts/rk3326-odroid-go2.dts
@@ -617,6 +617,22 @@
status = "okay";
 };
 
+&sfc {
+   pinctrl-0 = <&sfc_clk &sfc_cs &sfc_bus2>;
+   pinctrl-names = "default";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "okay";
+
+   flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <10800>;
+   spi-rx-bus-width = <2>;
+   spi-tx-bus-width = <1>;
+   };
+};
+
 &tsadc {
status = "okay";
 };
-- 
2.17.1

[RFC PATCH v8 3/5] rockchip: px30: add the serial flash controller

[Jon Lin]

From: Chris Morgan 

Add the serial flash controller to the devicetree for the PX30.

Signed-off-by: Chris Morgan 
Signed-off-by: Jon Lin 
Reviewed-by: Kever Yang 
---

(no changes since v5)

Changes in v5:
- px30 use "rockchip, sfc" as compatible id

 arch/arm/dts/px30.dtsi | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/arch/arm/dts/px30.dtsi b/arch/arm/dts/px30.dtsi
index b6c79e7ed3..aaa8ae2235 100644
--- a/arch/arm/dts/px30.dtsi
+++ b/arch/arm/dts/px30.dtsi
@@ -960,6 +960,18 @@
status = "disabled";
};
 
+   sfc: sfc@ff3a {
+   compatible = "rockchip,sfc";
+   reg = <0x0 0xff3a 0x0 0x4000>;
+   interrupts = ;
+   clocks = <&cru SCLK_SFC>, <&cru HCLK_SFC>;
+   clock-names = "clk_sfc", "hclk_sfc";
+   pinctrl-names = "default";
+   pinctrl-0 = <&sfc_clk &sfc_cs &sfc_bus4>;
+   power-domains = <&power PX30_PD_MMC_NAND>;
+   status = "disabled";
+   };
+
gpu: gpu@ff40 {
compatible = "rockchip,px30-mali", "arm,mali-bifrost";
reg = <0x0 0xff40 0x0 0x4000>;
@@ -1926,6 +1938,32 @@
};
};
 
+   serial_flash {
+   sfc_bus4: sfc-bus4 {
+   rockchip,pins =
+   <1 RK_PA0 3 &pcfg_pull_none>,
+   <1 RK_PA1 3 &pcfg_pull_none>,
+   <1 RK_PA2 3 &pcfg_pull_none>,
+   <1 RK_PA3 3 &pcfg_pull_none>;
+   };
+
+   sfc_bus2: sfc-bus2 {
+   rockchip,pins =
+   <1 RK_PA0 3 &pcfg_pull_none>,
+   <1 RK_PA1 3 &pcfg_pull_none>;
+   };
+
+   sfc_cs: sfc-cs {
+   rockchip,pins =
+   <1 RK_PA4 3 &pcfg_pull_none>;
+   };
+
+   sfc_clk: sfc-clk {
+   rockchip,pins =
+   <1 RK_PB1 3 &pcfg_pull_none>;
+   };
+   };
+
lcdc {
lcdc_rgb_dclk_pin: lcdc-rgb-dclk-pin {
rockchip,pins =
-- 
2.17.1

[RFC PATCH v8 2/5] rockchip: px30: Add support for using SFC

[Jon Lin]

From: Chris Morgan 

This patch adds support for setting the correct pin configuration
for the Rockchip Serial Flash Controller found on the PX30.

Signed-off-by: Chris Morgan 
Signed-off-by: Jon Lin 
Reviewed-by: Kever Yang 
---

(no changes since v1)

 arch/arm/mach-rockchip/px30/px30.c | 64 ++
 1 file changed, 64 insertions(+)

diff --git a/arch/arm/mach-rockchip/px30/px30.c 
b/arch/arm/mach-rockchip/px30/px30.c
index 6fcef63c1b..be70d30cc8 100644
--- a/arch/arm/mach-rockchip/px30/px30.c
+++ b/arch/arm/mach-rockchip/px30/px30.c
@@ -51,6 +51,57 @@ struct mm_region *mem_map = px30_mem_map;
 
 #define QOS_PRIORITY_LEVEL(h, l)   h) & 3) << 8) | ((l) & 3))
 
+/* GRF_GPIO1AL_IOMUX */
+enum {
+   GPIO1A3_SHIFT   = 12,
+   GPIO1A3_MASK= 0xf << GPIO1A3_SHIFT,
+   GPIO1A3_GPIO= 0,
+   GPIO1A3_FLASH_D3,
+   GPIO1A3_EMMC_D3,
+   GPIO1A3_SFC_SIO3,
+
+   GPIO1A2_SHIFT   = 8,
+   GPIO1A2_MASK= 0xf << GPIO1A2_SHIFT,
+   GPIO1A2_GPIO= 0,
+   GPIO1A2_FLASH_D2,
+   GPIO1A2_EMMC_D2,
+   GPIO1A2_SFC_SIO2,
+
+   GPIO1A1_SHIFT   = 4,
+   GPIO1A1_MASK= 0xf << GPIO1A1_SHIFT,
+   GPIO1A1_GPIO= 0,
+   GPIO1A1_FLASH_D1,
+   GPIO1A1_EMMC_D1,
+   GPIO1A1_SFC_SIO1,
+
+   GPIO1A0_SHIFT   = 0,
+   GPIO1A0_MASK= 0xf << GPIO1A0_SHIFT,
+   GPIO1A0_GPIO= 0,
+   GPIO1A0_FLASH_D0,
+   GPIO1A0_EMMC_D0,
+   GPIO1A0_SFC_SIO0,
+};
+
+/* GRF_GPIO1AH_IOMUX */
+enum {
+   GPIO1A4_SHIFT   = 0,
+   GPIO1A4_MASK= 0xf << GPIO1A4_SHIFT,
+   GPIO1A4_GPIO= 0,
+   GPIO1A4_FLASH_D4,
+   GPIO1A4_EMMC_D4,
+   GPIO1A4_SFC_CSN0,
+};
+
+/* GRF_GPIO1BL_IOMUX */
+enum {
+   GPIO1B1_SHIFT   = 4,
+   GPIO1B1_MASK= 0xf << GPIO1B1_SHIFT,
+   GPIO1B1_GPIO= 0,
+   GPIO1B1_FLASH_RDY,
+   GPIO1B1_EMMC_CLKOUT,
+   GPIO1B1_SFC_CLK,
+};
+
 /* GRF_GPIO1BH_IOMUX */
 enum {
GPIO1B7_SHIFT   = 12,
@@ -193,6 +244,19 @@ int arch_cpu_init(void)
 GPIO1D4_SDMMC_D2 << GPIO1D4_SHIFT);
 #endif
 
+#ifdef CONFIG_ROCKCHIP_SFC
+   rk_clrsetreg(&grf->gpio1al_iomux,
+GPIO1A3_MASK | GPIO1A2_MASK | GPIO1A1_MASK | GPIO1A0_MASK,
+GPIO1A3_SFC_SIO3 << GPIO1A3_SHIFT |
+GPIO1A2_SFC_SIO2 << GPIO1A2_SHIFT |
+GPIO1A1_SFC_SIO1 << GPIO1A1_SHIFT |
+GPIO1A0_SFC_SIO0 << GPIO1A0_SHIFT);
+   rk_clrsetreg(&grf->gpio1ah_iomux, GPIO1A4_MASK,
+GPIO1A4_SFC_CSN0 << GPIO1A4_SHIFT);
+   rk_clrsetreg(&grf->gpio1bl_iomux, GPIO1B1_MASK,
+GPIO1B1_SFC_CLK << GPIO1B1_SHIFT);
+#endif
+
 #endif
 
/* Enable PD_VO (default disable at reset) */
-- 
2.17.1

[RFC PATCH v8 5/5] rockchip: px30: Support configure SFC

[Jon Lin]

Make px30 SFC clock configurable

Signed-off-by: Jon Lin 
Reviewed-by: Jagan Teki 
Reviewed-by: Kever Yang 
Reviewed-by: Philipp Tomsich 
---

(no changes since v7)

Changes in v7:
- Make px30 SFC clock configurable

 drivers/clk/rockchip/clk_px30.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/clk/rockchip/clk_px30.c b/drivers/clk/rockchip/clk_px30.c
index 6b746f4c65..a49b6f19f4 100644
--- a/drivers/clk/rockchip/clk_px30.c
+++ b/drivers/clk/rockchip/clk_px30.c
@@ -581,6 +581,32 @@ static ulong px30_mmc_set_clk(struct px30_clk_priv *priv,
return px30_mmc_get_clk(priv, clk_id);
 }
 
+static ulong px30_sfc_get_clk(struct px30_clk_priv *priv, uint clk_id)
+{
+   struct px30_cru *cru = priv->cru;
+   u32 div, con;
+
+   con = readl(&cru->clksel_con[22]);
+   div = (con & SFC_DIV_CON_MASK) >> SFC_DIV_CON_SHIFT;
+
+   return DIV_TO_RATE(priv->gpll_hz, div);
+}
+
+static ulong px30_sfc_set_clk(struct px30_clk_priv *priv,
+ ulong clk_id, ulong set_rate)
+{
+   struct px30_cru *cru = priv->cru;
+   int src_clk_div;
+
+   src_clk_div = DIV_ROUND_UP(priv->gpll_hz, set_rate);
+   rk_clrsetreg(&cru->clksel_con[22],
+SFC_PLL_SEL_MASK | SFC_DIV_CON_MASK,
+0 << SFC_PLL_SEL_SHIFT |
+(src_clk_div - 1) << SFC_DIV_CON_SHIFT);
+
+   return px30_sfc_get_clk(priv, clk_id);
+}
+
 static ulong px30_pwm_get_clk(struct px30_clk_priv *priv, ulong clk_id)
 {
struct px30_cru *cru = priv->cru;
@@ -1192,6 +1218,9 @@ static ulong px30_clk_get_rate(struct clk *clk)
case SCLK_EMMC_SAMPLE:
rate = px30_mmc_get_clk(priv, clk->id);
break;
+   case SCLK_SFC:
+   rate = px30_sfc_get_clk(priv, clk->id);
+   break;
case SCLK_I2C0:
case SCLK_I2C1:
case SCLK_I2C2:
@@ -1271,6 +1300,9 @@ static ulong px30_clk_set_rate(struct clk *clk, ulong 
rate)
case SCLK_EMMC:
ret = px30_mmc_set_clk(priv, clk->id, rate);
break;
+   case SCLK_SFC:
+   ret = px30_sfc_set_clk(priv, clk->id, rate);
+   break;
case SCLK_I2C0:
case SCLK_I2C1:
case SCLK_I2C2:
-- 
2.17.1

Re: [PATCH v4 07/10] watchdog: wdt-uclass.c: handle all DM watchdogs in watchdog_reset()

[Simon Glass]

Hi Tom,

On Thu, 12 Aug 2021 at 07:48, Tom Rini  wrote:
>
> On Thu, Aug 12, 2021 at 08:40:21AM +0200, Wolfgang Denk wrote:
> > Dear Tom,
> >
> > In message <20210811124318.GT858@bill-the-cat> you wrote:
> > >
> > > > This argument fits on all types or effors: they are supposed to
> > > > never ever happen - at least in theory; in reality they do, and more
> > > > often than we like.
> > > >
> > > > And a proper error message is mandatory for correct error handling.
> > >
> > > Error messages are a fine line to walk.  We've got to have been very
> > > badly corrupted to go down this error path.  There's going to be lots of
> > > other error messages popping out.  Saving a bit of .text is good.  It
> > > makes it easier to justify spending a little .text later.
> >
> > Letting errors slip through unnoticed when there is a trival way to
> > at least inform the user of the problem is simply unacceptable.
> >
> > Please do not let U-Boot degrade into such a crappy piece of code.
> >
> > There are tons of other places where we don't even mention code
> > size, so if you want to save on that, there are many bette4r places
> > to save than error handling.
>
> Alright, lets take a look at what kind of area of the code we're talking
> about.  uclass_get is a pretty fundamental thing.  If that fails, your
> system is on fire.  Things are massively corrupt.  Lets look at other
> existing callers to see what happens.  Most callers check the return
> code, like you need to, and pass it up the chain to deal with.  We have
> a few board specific ones such as
> board/Marvell/octeontx2/board.c::board_quiesce_devices() that is also
> conceptually like the x530 case in the next part of the series.  That
> does print on failure.  The rest of the ones that print an error message
> are about commands and it's somewhat helpful there.
>
> So yes, return codes need to be checked and passed.  But no, not every
> single error path needs to print to the user along every part of an
> error path either.
>
> > > And here I agree, catch an error code, pass the error code back to the
> > > caller.  That's far more important than making sure that every error
> > > code we catch logs a message by default every time.
> >
> > It does not matter where the error is reported - in the called
> > function, or in some caller firther up the call tree.  But it _must_
> > be reportet at least once.
> >
> > So if we don't issue an error message here, we need to check and fix
> > the callers, too.
>
> That would be the next patch in the series where the BSP author isn't
> currently checking the return value, and this series doesn't change
> that.  Perhaps it should, and CC the maintainer.  But I think has been
> said a few times over the course of this series, what exactly is one
> going to do about the failure?  Getting specific for a moment, if you're
> in the case of "shutdown the watchdog" and the watchdog doesn't shutdown
> like you want it to, do you hang and hope the watchdog is alive to kick
> things still?  hang and lock the system?  Figure the system is on fire
> anyhow but add another message to the failure spew?
>
> Again, I think the change that's needed to this patch is to make it
> return the error code to the caller.  Let the caller decide.  And make
> sure to CC the board maintainer on the next go-round so they can chime
> in about that.

I strongly agree with this.I try to encourage people not to report
errors inside drivers, since the caller should be able to deal with
it, particularly if the error number provides useful information. It
bloats the code.

But we do have these strange cases where there is no obvious thing to
do. Where we are probing several devices to fire them up and one
fails, people worry that this means that some of them won't get
probed. In that case I tend to continue on and probe them all, but
then return error if any of them failed. At least the caller knows.

Also I like the new log_ret() and log_msg_ret() functions, which can
log an error as it goes up the stack if LOG_ERROR_RETURN is enabled.
It is nice to be able to see where an error came from. We could
perhaps improve this by logging the error when it is created (the
first time some calls 'return -Exxx').

I'm not a fan of board code which calls a function and doesn't check
the error. The board may not operate correctly, or it may limp along,
but the board author should be able to get all the bugs of it at the
start so that we are not requested invalid clocks, etc.

Regards,
Simon

Re: [PATCH v4 07/10] watchdog: wdt-uclass.c: handle all DM watchdogs in watchdog_reset()

[Wolfgang Denk]

Dear Tom,

In message <20210812134833.GU858@bill-the-cat> you wrote:
> 
> Alright, lets take a look at what kind of area of the code we're talking
> about.  uclass_get is a pretty fundamental thing.  If that fails, your
> system is on fire.  Things are massively corrupt.

Full agreement here.

> So yes, return codes need to be checked and passed.  But no, not every
> single error path needs to print to the user along every part of an
> error path either.

So if "the system is on fire" is one of the cases where an error
message should be omitted to save maybe 50 or 100 bytes of image
size?  This sounds wrong to me.

When a system crashes or hangs, it is extremely helpful to gen an
indication of what happened.

Printing messages only with debug enabled is pretty worthless, as in
the real world the failures will happen in the field when running
the production image with debug not enabled.

And as soon as you do enable debug, you will have a different image,
which may or may not show the problem.  We have all been there
before.

> That would be the next patch in the series where the BSP author isn't
> currently checking the return value, and this series doesn't change
> that.  Perhaps it should, and CC the maintainer.

Indeed.

> But I think has been
> said a few times over the course of this series, what exactly is one
> going to do about the failure?  Getting specific for a moment, if you're
> in the case of "shutdown the watchdog" and the watchdog doesn't shutdown
> like you want it to, do you hang and hope the watchdog is alive to kick
> things still?  hang and lock the system?  Figure the system is on fire
> anyhow but add another message to the failure spew?

Adding a message about the _cause_ of the failure, i. e. at least
information about the place where it was first detected, is what
will be helpful to the engineer who is supposed to analyze the
problem.

And yes, if such a fundamental operation fails, it is wise to abort
the operation of this device - either by hard resetting it or by
hanging it, depending of what the chances are that a reboot might
fix the problem.

IMO it is better to fail a broken device in a reliable mode instead
of letting it run and having more spectacular crashes (likely with
more serious consequences) happen later.

> Again, I think the change that's needed to this patch is to make it
> return the error code to the caller.  Let the caller decide.  And make
> sure to CC the board maintainer on the next go-round so they can chime
> in about that.

If we agree that in the disputed case "the system is on fire", then
there is actually very little to decide.  There should be only one
possible action: stop here, before more damage happens.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
... not meant for the weak-at-heart: /^(?=.*one)(?=.*two)/
If you can follow that, you can use it.
  - Randal L. Schwartz in 

Hints on how to use efi_driver/efi_block_device.c

[Christian Melki]

I was hoping that U-boot would detect BLOCK_IO devices provided by UEFI 
automatically. But I can't see anything attached under lsblk or find 
some other information about this.
For example, Barebox works just fine on both Virtualbox and real 
hardware in this regard.


Barebox does not have an emmc driver for the real hardware but 
piggybacks off the UEFI protocol for this.


I'm sure that the idea with this U-boot driver is something like that, 
but would appreciate some hints on how to use it.


Ie, standard usage. UEFI boots of a drive, posts some handles(?) to a 
block device and U-boot picks it up, not knowing more about the 
abstracted hardware.


Best regards,
Christian

[PATCH v4 2/3] arm64: memset-arm64: Use simple memset when cache is disabled

[Stefan Roese]

The optimized memset uses the dc opcode, which causes problems when the
cache is disabled. This patch adds a check if the cache is disabled and
uses a very simple memset implementation in this case. Otherwise the
optimized version is used.

Signed-off-by: Stefan Roese 

---

Changes in v4:
- Use macros instead of register names, following the optimized code
- Add zero size check

Changes in v2:
- New patch

 arch/arm/lib/memset-arm64.S | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/lib/memset-arm64.S b/arch/arm/lib/memset-arm64.S
index 710f6f582cad..ee9f9a96cfe6 100644
--- a/arch/arm/lib/memset-arm64.S
+++ b/arch/arm/lib/memset-arm64.S
@@ -11,6 +11,7 @@
  *
  */
 
+#include 
 #include "asmdefs.h"
 
 #define dstin  x0
@@ -25,6 +26,37 @@ ENTRY (memset)
PTR_ARG (0)
SIZE_ARG (2)
 
+   /*
+* The optimized memset uses the dc opcode, which causes problems
+* when the cache is disabled. Let's check if the cache is disabled
+* and use a very simple memset implementation in this case. Otherwise
+* jump to the optimized version.
+*/
+   switch_el x6, 3f, 2f, 1f
+3: mrs x6, sctlr_el3
+   b   0f
+2: mrs x6, sctlr_el2
+   b   0f
+1: mrs x6, sctlr_el1
+0:
+   tst x6, #CR_C
+   bne 9f
+
+   /*
+* A very "simple" memset implementation without the use of the
+* dc opcode. Can be run with caches disabled.
+*/
+   mov x3, #0x0
+   cmp count, x3   /* check for zero length */
+   beq 8f
+4: strbvalw, [dstin, x3]
+   add x3, x3, #0x1
+   cmp count, x3
+   bne 4b
+8: ret
+9:
+
+   /* Here the optimized memset version starts */
dup v0.16B, valw
add dstend, dstin, count
 
-- 
2.32.0

[PATCH v4 3/3] arm64: Kconfig: Enable usage of optimized memset/memcpy/memmove

[Stefan Roese]

This patch enables the use of the optimized memset(), memmove() &
memcpy() versions recently added on ARM64.

Signed-off-by: Stefan Roese 

---

(no changes since v3)

Changes in v3:
- Add memmove as well

 arch/arm/Kconfig  | 38 +--
 arch/arm/include/asm/string.h |  4 
 2 files changed, 36 insertions(+), 6 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index caa8a71c6cfd..9f74b5c352ad 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -457,7 +457,6 @@ config ARM_CORTEX_CPU_IS_UP
 config USE_ARCH_MEMCPY
bool "Use an assembly optimized implementation of memcpy"
default y
-   depends on !ARM64
help
  Enable the generation of an optimized version of memcpy.
  Such an implementation may be faster under some conditions
@@ -466,7 +465,7 @@ config USE_ARCH_MEMCPY
 config SPL_USE_ARCH_MEMCPY
bool "Use an assembly optimized implementation of memcpy for SPL"
default y if USE_ARCH_MEMCPY
-   depends on !ARM64 && SPL
+   depends on SPL
help
  Enable the generation of an optimized version of memcpy.
  Such an implementation may be faster under some conditions
@@ -475,16 +474,43 @@ config SPL_USE_ARCH_MEMCPY
 config TPL_USE_ARCH_MEMCPY
bool "Use an assembly optimized implementation of memcpy for TPL"
default y if USE_ARCH_MEMCPY
-   depends on !ARM64 && TPL
+   depends on TPL
help
  Enable the generation of an optimized version of memcpy.
  Such an implementation may be faster under some conditions
  but may increase the binary size.
 
+config USE_ARCH_MEMMOVE
+   bool "Use an assembly optimized implementation of memmove"
+   default y
+   depends on ARM64
+   help
+ Enable the generation of an optimized version of memmove.
+ Such an implementation may be faster under some conditions
+ but may increase the binary size.
+
+config SPL_USE_ARCH_MEMMOVE
+   bool "Use an assembly optimized implementation of memmove for SPL"
+   default y if USE_ARCH_MEMCPY
+   depends on SPL && ARM64
+   help
+ Enable the generation of an optimized version of memmove.
+ Such an implementation may be faster under some conditions
+ but may increase the binary size.
+
+config TPL_USE_ARCH_MEMMOVE
+   bool "Use an assembly optimized implementation of memmove for TPL"
+   default y if USE_ARCH_MEMCPY
+   depends on TPL && ARM64
+   depends on TPL
+   help
+ Enable the generation of an optimized version of memmove.
+ Such an implementation may be faster under some conditions
+ but may increase the binary size.
+
 config USE_ARCH_MEMSET
bool "Use an assembly optimized implementation of memset"
default y
-   depends on !ARM64
help
  Enable the generation of an optimized version of memset.
  Such an implementation may be faster under some conditions
@@ -493,7 +519,7 @@ config USE_ARCH_MEMSET
 config SPL_USE_ARCH_MEMSET
bool "Use an assembly optimized implementation of memset for SPL"
default y if USE_ARCH_MEMSET
-   depends on !ARM64 && SPL
+   depends on SPL
help
  Enable the generation of an optimized version of memset.
  Such an implementation may be faster under some conditions
@@ -502,7 +528,7 @@ config SPL_USE_ARCH_MEMSET
 config TPL_USE_ARCH_MEMSET
bool "Use an assembly optimized implementation of memset for TPL"
default y if USE_ARCH_MEMSET
-   depends on !ARM64 && TPL
+   depends on TPL
help
  Enable the generation of an optimized version of memset.
  Such an implementation may be faster under some conditions
diff --git a/arch/arm/include/asm/string.h b/arch/arm/include/asm/string.h
index 11eaa34fab8c..ead3f2c35643 100644
--- a/arch/arm/include/asm/string.h
+++ b/arch/arm/include/asm/string.h
@@ -19,7 +19,11 @@ extern char * strchr(const char * s, int c);
 #endif
 extern void * memcpy(void *, const void *, __kernel_size_t);
 
+#if CONFIG_IS_ENABLED(USE_ARCH_MEMMOVE)
+#define __HAVE_ARCH_MEMMOVE
+#else
 #undef __HAVE_ARCH_MEMMOVE
+#endif
 extern void * memmove(void *, const void *, __kernel_size_t);
 
 #undef __HAVE_ARCH_MEMCHR
-- 
2.32.0

[PATCH v4 0/3] arm64: Add optimized memset/memcpy/memove functions

[Stefan Roese]

On an NXP LX2160 based platform it has been noticed, that the currently
implemented memset/memcpy functions for aarch64 are suboptimal.
Especially the memset() for clearing the NXP MC firmware memory is very
expensive (time-wise).

This patchset now adds the optimized functions ported from this
repository:
https://github.com/ARM-software/optimized-routines

As the optimized memset function make use of the dc opcode, which needs
the caches to be enabled, an additional check is added and a simple
memset version is used in this case.

Please note that checkpatch.pl complains about some issue with this
imported file: arch/arm/lib/asmdefs.h
Since it's imported I did explicitly not make any changes here, to make
potential future sync'ing easer.

Here some numbers to see the speed improments:
Current original version:
-
memset() 32 Bytes, 16M times:
time: 0.446 seconds

memset() 16MiB, 256 times:
time: 1.076 seconds

memcpy() 512MiB:
time: 0.224 seconds

New optimized version:
--
memset() 32 Bytes, 16M times:
time: 0.287 seconds

memset() 16MiB, 256 times:
time: 0.292 seconds

memcpy() 512MiB:
time: 0.222 seconds

Summary:
The optimized memcpy is nearly identical to the original one. But the
optimized memset is much faster, for small and big sizes. Small sizes
factor ~1.6 and big sizes factor ~3.7.

Note: These measurements were done on the NXP LX2160ARDB board.

Thanks,
Stefan

Changes in v4:
- Use macros instead of register names, following the optimized code
- Add zero size check

Changes in v3:
- Add memmove alias, as this function also handles it optimized
- Add memmove as well

Changes in v2:
- Add file names and locations and git commit ID from imported files
  to the commit message
- New patch

Stefan Roese (3):
  arm64: arch/arm/lib: Add optimized memset/memcpy/memmove functions
  arm64: memset-arm64: Use simple memset when cache is disabled
  arm64: Kconfig: Enable usage of optimized memset/memcpy/memmove

 arch/arm/Kconfig  |  38 +-
 arch/arm/include/asm/string.h |   4 +
 arch/arm/lib/Makefile |   5 +
 arch/arm/lib/asmdefs.h|  98 ++
 arch/arm/lib/memcpy-arm64.S   | 242 ++
 arch/arm/lib/memset-arm64.S   | 148 +
 6 files changed, 529 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/lib/asmdefs.h
 create mode 100644 arch/arm/lib/memcpy-arm64.S
 create mode 100644 arch/arm/lib/memset-arm64.S

-- 
2.32.0

[PATCH v4 1/3] arm64: arch/arm/lib: Add optimized memset/memcpy/memmove functions

[Stefan Roese]

Ported from https://github.com/ARM-software/optimized-routines

These files are included from this repository, including the latest
git commit ID:
string/aarch64/memcpy.S: afd6244a1f8d
string/aarch64/memset.S: e823e3abf5f8
string/asmdefs.h: e823e3abf5f8

Note that memmove is also handled by the memcpy function.

Please note that when adding these optimized functions as default memset
memcpy functions in U-Boot, U-Boot fails to boot on the LX2160ARDB.
After the initial ATF output, no U-Boot output is shown on the serial
console. Some exception is triggered here in the very early boot process
as some of the assembler opcodes need the caches to be enabled.

Because of this, a follow-up patch will add a check to use a simple
non-optimized memset for the "cache disabled" case.

Note:
I also integrated and tested with the Linux versions of these optimized
functions. They are similar to the ones now integrated but these ARM
versions are still a small bit faster.

Signed-off-by: Stefan Roese 

---

(no changes since v3)

Changes in v3:
- Add memmove alias, as this function also handles it optimized

Changes in v2:
- Add file names and locations and git commit ID from imported files
  to the commit message

 arch/arm/lib/Makefile   |   5 +
 arch/arm/lib/asmdefs.h  |  98 +++
 arch/arm/lib/memcpy-arm64.S | 242 
 arch/arm/lib/memset-arm64.S | 116 +
 4 files changed, 461 insertions(+)
 create mode 100644 arch/arm/lib/asmdefs.h
 create mode 100644 arch/arm/lib/memcpy-arm64.S
 create mode 100644 arch/arm/lib/memset-arm64.S

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 7f6633271518..c48e1f622d3c 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -39,8 +39,13 @@ obj-$(CONFIG_$(SPL_TPL_)FRAMEWORK) += spl.o
 obj-$(CONFIG_SPL_FRAMEWORK) += zimage.o
 obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o
 endif
+ifdef CONFIG_ARM64
+obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMSET) += memset-arm64.o
+obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMCPY) += memcpy-arm64.o
+else
 obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMSET) += memset.o
 obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMCPY) += memcpy.o
+endif
 obj-$(CONFIG_SEMIHOSTING) += semihosting.o
 
 obj-y  += bdinfo.o
diff --git a/arch/arm/lib/asmdefs.h b/arch/arm/lib/asmdefs.h
new file mode 100644
index ..d307a3a8a25c
--- /dev/null
+++ b/arch/arm/lib/asmdefs.h
@@ -0,0 +1,98 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Macros for asm code.
+ *
+ * Copyright (c) 2019, Arm Limited.
+ */
+
+#ifndef _ASMDEFS_H
+#define _ASMDEFS_H
+
+#if defined(__aarch64__)
+
+/* Branch Target Identitication support.  */
+#define BTI_C  hint34
+#define BTI_J  hint36
+/* Return address signing support (pac-ret).  */
+#define PACIASPhint25; .cfi_window_save
+#define AUTIASPhint29; .cfi_window_save
+
+/* GNU_PROPERTY_AARCH64_* macros from elf.h.  */
+#define FEATURE_1_AND 0xc000
+#define FEATURE_1_BTI 1
+#define FEATURE_1_PAC 2
+
+/* Add a NT_GNU_PROPERTY_TYPE_0 note.  */
+#define GNU_PROPERTY(type, value)  \
+  .section .note.gnu.property, "a";\
+  .p2align 3;  \
+  .word 4; \
+  .word 16;\
+  .word 5; \
+  .asciz "GNU";\
+  .word type;  \
+  .word 4; \
+  .word value; \
+  .word 0; \
+  .text
+
+/* If set then the GNU Property Note section will be added to
+   mark objects to support BTI and PAC-RET.  */
+#ifndef WANT_GNU_PROPERTY
+#define WANT_GNU_PROPERTY 1
+#endif
+
+#if WANT_GNU_PROPERTY
+/* Add property note with supported features to all asm files.  */
+GNU_PROPERTY (FEATURE_1_AND, FEATURE_1_BTI|FEATURE_1_PAC)
+#endif
+
+#define ENTRY_ALIGN(name, alignment)   \
+  .global name;\
+  .type name,%function;\
+  .align alignment;\
+  name:\
+  .cfi_startproc;  \
+  BTI_C;
+
+#else
+
+#define END_FILE
+
+#define ENTRY_ALIGN(name, alignment)   \
+  .global name;\
+  .type name,%function;\
+  .align alignment;\
+  name:\
+  .cfi_startproc;
+
+#endif
+
+#define ENTRY(name)ENTRY_ALIGN(name, 6)
+
+#define ENTRY_ALIAS(name)  \
+  .global name;\
+  .type name,%function;\
+  name:
+
+#define END(name)  \
+  .cfi_endproc;\
+  .size name, .-name;
+
+#define L(l) .L ## l
+
+#ifdef __ILP32__
+  /* Sanitize padding bits of pointer arguments as per aapcs64 */
+#define PTR_ARG(n)  mov w##n, w##n
+#else
+#define PTR_ARG(n)
+#endif
+
+#ifdef __ILP32__
+  /* Sanitize padding bits of size arguments as per aapcs64 */
+#define SIZE_ARG(n)  mov w##n, w##n
+#else
+#define SIZE_ARG(n)
+#endif
+
+#endif
diff --git a/arch/arm/lib/memcpy-arm64.S b/arch/arm/lib/memcpy-arm6

Re: [PATCH] env: Make _init() expect _INVALID when _IS_NOWHERE

[Marek Vasut]

On 8/12/21 5:28 PM, Pierre-Clément Tosi wrote:

Avoid applying the "fix" introduced by commit 5557eec01cbf ("env: Fix
invalid env handling in env_init()") to the environment "nowhere".

This is necessary as that commit, by setting the return value of
env_init() to -ENOENT if gd->env_valid is ENV_INVALID, forces that
function to reset gd->env_valid to ENV_VALID. By doing so, it breaks the
assumption (required by ENV_IS_NOWHERE) that gd->env_valid must be
ENV_INVALID.

This, in turn, results in env_relocate() calling env_load() (it should
not), which itself, calls U_BOOT_ENV_LOCATION(nowhere).load() i.e.
env_nowhere_load(). That function, being implemented under the
assumption mentioned above, calls env_set_default(), which in turn,
seeing that gd->env_valid is ENV_VALID (it should not), tries to
dereference whatever lies in gd->env_addr (most likely garbage), leading
to a faulty memory access.

Note that other env_locations might be concerned by this bug but that
this commit only intends to fix it for when ENV_IS_NOWHERE.

Fixes: 5557eec01cbf ("env: Fix invalid env handling in env_init()")
Signed-off-by: Pierre-Clément Tosi 


Such patch was already posted, see the patch and the discussion, in the 
end there was a different fix for the relocation code:


https://patchwork.ozlabs.org/project/uboot/patch/1620828554-24013-1-git-send-email-hayashi.kunih...@socionext.com/

Re: [PATCH] cmd: boot: Update reset usage message

[Igor Opaniuk]

Hi Michal,

On Wed, Aug 11, 2021 at 1:04 PM Michal Simek  wrote:
>
> The commit 573a3811edc8 ("sysreset: psci: support system reset in a generic
> way with PSCI") has added support for warm reset via PSCI but this hasn't
> been reflected in usage message and user has to look at the code how to run
> it. That's why update usage text to make this clear.
>
> Here is full help with updated usage:
> ZynqMP> help reset
> reset - Perform RESET of the CPU
>
> Usage:
> reset - cold boot without level specifier
> reset -w - warm reset if implemented
>
> Signed-off-by: Michal Simek 
> ---
>
>  cmd/boot.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/cmd/boot.c b/cmd/boot.c
> index fab294e622be..be67a5980de3 100644
> --- a/cmd/boot.c
> +++ b/cmd/boot.c
> @@ -58,7 +58,8 @@ U_BOOT_CMD(
>  U_BOOT_CMD(
> reset, 2, 0,do_reset,
> "Perform RESET of the CPU",
> -   ""
> +   "- cold boot without level specifier\n"
> +   "reset -w - warm reset if implemented"
>  );
>
>  #ifdef CONFIG_CMD_POWEROFF
> --
> 2.32.0
>

Reviewed-by: Igor Opaniuk 

-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk
Embedded Software Engineer
T:  +380 938364067
E: igor.opan...@foundries.io
W: www.foundries.io

Re: [PATCH v4 07/10] watchdog: wdt-uclass.c: handle all DM watchdogs in watchdog_reset()

[Tom Rini]

On Thu, Aug 12, 2021 at 04:21:29PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20210812134833.GU858@bill-the-cat> you wrote:
> > 
> > Alright, lets take a look at what kind of area of the code we're talking
> > about.  uclass_get is a pretty fundamental thing.  If that fails, your
> > system is on fire.  Things are massively corrupt.
> 
> Full agreement here.
> 
> > So yes, return codes need to be checked and passed.  But no, not every
> > single error path needs to print to the user along every part of an
> > error path either.
> 
> So if "the system is on fire" is one of the cases where an error
> message should be omitted to save maybe 50 or 100 bytes of image
> size?  This sounds wrong to me.

It sounds right to me because it's unlikely everything caught fire
because of this call right here and likely it's because of one of the
messages much further up on the console log.  Hopefully we haven't
caused that message to be unavailable now due to unhelpful failure
messages.

A log message needs to have value to it above and beyond boiling down to
"%s: %d", __func__, __LINE__ having been reached.  This, right here, is
not a log message that matters.  With DM we've made a great deal of
progress in being able to populate meaningful errors back up to our
callers rather than -1 for everything.  So yes, in sum, these functions
need to return a value.  The BSP ought to care (in the next patch), even
if it doesn't today when it could.  But that's on the BSP author as they
know better than you or I what that system is being used for.

-- 
Tom


signature.asc
Description: PGP signature

U-Boot sunxi DM_I2C migration?

[Tom Rini]

Hey,

As I try and migrate more CONFIG symbols to be Kconfig only, I see that
sunxi is still using the legacy I2C drivers.  Is there something
specific holding up migration?  Thanks!

-- 
Tom


signature.asc
Description: PGP signature

[PATCH 1/1] riscv: show code leading to exception

[Heinrich Schuchardt]

To make analyzing exceptions easier output the code that leads to it.
We already do the same on the ARM platform.

Here is an example:

=> exception ebreak
Unhandled exception: Breakpoint
EPC: 8ff5d50e RA: 8ff5d62c TVAL: 
EPC: 8020b50e RA: 8020b62c reloc adjusted

Code: 2785 0693 07a0 dce3 fef6 47a5 d563 00e7 (9002)

To disassemble the code we can use the decodecode script:

$ echo 'Code: 2785 0693 07a0 dce3 fef6 47a5 d563 00e7 (9002)' | \
  CROSS_COMPILE=riscv64-linux-gnu- scripts/decodecode

Code: 2785 0693 07a0 dce3 fef6 47a5 d563 00e7 (9002)
All code

   0:   2785addiw   a5,a5,1
   2:   07a00693li  a3,122
   6:   fef6dce3bge a3,a5,0xfffe
   a:   47a5li  a5,9
   c:   00e7d563bge a5,a4,0x16
  10:*  9002ebreak <-- trapping instruction
...

Code starting with the faulting instruction
===
   0:   9002ebreak
...

As it is not always clear if the first 16 bits are at the start or in the
middle of a 32bit instruction it may become necessary to strip the first
u16 from the output before calling decodecode to get the correct
disassembled code.

Signed-off-by: Heinrich Schuchardt 
---
 arch/riscv/lib/interrupts.c | 42 +
 1 file changed, 42 insertions(+)

diff --git a/arch/riscv/lib/interrupts.c b/arch/riscv/lib/interrupts.c
index 7525c152b8..31b8a6603c 100644
--- a/arch/riscv/lib/interrupts.c
+++ b/arch/riscv/lib/interrupts.c
@@ -51,6 +51,47 @@ static void show_regs(struct pt_regs *regs)
 #endif
 }

+/**
+ * instr_len() - get instruction length
+ *
+ * @i: low 16 bits of the instruction
+ * Return: number of u16 in instruction
+ */
+static int instr_len(u16 i)
+{
+   if ((i & 0x03) != 0x03)
+   return 1;
+   if ((i & 0x1c) != 0x1c)
+   return 2;
+   if ((i & 0x3f) == 0x1f)
+   return 3;
+   if ((i & 0x7f) == 0x3f)
+   return 4;
+   i = (i >> 12) & 0x07;
+   if (i < 7)
+   return i + 5;
+   /* Encoding for >= 192 bits is not yet defined */
+   return 1;
+}
+
+/**
+ * show_code() - display code leading to exception
+ *
+ * @epc:   program counter
+ */
+static void show_code(ulong epc)
+{
+   u16 *pos = (u16 *)(epc & ~1UL);
+   int i, len = instr_len(*pos);
+
+   printf("\nCode: ");
+   for (i = -8; i; ++i)
+   printf("%04x ", pos[i]);
+   printf("(");
+   for (i = 0; i < len; ++i)
+   printf("%04x%s", pos[i], i + 1 == len ? ")\n" : " ");
+}
+
 static void _exit_trap(ulong code, ulong epc, ulong tval, struct pt_regs *regs)
 {
static const char * const exception_code[] = {
@@ -85,6 +126,7 @@ static void _exit_trap(ulong code, ulong epc, ulong tval, 
struct pt_regs *regs)
   epc - gd->reloc_off, regs->ra - gd->reloc_off);

show_regs(regs);
+   show_code(epc);
show_efi_loaded_images(epc);
panic("\n");
 }
--
2.30.2

Re: [PATCH v2 3/6] riscv: lib: introduce cache_init interface

[Sean Anderson]

On 8/10/21 2:57 AM, Zong Li wrote:

On Tue, Aug 10, 2021 at 12:47 PM Sean Anderson  wrote:


On 8/3/21 12:44 AM, Zong Li wrote:

Add an interface for cache initialization. Each platform can overwrite
this weak function by their own implementation, such as sifive_cache in
this patch.


Can we call this enable_caches instead of cache_init? This function is
called by initr_caches in board_r.c for ARM. There's even an
eight-year-old TODO on the subject.



I had considered use it, The reason I finally used cache_init here is
that it seems to me that cache_init would be more flexible for risc-v
platforms to do not only cache enable, but also various
platform-specific initialization of cache, even they could decide the
time to invoke cache_init if there is particular initialization
sequence.


Do you have some example in mind?


If you think that cache_init is OK to you, I would prefer to
retain cache_init. I can still use enable_caches instead of cache_init
if you think that it is a better way. Please let me know your thoughts
and thanks for your review.


I would like to reduce the proliferation of different cache enable
functions. Right now we have (i|d)cache_enable which are RISC-V-specific
and called very early during boot; cache_enable, which must be called
manually; enable_caches, which is implemented only for ARM; and your
proposed cache_init. I don't think there is need for yet another way to
accomplish the same thing.

--Sean



Signed-off-by: Zong Li 
---
   arch/riscv/Kconfig |  5 +
   arch/riscv/include/asm/cache.h |  1 +
   arch/riscv/lib/Makefile|  1 +
   arch/riscv/lib/cache.c |  5 +
   arch/riscv/lib/sifive_cache.c  | 27 +++
   5 files changed, 39 insertions(+)
   create mode 100644 arch/riscv/lib/sifive_cache.c

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 4b0c3dffa6..ec651fe0a4 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -179,6 +179,11 @@ config SPL_SIFIVE_CLINT
 The SiFive CLINT block holds memory-mapped control and status registers
 associated with software and timer interrupts.

+config SIFIVE_CACHE
+ bool
+ help
+   This enables the operations to configure SiFive cache
+
   config ANDES_PLIC
   bool
   depends on RISCV_MMODE || SPL_RISCV_MMODE
diff --git a/arch/riscv/include/asm/cache.h b/arch/riscv/include/asm/cache.h
index ec8fe201d3..6ebb2b4329 100644
--- a/arch/riscv/include/asm/cache.h
+++ b/arch/riscv/include/asm/cache.h
@@ -9,6 +9,7 @@

   /* cache */
   voidcache_flush(void);
+int cache_init(void);

   /*
* The current upper bound for RISCV L1 data cache line sizes is 32 bytes.
diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index c4cc41434b..06020fcc2a 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_CMD_BOOTM) += bootm.o
   obj-$(CONFIG_CMD_BOOTI) += bootm.o image.o
   obj-$(CONFIG_CMD_GO) += boot.o
   obj-y   += cache.o
+obj-$(CONFIG_SIFIVE_CACHE) += sifive_cache.o
   ifeq ($(CONFIG_$(SPL_)RISCV_MMODE),y)
   obj-$(CONFIG_$(SPL_)SIFIVE_CLINT) += sifive_clint.o
   obj-$(CONFIG_ANDES_PLIC) += andes_plic.o
diff --git a/arch/riscv/lib/cache.c b/arch/riscv/lib/cache.c
index b1d42bcc2b..2cd66504c6 100644
--- a/arch/riscv/lib/cache.c
+++ b/arch/riscv/lib/cache.c
@@ -70,3 +70,8 @@ __weak int dcache_status(void)
   {
   return 0;
   }
+
+__weak int cache_init(void)
+{
+ return 0;
+}
diff --git a/arch/riscv/lib/sifive_cache.c b/arch/riscv/lib/sifive_cache.c
new file mode 100644
index 00..94e84e024e
--- /dev/null
+++ b/arch/riscv/lib/sifive_cache.c
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2021 SiFive, Inc
+ */
+
+#include 
+#include 
+#include 
+
+int cache_init(void)
+{
+ struct udevice *dev;
+ int ret;
+
+ /* Enable ways of ccache */
+ ret = uclass_get_device_by_driver(UCLASS_CACHE,
+   DM_DRIVER_GET(sifive_ccache),
+   &dev);
+ if (ret)
+ return log_msg_ret("Cannot enable cache ways", ret);
+
+ ret = cache_enable(dev);
+ if (ret)
+ return log_msg_ret("ccache enable failed", ret);
+
+ return 0;
+}



Otherwise LGTM

Re: [PATCH v2 5/6] riscv: lib: move platform-related libraries to sperate folder

[Sean Anderson]

On 8/10/21 3:04 AM, Zong Li wrote:

On Tue, Aug 10, 2021 at 12:55 PM Sean Anderson  wrote:



Re: [PATCH v2 5/6] riscv: lib: move platform-related libraries to sperate folder


nit: separate



Thanks for catching it. Fix it in the next version.


On 8/3/21 12:44 AM, Zong Li wrote:

Put the platform-related implementation into their own folder
respectively. Just leave the common library in the top of lib
folder.

Signed-off-by: Zong Li 
---
   arch/riscv/Kconfig  | 7 +++
   arch/riscv/lib/Makefile | 9 -
   arch/riscv/lib/andestech/Kconfig| 8 
   arch/riscv/lib/andestech/Makefile   | 7 +++
   arch/riscv/lib/{ => andestech}/andes_plic.c | 0
   arch/riscv/lib/sifive/Kconfig   | 8 
   arch/riscv/lib/sifive/Makefile  | 9 +
   arch/riscv/lib/{ => sifive}/sifive_cache.c  | 0
   arch/riscv/lib/{ => sifive}/sifive_clint.c  | 0
   9 files changed, 43 insertions(+), 5 deletions(-)
   create mode 100644 arch/riscv/lib/andestech/Kconfig
   create mode 100644 arch/riscv/lib/andestech/Makefile
   rename arch/riscv/lib/{ => andestech}/andes_plic.c (100%)
   create mode 100644 arch/riscv/lib/sifive/Kconfig
   create mode 100644 arch/riscv/lib/sifive/Makefile
   rename arch/riscv/lib/{ => sifive}/sifive_cache.c (100%)
   rename arch/riscv/lib/{ => sifive}/sifive_clint.c (100%)


NAK from me. I'd much rather see organization by function (e.g.
clint/sbi/plic together) than by vendor. Plus, the clint/plic are not
really specific to one vendor like ccache.



Yes, it makes more sense to me. In this case, there are three
functionalities, so I'd like to separate clint, plic and cache at this
time, does it make sense to you?


No, it does not. clint and plic should be grouped with SBI because in
U-Boot they are all used for IPIs. But frankly, I don't really see the
need to place them in subdirectories yet...

--Sean




--Sean


diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index ec651fe0a4..ed1bf2f6c8 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -72,6 +72,10 @@ source "arch/riscv/cpu/fu540/Kconfig"
   source "arch/riscv/cpu/fu740/Kconfig"
   source "arch/riscv/cpu/generic/Kconfig"

+# library-specific options below
+source "arch/riscv/lib/sifive/Kconfig"
+source "arch/riscv/lib/andestech/Kconfig"
+
   # architecture-specific options below

   choice
@@ -175,18 +179,21 @@ config SIFIVE_CLINT
   config SPL_SIFIVE_CLINT
   bool
   depends on SPL_RISCV_MMODE
+ select SIFIVE_LIB
   help
 The SiFive CLINT block holds memory-mapped control and status registers
 associated with software and timer interrupts.

   config SIFIVE_CACHE
   bool
+ select SIFIVE_LIB
   help
 This enables the operations to configure SiFive cache

   config ANDES_PLIC
   bool
   depends on RISCV_MMODE || SPL_RISCV_MMODE
+ select ANDESTECH_LIB
   select REGMAP
   select SYSCON
   select SPL_REGMAP if SPL
diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index 06020fcc2a..f58d1f9819 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -10,11 +10,7 @@ obj-$(CONFIG_CMD_BOOTM) += bootm.o
   obj-$(CONFIG_CMD_BOOTI) += bootm.o image.o
   obj-$(CONFIG_CMD_GO) += boot.o
   obj-y   += cache.o
-obj-$(CONFIG_SIFIVE_CACHE) += sifive_cache.o
-ifeq ($(CONFIG_$(SPL_)RISCV_MMODE),y)
-obj-$(CONFIG_$(SPL_)SIFIVE_CLINT) += sifive_clint.o
-obj-$(CONFIG_ANDES_PLIC) += andes_plic.o
-else
+ifeq ($(CONFIG_$(SPL_)RISCV_MMODE),)
   obj-$(CONFIG_SBI) += sbi.o
   obj-$(CONFIG_SBI_IPI) += sbi_ipi.o
   endif
@@ -42,3 +38,6 @@ extra-$(CONFIG_EFI) += $(EFI_CRT0) $(EFI_RELOC)
   obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMSET) += memset.o
   obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMMOVE) += memmove.o
   obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMCPY) += memcpy.o
+
+obj-$(CONFIG_SIFIVE_LIB) += sifive/
+obj-$(CONFIG_ANDESTECH_LIB) += andestech/
diff --git a/arch/riscv/lib/andestech/Kconfig b/arch/riscv/lib/andestech/Kconfig
new file mode 100644
index 00..75f83a8123
--- /dev/null
+++ b/arch/riscv/lib/andestech/Kconfig
@@ -0,0 +1,8 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2021 SiFive, Inc
+
+config ANDESTECH_LIB
+ bool
+ help
+   This supports the specific libraries for AndesTech platforms
diff --git a/arch/riscv/lib/andestech/Makefile 
b/arch/riscv/lib/andestech/Makefile
new file mode 100644
index 00..49f45d0a29
--- /dev/null
+++ b/arch/riscv/lib/andestech/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2021 SiFive, Inc
+
+ifeq ($(CONFIG_$(SPL_)RISCV_MMODE),y)
+obj-$(CONFIG_ANDES_PLIC) += andes_plic.o
+endif
diff --git a/arch/riscv/lib/andes_plic.c b/arch/riscv/lib/andestech/andes_plic.c
similarity index 100%
rename from arch/riscv/lib/andes_plic.c
rename to arch/riscv/lib/andestech/andes_plic.c
diff --git a/arch/riscv/lib/sifive/Kconfig b/arch/riscv/lib/sifive/Kconfig
new file mode 

Re: U-Boot sunxi DM_I2C migration?

[Andre Przywara]

On Thu, 12 Aug 2021 13:49:30 -0400
Tom Rini  wrote:

Hi Tom,

> As I try and migrate more CONFIG symbols to be Kconfig only, I see that
> sunxi is still using the legacy I2C drivers.  Is there something
> specific holding up migration?  Thanks!

Do you mean a DM_I2C conversion, or just moving those base address
symbols to Kconfig? The latter is rather easy, let me know if I should
give it a shot.

For DM_I2C, it's the usual sunxi issue: we are using both: DM_I2C and
DT based probing for U-Boot proper, and hardcoded CONFIG_ symbols for
the SPL. *Some* boards need the set up the PMIC early (for increasing
the CPU frequency or setting the proper DRAM voltage), so this needs to
be done in the SPL. I don't know how to fix this "properly",
but introducing DM (and DT) into the SPL is surely not worth the
trouble. Alternatively we could have a separate, cut-down SPL-only
driver, like we have for SPI (arch/arm/mach-sunxi/spl_spi_sunxi.c),
but not sure that's really better.

If there is something in particular that annoys you about the
situation, we could try to improve this particular issue instead?
Moving the non-DM code into a separate file, maybe?

Cheers,
Andre

[PATCH] arm: kirkwood: Sheevaplug: Update board maintainer

[Tony Dinh]

Change maintainer to me. Prafulla is no longer active in U-Boot community.

Signed-off-by: Tony Dinh 
---

 board/Marvell/sheevaplug/MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/Marvell/sheevaplug/MAINTAINERS 
b/board/Marvell/sheevaplug/MAINTAINERS
index 2b0103d07d..282f046667 100644
--- a/board/Marvell/sheevaplug/MAINTAINERS
+++ b/board/Marvell/sheevaplug/MAINTAINERS
@@ -1,5 +1,5 @@
 SHEEVAPLUG BOARD
-M: Prafulla Wadaskar 
+M: Tony Dinh 
 S: Maintained
 F: board/Marvell/sheevaplug/
 F: include/configs/sheevaplug.h
-- 
2.20.1

Re: U-Boot sunxi DM_I2C migration?

[Tom Rini]

On Thu, Aug 12, 2021 at 10:22:07PM +0100, Andre Przywara wrote:
> On Thu, 12 Aug 2021 13:49:30 -0400
> Tom Rini  wrote:
> 
> Hi Tom,
> 
> > As I try and migrate more CONFIG symbols to be Kconfig only, I see that
> > sunxi is still using the legacy I2C drivers.  Is there something
> > specific holding up migration?  Thanks!
> 
> Do you mean a DM_I2C conversion, or just moving those base address
> symbols to Kconfig? The latter is rather easy, let me know if I should
> give it a shot.
> 
> For DM_I2C, it's the usual sunxi issue: we are using both: DM_I2C and
> DT based probing for U-Boot proper, and hardcoded CONFIG_ symbols for
> the SPL. *Some* boards need the set up the PMIC early (for increasing
> the CPU frequency or setting the proper DRAM voltage), so this needs to
> be done in the SPL. I don't know how to fix this "properly",
> but introducing DM (and DT) into the SPL is surely not worth the
> trouble. Alternatively we could have a separate, cut-down SPL-only
> driver, like we have for SPI (arch/arm/mach-sunxi/spl_spi_sunxi.c),
> but not sure that's really better.
> 
> If there is something in particular that annoys you about the
> situation, we could try to improve this particular issue instead?
> Moving the non-DM code into a separate file, maybe?

I'm working on the symbols now (since it gets tricky).  The first
example I pulled out was Hummingbird_A31 which does have legacy I2C and
does not set DM_I2C, which is what set me down the more worrying path.
If you can confirm that no, really, it's just SPL that's not using
DM_I2C that's OK enough for now, we can sort out what the best but
probably still unideal solution is long term for SPL.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/2] x86: crownbay: Enable SeaBIOS support

[Simon Glass]

On Tue, 3 Aug 2021 at 06:50, Bin Meng  wrote:
>
> Enable SeaBIOS support for any kernel that requires legacy BIOS
> services.
>
> Signed-off-by: Bin Meng 
> ---
>
>  configs/crownbay_defconfig | 1 +
>  1 file changed, 1 insertion(+)
>

Reviewed-by: Simon Glass 

Re: [PATCH 2/7] xyz-modem: Fix x-modem "xyzModem_eof error" at the end of file

[Simon Glass]

On Tue, 3 Aug 2021 at 08:29, Pali Rohár  wrote:
>
> In x-modem protocol EOF is not an error state at the end of file.
>
> Signed-off-by: Pali Rohár 
> ---
>  common/xyzModem.c | 2 ++
>  1 file changed, 2 insertions(+)

Reviewed-by: Simon Glass 

Re: [PATCH 5/7] xyz-modem: Properly abort/terminate transfer on error

[Simon Glass]

Hi Pali,

On Tue, 3 Aug 2021 at 08:29, Pali Rohár  wrote:
>
> Transfer termination tries to instruct sender that transfer was terminated.
>
> Print error message and indicates aborted transfer in return value.
>
> Signed-off-by: Pali Rohár 
> ---
>  cmd/load.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass 

>
> diff --git a/cmd/load.c b/cmd/load.c
> index fb8c191fb64f..1ed05a9cd21e 100644
> --- a/cmd/load.c
> +++ b/cmd/load.c
> @@ -975,6 +975,7 @@ static ulong load_serial_ymodem(ulong offset, int mode)
> res = xyzModem_stream_open(&info, &err);
> if (!res) {
>
> +   err = 0;
> while ((res =
> xyzModem_stream_read(ymodemBuf, 1024, &err)) > 0) {
> store_addr = addr + offset;
> @@ -987,6 +988,9 @@ static ulong load_serial_ymodem(ulong offset, int mode)
> rc = flash_write((char *) ymodemBuf,
>   store_addr, res);
> if (rc != 0) {
> +   xyzModem_stream_terminate(true, 
> &getcxmodem);
> +   xyzModem_stream_close(&err);
> +   printf("\n");
> flash_perror(rc);
> return (~0);
> }
> @@ -998,12 +1002,20 @@ static ulong load_serial_ymodem(ulong offset, int mode)
> }
>
> }
> +   if (err) {
> +   xyzModem_stream_terminate((err == xyzModem_cancel) ? 
> false : true, &getcxmodem);
> +   xyzModem_stream_close(&err);
> +   printf("\n%s\n", xyzModem_error(err));
> +   return (~0); /* Download aborted */
> +   }
> +
> if (IS_ENABLED(CONFIG_CMD_BOOTEFI))
> efi_set_bootdev("Uart", "", "",
> map_sysmem(offset, 0), size);
>
> } else {
> -   printf("%s\n", xyzModem_error(err));
> +   printf("\n%s\n", xyzModem_error(err));
> +   return (~0); /* Download aborted */

Should not have brackets around return value.

> }
>
> xyzModem_stream_terminate(false, &getcxmodem);
> --
> 2.20.1
>

Regards,
Simon

Re: [PATCH 2/2] doc: x86: Update SeaBIOS build instructions

[Simon Glass]

On Tue, 3 Aug 2021 at 06:50, Bin Meng  wrote:
>
> Update SeaBIOS build instructions using exact command that involves
> "make olddefconfig", and mention SeaBIOS release 1.14.0 has been
> used for testing.
>
> Signed-off-by: Bin Meng 
> ---
>
>  doc/arch/x86.rst | 21 -
>  1 file changed, 8 insertions(+), 13 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH 7/7] xyz-modem: Allow to cancel transfer also by CTRL+C

[Simon Glass]

On Tue, 3 Aug 2021 at 08:29, Pali Rohár  wrote:
>
> Currently it is possible to cancel loadx and loady commands by pressing
> CTRL+X (CAN character) at least 3 times quickly.
>
> All other U-Boot commands, including loadb and loads can be cancelled by
> CTRL+C. So allow it also in xyz-modem code used by loadx and loady
> commands. Implement it by handling CTRL+C (ETX character) in the same way
> as CTRL+X (CAN character).
>
> Due to how x/y-modem protocol works, it is required to press
> CTRL+C or CTRL+X at least 3 times quickly.
>
> Signed-off-by: Pali Rohár 
> ---
>  common/xyzModem.c | 2 ++
>  1 file changed, 2 insertions(+)

Reviewed-by: Simon Glass 

Re: [PATCH] x86: crownbay: Enable CONFIG_SPI_FLASH_SMART_HWCAPS

[Simon Glass]

On Tue, 3 Aug 2021 at 21:53, Bin Meng  wrote:
>
> Now that the spi-nor fix has been made in u-boot/master via:
>
>   commit 87e7219f9c6a ("mtd: spi-nor: Respect flash's hwcaps in 
> spi_nor_adjust_hwcaps()")
>
> enable CONFIG_SPI_FLASH_SMART_HWCAPS on Intel Crown Bay again.
>
> Signed-off-by: Bin Meng 
> ---
>
>  configs/crownbay_defconfig | 1 -
>  1 file changed, 1 deletion(-)

Reviewed-by: Simon Glass 

Re: [PATCH] cmd: pwm: Remove additional pwm description

[Simon Glass]

On Tue, 10 Aug 2021 at 07:50, Michal Simek  wrote:
>
> The first name is taken from command name that's why shouldn't be listed in
> help. And commands shouldn't be listed with <> which means value but value
> itself is command name.
> Also add description for commands to make it clear what it does.
>
> Before
> pwm pwm
> pwm 
> ...
>
> After:
> pwm invert- invert polarity
> pwm config - config PWM
> pwm enable   - enable PWM output
> pwm disable   - disable PWM output
>
> Signed-off-by: Michal Simek 
> ---
>
>  cmd/pwm.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>

Reviewed-by: Simon Glass 

Re: [PATCH] fdt_support: Add kernel-doc for fdt_fixup_memory_banks()

[Simon Glass]

On Tue, 10 Aug 2021 at 01:30, Michal Simek  wrote:
>
> Add kernel-doc description for fdt_fixup_memory_banks() because it is
> implemented in one specific way and this information should be available
> for others to decide if their SoC conforms to it.
> If you don't want U-Boot to update your memory DT layout please disable
> CONFIG_ARCH_FIXUP_FDT_MEMORY.
>
> Signed-off-by: Michal Simek 
> ---
>
>  common/fdt_support.c | 18 ++
>  1 file changed, 18 insertions(+)

Reviewed-by: Simon Glass 

Re: Proposal: U-Boot MTD (rewriting old story)

[Simon Glass]

Hi,

On Thu, 5 Aug 2021 at 19:07, Bin Meng  wrote:
>
> On Fri, Aug 6, 2021 at 3:40 AM Tom Rini  wrote:
> >
> > On Thu, Aug 05, 2021 at 01:20:51PM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Wed, 4 Aug 2021 at 12:49, Tom Rini  wrote:
> > > >
> > > > On Wed, Aug 04, 2021 at 10:09:55AM -0600, Simon Glass wrote:
> > > > > Hi Jagan,
> > > > >
> > > > > On Tue, 3 Aug 2021 at 09:01, Jagan Teki  
> > > > > wrote:
> > > > > >
> > > > > > Yes, this is the old discussion and triggered again now since we 
> > > > > > had a
> > > > > > discussion on the last U-Boot contributor call.
> > > > > >
> > > > > > I will brief the main points here, as most of the details are
> > > > > > mentioned in previous threads.
> > > > > >
> > > > > > Here are the couple of old and new implementations on the SPI-NOR 
> > > > > > side.
> > > > > >
> > > > > > http://u-boot.10912.n7.nabble.com/PATCH-v10-00-27-dm-Generic-MTD-Subsystem-with-SPI-NOR-interface-tt315694.html#none
> > > > > > http://u-boot.10912.n7.nabble.com/PATCH-0-5-mtd-Implement-MTD-UCLASS-use-SPINOR-td419538.html#a419541
> > > > > > https://patchwork.ozlabs.org/project/uboot/cover/20200709111709.68904-1-ja...@amarulasolutions.com/
> > > > > >
> > > > > > Idea is to
> > > > > > 1. Create MTD_UCLASS, already present
> > > > > > 2. Create DM MTD Operations, above patchset does.
> > > > > > 3. Create Flash specific MTD UClass's like
> > > > > > UCLASS_NAND
> > > > > > UCLASS_SPI_NAND
> > > > > > UCLASS_SPI_NOR
> > > > > > UCLASS_NOR
> > > > > > UCLASS_UBI
> > > > > > and register to UCLASS_MTD as interface slaves like how MMC, SCSI 
> > > > > > are
> > > > > > registered to UCLASS_BLK
> > > > > > 4. Sync only respective flash specific code, and drop __UBOOT__
> > > > > > 5. Interface mtd, sf, and nand commands to UCLASS_MTD.
> > > > >
> > > > > This all seems good to me.
> > > > >
> > > > > >
> > > > > > Hard points:
> > > > > > 1. Hard to arrange Linux specific code and drop unneeded _UBOOT_ 
> > > > > > code,
> > > > > > but possible.
> > > > > > 2. Requires a lot of testing.
> > > > >
> > > > > Let's add simple emulators for NAND, SPI_NAND and UBI. We already have
> > > > > one for SPI_NOR I believe. That will be a good long-term investment.
> > > >
> > > > What are our viable options here via QEMU?
> > >
> > > I don't mean QEMU, just sandbox emulators. They are pretty simple to
> > > write and faster/easier to run and debug than qemu.
> >
> > If something exists in QEMU today, there's nothing to write.  There are
> > many things sandbox is good for, and that I wish we made more use of (it
> > would be amazing if allyesconfig was viable for sandbox so everything
> > outside of arch/ could be static analyzed for example).  But when it
> > comes to driver testing, I really want to know what we can do with QEMU
> > first.
>
> Agree, I believe we can do something on QEMU ARM/RISC-V virt (NOR) and
> RISC-V sifive_u (spi-nor).

Actually I think people are missing the point with sandbox emulators.
They are not the same thing as qemu.

Emulators have these advantages that I can think of:

- very little code - see for example
https://github.com/u-boot/u-boot/blob/master/drivers/mmc/sandbox_mmc.c
- it supports detecting MMC and reading/writing. I have a patch to
use a backing file on disk with another 20 lines

- easy to debug - can use gdb and everything is in U-Boot, no need to
chase through qemu code to understand what is wrong

- just enough features - we only implement what we need, keeping the
code simple and avoiding complexity

- can define emulators in the DT (as with sandbox_mmc and others) so
it is easy to add and remove emulated devices

- can run in CI very quickly (fraction of a second) rather than
needing qemu to spin up, etc.

This isn't about writing lots of useless code that is duplicating
functionality elsewhere. The sandbox emulators are much more flexible
and easy to use.

Regards,
Simon

Re: [PATCH 5/7] xyz-modem: Properly abort/terminate transfer on error

[Pali Rohár]

On Thursday 12 August 2021 15:46:23 Simon Glass wrote:
> Hi Pali,
> 
> On Tue, 3 Aug 2021 at 08:29, Pali Rohár  wrote:
> >
> > Transfer termination tries to instruct sender that transfer was terminated.
> >
> > Print error message and indicates aborted transfer in return value.
> >
> > Signed-off-by: Pali Rohár 
> > ---
> >  cmd/load.c | 14 +-
> >  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> Reviewed-by: Simon Glass 
> 
> >
> > diff --git a/cmd/load.c b/cmd/load.c
> > index fb8c191fb64f..1ed05a9cd21e 100644
> > --- a/cmd/load.c
> > +++ b/cmd/load.c
> > @@ -975,6 +975,7 @@ static ulong load_serial_ymodem(ulong offset, int mode)
> > res = xyzModem_stream_open(&info, &err);
> > if (!res) {
> >
> > +   err = 0;
> > while ((res =
> > xyzModem_stream_read(ymodemBuf, 1024, &err)) > 0) {
> > store_addr = addr + offset;
> > @@ -987,6 +988,9 @@ static ulong load_serial_ymodem(ulong offset, int mode)
> > rc = flash_write((char *) ymodemBuf,
> >   store_addr, res);
> > if (rc != 0) {
> > +   xyzModem_stream_terminate(true, 
> > &getcxmodem);
> > +   xyzModem_stream_close(&err);
> > +   printf("\n");
> > flash_perror(rc);
> > return (~0);
> > }
> > @@ -998,12 +1002,20 @@ static ulong load_serial_ymodem(ulong offset, int 
> > mode)
> > }
> >
> > }
> > +   if (err) {
> > +   xyzModem_stream_terminate((err == xyzModem_cancel) 
> > ? false : true, &getcxmodem);
> > +   xyzModem_stream_close(&err);
> > +   printf("\n%s\n", xyzModem_error(err));
> > +   return (~0); /* Download aborted */
> > +   }
> > +
> > if (IS_ENABLED(CONFIG_CMD_BOOTEFI))
> > efi_set_bootdev("Uart", "", "",
> > map_sysmem(offset, 0), size);
> >
> > } else {
> > -   printf("%s\n", xyzModem_error(err));
> > +   printf("\n%s\n", xyzModem_error(err));
> > +   return (~0); /* Download aborted */
> 
> Should not have brackets around return value.

Hello! I have just copied used style around, to not mix different styles.

> > }
> >
> > xyzModem_stream_terminate(false, &getcxmodem);
> > --
> > 2.20.1
> >
> 
> Regards,
> Simon

Re: Hints on how to use efi_driver/efi_block_device.c

[Simon Glass]

+Heinrich Schuchardt too

On Thu, 12 Aug 2021 at 08:35, Christian Melki
 wrote:
>
> I was hoping that U-boot would detect BLOCK_IO devices provided by UEFI
> automatically. But I can't see anything attached under lsblk or find
> some other information about this.
> For example, Barebox works just fine on both Virtualbox and real
> hardware in this regard.
>
> Barebox does not have an emmc driver for the real hardware but
> piggybacks off the UEFI protocol for this.
>
> I'm sure that the idea with this U-boot driver is something like that,
> but would appreciate some hints on how to use it.
>
> Ie, standard usage. UEFI boots of a drive, posts some handles(?) to a
> block device and U-boot picks it up, not knowing more about the
> abstracted hardware.
>
> Best regards,
> Christian

Re: [PATCH 17/23] power: Tidy up #undef of CONFIG_DM_PMIC

[Jaehoon Chung]

On 8/9/21 3:20 AM, Simon Glass wrote:
> Add a proper Kconfig option for SPL so we can remove the hack in some of
> the board config files.
> 
> This involves adding CONFIG_SPL_DM_PMIC to some of the configs as well
> as updateing the Makefile rule for PMIC_RK8XX to exclude SPL.
> 
> Signed-off-by: Simon Glass 

Removed Lukasz's email address.

Reviewed-by: Jaehoon Chung 

Best Regars,
Jaehoon Chung

> ---
> 
>  configs/imx8mm-cl-iot-gate_defconfig |  1 +
>  configs/imx8mm_beacon_defconfig  |  1 +
>  configs/imx8mm_evk_defconfig |  1 +
>  configs/imx8mm_venice_defconfig  |  1 +
>  configs/imx8mn_evk_defconfig |  1 +
>  configs/verdin-imx8mm_defconfig  |  1 +
>  drivers/power/pmic/Kconfig   | 13 +
>  drivers/power/pmic/Makefile  |  4 ++--
>  include/configs/imx8mp_evk.h |  1 -
>  include/configs/imx8mq_evk.h |  5 -
>  include/configs/imx8mq_phanbell.h|  5 -
>  include/configs/pico-imx8mq.h|  5 -
>  12 files changed, 21 insertions(+), 18 deletions(-)
> 
> diff --git a/configs/imx8mm-cl-iot-gate_defconfig 
> b/configs/imx8mm-cl-iot-gate_defconfig
> index 58eb2d49c9d..41efb0f2454 100644
> --- a/configs/imx8mm-cl-iot-gate_defconfig
> +++ b/configs/imx8mm-cl-iot-gate_defconfig
> @@ -102,6 +102,7 @@ CONFIG_PINCTRL_IMX8M=y
>  CONFIG_POWER_DOMAIN=y
>  CONFIG_IMX8M_POWER_DOMAIN=y
>  CONFIG_DM_PMIC=y
> +CONFIG_SPL_DM_PMIC=y
>  CONFIG_DM_PMIC_BD71837=y
>  CONFIG_SPL_DM_PMIC_BD71837=y
>  CONFIG_DM_REGULATOR=y
> diff --git a/configs/imx8mm_beacon_defconfig b/configs/imx8mm_beacon_defconfig
> index a3f1515f4eb..0d99d04edcb 100644
> --- a/configs/imx8mm_beacon_defconfig
> +++ b/configs/imx8mm_beacon_defconfig
> @@ -97,6 +97,7 @@ CONFIG_PINCTRL=y
>  CONFIG_SPL_PINCTRL=y
>  CONFIG_PINCTRL_IMX8M=y
>  CONFIG_DM_PMIC=y
> +CONFIG_SPL_DM_PMIC=y
>  CONFIG_DM_PMIC_BD71837=y
>  CONFIG_SPL_DM_PMIC_BD71837=y
>  CONFIG_DM_REGULATOR=y
> diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig
> index e0c0c66f2db..bfd2c7aa6c1 100644
> --- a/configs/imx8mm_evk_defconfig
> +++ b/configs/imx8mm_evk_defconfig
> @@ -74,6 +74,7 @@ CONFIG_PINCTRL=y
>  CONFIG_SPL_PINCTRL=y
>  CONFIG_PINCTRL_IMX8M=y
>  CONFIG_DM_PMIC=y
> +CONFIG_SPL_DM_PMIC=y
>  CONFIG_SPL_DM_PMIC_PCA9450=y
>  CONFIG_DM_REGULATOR=y
>  CONFIG_DM_REGULATOR_FIXED=y
> diff --git a/configs/imx8mm_venice_defconfig b/configs/imx8mm_venice_defconfig
> index 1a98a8eb6f5..3e09a4a6639 100644
> --- a/configs/imx8mm_venice_defconfig
> +++ b/configs/imx8mm_venice_defconfig
> @@ -99,6 +99,7 @@ CONFIG_PINCTRL=y
>  CONFIG_SPL_PINCTRL=y
>  CONFIG_PINCTRL_IMX8M=y
>  CONFIG_DM_PMIC=y
> +CONFIG_SPL_DM_PMIC=y
>  CONFIG_DM_PMIC_BD71837=y
>  CONFIG_SPL_DM_PMIC_BD71837=y
>  CONFIG_DM_PMIC_MP5416=y
> diff --git a/configs/imx8mn_evk_defconfig b/configs/imx8mn_evk_defconfig
> index 4da37bd0227..ccbd8753b32 100644
> --- a/configs/imx8mn_evk_defconfig
> +++ b/configs/imx8mn_evk_defconfig
> @@ -75,6 +75,7 @@ CONFIG_PINCTRL=y
>  CONFIG_SPL_PINCTRL=y
>  CONFIG_PINCTRL_IMX8M=y
>  CONFIG_DM_PMIC=y
> +CONFIG_SPL_DM_PMIC=y
>  CONFIG_SPL_DM_PMIC_PCA9450=y
>  CONFIG_DM_REGULATOR=y
>  CONFIG_DM_REGULATOR_FIXED=y
> diff --git a/configs/verdin-imx8mm_defconfig b/configs/verdin-imx8mm_defconfig
> index 341d802d611..2d7e9bebeb7 100644
> --- a/configs/verdin-imx8mm_defconfig
> +++ b/configs/verdin-imx8mm_defconfig
> @@ -91,6 +91,7 @@ CONFIG_PINCTRL_IMX8M=y
>  CONFIG_POWER_DOMAIN=y
>  CONFIG_IMX8M_POWER_DOMAIN=y
>  CONFIG_DM_PMIC=y
> +CONFIG_SPL_DM_PMIC=y
>  CONFIG_SPL_DM_PMIC_PCA9450=y
>  CONFIG_DM_PMIC_PFUZE100=y
>  CONFIG_DM_REGULATOR=y
> diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
> index fd6648b313e..cb2a6adf84e 100644
> --- a/drivers/power/pmic/Kconfig
> +++ b/drivers/power/pmic/Kconfig
> @@ -10,6 +10,19 @@ config DM_PMIC
>   - 'drivers/power/pmic/pmic-uclass.c'
>   - 'include/power/pmic.h'
>  
> +config SPL_DM_PMIC
> + bool "Enable Driver Model for PMIC drivers (UCLASS_PMIC) in SPL"
> + depends on SPL_DM
> + default y if DM_PMIC
> + ---help---
> + This config enables the driver-model PMIC support in SPL.
> + UCLASS_PMIC - designed to provide an I/O interface for PMIC devices.
> + For the multi-function PMIC devices, this can be used as parent I/O
> + device for each IC's interface. Then, each children uses its parent
> + for read/write. For detailed description, please refer to the files:
> + - 'drivers/power/pmic/pmic-uclass.c'
> + - 'include/power/pmic.h'
> +
>  config PMIC_CHILDREN
>   bool "Allow child devices for PMICs"
>   depends on DM_PMIC
> diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
> index 5d1a97e5f6f..5250eac12f2 100644
> --- a/drivers/power/pmic/Makefile
> +++ b/drivers/power/pmic/Makefile
> @@ -3,7 +3,7 @@
>  # Copyright (C) 2012 Samsung Electronics
>  # Lukasz Majewski 
>  
> -obj-$(CONFIG_DM_PMIC) += pmic-uclass.o
> +obj-$(CONFIG_$(SPL_TPL_)DM_PMIC) += pmic-uclass.o
>  obj-$(CONFIG_

Re: [PATCH 18/23] power: Rename CONFIG_POWER to CONFIG_POWER_LEGACY

[Jaehoon Chung]

On 8/9/21 3:20 AM, Simon Glass wrote:
> This option is used in pre-driver model code and much of it has never
> been converted to driver model.
> 
> We want to add a new option to enable power support, so we can use a
> simple rule in the Makefile. Rename this one, which is really about
> a particular implementation of power.
> 
> Also update the pmic.h header file so it either includes the legacy
> API or the driver model one.
> 
> Signed-off-by: Simon Glass 


Reviewed-by: Jaehoon Chung 

Best Regars,
Jaehoon Chung

> ---
> 
>  board/compulab/cl-som-imx7/cl-som-imx7.c |  4 ++--
>  board/freescale/imx8mp_evk/spl.c |  2 +-
>  board/freescale/imx8mq_evk/spl.c |  2 +-
>  board/samsung/common/board.c |  2 +-
>  board/technexion/pico-imx7d/pico-imx7d.c |  2 +-
>  board/tqc/tqma6/tqma6.c  |  2 +-
>  board/udoo/neo/neo.c |  2 +-
>  drivers/power/Makefile   |  2 +-
>  drivers/power/regulator/Makefile |  2 +-
>  include/configs/am43xx_evm.h |  2 +-
>  include/configs/cl-som-imx7.h|  2 +-
>  include/configs/cm_t43.h |  2 +-
>  include/configs/el6x_common.h|  2 +-
>  include/configs/gw_ventana.h |  2 +-
>  include/configs/hikey.h  |  2 +-
>  include/configs/imx8mp_evk.h |  2 +-
>  include/configs/imx8mq_evk.h |  2 +-
>  include/configs/imx8mq_phanbell.h|  2 +-
>  include/configs/ls1046ardb.h |  4 ++--
>  include/configs/mx51evk.h|  2 +-
>  include/configs/mx53loco.h   |  2 +-
>  include/configs/mx6sabreauto.h   |  2 +-
>  include/configs/mx6sabresd.h |  2 +-
>  include/configs/novena.h |  2 +-
>  include/configs/phycore_imx8mp.h |  2 +-
>  include/configs/pico-imx7d.h |  2 +-
>  include/configs/pico-imx8mq.h|  2 +-
>  include/configs/tqma6.h  |  2 +-
>  include/configs/udoo_neo.h   |  2 +-
>  include/configs/vining_2000.h|  2 +-
>  include/configs/warp.h   |  2 +-
>  include/power/max77686_pmic.h|  2 +-
>  include/power/pmic.h | 15 ++-
>  scripts/config_whitelist.txt |  2 +-
>  34 files changed, 45 insertions(+), 40 deletions(-)
> 
> diff --git a/board/compulab/cl-som-imx7/cl-som-imx7.c 
> b/board/compulab/cl-som-imx7/cl-som-imx7.c
> index 454c93a572f..c54e02fdb44 100644
> --- a/board/compulab/cl-som-imx7/cl-som-imx7.c
> +++ b/board/compulab/cl-som-imx7/cl-som-imx7.c
> @@ -267,7 +267,7 @@ int board_init(void)
>   return 0;
>  }
>  
> -#ifdef CONFIG_POWER
> +#ifdef CONFIG_POWER_LEGACY
>  #define I2C_PMIC 0
>  int power_init_board(void)
>  {
> @@ -293,7 +293,7 @@ int power_init_board(void)
>  
>   return 0;
>  }
> -#endif /* CONFIG_POWER */
> +#endif /* CONFIG_POWER_LEGACY */
>  
>  /*
>   * cl_som_imx7_setup_wdog() - watchdog configuration.
> diff --git a/board/freescale/imx8mp_evk/spl.c 
> b/board/freescale/imx8mp_evk/spl.c
> index a7564e9b1ae..d317f212973 100644
> --- a/board/freescale/imx8mp_evk/spl.c
> +++ b/board/freescale/imx8mp_evk/spl.c
> @@ -63,7 +63,7 @@ struct i2c_pads_info i2c_pad_info1 = {
>   },
>  };
>  
> -#ifdef CONFIG_POWER
> +#ifdef CONFIG_POWER_LEGACY
>  #define I2C_PMIC 0
>  int power_init_board(void)
>  {
> diff --git a/board/freescale/imx8mq_evk/spl.c 
> b/board/freescale/imx8mq_evk/spl.c
> index e8e0efe4855..6ee6230f748 100644
> --- a/board/freescale/imx8mq_evk/spl.c
> +++ b/board/freescale/imx8mq_evk/spl.c
> @@ -156,7 +156,7 @@ int board_mmc_init(struct bd_info *bis)
>   return 0;
>  }
>  
> -#ifdef CONFIG_POWER
> +#ifdef CONFIG_POWER_LEGACY
>  #define I2C_PMIC 0
>  int power_init_board(void)
>  {
> diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
> index 1c2fe025e89..08f9202b711 100644
> --- a/board/samsung/common/board.c
> +++ b/board/samsung/common/board.c
> @@ -185,7 +185,7 @@ int board_early_init_f(void)
>  }
>  #endif
>  
> -#if defined(CONFIG_POWER) || defined(CONFIG_DM_PMIC)
> +#if defined(CONFIG_POWER_LEGACY) || defined(CONFIG_DM_PMIC)
>  int power_init_board(void)
>  {
>   set_ps_hold_ctrl();
> diff --git a/board/technexion/pico-imx7d/pico-imx7d.c 
> b/board/technexion/pico-imx7d/pico-imx7d.c
> index 2d749dac19a..81b1fb35122 100644
> --- a/board/technexion/pico-imx7d/pico-imx7d.c
> +++ b/board/technexion/pico-imx7d/pico-imx7d.c
> @@ -60,7 +60,7 @@ int dram_init(void)
>   return 0;
>  }
>  
> -#ifdef CONFIG_POWER
> +#ifdef CONFIG_POWER_LEGACY
>  #define I2C_PMIC 3
>  int power_init_board(void)
>  {
> diff --git a/board/tqc/tqma6/tqma6.c b/board/tqc/tqma6/tqma6.c
> index 4f86a929016..5d2e13a95a2 100644
> --- a/board/tqc/tqma6/tqma6.c
> +++ b/board/tqc/tqma6/tqma6.c
> @@ -247,7 +247,7 @@ static const char *tqma6_get_boardname(void)
>   };
>  }
>  
> -#ifdef CONFIG_POWER
> +#ifdef CONFIG_POWER_LEGACY
>  /* s

Re: [PATCH 19/23] i2c: Convert CONFIG_POWER_I2C et al to Kconfig

[Jaehoon Chung]

On 8/9/21 3:20 AM, Simon Glass wrote:
> This converts the following to Kconfig:
>CONFIG_POWER_I2C
>CONFIG_POWER_LEGACY
> 
> They are handled at the same time due to a dependency between them.
> Update the Makefile rule to use legacy power only in U-Boot proper.
> 
> Unfortunately a separate rule is needed in SPL to be able to build legacy
> power. All of this can be cleaned up when boards are migrated or removed.
> 
> Signed-off-by: Simon Glass 

Reviewed-by: Jaehoon Chung 

Best Regars,
Jaehoon Chung

> ---

Re: [PATCH 21/23] power: Refactor Makefile rules

[Jaehoon Chung]

On 8/9/21 3:20 AM, Simon Glass wrote:
> Move the power/ rules into drivers/power to avoid clutter in the Makefile
> and drivers/Makefile files.
> 
> We must select SPL_POWER if SPL_POWER_DOMAIN is used, since the two are
> currently independent and boards do not necessarily enable SPL_POWER.
> 
> Add a TPL_POWER as well, as that is used by one board.
> 
> Signed-off-by: Simon Glass 

Reviewed-by: Jaehoon Chung 

Best Regars,
Jaehoon Chung

> ---
> 
>  Makefile   |  7 ---
>  common/spl/Kconfig | 13 +
>  configs/chromebook_coral_defconfig |  2 ++
>  drivers/Makefile   |  5 +
>  drivers/power/Makefile |  8 
>  drivers/power/acpi_pmc/Makefile|  2 +-
>  6 files changed, 25 insertions(+), 12 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index cc51265f1fc..c744ff8ee4e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -815,13 +815,6 @@ libs-y += disk/
>  libs-y += drivers/
>  libs-y += drivers/net/
>  libs-y += drivers/net/phy/
> -libs-y += drivers/power/ \
> - drivers/power/domain/ \
> - drivers/power/fuel_gauge/ \
> - drivers/power/mfd/ \
> - drivers/power/pmic/ \
> - drivers/power/battery/ \
> - drivers/power/regulator/
>  libs-$(CONFIG_FMAN_ENET) += drivers/net/fm/
>  libs-$(CONFIG_SYS_FSL_DDR) += drivers/ddr/fsl/
>  libs-$(CONFIG_SYS_FSL_MMDC) += drivers/ddr/fsl/
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index 1ce74d07618..59672d2fdd3 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -1042,6 +1042,7 @@ config SPL_POWER
>  
>  config SPL_POWER_DOMAIN
>   bool "Support power domain drivers"
> + select SPL_POWER
>   help
> Enable support for power domain control in SPL. Many SoCs allow
> power to be applied to or removed from portions of the SoC (power
> @@ -1431,6 +1432,18 @@ config TPL_NEEDS_SEPARATE_STACK
> Enable, if the TPL stage should not inherit its initial
> stack-pointer from the settings for the SPL stage.
>  
> +config TPL_POWER
> + bool "Support power drivers"
> + help
> +   Enable support for power control in TPL. This includes support
> +   for PMICs (Power-management Integrated Circuits) and some of the
> +   features provided by PMICs. In particular, voltage regulators can
> +   be used to enable/disable power and vary its voltage. That can be
> +   useful in TPL to turn on boot peripherals and adjust CPU voltage
> +   so that the clock speed can be increased. This enables the drivers
> +   in drivers/power, drivers/power/pmic and drivers/power/regulator
> +   as part of an TPL build.
> +
>  config TPL_TEXT_BASE
>   hex "Base address for the .text section of the TPL stage"
>   depends on TPL_NEEDS_SEPARATE_TEXT_BASE
> diff --git a/configs/chromebook_coral_defconfig 
> b/configs/chromebook_coral_defconfig
> index eb0884f1f5d..321ad7de5b7 100644
> --- a/configs/chromebook_coral_defconfig
> +++ b/configs/chromebook_coral_defconfig
> @@ -44,7 +44,9 @@ CONFIG_SPL_SEPARATE_BSS=y
>  CONFIG_SPL_CPU=y
>  CONFIG_SPL_DM_SPI_FLASH=y
>  CONFIG_SPL_PCI=y
> +CONFIG_SPL_POWER=y
>  # CONFIG_SPL_SPI_FLASH_TINY is not set
> +CONFIG_TPL_POWER=y
>  CONFIG_HUSH_PARSER=y
>  CONFIG_CMD_CPU=y
>  CONFIG_CMD_PMC=y
> diff --git a/drivers/Makefile b/drivers/Makefile
> index d63cc48f5f4..c256cd97210 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -22,6 +22,7 @@ obj-$(CONFIG_$(SPL_TPL_)PCH) += pch/
>  obj-$(CONFIG_$(SPL_TPL_)PCI) += pci/
>  obj-$(CONFIG_$(SPL_TPL_)PHY) += phy/
>  obj-$(CONFIG_$(SPL_TPL_)PINCTRL) += pinctrl/
> +obj-$(CONFIG_$(SPL_TPL_)POWER) += power/
>  obj-$(CONFIG_$(SPL_TPL_)RAM) += ram/
>  obj-$(CONFIG_$(SPL_TPL_)RTC) += rtc/
>  obj-$(CONFIG_$(SPL_TPL_)SERIAL) += serial/
> @@ -32,7 +33,6 @@ obj-$(CONFIG_$(SPL_)DM_MAILBOX) += mailbox/
>  obj-$(CONFIG_$(SPL_)REMOTEPROC) += remoteproc/
>  obj-$(CONFIG_$(SPL_)SYSINFO) += sysinfo/
>  obj-$(CONFIG_$(SPL_TPL_)TPM) += tpm/
> -obj-$(CONFIG_$(SPL_TPL_)ACPI_PMC) += power/acpi_pmc/
>  obj-$(CONFIG_XEN) += xen/
>  obj-$(CONFIG_$(SPL_)FPGA) += fpga/
>  
> @@ -46,9 +46,6 @@ obj-$(CONFIG_ARMADA_38X) += ddr/marvell/a38x/
>  obj-$(CONFIG_ARMADA_XP) += ddr/marvell/axp/
>  obj-$(CONFIG_$(SPL_)ALTERA_SDRAM) += ddr/altera/
>  obj-$(CONFIG_ARCH_IMX8M) += ddr/imx/imx8m/
> -obj-$(CONFIG_SPL_POWER) += power/ power/pmic/
> -obj-$(CONFIG_SPL_POWER) += power/regulator/
> -obj-$(CONFIG_SPL_POWER_DOMAIN) += power/domain/
>  obj-$(CONFIG_SPL_DM_RESET) += reset/
>  obj-$(CONFIG_SPL_ETH) += net/
>  obj-$(CONFIG_SPL_ETH) += net/phy/
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index 09fe2a958d0..5c6d6bc3ec9 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -3,6 +3,14 @@
>  # Copyright (c) 2009 Wind River Systems, Inc.
>  # Tom Rix 
>  
> +obj-$(CONFIG_$(SPL_TPL_)ACPI_PMC) += acpi_pmc/
> +obj-y += battery/
> +obj-$(CONFIG_$(SPL_TPL_)POWER_DOMAIN) += domain/
> +obj-y += fuel_gauge/
> +obj-y

Re: [PATCH 05/12] mmc: nds32: ftsdc010: Convert to livetree

[Jaehoon Chung]

On 8/7/21 10:24 PM, Simon Glass wrote:
> Use the livetree API for this driver.
> 
> Signed-off-by: Simon Glass 

Reviewed-by: Jaehoon Chung 

Best Regars,
Jaehoon Chung

> ---
> 
>  drivers/mmc/ftsdc010_mci.c | 22 +++---
>  1 file changed, 7 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/mmc/ftsdc010_mci.c b/drivers/mmc/ftsdc010_mci.c
> index 221fba313d3..b30da5b72a4 100644
> --- a/drivers/mmc/ftsdc010_mci.c
> +++ b/drivers/mmc/ftsdc010_mci.c
> @@ -30,8 +30,6 @@
>  #include 
>  #include 
>  
> -DECLARE_GLOBAL_DATA_PTR;
> -
>  #define CFG_CMD_TIMEOUT (CONFIG_SYS_HZ >> 4) /* 250 ms */
>  #define CFG_RST_TIMEOUT CONFIG_SYS_HZ /* 1 sec reset timeout */
>  
> @@ -395,24 +393,18 @@ static int ftsdc010_mmc_of_to_plat(struct udevice *dev)
>  #if CONFIG_IS_ENABLED(OF_REAL)
>   struct ftsdc_priv *priv = dev_get_priv(dev);
>   struct ftsdc010_chip *chip = &priv->chip;
> +
>   chip->name = dev->name;
>   chip->ioaddr = dev_read_addr_ptr(dev);
> - chip->buswidth = fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev),
> - "bus-width", 4);
> + chip->buswidth = dev_read_u32_default(dev, "bus-width", 4);
>   chip->priv = dev;
> - priv->fifo_depth = fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev),
> - "fifo-depth", 0);
> - priv->fifo_mode = fdtdec_get_bool(gd->fdt_blob, dev_of_offset(dev),
> -   "fifo-mode");
> - if (fdtdec_get_int_array(gd->fdt_blob, dev_of_offset(dev),
> -  "clock-freq-min-max", priv->minmax, 2)) {
> - int val = fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev),
> -   "max-frequency", -EINVAL);
> - if (val < 0)
> - return val;
> + priv->fifo_depth = dev_read_u32_default(dev, "fifo-depth", 0);
> + priv->fifo_mode = dev_read_bool(dev, "fifo-mode");
> + if (dev_read_u32_array(dev, "clock-freq-min-max", priv->minmax, 2)) {
> + if (dev_read_u32(dev, "max-frequency", &priv->minmax[1]))
> + return -EINVAL;
>  
>   priv->minmax[0] = 40;  /* 400 kHz */
> - priv->minmax[1] = val;
>   } else {
>   debug("%s: 'clock-freq-min-max' property was deprecated.\n",
>   __func__);
> 

Re: [PATCH 01/23] mmc: Rename MMC_SUPPORT to MMC

[Jaehoon Chung]

On 8/9/21 3:20 AM, Simon Glass wrote:
> Rename these options so that CONFIG_IS_ENABLED can be used with them.
> 
> Signed-off-by: Simon Glass 


Reviewed-by: Jaehoon Chung 

Best Regars,
Jaehoon Chung

> ---

Re: [PATCH 3/3] exynos: Update environment macros a bit

[Jaehoon Chung]

On 8/11/21 6:34 AM, Tom Rini wrote:
> Rework the default environment a bit to not use non-standard
> CONFIG_ENV_... names and similar one-off CONFIG names.
> 
> Cc: Jaehoon Chung 
> Signed-off-by: Tom Rini 

Reviewed-by: Jaehoon Chung 

Best Regars,
Jaehoon Chung

> ---
>  include/configs/exynos4-common.h|  2 +-
>  include/configs/s5pc210_universal.h | 26 +-
>  include/configs/trats.h |  9 +++--
>  include/configs/trats2.h|  2 +-
>  4 files changed, 14 insertions(+), 25 deletions(-)
> 
> diff --git a/include/configs/exynos4-common.h 
> b/include/configs/exynos4-common.h
> index 5e2aca371e7e..2ca14d0b86e3 100644
> --- a/include/configs/exynos4-common.h
> +++ b/include/configs/exynos4-common.h
> @@ -32,7 +32,7 @@
>  #define CONFIG_USB_GADGET_DWC2_OTG_PHY
>  
>  /* Common environment variables */
> -#define CONFIG_EXTRA_ENV_ITB \
> +#define ENV_ITB \
>   "loadkernel=load mmc ${mmcbootdev}:${mmcbootpart} ${kerneladdr} " \
>   "${kernelname}\0" \
>   "loadinitrd=load mmc ${mmcbootdev}:${mmcbootpart} ${initrdaddr} " \
> diff --git a/include/configs/s5pc210_universal.h 
> b/include/configs/s5pc210_universal.h
> index 0b679f437482..8ee667e69306 100644
> --- a/include/configs/s5pc210_universal.h
> +++ b/include/configs/s5pc210_universal.h
> @@ -44,16 +44,6 @@
>   ",100M(swap)"\
>   ",-(UMS)\0"
>  
> -#define CONFIG_ENV_UBI_MTD   " ubi.mtd=${ubiblock} ubi.mtd=4 ubi.mtd=7"
> -#define CONFIG_BOOTBLOCK "10"
> -#define CONFIG_UBIBLOCK  "9"
> -
> -#define CONFIG_ENV_UBIFS_OPTION  " rootflags=bulk_read,no_chk_data_crc "
> -#define CONFIG_ENV_FLASHBOOT CONFIG_ENV_UBI_MTD CONFIG_ENV_UBIFS_OPTION \
> - "${mtdparts}"
> -
> -#define CONFIG_ENV_COMMON_BOOT   "${console} ${meminfo}"
> -
>  #define CONFIG_EXTRA_ENV_SETTINGS\
>   "updateb=" \
>   "onenand erase 0x0 0x10;" \
> @@ -71,18 +61,20 @@
>   "lpj=lpj=3981312\0" \
>   "ubifsboot=" \
>   "set bootargs root=ubi0!rootfs rootfstype=ubifs ${lpj} " \
> - CONFIG_ENV_FLASHBOOT " ${opts} ${lcdinfo} " \
> - CONFIG_ENV_COMMON_BOOT "; run bootk\0" \
> + "ubi.mtd=${ubiblock} ubi.mtd=4 ubi.mtd=7 " \
> + "rootflags=bulk_read,no_chk_data_crc ${mtdparts} ${opts} " \
> + "${lcdinfo} ${console} ${meminfo}; run bootk\0" \
>   "tftpboot=" \
>   "set bootargs root=ubi0!rootfs rootfstype=ubifs " \
> - CONFIG_ENV_FLASHBOOT " ${opts} ${lcdinfo} " \
> - CONFIG_ENV_COMMON_BOOT \
> + "ubi.mtd=${ubiblock} ubi.mtd=4 ubi.mtd=7 " \
> + "rootflags=bulk_read,no_chk_data_crc ${mtdparts} ${opts} " \
> + "${lcdinfo} ${console} ${meminfo}" \
>   "; tftp 0x40007FC0 uImage; bootm 0x40007FC0\0" \
>   "nfsboot=" \
>   "set bootargs root=/dev/nfs rw " \
>   "nfsroot=${nfsroot},nolock,tcp " \
>   "ip=${ipaddr}:${serverip}:${gatewayip}:" \
> - "${netmask}:generic:usb0:off " CONFIG_ENV_COMMON_BOOT \
> + "${netmask}:generic:usb0:off ${console} ${meminfo}" \
>   "; run bootk\0" \
>   "ramfsboot=" \
>   "set bootargs root=/dev/ram0 rw rootfstype=ext2 " \
> @@ -102,8 +94,8 @@
>   "mbrparts=" MBRPARTS_DEFAULT \
>   "meminfo=crashkernel=32M@0x5000\0" \
>   "nfsroot=/nfsroot/arm\0" \
> - "bootblock=" CONFIG_BOOTBLOCK "\0" \
> - "ubiblock=" CONFIG_UBIBLOCK" \0" \
> + "bootblock=10\0" \
> + "ubiblock=9\0" \
>   "ubi=enabled\0" \
>   "loaduimage=fatload mmc ${mmcdev}:${mmcbootpart} 0x40007FC0 uImage\0" \
>   "mmcdev=0\0" \
> diff --git a/include/configs/trats.h b/include/configs/trats.h
> index a44792d85764..c3f891ae53d8 100644
> --- a/include/configs/trats.h
> +++ b/include/configs/trats.h
> @@ -40,9 +40,6 @@
>  
>  #define CONFIG_SYS_MONITOR_BASE  0x
>  
> -#define CONFIG_BOOTBLOCK "10"
> -#define CONFIG_ENV_COMMON_BOOT   "${console} ${meminfo}"
> -
>  /* Tizen - partitions definitions */
>  #define PARTS_CSA"csa-mmc"
>  #define PARTS_BOOT   "boot"
> @@ -94,7 +91,7 @@
>   "setenv bootargs root=/dev/nfs rw " \
>   "nfsroot=${nfsroot},nolock,tcp " \
>   "ip=${ipaddr}:${serverip}:${gatewayip}:" \
> - "${netmask}:generic:usb0:off " CONFIG_ENV_COMMON_BOOT \
> + "${netmask}:generic:usb0:off ${console} ${meminfo}" \
>   "; run bootk\0" \
>   "ramfsboot=" \
>   "setenv bootargs root=/dev/ram0 rw rootfstype=ext2 " \
> @@ -112,7 +109,7 @@
>   "console=console=ttySAC2,115200n8\0" \
>   "meminfo=crashkernel=32M@0x5000\0" \
>   "nfsroot=/nfsroot/arm\0" \
> - "bootblock=" CONFIG_BOOTBLOCK "\0" \
> + "bootblock=10\0" \
>   "loaduimage=ext4

[PATCH] env: Make _init() expect _INVALID when _IS_NOWHERE

[Pierre-Clément Tosi]

Avoid applying the "fix" introduced by commit 5557eec01cbf ("env: Fix
invalid env handling in env_init()") to the environment "nowhere".

This is necessary as that commit, by setting the return value of
env_init() to -ENOENT if gd->env_valid is ENV_INVALID, forces that
function to reset gd->env_valid to ENV_VALID. By doing so, it breaks the
assumption (required by ENV_IS_NOWHERE) that gd->env_valid must be
ENV_INVALID.

This, in turn, results in env_relocate() calling env_load() (it should
not), which itself, calls U_BOOT_ENV_LOCATION(nowhere).load() i.e.
env_nowhere_load(). That function, being implemented under the
assumption mentioned above, calls env_set_default(), which in turn,
seeing that gd->env_valid is ENV_VALID (it should not), tries to
dereference whatever lies in gd->env_addr (most likely garbage), leading
to a faulty memory access.

Note that other env_locations might be concerned by this bug but that
this commit only intends to fix it for when ENV_IS_NOWHERE.

Fixes: 5557eec01cbf ("env: Fix invalid env handling in env_init()")
Signed-off-by: Pierre-Clément Tosi 
---
 env/env.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/env/env.c b/env/env.c
index e534008006..0a0f234747 100644
--- a/env/env.c
+++ b/env/env.c
@@ -336,7 +336,7 @@ int env_init(void)
debug("%s: Environment %s init done (ret=%d)\n", __func__,
  drv->name, ret);
 
-   if (gd->env_valid == ENV_INVALID)
+   if (gd->env_valid == ENV_INVALID && drv->location != 
ENVL_NOWHERE)
ret = -ENOENT;
}
 
-- 
2.32.0.605.g8dce9f2422-goog


-- 
Pierre

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

[Chris Morgan]

On Thu, Aug 12, 2021 at 09:15:14PM +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 
> ---
> 

I'll need to debug it further, but unfortunately this is not working
for me. On my Odroid Go Advance I get a "Synchronous Abort" error when
I attempt to do an "sf probe". This same sequence (boot, then do sf
probe) has worked on all prior revisions without a crash.

U-Boot TPL board init
DDR3, 333MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
out

U-Boot SPL 2021.10-rc1+ (Aug 12 2021 - 14:03:30 -0500)
Trying to boot from MMC1
NOTICE:  BL31: v2.5(release):v2.5-284-g87311b4c1
NOTICE:  BL31: Built : 10:43:59, Aug  5 2021


U-Boot 2021.10-rc1+ (Aug 12 2021 - 14:03:30 -0500)

Model: ODROID-GO Advance
DRAM:  1022 MiB
PMIC:  RK8170 (on=0x80, off=0x04)
MMC:   dwmmc@ff37: 0
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
In:serial@ff16
Out:   serial@ff16
Err:   serial@ff16
Model: ODROID-GO Advance
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
MMC Device 1 not found
no mmc device at slot 1
starting USB...
Bus usb@ff30: probe failed, error -2
No working controllers found
USB is stopped. Please issue 'usb start' first.
=> sf probe
"Synchronous Abort" handler, esr 0x9610
elr: 0022d730 lr : 0022d72c (reloc)
elr: 3ff85730 lr : 3ff8572c
x0 :  x1 : 066ff300
x2 : 3ff85714 x3 : 
x4 : 3ffccd1d x5 : 006e
x6 : 3ffba6d8 x7 : 0044
x8 : 000a x9 : 0008
x10: 0034 x11: 0003
x12:  x13: ffd8
x14: 3df485d0 x15: 0002
x16: 3ff8ebe8 x17: 0001
x18: 3df53dd0 x19: 066ff300
x20:  x21: 066ff300
x22: 3ffbdef8 x23: 1000
x24: 3df6f530 x25: 3df92e90
x26: 3ffeecc0 x27: 
x28: 0003 x29: 3df481c0

Code: f90013f5 2a0103f5 94003427 aa0003f4 (294c0013)
Resetting CPU ...

resetting ...


> Changes in v8:
> - Move speed operation to set_speed logic
> - Use read_poll
> - Change debug to dev_dbg
> - Simply exec_op dma logic
> 
> Changes in v7:
> - Make sfc-use-dma configurable
> 
> 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 +
>  

[PATCH v3 0/3] Add support for the GST ESPRESSOBin-Ultra board

[Luka Kovacic]

This patchset adds initial support for the ESPRESSOBin-Ultra board from
Globalscale Technologies, Inc.

The board is based on the 64-bit dual-core Marvell Armada 3720 SoC.
Peripherals:
 - 5 Gigabit Ethernet ports (WAN has PoE, up to 30W, Topaz 6341 switch)
 - RTC clock (PCF8563)
 - USB 3.0 port
 - USB 2.0 port
 - 4x LED
 - UART over Micro-USB
 - M.2 slot (2280)
 - Mini PCI-E slot

Additionally support for importing Marvell hw_info formatted environments
is added to fully support the board.

Changes for v3:
  - Use the common mac command instead of the vendor specific hw_info
  - Clean up the device tree to use a dtsi, like in Linux
  - Sync the defconfig with the latest mainline changes

Luka Kovacic (3):
  arm: mvebu: mvebu_armada-37xx: Implement the mac command (Marvell
hw_info)
  arm: mvebu: mvebu_armada-37xx: Define the loadaddr environment
variable
  arm: mvebu: Initial ESPRESSOBin-Ultra board support

 arch/arm/dts/Makefile |   1 +
 .../arm/dts/armada-3720-espressobin-ultra.dts | 114 +
 arch/arm/dts/armada-3720-espressobin.dts  | 199 +
 arch/arm/dts/armada-3720-espressobin.dtsi | 210 ++
 arch/arm/mach-mvebu/Kconfig   |   1 +
 board/Marvell/mvebu_armada-37xx/Kconfig   |  29 ++
 board/Marvell/mvebu_armada-37xx/MAINTAINERS   |   8 +
 board/Marvell/mvebu_armada-37xx/Makefile  |   3 +-
 board/Marvell/mvebu_armada-37xx/board.c   |  92 -
 board/Marvell/mvebu_armada-37xx/mac/Makefile  |   5 +
 board/Marvell/mvebu_armada-37xx/mac/hw_info.c | 391 ++
 .../mvebu_espressobin-ultra-88f3720_defconfig |  93 +
 include/configs/mvebu_armada-37xx.h   |   8 +
 lib/hashtable.c   |   2 +-
 14 files changed, 951 insertions(+), 205 deletions(-)
 create mode 100644 arch/arm/dts/armada-3720-espressobin-ultra.dts
 create mode 100644 arch/arm/dts/armada-3720-espressobin.dtsi
 create mode 100644 board/Marvell/mvebu_armada-37xx/Kconfig
 create mode 100644 board/Marvell/mvebu_armada-37xx/mac/Makefile
 create mode 100644 board/Marvell/mvebu_armada-37xx/mac/hw_info.c
 create mode 100644 configs/mvebu_espressobin-ultra-88f3720_defconfig

-- 
2.31.1

[PATCH v3 2/3] arm: mvebu: mvebu_armada-37xx: Define the loadaddr environment variable

[Luka Kovacic]

Add the loadaddr U-Boot environment variable, as this is available in
the stock Marvell U-Boot by default on Marvell Armada A37XX platforms.

Signed-off-by: Luka Kovacic 
Cc: Luka Perkov 
Cc: Robert Marko 
---
 include/configs/mvebu_armada-37xx.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/mvebu_armada-37xx.h 
b/include/configs/mvebu_armada-37xx.h
index 8e8bcfa018..6901680e32 100644
--- a/include/configs/mvebu_armada-37xx.h
+++ b/include/configs/mvebu_armada-37xx.h
@@ -110,6 +110,7 @@
 
 /* fdt_addr and kernel_addr are needed for existing distribution boot scripts 
*/
 #define CONFIG_EXTRA_ENV_SETTINGS  \
+   "loadaddr=0x600\0"  \
"scriptaddr=0x6d0\0"\
"pxefile_addr_r=0x6e0\0"\
"fdt_addr=0x6f0\0"  \
-- 
2.31.1

[PATCH v3 1/3] arm: mvebu: mvebu_armada-37xx: Implement the mac command (Marvell hw_info)

[Luka Kovacic]

The mac command is implemented to enable parsing Marvell hw_info formatted
environments. This format is often used on Marvell Armada A37XX based
devices to store parameters like the board serial number, factory
MAC addresses and some other information.
These parameters are usually written to the flash in the factory.

Currently the mac command supports reading/writing parameters and dumping
the current hw_info parameters.
EEPROM config pattern and checksum aren't supported.

This functionality has been tested on the GST ESPRESSOBin-Ultra board
successfully, both reading the stock U-Boot parameters in mainline U-Boot
and reading the parameters written by this command in the stock U-Boot.

Usage example:
 => mac read
 => saveenv

Signed-off-by: Luka Kovacic 
Cc: Luka Perkov 
Cc: Robert Marko 
---
 arch/arm/mach-mvebu/Kconfig   |   1 +
 board/Marvell/mvebu_armada-37xx/Kconfig   |  29 ++
 board/Marvell/mvebu_armada-37xx/Makefile  |   3 +-
 board/Marvell/mvebu_armada-37xx/mac/Makefile  |   5 +
 board/Marvell/mvebu_armada-37xx/mac/hw_info.c | 391 ++
 include/configs/mvebu_armada-37xx.h   |   7 +
 lib/hashtable.c   |   2 +-
 7 files changed, 436 insertions(+), 2 deletions(-)
 create mode 100644 board/Marvell/mvebu_armada-37xx/Kconfig
 create mode 100644 board/Marvell/mvebu_armada-37xx/mac/Makefile
 create mode 100644 board/Marvell/mvebu_armada-37xx/mac/hw_info.c

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 89737a37ad..dff9f05b28 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -312,6 +312,7 @@ config SECURED_MODE_CSK_INDEX
default 0
depends on SECURED_MODE_IMAGE
 
+source "board/Marvell/mvebu_armada-37xx/Kconfig"
 source "board/solidrun/clearfog/Kconfig"
 source "board/kobol/helios4/Kconfig"
 
diff --git a/board/Marvell/mvebu_armada-37xx/Kconfig 
b/board/Marvell/mvebu_armada-37xx/Kconfig
new file mode 100644
index 00..b84dd20023
--- /dev/null
+++ b/board/Marvell/mvebu_armada-37xx/Kconfig
@@ -0,0 +1,29 @@
+menu "Marvell Armada 37xx configuration"
+depends on TARGET_MVEBU_ARMADA_37XX
+
+config MVEBU_MAC_HW_INFO
+   bool "Marvell hw_info (mac) support"
+   depends on SPI_FLASH && ENV_IS_IN_SPI_FLASH && ARCH_MVEBU
+   default n
+   help
+ Enable loading of the Marvell hw_info parameters from the
+ SPI flash hw_info area. Parameters (usually the board serial
+ number and MAC addresses) are then imported into the
+ existing U-Boot environment.
+ Implementation of this command is compatible with the
+ original Marvell U-Boot command. Reading and writing is
+ supported.
+ EEPROM config pattern and checksum aren't supported.
+ After enabled, these parameters are managed from the common
+ U-Boot mac command.
+
+config MVEBU_MAC_HW_INFO_OFFSET
+   hex "Marvell hw_info (mac) SPI flash offset"
+   depends on MVEBU_MAC_HW_INFO
+   default 0x3E
+   help
+ This option defines the SPI flash offset of the Marvell
+ hw_info area. This defaults to 0x3E on most Armada
+ A3720 platforms.
+
+endmenu
diff --git a/board/Marvell/mvebu_armada-37xx/Makefile 
b/board/Marvell/mvebu_armada-37xx/Makefile
index 27221557c7..6f6ac6b193 100644
--- a/board/Marvell/mvebu_armada-37xx/Makefile
+++ b/board/Marvell/mvebu_armada-37xx/Makefile
@@ -2,4 +2,5 @@
 #
 # Copyright (C) 2016 Stefan Roese 
 
-obj-y  := board.o
+obj-y += board.o
+obj-y += mac/
diff --git a/board/Marvell/mvebu_armada-37xx/mac/Makefile 
b/board/Marvell/mvebu_armada-37xx/mac/Makefile
new file mode 100644
index 00..7c30fe6194
--- /dev/null
+++ b/board/Marvell/mvebu_armada-37xx/mac/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (c) 2021 Sartura Ltd.
+
+obj-$(CONFIG_ID_EEPROM) += hw_info.o
diff --git a/board/Marvell/mvebu_armada-37xx/mac/hw_info.c 
b/board/Marvell/mvebu_armada-37xx/mac/hw_info.c
new file mode 100644
index 00..91e5cd8dcf
--- /dev/null
+++ b/board/Marvell/mvebu_armada-37xx/mac/hw_info.c
@@ -0,0 +1,391 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Marvell hw_info (mac) command implementation
+ * Helper command for interfacing with the Marvell hw_info parameters
+ *
+ * Copyright (c) 2021 Sartura Ltd.
+ * Copyright (c) 2018 Marvell International Ltd.
+ *
+ * Author: Luka Kovacic 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define HW_INFO_SPI_FLASH_OFFSET   CONFIG_MVEBU_MAC_HW_INFO_OFFSET
+
+#define HW_INFO_MAX_ENV_SIZE   0x1F0
+#define HW_INFO_ENV_OFFSET 0xA
+#define HW_INFO_ENV_SEP0x20
+
+#define HW_INFO_MAX_NAME_LEN   32
+
+#define HW_INFO_MERGED_VARIABLE"read_board_hw_info"
+
+static char hw_info_allowed_parameters[][HW_INFO_MAX_NAME_LEN] = {
+   "pcb_slm",
+   "pcb_rev",
+   "eco_rev",
+   "pcb_sn",
+   

[PATCH v3 3/3] arm: mvebu: Initial ESPRESSOBin-Ultra board support

[Luka Kovacic]

Add initial support for the ESPRESSOBin-Ultra board from Globalscale
Technologies, Inc.

The board is based on the 64-bit dual-core Marvell Armada 3720 SoC.
Peripherals:
 - 5 Gigabit Ethernet ports (WAN has PoE, up to 30W, Topaz 6341 switch)
 - RTC clock (PCF8563)
 - USB 3.0 port
 - USB 2.0 port
 - 4x LED
 - UART over Micro-USB
 - M.2 slot (2280)
 - Mini PCI-E slot

Additionally, automatic import of the Marvell hw_info parameters is
enabled via the recently added mac command for A37XX platforms.
The parameters stored in Marvell hw_info are usually the board serial
number and MAC addresses.

Signed-off-by: Luka Kovacic 
Cc: Luka Perkov 
Cc: Robert Marko 
---
 arch/arm/dts/Makefile |   1 +
 .../arm/dts/armada-3720-espressobin-ultra.dts | 114 ++
 arch/arm/dts/armada-3720-espressobin.dts  | 199 +
 arch/arm/dts/armada-3720-espressobin.dtsi | 210 ++
 board/Marvell/mvebu_armada-37xx/MAINTAINERS   |   8 +
 board/Marvell/mvebu_armada-37xx/board.c   |  92 +++-
 .../mvebu_espressobin-ultra-88f3720_defconfig |  93 
 7 files changed, 514 insertions(+), 203 deletions(-)
 create mode 100644 arch/arm/dts/armada-3720-espressobin-ultra.dts
 create mode 100644 arch/arm/dts/armada-3720-espressobin.dtsi
 create mode 100644 configs/mvebu_espressobin-ultra-88f3720_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index c42715ead4..f21c9c94d3 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -213,6 +213,7 @@ dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
 dtb-$(CONFIG_ARCH_MVEBU) +=\
armada-3720-db.dtb  \
armada-3720-espressobin.dtb \
+   armada-3720-espressobin-ultra.dtb   \
armada-3720-turris-mox.dtb  \
armada-3720-uDPU.dtb\
armada-375-db.dtb   \
diff --git a/arch/arm/dts/armada-3720-espressobin-ultra.dts 
b/arch/arm/dts/armada-3720-espressobin-ultra.dts
new file mode 100644
index 00..5ad0c723e3
--- /dev/null
+++ b/arch/arm/dts/armada-3720-espressobin-ultra.dts
@@ -0,0 +1,114 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree file for ESPRESSObin-Ultra board
+ * Copyright (C) 2016 Marvell
+ * Copyright (C) 2019 Globalscale technologies, Inc.
+ * Copyright (C) 2021 Sartura Ltd.
+ *
+ * Author: Jason Hung 
+ * Author: Luka Kovacic 
+ * Author: Vladimir Vid 
+ */
+
+/dts-v1/;
+
+#include "armada-3720-espressobin.dtsi"
+
+/ {
+   model = "Globalscale Marvell ESPRESSOBin Ultra Board";
+   compatible = "globalscale,espressobin-ultra", "marvell,armada3720", 
"marvell,armada3710";
+
+   gpio-leds {
+   pinctrl-names = "default";
+   pinctrl-0 = <&led1_pins>, <&led2_pins>, <&led3_pins>, 
<&led4_pins>;
+   compatible = "gpio-leds";
+
+   led1 {
+   label = "led1";
+   gpios = <&gpionb 11 GPIO_ACTIVE_LOW>;
+   default-state = "on";
+   };
+   led2 {
+   label = "led2";
+   gpios = <&gpionb 12 GPIO_ACTIVE_LOW>;
+   default-state = "on";
+   };
+   led3 {
+   label = "led3";
+   gpios = <&gpionb 13 GPIO_ACTIVE_LOW>;
+   default-state = "on";
+   };
+   led4 {
+   label = "led4";
+   gpios = <&gpionb 14 GPIO_ACTIVE_LOW>;
+   default-state = "on";
+   };
+   };
+};
+
+&pinctrl_nb {
+   led1_pins: led1-pins {
+   groups = "pwm0";
+   function = "gpio";
+   };
+   led2_pins: led2-pins {
+   groups = "pwm1";
+   function = "gpio";
+   };
+   led3_pins: led3-pins {
+   groups = "pwm2";
+   function = "gpio";
+   };
+   led4_pins: led4-pins {
+   groups = "pwm3";
+   function = "gpio";
+   };
+};
+
+ð0 {
+   status = "okay";
+   phy_addr = <0x3>;
+};
+
+&i2c0 {
+   status = "okay";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   rtc@51 {
+   compatible = "nxp,pcf8563";
+   reg = <0x51>;
+   };
+};
+
+&sata {
+   status = "okay";
+};
+
+&sdhci0 {
+   status = "disabled";
+};
+
+&sdhci1 {
+   status = "okay";
+};
+
+&spi0 {
+   status = "okay";
+};
+
+/* Exported on the micro USB connector through an FTDI */
+&uart0 {
+   status = "okay";
+};
+
+&usb2 {
+   status = "okay";
+};
+
+&usb3 {
+   status = "okay";
+};
+
+&pcie0 {
+   status = "okay";
+};
diff --git a/arch/arm/dts/armada-3720-espressobin.dts 
b/arch/arm/dts/armada-3720-espressobin.dts
index cba6139be6..925ce6a38e 100644
--- a/arch/arm/dts/armada-3720-espressobin.dts
+++ b/arch/arm/dts/armada-372

Re: Hints on how to use efi_driver/efi_block_device.c

[Heinrich Schuchardt]

On 8/12/21 11:49 PM, Simon Glass wrote:

+Heinrich Schuchardt too

On Thu, 12 Aug 2021 at 08:35, Christian Melki
 wrote:


I was hoping that U-boot would detect BLOCK_IO devices provided by UEFI
automatically. But I can't see anything attached under lsblk or find
some other information about this.
For example, Barebox works just fine on both Virtualbox and real
hardware in this regard.

Barebox does not have an emmc driver for the real hardware but
piggybacks off the UEFI protocol for this.


Hello Christian,

U-Boot can be used in two scenarios:

1) U-Boot is the firmware providing the UEFI API
2) U-Boot is running as an application consuming the UEFI API.

Barebox only supports scenario 2).



I'm sure that the idea with this U-boot driver is something like that,
but would appreciate some hints on how to use it.


efi_driver/efi_block_device.c is used in scenario 1).

When a UEFI payload like iPXE provides an EFI_BLOCK_IO_PROTOCOL on a
handle and calls ConnectController() U-Boot will install the
EFI_SIMPLE_FILE_PROTOCOL for each partition on the block device.

You can find a detailed description of this use case in:

* https://u-boot.readthedocs.io/en/latest/develop/uefi/iscsi.html
* https://archive.fosdem.org/2020/schedule/event/firmware_duwu/



Ie, standard usage. UEFI boots of a drive, posts some handles(?) to a
block device and U-boot picks it up, not knowing more about the
abstracted hardware.


Here you seem be referring to scenario 2).

For scenario 2) support for UEFI block devices has not been implemented,
yet. As operating systems like Linux, BSD, Windows all can be booted via
UEFI there has not been any use case driving further development of this
scenario.

Please, describe what you want to do with U-Boot.

Best regards

Heinrich

Re: [PATCH 1/2] x86: crownbay: Enable SeaBIOS support

[Bin Meng]

On Fri, Aug 13, 2021 at 5:46 AM Simon Glass  wrote:
>
> On Tue, 3 Aug 2021 at 06:50, Bin Meng  wrote:
> >
> > Enable SeaBIOS support for any kernel that requires legacy BIOS
> > services.
> >
> > Signed-off-by: Bin Meng 
> > ---
> >
> >  configs/crownbay_defconfig | 1 +
> >  1 file changed, 1 insertion(+)
> >
>
> Reviewed-by: Simon Glass 

applied to u-boot-x86, thanks!

Re: [PATCH 2/2] doc: x86: Update SeaBIOS build instructions

[Bin Meng]

On Fri, Aug 13, 2021 at 5:46 AM Simon Glass  wrote:
>
> On Tue, 3 Aug 2021 at 06:50, Bin Meng  wrote:
> >
> > Update SeaBIOS build instructions using exact command that involves
> > "make olddefconfig", and mention SeaBIOS release 1.14.0 has been
> > used for testing.
> >
> > Signed-off-by: Bin Meng 
> > ---
> >
> >  doc/arch/x86.rst | 21 -
> >  1 file changed, 8 insertions(+), 13 deletions(-)
>
> Reviewed-by: Simon Glass 

applied to u-boot-x86, thanks!

Re: [PATCH] x86: crownbay: Enable CONFIG_SPI_FLASH_SMART_HWCAPS

[Bin Meng]

On Fri, Aug 13, 2021 at 5:46 AM Simon Glass  wrote:
>
> On Tue, 3 Aug 2021 at 21:53, Bin Meng  wrote:
> >
> > Now that the spi-nor fix has been made in u-boot/master via:
> >
> >   commit 87e7219f9c6a ("mtd: spi-nor: Respect flash's hwcaps in 
> > spi_nor_adjust_hwcaps()")
> >
> > enable CONFIG_SPI_FLASH_SMART_HWCAPS on Intel Crown Bay again.
> >
> > Signed-off-by: Bin Meng 
> > ---
> >
> >  configs/crownbay_defconfig | 1 -
> >  1 file changed, 1 deletion(-)
>
> Reviewed-by: Simon Glass 

applied to u-boot-x86, thanks!

[PATCH 1/2] imx8mm-cl-iot-gate: Do not build fip.bin by default

[Fabio Estevam]

When trying to build the imx8mm-cl-iot-gate_defconfig target there is a
build error due to the missing 'fip.bin'.

To make the build process more consistent with other i.MX8M boards,
do not build fip.bin by default.

Signed-off-by: Fabio Estevam 
---
 arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi 
b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
index 3226a244a97e..00927c157449 100644
--- a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
@@ -217,18 +217,6 @@
};
};
 
-   fip {
-   description = "Trusted Firmware FIP";
-   type = "firmware";
-   arch = "arm64";
-   compression = "none";
-   load = <0x4031>;
-
-   fip_blob: blob-ext{
-   filename = "fip.bin";
-   };
-   };
-
fdt {
description = "NAME";
type = "flat_dt";
@@ -246,7 +234,7 @@
conf {
description = "NAME";
firmware = "uboot";
-   loadables = "atf", "fip";
+   loadables = "atf";
fdt = "fdt";
};
};
-- 
2.25.1

[PATCH 2/2] imx8mm-cl-iot-gate: Add documentation

[Fabio Estevam]

Add documentation for building and flashing mainline U-Boot
in the IOT-GATE-iMX8 board.

Signed-off-by: Fabio Estevam 
---
 doc/board/compulab/imx8mm-cl-iot-gate.rst | 84 +++
 doc/board/index.rst   |  1 +
 2 files changed, 85 insertions(+)
 create mode 100644 doc/board/compulab/imx8mm-cl-iot-gate.rst

diff --git a/doc/board/compulab/imx8mm-cl-iot-gate.rst 
b/doc/board/compulab/imx8mm-cl-iot-gate.rst
new file mode 100644
index ..b63b8d61f13f
--- /dev/null
+++ b/doc/board/compulab/imx8mm-cl-iot-gate.rst
@@ -0,0 +1,83 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+IOT-GATE-iMX8
+=
+
+U-Boot for Compulab i.MX8MM IoT Gateway board.
+
+Quick Start
+---
+
+- Build the ARM Trusted firmware binary
+- Get the DDR firmwares
+- Build U-Boot
+- Flash U-Boot into the eMMC
+
+Get and build the ARM Trusted firmware
+--
+
+Note: builddir is U-Boot build directory (source directory for in-tree builds).
+
+Get mainline ATF:
+
+.. code-block:: bash
+
+   $ git clone https://github.com/ARM-software/arm-trusted-firmware.git
+   $ cd arm-trusted-firmware
+   $ git checkout v2.5
+
+Generate the bl31.bin ATF binary:
+
+.. code-block:: bash
+
+   $ export CROSS_COMPILE=aarch64-poky-linux-
+   $ make PLAT=imx8mm IMX_BOOT_UART_BASE=0x3088 bl31
+   $ cp build/imx8mm/release/bl31.bin $(builddir)
+
+Get the DDR firmwares
+-
+
+.. code-block:: bash
+
+   $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.9.bin
+   $ chmod +x firmware-imx-8.9.bin
+   $ ./firmware-imx-8.9
+   $ cp firmware-imx-8.9/firmware/ddr/synopsys/lpddr4*.bin $(builddir)
+
+Build U-Boot
+
+
+.. code-block:: bash
+
+   $ export CROSS_COMPILE=aarch64-poky-linux-
+   $ make imx8mm-cl-iot-gate_defconfig
+   $ export ATF_LOAD_ADDR=0x92
+   $ make
+
+This will result in two binaries: flash.bin and u-boot.itb.
+
+Flash U-Boot into the eMMC
+--
+
+Make sure to have access to the IOTG-ACC-M2SD adapter to recover
+the board in case something goes wrong. More details at:
+https://mediawiki.compulab.com/w/index.php?title=IOT-GATE-iMX8_and_SBC-IOT-iMX8:_U-Boot:_Recovery
+
+The flash.bin and u-boot.itb binaries need to be flashed into the eMMC at
+offset 33K and 384K, respectively.
+
+These binaries can be transferred from the host PC to the board running
+U-Boot via TFTP:
+
+.. code-block:: bash
+
+   => mmc dev 2
+   => mmc partconf 2 1 7 0 (This is only needed to be done for the first time)
+
+   => tftp $loadaddr flash.bin
+   => setexpr blkcnt $filesize + 0x1ff && setexpr blkcnt $blkcnt / 0x200
+   => mmc write $loadaddr 0x42 $blkcnt
+
+   => tftp $loadaddr u-boot.itb
+   => setexpr blkcnt $filesize + 0x1ff && setexpr blkcnt $blkcnt / 0x200
+   => mmc write $loadaddr 0x300 $blkcnt
diff --git a/doc/board/index.rst b/doc/board/index.rst
index 9e9097889161..5c5420f3d75a 100644
--- a/doc/board/index.rst
+++ b/doc/board/index.rst
@@ -11,6 +11,7 @@ Board-specific doc
AndesTech/index
amlogic/index
atmel/index
+   compulab/index
congatec/index
coreboot/index
emulation/index
-- 
2.25.1

Re: [PATCH 05/23] serial: Add a SERIAL config

[Sean Anderson]

On 8/8/21 2:20 PM, Simon Glass wrote:

At present we have SPL_SERIAL and TPL_SERIAL but not piain SERIAL. This


nit: plain

I believe this typo occurs in several other patches in this series as well, 
e.g. GPIO and POWER.

--Sean


works because there is a special build rule in Makefile that always
includes the drivers/serial directory.

It is better to have all driver directories included by drivers/Makefile
and there is already a rule in there for this purpose. It just needs a
Kconfig for U-Boot proper, so add one.

It is always enabled, for now, since that mimics the current behaviour.
It should be possible to drop the strange 'SERIAL_PRESENT' option at some
point and use SERIAL instead.

Signed-off-by: Simon Glass 
---

  Makefile   |  1 -
  drivers/serial/Kconfig | 15 +--
  2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 269e353a28a..653df0d2731 100644
--- a/Makefile
+++ b/Makefile
@@ -829,7 +829,6 @@ libs-$(CONFIG_FMAN_ENET) += drivers/net/fm/
  libs-$(CONFIG_SYS_FSL_DDR) += drivers/ddr/fsl/
  libs-$(CONFIG_SYS_FSL_MMDC) += drivers/ddr/fsl/
  libs-$(CONFIG_$(SPL_)ALTERA_SDRAM) += drivers/ddr/altera/
-libs-y += drivers/serial/
  libs-y += drivers/usb/cdns3/
  libs-y += drivers/usb/dwc3/
  libs-y += drivers/usb/common/
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 93348c0929c..205c9ddc442 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -2,7 +2,18 @@
  # Serial device configuration
  #
  
-menu "Serial drivers"

+menuconfig SERIAL
+   bool "Serial"
+   default y
+   help
+ Enable support for serial drivers. This allows use of a serial UART
+ for displaying messages while U-Boot is running. It also brings in
+ printf() and panic() functions. This should normally be enabled
+ unless there are space reasons not to. If you just need to disable
+ the console you can adjust the stdout environment variable or use
+ SILENT_CONSOLE.
+
+if SERIAL
  
  config BAUDRATE

int "Default baudrate"
@@ -939,4 +950,4 @@ config SYS_SDMR
depends on MPC8XX_CONS
default 0
  
-endmenu

+endif

Re: Hints on how to use efi_driver/efi_block_device.c

[AKASHI Takahiro]

On Thu, Aug 12, 2021 at 04:34:01PM +0200, Christian Melki wrote:
> I was hoping that U-boot would detect BLOCK_IO devices provided by UEFI
> automatically. But I can't see anything attached under lsblk or find some
> other information about this.

I'm not sure what you intend to do here, but please try
the commands, "efidebug devices" and/or "efidebug dh"
to find out what you're looking for.

Please note that you have to enumerate (block) devices
in advance with, say, "mmc rescan", "scsi scan" (and
probably "virtio scan" as well).

-Takahiro Akashi

> For example, Barebox works just fine on both Virtualbox and real hardware in
> this regard.
> 
> Barebox does not have an emmc driver for the real hardware but piggybacks
> off the UEFI protocol for this.
> 
> I'm sure that the idea with this U-boot driver is something like that, but
> would appreciate some hints on how to use it.
> 
> Ie, standard usage. UEFI boots of a drive, posts some handles(?) to a block
> device and U-boot picks it up, not knowing more about the abstracted
> hardware.
> 
> Best regards,
> Christian

Re: [PATCH 1/1] riscv: show code leading to exception

[Sean Anderson]

On 8/12/21 2:25 PM, Heinrich Schuchardt wrote:

To make analyzing exceptions easier output the code that leads to it.
We already do the same on the ARM platform.

Here is an example:

 => exception ebreak
 Unhandled exception: Breakpoint
 EPC: 8ff5d50e RA: 8ff5d62c TVAL: 
 EPC: 8020b50e RA: 8020b62c reloc adjusted

 Code: 2785 0693 07a0 dce3 fef6 47a5 d563 00e7 (9002)

To disassemble the code we can use the decodecode script:

 $ echo 'Code: 2785 0693 07a0 dce3 fef6 47a5 d563 00e7 (9002)' | \
   CROSS_COMPILE=riscv64-linux-gnu- scripts/decodecode

 Code: 2785 0693 07a0 dce3 fef6 47a5 d563 00e7 (9002)
 All code
 
0:   2785addiw   a5,a5,1
2:   07a00693li  a3,122
6:   fef6dce3bge a3,a5,0xfffe
a:   47a5li  a5,9
c:   00e7d563bge a5,a4,0x16
   10:*  9002ebreak <-- trapping instruction
 ...

 Code starting with the faulting instruction
 ===
0:   9002ebreak
 ...

As it is not always clear if the first 16 bits are at the start or in the
middle of a 32bit instruction it may become necessary to strip the first
u16 from the output before calling decodecode to get the correct
disassembled code.

Signed-off-by: Heinrich Schuchardt 
---
  arch/riscv/lib/interrupts.c | 42 +
  1 file changed, 42 insertions(+)

diff --git a/arch/riscv/lib/interrupts.c b/arch/riscv/lib/interrupts.c
index 7525c152b8..31b8a6603c 100644
--- a/arch/riscv/lib/interrupts.c
+++ b/arch/riscv/lib/interrupts.c
@@ -51,6 +51,47 @@ static void show_regs(struct pt_regs *regs)
  #endif
  }

+/**
+ * instr_len() - get instruction length
+ *
+ * @i: low 16 bits of the instruction
+ * Return: number of u16 in instruction
+ */
+static int instr_len(u16 i)
+{
+   if ((i & 0x03) != 0x03)
+   return 1;
+   if ((i & 0x1c) != 0x1c)


Shouldn't this be 1f?

And TBH I would not bother dealing with >48-bit instructions, as not
even 48-bit instructions have been standardized (with the closest
candidate being [1] AFAIK). That would allow for simplification to

i &= 0b1;
if (i == 0b01)
return 3;

i &= 0b11;
if (i == 0b11)
return 2;
return 1;

If we ever see a 64-bit instruction, we can come back and modify this.

--Sean

[1] 
https://github.com/riscv/riscv-code-size-reduction/blob/master/ISA%20proposals/Huawei/48bit_encodings.adoc


+   return 2;
+   if ((i & 0x3f) == 0x1f)
+   return 3;
+   if ((i & 0x7f) == 0x3f)
+   return 4;
+   i = (i >> 12) & 0x07;
+   if (i < 7)
+   return i + 5;
+   /* Encoding for >= 192 bits is not yet defined */
+   return 1;
+}
+
+/**
+ * show_code() - display code leading to exception
+ *
+ * @epc:   program counter
+ */
+static void show_code(ulong epc)
+{
+   u16 *pos = (u16 *)(epc & ~1UL);
+   int i, len = instr_len(*pos);
+
+   printf("\nCode: ");
+   for (i = -8; i; ++i)
+   printf("%04x ", pos[i]);
+   printf("(");
+   for (i = 0; i < len; ++i)
+   printf("%04x%s", pos[i], i + 1 == len ? ")\n" : " ");
+}
+
  static void _exit_trap(ulong code, ulong epc, ulong tval, struct pt_regs 
*regs)
  {
static const char * const exception_code[] = {
@@ -85,6 +126,7 @@ static void _exit_trap(ulong code, ulong epc, ulong tval, 
struct pt_regs *regs)
   epc - gd->reloc_off, regs->ra - gd->reloc_off);

show_regs(regs);
+   show_code(epc);
show_efi_loaded_images(epc);
panic("\n");
  }
--
2.30.2

Re: [PATCH v3 1/3] arm: mvebu: mvebu_armada-37xx: Implement the mac command (Marvell hw_info)

[Marek Behún]

On Fri, 13 Aug 2021 01:39:36 +0200
Luka Kovacic  wrote:

> The mac command is implemented to enable parsing Marvell hw_info formatted
> environments. This format is often used on Marvell Armada A37XX based
> devices to store parameters like the board serial number, factory
> MAC addresses and some other information.
> These parameters are usually written to the flash in the factory.
> 
> Currently the mac command supports reading/writing parameters and dumping
> the current hw_info parameters.
> EEPROM config pattern and checksum aren't supported.
> 
> This functionality has been tested on the GST ESPRESSOBin-Ultra board
> successfully, both reading the stock U-Boot parameters in mainline U-Boot
> and reading the parameters written by this command in the stock U-Boot.
> 
> Usage example:
>  => mac read
>  => saveenv  

I think the mac/fuse commands should be killed and nvmem API should be
implemented as is in Linux, with a corresponding nvmem command.

Marek

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

[Jon Lin]

Here is the point, Can you take a try.

diff --git a/drivers/spi/rockchip_sfc.c b/drivers/spi/rockchip_sfc.c
index 8173724ecd..33c5344c70 100644
--- a/drivers/spi/rockchip_sfc.c
+++ b/drivers/spi/rockchip_sfc.c
@@ -591,7 +591,7 @@ static int rockchip_sfc_adjust_op_size(struct 
spi_slave *mem, struct spi_mem_op


 static int rockchip_sfc_set_speed(struct udevice *bus, uint speed)
 {
-   struct rockchip_sfc *sfc = dev_get_priv(bus);
+   struct rockchip_sfc *sfc = dev_get_plat(bus);
    int ret;

    if (speed > sfc->max_freq)
@@ -609,7 +609,7 @@ static int rockchip_sfc_set_speed(struct udevice 
*bus, uint speed)

    }
    sfc->speed = speed;
 #else
-   dev_dbg(sfc->dev, "sfc failed, CLK not support\n", __func__);
+   dev_dbg(sfc->dev, "sfc failed, CLK not support\n");
 #endif
    return 0;
 }


On 2021/8/13 3:13, Chris Morgan wrote:

On Thu, Aug 12, 2021 at 09:15:14PM +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 
---


I'll need to debug it further, but unfortunately this is not working
for me. On my Odroid Go Advance I get a "Synchronous Abort" error when
I attempt to do an "sf probe". This same sequence (boot, then do sf
probe) has worked on all prior revisions without a crash.

U-Boot TPL board init
DDR3, 333MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
out

U-Boot SPL 2021.10-rc1+ (Aug 12 2021 - 14:03:30 -0500)
Trying to boot from MMC1
NOTICE:  BL31: v2.5(release):v2.5-284-g87311b4c1
NOTICE:  BL31: Built : 10:43:59, Aug  5 2021


U-Boot 2021.10-rc1+ (Aug 12 2021 - 14:03:30 -0500)

Model: ODROID-GO Advance
DRAM:  1022 MiB
PMIC:  RK8170 (on=0x80, off=0x04)
MMC:   dwmmc@ff37: 0
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
In:serial@ff16
Out:   serial@ff16
Err:   serial@ff16
Model: ODROID-GO Advance
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
MMC Device 1 not found
no mmc device at slot 1
starting USB...
Bus usb@ff30: probe failed, error -2
No working controllers found
USB is stopped. Please issue 'usb start' first.
=> sf probe
"Synchronous Abort" handler, esr 0x9610
elr: 0022d730 lr : 0022d72c (reloc)
elr: 3ff85730 lr : 3ff8572c
x0 :  x1 : 066ff300
x2 : 3ff85714 x3 : 
x4 : 3ffccd1d x5 : 006e
x6 : 3ffba6d8 x7 : 0044
x8 : 000a x9 : 0008
x10: 0034 x11: 0003
x12:  x13: ffd8
x14: 3df485d0 x15: 0002
x16: 3ff8ebe8 x17: 0001
x18: 3df53dd0 x19: 066ff300
x20:  x21: 066ff300
x22: 3ffbdef8 x23: 1000
x24: 3df6f530 x25: 3df92e90
x26: 3ffeecc0 x27: 
x28: 0003 x29: 3df481c0

Code: f90013f5 2a0103f5 94003427 aa0003f4 (294c0013)
Resetting CPU ...

resetting ...



Changes in v8:
- Move speed operation to set_speed logic
- Use read_poll
- Change debug to dev_dbg
- Simply exec_op dma logic

Changes in v7:
- Make sfc-use-dma configurable

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 fr

Re: [PATCH 1/1] riscv: show code leading to exception

[Heinrich Schuchardt]

Am 13. August 2021 03:34:58 MESZ schrieb Sean Anderson :
>On 8/12/21 2:25 PM, Heinrich Schuchardt wrote:
>> To make analyzing exceptions easier output the code that leads to it.
>> We already do the same on the ARM platform.
>> 
>> Here is an example:
>> 
>>  => exception ebreak
>>  Unhandled exception: Breakpoint
>>  EPC: 8ff5d50e RA: 8ff5d62c TVAL: 
>>  EPC: 8020b50e RA: 8020b62c reloc adjusted
>> 
>>  Code: 2785 0693 07a0 dce3 fef6 47a5 d563 00e7 (9002)
>> 
>> To disassemble the code we can use the decodecode script:
>> 
>>  $ echo 'Code: 2785 0693 07a0 dce3 fef6 47a5 d563 00e7 (9002)' | \
>>CROSS_COMPILE=riscv64-linux-gnu- scripts/decodecode
>> 
>>  Code: 2785 0693 07a0 dce3 fef6 47a5 d563 00e7 (9002)
>>  All code
>>  
>> 0:   2785addiw   a5,a5,1
>> 2:   07a00693li  a3,122
>> 6:   fef6dce3bge a3,a5,0xfffe
>> a:   47a5li  a5,9
>> c:   00e7d563bge a5,a4,0x16
>>10:*  9002ebreak <-- trapping instruction
>>  ...
>> 
>>  Code starting with the faulting instruction
>>  ===
>> 0:   9002ebreak
>>  ...
>> 
>> As it is not always clear if the first 16 bits are at the start or in the
>> middle of a 32bit instruction it may become necessary to strip the first
>> u16 from the output before calling decodecode to get the correct
>> disassembled code.
>> 
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>>   arch/riscv/lib/interrupts.c | 42 +
>>   1 file changed, 42 insertions(+)
>> 
>> diff --git a/arch/riscv/lib/interrupts.c b/arch/riscv/lib/interrupts.c
>> index 7525c152b8..31b8a6603c 100644
>> --- a/arch/riscv/lib/interrupts.c
>> +++ b/arch/riscv/lib/interrupts.c
>> @@ -51,6 +51,47 @@ static void show_regs(struct pt_regs *regs)
>>   #endif
>>   }
>> 
>> +/**
>> + * instr_len() - get instruction length
>> + *
>> + * @i:  low 16 bits of the instruction
>> + * Return:  number of u16 in instruction
>> + */
>> +static int instr_len(u16 i)
>> +{
>> +if ((i & 0x03) != 0x03)
>> +return 1;
>> +if ((i & 0x1c) != 0x1c)
>
>Shouldn't this be 1f?

We already know that bits 0 and 1 are set here. We only have to check that not 
all of bits 2 - 4 are set. 

>
>And TBH I would not bother dealing with >48-bit instructions, as not
>even 48-bit instructions have been standardized (with the closest
>candidate being [1] AFAIK). That would allow for simplification to
>
>   i &= 0b1;
>   if (i == 0b01)
>   return 3;
>
>   i &= 0b11;
>   if (i == 0b11)
>   return 2;
>   return 1;
>
>If we ever see a 64-bit instruction, we can come back and modify this.

Won't extending [1] to load 64 bit values result in 80 bit instructions?

Best regards

Heinrich

>
>--Sean
>
>[1] 
>https://github.com/riscv/riscv-code-size-reduction/blob/master/ISA%20proposals/Huawei/48bit_encodings.adoc
>
>> +return 2;
>> +if ((i & 0x3f) == 0x1f)
>> +return 3;
>> +if ((i & 0x7f) == 0x3f)
>> +return 4;
>> +i = (i >> 12) & 0x07;
>> +if (i < 7)
>> +return i + 5;
>> +/* Encoding for >= 192 bits is not yet defined */
>> +return 1;
>> +}
>> +
>> +/**
>> + * show_code() - display code leading to exception
>> + *
>> + * @epc:program counter
>> + */
>> +static void show_code(ulong epc)
>> +{
>> +u16 *pos = (u16 *)(epc & ~1UL);
>> +int i, len = instr_len(*pos);
>> +
>> +printf("\nCode: ");
>> +for (i = -8; i; ++i)
>> +printf("%04x ", pos[i]);
>> +printf("(");
>> +for (i = 0; i < len; ++i)
>> +printf("%04x%s", pos[i], i + 1 == len ? ")\n" : " ");
>> +}
>> +
>>   static void _exit_trap(ulong code, ulong epc, ulong tval, struct pt_regs 
>> *regs)
>>   {
>>  static const char * const exception_code[] = {
>> @@ -85,6 +126,7 @@ static void _exit_trap(ulong code, ulong epc, ulong tval, 
>> struct pt_regs *regs)
>> epc - gd->reloc_off, regs->ra - gd->reloc_off);
>> 
>>  show_regs(regs);
>> +show_code(epc);
>>  show_efi_loaded_images(epc);
>>  panic("\n");
>>   }
>> --
>> 2.30.2
>> 
>

Re: [PATCH 1/1] riscv: show code leading to exception

[Sean Anderson]

Am 13. August 2021 03:34:58 MESZ schrieb Sean Anderson :

On 8/12/21 2:25 PM, Heinrich Schuchardt wrote:

To make analyzing exceptions easier output the code that leads to it.
We already do the same on the ARM platform.

Here is an example:

 => exception ebreak
 Unhandled exception: Breakpoint
 EPC: 8ff5d50e RA: 8ff5d62c TVAL: 
 EPC: 8020b50e RA: 8020b62c reloc adjusted

 Code: 2785 0693 07a0 dce3 fef6 47a5 d563 00e7 (9002)

To disassemble the code we can use the decodecode script:

 $ echo 'Code: 2785 0693 07a0 dce3 fef6 47a5 d563 00e7 (9002)' | \
   CROSS_COMPILE=riscv64-linux-gnu- scripts/decodecode

 Code: 2785 0693 07a0 dce3 fef6 47a5 d563 00e7 (9002)
 All code
 
0:   2785addiw   a5,a5,1
2:   07a00693li  a3,122
6:   fef6dce3bge a3,a5,0xfffe
a:   47a5li  a5,9
c:   00e7d563bge a5,a4,0x16
   10:*  9002ebreak <-- trapping instruction
 ...

 Code starting with the faulting instruction
 ===
0:   9002ebreak
 ...

As it is not always clear if the first 16 bits are at the start or in the
middle of a 32bit instruction it may become necessary to strip the first
u16 from the output before calling decodecode to get the correct
disassembled code.

Signed-off-by: Heinrich Schuchardt 
---
  arch/riscv/lib/interrupts.c | 42 +
  1 file changed, 42 insertions(+)

diff --git a/arch/riscv/lib/interrupts.c b/arch/riscv/lib/interrupts.c
index 7525c152b8..31b8a6603c 100644
--- a/arch/riscv/lib/interrupts.c
+++ b/arch/riscv/lib/interrupts.c
@@ -51,6 +51,47 @@ static void show_regs(struct pt_regs *regs)
  #endif
  }

+/**
+ * instr_len() - get instruction length
+ *
+ * @i: low 16 bits of the instruction
+ * Return: number of u16 in instruction
+ */
+static int instr_len(u16 i)
+{
+   if ((i & 0x03) != 0x03)
+   return 1;
+   if ((i & 0x1c) != 0x1c)


Shouldn't this be 1f?


We already know that bits 0 and 1 are set here. We only have to check that not 
all of bits 2 - 4 are set.



And TBH I would not bother dealing with >48-bit instructions, as not
even 48-bit instructions have been standardized (with the closest
candidate being [1] AFAIK). That would allow for simplification to

i &= 0b1;
if (i == 0b01)
return 3;

i &= 0b11;
if (i == 0b11)
return 2;
return 1;

If we ever see a 64-bit instruction, we can come back and modify this.


Won't extending [1] to load 64 bit values result in 80 bit instructions?

Best regards

Heinrich



--Sean

[1] 
https://github.com/riscv/riscv-code-size-reduction/blob/master/ISA%20proposals/Huawei/48bit_encodings.adoc


+   return 2;
+   if ((i & 0x3f) == 0x1f)
+   return 3;
+   if ((i & 0x7f) == 0x3f)
+   return 4;
+   i = (i >> 12) & 0x07;
+   if (i < 7)
+   return i + 5;
+   /* Encoding for >= 192 bits is not yet defined */
+   return 1;
+}
+
+/**
+ * show_code() - display code leading to exception
+ *
+ * @epc:   program counter
+ */
+static void show_code(ulong epc)
+{
+   u16 *pos = (u16 *)(epc & ~1UL);
+   int i, len = instr_len(*pos);
+
+   printf("\nCode: ");
+   for (i = -8; i; ++i)
+   printf("%04x ", pos[i]);
+   printf("(");
+   for (i = 0; i < len; ++i)
+   printf("%04x%s", pos[i], i + 1 == len ? ")\n" : " ");
+}
+
  static void _exit_trap(ulong code, ulong epc, ulong tval, struct pt_regs 
*regs)
  {
static const char * const exception_code[] = {
@@ -85,6 +126,7 @@ static void _exit_trap(ulong code, ulong epc, ulong tval, 
struct pt_regs *regs)
   epc - gd->reloc_off, regs->ra - gd->reloc_off);

show_regs(regs);
+   show_code(epc);
show_efi_loaded_images(epc);
panic("\n");
  }
--
2.30.2

Re: [PATCH 1/1] riscv: show code leading to exception

[Sean Anderson]

On 8/12/21 10:25 PM, Heinrich Schuchardt wrote:

Am 13. August 2021 03:34:58 MESZ schrieb Sean Anderson :

On 8/12/21 2:25 PM, Heinrich Schuchardt wrote:

To make analyzing exceptions easier output the code that leads to it.
We already do the same on the ARM platform.

Here is an example:

  => exception ebreak
  Unhandled exception: Breakpoint
  EPC: 8ff5d50e RA: 8ff5d62c TVAL: 
  EPC: 8020b50e RA: 8020b62c reloc adjusted

  Code: 2785 0693 07a0 dce3 fef6 47a5 d563 00e7 (9002)

To disassemble the code we can use the decodecode script:

  $ echo 'Code: 2785 0693 07a0 dce3 fef6 47a5 d563 00e7 (9002)' | \
CROSS_COMPILE=riscv64-linux-gnu- scripts/decodecode

  Code: 2785 0693 07a0 dce3 fef6 47a5 d563 00e7 (9002)
  All code
  
 0:   2785addiw   a5,a5,1
 2:   07a00693li  a3,122
 6:   fef6dce3bge a3,a5,0xfffe
 a:   47a5li  a5,9
 c:   00e7d563bge a5,a4,0x16
10:*  9002ebreak <-- trapping instruction
  ...

  Code starting with the faulting instruction
  ===
 0:   9002ebreak
  ...

As it is not always clear if the first 16 bits are at the start or in the
middle of a 32bit instruction it may become necessary to strip the first
u16 from the output before calling decodecode to get the correct
disassembled code.

Signed-off-by: Heinrich Schuchardt 
---
   arch/riscv/lib/interrupts.c | 42 +
   1 file changed, 42 insertions(+)

diff --git a/arch/riscv/lib/interrupts.c b/arch/riscv/lib/interrupts.c
index 7525c152b8..31b8a6603c 100644
--- a/arch/riscv/lib/interrupts.c
+++ b/arch/riscv/lib/interrupts.c
@@ -51,6 +51,47 @@ static void show_regs(struct pt_regs *regs)
   #endif
   }

+/**
+ * instr_len() - get instruction length
+ *
+ * @i: low 16 bits of the instruction
+ * Return: number of u16 in instruction
+ */
+static int instr_len(u16 i)
+{
+   if ((i & 0x03) != 0x03)
+   return 1;
+   if ((i & 0x1c) != 0x1c)


Shouldn't this be 1f?


We already know that bits 0 and 1 are set here. We only have to check that not 
all of bits 2 - 4 are set.


*shrug* It's one instruction anyway and it helps clarity.





And TBH I would not bother dealing with >48-bit instructions, as not
even 48-bit instructions have been standardized (with the closest
candidate being [1] AFAIK). That would allow for simplification to

i &= 0b1;
if (i == 0b01)
return 3;

i &= 0b11;
if (i == 0b11)
return 2;
return 1;

If we ever see a 64-bit instruction, we can come back and modify this.


Won't extending [1] to load 64 bit values result in 80 bit instructions?


Yes? But I think it's extremely unlikely to happen. You can always just
put your 64-bit literals in the data section. And true 64-bit addresses
(where each bit must be specified) basically don't exist, since no one
has that much memory. Even the 32-bit version is just a suggestion at
this point, and I think the added complexity to instruction decoding
will make 80-bit instructions just theory.

--Sean



Best regards

Heinrich



--Sean

[1] 
https://github.com/riscv/riscv-code-size-reduction/blob/master/ISA%20proposals/Huawei/48bit_encodings.adoc


+   return 2;
+   if ((i & 0x3f) == 0x1f)
+   return 3;
+   if ((i & 0x7f) == 0x3f)
+   return 4;
+   i = (i >> 12) & 0x07;
+   if (i < 7)
+   return i + 5;
+   /* Encoding for >= 192 bits is not yet defined */
+   return 1;
+}
+
+/**
+ * show_code() - display code leading to exception
+ *
+ * @epc:   program counter
+ */
+static void show_code(ulong epc)
+{
+   u16 *pos = (u16 *)(epc & ~1UL);
+   int i, len = instr_len(*pos);
+
+   printf("\nCode: ");
+   for (i = -8; i; ++i)
+   printf("%04x ", pos[i]);
+   printf("(");
+   for (i = 0; i < len; ++i)
+   printf("%04x%s", pos[i], i + 1 == len ? ")\n" : " ");
+}
+
   static void _exit_trap(ulong code, ulong epc, ulong tval, struct pt_regs 
*regs)
   {
static const char * const exception_code[] = {
@@ -85,6 +126,7 @@ static void _exit_trap(ulong code, ulong epc, ulong tval, 
struct pt_regs *regs)
   epc - gd->reloc_off, regs->ra - gd->reloc_off);

show_regs(regs);
+   show_code(epc);
show_efi_loaded_images(epc);
panic("\n");
   }
--
2.30.2

Re: [PATCH v2 5/6] riscv: lib: move platform-related libraries to sperate folder

[Zong Li]

On Fri, Aug 13, 2021 at 4:22 AM Sean Anderson  wrote:
>
> On 8/10/21 3:04 AM, Zong Li wrote:
> > On Tue, Aug 10, 2021 at 12:55 PM Sean Anderson  wrote:
> >>
> >>> Re: [PATCH v2 5/6] riscv: lib: move platform-related libraries to sperate 
> >>> folder
> >>
> >> nit: separate
> >>
> >
> > Thanks for catching it. Fix it in the next version.
> >
> >> On 8/3/21 12:44 AM, Zong Li wrote:
> >>> Put the platform-related implementation into their own folder
> >>> respectively. Just leave the common library in the top of lib
> >>> folder.
> >>>
> >>> Signed-off-by: Zong Li 
> >>> ---
> >>>arch/riscv/Kconfig  | 7 +++
> >>>arch/riscv/lib/Makefile | 9 -
> >>>arch/riscv/lib/andestech/Kconfig| 8 
> >>>arch/riscv/lib/andestech/Makefile   | 7 +++
> >>>arch/riscv/lib/{ => andestech}/andes_plic.c | 0
> >>>arch/riscv/lib/sifive/Kconfig   | 8 
> >>>arch/riscv/lib/sifive/Makefile  | 9 +
> >>>arch/riscv/lib/{ => sifive}/sifive_cache.c  | 0
> >>>arch/riscv/lib/{ => sifive}/sifive_clint.c  | 0
> >>>9 files changed, 43 insertions(+), 5 deletions(-)
> >>>create mode 100644 arch/riscv/lib/andestech/Kconfig
> >>>create mode 100644 arch/riscv/lib/andestech/Makefile
> >>>rename arch/riscv/lib/{ => andestech}/andes_plic.c (100%)
> >>>create mode 100644 arch/riscv/lib/sifive/Kconfig
> >>>create mode 100644 arch/riscv/lib/sifive/Makefile
> >>>rename arch/riscv/lib/{ => sifive}/sifive_cache.c (100%)
> >>>rename arch/riscv/lib/{ => sifive}/sifive_clint.c (100%)
> >>
> >> NAK from me. I'd much rather see organization by function (e.g.
> >> clint/sbi/plic together) than by vendor. Plus, the clint/plic are not
> >> really specific to one vendor like ccache.
> >>
> >
> > Yes, it makes more sense to me. In this case, there are three
> > functionalities, so I'd like to separate clint, plic and cache at this
> > time, does it make sense to you?
>
> No, it does not. clint and plic should be grouped with SBI because in
> U-Boot they are all used for IPIs. But frankly, I don't really see the
> need to place them in subdirectories yet...
>

Okay, I got it, how about only separate cache into a subdirectory? Or
you think that it might be OK to just put all of them in lib/ ?

> --Sean
>
> >
> >> --Sean
> >>
> >>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> >>> index ec651fe0a4..ed1bf2f6c8 100644
> >>> --- a/arch/riscv/Kconfig
> >>> +++ b/arch/riscv/Kconfig
> >>> @@ -72,6 +72,10 @@ source "arch/riscv/cpu/fu540/Kconfig"
> >>>source "arch/riscv/cpu/fu740/Kconfig"
> >>>source "arch/riscv/cpu/generic/Kconfig"
> >>>
> >>> +# library-specific options below
> >>> +source "arch/riscv/lib/sifive/Kconfig"
> >>> +source "arch/riscv/lib/andestech/Kconfig"
> >>> +
> >>># architecture-specific options below
> >>>
> >>>choice
> >>> @@ -175,18 +179,21 @@ config SIFIVE_CLINT
> >>>config SPL_SIFIVE_CLINT
> >>>bool
> >>>depends on SPL_RISCV_MMODE
> >>> + select SIFIVE_LIB
> >>>help
> >>>  The SiFive CLINT block holds memory-mapped control and status 
> >>> registers
> >>>  associated with software and timer interrupts.
> >>>
> >>>config SIFIVE_CACHE
> >>>bool
> >>> + select SIFIVE_LIB
> >>>help
> >>>  This enables the operations to configure SiFive cache
> >>>
> >>>config ANDES_PLIC
> >>>bool
> >>>depends on RISCV_MMODE || SPL_RISCV_MMODE
> >>> + select ANDESTECH_LIB
> >>>select REGMAP
> >>>select SYSCON
> >>>select SPL_REGMAP if SPL
> >>> diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
> >>> index 06020fcc2a..f58d1f9819 100644
> >>> --- a/arch/riscv/lib/Makefile
> >>> +++ b/arch/riscv/lib/Makefile
> >>> @@ -10,11 +10,7 @@ obj-$(CONFIG_CMD_BOOTM) += bootm.o
> >>>obj-$(CONFIG_CMD_BOOTI) += bootm.o image.o
> >>>obj-$(CONFIG_CMD_GO) += boot.o
> >>>obj-y   += cache.o
> >>> -obj-$(CONFIG_SIFIVE_CACHE) += sifive_cache.o
> >>> -ifeq ($(CONFIG_$(SPL_)RISCV_MMODE),y)
> >>> -obj-$(CONFIG_$(SPL_)SIFIVE_CLINT) += sifive_clint.o
> >>> -obj-$(CONFIG_ANDES_PLIC) += andes_plic.o
> >>> -else
> >>> +ifeq ($(CONFIG_$(SPL_)RISCV_MMODE),)
> >>>obj-$(CONFIG_SBI) += sbi.o
> >>>obj-$(CONFIG_SBI_IPI) += sbi_ipi.o
> >>>endif
> >>> @@ -42,3 +38,6 @@ extra-$(CONFIG_EFI) += $(EFI_CRT0) $(EFI_RELOC)
> >>>obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMSET) += memset.o
> >>>obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMMOVE) += memmove.o
> >>>obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMCPY) += memcpy.o
> >>> +
> >>> +obj-$(CONFIG_SIFIVE_LIB) += sifive/
> >>> +obj-$(CONFIG_ANDESTECH_LIB) += andestech/
> >>> diff --git a/arch/riscv/lib/andestech/Kconfig 
> >>> b/arch/riscv/lib/andestech/Kconfig
> >>> new file mode 100644
> >>> index 00..75f83a8123
> >>> --- /dev/null
> >>> +++ b/arch/riscv/lib/andestech/Kconfig
> >>> @@ -0,0 +1,8 @

Re: [PATCH v2 3/6] riscv: lib: introduce cache_init interface

[Zong Li]

On Fri, Aug 13, 2021 at 4:20 AM Sean Anderson  wrote:
>
> On 8/10/21 2:57 AM, Zong Li wrote:
> > On Tue, Aug 10, 2021 at 12:47 PM Sean Anderson  wrote:
> >>
> >> On 8/3/21 12:44 AM, Zong Li wrote:
> >>> Add an interface for cache initialization. Each platform can overwrite
> >>> this weak function by their own implementation, such as sifive_cache in
> >>> this patch.
> >>
> >> Can we call this enable_caches instead of cache_init? This function is
> >> called by initr_caches in board_r.c for ARM. There's even an
> >> eight-year-old TODO on the subject.
> >>
> >
> > I had considered use it, The reason I finally used cache_init here is
> > that it seems to me that cache_init would be more flexible for risc-v
> > platforms to do not only cache enable, but also various
> > platform-specific initialization of cache, even they could decide the
> > time to invoke cache_init if there is particular initialization
> > sequence.
>
> Do you have some example in mind?

It seems to me that not all cache devices are only configured for
operations related to enable/disable. It might refer to the status of
the cache itself or different functionalities, then it might be a bit
weird if we associate them with the "enable" term, It is a
platform-specific implementation.

>
> > If you think that cache_init is OK to you, I would prefer to
> > retain cache_init. I can still use enable_caches instead of cache_init
> > if you think that it is a better way. Please let me know your thoughts
> > and thanks for your review.
>
> I would like to reduce the proliferation of different cache enable
> functions. Right now we have (i|d)cache_enable which are RISC-V-specific
> and called very early during boot; cache_enable, which must be called
> manually; enable_caches, which is implemented only for ARM; and your
> proposed cache_init. I don't think there is need for yet another way to
> accomplish the same thing.
>
> --Sean
>
> >>>
> >>> Signed-off-by: Zong Li 
> >>> ---
> >>>arch/riscv/Kconfig |  5 +
> >>>arch/riscv/include/asm/cache.h |  1 +
> >>>arch/riscv/lib/Makefile|  1 +
> >>>arch/riscv/lib/cache.c |  5 +
> >>>arch/riscv/lib/sifive_cache.c  | 27 +++
> >>>5 files changed, 39 insertions(+)
> >>>create mode 100644 arch/riscv/lib/sifive_cache.c
> >>>
> >>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> >>> index 4b0c3dffa6..ec651fe0a4 100644
> >>> --- a/arch/riscv/Kconfig
> >>> +++ b/arch/riscv/Kconfig
> >>> @@ -179,6 +179,11 @@ config SPL_SIFIVE_CLINT
> >>>  The SiFive CLINT block holds memory-mapped control and status 
> >>> registers
> >>>  associated with software and timer interrupts.
> >>>
> >>> +config SIFIVE_CACHE
> >>> + bool
> >>> + help
> >>> +   This enables the operations to configure SiFive cache
> >>> +
> >>>config ANDES_PLIC
> >>>bool
> >>>depends on RISCV_MMODE || SPL_RISCV_MMODE
> >>> diff --git a/arch/riscv/include/asm/cache.h 
> >>> b/arch/riscv/include/asm/cache.h
> >>> index ec8fe201d3..6ebb2b4329 100644
> >>> --- a/arch/riscv/include/asm/cache.h
> >>> +++ b/arch/riscv/include/asm/cache.h
> >>> @@ -9,6 +9,7 @@
> >>>
> >>>/* cache */
> >>>voidcache_flush(void);
> >>> +int cache_init(void);
> >>>
> >>>/*
> >>> * The current upper bound for RISCV L1 data cache line sizes is 32 
> >>> bytes.
> >>> diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
> >>> index c4cc41434b..06020fcc2a 100644
> >>> --- a/arch/riscv/lib/Makefile
> >>> +++ b/arch/riscv/lib/Makefile
> >>> @@ -10,6 +10,7 @@ obj-$(CONFIG_CMD_BOOTM) += bootm.o
> >>>obj-$(CONFIG_CMD_BOOTI) += bootm.o image.o
> >>>obj-$(CONFIG_CMD_GO) += boot.o
> >>>obj-y   += cache.o
> >>> +obj-$(CONFIG_SIFIVE_CACHE) += sifive_cache.o
> >>>ifeq ($(CONFIG_$(SPL_)RISCV_MMODE),y)
> >>>obj-$(CONFIG_$(SPL_)SIFIVE_CLINT) += sifive_clint.o
> >>>obj-$(CONFIG_ANDES_PLIC) += andes_plic.o
> >>> diff --git a/arch/riscv/lib/cache.c b/arch/riscv/lib/cache.c
> >>> index b1d42bcc2b..2cd66504c6 100644
> >>> --- a/arch/riscv/lib/cache.c
> >>> +++ b/arch/riscv/lib/cache.c
> >>> @@ -70,3 +70,8 @@ __weak int dcache_status(void)
> >>>{
> >>>return 0;
> >>>}
> >>> +
> >>> +__weak int cache_init(void)
> >>> +{
> >>> + return 0;
> >>> +}
> >>> diff --git a/arch/riscv/lib/sifive_cache.c b/arch/riscv/lib/sifive_cache.c
> >>> new file mode 100644
> >>> index 00..94e84e024e
> >>> --- /dev/null
> >>> +++ b/arch/riscv/lib/sifive_cache.c
> >>> @@ -0,0 +1,27 @@
> >>> +// SPDX-License-Identifier: GPL-2.0+
> >>> +/*
> >>> + * Copyright (C) 2021 SiFive, Inc
> >>> + */
> >>> +
> >>> +#include 
> >>> +#include 
> >>> +#include 
> >>> +
> >>> +int cache_init(void)
> >>> +{
> >>> + struct udevice *dev;
> >>> + int ret;
> >>> +
> >>> + /* Enable ways of ccache */
> >>> + ret = uclass_get_device_by_driver(UCLASS_CACHE,
> >>> +   DM_DRIVER_G

Please pull u-boot-x86

[Bin Meng]

Hi Tom,

This PR includes the following x86 changes for v2021.10:

- Enable SeaBIOS support for Crown Bay
- Update SeaBIOS build instructions in the x86 doc
- Enable CONFIG_SPI_FLASH_SMART_HWCAPS for Crown Bay

Azure results: PASS
https://dev.azure.com/bmeng/GitHub/_build/results?buildId=419&view=results

The following changes since commit a25277122dad99837b78cd3b3ae6b8214df88c26:

  Merge https://source.denx.de/u-boot/custodians/u-boot-cfi-flash
(2021-08-11 08:31:56 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-x86

for you to fetch changes up to cedd754484eb929b6f90c60d5d7e6ee458440152:

  x86: crownbay: Enable CONFIG_SPI_FLASH_SMART_HWCAPS (2021-08-13
08:53:49 +0800)


Bin Meng (3):
  x86: crownbay: Enable SeaBIOS support
  doc: x86: Update SeaBIOS build instructions
  x86: crownbay: Enable CONFIG_SPI_FLASH_SMART_HWCAPS

 configs/crownbay_defconfig |  2 +-
 doc/arch/x86.rst   | 21 -
 2 files changed, 9 insertions(+), 14 deletions(-)

Regards,
Bin

Re: [PATCH] cmd: boot: Update reset usage message

[Wolfgang Denk]

Dear Michal,

In message 
<82e0d7efdbd9f8c62f46c7e1a8913ffa52de5a1e.1628676265.git.michal.si...@xilinx.com>
 you wrote:
> The commit 573a3811edc8 ("sysreset: psci: support system reset in a generic
> way with PSCI") has added support for warm reset via PSCI but this hasn't
> been reflected in usage message and user has to look at the code how to run
> it. That's why update usage text to make this clear.
>
> Here is full help with updated usage:
> ZynqMP> help reset
> reset - Perform RESET of the CPU
>
> Usage:
> reset - cold boot without level specifier
> reset -w - warm reset if implemented

In case of the hard (cold) reset - is it really only a reset of the
CPU, or of the whole board hardware?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Every revolutionary idea - in science, politics, art, or  whatever  -
evokes three stages of reaction in a hearer:
  1. It is completely impossible - don't waste my time.
  2. It is possible, but it is not worth doing.
  3. I said it was a good idea all along.

Re: [PATCH v4 07/10] watchdog: wdt-uclass.c: handle all DM watchdogs in watchdog_reset()

[Wolfgang Denk]

Dear Tom,

In message <20210812162034.GY858@bill-the-cat> you wrote:
> 
> > So if "the system is on fire" is one of the cases where an error
> > message should be omitted to save maybe 50 or 100 bytes of image
> > size?  This sounds wrong to me.
>
> It sounds right to me because it's unlikely everything caught fire
> because of this call right here and likely it's because of one of the
> messages much further up on the console log.  Hopefully we haven't
> caused that message to be unavailable now due to unhelpful failure
> messages.

Omitting code to handle situations that are unlikely to happen is
definitely not what I consider robust programming, and nothing which
I would let pass a code review.

But if you insist, there is no more to do for me here that to note
that fact that we disagree.


Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
People are very flexible and learn to adjust to strange  surroundings
--  they can become accustomed to read Lisp and Fortran programs, for
example.   - Leon Sterling and Ehud Shapiro, Art of Prolog, MIT Press

Re: [PATCH] cmd: boot: Update reset usage message

[Michal Simek]

On 8/13/21 8:11 AM, Wolfgang Denk wrote:
> Dear Michal,
> 
> In message 
> <82e0d7efdbd9f8c62f46c7e1a8913ffa52de5a1e.1628676265.git.michal.si...@xilinx.com>
>  you wrote:
>> The commit 573a3811edc8 ("sysreset: psci: support system reset in a generic
>> way with PSCI") has added support for warm reset via PSCI but this hasn't
>> been reflected in usage message and user has to look at the code how to run
>> it. That's why update usage text to make this clear.
>>
>> Here is full help with updated usage:
>> ZynqMP> help reset
>> reset - Perform RESET of the CPU
>>
>> Usage:
>> reset - cold boot without level specifier
>> reset -w - warm reset if implemented
> 
> In case of the hard (cold) reset - is it really only a reset of the
> CPU, or of the whole board hardware?

If you look at sysreset headers you will find these levels
 11 SYSRESET_WARM,  /* Reset CPU, keep GPIOs active */
 12 SYSRESET_COLD,  /* Reset CPU and GPIOs */
 13 SYSRESET_POWER, /* Reset PMIC (remove and restore power) */
 14 SYSRESET_POWER_OFF, /* Turn off power */

When you call reset sysreset uclass is calling sysreset_walk which is
request to drivers with type passed.
I see we have mixed drivers which deals with levels and especially in
gpio case it is question how you connect it.
I develop this for microblaze where gpio is connected reset logic which
is normally only for CPU and subsystem.
But in general you can connect whatever you want. It means it doesn't
need to be only cpu which is reset.
Do you want me to update that line and remove CPU from it?

Thanks,
Michal

Re: [PATCH] cmd: boot: Update reset usage message

[Wolfgang Denk]

Dear Michal,

In message <90e6c670-9e11-beb8-bcb5-9d22ba00f...@xilinx.com> you wrote:
> 
> > In case of the hard (cold) reset - is it really only a reset of the
> > CPU, or of the whole board hardware?
>
> If you look at sysreset headers you will find these levels
>  11 SYSRESET_WARM,  /* Reset CPU, keep GPIOs active */
>  12 SYSRESET_COLD,  /* Reset CPU and GPIOs */
>  13 SYSRESET_POWER, /* Reset PMIC (remove and restore power) */
>  14 SYSRESET_POWER_OFF, /* Turn off power */
>
> When you call reset sysreset uclass is calling sysreset_walk which is
> request to drivers with type passed.
> I see we have mixed drivers which deals with levels and especially in
> gpio case it is question how you connect it.
> I develop this for microblaze where gpio is connected reset logic which
> is normally only for CPU and subsystem.
> But in general you can connect whatever you want. It means it doesn't
> need to be only cpu which is reset.

Thanks a lot for the explanation.

> Do you want me to update that line and remove CPU from it?

I don't know :-)

What the "reset" command _should_ do is a hard cold boot including
the reset of all peripherals - for example, when booting from SPI
NOR flash it is mandatory to reset this flash to make sure the ROM
boot loader can actually read it.

I would appreciate if the help message documents what it actually
does.  Also, what the difference between "cold" and "warm" reset is.
My expectation (without knowing any hardware details) would be that
a warm reset is just a restart of the already loaded code? Or is it
just a reset of the CPU (without external reset)? This might then
hang the system if it's attempting to boot from a flash which is in
the wrong state.

So my problem with this is primarily that I don't understand what
the command really does, and the help command is of no help either.

[And if I understand correctly, this is even board dependent?]

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
How many NASA managers does it take to screw in a lightbulb?  "That's
a known problem... don't worry about it."