[PATCH] net: zynq_gem: Use ulong instead of u32 data type

[Michal Simek]

From: T Karthik Reddy 

flush_dcache_range() expects unsigned long in the arguments. Here u32
variable is unable to hold the higher address value when ddr mapped
to higher addresses & flushing lower address dchache range instead
which is unmapped causing to crash.

Signed-off-by: T Karthik Reddy 
Signed-off-by: Michal Simek 
---

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

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index c3fe8e3c563f..879129653df3 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -653,7 +653,7 @@ static int zynq_gem_probe(struct udevice *dev)
return -ENOMEM;
 
memset(priv->rxbuffers, 0, RX_BUF * PKTSIZE_ALIGN);
-   u32 addr = (ulong)priv->rxbuffers;
+   ulong addr = (ulong)priv->rxbuffers;
flush_dcache_range(addr, addr + roundup(RX_BUF * PKTSIZE_ALIGN, 
ARCH_DMA_MINALIGN));
barrier();
 
-- 
2.25.0

[PATCH] MAINTAINERS: Update ARM TI entry

[Lokesh Vutla]

Take over TI maintainership from Tom.

Signed-off-by: Lokesh Vutla 
---
 MAINTAINERS| 2 +-
 doc/git-mailrc | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 438fb225ab..e3193df96c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -394,7 +394,7 @@ F:  arch/arm/mach-tegra/
 F: arch/arm/include/asm/arch-tegra*/
 
 ARM TI
-M: Tom Rini 
+M: Lokesh Vutla 
 S: Maintained
 T: git https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git
 F: arch/arm/mach-davinci/
diff --git a/doc/git-mailrc b/doc/git-mailrc
index d29416a57a..be88afcefd 100644
--- a/doc/git-mailrc
+++ b/doc/git-mailrc
@@ -28,6 +28,7 @@ alias jagan  Jagan Teki 
 alias jhersh Joe Hershberger 
 alias kevery Kever Yang 
 alias leyfoonLey Foon Tan 
+alias lokeshvutlaLokesh Vutla 
 alias lukma  Lukasz Majewski 
 alias macpaulMacpaul Lin 
 alias marex  Marek Vasut 
@@ -70,7 +71,7 @@ alias socfpgauboot, marex, dinh, simongoldschmidt, 
leyfoon
 alias sunxi  uboot, jagan, maxime
 alias tegra  uboot, sjg, Tom Warren , Stephen 
Warren 
 alias tegra2 tegra
-alias ti uboot, trini
+alias ti uboot, lokeshvutla
 alias uniphier   uboot, masahiro
 alias zynq   uboot, monstr
 alias rockchip   uboot, sjg, kevery, ptomsich
-- 
2.23.0

[GIT PULL] Xilinx patches for v2020.04

[Michal Simek]

Hi Tom,

please pull the following changes to your tree.
The major part of this pull request is using only one defconfig for
Xilinx ZynqMP platforms. The same change should also happen with Zynq
platforms but I haven't had a time to do it (Microblaze is using it from
the begining and Versal too).
I have also added that custom script for u-boot.itb generation to get
things going before unification can happen as we talked about.

I have sync up Linux DT with U-Boot but still there are things to work on.

There are some minor changes in generic code. For more information take
a look at tag description below.

Travis looks good
https://travis-ci.org/michalsimek/u-boot/builds/636763911
and gitlab CI too.
https://gitlab.denx.de/u-boot/custodians/u-boot-microblaze/pipelines/1849

Thanks,
Michal


The following changes since commit 88366b96ee0d8640b2af53e4026dbaeed0fab5e0:

  travis: Switch to QEMU v4.2.0 globally (2020-01-11 08:07:03 -0500)

are available in the Git repository at:

  g...@gitlab.denx.de:u-boot/custodians/u-boot-microblaze.git
tags/xilinx-for-v2020.04

for you to fetch changes up to ddb55ff8a66dabe3365735eff9f901bb259c223f:

  arm64: versal: Enable board_late_init calling (2020-01-14 09:06:42 +0100)


Xilinx/FPGA changes for v2020.04

ARM64:
- Add INIT_SPL_RELATIVE dependency

SPL:
- FIT image fix
- Enable customization of bl2_plat_get_bl31_params()

Pytest:
- Add test for octal/hex conversions

Microblaze:
- Fix manual relocation for one SPI instance

Nand:
- Convert zynq/zynqmp drivers to DM

Xilinx:
- Enable boot script location via Kconfig
- Support OF_SEPARATE in board FDT selection
- Remove low level uart setup it is done later by code
- Add support for DEVICE_TREE variable passing for SPL

Zynq:
- Enable jtag boot mode via distro boot
- Removing unused baseaddresses from hardware.h
- DT fixups

ZynqMP:
- Fix emmc boot sequence
- Simplify spl logic around bss and board_init_r()
- Support psu_post_config_data() calling
- Tune mini-nand DTS
- Fix psu wiring for a2197 boards
- Add runtime MMC device boot order filling in spl
- Clear ATF handoff handling with custom bl2_plat_get_bl31_params()
- Add support u-boot.its generation
- Use single image configuration for all platforms
- Enable PANIC_HANG via Kconfig
- DT fixups
- Firmware fixes
- Add support for zcu208 and zcu1285

Versal:
- Fix emmc boot sequence
- Enable board_late_init() by default


Ashok Reddy Soma (6):
  mtd: nand: Move arasan nand driver to driver model
  mtd: nand: Remove hardcoded base address of nand
  spi: Fix manual relocation calling more times
  zynq: mtd: nand: Move zynq nand driver to driver model
  zynq: mtd: nand: Remove hardcoded base addresses
  firmware: Remove probe which is causing extra bind

Jan Kiszka (1):
  arm64: dts: zcu100-revC: Give wifi some time after power-on

Michal Simek (33):
  spl: atf: Add missing ndepth initialization
  arm64: zynqmp: Do not call bss init and board_init_r from board_init_f
  arm64: Enable INIT_SP_RELATIVE by default when POC is enabled
  arm64: zynqmp: Rename fw_dtb variable to fdt_blob
  arm64: zynqmp: Add support for OF_SEPARATE with board DTB
  arm64: zynqmp: Do not assing MIO34 that early on zcu100
  arm64: zynqmp: Remove low level UART setting
  arm: zynq: Remove low level UART setting
  arm64: zynqmp: Enable bind/unbind commands for all boards
  arm64: zynqmp: Remove nand partition description from mini-nand
  arm64: zynqmp: Fix symlinks to SC psu_init* files
  arm64: zynqmp: Add board_boot_order for MMC boot extension
  arm64: zynqmp: Fix return value of board_fit_config_name_match
  arm: xilinx: Use device tree which can be passed on cmd line
  spl: atf: Enable option to rewrite bl2_plat_get_bl31_params()
  arm: zynqmp: Wire SPL/ATF handoff structure properly
  ARM: zynq: Remove unused QSPI and USB addresses
  test/py: hush_if_test: Add tests to cover octal/hex values
  arm64: zynqmp: Add support for u-boot.itb generation with ATF
  arm64: zynqmp: Add missing Kconfig options to zynqmp_virt platform
  arm64: zynqmp: Use zynqmp_virt platform
  arm64: zynqmp: Move PANIC to Kconfig
  arm64: zynqmp: Fix ina226 shunt resistor value
  ARM: zynq: Add missing nand/smcc nodes
  arm64: zynqmp: Add support for zcu208
  arm64: zynqmp: Switch zcu100 revC to use firmware clock driver
  net: zynq: Add a note about RX_BUF macro
  arm64: zynqmp: Add support for zcu1285 revA board
  arm64: zynqmp: Remove incorrect phy from DT for zcu102-revB up
  arm64: dts: zynqmp: Fix node names which contain "_"
  arm64: zynqmp: Sync gpio-controller name location
  arm64: zynqmp: Sync gem clock nodes with mainline Linux
  arm64: versal: Enable board_late_init calling

Raviteja Narayanam (1):
  arm64: zynqmp: Correct 

Re: [PATCH] arm: dts: imx7ulp-evk: remove mux value from pad configuration

[Jorge Ramirez-Ortiz, Foundries]

On 16/01/20 02:22:35, Peng Fan wrote:
> > Subject: [PATCH] arm: dts: imx7ulp-evk: remove mux value from pad
> > configuration
> > 
> > The mux mode is embedded in the PAD definition and therefore there is no
> > need to repeat it in the PAD configuration value (more over since this
> > information will be masked out when the configuration value is applied).
> 
> Has this been accepted by Shawn?

added to DL now

> 
> Thanks,
> Peng.
> 
> > 
> > Signed-off-by: Jorge Ramirez-Ortiz 
> > ---
> >  arch/arm/dts/imx7ulp-evk.dts | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/dts/imx7ulp-evk.dts b/arch/arm/dts/imx7ulp-evk.dts
> > index 08a682f314..8f6a935e24 100644
> > --- a/arch/arm/dts/imx7ulp-evk.dts
> > +++ b/arch/arm/dts/imx7ulp-evk.dts
> > @@ -156,7 +156,7 @@
> > 
> > pinctrl_backlight: backlight_grp {
> > fsl,pins = <
> > -   IMX7ULP_PAD_PTF2__PTF2  0x20100
> > +   IMX7ULP_PAD_PTF2__PTF2  0x2
> > >;
> > };
> > 
> > --
> > 2.17.1
> 

Re: [PATCH 0/2] Move arasan nand driver to driver model

[Michal Simek]

čt 19. 12. 2019 v 16:06 odesílatel Michal Simek
 napsal:
>
> Hi,
>
> these two patches are moving nand driver to DM and also remove hardcoded
> base address of nand controller and get it from device tree.
>
> Thanks,
> Michal
>
>
> Ashok Reddy Soma (2):
>   mtd: nand: Move arasan nand driver to driver model
>   mtd: nand: Remove hardcoded base address of nand
>
>  arch/arm/mach-zynqmp/include/mach/hardware.h |   2 -
>  drivers/mtd/nand/raw/Kconfig |   1 +
>  drivers/mtd/nand/raw/arasan_nfc.c| 364 +++
>  3 files changed, 206 insertions(+), 161 deletions(-)
>
> --
> 2.24.0
>

Applied.
M

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH] arm64: versal: Fix emmc boot mode boot_target issue

[Michal Simek]

út 17. 12. 2019 v 11:16 odesílatel Michal Simek
 napsal:
>
> From: T Karthik Reddy 
>
> Emmc boot devcie is mounted to sdhci@f105 controller on versal, while
> in emmc boot mode, boot tragets are set to mmc0. So removed mmc0 and using
> the dev seq number from the sdhci@f105 controller.
> Dev seq number is setup based on DT aliases that's why needs to be setup at
> run time.
>
> Signed-off-by: T Karthik Reddy 
> Signed-off-by: Michal Simek 
> ---
>
>  board/xilinx/versal/board.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/board/xilinx/versal/board.c b/board/xilinx/versal/board.c
> index 23bb6b962387..45724478a25e 100644
> --- a/board/xilinx/versal/board.c
> +++ b/board/xilinx/versal/board.c
> @@ -130,7 +130,14 @@ int board_late_init(void)
> break;
> case EMMC_MODE:
> puts("EMMC_MODE\n");
> -   mode = "mmc0";
> +   if (uclass_get_device_by_name(UCLASS_MMC,
> + "sdhci@f105", )) {
> +   puts("Boot from EMMC but without SD1 enabled!\n");
> +   return -1;
> +   }
> +   debug("mmc1 device found at %p, seq %d\n", dev, dev->seq);
> +   mode = "mmc";
> +   bootseq = dev->seq;
> break;
> case SD_MODE:
> puts("SD_MODE\n");
> --
> 2.24.0
>

Applied.
M

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH] board: xilinx: Add support for user configurable boot script offset

[Michal Simek]

st 18. 12. 2019 v 11:54 odesílatel Michal Simek
 napsal:
>
> From: T Karthik Reddy 
>
> Currently "script_offset_f" env variable is hardcoded, this variable
> specifies from which offset of the flash boot.scr should be read/write.
> As flashes are of different sizes having a fixed offset makes it
> difficult to load other images into the flash which may overwrite the
> boot script or cannot utilize the full memory. This current fix
> creates a new config "CONFIG_BOOT_SCRIPT_OFFSET" which holds the
> offset address, overwrites the "script_offset_f" variable.
> Also removed existing variable with default values, as the default
> values are held by CONFIG_BOOT_SCRIPT_OFFSET
>
> Signed-off-by: T Karthik Reddy 
> Signed-off-by: Michal Simek 
> ---
>
>  board/xilinx/Kconfig| 9 +
>  board/xilinx/versal/board.c | 2 ++
>  board/xilinx/zynq/board.c   | 2 ++
>  board/xilinx/zynqmp/zynqmp.c| 2 ++
>  include/configs/xilinx_versal.h | 1 -
>  include/configs/xilinx_zynqmp.h | 1 -
>  include/configs/zynq-common.h   | 1 -
>  7 files changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/board/xilinx/Kconfig b/board/xilinx/Kconfig
> index cb272eafda7a..7833b11767c4 100644
> --- a/board/xilinx/Kconfig
> +++ b/board/xilinx/Kconfig
> @@ -47,3 +47,12 @@ config XILINX_OF_BOARD_DTB_ADDR
> depends on OF_BOARD
> help
>   Offset in the memory where the board configuration DTB is placed.
> +
> +config BOOT_SCRIPT_OFFSET
> +   hex "Boot script offset"
> +   depends on ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_VERSAL
> +   default 0xFC if ARCH_ZYNQ
> +   default 0x3E8 if ARCH_ZYNQMP
> +   default 0x7F8 if ARCH_VERSAL
> +   help
> +  Specifies distro boot script offset in NAND/NOR flash.
> diff --git a/board/xilinx/versal/board.c b/board/xilinx/versal/board.c
> index 45724478a25e..9fa9e76e6663 100644
> --- a/board/xilinx/versal/board.c
> +++ b/board/xilinx/versal/board.c
> @@ -203,6 +203,8 @@ int board_late_init(void)
> initrd_hi = round_down(initrd_hi, SZ_16M);
> env_set_addr("initrd_high", (void *)initrd_hi);
>
> +   env_set_hex("script_offset_f", CONFIG_BOOT_SCRIPT_OFFSET);
> +
> return 0;
>  }
>
> diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
> index 8929b6c5d22d..420a5ca66311 100644
> --- a/board/xilinx/zynq/board.c
> +++ b/board/xilinx/zynq/board.c
> @@ -76,6 +76,8 @@ int board_late_init(void)
>
> env_set("boot_targets", new_targets);
>
> +   env_set_hex("script_offset_f", CONFIG_BOOT_SCRIPT_OFFSET);
> +
> return 0;
>  }
>
> diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
> index b72eade43eea..8bdc67748ec2 100644
> --- a/board/xilinx/zynqmp/zynqmp.c
> +++ b/board/xilinx/zynqmp/zynqmp.c
> @@ -667,6 +667,8 @@ int board_late_init(void)
> initrd_hi = round_down(initrd_hi, SZ_16M);
> env_set_addr("initrd_high", (void *)initrd_hi);
>
> +   env_set_hex("script_offset_f", CONFIG_BOOT_SCRIPT_OFFSET);
> +
> reset_reason();
>
> return 0;
> diff --git a/include/configs/xilinx_versal.h b/include/configs/xilinx_versal.h
> index f426127edcff..dec5001b5fe4 100644
> --- a/include/configs/xilinx_versal.h
> +++ b/include/configs/xilinx_versal.h
> @@ -92,7 +92,6 @@
> "kernel_size_r=0x1000\0" \
> "scriptaddr=0x2000\0" \
> "ramdisk_addr_r=0x0210\0" \
> -   "script_offset_f=0x7F8\0" \
> "script_size_f=0x8\0"
>
>  #if defined(CONFIG_MMC_SDHCI_ZYNQ)
> diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h
> index b13765e17593..010738363d13 100644
> --- a/include/configs/xilinx_zynqmp.h
> +++ b/include/configs/xilinx_zynqmp.h
> @@ -113,7 +113,6 @@
> "kernel_addr_r=0x1800\0" \
> "scriptaddr=0x2000\0" \
> "ramdisk_addr_r=0x0210\0" \
> -   "script_offset_f=0x3e8\0" \
> "script_size_f=0x8\0" \
>
>  #if defined(CONFIG_MMC_SDHCI_ZYNQ)
> diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
> index 4dbd30054643..fe4679a90b2c 100644
> --- a/include/configs/zynq-common.h
> +++ b/include/configs/zynq-common.h
> @@ -203,7 +203,6 @@
> "fdt_high=0x2000\0" \
> "initrd_high=0x2000\0"  \
> "scriptaddr=0x2\0"  \
> -   "script_offset_f=0xFC\0"\
> "script_size_f=0x4\0"   \
> "fdt_addr_r=0x1f0\0"\
> "pxefile_addr_r=0x200\0"\
> --
> 2.24.0
>

Applied.
M


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH] spl: atf: Add missing ndepth initialization

[Michal Simek]

čt 19. 12. 2019 v 15:52 odesílatel Michal Simek
 napsal:
>
> ndepth needs to be initialized before it is used in fdt_next_node().
> Uninitialized value is causing that node is found and depth increase but
> won't pass condition below because initial state wasn't setup.
>
> Signed-off-by: Michal Simek 
> ---
>
>  common/spl/spl_atf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/common/spl/spl_atf.c b/common/spl/spl_atf.c
> index df2927420746..24fd35ed85f4 100644
> --- a/common/spl/spl_atf.c
> +++ b/common/spl/spl_atf.c
> @@ -112,7 +112,7 @@ static void bl31_entry(uintptr_t bl31_entry, uintptr_t 
> bl32_entry,
>
>  static int spl_fit_images_find(void *blob, int os)
>  {
> -   int parent, node, ndepth;
> +   int parent, node, ndepth = 0;
> const void *data;
>
> if (!blob)
> --
> 2.24.0
>

Applied.
M

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH] arm64: Enable INIT_SP_RELATIVE by default when POC is enabled

[Michal Simek]

pá 20. 12. 2019 v 11:43 odesílatel Michal Simek
 napsal:
>
> When position-independent pre-relocation code is enable there is also
> necessary to enable relative early stack pointer not to use origin location
> pointed by CONFIG_SYS_INIT_SP_ADDR macro.
>
> Signed-off-by: Michal Simek 
> ---
>
>  arch/arm/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index f9dab073ea14..07746de69c46 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -12,6 +12,7 @@ config ARM64
>  if ARM64
>  config POSITION_INDEPENDENT
> bool "Generate position-independent pre-relocation code"
> +   select INIT_SP_RELATIVE
> help
>   U-Boot expects to be linked to a specific hard-coded address, and to
>   be loaded to and run from that address. This option lifts that
> --
> 2.24.0
>

Applied.
M


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH] arm64: zynqmp: Do not call bss init and board_init_r from board_init_f

[Michal Simek]

čt 19. 12. 2019 v 15:58 odesílatel Michal Simek
 napsal:
>
> There is no reason to clear bss and call board_init_r() from board_init_f()
> beca it can be called directly from crt0_64.S with also support for SPL
> stack relocation to SDRAM.
> For more information please take a look at arch/arm/lib/crt0_64.S
>
> Signed-off-by: Michal Simek 
> ---
>
>  arch/arm/mach-zynqmp/spl.c | 7 ---
>  1 file changed, 7 deletions(-)
>
> diff --git a/arch/arm/mach-zynqmp/spl.c b/arch/arm/mach-zynqmp/spl.c
> index 76bafcdd2a38..095b4e61a590 100644
> --- a/arch/arm/mach-zynqmp/spl.c
> +++ b/arch/arm/mach-zynqmp/spl.c
> @@ -28,13 +28,6 @@ void board_init_f(ulong dummy)
>  #endif
> /* Delay is required for clocks to be propagated */
> udelay(100);
> -
> -   debug("Clearing BSS 0x%p - 0x%p\n", __bss_start, __bss_end);
> -   /* Clear the BSS */
> -   memset(__bss_start, 0, __bss_end - __bss_start);
> -
> -   /* No need to call timer init - it is empty for ZynqMP */
> -   board_init_r(NULL, 0);
>  }
>
>  static void ps_mode_reset(ulong mode)
> --
> 2.24.0
>

Applied.
M


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH v2] arm64: zynqmp: Do not assing MIO34 that early on zcu100

[Michal Simek]

út 3. 12. 2019 v 16:33 odesílatel Michal Simek  napsal:
>
> MIO34 is connected to POWER_KILL signal. When MIO configuration is done in
> psu_init() and this pin is assigned to PMU but PMU configuration is not
> loaded yet. PMU gpio output is high that means board is powered off
> immediately.
> The patch is fixing this sequence that MIO34 stays assing to ps gpio IP.
> PMU config is loaded in SPL and then pin assigned to PMU through
> psu_post_config_data().
>
> Signed-off-by: Michal Simek 
> ---
>
> Changes in v2:
> - add missing declaration in header
>
>  arch/arm/mach-zynqmp/include/mach/psu_init_gpl.h  | 1 +
>  arch/arm/mach-zynqmp/psu_spl_init.c   | 9 +
>  arch/arm/mach-zynqmp/spl.c| 1 +
>  board/xilinx/zynqmp/zynqmp-zcu100-revC/psu_init_gpl.c | 7 ++-
>  4 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-zynqmp/include/mach/psu_init_gpl.h 
> b/arch/arm/mach-zynqmp/include/mach/psu_init_gpl.h
> index 15e54c049387..e37acda2f89e 100644
> --- a/arch/arm/mach-zynqmp/include/mach/psu_init_gpl.h
> +++ b/arch/arm/mach-zynqmp/include/mach/psu_init_gpl.h
> @@ -21,5 +21,6 @@ void prog_reg(unsigned long addr, unsigned long mask,
>   unsigned long shift, unsigned long value);
>
>  int psu_init(void);
> +unsigned long psu_post_config_data(void);
>
>  #endif /* _PSU_INIT_GPL_H_ */
> diff --git a/arch/arm/mach-zynqmp/psu_spl_init.c 
> b/arch/arm/mach-zynqmp/psu_spl_init.c
> index b357de32358c..b6abdfd608ee 100644
> --- a/arch/arm/mach-zynqmp/psu_spl_init.c
> +++ b/arch/arm/mach-zynqmp/psu_spl_init.c
> @@ -77,3 +77,12 @@ __weak int psu_init(void)
>  */
> return -1;
>  }
> +
> +__weak unsigned long psu_post_config_data(void)
> +{
> +   /*
> +* This function is overridden by the one in
> +* board/xilinx/zynqmp/(platform)/psu_init_gpl.c, if it exists.
> +*/
> +   return 0;
> +}
> diff --git a/arch/arm/mach-zynqmp/spl.c b/arch/arm/mach-zynqmp/spl.c
> index 6ba42bb42f62..6551b33f42d0 100644
> --- a/arch/arm/mach-zynqmp/spl.c
> +++ b/arch/arm/mach-zynqmp/spl.c
> @@ -60,6 +60,7 @@ void spl_board_init(void)
> preloader_console_init();
> ps_mode_reset(MODE_RESET);
> board_init();
> +   psu_post_config_data();
>  }
>  #endif
>
> diff --git a/board/xilinx/zynqmp/zynqmp-zcu100-revC/psu_init_gpl.c 
> b/board/xilinx/zynqmp/zynqmp-zcu100-revC/psu_init_gpl.c
> index e1fdabaeb9d1..585b3afc218a 100644
> --- a/board/xilinx/zynqmp/zynqmp-zcu100-revC/psu_init_gpl.c
> +++ b/board/xilinx/zynqmp/zynqmp-zcu100-revC/psu_init_gpl.c
> @@ -409,7 +409,6 @@ static unsigned long psu_mio_init_data(void)
> psu_mask_write(0xFF18007C, 0x00FEU, 0xU);
> psu_mask_write(0xFF180080, 0x00FEU, 0x0008U);
> psu_mask_write(0xFF180084, 0x00FEU, 0x0008U);
> -   psu_mask_write(0xFF180088, 0x00FEU, 0x0008U);
> psu_mask_write(0xFF18008C, 0x00FEU, 0xU);
> psu_mask_write(0xFF180090, 0x00FEU, 0xU);
> psu_mask_write(0xFF180094, 0x00FEU, 0xU);
> @@ -990,3 +989,9 @@ int psu_init(void)
> return 1;
> return 0;
>  }
> +
> +unsigned long psu_post_config_data(void)
> +{
> +   psu_mask_write(0xFF180088, 0x00FEU, 0x0008U);
> +   return 0;
> +}
> --
> 2.24.0
>

Applied.
M

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH v2 0/2] Extend board_fdt_blob_setup() to support OF_SEPARATE

[Michal Simek]

po 6. 1. 2020 v 10:00 odesílatel Michal Simek  napsal:
>
> Hi,
>
> it is simply series which align board_fdt_blob_setup() with fdtdec with
> highest priority on default location where external DTB can be found.
>
> Thanks,
> Michal
>
> Changes in v2:
> - Fix print messages not to generate compilation warnings on arm32
> - Silent all prints
>
> Michal Simek (2):
>   arm64: zynqmp: Rename fw_dtb variable to fdt_blob
>   arm64: zynqmp: Add support for OF_SEPARATE with board DTB
>
>  board/xilinx/Kconfig|  2 +-
>  board/xilinx/common/board.c | 31 ---
>  2 files changed, 25 insertions(+), 8 deletions(-)
>
> --
> 2.24.0
>

Applied.
M


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH] arm64: zynqmp: Remove low level UART setting

[Michal Simek]

pá 6. 12. 2019 v 9:17 odesílatel Michal Simek  napsal:
>
> There is no reason to do serial initialization. Uart driver does it already
> based on DT. Good effect is that it is clear which interface is console.
>
> Signed-off-by: Michal Simek 
> ---
>
>  .../psu_init_gpl.c| 8 
>  board/xilinx/zynqmp/zynqmp-a2197-revA/psu_init_gpl.c  | 8 
>  board/xilinx/zynqmp/zynqmp-zc1232-revA/psu_init_gpl.c | 4 
>  board/xilinx/zynqmp/zynqmp-zc1254-revA/psu_init_gpl.c | 4 
>  board/xilinx/zynqmp/zynqmp-zc1275-revB/psu_init_gpl.c | 4 
>  .../xilinx/zynqmp/zynqmp-zc1751-xm015-dc1/psu_init_gpl.c  | 4 
>  .../xilinx/zynqmp/zynqmp-zc1751-xm016-dc2/psu_init_gpl.c  | 8 
>  .../xilinx/zynqmp/zynqmp-zc1751-xm017-dc3/psu_init_gpl.c  | 8 
>  .../xilinx/zynqmp/zynqmp-zc1751-xm018-dc4/psu_init_gpl.c  | 8 
>  .../xilinx/zynqmp/zynqmp-zc1751-xm019-dc5/psu_init_gpl.c  | 8 
>  board/xilinx/zynqmp/zynqmp-zcu100-revC/psu_init_gpl.c | 8 
>  board/xilinx/zynqmp/zynqmp-zcu102-rev1.0/psu_init_gpl.c   | 8 
>  board/xilinx/zynqmp/zynqmp-zcu102-revA/psu_init_gpl.c | 8 
>  board/xilinx/zynqmp/zynqmp-zcu104-revA/psu_init_gpl.c | 8 
>  board/xilinx/zynqmp/zynqmp-zcu106-revA/psu_init_gpl.c | 8 
>  15 files changed, 104 deletions(-)
>
> diff --git 
> a/board/xilinx/zynqmp/avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0/psu_init_gpl.c
>  
> b/board/xilinx/zynqmp/avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0/psu_init_gpl.c
> index ac3f716392bd..d030e79770ce 100644
> --- 
> a/board/xilinx/zynqmp/avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0/psu_init_gpl.c
> +++ 
> b/board/xilinx/zynqmp/avnet-ultrazedev-cc-v1.0-ultrazedev-som-v1.0/psu_init_gpl.c
> @@ -506,14 +506,6 @@ static unsigned long psu_peripherals_init_data(void)
> psu_mask_write(0xFF5E0238, 0x8000U, 0xU);
> psu_mask_write(0xFF5E0238, 0x7800U, 0xU);
> psu_mask_write(0xFF5E0238, 0x0006U, 0xU);
> -   psu_mask_write(0xFF34, 0x00FFU, 0x0005U);
> -   psu_mask_write(0xFF18, 0xU, 0x008FU);
> -   psu_mask_write(0xFF00, 0x01FFU, 0x0017U);
> -   psu_mask_write(0xFF04, 0x03FFU, 0x0020U);
> -   psu_mask_write(0xFF010034, 0x00FFU, 0x0005U);
> -   psu_mask_write(0xFF010018, 0xU, 0x008FU);
> -   psu_mask_write(0xFF01, 0x01FFU, 0x0017U);
> -   psu_mask_write(0xFF010004, 0x03FFU, 0x0020U);
> psu_mask_write(0xFF5E0238, 0x0004U, 0xU);
> psu_mask_write(0xFF4B0024, 0x00FFU, 0x00FFU);
> psu_mask_write(0xFFCA5000, 0x1FFFU, 0xU);
> diff --git a/board/xilinx/zynqmp/zynqmp-a2197-revA/psu_init_gpl.c 
> b/board/xilinx/zynqmp/zynqmp-a2197-revA/psu_init_gpl.c
> index ac4a073e1bc3..be9992c90f29 100644
> --- a/board/xilinx/zynqmp/zynqmp-a2197-revA/psu_init_gpl.c
> +++ b/board/xilinx/zynqmp/zynqmp-a2197-revA/psu_init_gpl.c
> @@ -479,14 +479,6 @@ static unsigned long psu_peripherals_init_data(void)
> psu_mask_write(0xFF180324, 0x03C0U, 0xU);
> psu_mask_write(0xFF5E0238, 0x0600U, 0xU);
> psu_mask_write(0xFF5E0238, 0x0006U, 0xU);
> -   psu_mask_write(0xFF34, 0x00FFU, 0x0005U);
> -   psu_mask_write(0xFF18, 0xU, 0x008FU);
> -   psu_mask_write(0xFF00, 0x01FFU, 0x0017U);
> -   psu_mask_write(0xFF04, 0x03FFU, 0x0020U);
> -   psu_mask_write(0xFF010034, 0x00FFU, 0x0005U);
> -   psu_mask_write(0xFF010018, 0xU, 0x008FU);
> -   psu_mask_write(0xFF01, 0x01FFU, 0x0017U);
> -   psu_mask_write(0xFF010004, 0x03FFU, 0x0020U);
> psu_mask_write(0xFF5E0238, 0x0004U, 0xU);
> psu_mask_write(0xFF4B0024, 0x00FFU, 0x00FFU);
> psu_mask_write(0xFFCA5000, 0x1FFFU, 0xU);
> diff --git a/board/xilinx/zynqmp/zynqmp-zc1232-revA/psu_init_gpl.c 
> b/board/xilinx/zynqmp/zynqmp-zc1232-revA/psu_init_gpl.c
> index af6b49a97369..b8ea291f8bc6 100644
> --- a/board/xilinx/zynqmp/zynqmp-zc1232-revA/psu_init_gpl.c
> +++ b/board/xilinx/zynqmp/zynqmp-zc1232-revA/psu_init_gpl.c
> @@ -388,10 +388,6 @@ static unsigned long psu_peripherals_init_data(void)
> psu_mask_write(0xFF5E0238, 0x8000U, 0xU);
> psu_mask_write(0xFF5E0238, 0x7800U, 0xU);
> psu_mask_write(0xFF5E0238, 0x0002U, 0xU);
> -   psu_mask_write(0xFF34, 0x00FFU, 0x0005U);
> -   psu_mask_write(0xFF18, 0xU, 0x008FU);
> -   psu_mask_write(0xFF00, 0x01FFU, 0x0017U);
> -   psu_mask_write(0xFF04, 0x03FFU, 0x0020U);
> psu_mask_write(0xFF5E0238, 0x0004U, 0xU);
> psu_mask_write(0xFF4B0024, 0x00FFU, 0x00FFU);
> 

Re: [PATCH] arm: zynq: Remove low level UART setting

[Michal Simek]

pá 6. 12. 2019 v 9:44 odesílatel Michal Simek  napsal:
>
> There is no reason to do serial initializationin low level code. Uart
> driver does it already based on DT.
>
> Signed-off-by: Michal Simek 
> ---
>
>  .../zynq/zynq-syzygy-hub/ps7_init_gpl.c   |   4 -
>  .../zynq/zynq-topic-miami/ps7_init_gpl.c  |   8 -
>  .../zynq/zynq-topic-miamilite/ps7_init_gpl.c  |   8 -
>  .../zynq/zynq-topic-miamiplus/ps7_init_gpl.c  |   8 -
>  board/xilinx/zynq/zynq-cc108/ps7_init_gpl.c   |  12 --
>  .../zynq/zynq-dlc20-rev1.0/ps7_init_gpl.c |   4 -
>  .../xilinx/zynq/zynq-microzed/ps7_init_gpl.c  | 186 --
>  board/xilinx/zynq/zynq-zc702/ps7_init_gpl.c   | 186 --
>  board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c   | 186 --
>  .../zynq/zynq-zc770-xm010/ps7_init_gpl.c  |  12 --
>  .../zynq/zynq-zc770-xm011-x16/ps7_init_gpl.c  |  12 --
>  .../zynq/zynq-zc770-xm011/ps7_init_gpl.c  |  12 --
>  .../zynq/zynq-zc770-xm012/ps7_init_gpl.c  |  12 --
>  .../zynq/zynq-zc770-xm013/ps7_init_gpl.c  |  12 --
>  board/xilinx/zynq/zynq-zed/ps7_init_gpl.c | 186 --
>  board/xilinx/zynq/zynq-zturn/ps7_init_gpl.c   |   8 -
>  board/xilinx/zynq/zynq-zybo-z7/ps7_init_gpl.c |   4 -
>  board/xilinx/zynq/zynq-zybo/ps7_init_gpl.c| 186 --
>  18 files changed, 1046 deletions(-)
>
> diff --git a/board/opalkelly/zynq/zynq-syzygy-hub/ps7_init_gpl.c 
> b/board/opalkelly/zynq/zynq-syzygy-hub/ps7_init_gpl.c
> index 500dcce4da5c..80f2b83b5899 100644
> --- a/board/opalkelly/zynq/zynq-syzygy-hub/ps7_init_gpl.c
> +++ b/board/opalkelly/zynq/zynq-syzygy-hub/ps7_init_gpl.c
> @@ -220,10 +220,6 @@ unsigned long ps7_peripherals_init_data_3_0[] = {
> EMIT_MASKWRITE(0XF8000B50, 0x0180U, 0x0180U),
> EMIT_MASKWRITE(0XF8000B54, 0x0180U, 0x0180U),
> EMIT_WRITE(0XF804, 0x767BU),
> -   EMIT_MASKWRITE(0XE034, 0x00FFU, 0x0006U),
> -   EMIT_MASKWRITE(0XE018, 0xU, 0x007CU),
> -   EMIT_MASKWRITE(0XE000, 0x01FFU, 0x0017U),
> -   EMIT_MASKWRITE(0XE004, 0x03FFU, 0x0020U),
> EMIT_MASKWRITE(0XE000D000, 0x0008U, 0x0008U),
> EMIT_MASKWRITE(0XF8007000, 0x2000U, 0xU),
> EMIT_MASKWRITE(0XE000A244, 0x003FU, 0x00088000U),
> diff --git a/board/topic/zynq/zynq-topic-miami/ps7_init_gpl.c 
> b/board/topic/zynq/zynq-topic-miami/ps7_init_gpl.c
> index 8be3fb1e35a8..360beaef8ecf 100644
> --- a/board/topic/zynq/zynq-topic-miami/ps7_init_gpl.c
> +++ b/board/topic/zynq/zynq-topic-miami/ps7_init_gpl.c
> @@ -173,14 +173,6 @@ static unsigned long ps7_peripherals_init_data_3_0[] = {
> EMIT_MASKWRITE(0XF8000B50, 0x0180U, 0x0180U),
> EMIT_MASKWRITE(0XF8000B54, 0x0180U, 0x0180U),
> EMIT_MASKWRITE(0XF804, 0xU, 0x767BU),
> -   EMIT_MASKWRITE(0XE0001034, 0x00FFU, 0x0006U),
> -   EMIT_MASKWRITE(0XE0001018, 0xU, 0x007CU),
> -   EMIT_MASKWRITE(0XE0001000, 0x01FFU, 0x0017U),
> -   EMIT_MASKWRITE(0XE0001004, 0x03FFU, 0x0020U),
> -   EMIT_MASKWRITE(0XE034, 0x00FFU, 0x0006U),
> -   EMIT_MASKWRITE(0XE018, 0xU, 0x007CU),
> -   EMIT_MASKWRITE(0XE000, 0x01FFU, 0x0017U),
> -   EMIT_MASKWRITE(0XE004, 0x03FFU, 0x0020U),
> EMIT_MASKWRITE(0XE000D000, 0x000800FFU, 0x000800C1U),
> EMIT_MASKWRITE(0XF8007000, 0x2000U, 0xU),
> EMIT_MASKDELAY(0XF8F00200, 1),
> diff --git a/board/topic/zynq/zynq-topic-miamilite/ps7_init_gpl.c 
> b/board/topic/zynq/zynq-topic-miamilite/ps7_init_gpl.c
> index afec4038d3e7..ae4666f7d590 100644
> --- a/board/topic/zynq/zynq-topic-miamilite/ps7_init_gpl.c
> +++ b/board/topic/zynq/zynq-topic-miamilite/ps7_init_gpl.c
> @@ -173,14 +173,6 @@ static unsigned long ps7_peripherals_init_data_3_0[] = {
> EMIT_MASKWRITE(0xF8000B50, 0x0180U, 0x0180U),
> EMIT_MASKWRITE(0xF8000B54, 0x0180U, 0x0180U),
> EMIT_MASKWRITE(0xF804, 0xU, 0x767BU),
> -   EMIT_MASKWRITE(0xE0001034, 0x00FFU, 0x0006U),
> -   EMIT_MASKWRITE(0xE0001018, 0xU, 0x007CU),
> -   EMIT_MASKWRITE(0xE0001000, 0x01FFU, 0x0017U),
> -   EMIT_MASKWRITE(0xE0001004, 0x03FFU, 0x0020U),
> -   EMIT_MASKWRITE(0xE034, 0x00FFU, 0x0006U),
> -   EMIT_MASKWRITE(0xE018, 0xU, 0x007CU),
> -   EMIT_MASKWRITE(0xE000, 0x01FFU, 0x0017U),
> -   EMIT_MASKWRITE(0xE004, 0x03FFU, 0x0020U),
> EMIT_MASKWRITE(0xE000D000, 0x000800FFU, 0x000800C1U),
> EMIT_MASKWRITE(0xF8007000, 0x2000U, 0xU),
> EMIT_MASKDELAY(0xF8F00200, 1),
> diff --git a/board/topic/zynq/zynq-topic-miamiplus/ps7_init_gpl.c 
> b/board/topic/zynq/zynq-topic-miamiplus/ps7_init_gpl.c
> index d90a350d3fe0..717955808de6 100644
> --- 

Re: [PATCH] arm64: zynqmp: Enable bind/unbind commands for all boards

[Michal Simek]

pá 6. 12. 2019 v 11:19 odesílatel Michal Simek  napsal:
>
> These commands are useful in connection to usb and other devices that's why
> enable it by default.
>
> Signed-off-by: Michal Simek 
> ---
>
>  configs/xilinx_zynqmp_zc1232_revA_defconfig  | 1 +
>  configs/xilinx_zynqmp_zc1254_revA_defconfig  | 1 +
>  configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 +
>  configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 +
>  configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig | 1 +
>  configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 1 +
>  configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig | 1 +
>  configs/xilinx_zynqmp_zcu102_rev1_0_defconfig| 1 +
>  configs/xilinx_zynqmp_zcu102_revA_defconfig  | 1 +
>  configs/xilinx_zynqmp_zcu102_revB_defconfig  | 1 +
>  configs/xilinx_zynqmp_zcu104_revA_defconfig  | 1 +
>  configs/xilinx_zynqmp_zcu104_revC_defconfig  | 1 +
>  configs/xilinx_zynqmp_zcu106_revA_defconfig  | 1 +
>  configs/xilinx_zynqmp_zcu111_revA_defconfig  | 1 +
>  configs/xilinx_zynqmp_zcu1275_revA_defconfig | 1 +
>  configs/xilinx_zynqmp_zcu1275_revB_defconfig | 1 +
>  configs/xilinx_zynqmp_zcu216_revA_defconfig  | 1 +
>  17 files changed, 17 insertions(+)
>
> diff --git a/configs/xilinx_zynqmp_zc1232_revA_defconfig 
> b/configs/xilinx_zynqmp_zc1232_revA_defconfig
> index 73617cedd236..f79d803d3225 100644
> --- a/configs/xilinx_zynqmp_zc1232_revA_defconfig
> +++ b/configs/xilinx_zynqmp_zc1232_revA_defconfig
> @@ -18,6 +18,7 @@ CONFIG_SPL_RAM_SUPPORT=y
>  CONFIG_SPL_RAM_DEVICE=y
>  CONFIG_SPL_ATF=y
>  CONFIG_CMD_MEMTEST=y
> +CONFIG_CMD_BIND=y
>  CONFIG_CMD_CLK=y
>  CONFIG_CMD_FPGA_LOADBP=y
>  CONFIG_CMD_FPGA_LOADP=y
> diff --git a/configs/xilinx_zynqmp_zc1254_revA_defconfig 
> b/configs/xilinx_zynqmp_zc1254_revA_defconfig
> index 3341af14443f..bc3d0dfe2201 100644
> --- a/configs/xilinx_zynqmp_zc1254_revA_defconfig
> +++ b/configs/xilinx_zynqmp_zc1254_revA_defconfig
> @@ -18,6 +18,7 @@ CONFIG_SPL_RAM_SUPPORT=y
>  CONFIG_SPL_RAM_DEVICE=y
>  CONFIG_SPL_ATF=y
>  CONFIG_CMD_MEMTEST=y
> +CONFIG_CMD_BIND=y
>  CONFIG_CMD_CLK=y
>  CONFIG_CMD_FPGA_LOADBP=y
>  CONFIG_CMD_FPGA_LOADP=y
> diff --git a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig 
> b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
> index af79cf755249..65ce1ff2d337 100644
> --- a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
> +++ b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
> @@ -23,6 +23,7 @@ CONFIG_SPL_ATF=y
>  CONFIG_CMD_THOR_DOWNLOAD=y
>  CONFIG_CMD_MEMTEST=y
>  CONFIG_SYS_ALT_MEMTEST=y
> +CONFIG_CMD_BIND=y
>  CONFIG_CMD_CLK=y
>  CONFIG_CMD_DFU=y
>  CONFIG_CMD_FPGA_LOADBP=y
> diff --git a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig 
> b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
> index 986754018278..0492aba7f4a2 100644
> --- a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
> +++ b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
> @@ -23,6 +23,7 @@ CONFIG_SPL_ATF=y
>  CONFIG_CMD_THOR_DOWNLOAD=y
>  CONFIG_CMD_MEMTEST=y
>  CONFIG_SYS_ALT_MEMTEST=y
> +CONFIG_CMD_BIND=y
>  CONFIG_CMD_CLK=y
>  CONFIG_CMD_DFU=y
>  # CONFIG_CMD_FLASH is not set
> diff --git a/configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig 
> b/configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig
> index b22ebdac1505..84a2cd77f766 100644
> --- a/configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig
> +++ b/configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig
> @@ -19,6 +19,7 @@ CONFIG_SPL_RAM_SUPPORT=y
>  CONFIG_SPL_RAM_DEVICE=y
>  CONFIG_SPL_ATF=y
>  CONFIG_CMD_MEMTEST=y
> +CONFIG_CMD_BIND=y
>  CONFIG_CMD_CLK=y
>  CONFIG_CMD_DFU=y
>  # CONFIG_CMD_FLASH is not set
> diff --git a/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig 
> b/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
> index a59194288ba9..e6ea056a77d2 100644
> --- a/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
> +++ b/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
> @@ -19,6 +19,7 @@ CONFIG_SPL_RAM_DEVICE=y
>  CONFIG_SPL_ATF=y
>  CONFIG_CMD_MEMTEST=y
>  CONFIG_SYS_ALT_MEMTEST=y
> +CONFIG_CMD_BIND=y
>  CONFIG_CMD_CLK=y
>  CONFIG_CMD_FPGA_LOADBP=y
>  CONFIG_CMD_FPGA_LOADP=y
> diff --git a/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig 
> b/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
> index e1cc92425188..92cfe22d16a1 100644
> --- a/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
> +++ b/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
> @@ -18,6 +18,7 @@ CONFIG_SPL_RAM_DEVICE=y
>  CONFIG_SPL_ATF=y
>  CONFIG_CMD_MEMTEST=y
>  CONFIG_SYS_ALT_MEMTEST=y
> +CONFIG_CMD_BIND=y
>  CONFIG_CMD_CLK=y
>  CONFIG_CMD_FPGA_LOADBP=y
>  CONFIG_CMD_FPGA_LOADP=y
> diff --git a/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig 
> b/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig
> index e924c0347f17..af4a6df5933a 100644
> --- a/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig
> +++ b/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig
> @@ -25,6 +25,7 @@ CONFIG_SPL_ATF=y
>  CONFIG_CMD_THOR_DOWNLOAD=y
>  CONFIG_CMD_MEMTEST=y
>  CONFIG_SYS_ALT_MEMTEST=y
> +CONFIG_CMD_BIND=y
>  

Re: [PATCH] arm64: zynqmp: Fix symlinks to SC psu_init* files

[Michal Simek]

po 9. 12. 2019 v 15:57 odesílatel Michal Simek  napsal:
>
> Names have to match device tree file names. Also add missing one.
>
> Fixes: 50d92833477e ("arm64: zynqmp: Sync names for SC with Versal")
> Signed-off-by: Michal Simek 
> ---
>
>  .../zynqmp/{zynqmp-a2197-g-revA => zynqmp-g-a2197-00-revA}   | 0
>  .../zynqmp/{zynqmp-a2197-m-revA => zynqmp-m-a2197-01-revA}   | 0
>  .../zynqmp/{zynqmp-a2197-p-revA => zynqmp-m-a2197-02-revA}   | 0
>  board/xilinx/zynqmp/zynqmp-m-a2197-03-revA   | 1 +
>  board/xilinx/zynqmp/zynqmp-p-a2197-00-revA   | 1 +
>  5 files changed, 2 insertions(+)
>  rename board/xilinx/zynqmp/{zynqmp-a2197-g-revA => zynqmp-g-a2197-00-revA} 
> (100%)
>  rename board/xilinx/zynqmp/{zynqmp-a2197-m-revA => zynqmp-m-a2197-01-revA} 
> (100%)
>  rename board/xilinx/zynqmp/{zynqmp-a2197-p-revA => zynqmp-m-a2197-02-revA} 
> (100%)
>  create mode 12 board/xilinx/zynqmp/zynqmp-m-a2197-03-revA
>  create mode 12 board/xilinx/zynqmp/zynqmp-p-a2197-00-revA
>
> diff --git a/board/xilinx/zynqmp/zynqmp-a2197-g-revA 
> b/board/xilinx/zynqmp/zynqmp-g-a2197-00-revA
> similarity index 100%
> rename from board/xilinx/zynqmp/zynqmp-a2197-g-revA
> rename to board/xilinx/zynqmp/zynqmp-g-a2197-00-revA
> diff --git a/board/xilinx/zynqmp/zynqmp-a2197-m-revA 
> b/board/xilinx/zynqmp/zynqmp-m-a2197-01-revA
> similarity index 100%
> rename from board/xilinx/zynqmp/zynqmp-a2197-m-revA
> rename to board/xilinx/zynqmp/zynqmp-m-a2197-01-revA
> diff --git a/board/xilinx/zynqmp/zynqmp-a2197-p-revA 
> b/board/xilinx/zynqmp/zynqmp-m-a2197-02-revA
> similarity index 100%
> rename from board/xilinx/zynqmp/zynqmp-a2197-p-revA
> rename to board/xilinx/zynqmp/zynqmp-m-a2197-02-revA
> diff --git a/board/xilinx/zynqmp/zynqmp-m-a2197-03-revA 
> b/board/xilinx/zynqmp/zynqmp-m-a2197-03-revA
> new file mode 12
> index ..a64c140b860a
> --- /dev/null
> +++ b/board/xilinx/zynqmp/zynqmp-m-a2197-03-revA
> @@ -0,0 +1 @@
> +zynqmp-a2197-revA
> \ No newline at end of file
> diff --git a/board/xilinx/zynqmp/zynqmp-p-a2197-00-revA 
> b/board/xilinx/zynqmp/zynqmp-p-a2197-00-revA
> new file mode 12
> index ..a64c140b860a
> --- /dev/null
> +++ b/board/xilinx/zynqmp/zynqmp-p-a2197-00-revA
> @@ -0,0 +1 @@
> +zynqmp-a2197-revA
> \ No newline at end of file
> --
> 2.24.0
>

Applied.
M


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH] arm64: zynqmp: Remove nand partition description from mini-nand

[Michal Simek]

pá 6. 12. 2019 v 11:14 odesílatel Michal Simek  napsal:
>
> There shouldn't be a need to use any partition description because it
> can be used for writing data anywhere.
>
> Signed-off-by: Michal Simek 
> ---
>
>  arch/arm/dts/zynqmp-mini-nand.dts | 49 ---
>  1 file changed, 49 deletions(-)
>
> diff --git a/arch/arm/dts/zynqmp-mini-nand.dts 
> b/arch/arm/dts/zynqmp-mini-nand.dts
> index 93aa193f0178..d376ade83472 100644
> --- a/arch/arm/dts/zynqmp-mini-nand.dts
> +++ b/arch/arm/dts/zynqmp-mini-nand.dts
> @@ -50,55 +50,6 @@
> #size-cells = <1>;
> arasan,has-mdma;
> num-cs = <2>;
> -
> -   partition@0 {   /* for testing purpose */
> -   label = "nand-fsbl-uboot";
> -   reg = <0x0 0x0 0x40>;
> -   };
> -   partition@1 {   /* for testing purpose */
> -   label = "nand-linux";
> -   reg = <0x0 0x40 0x140>;
> -   };
> -   partition@2 {   /* for testing purpose */
> -   label = "nand-device-tree";
> -   reg = <0x0 0x180 0x40>;
> -   };
> -   partition@3 {   /* for testing purpose */
> -   label = "nand-rootfs";
> -   reg = <0x0 0x1C0 0x140>;
> -   };
> -   partition@4 {   /* for testing purpose */
> -   label = "nand-bitstream";
> -   reg = <0x0 0x300 0x40>;
> -   };
> -   partition@5 {   /* for testing purpose */
> -   label = "nand-misc";
> -   reg = <0x0 0x340 0xFCC0>;
> -   };
> -   partition@6 {   /* for testing purpose */
> -   label = "nand1-fsbl-uboot";
> -   reg = <0x1 0x0 0x40>;
> -   };
> -   partition@7 {   /* for testing purpose */
> -   label = "nand1-linux";
> -   reg = <0x1 0x40 0x140>;
> -   };
> -   partition@8 {   /* for testing purpose */
> -   label = "nand1-device-tree";
> -   reg = <0x1 0x180 0x40>;
> -   };
> -   partition@9 {   /* for testing purpose */
> -   label = "nand1-rootfs";
> -   reg = <0x1 0x1C0 0x140>;
> -   };
> -   partition@10 {  /* for testing purpose */
> -   label = "nand1-bitstream";
> -   reg = <0x1 0x300 0x40>;
> -   };
> -   partition@11 {  /* for testing purpose */
> -   label = "nand1-misc";
> -   reg = <0x1 0x340 0xFCC0>;
> -   };
> };
> };
>  };
> --
> 2.24.0
>

Applied.
M



-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH] arm64: zynqmp: Add board_boot_order for MMC boot extension

[Michal Simek]

po 9. 12. 2019 v 15:58 odesílatel Michal Simek  napsal:
>
> In past SPL_ZYNQMP_TWO_SDHCI symbol was introduced to handle boards with
> two sdhci controllers. The problem was that U-Boot is registering
> controllers based on aliases in DT but bootmode targets specific controller
> ID. That's why on boards with one "second" sdhci controller bootmode was
> pointing to second controller(MMC2) but alias was setup to mmc0 (the first
> controller). And SPL requires to point to mmc0 in this case.
>
> Long time ago commit f101e4bd3703
> ("spl: add support for alternative boot device") added support for handling
> multiple bootmodes in SPL. Use this functionality and setup second sdhci
> controller as backup boot device.
>
> Below is table with behavior:
> HW/bootmode  bootorder
> sd0/sd0  mmc0/mmc1 (mmc1 never called)
> sd1/sd1  mmc1/mmc0 (mmc0 fails and mmc1 is called)
> sd0+sd1/sd0  mmc0/mmc1 (mmc1 never called)
> sd0+sd1/sd1  mmc1/mmc0 (mmc0 never called)
>
> All other bootmodes are not affected but order can be extended to cover
> advance boot flows.
>
> Signed-off-by: Michal Simek 
> ---
>
>  arch/arm/mach-zynqmp/Kconfig   | 11 ---
>  arch/arm/mach-zynqmp/spl.c | 14 ++
>  ...ltrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig |  1 -
>  configs/xilinx_zynqmp_p_a2197_00_revA_defconfig|  1 -
>  configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig   |  1 -
>  5 files changed, 10 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/mach-zynqmp/Kconfig b/arch/arm/mach-zynqmp/Kconfig
> index 6cf17eb94e11..d82a737a699e 100644
> --- a/arch/arm/mach-zynqmp/Kconfig
> +++ b/arch/arm/mach-zynqmp/Kconfig
> @@ -117,17 +117,6 @@ config SPL_ZYNQMP_ALT_BOOTMODE_ENABLED
>  config ZYNQ_SDHCI_MAX_FREQ
> default 2
>
> -config SPL_ZYNQMP_TWO_SDHCI
> -   bool "Enable booting from both SDHCIs"
> -   depends on SPL
> -   help
> - This option reflects that board has two SDHCI controllers which
> - platform can use as boot device. This option ensures that SPL will
> - setup BOOT_DEVICE_MMC2 for SDHCI1 controller and BOOT_DEVICE_MMC1 
> for
> - SDHCI0 controller. Platforms which have only one SDHCI controller
> - shouldn't enable this option because it for software SDHCI0 or 
> SDHCI1
> - are both covered by BOOT_DEVICE_MMC1.
> -
>  config SPL_ZYNQMP_ALT_BOOTMODE
> hex
> default 0x0 if JTAG_MODE
> diff --git a/arch/arm/mach-zynqmp/spl.c b/arch/arm/mach-zynqmp/spl.c
> index 8bb1cdf69e1b..37f690d9b958 100644
> --- a/arch/arm/mach-zynqmp/spl.c
> +++ b/arch/arm/mach-zynqmp/spl.c
> @@ -65,6 +65,16 @@ void spl_board_init(void)
>  }
>  #endif
>
> +void board_boot_order(u32 *spl_boot_list)
> +{
> +   spl_boot_list[0] = spl_boot_device();
> +
> +   if (spl_boot_list[0] == BOOT_DEVICE_MMC1)
> +   spl_boot_list[1] = BOOT_DEVICE_MMC2;
> +   if (spl_boot_list[0] == BOOT_DEVICE_MMC2)
> +   spl_boot_list[1] = BOOT_DEVICE_MMC1;
> +}
> +
>  u32 spl_boot_device(void)
>  {
> u32 reg = 0;
> @@ -88,11 +98,7 @@ u32 spl_boot_device(void)
>  #ifdef CONFIG_SPL_MMC_SUPPORT
> case SD_MODE1:
> case SD1_LSHFT_MODE: /* not working on silicon v1 */
> -/* if both controllers enabled, then these two are the second controller */
> -#ifdef CONFIG_SPL_ZYNQMP_TWO_SDHCI
> return BOOT_DEVICE_MMC2;
> -/* else, fall through, the one SDHCI controller that is enabled is number 1 
> */
> -#endif
> case SD_MODE:
> case EMMC_MODE:
> return BOOT_DEVICE_MMC1;
> diff --git a/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig 
> b/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig
> index 177558db4198..280983d187a1 100644
> --- a/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig
> +++ b/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig
> @@ -7,7 +7,6 @@ CONFIG_DEBUG_UART_BASE=0xff00
>  CONFIG_DEBUG_UART_CLOCK=1
>  CONFIG_SPL_SPI_FLASH_SUPPORT=y
>  CONFIG_SPL_SPI_SUPPORT=y
> -CONFIG_SPL_ZYNQMP_TWO_SDHCI=y
>  CONFIG_DEBUG_UART=y
>  CONFIG_DISTRO_DEFAULTS=y
>  CONFIG_FIT=y
> diff --git a/configs/xilinx_zynqmp_p_a2197_00_revA_defconfig 
> b/configs/xilinx_zynqmp_p_a2197_00_revA_defconfig
> index ba2cbaba58e9..f206be8a3145 100644
> --- a/configs/xilinx_zynqmp_p_a2197_00_revA_defconfig
> +++ b/configs/xilinx_zynqmp_p_a2197_00_revA_defconfig
> @@ -9,7 +9,6 @@ CONFIG_IDENT_STRING=" Xilinx ZynqMP SC for Versal"
>  CONFIG_SPL_SPI_FLASH_SUPPORT=y
>  CONFIG_SPL_SPI_SUPPORT=y
>  CONFIG_ZYNQMP_USB=y
> -CONFIG_SPL_ZYNQMP_TWO_SDHCI=y
>  CONFIG_DEBUG_UART=y
>  CONFIG_AHCI=y
>  CONFIG_DISTRO_DEFAULTS=y
> diff --git a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig 
> b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
> index 65ce1ff2d337..c7524f630788 100644
> --- a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
> +++ b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
> @@ 

Re: [PATCH] arm64: zynqmp: Fix return value of board_fit_config_name_match

[Michal Simek]

po 9. 12. 2019 v 15:58 odesílatel Michal Simek  napsal:
>
> Empty implementation should not return 0 (success) because that mean that
> passed name matches the board configuration.
>
> Signed-off-by: Michal Simek 
> ---
>
>  arch/arm/mach-zynqmp/spl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-zynqmp/spl.c b/arch/arm/mach-zynqmp/spl.c
> index 37f690d9b958..76bafcdd2a38 100644
> --- a/arch/arm/mach-zynqmp/spl.c
> +++ b/arch/arm/mach-zynqmp/spl.c
> @@ -139,6 +139,6 @@ int board_fit_config_name_match(const char *name)
> /* Just empty function now - can't decide what to choose */
> debug("%s: %s\n", __func__, name);
>
> -   return 0;
> +   return -1;
>  }
>  #endif
> --
> 2.24.0
>

Applied.
M

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH 0/2] Enable private ATF handoff structure

[Michal Simek]

čt 19. 12. 2019 v 18:32 odesílatel Michal Simek
 napsal:
>
> Hi,
>
> Xilinx ZynqMP platform is using from the beggining specific structure which
> is passed from FSBL/SPL to ATF.
> Maybe in future both options can be supported by ATF and we can remove this
> private structure completely. But as of now bl31_params are completely
> ignored by ATF by RESET_TO_BL31=1 build flag.
>
> Thanks,
> Michal
>
>
> Michal Simek (2):
>   spl: atf: Enable option to rewrite bl2_plat_get_bl31_params()
>   arm: zynqmp: Wire SPL/ATF handoff structure properly
>
>  arch/arm/mach-zynqmp/handoff.c| 17 +++-
>  arch/arm/mach-zynqmp/include/mach/sys_proto.h |  2 --
>  arch/arm/mach-zynqmp/spl.c|  2 --
>  common/spl/spl_atf.c  | 15 +-
>  include/spl.h | 20 +++
>  5 files changed, 33 insertions(+), 23 deletions(-)
>
> --
> 2.24.0
>

Applied.
M

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH] arm: xilinx: Use device tree which can be passed on cmd line

[Michal Simek]

po 9. 12. 2019 v 16:00 odesílatel Michal Simek  napsal:
>
> DEVICE_TREE variable has been added by commit 6ab6b2afa091
> ("dts: re-write dts/Makefile more simply with Kbuild")
> where DT can be specified on command line. If it is not then
> CONFIG_DEFAULT_DEVICE_TREE is used to ensure backward compatibility.
>
> Signed-off-by: Michal Simek 
> ---
>
>  board/xilinx/zynq/Makefile   | 2 +-
>  board/xilinx/zynqmp/Makefile | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/board/xilinx/zynq/Makefile b/board/xilinx/zynq/Makefile
> index 8d3301543959..6a2acee108fa 100644
> --- a/board/xilinx/zynq/Makefile
> +++ b/board/xilinx/zynq/Makefile
> @@ -14,7 +14,7 @@ spl/board/xilinx/zynq/ps_init_gpl.o 
> board/xilinx/zynq/ps_init_gpl.o: $(PS_INIT_F
>  endif
>
>  ifeq ($(init-objs),)
> -hw-platform-y :=$(shell echo $(CONFIG_DEFAULT_DEVICE_TREE))
> +hw-platform-y :=$(shell echo $(DEVICE_TREE))
>  init-objs := $(if $(wildcard 
> $(srctree)/$(src)/$(hw-platform-y)/ps7_init_gpl.c),\
> $(hw-platform-y)/ps7_init_gpl.o)
>  endif
> diff --git a/board/xilinx/zynqmp/Makefile b/board/xilinx/zynqmp/Makefile
> index 5ace6cc1b478..174f4ed24be3 100644
> --- a/board/xilinx/zynqmp/Makefile
> +++ b/board/xilinx/zynqmp/Makefile
> @@ -14,7 +14,7 @@ spl/board/xilinx/zynqmp/ps_init_gpl.o 
> board/xilinx/zynqmp/ps_init_gpl.o: $(PS_IN
>  endif
>
>  ifeq ($(init-objs),)
> -hw-platform-y :=$(shell echo $(CONFIG_DEFAULT_DEVICE_TREE))
> +hw-platform-y :=$(shell echo $(DEVICE_TREE))
>  init-objs := $(if $(wildcard 
> $(srctree)/$(src)/$(hw-platform-y)/psu_init_gpl.c),\
> $(hw-platform-y)/psu_init_gpl.o)
>  endif
> --
> 2.24.0
>

Applied.
M

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

[PATCH] riscv: sifive: fu540: Enable saving environment in MMC

[Bin Meng]

At present U-Boot environment is not saved so it's a little bit
inconvenient if booting kernel via network as each time we need
input the network environment variables from U-Boot shell.

We already have the MMC support and let's enable saveenv with that.

Signed-off-by: Bin Meng 
---

 configs/sifive_fu540_defconfig | 2 ++
 include/configs/sifive-fu540.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig
index 7d38ec9..6f9e619 100644
--- a/configs/sifive_fu540_defconfig
+++ b/configs/sifive_fu540_defconfig
@@ -1,5 +1,6 @@
 CONFIG_RISCV=y
 CONFIG_ENV_SIZE=0x2
+CONFIG_ENV_OFFSET=0x100
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_TARGET_SIFIVE_FU540=y
 CONFIG_ARCH_RV64I=y
@@ -11,5 +12,6 @@ CONFIG_DEFAULT_DEVICE_TREE="hifive-unleashed-a00"
 CONFIG_DISPLAY_CPUINFO=y
 CONFIG_DISPLAY_BOARDINFO=y
 CONFIG_OF_SEPARATE=y
+CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_DM_MTD=y
diff --git a/include/configs/sifive-fu540.h b/include/configs/sifive-fu540.h
index 2756ed5..fb829be 100644
--- a/include/configs/sifive-fu540.h
+++ b/include/configs/sifive-fu540.h
@@ -24,6 +24,8 @@
 
 /* Environment options */
 
+#define CONFIG_SYS_MMC_ENV_DEV 0
+
 #define BOOT_TARGET_DEVICES(func) \
func(MMC, mmc, 0) \
func(DHCP, dhcp, na)
-- 
2.7.4

Re: [PATCH 0/2] mtd: nand: Move zynq nand driver to driver model

[Michal Simek]

po 6. 1. 2020 v 10:32 odesílatel Michal Simek  napsal:
>
> Hi,
>
> This series is moving Xilinx Zynq NAND driver to driver model.
> It allows us to remove hardcoded base address of smc and nand controller
> and get base addresses from device tree.
>
> Thanks,
> Michal
>
>
> Ashok Reddy Soma (2):
>   zynq: mtd: nand: Move zynq nand driver to driver model
>   zynq: mtd: nand: Remove hardcoded base addresses
>
>  arch/arm/mach-zynq/include/mach/hardware.h |   2 -
>  drivers/mtd/nand/raw/Kconfig   |   1 +
>  drivers/mtd/nand/raw/zynq_nand.c   | 132 ++---
>  3 files changed, 88 insertions(+), 47 deletions(-)
>
> --
> 2.24.0
>

Applied.
M


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH v2] test/py: hush_if_test: Add tests to cover octal/hex values

[Michal Simek]

po 6. 1. 2020 v 10:18 odesílatel Michal Simek  napsal:
>
> Extend test suite to cover also automatic octal/hex converstions which
> haven't been implemented in past.
>
> Signed-off-by: Michal Simek 
> Acked-by: Stephen Warren 
> Reviewed-by: Simon Goldschmidt 
> ---
>
> Changes in v2:
> - Based on discussion with Simon add TODO
>
> Depends on https://lists.denx.de/pipermail/u-boot/2019-September/383309.html
>
> There are of course other tests which we can run but not sure if make sense
> to have there all combinations. The most interesting are mixed tests which
> are failing before patch above is applied.
> Definitely please let me know if you want to add any other test.
>
> ---
>  test/py/tests/test_hush_if_test.py | 31 ++
>  1 file changed, 31 insertions(+)
>
> diff --git a/test/py/tests/test_hush_if_test.py 
> b/test/py/tests/test_hush_if_test.py
> index bba8d41d9648..d117921a6ac7 100644
> --- a/test/py/tests/test_hush_if_test.py
> +++ b/test/py/tests/test_hush_if_test.py
> @@ -7,6 +7,10 @@ import os
>  import os.path
>  import pytest
>
> +# TODO: These tests should be converted to a C test.
> +# For more information please take a look at the thread
> +# https://lists.denx.de/pipermail/u-boot/2019-October/388732.html
> +
>  pytestmark = pytest.mark.buildconfigspec('hush_parser')
>
>  # The list of "if test" conditions to test.
> @@ -52,6 +56,33 @@ subtests = (
>  ('test 123 -ge 123', True),
>  ('test 123 -ge 456', False),
>
> +# Octal tests
> +
> +('test 010 -eq 010', True),
> +('test 010 -eq 011', False),
> +
> +('test 010 -ne 011', True),
> +('test 010 -ne 010', False),
> +
> +# Hexadecimal tests
> +
> +('test 0x200 -gt 0x201', False),
> +('test 0x200 -gt 0x200', False),
> +('test 0x200 -gt 0x1ff', True),
> +
> +# Mixed tests
> +
> +('test 010 -eq 10', False),
> +('test 010 -ne 10', True),
> +('test 0xa -eq 10', True),
> +('test 0xa -eq 012', True),
> +
> +('test 200 -gt 0x1ff', False),
> +('test 0x200 -gt 1ff', True),
> +('test 0x200 -lt 1ff', False),
> +('test 0x200 -eq 200', False),
> +('test 0x200 -ne 200', True),
> +
>  ('test -z ""', True),
>  ('test -z "aaa"', False),
>
> --
> 2.24.0
>

Applied.
M

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH] ARM: zynq: Remove unused QSPI and USB addresses

[Michal Simek]

po 6. 1. 2020 v 10:34 odesílatel Michal Simek  napsal:
>
> All drivers should be converted to DM already that's why these hardcoded
> base addresses are not needed anymore.
>
> Signed-off-by: Michal Simek 
> ---
>
>  arch/arm/mach-zynq/include/mach/hardware.h | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/arch/arm/mach-zynq/include/mach/hardware.h 
> b/arch/arm/mach-zynq/include/mach/hardware.h
> index 0fe49aeb2276..89eb565c9412 100644
> --- a/arch/arm/mach-zynq/include/mach/hardware.h
> +++ b/arch/arm/mach-zynq/include/mach/hardware.h
> @@ -9,11 +9,8 @@
>  #define ZYNQ_SYS_CTRL_BASEADDR 0xF800
>  #define ZYNQ_DEV_CFG_APB_BASEADDR  0xF8007000
>  #define ZYNQ_SCU_BASEADDR  0xF8F0
> -#define ZYNQ_QSPI_BASEADDR 0xE000D000
>  #define ZYNQ_DDRC_BASEADDR 0xF8006000
>  #define ZYNQ_EFUSE_BASEADDR0xF800D000
> -#define ZYNQ_USB_BASEADDR0 0xE0002000
> -#define ZYNQ_USB_BASEADDR1 0xE0003000
>  #define ZYNQ_OCM_BASEADDR  0xFFFC
>
>  /* Bootmode setting values */
> --
> 2.24.0
>

Applied.
M


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH v3] arm64: zynqmp: Add support for u-boot.itb generation with ATF

[Michal Simek]

po 6. 1. 2020 v 10:28 odesílatel Michal Simek  napsal:
>
> Follow i.MX, Sunxi, RISC-V and Rockchip to generate u-boot.itb which
> includes U-Boot proper, ATF and DTBs in FIT format. ZynqMP supports FIT for
> quite a long time but with using out of tree solution. The patch is filling
> this gap.
>
> Tested on zcu102, zcu104 and zcu100/Ultra96.
>
> zcu100/Ultra96 v2.2 ATF build by:
> make DEBUG=0 ZYNQMP_CONSOLE=cadence1 RESET_TO_BL31=1 PLAT=zynqmp bl31
>
> Signed-off-by: Michal Simek 
> ---
>
> Changes in v3:
> - remove bl31 size report
> - detect u-boot address based on text base
> - enable build without ATF
> - add license to its
> - setup default option based on DEVICE_TREE variable
> - add note about readelf
> - add entry field to uboot
> - call only awk instead of grep and awk
> - add support for filling load DTB address based on 
> CONFIG_XILINX_OF_BOARD_DTB_ADDR
>
> Changes in v2:
> - Exchange u-boot/atf in config section
> - Use default ATF baseaddr from mainline
> - Update commit message
>
> Based on my discussion with Tom this should be converted to common shell
> script which will contain ITB generation. To enable this generation for
> ZynqMP make sense to include this script to let distribution like Fedora to
> use and conversion can be done on the top of this.
> For more information please take a look at
> https://lists.denx.de/pipermail/u-boot/2019-December/393556.html
>
> ---
>  Kconfig |   3 +-
>  arch/arm/mach-zynqmp/mkimage_fit_atf.sh | 123 
>  include/configs/xilinx_zynqmp.h |   6 +-
>  3 files changed, 130 insertions(+), 2 deletions(-)
>  create mode 100755 arch/arm/mach-zynqmp/mkimage_fit_atf.sh
>
> diff --git a/Kconfig b/Kconfig
> index 92fc4fc135a4..526a5a2e2bde 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -254,7 +254,7 @@ config BUILD_TARGET
> default "u-boot-spl.kwb" if ARCH_MVEBU && SPL
> default "u-boot-elf.srec" if RCAR_GEN3
> default "u-boot.itb" if SPL_LOAD_FIT && (ARCH_ROCKCHIP || \
> -   ARCH_SUNXI || RISCV)
> +   ARCH_SUNXI || RISCV || ARCH_ZYNQMP)
> default "u-boot.kwb" if KIRKWOOD
> default "u-boot-with-spl.bin" if ARCH_AT91 && SPL_NAND_SUPPORT
> default "u-boot-with-spl.imx" if ARCH_MX6 && SPL
> @@ -482,6 +482,7 @@ config SPL_FIT_GENERATOR
> depends on SPL_FIT
> default "board/sunxi/mksunxi_fit_atf.sh" if SPL_LOAD_FIT && ARCH_SUNXI
> default "arch/arm/mach-rockchip/make_fit_atf.py" if SPL_LOAD_FIT && 
> ARCH_ROCKCHIP
> +   default "arch/arm/mach-zynqmp/mkimage_fit_atf.sh" if SPL_LOAD_FIT && 
> ARCH_ZYNQMP
> default "arch/riscv/lib/mkimage_fit_opensbi.sh" if SPL_LOAD_FIT && 
> RISCV
> help
>   Specifies a (platform specific) script file to generate the FIT
> diff --git a/arch/arm/mach-zynqmp/mkimage_fit_atf.sh 
> b/arch/arm/mach-zynqmp/mkimage_fit_atf.sh
> new file mode 100755
> index ..9c6f973bfa70
> --- /dev/null
> +++ b/arch/arm/mach-zynqmp/mkimage_fit_atf.sh
> @@ -0,0 +1,123 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# script to generate FIT image source for Xilinx ZynqMP boards with
> +# ARM Trusted Firmware and multiple device trees (given on the command line)
> +#
> +# usage: $0  [ [ +
> +BL33="u-boot-nodtb.bin"
> +[ -z "$BL31" ] && BL31="bl31.bin"
> +# Can be also done as ${CROSS_COMPILE}readelf -l bl31.elf | awk '/Entry 
> point/ { print $3 }'
> +[ -z "$ATF_LOAD_ADDR" ] && ATF_LOAD_ADDR="0xfffea000"
> +
> +if [ -z "$BL33_LOAD_ADDR" ];then
> +   BL33_LOAD_ADDR=`awk '/CONFIG_SYS_TEXT_BASE/ { print $3 }' 
> include/generated/autoconf.h`
> +fi
> +
> +DTB_LOAD_ADDR=`awk '/CONFIG_XILINX_OF_BOARD_DTB_ADDR/ { print $3 }' 
> include/generated/autoconf.h`
> +if [ ! -z "$DTB_LOAD_ADDR" ]; then
> +   DTB_LOAD="load = <$DTB_LOAD_ADDR>;"
> +else
> +   DTB_LOAD=""
> +fi
> +
> +if [ -z "$*" ]; then
> +   DT=arch/arm/dts/${DEVICE_TREE}.dtb
> +else
> +   DT=$*
> +fi
> +
> +if [ ! -f $BL31 ]; then
> +   echo "WARNING: BL31 file $BL31 NOT found, resulting binary is 
> non-functional" >&2
> +   BL31=/dev/null
> +   # But U-Boot proper could be loaded in EL3 by specifying
> +   # firmware = "uboot";
> +   # instead of "atf" in config node
> +fi
> +
> +cat << __HEADER_EOF
> +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +
> +/dts-v1/;
> +
> +/ {
> +   description = "Configuration to load ATF before U-Boot";
> +
> +   images {
> +   uboot {
> +   description = "U-Boot (64-bit)";
> +   data = /incbin/("$BL33");
> +   type = "firmware";
> +   os = "u-boot";
> +   arch = "arm64";
> +   compression = "none";
> +   load = <$BL33_LOAD_ADDR>;
> +   entry = <$BL33_LOAD_ADDR>;
> +   hash {
> +

Re: [PATCH 0/2] arm64: zynqmp: Cleanup defconfigs

[Michal Simek]

po 9. 12. 2019 v 16:19 odesílatel Michal Simek  napsal:
>
> Hi,
>
> over years a lot of new Xilinx ZynqMP board have been added to U-Boot with
> corresponding defconfigs. Also a lot of drivers have been moved to DM that
> we can make one generic configuration with one defconfig.
> Nand still needs to be validated that's why dc2/dc3 are not moved yet.
>
> Boards can be build like this:
> export DEVICE_TREE="avnet-ultra96-rev1"
> make xilinx_zynqmp_virt_defconfig
> make -j
>
> Series depends on patches sent before that's why here is full tree:
> https://github.com/michalsimek/u-boot/tree/20191209-mainline
>
> Thanks,
> Michal
>
>
> Michal Simek (2):
>   arm64: zynqmp: Add missing Kconfig options to zynqmp_virt platform
>   arm64: zynqmp: Use zynqmp_virt platform
>
>  configs/avnet_ultra96_rev1_defconfig  |  90 --
>  configs/xilinx_zynqmp_a2197_revA_defconfig| 113 --
>  .../xilinx_zynqmp_e_a2197_00_revA_defconfig   | 111 -
>  .../xilinx_zynqmp_g_a2197_00_revA_defconfig   | 111 -
>  .../xilinx_zynqmp_m_a2197_01_revA_defconfig   | 111 -
>  .../xilinx_zynqmp_m_a2197_02_revA_defconfig   | 111 -
>  .../xilinx_zynqmp_m_a2197_03_revA_defconfig   | 111 -
>  .../xilinx_zynqmp_p_a2197_00_revA_defconfig   | 111 -
>  configs/xilinx_zynqmp_virt_defconfig  |  28 -
>  configs/xilinx_zynqmp_zc1232_revA_defconfig   |  50 
>  configs/xilinx_zynqmp_zc1254_revA_defconfig   |  50 
>  .../xilinx_zynqmp_zc1751_xm015_dc1_defconfig  |  95 ---
>  .../xilinx_zynqmp_zc1751_xm018_dc4_defconfig  |  68 ---
>  .../xilinx_zynqmp_zc1751_xm019_dc5_defconfig  |  61 --
>  configs/xilinx_zynqmp_zcu100_revC_defconfig   |  87 --
>  configs/xilinx_zynqmp_zcu102_rev1_0_defconfig | 112 -
>  configs/xilinx_zynqmp_zcu102_revA_defconfig   | 112 -
>  configs/xilinx_zynqmp_zcu102_revB_defconfig   | 111 -
>  configs/xilinx_zynqmp_zcu104_revA_defconfig   |  92 --
>  configs/xilinx_zynqmp_zcu104_revC_defconfig   |  96 ---
>  configs/xilinx_zynqmp_zcu106_revA_defconfig   | 105 
>  configs/xilinx_zynqmp_zcu111_revA_defconfig   |  94 ---
>  configs/xilinx_zynqmp_zcu1275_revA_defconfig  |  50 
>  configs/xilinx_zynqmp_zcu1275_revB_defconfig  |  59 -
>  configs/xilinx_zynqmp_zcu216_revA_defconfig   |  95 ---
>  25 files changed, 26 insertions(+), 2208 deletions(-)
>  delete mode 100644 configs/avnet_ultra96_rev1_defconfig
>  delete mode 100644 configs/xilinx_zynqmp_a2197_revA_defconfig
>  delete mode 100644 configs/xilinx_zynqmp_e_a2197_00_revA_defconfig
>  delete mode 100644 configs/xilinx_zynqmp_g_a2197_00_revA_defconfig
>  delete mode 100644 configs/xilinx_zynqmp_m_a2197_01_revA_defconfig
>  delete mode 100644 configs/xilinx_zynqmp_m_a2197_02_revA_defconfig
>  delete mode 100644 configs/xilinx_zynqmp_m_a2197_03_revA_defconfig
>  delete mode 100644 configs/xilinx_zynqmp_p_a2197_00_revA_defconfig
>  delete mode 100644 configs/xilinx_zynqmp_zc1232_revA_defconfig
>  delete mode 100644 configs/xilinx_zynqmp_zc1254_revA_defconfig
>  delete mode 100644 configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
>  delete mode 100644 configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
>  delete mode 100644 configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
>  delete mode 100644 configs/xilinx_zynqmp_zcu100_revC_defconfig
>  delete mode 100644 configs/xilinx_zynqmp_zcu102_rev1_0_defconfig
>  delete mode 100644 configs/xilinx_zynqmp_zcu102_revA_defconfig
>  delete mode 100644 configs/xilinx_zynqmp_zcu102_revB_defconfig
>  delete mode 100644 configs/xilinx_zynqmp_zcu104_revA_defconfig
>  delete mode 100644 configs/xilinx_zynqmp_zcu104_revC_defconfig
>  delete mode 100644 configs/xilinx_zynqmp_zcu106_revA_defconfig
>  delete mode 100644 configs/xilinx_zynqmp_zcu111_revA_defconfig
>  delete mode 100644 configs/xilinx_zynqmp_zcu1275_revA_defconfig
>  delete mode 100644 configs/xilinx_zynqmp_zcu1275_revB_defconfig
>  delete mode 100644 configs/xilinx_zynqmp_zcu216_revA_defconfig
>
> --
> 2.24.0
>

Applied but with default DT setup because I couldn't find proper setup
to pass CI loop.
Something to take a look later.

M


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH] arm64: zynqmp: Move PANIC to Kconfig

[Michal Simek]

út 17. 12. 2019 v 16:14 odesílatel Michal Simek
 napsal:
>
> Convert another option Kconfig.
>
> Reported-by: Robert P. J. Day 
> Signed-off-by: Michal Simek 
> ---
>
>  configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig | 1 +
>  configs/xilinx_zynqmp_mini_defconfig   | 1 +
>  configs/xilinx_zynqmp_mini_emmc0_defconfig | 1 +
>  configs/xilinx_zynqmp_mini_emmc1_defconfig | 1 +
>  configs/xilinx_zynqmp_mini_nand_defconfig  | 1 +
>  configs/xilinx_zynqmp_mini_nand_single_defconfig   | 1 +
>  configs/xilinx_zynqmp_mini_qspi_defconfig  | 1 +
>  configs/xilinx_zynqmp_virt_defconfig   | 1 +
>  configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig   | 1 +
>  configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig   | 1 +
>  include/configs/xilinx_zynqmp.h| 1 -
>  11 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig 
> b/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig
> index 280983d187a1..71e0d2726ed0 100644
> --- a/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig
> +++ b/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig
> @@ -56,5 +56,6 @@ CONFIG_DEBUG_UART_ANNOUNCE=y
>  CONFIG_ZYNQ_SERIAL=y
>  CONFIG_SPI=y
>  CONFIG_ZYNQMP_GQSPI=y
> +CONFIG_PANIC_HANG=y
>  CONFIG_OF_LIBFDT_OVERLAY=y
>  CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
> diff --git a/configs/xilinx_zynqmp_mini_defconfig 
> b/configs/xilinx_zynqmp_mini_defconfig
> index e861cf691056..d953c91a66ed 100644
> --- a/configs/xilinx_zynqmp_mini_defconfig
> +++ b/configs/xilinx_zynqmp_mini_defconfig
> @@ -49,4 +49,5 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
>  # CONFIG_DM_WARN is not set
>  # CONFIG_DM_DEVICE_REMOVE is not set
>  # CONFIG_MMC is not set
> +CONFIG_PANIC_HANG=y
>  # CONFIG_EFI_LOADER is not set
> diff --git a/configs/xilinx_zynqmp_mini_emmc0_defconfig 
> b/configs/xilinx_zynqmp_mini_emmc0_defconfig
> index 644223633bc7..cb2983d2476e 100644
> --- a/configs/xilinx_zynqmp_mini_emmc0_defconfig
> +++ b/configs/xilinx_zynqmp_mini_emmc0_defconfig
> @@ -55,4 +55,5 @@ CONFIG_SPL_DM_SEQ_ALIAS=y
>  CONFIG_SUPPORT_EMMC_BOOT=y
>  CONFIG_MMC_SDHCI=y
>  CONFIG_MMC_SDHCI_ZYNQ=y
> +CONFIG_PANIC_HANG=y
>  # CONFIG_EFI_LOADER is not set
> diff --git a/configs/xilinx_zynqmp_mini_emmc1_defconfig 
> b/configs/xilinx_zynqmp_mini_emmc1_defconfig
> index 5b468f1cfab6..f7bec364c386 100644
> --- a/configs/xilinx_zynqmp_mini_emmc1_defconfig
> +++ b/configs/xilinx_zynqmp_mini_emmc1_defconfig
> @@ -55,4 +55,5 @@ CONFIG_SPL_DM_SEQ_ALIAS=y
>  CONFIG_SUPPORT_EMMC_BOOT=y
>  CONFIG_MMC_SDHCI=y
>  CONFIG_MMC_SDHCI_ZYNQ=y
> +CONFIG_PANIC_HANG=y
>  # CONFIG_EFI_LOADER is not set
> diff --git a/configs/xilinx_zynqmp_mini_nand_defconfig 
> b/configs/xilinx_zynqmp_mini_nand_defconfig
> index d490f357b7ac..01e097199155 100644
> --- a/configs/xilinx_zynqmp_mini_nand_defconfig
> +++ b/configs/xilinx_zynqmp_mini_nand_defconfig
> @@ -51,4 +51,5 @@ CONFIG_MTD=y
>  CONFIG_MTD_RAW_NAND=y
>  CONFIG_NAND_ARASAN=y
>  CONFIG_SYS_NAND_MAX_CHIPS=2
> +CONFIG_PANIC_HANG=y
>  # CONFIG_EFI_LOADER is not set
> diff --git a/configs/xilinx_zynqmp_mini_nand_single_defconfig 
> b/configs/xilinx_zynqmp_mini_nand_single_defconfig
> index 21aafe1d275e..20e76cb11e8b 100644
> --- a/configs/xilinx_zynqmp_mini_nand_single_defconfig
> +++ b/configs/xilinx_zynqmp_mini_nand_single_defconfig
> @@ -50,4 +50,5 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
>  CONFIG_MTD=y
>  CONFIG_MTD_RAW_NAND=y
>  CONFIG_NAND_ARASAN=y
> +CONFIG_PANIC_HANG=y
>  # CONFIG_EFI_LOADER is not set
> diff --git a/configs/xilinx_zynqmp_mini_qspi_defconfig 
> b/configs/xilinx_zynqmp_mini_qspi_defconfig
> index 902dceb0f622..c6e03cd256d4 100644
> --- a/configs/xilinx_zynqmp_mini_qspi_defconfig
> +++ b/configs/xilinx_zynqmp_mini_qspi_defconfig
> @@ -62,4 +62,5 @@ CONFIG_SPI_FLASH_WINBOND=y
>  # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
>  CONFIG_SPI=y
>  CONFIG_ZYNQMP_GQSPI=y
> +CONFIG_PANIC_HANG=y
>  # CONFIG_EFI_LOADER is not set
> diff --git a/configs/xilinx_zynqmp_virt_defconfig 
> b/configs/xilinx_zynqmp_virt_defconfig
> index 4047475d3c11..ab46d16791ab 100644
> --- a/configs/xilinx_zynqmp_virt_defconfig
> +++ b/configs/xilinx_zynqmp_virt_defconfig
> @@ -123,6 +123,7 @@ CONFIG_USB_HOST_ETHER=y
>  CONFIG_USB_ETHER_ASIX=y
>  CONFIG_WDT=y
>  CONFIG_WDT_CDNS=y
> +CONFIG_PANIC_HANG=y
>  CONFIG_SPL_GZIP=y
>  CONFIG_OF_LIBFDT_OVERLAY=y
>  CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
> diff --git a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig 
> b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
> index ae85bb480526..0dfd38d46981 100644
> --- a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
> +++ b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
> @@ -85,4 +85,5 @@ CONFIG_USB_GADGET_MANUFACTURER="Xilinx"
>  CONFIG_USB_GADGET_VENDOR_NUM=0x03FD
>  

Re: [PATCH] arm64: zynqmp: Fix ina226 shunt resistor value

[Michal Simek]

po 6. 1. 2020 v 14:12 odesílatel Michal Simek  napsal:
>
> Fix shunt resistor value for ina226 vccint_ams and vccint_io_bram_ps.
> 2mOhm shunt was only in early board revision schematics but never got to
> real revA board.
>
> Signed-off-by: Michal Simek 
> ---
>
>  arch/arm/dts/zynqmp-zcu216-revA.dts | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/zynqmp-zcu216-revA.dts 
> b/arch/arm/dts/zynqmp-zcu216-revA.dts
> index dd9cd7b38f37..2dd15114a2c3 100644
> --- a/arch/arm/dts/zynqmp-zcu216-revA.dts
> +++ b/arch/arm/dts/zynqmp-zcu216-revA.dts
> @@ -253,7 +253,7 @@
> #io-channel-cells = <1>;
> label = "ina226-vccint-io-bram-ps";
> reg = <0x41>;
> -   shunt-resistor = <2000>;
> +   shunt-resistor = <5000>;
> };
> vcc1v8: ina226@42 { /* u60 */
> compatible = "ti,ina226";
> @@ -302,7 +302,7 @@
> #io-channel-cells = <1>;
> label = "ina226-vccint-ams";
> reg = <0x49>;
> -   shunt-resistor = <2000>;
> +   shunt-resistor = <5000>;
> };
> dac_avtt: ina226@4a { /* u59 */
> compatible = "ti,ina226";
> --
> 2.24.0
>

Applied.
M

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH] arm64: zynqmp: Correct the type of eeprom for zcu216 boards

[Michal Simek]

po 6. 1. 2020 v 14:13 odesílatel Michal Simek  napsal:
>
> From: Raviteja Narayanam 
>
> Corrected the type of eeprom in device tree for zcu216 boards according
> to schematic.
>
> Signed-off-by: Raviteja Narayanam 
> Signed-off-by: Michal Simek 
> ---
>
>  arch/arm/dts/zynqmp-zcu216-revA.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/zynqmp-zcu216-revA.dts 
> b/arch/arm/dts/zynqmp-zcu216-revA.dts
> index 2dd15114a2c3..c294e1b51a22 100644
> --- a/arch/arm/dts/zynqmp-zcu216-revA.dts
> +++ b/arch/arm/dts/zynqmp-zcu216-revA.dts
> @@ -401,7 +401,7 @@
>  * 768B - 1024B address 0x57
>  */
> eeprom: eeprom@54 { /* u21 */
> -   compatible = "atmel,24c08";
> +   compatible = "atmel,24c128";
> reg = <0x54>;
> };
> };
> --
> 2.24.0
>

Applied.
M

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH] firmware: Remove probe which is causing extra bind

[Michal Simek]

út 7. 1. 2020 v 11:18 odesílatel Michal Simek  napsal:
>
> From: Ashok Reddy Soma 
>
> Remove probe function dm_scan_fdt_dev from zynqmp-firmware driver.
> It is just binding its subnode zynqmp-clk.
> As a result one extra node is showing up in dm tree.
>
> This is not required, it is anyway bound from it's own zynqmp-clk driver.
>
> Signed-off-by: Ashok Reddy Soma 
> Signed-off-by: Michal Simek 
> ---
>
>  drivers/firmware/firmware-zynqmp.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/firmware/firmware-zynqmp.c 
> b/drivers/firmware/firmware-zynqmp.c
> index dea58b558102..2a2aa2f4f169 100644
> --- a/drivers/firmware/firmware-zynqmp.c
> +++ b/drivers/firmware/firmware-zynqmp.c
> @@ -187,6 +187,5 @@ static const struct udevice_id zynqmp_firmware_ids[] = {
>  U_BOOT_DRIVER(zynqmp_firmware) = {
> .id = UCLASS_FIRMWARE,
> .name = "zynqmp-firmware",
> -   .probe = dm_scan_fdt_dev,
> .of_match = zynqmp_firmware_ids,
>  };
> --
> 2.24.0
>

Applied.
M

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH] ARM: zynq: Add missing nand/smcc nodes

[Michal Simek]

út 7. 1. 2020 v 11:26 odesílatel Michal Simek  napsal:
>
> Add missing nand/smcc description.
>
> Signed-off-by: Michal Simek 
> ---
>
>  arch/arm/dts/zynq-zc770-xm011.dts | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/dts/zynq-zc770-xm011.dts 
> b/arch/arm/dts/zynq-zc770-xm011.dts
> index 1123bfc74392..61482017d65c 100644
> --- a/arch/arm/dts/zynq-zc770-xm011.dts
> +++ b/arch/arm/dts/zynq-zc770-xm011.dts
> @@ -47,6 +47,14 @@
> };
>  };
>
> + {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
> +};
> +
>   {
> status = "okay";
> num-cs = <4>;
> --
> 2.24.0
>

Applied.
M

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH] zynqmp: dts: Cleanup no-1-8-v property from sdhci dt nodes

[Michal Simek]

út 7. 1. 2020 v 12:33 odesílatel Michal Simek  napsal:
>
> From: T Karthik Reddy 
>
> Removed no-1-8-v property from zynqmp sdhci devicetree nodes to
> allow UHS-I capable SD cards to work in SD3.0 UHS modes.
>
> Boards that does not have level shifter for SD, does not support 1.8v.
> so no-1-8-v property to sdhci dt nodes should be present in zcu102 Rev-A,B,
> zcu104 Rev-A,C, zcu100, zcu1275 Rev-B boards.
>
> Signed-off-by: T Karthik Reddy 
> Signed-off-by: Michal Simek 
> ---
>
>  arch/arm/dts/zynqmp-zcu100-revC.dts  | 1 +
>  arch/arm/dts/zynqmp-zcu106-revA.dts  | 1 -
>  arch/arm/dts/zynqmp-zcu111-revA.dts  | 1 -
>  arch/arm/dts/zynqmp-zcu1275-revB.dts | 4 
>  4 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/zynqmp-zcu100-revC.dts 
> b/arch/arm/dts/zynqmp-zcu100-revC.dts
> index 14aa98de73fe..d1b0dab1c6d5 100644
> --- a/arch/arm/dts/zynqmp-zcu100-revC.dts
> +++ b/arch/arm/dts/zynqmp-zcu100-revC.dts
> @@ -259,6 +259,7 @@
> no-1-8-v;
> disable-wp;
> xlnx,mio_bank = <0>;
> +   no-1-8-v;
>  };
>
>   {
> diff --git a/arch/arm/dts/zynqmp-zcu106-revA.dts 
> b/arch/arm/dts/zynqmp-zcu106-revA.dts
> index b4dd10133008..7c73ff283e7a 100644
> --- a/arch/arm/dts/zynqmp-zcu106-revA.dts
> +++ b/arch/arm/dts/zynqmp-zcu106-revA.dts
> @@ -653,7 +653,6 @@
>  /* SD1 with level shifter */
>   {
> status = "okay";
> -   no-1-8-v;
> xlnx,mio_bank = <1>;
>  };
>
> diff --git a/arch/arm/dts/zynqmp-zcu111-revA.dts 
> b/arch/arm/dts/zynqmp-zcu111-revA.dts
> index aabf73dd6dc9..ca95d7e059a8 100644
> --- a/arch/arm/dts/zynqmp-zcu111-revA.dts
> +++ b/arch/arm/dts/zynqmp-zcu111-revA.dts
> @@ -566,7 +566,6 @@
>  /* SD1 with level shifter */
>   {
> status = "okay";
> -   no-1-8-v;
> disable-wp;
> xlnx,mio_bank = <1>;
>  };
> diff --git a/arch/arm/dts/zynqmp-zcu1275-revB.dts 
> b/arch/arm/dts/zynqmp-zcu1275-revB.dts
> index 34c4becd434a..2ec29b0b5d11 100644
> --- a/arch/arm/dts/zynqmp-zcu1275-revB.dts
> +++ b/arch/arm/dts/zynqmp-zcu1275-revB.dts
> @@ -75,6 +75,10 @@
>
>   {
> status = "okay";
> +   /*
> +* 1.0 revision has level shifter and this property should be
> +* removed for supporting UHS mode
> +*/
> no-1-8-v;
> xlnx,mio_bank = <1>;
>  };
> --
> 2.24.0
>

Applied.
M

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH] arm64: zynqmp: Add support for zcu208

[Michal Simek]

út 7. 1. 2020 v 12:12 odesílatel Michal Simek  napsal:
>
> The board is very similar to zcu216 with zu49dr device.
>
> Signed-off-by: Michal Simek 
> ---
>
>  arch/arm/dts/Makefile|   1 +
>  arch/arm/dts/zynqmp-zcu208-revA.dts  | 588 +++
>  configs/xilinx_zynqmp_virt_defconfig |   2 +-
>  3 files changed, 590 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/zynqmp-zcu208-revA.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 0127a91a8203..a82ba0da9abe 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -281,6 +281,7 @@ dtb-$(CONFIG_ARCH_ZYNQMP) += \
> zynqmp-zcu111-revA.dtb  \
> zynqmp-zcu1275-revA.dtb \
> zynqmp-zcu1275-revB.dtb \
> +   zynqmp-zcu208-revA.dtb  \
> zynqmp-zcu216-revA.dtb  \
> zynqmp-zc1232-revA.dtb  \
> zynqmp-zc1254-revA.dtb  \
> diff --git a/arch/arm/dts/zynqmp-zcu208-revA.dts 
> b/arch/arm/dts/zynqmp-zcu208-revA.dts
> new file mode 100644
> index ..9181060b893a
> --- /dev/null
> +++ b/arch/arm/dts/zynqmp-zcu208-revA.dts
> @@ -0,0 +1,588 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * dts file for Xilinx ZynqMP ZCU208
> + *
> + * (C) Copyright 2017 - 2019, Xilinx, Inc.
> + *
> + * Michal Simek 
> + */
> +
> +/dts-v1/;
> +
> +#include "zynqmp.dtsi"
> +#include "zynqmp-clk-ccf.dtsi"
> +#include 
> +#include 
> +#include 
> +
> +/ {
> +   model = "ZynqMP ZCU208 RevA";
> +   compatible = "xlnx,zynqmp-zcu208-revA", "xlnx,zynqmp-zcu208", 
> "xlnx,zynqmp";
> +
> +   aliases {
> +   ethernet0 = 
> +   gpio0 = 
> +   i2c0 = 
> +   i2c1 = 
> +   mmc0 = 
> +   rtc0 = 
> +   serial0 = 
> +   serial1 = 
> +   spi0 = 
> +   usb0 = 
> +   };
> +
> +   chosen {
> +   bootargs = "earlycon";
> +   stdout-path = "serial0:115200n8";
> +   xlnx,eeprom = 
> +   };
> +
> +   memory@0 {
> +   device_type = "memory";
> +   reg = <0x0 0x0 0x0 0x8000>, <0x8 0x 0x0 
> 0x8000>;
> +   };
> +
> +   gpio-keys {
> +   compatible = "gpio-keys";
> +   autorepeat;
> +   sw19 {
> +   label = "sw19";
> +   gpios = < 22 GPIO_ACTIVE_HIGH>;
> +   linux,code = ;
> +   gpio-key,wakeup;
> +   autorepeat;
> +   };
> +   };
> +
> +   leds {
> +   compatible = "gpio-leds";
> +   heartbeat_led {
> +   label = "heartbeat";
> +   gpios = < 23 GPIO_ACTIVE_HIGH>;
> +   linux,default-trigger = "heartbeat";
> +   };
> +   };
> +
> +   ina226-vccint {
> +   compatible = "iio-hwmon";
> +   io-channels = < 0>, < 1>, < 2>, < 
> 3>;
> +   };
> +   ina226-vccint-io-bram-ps {
> +   compatible = "iio-hwmon";
> +   io-channels = <_io_bram_ps 0>, <_io_bram_ps 1>, 
> <_io_bram_ps 2>, <_io_bram_ps 3>;
> +   };
> +   ina226-vcc1v8 {
> +   compatible = "iio-hwmon";
> +   io-channels = < 0>, < 1>, < 2>, < 
> 3>;
> +   };
> +   ina226-vcc1v2 {
> +   compatible = "iio-hwmon";
> +   io-channels = < 0>, < 1>, < 2>, < 
> 3>;
> +   };
> +   ina226-vadj-fmc {
> +   compatible = "iio-hwmon";
> +   io-channels = <_fmc 0>, <_fmc 1>, <_fmc 2>, 
> <_fmc 3>;
> +   };
> +   ina226-mgtavcc {
> +   compatible = "iio-hwmon";
> +   io-channels = < 0>, < 1>, < 2>, 
> < 3>;
> +   };
> +   ina226-mgt1v2 {
> +   compatible = "iio-hwmon";
> +   io-channels = < 0>, < 1>, < 2>, < 
> 3>;
> +   };
> +   ina226-mgt1v8 {
> +   compatible = "iio-hwmon";
> +   io-channels = < 0>, < 1>, < 2>, < 
> 3>;
> +   };
> +   ina226-vccint-ams {
> +   compatible = "iio-hwmon";
> +   io-channels = <_ams 0>, <_ams 1>, <_ams 
> 2>, <_ams 3>;
> +   };
> +   ina226-dac-avtt {
> +   compatible = "iio-hwmon";
> +   io-channels = <_avtt 0>, <_avtt 1>, <_avtt 2>, 
> <_avtt 3>;
> +   };
> +   ina226-dac-avccaux {
> +   compatible = "iio-hwmon";
> +   io-channels = <_avccaux 0>, <_avccaux 1>, 
> <_avccaux 2>, <_avccaux 3>;
> +   };
> +   ina226-adc-avcc {
> +   compatible = "iio-hwmon";
> +   io-channels = <_avcc 0>, <_avcc 1>, <_avcc 2>, 
> <_avcc 3>;
> +   };
> +   ina226-adc-avccaux {
> +   compatible = "iio-hwmon";
> +   io-channels = 

Re: [PATCH] net: zynq: Add a note about RX_BUF macro

[Michal Simek]

čt 9. 1. 2020 v 7:38 odesílatel Michal Simek  napsal:
>
> Record note about reducing number of BDs.
>
> Signed-off-by: Michal Simek 
> ---
>
>  drivers/net/zynq_gem.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
> index 78f94148b411..c3fe8e3c563f 100644
> --- a/drivers/net/zynq_gem.c
> +++ b/drivers/net/zynq_gem.c
> @@ -173,6 +173,7 @@ struct emac_bd {
>  #endif
>  };
>
> +/* Reduce amount of BUFs if you have limited amount of memory */
>  #define RX_BUF 32
>  /* Page table entries are set to 1MB, or multiples of 1MB
>   * (not < 1MB). driver uses less bd's so use 1MB bdspace.
> --
> 2.24.0
>

Applied.
M


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH] arm64: zynqmp: Switch zcu100 revC to use firmware clock driver

[Michal Simek]

út 7. 1. 2020 v 12:45 odesílatel Michal Simek  napsal:
>
> There is no issue with using firmware based driver instead of fixed clock
> one.
>
> Signed-off-by: Michal Simek 
> ---
>
>  arch/arm/dts/zynqmp-zcu100-revC.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/zynqmp-zcu100-revC.dts 
> b/arch/arm/dts/zynqmp-zcu100-revC.dts
> index d1b0dab1c6d5..c012f4c99b0e 100644
> --- a/arch/arm/dts/zynqmp-zcu100-revC.dts
> +++ b/arch/arm/dts/zynqmp-zcu100-revC.dts
> @@ -11,7 +11,7 @@
>  /dts-v1/;
>
>  #include "zynqmp.dtsi"
> -#include "zynqmp-clk.dtsi"
> +#include "zynqmp-clk-ccf.dtsi"
>  #include 
>  #include 
>  #include 
> --
> 2.24.0
>

Applied.
M

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs

Re: [PATCH 0/8] xilinx: Various DT changes and syncups

[Michal Simek]

On 09. 01. 20 15:18, Michal Simek wrote:
> Hi,
> 
> I am sending some patches to fix bugs we found in xilinx release cycle.
> Also do some syncs to keep kernel/u-boot dts in pseudo sync.
> 
> Thanks,
> Michal
> 
> 
> Jan Kiszka (1):
>   arm64: dts: zcu100-revC: Give wifi some time after power-on
> 
> Michal Simek (4):
>   arm64: zynqmp: Remove incorrect phy from DT for zcu102-revB up
>   arm64: dts: zynqmp: Fix node names which contain "_"
>   arm64: zynqmp: Sync gpio-controller name location
>   arm64: zynqmp: Sync gem clock nodes with mainline Linux
> 
> Rob Herring (1):
>   arm64: dts: Remove inconsistent use of 'arm,armv8' compatible string
> 
> Sudeep Holla (1):
>   arm64: dts: zynqmp: replace gpio-key,wakeup with wakeup-source
> property
> 
> Zumeng Chen (1):
>   ARM: dts: zynq: enablement of coresight topology
> 
>  arch/arm/dts/zynq-7000.dtsi | 135 
>  arch/arm/dts/zynqmp-clk-ccf.dtsi|  22 +++--
>  arch/arm/dts/zynqmp-clk.dtsi|   4 +-
>  arch/arm/dts/zynqmp-zcu100-revC.dts |   7 +-
>  arch/arm/dts/zynqmp-zcu102-revA.dts |  12 +--
>  arch/arm/dts/zynqmp-zcu102-revB.dts |   2 +-
>  arch/arm/dts/zynqmp-zcu106-revA.dts |   4 +-
>  arch/arm/dts/zynqmp-zcu111-revA.dts |   4 +-
>  arch/arm/dts/zynqmp.dtsi|  14 +--
>  9 files changed, 172 insertions(+), 32 deletions(-)
> 

Apply all.
M

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2 19/19] i2c: Update drivers to use enum for speed

[Heiko Schocher]

Hello Simon,

Am 03.01.2020 um 23:26 schrieb Simon Glass:

Convert the obvious uses of i2c bus speeds to use the enum.

Use livetree access for code changes.

Signed-off-by: Simon Glass 
---

Changes in v2: None

  drivers/i2c/exynos_hs_i2c.c  |  4 ++--
  drivers/i2c/fsl_i2c.c|  3 ++-
  drivers/i2c/i2c-cdns.c   |  2 +-
  drivers/i2c/i2c-uclass.c | 12 ++--
  drivers/i2c/i2c-uniphier-f.c |  2 +-
  drivers/i2c/i2c-uniphier.c   |  2 +-
  drivers/i2c/imx_lpi2c.c  |  8 
  drivers/i2c/mv_i2c.c |  4 ++--
  drivers/i2c/mvtwsi.c |  5 +++--
  drivers/i2c/omap24xx_i2c.c   |  3 ++-
  drivers/i2c/rcar_i2c.c   |  2 +-
  drivers/i2c/rcar_iic.c   |  2 +-
  drivers/i2c/s3c24x0_i2c.c|  4 ++--
  drivers/i2c/sandbox_i2c.c|  3 ++-
  14 files changed, 30 insertions(+), 26 deletions(-)


Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v2 18/19] i2c: stm32: Update to use standard enums for speed

[Heiko Schocher]

Hello Simon,

Am 03.01.2020 um 23:26 schrieb Simon Glass:

Update this driver to use the new standard enums for speed.

Note: This driver needs to move to driver model.

Signed-off-by: Simon Glass 
---

Changes in v2: None

  drivers/i2c/stm32f7_i2c.c | 43 +++
  1 file changed, 16 insertions(+), 27 deletions(-)


Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v2 16/19] i2c: kona_i2c: Update to use standard enums for speed

[Heiko Schocher]

Hello simon,

Am 03.01.2020 um 23:26 schrieb Simon Glass:

Update this driver to use the new standard enums for speed.

Note: This driver needs to move to driver model.

Signed-off-by: Simon Glass 
---

Changes in v2: None

  drivers/i2c/kona_i2c.c | 28 +++-
  1 file changed, 11 insertions(+), 17 deletions(-)


Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v2 17/19] i2c: omap: Update to use standard enums for speed

[Heiko Schocher]

Hello Simon,

Am 03.01.2020 um 23:26 schrieb Simon Glass:

Update this driver to use the new standard enums for speed.

Note: This driver needs to move to driver model.

Signed-off-by: Simon Glass 
---

Changes in v2: None

  drivers/i2c/omap24xx_i2c.c | 2 +-
  drivers/i2c/omap24xx_i2c.h | 4 
  2 files changed, 1 insertion(+), 5 deletions(-)


Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v2 15/19] i2c: designware_i2c: Update to use standard enums for speed

[Heiko Schocher]

Hello Simon,

Am 03.01.2020 um 23:26 schrieb Simon Glass:

Update this driver to use the new standard enums for speed.

Signed-off-by: Simon Glass 
---

Changes in v2: None

  drivers/i2c/designware_i2c.c | 10 +-
  drivers/i2c/designware_i2c.h | 13 -
  2 files changed, 5 insertions(+), 18 deletions(-)


Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v2 14/19] i2c: ast_i2c: Update to use standard enums for speed

[Heiko Schocher]

Hello Simon,

Am 03.01.2020 um 23:26 schrieb Simon Glass:

Update this driver to use the new standard enums for speed.

Signed-off-by: Simon Glass 
---

Changes in v2: None

  drivers/i2c/ast_i2c.c | 2 +-
  drivers/i2c/ast_i2c.h | 2 --
  2 files changed, 1 insertion(+), 3 deletions(-)


Thanks for cleaning this up!

Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v2 13/19] i2c: Add enums for i2c speed and address size

[Heiko Schocher]

Hello Simon,

Am 03.01.2020 um 23:26 schrieb Simon Glass:

Some drivers define their own speed enums and use their own constants for
speed. It makes sense to have a unified defition of the different speeds.

Since many controllers have to do different things for fast/high speed, it
is a good idea to have an enum for the mode.

Add these as well as an enum for the address mode.

Signed-off-by: Simon Glass 
---

Changes in v2: None

  include/i2c.h | 26 ++
  1 file changed, 26 insertions(+)


Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v2 12/19] i2c: designware_i2c: Add spike supression

[Heiko Schocher]

Hello Simon,

Am 03.01.2020 um 23:26 schrieb Simon Glass:

Some versions of this peripheral include a spike-suppression phase of the
bus. Add support for this.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Add a few more clean-up patches for i2c

  drivers/i2c/designware_i2c.c | 10 +-
  drivers/i2c/designware_i2c.h |  2 ++
  drivers/i2c/designware_i2c_pci.c |  2 ++
  3 files changed, 13 insertions(+), 1 deletion(-)


Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v2 11/19] i2c: designware_i2c: Rewrite timing calculation

[Heiko Schocher]

Hello Simon,

Am 03.01.2020 um 23:26 schrieb Simon Glass:

At present the driver can end up with timing parameters which are slightly
faster than those expected. It is possible to optimise the parameters to
get the best possible result.

Create a new function to handle the timing calculation. This uses a table
of defaults for each speed mode rather than writing it in code.

The function works by calculating the 'period' of each bit on the bus in
terms of the input clock to the controller (IC_CLK). It makes sure that
the constraints are met and that the different components of that period
add up correctly.

This code was taken from coreboot which has ended up with this same
driver, but now in a much-different form.

Signed-off-by: Simon Glass 
---

Changes in v2: None

  drivers/i2c/designware_i2c.c | 169 ++-
  1 file changed, 147 insertions(+), 22 deletions(-)


Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v2 10/19] i2c: designware_i2c: Put hold config in a struct

[Heiko Schocher]

Hello Simon,

Am 03.01.2020 um 23:26 schrieb Simon Glass:

Create a struct to hold the three timing parameters. This will make it
easier to move these calculations into a separate function in a later
patch.

Signed-off-by: Simon Glass 
---

Changes in v2: None

  drivers/i2c/designware_i2c.c | 82 
  1 file changed, 55 insertions(+), 27 deletions(-)


Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v2 09/19] i2c: designware_i2c: Drop scl_sda_cfg parameter

[Heiko Schocher]

Hello Simon,

Am 03.01.2020 um 23:26 schrieb Simon Glass:

Instead of passing this parameter into __dw_i2c_set_bus_speed(), pass in
the driver's private data, from which the function can obtain that
information. This allows the function to have access to the full state of
the driver.

Signed-off-by: Simon Glass 
---

Changes in v2: None

  drivers/i2c/designware_i2c.c | 14 --
  1 file changed, 8 insertions(+), 6 deletions(-)


Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v2 08/19] i2c: designware_i2c: Read device-tree properties

[Heiko Schocher]

Hello Simon,

Am 03.01.2020 um 23:26 schrieb Simon Glass:

The i2c controller defines a few timing properties. Read these in and
store them for use by the driver.

Signed-off-by: Simon Glass 
---

Changes in v2: None

  drivers/i2c/designware_i2c.c |  8 ++--
  drivers/i2c/designware_i2c.h | 15 +++
  drivers/i2c/designware_i2c_pci.c |  2 +-
  3 files changed, 22 insertions(+), 3 deletions(-)


Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v2 07/19] i2c: designware_i2c: Bring in the binding file

[Heiko Schocher]

Hello Simon,

Am 03.01.2020 um 23:26 schrieb Simon Glass:

Bring in this file from Linux v5.4.


may you can add here the commit ID ? Or is it from tag "v5.4" ?


Signed-off-by: Simon Glass 
---

Changes in v2: None

  .../i2c/i2c-designware.txt| 73 +++
  1 file changed, 73 insertions(+)
  create mode 100644 doc/device-tree-bindings/i2c/i2c-designware.txt


Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v2 06/19] i2c: designware_i2c: Use an accurate bus clock instead of MHz

[Heiko Schocher]

Hello Simon,

Am 03.01.2020 um 23:26 schrieb Simon Glass:

At present the driver uses an approximation for the bus clock, e.g. 166MHz
instead of 166 2/3 MHz.

This can result in small errors in the resulting I2C speed, perhaps 0.5%
or so.

Adjust the existing code to start from the accurate figure, even if later
rounding reduces this accuracy.

Update the bus speed code to work in KHz instead of MHz, which removes
most of the error.

Signed-off-by: Simon Glass 
---

Changes in v2: None

  drivers/i2c/designware_i2c.c | 18 --
  drivers/i2c/designware_i2c.h |  4 ++--
  2 files changed, 10 insertions(+), 12 deletions(-)


Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v2 05/19] i2c: designware_i2c: Use an enum for selected speed mode

[Heiko Schocher]

Hello Simon,

Am 03.01.2020 um 23:26 schrieb Simon Glass:

Group these #defines into an enum to make it easier to understand the
relationship between them.

Signed-off-by: Simon Glass 
---

Changes in v2: None

  drivers/i2c/designware_i2c.c |  2 +-
  drivers/i2c/designware_i2c.h | 10 +++---
  2 files changed, 8 insertions(+), 4 deletions(-)


Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v2 04/19] i2c: designware_i2c: Rename 'max' speed to 'high' speed

[Heiko Schocher]

Hello Simon,

Am 03.01.2020 um 23:26 schrieb Simon Glass:

Some SoCs support a higher speed than what is currently called 'max' in
this driver. Rename it to 'high' speed, which is the official name of the
3.4MHz speed.

Signed-off-by: Simon Glass 
---

Changes in v2: None

  drivers/i2c/designware_i2c.c | 10 +-
  drivers/i2c/designware_i2c.h |  8 
  2 files changed, 9 insertions(+), 9 deletions(-)


Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v2 03/19] i2c: designware_i2c: Include clk.h in the header file

[Heiko Schocher]

Hello Simon,

Am 03.01.2020 um 23:26 schrieb Simon Glass:

We use struct clk here so really should include this header file to avoid
build errors. Also switch the order of clk.h in the C file to match the
required code style.

Signed-off-by: Simon Glass 
Reviewed-by: Ley Foon Tan 
---

Changes in v2: None

  drivers/i2c/designware_i2c.c | 2 +-
  drivers/i2c/designware_i2c.h | 1 +
  2 files changed, 2 insertions(+), 1 deletion(-)


Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v2 02/19] i2c: designware_i2c: Don't allow changing IC_CLK

[Heiko Schocher]

Hello Simon,

Am 03.01.2020 um 23:26 schrieb Simon Glass:

If a different input clock is required then the correct way to do this is
with a clock driver. Don't allow boards to override IC_CLK.

Signed-off-by: Simon Glass 
---

Changes in v2: None

  drivers/i2c/designware_i2c.h | 2 --
  1 file changed, 2 deletions(-)


Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH v2 01/19] i2c: designware_i2c: Add more registers

[Heiko Schocher]

Hello Simon,

Am 03.01.2020 um 23:26 schrieb Simon Glass:

Some versions of this peripherals provide more control of the bus
behaviour. Add definitions for these registers.

Signed-off-by: Simon Glass 
Reviewed-by: Ley Foon Tan 
Reviewed-by: Jun Chen 
---

Changes in v2:
- Fix 'previde' typo

  drivers/i2c/designware_i2c.h | 13 -
  1 file changed, 12 insertions(+), 1 deletion(-)


please add the gap Jun Chen reported, beside of this:

Reviewed-by: Heiko Schocher 

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: Debugging VoCore2 ROM Startup

[Stefan Roese]

Hi Mauro,

On 15.01.20 18:25, Mauro Condarelli wrote:



Note: I assumed u-boot-mtmips.bin is linked at 9c00, right?


You don't need to know where it is linked to if you program it into
SPI NOR. But yes, the first stage the SPL is linked to 0x9c00.

Can You elaborate, please?


Each image generated to boot from SPI NOR needs to be linked to 9c00.
This is what the ROM image (non-RAM) of mainline does and the SPL image
of the dual image version (SPL plus main U-Boot proper) does.


I know for sure that if I flash at 3 a u-boot that has been compiled
with SYS_TEXT_BASE = 0x9c00 it will not start with "go 9c03"
I need to rebuild with SYS_TEXT_BASE = 0x9c03.


But you flash at offset 0 in SPI NOR, right? That's where the SoC starts
reading the bootloader binary after a reset or on power-up.

I was trying to say that, in my "secondary u-boot" attempts, where I
start from "paleolithic" and then do a "go " I need to put the
secondary at the same address specified in SYS_TEXT_BASE.
I mean:
if I want to boot directly from new then
     SYS_TEXT_BASE = 0x9c00
     flash at start of SPI NOR
     go 9c00
else if I want to start "secondary" then
     SYS_TEXT_BASE = 0x9c03
     flash at offset 3 in SPI NOR
     go 9c03
Any other combination does not work (i.e.: I cannot flash and run at
start an u-boot compiled with SYS_TEXT_BASE = 0x9c03 and
vice versa).

Note: I had to edit directly .config to change SYS_TEXT_BASE, apparently
it is visible in menuconfig only for ARM; am I missing something?


I can change it for my LinkIt target via "make menuconfig". Just search
for it by entering "/" in "make menuconfig" and it should show up there.

  

===8<--

I do have a led I can use for crude signalling, but I'm not really familiar
with mips Assembly.
Can You share the code to turn it on? (it is connected to
GPIO44/WLED(pin144).


i don't remember but it might be the case. Here the code snippet that
I used at that time. Perhaps it helps:

+#if 0 // test-only: WLAN LED on
+#define RALINK_SYSCTL_BASE 0xB000
+   // GPIO mode
+   li  t0, RALINK_SYSCTL_BASE + 0x64
+   li  t1, 0x05540551
+   sw  t1, 0(t0)
+
+   // GPIO direction
+   li  t0, RALINK_SYSCTL_BASE + 0x604
+   li  t1, 0x1000
+   sw  t1, 0(t0)
+
+   // GPIO value
+   li  t0, RALINK_SYSCTL_BASE + 0x624
+   li  t1, 0x0002f5f
+   sw  t1, 0(t0)
+#endif

Thanks,
Stefan

Re: [PATCH v2 2/2] env: Access Environment in SPI flashes before relocation

[Heiko Schocher]

Hello Simon,

Am 16.01.2020 um 01:10 schrieb Simon Glass:

Hi Heiko,

On Wed, 15 Jan 2020 at 23:13, Heiko Schocher  wrote:


Hello Simon,

Am 10.12.2019 um 13:39 schrieb Simon Glass:

Hi Heiko,

On Fri, 15 Nov 2019 at 00:28, Heiko Schocher  wrote:


Enable the new Kconfig option ENV_SPI_EARLY if you want
to use Environment in SPI flash before relocation.
Call env_init() and than you can use env_get_f() for
accessing Environment variables.

Signed-off-by: Heiko Schocher 

---

Changes in v2:
- env_sf_init_early() always return 0 now. If we do not return
0 in this function, env_set_inited() never get called,
which has the consequence that env_load/save/erase never
work, because they check if the init bit is set.

   env/Kconfig |  8 ++
   env/sf.c| 81 +
   2 files changed, 89 insertions(+)



[..]


+   tmp_env2 = (env_t *)memalign(ARCH_DMA_MINALIGN,
+   CONFIG_ENV_SIZE);
+#endif
+   if (!tmp_env1 || !tmp_env2)
+   goto out;
+
+   ret = setup_flash_device();
+   if (ret)
+   goto out;
+
+   read1_fail = spi_flash_read(env_flash, CONFIG_ENV_OFFSET,
+   CONFIG_ENV_SIZE, tmp_env1);
+#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT
+   read2_fail = spi_flash_read(env_flash, CONFIG_ENV_OFFSET_REDUND,
+   CONFIG_ENV_SIZE, tmp_env2);


Hmm... if porting to "if(IS_ENABLED...)" may here is CONFIG_ENV_OFFSET_REDUND
not defined ... I will see on world build ...


OK maybe it is not in Kconfig yet?


No, both are in Kconfig, and ENV_OFFSET_REDUND depends on 
SYS_REDUNDAND_ENVIRONMENT
so all should be fine.


+   ret = env_check_redund((char *)tmp_env1, read1_fail,
+  (char *)tmp_env2, read2_fail);
+
+   if ((ret == -EIO) || (ret == -ENOMSG))


Can drop extra brackets


Without this bracket I get:

/home/hs/data/Entwicklung/abb/uboot-rework/u-boot/env/sf.c: In function 
‘env_sf_init_early’:
/home/hs/data/Entwicklung/abb/uboot-rework/u-boot/env/sf.c:355:20: error: 
expected expression before
‘||’ token
 if (ret == -EIO) || (ret == -ENOMSG)
  ^~


No, I mean:

if (ret == -EIO || ret == -ENOMSG)


of course, sorry for being so stupid!


+   goto err_read;
+
+   if (gd->env_valid == ENV_VALID)
+   gd->env_addr = (unsigned long)_env1->data;
+   else
+   gd->env_addr = (unsigned long)_env2->data;
+
+#else
+   if (read1_fail)
+   goto err_read;
+
+   crc1_ok = crc32(0, tmp_env1->data, ENV_SIZE) ==
+   tmp_env1->crc;
+   if (!crc1_ok)
+   goto err_read;
+
+   /* if valid -> this is our env */
+   gd->env_valid = ENV_VALID;
+   gd->env_addr = (unsigned long)_env1->data;
+#endif
+
+   return 0;
+err_read:
+   spi_flash_free(env_flash);
+   env_flash = NULL;
+   free(tmp_env1);
+#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT


Unrelated to your patch, but should that be REDUNDANT?


Hmm.. currently the define is REDUNDAND ... but you are correct ...


+   free(tmp_env2);
+#endif
+out:
+   /* env is not valid. always return 0 */
+   gd->env_valid = ENV_INVALID;
+   return 0;
+}
+#endif
+
   U_BOOT_ENV_LOCATION(sf) = {
  .location   = ENVL_SPI_FLASH,
  ENV_NAME("SPI Flash")
@@ -317,5 +396,7 @@ U_BOOT_ENV_LOCATION(sf) = {
   #endif
   #if defined(INITENV) && defined(CONFIG_ENV_ADDR)
  .init   = env_sf_init,
+#elif defined(CONFIG_ENV_SPI_EARLY)
+   .init   = env_sf_init_early,
   #endif


It seems like we should have two drivers here, only one of which is
enabled. Perhaps for testing sandbox would want to enable both?

Alternatively I think env_sf_init() should decide which init function to call.


Ok, I can change this, but this leads into change, that we now always
call ".init" ...

in env/env.c env_init():

  for (prio = 0; (drv = env_driver_lookup(ENVOP_INIT, prio)); prio++) {
  if (!drv->init || !(ret = drv->init()))
  env_set_inited(drv->location);

So, if env_sf_init() return 0 in case nothing ToDo, it is OK to change
this. I added a comment in env_sf_init()


Yes I think it is better to have the function decide is anything is needed.


Ok, I rework it.

Thanks for your comments!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [RFC WIP PATCH v1 7/7] wandboard: in SPL use only D1 DTB

[Heiko Schocher]

Hello Fabio,

Am 15.01.2020 um 20:54 schrieb Fabio Estevam:

Hi Heiko,

On Tue, Jan 14, 2020 at 3:14 AM Heiko Schocher  wrote:


+#if defined(CONFIG_SPL_BUILD)
+   /* in SPL we use only revision D1 DTB */
+   if (1) {
+#else
 if (is_revd1()) {
+#endif


Is there a way to improve is_revd1() so that it can call i2c_probe()
and detect whether the PMIC is present or not?


It is WIP so maybe yes ;-)

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [RFC WIP PATCH v1 6/7] wandboard: add u-boot specific *wandboard-revd1-u-boot.dtsi

[Heiko Schocher]

Hello Fabio,

Am 15.01.2020 um 20:52 schrieb Fabio Estevam:

Hi Heiko,

On Tue, Jan 14, 2020 at 3:14 AM Heiko Schocher  wrote:


we want to access PMIC before relocation, so we need
to add u-boot specific "u-boot,dm-pre-reloc" properties.

Signed-off-by: Heiko Schocher 
---

  arch/arm/dts/imx6dl-wandboard-revd1-u-boot.dtsi | 11 +++
  arch/arm/dts/imx6q-wandboard-revd1-u-boot.dtsi  | 11 +++
  2 files changed, 22 insertions(+)
  create mode 100644 arch/arm/dts/imx6dl-wandboard-revd1-u-boot.dtsi
  create mode 100644 arch/arm/dts/imx6q-wandboard-revd1-u-boot.dtsi


The imx6q-wandboard-revd1-u-boot.dtsi is missing.


Ah, ok, I can add it ... wait for your testing results.

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [meta-freescale] Ramdisk booting: EXT4-fs (ram0): bad geometry error.

[Yusuf Altıparmak]

> --
>
> Hello
>
> With t1042d4rdb-64b and yocto 2.7 (
> https://source.codeaurora.org/external/qoriq/qoriq-components/yocto-sdk/tree/readme?h=warrior
> ) I am having bad geometry error while booting and U-boot is freezing. I
> declared "setenv intrd_high=0x" to use large rootfs but I am unable
> to reach root login. Can anyone help me about this situation ?
>
> *Full error console log is here:*
>
> RAMDISK: gzip image found at block 0
> RAMDISK: incomplete write (17195 != 32768)
> write error
> EXT4-fs (ram0): bad geometry: block count 435752 exceeds size of device
> (131072 blocks)
> VFS: Mounted root (ext2 filesystem) on device 1:0.
> devtmpfs: mounted
> Freeing unused kernel memory: 536K
> This architecture does not have kernel memory protection.
> Run /sbin/init as init process
> attempt to access beyond end of device
> ram0: rw=0, want=450632, limit=262144
> Buffer I/O error on dev ram0, logical block 225315, async page read
> attempt to access beyond end of device
> ram0: rw=0, want=454376, limit=262144
> Buffer I/O error on dev ram0, logical block 227187, async page read
> attempt to access beyond end of device
> ram0: rw=0, want=458082, limit=262144
> Buffer I/O error on dev ram0, logical block 229040, async page read
> attempt to access beyond end of device
> ram0: rw=0, want=458084, limit=262144
> Buffer I/O error on dev ram0, logical block 229041, async page read
> Run /etc/init as init process
> attempt to access beyond end of device
> ram0: rw=0, want=456378, limit=262144
> Buffer I/O error on dev ram0, logical block 228188, async page read
> attempt to access beyond end of device
> ram0: rw=0, want=457688, limit=262144
> Buffer I/O error on dev ram0, logical block 228843, async page read
> attempt to access beyond end of device
> ram0: rw=0, want=458086, limit=262144
> Buffer I/O error on dev ram0, logical block 229042, async page read
> Run /bin/init as init process
> attempt to access beyond end of device
> ram0: rw=0, want=457942, limit=262144
> Buffer I/O error on dev ram0, logical block 228970, async page read
> Run /bin/sh as init process
> attempt to access beyond end of device
> ram0: rw=0, want=457942, limit=262144
> Buffer I/O error on dev ram0, logical block 228970, async page read
> Kernel panic - not syncing: No working init found.  Try passing init=
> option to kernel. See Linux Documentation/admin.
> CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.19.26+gc0c2141 #1
> Call Trace:
> [c001f3107c70] [c0a69bf4] .dump_stack+0xa8/0xec (unreliable)
> [c001f3107d00] [c004b580] .panic+0x12c/0x2e8
> [c001f3107db0] [c0002464] .kernel_init+0x10c/0x128
> [c001f3107e30] [c9f4] .ret_from_kernel_thread+0x58/0x64
> Rebooting in 180 seconds..
>
> *printenv output:*
>
> baudrate=115200
> bdev=sda3
> bootargs=root=/dev/ram rw console=ttyS0,115200
> bootcmd=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate
> $othbootargs;bootm e802 e930 e880
> bootdelay=3
> bootfile=uImage
> c=ffe
> consoledev=ttyS0
> eth1addr=00:04:9F:05:B7:B1
> eth2addr=00:04:9F:05:B7:B2
> eth3addr=00:04:9F:05:B7:B3
> eth4addr=00:04:9F:05:B7:B4
> eth5addr=00:04:9f:8e:7b:b4
> ethact=FM1@DTSEC1
> ethaddr=00:04:9F:05:B7:B0
> ethprime=e1000#0
> fdtaddr=200
> fdtfile=uImage-t1042d4rdb.dtb
> fileaddr=200
> filesize=9a83
> fman_ucode=eff0
> gatewayip=192.168.10.4
> hvboot=setenv bootargs console=$consoledev,$baudrate
> config-addr=0xfe890;bootm 0xfe870 - 0xfe880
> hwconfig=fsl_ddr:bank_intlv=cs0_cs1
> initrd_high=0x
> ipaddr=192.168.10.99
> loadaddr=100
> netdev=eth0
> netmask=255.255.255.0
> nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath
> ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostnar
> nohvboot=tftp 100 $dir/$bootfile;tftp 500 $dir/$ramdiskfile;tftp
> 200 $dir/$fdtfile;setenv bootargs root=/;
> othbootargs=ramdisk_size=100
> ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate
> $othbootargs;tftp $ramdiskaddr $ramdiskfile;tfr
> ramdisk_size=41943040
> ramdiskaddr=500
> ramdiskfile=fsl-image-core-t1042d4rdb.ext2.gz.u-boot
> rootpath=/opt/nfsroot
> serverip=192.168.10.50
> tftpflash=tftpboot $loadaddr $uboot && protect off $ubootaddr +$filesize
> && erase $ubootaddr +$filesize && cp.b $loade
> uboot=u-boot.bin
> ubootaddr=0xeff4
>
> Environment size: 1871/8188 bytes
>
> *and the commands I used:*
>
> tftp 1000 uImage--4.19-r0-t1042d4rdb-64b-20200106043637.bin
> tftp 1f00 t1042d4rdb--4.19-r0-t1042d4rdb-64b-20200106043637.dtb
> tftp 2000 rootfs.ext2.gz.u-boot
> bootm 1000 2000 1f00
>


What is BLK_DEV_RAM_SIZE set to in the kernel?
>

Hello,
It's set to;
CONFIG_BLK_DEV_RAM_SIZE=131072

RE: [PATCH] arm: dts: imx7ulp-evk: remove mux value from pad configuration

[Peng Fan]

> Subject: [PATCH] arm: dts: imx7ulp-evk: remove mux value from pad
> configuration
> 
> The mux mode is embedded in the PAD definition and therefore there is no
> need to repeat it in the PAD configuration value (more over since this
> information will be masked out when the configuration value is applied).

Has this been accepted by Shawn?

Thanks,
Peng.

> 
> Signed-off-by: Jorge Ramirez-Ortiz 
> ---
>  arch/arm/dts/imx7ulp-evk.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/dts/imx7ulp-evk.dts b/arch/arm/dts/imx7ulp-evk.dts
> index 08a682f314..8f6a935e24 100644
> --- a/arch/arm/dts/imx7ulp-evk.dts
> +++ b/arch/arm/dts/imx7ulp-evk.dts
> @@ -156,7 +156,7 @@
> 
>   pinctrl_backlight: backlight_grp {
>   fsl,pins = <
> - IMX7ULP_PAD_PTF2__PTF2  0x20100
> + IMX7ULP_PAD_PTF2__PTF2  0x2
>   >;
>   };
> 
> --
> 2.17.1

RE: [RFC PATCH] imx: imx8mm-evk/imx8mn-evk: enable sysreset driver for SPL

[Peng Fan]

> Subject: [RFC PATCH] imx: imx8mm-evk/imx8mn-evk: enable sysreset driver
> for SPL
> 

NAK, this will not work on i.MX8MM/N.

Currently sysreset psci is enabled, however psci will not work for SPL, because
SPL boots before BL31.

Regards,
Peng.

> Hi,
> 
> I have only tested compiling, but if the reset in the SPL on i.MX8MM and
> i.MX8MN still works with this patch applied, then we don't need board
> specific 'do_reset' function and special configurations flags for this case.
> 
> I currently don't have access to the hardware to test this.
> 
> regards,
> Claudius
> 
> -- >8 --
> Subject: [RFC PATCH] imx: imx8mm-evk/imx8mn-evk: enable sysreset driver
> for  SPL
> 
> Instead of implementing a custom reset function for the SPL, it can directly
> use the sysreset DM driver.
> 
> Signed-off-by: Claudius Heine 
> ---
>  arch/arm/mach-imx/imx8m/soc.c | 19 ---
>  board/freescale/imx8mm_evk/spl.c  |  9 -
> board/freescale/imx8mn_evk/spl.c  |  9 -
>  configs/imx8mm_evk_defconfig  |  1 +
>  configs/imx8mn_ddr4_evk_defconfig |  1 +
>  5 files changed, 2 insertions(+), 37 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/imx8m/soc.c
> b/arch/arm/mach-imx/imx8m/soc.c index 5ce5a180e8..519108d4c9 100644
> --- a/arch/arm/mach-imx/imx8m/soc.c
> +++ b/arch/arm/mach-imx/imx8m/soc.c
> @@ -378,22 +378,3 @@ int ft_system_setup(void *blob, bd_t *bd)
>   return 0;
>  }
>  #endif
> -
> -#if defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SYSRESET) -void
> reset_cpu(ulong addr) -{
> -   struct watchdog_regs *wdog = (struct watchdog_regs *)addr;
> -
> -   if (!addr)
> -wdog = (struct watchdog_regs *)WDOG1_BASE_ADDR;
> -
> -   /* Clear WDA to trigger WDOG_B immediately */
> -   writew((WCR_WDE | WCR_SRS), >wcr);
> -
> -   while (1) {
> -   /*
> -* spin for .5 seconds before reset
> -*/
> -   }
> -}
> -#endif
> diff --git a/board/freescale/imx8mm_evk/spl.c
> b/board/freescale/imx8mm_evk/spl.c
> index 2d08f9a563..e8dec452ea 100644
> --- a/board/freescale/imx8mm_evk/spl.c
> +++ b/board/freescale/imx8mm_evk/spl.c
> @@ -159,12 +159,3 @@ void board_init_f(ulong dummy)
> 
>   board_init_r(NULL, 0);
>  }
> -
> -int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) -{
> - puts ("resetting ...\n");
> -
> - reset_cpu(WDOG1_BASE_ADDR);
> -
> - return 0;
> -}
> diff --git a/board/freescale/imx8mn_evk/spl.c
> b/board/freescale/imx8mn_evk/spl.c
> index cbde9f6b3c..0c70fbb155 100644
> --- a/board/freescale/imx8mn_evk/spl.c
> +++ b/board/freescale/imx8mn_evk/spl.c
> @@ -112,12 +112,3 @@ void board_init_f(ulong dummy)
> 
>   board_init_r(NULL, 0);
>  }
> -
> -int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) -{
> - puts("resetting ...\n");
> -
> - reset_cpu(WDOG1_BASE_ADDR);
> -
> - return 0;
> -}
> diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig
> index 87560ef989..c07f4104f9 100644
> --- a/configs/imx8mm_evk_defconfig
> +++ b/configs/imx8mm_evk_defconfig
> @@ -83,5 +83,6 @@ CONFIG_DM_REGULATOR_FIXED=y
> CONFIG_DM_REGULATOR_GPIO=y  CONFIG_MXC_UART=y
> CONFIG_SYSRESET=y
> +CONFIG_SPL_SYSRESET=y
>  CONFIG_SYSRESET_PSCI=y
>  CONFIG_DM_THERMAL=y
> diff --git a/configs/imx8mn_ddr4_evk_defconfig
> b/configs/imx8mn_ddr4_evk_defconfig
> index 50b03d0763..c55998da4c 100644
> --- a/configs/imx8mn_ddr4_evk_defconfig
> +++ b/configs/imx8mn_ddr4_evk_defconfig
> @@ -75,5 +75,6 @@ CONFIG_DM_REGULATOR_FIXED=y
> CONFIG_DM_REGULATOR_GPIO=y  CONFIG_MXC_UART=y
> CONFIG_SYSRESET=y
> +CONFIG_SPL_SYSRESET=y
>  CONFIG_SYSRESET_PSCI=y
>  CONFIG_DM_THERMAL=y
> --
> 2.24.1

Re: fat: handle Windows formatted partition (thru USB Mass Storage)

[AKASHI Takahiro]

On Wed, Jan 15, 2020 at 09:12:59AM +0900, AKASHI Takahiro wrote:
> On Tue, Jan 14, 2020 at 02:43:43PM +0200, Andy Shevchenko wrote:
> > On Tue, Jan 14, 2020 at 10:23 AM Andy Shevchenko
> >  wrote:
> > > On Tue, Jan 14, 2020 at 10:21 AM Andy Shevchenko
> > >  wrote:
> > > > On Tue, Jan 14, 2020 at 1:14 AM Heinrich Schuchardt 
> > > >  wrote:
> > > > > On 1/13/20 10:52 PM, Andy Shevchenko wrote:
> > >
> > > ...
> > >
> > > > > This image loads fine on current U-Boot, see below.
> > > >
> > > > Of course it does *in the test case you have done*.
> > > > I'm describing different one. The provided image must be a *partition*
> > > > on the real disk.
> > > >
> > > > So, before use it the preparatory steps must be made.
> > > >
> > > > Something like
> > > >
> > > > % dd if=/dev/zero of=image-file bs=1M count=1000
> > > > % fdisk image-file
> > > >  ...create a partition table, where one partition has a (similar) size
> > > > of the image I provided
> > > > % mount -o loop,offset=... image-file /mnt # use *partition* as a disk!
> > > > % dd --sparse if=mmc-fat-part of=/mnt
> > > > % umount /mnt
> > > >
> > > > And use image-file instead.
> > >
> > > Should I prepare it for you or you can do it yourself?
> > 
> > It's there under name image-file.gz
> 
> ===8<===
> $ hd image-file
>   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
> *
> 01b0  00 00 00 00 00 00 00 00  59 02 8c 89 00 00 00 20  |Y.. |
> 01c0  21 00 0c 08 27 62 00 08  00 00 01 00 18 00 00 00  |!...'b..|
> 01d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
> *
> (snip)
> 0010  eb 3c 90 6d 6b 64 6f 73  66 73 00 00 02 20 01 00  |.<.mkdosfs... ..|
> 00100010  02 00 02 00 00 f8 c0 00  10 00 04 00 00 00 00 00  ||
> 00100020  00 00 18 00 80 00 29 ea  36 23 57 20 20 20 20 20  |..).6#W |
> 00100030  20 20 20 20 20 20 46 41  54 31 36 20 20 20 0e 1f  |  FAT16   ..|
> (snip)
> 001001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
> *
> 001001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..U.|
> 00100200  f8 ff ff ff 00 00 00 00  00 00 00 00 00 00 00 00  ||
> 00100210  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
> *
> 0011  eb 58 90 4d 53 44 4f 53  35 2e 30 00 02 08 1a 14  |.X.MSDOS5.0.|
> 00110010  02 00 00 00 00 f8 00 00  3f 00 ff 00 80 00 00 00  |?...|
> 00110020  00 e8 17 00 f3 05 00 00  00 00 00 00 02 00 00 00  ||
> 00110030  01 00 06 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
> 00110040  80 00 29 f8 a9 74 d0 4e  4f 20 4e 41 4d 45 20 20  |..)..t.NO NAME  |
> 00110050  20 20 46 41 54 33 32 20  20 20 33 c9 8e d1 bc f4  |  FAT32   3.|
> (snip)
> ===>8===
> 
> [0x10-0x100200) looks to be PBR.
> [0x11-0x110050) looks to be MBR.
> But I don't know what is [0x0-0x10).

(Correction)
[0x0-0x200) is actually a partition table:

  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
01b0  00 00 00 00 00 00 00 00  59 02 8c 89 00 00/00/20  |Y.. |
 ^^:boot_ind
boot_ind: not ACTIVE
01c0  21 00 0c 08 27 62/00 08  00 00/01 00 18 00/00 00  |!...'b..|
p1's start   p1's size
start: 0x0800 sector (= 0x10)
size:  0x0018 sectors
01d0  00 00/00 00 00 00/00 00  00 00/00 00 00 00/00 00  ||
*
01f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..U.|
 ^:magic number

And [0x10-0x100200) is a PBR, which then points to a next-level
partition:

0010  eb 3c 90 6d 6b 64 6f 73  66 73 00 00 02 20 01 00  |.<.mkdosfs... ..|
(snip)
001001b0  00 00 00 00 00 00 00 00  8c 60 88 d5 00 00/00/02/ |.`..|
001001c0  03 00 0c fe 3f 60/80 00  00 00/00 e8 17 00/00 00  |?`..|
startsize
start: 0x0080
size:  0x0017e800

> Obviously U-Boot's fat code cannot handle it.

So precisely, U-Boot cannot handle nested partition( table)s?

-Takahiro Akashi

> 
> Thanks,
> -Takahiro Akashi
> 
> 
> > Commit messages have the commands I performed to get this image cooked.
> > 
> > -- 
> > With Best Regards,
> > Andy Shevchenko

Re: [PATCH 6/6] fastboot: mt85xx: add command to flash/erase emmc hwpart

[Mingming Lee]

On Wed, 2020-01-15 at 15:48 -0500, Tom Rini wrote:
> On Mon, Jan 06, 2020 at 02:26:49PM +0800, mingming lee wrote:
> 
> > This patch includes the following:
> > 1. Add fastboot command to erase the whole EMMC_USER
> > 2. Add fastboot command to flash image at EMMC_BOOT1
> > 3. Add fastboot command to erase the whole EMMC_BOOT1
> > 4. Enale CONFIG_FASTBOOT_MMC_BOOT1_SUPPORT for mt8518
> > 
> > Signed-off-by: mingming lee 
> 
> This breaks building of dra7xx_evm and possibly others, thanks.
> 

hi Tom,

Thank you very much for the review, I would fixed  it in the next
version.

By The way, I wonder could U  pls share your way for check? Then in the
futher I could check it all on my local before submit.

Re: Apollo Lake GPIO driver with Coreboot/U-Boot

[Simon Glass]

Hi Wolfgang,

On Thu, 16 Jan 2020 at 02:55, Wolfgang Wallner
 wrote:
>
> Hello Simon, Bin, all,
>
> I have an Apollo Lake based device, where U-Boot is booted as a Coreboot
> payload. I would like to utilize the Apollo Lake GPIO driver
> (drivers/gpio/intel_gpio.c), but I struggle with the dependencies.
>
> For my use case, I face 2 obstacles:
>
>   1) Some required drivers are not built
>
> The Apollo Lake GPIO driver requires the P2SB and ITSS drivers, but those
> are located in arch/x86/cpu/apollolake. Drivers in this directory are not
> included in my build as it builds for Coreboot, not for Apollo Lake.
>
>   2) Some header files are not found
>
> The header files gpio.h and itss.h are located in
> arch/x86/include/asm/arch-apollolake, but as I build for Coreboot the
> symlink arch/x86/include/asm/arch points to arch-coreboot instead of
> arch-apollolake, so those header files are not found.
>
> Does anyone have recommendations on how to solve those issues?
> Would it be possible to move the drivers for P2SB and ITSS out of
> arch/x86/cpu/apollolake to the generic drivers/ directory?

I don't have any great ideas. At present we rely on the device tree to
bind these drivers but I suppose we could add the PCI IDs and then the
coreboot target could bind them.

I did send a series to add checks to skip low-level init as needed
when running from coreboot:

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

>
> regards, Wolfgang
>
> PS: Thanks Simon for providing the initial support for Apollo Lake!

You're welcome. I'm expecting to have full ACPI support around the end
of the month.

Regards,
Simon

Re: [RFC PATCH] imx: imx8mm-evk/imx8mn-evk: enable sysreset driver for SPL

[Simon Glass]

On Thu, 16 Jan 2020 at 03:50, Claudius Heine  wrote:
>
> Hi,
>
> I have only tested compiling, but if the reset in the SPL on i.MX8MM and
> i.MX8MN still works with this patch applied, then we don't need board
> specific 'do_reset' function and special configurations flags for this
> case.
>
> I currently don't have access to the hardware to test this.
>
> regards,
> Claudius
>
> -- >8 --
> Subject: [RFC PATCH] imx: imx8mm-evk/imx8mn-evk: enable sysreset driver for
>  SPL
>
> Instead of implementing a custom reset function for the SPL, it can
> directly use the sysreset DM driver.
>
> Signed-off-by: Claudius Heine 
> ---
>  arch/arm/mach-imx/imx8m/soc.c | 19 ---
>  board/freescale/imx8mm_evk/spl.c  |  9 -
>  board/freescale/imx8mn_evk/spl.c  |  9 -
>  configs/imx8mm_evk_defconfig  |  1 +
>  configs/imx8mn_ddr4_evk_defconfig |  1 +
>  5 files changed, 2 insertions(+), 37 deletions(-)

Reviewed-by: Simon Glass 

Re: [PATCH v2 2/2] env: Access Environment in SPI flashes before relocation

[Simon Glass]

Hi Heiko,

On Wed, 15 Jan 2020 at 23:13, Heiko Schocher  wrote:
>
> Hello Simon,
>
> Am 10.12.2019 um 13:39 schrieb Simon Glass:
> > Hi Heiko,
> >
> > On Fri, 15 Nov 2019 at 00:28, Heiko Schocher  wrote:
> >>
> >> Enable the new Kconfig option ENV_SPI_EARLY if you want
> >> to use Environment in SPI flash before relocation.
> >> Call env_init() and than you can use env_get_f() for
> >> accessing Environment variables.
> >>
> >> Signed-off-by: Heiko Schocher 
> >>
> >> ---
> >>
> >> Changes in v2:
> >> - env_sf_init_early() always return 0 now. If we do not return
> >>0 in this function, env_set_inited() never get called,
> >>which has the consequence that env_load/save/erase never
> >>work, because they check if the init bit is set.
> >>
> >>   env/Kconfig |  8 ++
> >>   env/sf.c| 81 +
> >>   2 files changed, 89 insertions(+)
> >>

[..]

> >> +   tmp_env2 = (env_t *)memalign(ARCH_DMA_MINALIGN,
> >> +   CONFIG_ENV_SIZE);
> >> +#endif
> >> +   if (!tmp_env1 || !tmp_env2)
> >> +   goto out;
> >> +
> >> +   ret = setup_flash_device();
> >> +   if (ret)
> >> +   goto out;
> >> +
> >> +   read1_fail = spi_flash_read(env_flash, CONFIG_ENV_OFFSET,
> >> +   CONFIG_ENV_SIZE, tmp_env1);
> >> +#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT
> >> +   read2_fail = spi_flash_read(env_flash, CONFIG_ENV_OFFSET_REDUND,
> >> +   CONFIG_ENV_SIZE, tmp_env2);
>
> Hmm... if porting to "if(IS_ENABLED...)" may here is CONFIG_ENV_OFFSET_REDUND
> not defined ... I will see on world build ...

OK maybe it is not in Kconfig yet?

>
> >> +   ret = env_check_redund((char *)tmp_env1, read1_fail,
> >> +  (char *)tmp_env2, read2_fail);
> >> +
> >> +   if ((ret == -EIO) || (ret == -ENOMSG))
> >
> > Can drop extra brackets
>
> Without this bracket I get:
>
> /home/hs/data/Entwicklung/abb/uboot-rework/u-boot/env/sf.c: In function 
> ‘env_sf_init_early’:
> /home/hs/data/Entwicklung/abb/uboot-rework/u-boot/env/sf.c:355:20: error: 
> expected expression before
> ‘||’ token
> if (ret == -EIO) || (ret == -ENOMSG)
>  ^~

No, I mean:

   if (ret == -EIO || ret == -ENOMSG)

>
> >> +   goto err_read;
> >> +
> >> +   if (gd->env_valid == ENV_VALID)
> >> +   gd->env_addr = (unsigned long)_env1->data;
> >> +   else
> >> +   gd->env_addr = (unsigned long)_env2->data;
> >> +
> >> +#else
> >> +   if (read1_fail)
> >> +   goto err_read;
> >> +
> >> +   crc1_ok = crc32(0, tmp_env1->data, ENV_SIZE) ==
> >> +   tmp_env1->crc;
> >> +   if (!crc1_ok)
> >> +   goto err_read;
> >> +
> >> +   /* if valid -> this is our env */
> >> +   gd->env_valid = ENV_VALID;
> >> +   gd->env_addr = (unsigned long)_env1->data;
> >> +#endif
> >> +
> >> +   return 0;
> >> +err_read:
> >> +   spi_flash_free(env_flash);
> >> +   env_flash = NULL;
> >> +   free(tmp_env1);
> >> +#ifdef CONFIG_SYS_REDUNDAND_ENVIRONMENT
> >
> > Unrelated to your patch, but should that be REDUNDANT?
>
> Hmm.. currently the define is REDUNDAND ... but you are correct ...
>
> >> +   free(tmp_env2);
> >> +#endif
> >> +out:
> >> +   /* env is not valid. always return 0 */
> >> +   gd->env_valid = ENV_INVALID;
> >> +   return 0;
> >> +}
> >> +#endif
> >> +
> >>   U_BOOT_ENV_LOCATION(sf) = {
> >>  .location   = ENVL_SPI_FLASH,
> >>  ENV_NAME("SPI Flash")
> >> @@ -317,5 +396,7 @@ U_BOOT_ENV_LOCATION(sf) = {
> >>   #endif
> >>   #if defined(INITENV) && defined(CONFIG_ENV_ADDR)
> >>  .init   = env_sf_init,
> >> +#elif defined(CONFIG_ENV_SPI_EARLY)
> >> +   .init   = env_sf_init_early,
> >>   #endif
> >
> > It seems like we should have two drivers here, only one of which is
> > enabled. Perhaps for testing sandbox would want to enable both?
> >
> > Alternatively I think env_sf_init() should decide which init function to 
> > call.
>
> Ok, I can change this, but this leads into change, that we now always
> call ".init" ...
>
> in env/env.c env_init():
>
>  for (prio = 0; (drv = env_driver_lookup(ENVOP_INIT, prio)); prio++) {
>  if (!drv->init || !(ret = drv->init()))
>  env_set_inited(drv->location);
>
> So, if env_sf_init() return 0 in case nothing ToDo, it is OK to change
> this. I added a comment in env_sf_init()

Yes I think it is better to have the function decide is anything is needed.

Regards,
Simon

Re: [PATCH] doc: android: Convert to Sphinx format

[Simon Glass]

On Wed, 15 Jan 2020 at 06:50, Sam Protsenko  wrote:
>
> Convert Android documentation from regular txt format to Sphinx (RST).
> Also add Android index.rst file and reference it in root index.rst, so
> that Android documentation is visible.
>
> Test:
>
> $ make htmldocs
> $ xdg-open doc/output/index.html
>
> Signed-off-by: Sam Protsenko 
> ---
>  MAINTAINERS   |   4 +-
>  cmd/Kconfig   |   2 +-
>  doc/android/{ab.txt => ab.rst}|  39 ++---
>  doc/android/avb2.rst  | 133 ++
>  doc/android/avb2.txt  | 115 ---
>  doc/android/bcb.rst   | 100 +
>  doc/android/bcb.txt   |  89 
>  ...oot-protocol.txt => fastboot-protocol.rst} |  45 +++---
>  doc/android/{fastboot.txt => fastboot.rst}|  92 ++--
>  doc/android/index.rst |  14 ++
>  doc/index.rst |  12 ++
>  test/py/tests/test_android/test_avb.py|   2 +-
>  12 files changed, 351 insertions(+), 296 deletions(-)
>  rename doc/android/{ab.txt => ab.rst} (52%)
>  create mode 100644 doc/android/avb2.rst
>  delete mode 100644 doc/android/avb2.txt
>  create mode 100644 doc/android/bcb.rst
>  delete mode 100644 doc/android/bcb.txt
>  rename doc/android/{fastboot-protocol.txt => fastboot-protocol.rst} (82%)
>  rename doc/android/{fastboot.txt => fastboot.rst} (79%)
>  create mode 100644 doc/android/index.rst

Reviewed-by: Simon Glass 

[PATCH v2 11/11] riscv: Add K210 clock support

[Sean Anderson]

Due to the large number of clocks, I decided to use the CCF. The overall
structure is modeled after the imx code. A common pattern is to create a
composite clock composed of several component clocks. For these component
clocks, the clk_register_* functions are not used, since they will be registered
as part of the composite clock. To create these component clocks, several helper
k210_clk_comp_* functions are used. This functionality seems like it would be
useful to other drivers also creating composite clocks, so perhaps some general
versions should be created. I am not particularly attached to the naming
convention, suggestions are welcome.

Signed-off-by: Sean Anderson 
---
Changes for v2:
  Add clk.o to obj-y.
  Don't probe before relocation.

 arch/riscv/Kconfig|   3 -
 board/sipeed/maix/Kconfig |   3 +
 drivers/clk/kendryte/Makefile |   2 +-
 drivers/clk/kendryte/clk.c| 390 ++
 drivers/clk/kendryte/clk.h|  27 +++
 5 files changed, 421 insertions(+), 4 deletions(-)
 create mode 100644 drivers/clk/kendryte/clk.c
 create mode 100644 drivers/clk/kendryte/clk.h

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 677cdf5f24..6b05ef72d0 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -248,7 +248,4 @@ config STACK_SIZE_SHIFT
 config SPL_LDSCRIPT
default "arch/riscv/cpu/u-boot-spl.lds"
 
-config ARCH_K210
-   bool "Support Kendryte K210 SOCs"
-
 endmenu
diff --git a/board/sipeed/maix/Kconfig b/board/sipeed/maix/Kconfig
index 10e492a425..c456c47fb2 100644
--- a/board/sipeed/maix/Kconfig
+++ b/board/sipeed/maix/Kconfig
@@ -27,6 +27,9 @@ config NR_CPUS
 config NR_DRAM_BANKS
default 2
 
+config SYS_MALLOC_F_LEN
+   default 0x8000
+
 config BOARD_SPECIFIC_OPTIONS
def_bool y
select GENERIC_RISCV
diff --git a/drivers/clk/kendryte/Makefile b/drivers/clk/kendryte/Makefile
index c56d93ea1c..d26bce954f 100644
--- a/drivers/clk/kendryte/Makefile
+++ b/drivers/clk/kendryte/Makefile
@@ -1 +1 @@
-obj-y += pll.o
+obj-y += clk.o pll.o
diff --git a/drivers/clk/kendryte/clk.c b/drivers/clk/kendryte/clk.c
new file mode 100644
index 00..c6405a329c
--- /dev/null
+++ b/drivers/clk/kendryte/clk.c
@@ -0,0 +1,390 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Sean Anderson 
+ */
+#include "clk.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pll.h"
+
+static ulong k210_clk_get_rate(struct clk *clk)
+{
+   struct clk *c;
+   int err = clk_get_by_id(clk->id, );
+
+   if (err)
+   return err;
+   return clk_get_rate(c);
+}
+
+static ulong k210_clk_set_rate(struct clk *clk, unsigned long rate)
+{
+   struct clk *c;
+   int err = clk_get_by_id(clk->id, );
+
+   if (err)
+   return err;
+   return clk_set_rate(c, rate);
+}
+
+static int k210_clk_set_parent(struct clk *clk, struct clk *parent)
+{
+   struct clk *c, *p;
+   int err = clk_get_by_id(clk->id, );
+
+   if (err)
+   return err;
+   
+   err = clk_get_by_id(parent->id, );
+   if (err)
+   return err;
+
+   return clk_set_parent(c, p);
+}
+
+static int k210_clk_endisable(struct clk *clk, bool enable)
+{
+   struct clk *c;
+   int err = clk_get_by_id(clk->id, );
+
+   if (err)
+   return err;
+   return enable ? clk_enable(c) : clk_disable(c);
+}
+
+static int k210_clk_enable(struct clk *clk)
+{
+   return k210_clk_endisable(clk, true);
+}
+
+static int k210_clk_disable(struct clk *clk)
+{
+   return k210_clk_endisable(clk, false);
+}
+
+static const struct clk_ops k210_clk_ops = {
+   .set_rate = k210_clk_set_rate,
+   .get_rate = k210_clk_get_rate,
+   .set_parent = k210_clk_set_parent,
+   .enable = k210_clk_enable,
+   .disable = k210_clk_disable,
+};
+
+/* The first clock is in0, which is filled in by k210_clk_probe */
+static const char *generic_sels[] = { NULL, "pll0", };
+static const char *aclk_sels[] = { "in0_half", "pll0_half", };
+static const char *pll2_sels[] = { NULL, "pll0", "pll1", };
+
+static struct clk_divider *k210_clk_comp_div_flags(void __iomem *reg, u8 shift,
+  u8 width, u8 flags)
+{
+   struct clk_divider *div;
+
+   div = kzalloc(sizeof(*div), GFP_KERNEL);
+   if (!div)
+   return div;
+   div->reg = reg;
+   div->shift = shift;
+   div->width = width;
+   div->flags = flags;
+   return div;
+}
+
+static inline struct clk_divider *k210_clk_comp_div(void __iomem *reg, u8 
shift,
+   u8 width)
+{
+   return k210_clk_comp_div_flags(reg, shift, width, 0);
+}
+
+static struct clk_gate *k210_clk_comp_gate(void __iomem *reg, u8 bit_idx)
+{
+   struct clk_gate *gate;
+
+   gate = kzalloc(sizeof(*gate), GFP_KERNEL);
+   if (!gate)
+   return gate;
+   

[PATCH v2 10/11] riscv: Add K210 pll support

[Sean Anderson]

This pll code is primarily based on the code from the kendryte standalone sdk in
lib/drivers/sysctl.c. k210_pll_calc_params is roughly analogous to the algorithm
used to set the pll frequency, but it has been completely rewritten to be
fixed-point based.

Signed-off-by: Sean Anderson 
---
Changes for v2.
  Rename driver to "k210_clk_pll"
  Add additional in-line documentation on algorithm and PLLs.
  Restrict the range of internal VCO and reference frequencies.
  Don't load driver before relocation.
  Remove spurious references to mach-k210.

 board/sipeed/maix/Kconfig  |   1 +
 configs/sipeed_maix_bitm_defconfig |   1 +
 drivers/clk/Kconfig|   1 +
 drivers/clk/Makefile   |   1 +
 drivers/clk/kendryte/Kconfig   |   7 +
 drivers/clk/kendryte/Makefile  |   1 +
 drivers/clk/kendryte/pll.c | 598 +
 drivers/clk/kendryte/pll.h |  38 ++
 8 files changed, 648 insertions(+)
 create mode 100644 drivers/clk/kendryte/Kconfig
 create mode 100644 drivers/clk/kendryte/Makefile
 create mode 100644 drivers/clk/kendryte/pll.c
 create mode 100644 drivers/clk/kendryte/pll.h

diff --git a/board/sipeed/maix/Kconfig b/board/sipeed/maix/Kconfig
index 9ffd3aa7aa..10e492a425 100644
--- a/board/sipeed/maix/Kconfig
+++ b/board/sipeed/maix/Kconfig
@@ -37,6 +37,7 @@ config BOARD_SPECIFIC_OPTIONS
select SYS_RISCV_NOCOUNTER
imply SIFIVE_CLINT
imply K210_SYSCTL
+   imply CLK_K210
imply SPI
imply DM_GPIO
imply CMD_GPIO
diff --git a/configs/sipeed_maix_bitm_defconfig 
b/configs/sipeed_maix_bitm_defconfig
index ecd69c0873..aeab7db0c3 100644
--- a/configs/sipeed_maix_bitm_defconfig
+++ b/configs/sipeed_maix_bitm_defconfig
@@ -65,6 +65,7 @@ CONFIG_OF_TRANSLATE=y
 CONFIG_CLK=y
 CONFIG_CLK_CCF=y
 CONFIG_CLK_COMPOSITE_CCF=y
+CONFIG_CLK_K210=y
 CONFIG_CPU=y
 CONFIG_CPU_RISCV=y
 CONFIG_MMC=y
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 16d4237f89..af75c7c4cf 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -145,6 +145,7 @@ source "drivers/clk/analogbits/Kconfig"
 source "drivers/clk/at91/Kconfig"
 source "drivers/clk/exynos/Kconfig"
 source "drivers/clk/imx/Kconfig"
+source "drivers/clk/kendryte/Kconfig"
 source "drivers/clk/meson/Kconfig"
 source "drivers/clk/mvebu/Kconfig"
 source "drivers/clk/owl/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 06131edb9f..4f3893f6fc 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_CLK_BCM6345) += clk_bcm6345.o
 obj-$(CONFIG_CLK_BOSTON) += clk_boston.o
 obj-$(CONFIG_CLK_EXYNOS) += exynos/
 obj-$(CONFIG_CLK_HSDK) += clk-hsdk-cgu.o
+obj-$(CONFIG_CLK_K210) += kendryte/
 obj-$(CONFIG_CLK_MPC83XX) += mpc83xx_clk.o
 obj-$(CONFIG_CLK_OWL) += owl/
 obj-$(CONFIG_CLK_RENESAS) += renesas/
diff --git a/drivers/clk/kendryte/Kconfig b/drivers/clk/kendryte/Kconfig
new file mode 100644
index 00..a178d50f5e
--- /dev/null
+++ b/drivers/clk/kendryte/Kconfig
@@ -0,0 +1,7 @@
+config CLK_K210
+   bool "Clock support for Kendryte K210"
+   depends on K210_SYSCTL
+   select CLK
+   select CLK_CCF
+   help
+ This enables support clock driver for Kendryte K210 platforms.
diff --git a/drivers/clk/kendryte/Makefile b/drivers/clk/kendryte/Makefile
new file mode 100644
index 00..c56d93ea1c
--- /dev/null
+++ b/drivers/clk/kendryte/Makefile
@@ -0,0 +1 @@
+obj-y += pll.o
diff --git a/drivers/clk/kendryte/pll.c b/drivers/clk/kendryte/pll.c
new file mode 100644
index 00..cbb112f5a8
--- /dev/null
+++ b/drivers/clk/kendryte/pll.c
@@ -0,0 +1,598 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Sean Anderson 
+ */
+#include "pll.h"
+
+#define LOG_CATEGORY UCLASS_CLK
+#include 
+/* For DIV_ROUND_DOWN_ULL, defined in linux/kernel.h */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CLK_K210_PLL "k210_clk_pll"
+#define to_k210_pll(_clk) container_of(_clk, struct k210_pll, clk)
+
+static int k210_pll_enable(struct clk *clk);
+static int k210_pll_disable(struct clk *clk);
+
+/*
+ * The logical layout of the PLL is approximately the following:
+ *
+ *+---+
+ *|input clock|
+ *+---+
+ *  |
+ *  v
+ *+--+
+ *|/r|
+ *+--+
+ *  |
+ *  v
+ *  +---+
+ *  |reference clock|
+ *  +---+
+ *  |
+ *  v
+ * ++
+ * |phase comparator|<--+
+ * ++   |
+ *  |   |
+ *  v   |
+ *+---+ |
+ *|VCO| |
+ *+---+ |
+ *  |+--+   |
+ *  +--->|/f|---+
+ *  |+--+
+ *  v
+ *+---+
+ *|/od|
+ *+---+
+ *  |
+ *  v
+ *   +--+
+ *   |output|
+ *   +--+
+ *
+ * The k210 PLLs have three factors: r, f, and od. Because of the 

[PATCH v2 09/11] riscv: Add K210 sysctl support

[Sean Anderson]

This driver does nothing but load its children for the moment. Should it be
using regmap? I'm not sure how that fits into everything.

Signed-off-by: Sean Anderson 
---
Changes for v2:
  Removed spurious references to mach-k210.
  Don't load pre-relocation.

 arch/riscv/Kconfig   | 11 +++
 arch/riscv/include/asm/k210_sysctl.h | 43 
 arch/riscv/lib/Makefile  |  1 +
 arch/riscv/lib/k210_sysctl.c | 21 ++
 board/sipeed/maix/Kconfig|  1 +
 5 files changed, 77 insertions(+)
 create mode 100644 arch/riscv/include/asm/k210_sysctl.h
 create mode 100644 arch/riscv/lib/k210_sysctl.c

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 4c62b8dd77..677cdf5f24 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -196,6 +196,14 @@ config RISCV_RDTIME
  standard rdtime instruction. This is the case for S-mode U-Boot, and
  is useful for processors that support rdtime in M-mode too.
 
+config K210_SYSCTL
+   bool
+   select SYSCON
+   select SPL_SYSCON if SPL
+   help
+ The K210 sysctl block holds memory-mapped control and status
+ registers associated with clocks, resets, power, and dma handshakes.
+
 config SYS_MALLOC_F_LEN
default 0x1000
 
@@ -240,4 +248,7 @@ config STACK_SIZE_SHIFT
 config SPL_LDSCRIPT
default "arch/riscv/cpu/u-boot-spl.lds"
 
+config ARCH_K210
+   bool "Support Kendryte K210 SOCs"
+
 endmenu
diff --git a/arch/riscv/include/asm/k210_sysctl.h 
b/arch/riscv/include/asm/k210_sysctl.h
new file mode 100644
index 00..94170f4f31
--- /dev/null
+++ b/arch/riscv/include/asm/k210_sysctl.h
@@ -0,0 +1,43 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2019 Sean Anderson 
+ */
+
+#ifndef K210_SYSCTL_H
+#define K210_SYSCTL_H
+
+#include 
+
+/*
+ * sysctl registers
+ * Taken from kendryte-standalone-sdk/lib/drivers/include/sysctl.h
+ */
+struct k210_sysctl {
+   u32 git_id;
+   u32 clk_freq;
+   u32 pll0;
+   u32 pll1;
+   u32 pll2;
+   u32 resv5;
+   u32 pll_lock;
+   u32 rom_error;
+   u32 clk_sel[2];
+   u32 clk_en_cent;
+   u32 clk_en_peri;
+   u32 soft_reset;
+   u32 peri_reset;
+   u32 clk_thr[7];
+   u32 misc;
+   u32 peri;
+   u32 spi_sleep;
+   u32 reset_status;
+   u32 dma_sel0;
+   u32 dma_sel1;
+   u32 power_sel;
+   u32 resv28;
+   u32 resv29;
+   u32 resv30;
+   u32 resv31;
+} __packed;
+
+#endif /* K210_SYSCTL_H */
diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index c9179a5ff8..4c31e824d9 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -14,6 +14,7 @@ ifeq ($(CONFIG_$(SPL_)RISCV_MMODE),y)
 obj-$(CONFIG_SIFIVE_CLINT) += sifive_clint.o
 obj-$(CONFIG_ANDES_PLIC) += andes_plic.o
 obj-$(CONFIG_ANDES_PLMT) += andes_plmt.o
+obj-$(CONFIG_K210_SYSCTL) += k210_sysctl.o
 else
 obj-$(CONFIG_RISCV_RDTIME) += rdtime.o
 obj-$(CONFIG_SBI_IPI) += sbi_ipi.o
diff --git a/arch/riscv/lib/k210_sysctl.c b/arch/riscv/lib/k210_sysctl.c
new file mode 100644
index 00..db2e79c974
--- /dev/null
+++ b/arch/riscv/lib/k210_sysctl.c
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Sean Anderson 
+ */
+#include 
+
+#include 
+
+static const struct udevice_id k210_sysctl_ids[] = {
+   { .compatible = "kendryte,k210-sysctl", },
+   { }
+};
+
+U_BOOT_DRIVER(k210_sysctl) = {
+   .name = "k210_sysctl",
+   .id = UCLASS_SYSCON,
+#if !CONFIG_IS_ENABLED(OF_PLATDATA)
+   .bind = dm_scan_fdt_dev,
+#endif
+   .of_match = k210_sysctl_ids,
+};
diff --git a/board/sipeed/maix/Kconfig b/board/sipeed/maix/Kconfig
index efeaddf317..9ffd3aa7aa 100644
--- a/board/sipeed/maix/Kconfig
+++ b/board/sipeed/maix/Kconfig
@@ -36,6 +36,7 @@ config BOARD_SPECIFIC_OPTIONS
select ENV_IS_NOWHERE
select SYS_RISCV_NOCOUNTER
imply SIFIVE_CLINT
+   imply K210_SYSCTL
imply SPI
imply DM_GPIO
imply CMD_GPIO
-- 
2.24.1

[PATCH v2 08/11] riscv: Add device tree for K210

[Sean Anderson]

The subject for this patch should be

Subject: [PATCH v2 08/11] riscv: Add device tree for K210

Re: [PATCH v2 00/11] riscv: Add Sipeed Maix support

[Sean Anderson]

From 1db8b70d069d1f96eb33597fb5bd82cb8a9cec9d Mon Sep 17 00:00:00 2001
From: Sean Anderson 
Date: Tue, 31 Dec 2019 14:28:58 -0500
Subject: [PATCH v2 08/11] riscv: Add device tree for K210

There is a mirror of ram located at 0x400 which is un-cached. This is
probably useful for DMA, but I am unsure of how to describe it in this device
tree. 

The cache-line size is undocumented. Emphirical tests suggest that it is 32
bytes, but I've used 64-bytes to be on the safe side.

Where possible, I have tried to find compatible drivers based on the layout of
registers. However, I have not tested most of this functionality, and anything
aside from clint0, uarths0, and sysctl should be considered descriptive at best.
I would appreciate if anyone could help identify possibly compatible devices,
especially for the timers, watchdogs, and rtc.

The documentation for pinconf devices indicates that #pinctrl-cells is a
required property, but I am unsure what to put for it. Should that be filled in
by a board-specific device tree?

The sysctl device has multiple different unrelated registers. For the moment, I
have split off sub-devices for each functionality. In addition to clock and
reset control, it also contains DMA handshake registers, and power registers. I
have not described those at the moment, and I would appreciate suggestions on
how to best describe them.

I'm not sure what the value of spi-max-frequency should be for external sd-card
slots. Suggestions are appreciated.

Signed-off-by: Sean Anderson 
---
Changes for v2:
  Model changed to "Sipeed Maix Bit" to match file name.
  Value of stdout-path fixed.
  SD card slot compatible changed to "mmc-spi-slot".
  "jedec,spi-nor" added to spi flash compatible list.
  Aliases for spi busses added.
  timebase-frequency divided by 50 to match timer speed.
  cpu-frequency renamed to clock-frequency.
  CPUX_intc restyled to cpuX_intc.
  "kendryte,k210-soc" added to soc compatible list for future-proofing.
  PLIC handle renamed to plic0 from pic0.
  K210_RST_SOC removed from sysrst, due to not being located in the
  reset register.
  K210_RST_* numbers changed to match their bit offset within the reset
  register.
  gpio_controller restyled to gpio-controller.
  Added a second clock to the dma binding to match what the driver
  expects.
  Changed "snps,designware-spi" compatible string to "snps,dw-apb-ssi"
  to match the correct driver.
  Added a name to the spi clocks.
  Added reg-io-width property to spi bindings.
  Assigned a default parent to K210_CLK_SPI3.
  Removed assigned clocks for ACLK and PLLs.
  Removed u-boot,dm-pre-reloc bindings.

 arch/riscv/dts/Makefile |   1 +
 arch/riscv/dts/k210-maix-bit.dts|  42 +++
 arch/riscv/dts/k210.dtsi| 453 
 board/sipeed/maix/Kconfig   |   3 +
 configs/sipeed_maix_bitm_defconfig  |   1 +
 include/dt-bindings/clock/k210-sysctl.h |  54 +++
 include/dt-bindings/reset/k210-sysctl.h |  38 ++
 7 files changed, 592 insertions(+)
 create mode 100644 arch/riscv/dts/k210-maix-bit.dts
 create mode 100644 arch/riscv/dts/k210.dtsi
 create mode 100644 include/dt-bindings/clock/k210-sysctl.h
 create mode 100644 include/dt-bindings/reset/k210-sysctl.h

diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
index 4f30e6936f..3a6f96c67d 100644
--- a/arch/riscv/dts/Makefile
+++ b/arch/riscv/dts/Makefile
@@ -2,6 +2,7 @@
 
 dtb-$(CONFIG_TARGET_AX25_AE350) += ae350_32.dtb ae350_64.dtb
 dtb-$(CONFIG_TARGET_SIFIVE_FU540) += hifive-unleashed-a00.dtb
+dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb
 
 targets += $(dtb-y)
 
diff --git a/arch/riscv/dts/k210-maix-bit.dts b/arch/riscv/dts/k210-maix-bit.dts
new file mode 100644
index 00..a25aa34ff8
--- /dev/null
+++ b/arch/riscv/dts/k210-maix-bit.dts
@@ -0,0 +1,42 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Sean Anderson 
+ */
+
+/dts-v1/;
+
+#include "k210.dtsi"
+
+/ {
+   model = "Sipeed Maix Bit";
+   compatible = "sipeed,maix-bit", "kendryte,k210";
+
+   chosen {
+   bootargs = "console=ttyS0,115200n8 debug loglevel=7";
+   stdout-path = "serial0";
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   slot@0 {
+   compatible = "mmc-spi-slot";
+   reg = <0>;
+   broken-cd;
+   disable-wp;
+   };
+};
+
+ {
+   status = "okay";
+   spi-flash@0 {
+   compatible = "gd25lq64c", "gd25q64", "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <12000>;
+   m25p,fast-read;
+   };
+};
diff --git a/arch/riscv/dts/k210.dtsi b/arch/riscv/dts/k210.dtsi
new file mode 100644
index 00..1408d9b4a9
--- /dev/null
+++ b/arch/riscv/dts/k210.dtsi
@@ -0,0 +1,453 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Sean Anderson 
+ */
+
+#include 
+#include 
+
+/ {
+   /*
+* Although 

[PATCH v2 07/11] riscv: Add initial Sipeed Maix support

[Sean Anderson]

The Sipeed Maix series is a collection of boards built around the RISC-V
Kendryte K210 processor. This processor contains several peripherals to
accelerate neural network processing and other "ai" tasks. This includes a "KPU"
neural network processor, an audio processor supporting beamforming reception,
and a digital video port supporting capture and output at VGA resolution. Other
peripherals include 8M of sram (accessible with and without caching);
remappable pins, including 40 GPIOs; AES, FFT, and SHA256 accelerators; a DMA
controller; and I2C, I2S, and SPI controllers. Maix peripherals vary, but
include spi flash; on-board usb-serial bridges; ports for cameras, displays, and
sd cards; and ESP32 chips. Currently, only the Sipeed Maix Bit V2.0 (bitm) is
supported, but the boards are fairly similar.

Documentation for Maix boards is located at .
Documentation for the Kendryte K210 is located at
. However, hardware details are rather lacking,
so most technical reference has been taken from the standalone sdk located at
.

Signed-off-by: Sean Anderson 
---
Changes for v2:
  Select CONFIG_SYS_RISCV_NOCOUNTER.
  Imply CONFIG_CLK_K210.
  Remove spurious references to CONFIG_ARCH_K210.
  Remove many configs from defconfig where the defaults were fine.
  Add a few "not set" lines to suppress unneeded defaults.
  Reduce pre-reloc malloc space, now that clocks initialization happens
  later.
  
 arch/riscv/Kconfig |  4 ++
 board/sipeed/maix/Kconfig  | 41 +
 board/sipeed/maix/MAINTAINERS  | 13 +
 board/sipeed/maix/Makefile |  5 ++
 board/sipeed/maix/maix.c   |  9 +++
 configs/sipeed_maix_bitm_defconfig | 93 ++
 include/configs/sipeed-maix.h  | 19 ++
 7 files changed, 184 insertions(+)
 create mode 100644 board/sipeed/maix/Kconfig
 create mode 100644 board/sipeed/maix/MAINTAINERS
 create mode 100644 board/sipeed/maix/Makefile
 create mode 100644 board/sipeed/maix/maix.c
 create mode 100644 configs/sipeed_maix_bitm_defconfig
 create mode 100644 include/configs/sipeed-maix.h

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 4f8c62dcff..4c62b8dd77 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -20,6 +20,9 @@ config TARGET_QEMU_VIRT
 config TARGET_SIFIVE_FU540
bool "Support SiFive FU540 Board"
 
+config TARGET_SIPEED_MAIX
+   bool "Support Sipeed Maix Board"
+
 endchoice
 
 config SYS_ICACHE_OFF
@@ -53,6 +56,7 @@ source "board/AndesTech/ax25-ae350/Kconfig"
 source "board/emulation/qemu-riscv/Kconfig"
 source "board/microchip/mpfs_icicle/Kconfig"
 source "board/sifive/fu540/Kconfig"
+source "board/sipeed/maix/Kconfig"
 
 # platform-specific options below
 source "arch/riscv/cpu/ax25/Kconfig"
diff --git a/board/sipeed/maix/Kconfig b/board/sipeed/maix/Kconfig
new file mode 100644
index 00..9259eb34aa
--- /dev/null
+++ b/board/sipeed/maix/Kconfig
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2019 Sean Anderson 
+
+if TARGET_SIPEED_MAIX
+
+config SYS_BOARD
+   default "maix"
+
+config SYS_VENDOR
+   default "sipeed"
+
+config SYS_CPU
+   default "generic"
+
+config SYS_CONFIG_NAME
+   default "sipeed-maix"
+
+config SYS_TEXT_BASE
+   default 0x8000
+
+config NR_CPUS
+   default 2
+
+config NR_DRAM_BANKS
+   default 2
+
+config BOARD_SPECIFIC_OPTIONS
+   def_bool y
+   select GENERIC_RISCV
+   select DM_SERIAL
+   select SIFIVE_SERIAL
+   select ARCH_DEFAULT_RV64I
+   select ENV_IS_NOWHERE
+   select SYS_RISCV_NOCOUNTER
+   imply SIFIVE_CLINT
+   imply SPI
+   imply DM_GPIO
+   imply CMD_GPIO
+   imply SYS_NS16550
+   imply SYS_MALLOC_F
+endif
diff --git a/board/sipeed/maix/MAINTAINERS b/board/sipeed/maix/MAINTAINERS
new file mode 100644
index 00..217de45970
--- /dev/null
+++ b/board/sipeed/maix/MAINTAINERS
@@ -0,0 +1,13 @@
+Sipeed Maix BOARD
+M: Sean Anderson 
+S: Maintained
+F: arch/riscv/dts/k210.dtsi
+F: arch/riscv/dts/k210-maix-bit.dts
+F: arch/riscv/include/asm/k210_sysctl.h
+F: arch/riscv/lib/k210_sysctl.c
+F: board/sipeed/maix/
+F: configs/sipeed_maix_defconfig
+F: drivers/clk/kendryte/
+F: include/configs/sipeed-maix.h
+F: include/dt-bindings/clock/k210-sysctl.h
+F: include/dt-bindings/reset/k210-sysctl.h
diff --git a/board/sipeed/maix/Makefile b/board/sipeed/maix/Makefile
new file mode 100644
index 00..4acff5b31e
--- /dev/null
+++ b/board/sipeed/maix/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (c) 2019 Western Digital Corporation or its affiliates.
+
+obj-y += maix.o
diff --git a/board/sipeed/maix/maix.c b/board/sipeed/maix/maix.c
new file mode 100644
index 00..f8e773acf7
--- /dev/null
+++ b/board/sipeed/maix/maix.c
@@ -0,0 +1,9 @@
+// 

[PATCH v2 06/11] riscv: Fix incorrect cpu frequency on RV64

[Sean Anderson]

The riscv_cpu_get_info function does not always zero-out cpu_freq. This can
cause spurious higher frequencies.

Signed-off-by Sean Anderson 
---
Changes for v2:
  New.

 drivers/cpu/riscv_cpu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/cpu/riscv_cpu.c b/drivers/cpu/riscv_cpu.c
index 28ad0aa30f..1e32bb5678 100644
--- a/drivers/cpu/riscv_cpu.c
+++ b/drivers/cpu/riscv_cpu.c
@@ -29,6 +29,8 @@ static int riscv_cpu_get_info(struct udevice *dev, struct 
cpu_info *info)
 {
const char *mmu;
 
+   /* Zero out the frequency, in case sizeof(ulong) != sizeof(u32) */
+   info->cpu_freq = 0;
dev_read_u32(dev, "clock-frequency", (u32 *)>cpu_freq);
 
mmu = dev_read_string(dev, "mmu-type");
-- 
2.24.1

[PATCH v2 05/11] riscv: Add option to disable writes to mcounteren

[Sean Anderson]

On the kendryte k210, writes to mcounteren result in an illegal instruction
exception.

Signed-off-by: Sean Anderson 
---
Changes for v2:
 Moved forward in the patch series

 arch/riscv/Kconfig   | 3 +++
 arch/riscv/cpu/cpu.c | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 9a7b0334c2..4f8c62dcff 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -226,6 +226,9 @@ config XIP
  from a NOR flash memory without copying the code to ram.
  Say yes here if U-Boot boots from flash directly.
 
+config SYS_RISCV_NOCOUNTER
+   bool "Disable accesses to the mcounteren CSR"
+
 config STACK_SIZE_SHIFT
int
default 14
diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
index e457f6acbf..df9eae663c 100644
--- a/arch/riscv/cpu/cpu.c
+++ b/arch/riscv/cpu/cpu.c
@@ -89,7 +89,9 @@ int arch_cpu_init_dm(void)
 * Enable perf counters for cycle, time,
 * and instret counters only
 */
+#ifndef CONFIG_SYS_RISCV_NOCOUNTER
csr_write(CSR_MCOUNTEREN, GENMASK(2, 0));
+#endif
 
/* Disable paging */
if (supports_extension('s'))
-- 
2.24.1

[PATCH v2 04/11] riscv: Add an option to default to RV64I

[Sean Anderson]

This allows 64-bit boards to default to the 64-bit instruction set
without changing the current default of 32-bit.

Signed-off-by: Sean Anderson 
---
 arch/riscv/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 85e15ebffa..9a7b0334c2 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -60,8 +60,12 @@ source "arch/riscv/cpu/generic/Kconfig"
 
 # architecture-specific options below
 
+config ARCH_DEFAULT_RV64I
+   bool
+
 choice
prompt "Base ISA"
+   default ARCH_RV64I if ARCH_DEFAULT_RV64I
default ARCH_RV32I
 
 config ARCH_RV32I
-- 
2.24.1

[PATCH v2 03/11] riscv: Add headers for asm/global_data.h

[Sean Anderson]

This header depended on bd_t and ulong, but did not include the appropriate
headers.

Signed-off-by: Sean Anderson 
---
 arch/riscv/include/asm/global_data.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/riscv/include/asm/global_data.h 
b/arch/riscv/include/asm/global_data.h
index b74bd7e738..4f0c12b402 100644
--- a/arch/riscv/include/asm/global_data.h
+++ b/arch/riscv/include/asm/global_data.h
@@ -11,6 +11,8 @@
 #define __ASM_GBL_DATA_H
 
 #include 
+#include 
+#include 
 
 /* Architecture-specific global data */
 struct arch_global_data {
-- 
2.24.1

[PATCH v2 02/11] clk: Check that ops of composite clock components, exist before calling

[Sean Anderson]

clk_composite_ops was shared between all devices in the composite clock driver.
If one clock had a feature (such as supporting set_parent) which another clock
did not, it could call a null pointer dereference.

This patch does three things
1. It adds null-pointer checks to all composite clock functions.
2. It makes clk_composite_ops const and sets its functions at compile-time.
3. It adds some basic sanity checks to num_parents.

The combined effect of these changes is that any of mux, rate, or gate can be
NULL, and composite clocks will still function normally. Previously, at least
mux had to exist, since clk_composite_get_parent was used to determine the
parent for clk_register.

Signed-off-by: Sean Anderson 
---
 drivers/clk/clk-composite.c | 57 +++--
 1 file changed, 35 insertions(+), 22 deletions(-)

diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
index d0f273d47f..ea9982fd57 100644
--- a/drivers/clk/clk-composite.c
+++ b/drivers/clk/clk-composite.c
@@ -22,7 +22,10 @@ static u8 clk_composite_get_parent(struct clk *clk)
(struct clk *)dev_get_clk_ptr(clk->dev) : clk);
struct clk *mux = composite->mux;
 
-   return clk_mux_get_parent(mux);
+   if (mux)
+   return clk_mux_get_parent(mux);
+   else
+   return 0;
 }
 
 static int clk_composite_set_parent(struct clk *clk, struct clk *parent)
@@ -32,7 +35,10 @@ static int clk_composite_set_parent(struct clk *clk, struct 
clk *parent)
const struct clk_ops *mux_ops = composite->mux_ops;
struct clk *mux = composite->mux;
 
-   return mux_ops->set_parent(mux, parent);
+   if (mux && mux_ops)
+   return mux_ops->set_parent(mux, parent);
+   else
+   return -ENOTSUPP;
 }
 
 static unsigned long clk_composite_recalc_rate(struct clk *clk)
@@ -42,7 +48,10 @@ static unsigned long clk_composite_recalc_rate(struct clk 
*clk)
const struct clk_ops *rate_ops = composite->rate_ops;
struct clk *rate = composite->rate;
 
-   return rate_ops->get_rate(rate);
+   if (rate && rate_ops)
+   return rate_ops->get_rate(rate);
+   else
+   return clk_get_parent_rate(clk);
 }
 
 static ulong clk_composite_set_rate(struct clk *clk, unsigned long rate)
@@ -52,7 +61,10 @@ static ulong clk_composite_set_rate(struct clk *clk, 
unsigned long rate)
const struct clk_ops *rate_ops = composite->rate_ops;
struct clk *clk_rate = composite->rate;
 
-   return rate_ops->set_rate(clk_rate, rate);
+   if (rate && rate_ops)
+   return rate_ops->set_rate(clk_rate, rate);
+   else
+   return -ENOTSUPP;
 }
 
 static int clk_composite_enable(struct clk *clk)
@@ -62,7 +74,10 @@ static int clk_composite_enable(struct clk *clk)
const struct clk_ops *gate_ops = composite->gate_ops;
struct clk *gate = composite->gate;
 
-   return gate_ops->enable(gate);
+   if (gate && gate_ops)
+   return gate_ops->enable(gate);
+   else
+   return -ENOTSUPP;
 }
 
 static int clk_composite_disable(struct clk *clk)
@@ -72,15 +87,12 @@ static int clk_composite_disable(struct clk *clk)
const struct clk_ops *gate_ops = composite->gate_ops;
struct clk *gate = composite->gate;
 
-   gate_ops->disable(gate);
-
-   return 0;
+   if (gate && gate_ops)
+   return gate_ops->disable(gate);
+   else
+   return -ENOTSUPP;
 }
 
-struct clk_ops clk_composite_ops = {
-   /* This will be set according to clk_register_composite */
-};
-
 struct clk *clk_register_composite(struct device *dev, const char *name,
   const char * const *parent_names,
   int num_parents, struct clk *mux,
@@ -94,7 +106,9 @@ struct clk *clk_register_composite(struct device *dev, const 
char *name,
struct clk *clk;
struct clk_composite *composite;
int ret;
-   struct clk_ops *composite_ops = _composite_ops;
+
+   if (!num_parents || (num_parents != 1 && !mux))
+   return ERR_PTR(-EINVAL);
 
composite = kzalloc(sizeof(*composite), GFP_KERNEL);
if (!composite)
@@ -103,8 +117,6 @@ struct clk *clk_register_composite(struct device *dev, 
const char *name,
if (mux && mux_ops) {
composite->mux = mux;
composite->mux_ops = mux_ops;
-   if (mux_ops->set_parent)
-   composite_ops->set_parent = clk_composite_set_parent;
mux->data = (ulong)composite;
}
 
@@ -113,11 +125,6 @@ struct clk *clk_register_composite(struct device *dev, 
const char *name,
clk = ERR_PTR(-EINVAL);
goto err;
}
-   composite_ops->get_rate = clk_composite_recalc_rate;
-
-   /* .set_rate requires either .round_rate or .determine_rate 

[PATCH v2 01/11] clk: Always use the supplied struct clk

[Sean Anderson]

CCF clocks should always use the struct clock passed to their methods for
extracting the driver-specific clock information struct. Previously, many
functions would use the clk->dev->priv if the device was bound. This could cause
problems with composite clocks. The individual clocks in a composite clock did
not have the ->dev field filled in. This was fine, because the device-specific
clock information would be used. However, since there was no ->dev, there was no
way to get the parent clock. This caused the recalc_rate method of the CCF
divider clock to fail. One option would be to use the clk->priv field to get the
composite clock and from there get the appropriate parent device. However, this
would tie the implementation to the composite clock. In general, different
devices should not rely on the contents of ->priv from another device.

The simple solution to this problem is to just always use the supplied struct
clock. The composite clock now fills in the ->dev pointer of its child clocks.
This allows child clocks to make calls like clk_get_parent() without issue.

imx avoided the above problem by using a custom get_rate function with composite
clocks.

Signed-off-by: Sean Anderson 
---
 drivers/clk/clk-composite.c|  8 
 drivers/clk/clk-divider.c  |  6 ++
 drivers/clk/clk-fixed-factor.c |  3 +--
 drivers/clk/clk-gate.c |  6 ++
 drivers/clk/clk-mux.c  | 12 
 drivers/clk/imx/clk-gate2.c|  4 ++--
 6 files changed, 19 insertions(+), 20 deletions(-)

diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
index a5626c33d1..d0f273d47f 100644
--- a/drivers/clk/clk-composite.c
+++ b/drivers/clk/clk-composite.c
@@ -145,6 +145,14 @@ struct clk *clk_register_composite(struct device *dev, 
const char *name,
goto err;
}
 
+   if (composite->mux)
+   composite->mux->dev = clk->dev;
+   if (composite->rate)
+   composite->rate->dev = clk->dev;
+   if (composite->gate)
+   composite->gate->dev = clk->dev;
+
+
return clk;
 
 err:
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 822e09b084..bfa05f24a3 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -70,8 +70,7 @@ unsigned long divider_recalc_rate(struct clk *hw, unsigned 
long parent_rate,
 
 static ulong clk_divider_recalc_rate(struct clk *clk)
 {
-   struct clk_divider *divider = to_clk_divider(clk_dev_binded(clk) ?
-   dev_get_clk_ptr(clk->dev) : clk);
+   struct clk_divider *divider = to_clk_divider(clk);
unsigned long parent_rate = clk_get_parent_rate(clk);
unsigned int val;
 
@@ -150,8 +149,7 @@ int divider_get_val(unsigned long rate, unsigned long 
parent_rate,
 
 static ulong clk_divider_set_rate(struct clk *clk, unsigned long rate)
 {
-   struct clk_divider *divider = to_clk_divider(clk_dev_binded(clk) ?
-   dev_get_clk_ptr(clk->dev) : clk);
+   struct clk_divider *divider = to_clk_divider(clk);
unsigned long parent_rate = clk_get_parent_rate(clk);
int value;
u32 val;
diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
index 711b0588bc..d2401cf440 100644
--- a/drivers/clk/clk-fixed-factor.c
+++ b/drivers/clk/clk-fixed-factor.c
@@ -18,8 +18,7 @@
 
 static ulong clk_factor_recalc_rate(struct clk *clk)
 {
-   struct clk_fixed_factor *fix =
-   to_clk_fixed_factor(dev_get_clk_ptr(clk->dev));
+   struct clk_fixed_factor *fix = to_clk_fixed_factor(clk);
unsigned long parent_rate = clk_get_parent_rate(clk);
unsigned long long int rate;
 
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index 70b8794554..b2933bc24a 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -43,8 +43,7 @@
  */
 static void clk_gate_endisable(struct clk *clk, int enable)
 {
-   struct clk_gate *gate = to_clk_gate(clk_dev_binded(clk) ?
-   dev_get_clk_ptr(clk->dev) : clk);
+   struct clk_gate *gate = to_clk_gate(clk);
int set = gate->flags & CLK_GATE_SET_TO_DISABLE ? 1 : 0;
u32 reg;
 
@@ -86,8 +85,7 @@ static int clk_gate_disable(struct clk *clk)
 
 int clk_gate_is_enabled(struct clk *clk)
 {
-   struct clk_gate *gate = to_clk_gate(clk_dev_binded(clk) ?
-   dev_get_clk_ptr(clk->dev) : clk);
+   struct clk_gate *gate = to_clk_gate(clk);
u32 reg;
 
 #if CONFIG_IS_ENABLED(SANDBOX_CLK_CCF)
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 5acc0b8cbd..67b4afef28 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -35,8 +35,7 @@
 int clk_mux_val_to_index(struct clk *clk, u32 *table, unsigned int flags,
 unsigned int val)
 {
-   struct clk_mux *mux = to_clk_mux(clk_dev_binded(clk) ?
-   dev_get_clk_ptr(clk->dev) : clk);
+   struct clk_mux *mux = to_clk_mux(clk);

[PATCH v2 00/11] riscv: Add Sipeed Maix support

[Sean Anderson]

This patch series adds support for Sipeed Maix boards and the
Kendryte K210 CPU. Currently, only the Maix Bit V2.0 is supported,
however other models are similar. This series depends on

(clk: Include missing headers for linux/clk-provider.h).

To flash u-boot to a maix bit, run
kflash -tp /dev/ -B bit_mic u-boot-dtb.bin

Boot output should look like the following:

U-Boot 2020.01-00455-gad03fd83e1 (Jan 15 2020 - 17:10:24 -0500)

DRAM:  8 MiB
MMC:   spi@5200:slot@0: 0
In:serial@3800
Out:   serial@3800
Err:   serial@3800
=> 

I would really appreciate feedback! Many of the changes I had to make
for this revision were fairly trivial and could have been caught by
someone more familiar with the source code than I. In particular, there
are still some questions in individual patches which have yet to be
answered.

Changes for v2:
  Many bugfixes for the device tree.
  Modify the config to build without errors.
  Add support for keeping internal PLL frequencies in-range.
  Fix several rebase-induced artifacts.

Sean Anderson (11):
  clk: Always use the supplied struct clk
  clk: Check that ops of composite clock components exist before calling
  riscv: Add headers for asm/global_data.h
  riscv: Add an option to default to RV64I
  riscv: Add option to disable writes to mcounteren
  riscv: Fix incorrect cpu frequency on RV64
  riscv: Add initial Sipeed Maix support
  riscv: Add device tree for K210
  riscv: Add K210 sysctl support
  riscv: Add K210 pll support
  riscv: Add K210 clock support

 arch/riscv/Kconfig  |  19 +
 arch/riscv/cpu/cpu.c|   2 +
 arch/riscv/dts/Makefile |   1 +
 arch/riscv/dts/k210-maix-bit.dts|  42 ++
 arch/riscv/dts/k210.dtsi| 453 ++
 arch/riscv/include/asm/global_data.h|   2 +
 arch/riscv/include/asm/k210_sysctl.h|  43 ++
 arch/riscv/lib/Makefile |   1 +
 arch/riscv/lib/k210_sysctl.c|  21 +
 board/sipeed/maix/Kconfig   |  49 ++
 board/sipeed/maix/MAINTAINERS   |  13 +
 board/sipeed/maix/Makefile  |   5 +
 board/sipeed/maix/maix.c|   9 +
 configs/sipeed_maix_bitm_defconfig  |  95 
 drivers/clk/Kconfig |   1 +
 drivers/clk/Makefile|   1 +
 drivers/clk/clk-composite.c |  65 ++-
 drivers/clk/clk-divider.c   |   6 +-
 drivers/clk/clk-fixed-factor.c  |   3 +-
 drivers/clk/clk-gate.c  |   6 +-
 drivers/clk/clk-mux.c   |  12 +-
 drivers/clk/imx/clk-gate2.c |   4 +-
 drivers/clk/kendryte/Kconfig|   7 +
 drivers/clk/kendryte/Makefile   |   1 +
 drivers/clk/kendryte/clk.c  | 390 
 drivers/clk/kendryte/clk.h  |  27 ++
 drivers/clk/kendryte/pll.c  | 598 
 drivers/clk/kendryte/pll.h  |  38 ++
 drivers/cpu/riscv_cpu.c |   2 +
 include/configs/sipeed-maix.h   |  19 +
 include/dt-bindings/clock/k210-sysctl.h |  54 +++
 include/dt-bindings/reset/k210-sysctl.h |  38 ++
 32 files changed, 1985 insertions(+), 42 deletions(-)
 create mode 100644 arch/riscv/dts/k210-maix-bit.dts
 create mode 100644 arch/riscv/dts/k210.dtsi
 create mode 100644 arch/riscv/include/asm/k210_sysctl.h
 create mode 100644 arch/riscv/lib/k210_sysctl.c
 create mode 100644 board/sipeed/maix/Kconfig
 create mode 100644 board/sipeed/maix/MAINTAINERS
 create mode 100644 board/sipeed/maix/Makefile
 create mode 100644 board/sipeed/maix/maix.c
 create mode 100644 configs/sipeed_maix_bitm_defconfig
 create mode 100644 drivers/clk/kendryte/Kconfig
 create mode 100644 drivers/clk/kendryte/Makefile
 create mode 100644 drivers/clk/kendryte/clk.c
 create mode 100644 drivers/clk/kendryte/clk.h
 create mode 100644 drivers/clk/kendryte/pll.c
 create mode 100644 drivers/clk/kendryte/pll.h
 create mode 100644 include/configs/sipeed-maix.h
 create mode 100644 include/dt-bindings/clock/k210-sysctl.h
 create mode 100644 include/dt-bindings/reset/k210-sysctl.h

-- 
2.24.1

Re: [PATCH] clk: Fix error checking of dev_read_addr_ptr

[Sean Anderson]

On 12/24/19 11:57 PM, Sean Anderson wrote:
> dev_read_addr_ptr returns NULL on error, not FDT_ADDR_T_NONE.
> 
> Signed-off-by: Sean Anderson 

*bump*

Lukasz do you have any comments?

Re: [PATCH 6/6] fastboot: mt85xx: add command to flash/erase emmc hwpart

[Tom Rini]

On Mon, Jan 06, 2020 at 02:26:49PM +0800, mingming lee wrote:

> This patch includes the following:
> 1. Add fastboot command to erase the whole EMMC_USER
> 2. Add fastboot command to flash image at EMMC_BOOT1
> 3. Add fastboot command to erase the whole EMMC_BOOT1
> 4. Enale CONFIG_FASTBOOT_MMC_BOOT1_SUPPORT for mt8518
> 
> Signed-off-by: mingming lee 

This breaks building of dra7xx_evm and possibly others, thanks.

-- 
Tom


signature.asc
Description: PGP signature

Re: [U-Boot] [PATCH 1/4] asm: dma-mapping.h: Fix dma mapping functions

[Tom Rini]

On Fri, Nov 15, 2019 at 05:25:02PM +0530, Vignesh Raghavendra wrote:

> Subsystems such as USB expect dma_map_single() and dma_unmap_single() to
> do dcache flush/invalidate operations as required. For example, see
> drivers/usb/gadget/udc/udc-core.c::usb_gadget_map_request().
> Currently drivers do this locally, (see drivers/usb/dwc3/ep0.c,
> drivers/mtd/nand/raw/denali.c etc..)
> Update arch specific dma_map_single() and dma_unmap_single() APIs to do
> cache flush/invalidate  operations, so that drivers need not implement
> them locally.
> 
> Signed-off-by: Vignesh Raghavendra 
> Reviewed-by: Masahiro Yamada 
> Reviewed-by: Rick Chen 
> ---
>  arch/arm/include/asm/dma-mapping.h   | 22 --
>  arch/nds32/include/asm/dma-mapping.h | 22 --
>  arch/riscv/include/asm/dma-mapping.h | 22 --
>  arch/x86/include/asm/dma-mapping.h   | 22 --
>  4 files changed, 80 insertions(+), 8 deletions(-)

This throws warnings on am335x_evm, please re-check and resubmit,
thanks.

-- 
Tom


signature.asc
Description: PGP signature

Re: [U-Boot] [RESEND PATCH] common: add blkcache init

[Tom Rini]

On Sat, Nov 23, 2019 at 11:51:11PM +0100, Angelo Dureghello wrote:

> From: Angelo Durgehello 
> 
> On m68k, block_cache list is relocated, but next and prev list
> pointers are not adjusted to the relocated struct list_head address,
> so the first iteration over the block_cache list hangs.
> 
> This patch initializes the block_cache list after relocation.
> 
> Signed-off-by: Angelo Durgehello 

As noted by Eric in the original posting, we don't need the indirection
just for the name as there's not really a hard rule about names there,
please just call the function directly, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [RFC WIP PATCH v1 7/7] wandboard: in SPL use only D1 DTB

[Fabio Estevam]

Hi Heiko,

On Tue, Jan 14, 2020 at 3:14 AM Heiko Schocher  wrote:

> +#if defined(CONFIG_SPL_BUILD)
> +   /* in SPL we use only revision D1 DTB */
> +   if (1) {
> +#else
> if (is_revd1()) {
> +#endif

Is there a way to improve is_revd1() so that it can call i2c_probe()
and detect whether the PMIC is present or not?

Thanks

Re: [RFC WIP PATCH v1 6/7] wandboard: add u-boot specific *wandboard-revd1-u-boot.dtsi

[Fabio Estevam]

Hi Heiko,

On Tue, Jan 14, 2020 at 3:14 AM Heiko Schocher  wrote:
>
> we want to access PMIC before relocation, so we need
> to add u-boot specific "u-boot,dm-pre-reloc" properties.
>
> Signed-off-by: Heiko Schocher 
> ---
>
>  arch/arm/dts/imx6dl-wandboard-revd1-u-boot.dtsi | 11 +++
>  arch/arm/dts/imx6q-wandboard-revd1-u-boot.dtsi  | 11 +++
>  2 files changed, 22 insertions(+)
>  create mode 100644 arch/arm/dts/imx6dl-wandboard-revd1-u-boot.dtsi
>  create mode 100644 arch/arm/dts/imx6q-wandboard-revd1-u-boot.dtsi

The imx6q-wandboard-revd1-u-boot.dtsi is missing.

Thanks

Re: Pull request for UEFI sub-system for efi-2020-04-rc1-2

[Tom Rini]

On Wed, Jan 15, 2020 at 08:04:48AM +0100, Heinrich Schuchardt wrote:

> The following changes since commit 88366b96ee0d8640b2af53e4026dbaeed0fab5e0:
> 
>   travis: Switch to QEMU v4.2.0 globally (2020-01-11 08:07:03 -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
> tags/efi-2020-04-rc1-2
> 
> for you to fetch changes up to faadc04180ef05acfd6523b49a2abf37ae61afad:
> 
>   efi_loader: imply VIDEO_ANSI (2020-01-15 00:51:51 +0100)
> 
> Gitlab CI and Travis CI showed no problems:
> https://gitlab.denx.de/u-boot/custodians/u-boot-efi/pipelines/1851
> https://travis-ci.org/xypron2/u-boot/builds/637171603
> 
> Primary key fingerprint:
> 6DC4 F9C7 1F29 A6FA 06B7  6D33 C481 DBBC 2C05 1AC4
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

[PATCH] arm: dts: imx7ulp-evk: remove mux value from pad configuration

[Jorge Ramirez-Ortiz]

The mux mode is embedded in the PAD definition and therefore there is
no need to repeat it in the PAD configuration value (more over since
this information will be masked out when the configuration value is
applied).

Signed-off-by: Jorge Ramirez-Ortiz 
---
 arch/arm/dts/imx7ulp-evk.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/dts/imx7ulp-evk.dts b/arch/arm/dts/imx7ulp-evk.dts
index 08a682f314..8f6a935e24 100644
--- a/arch/arm/dts/imx7ulp-evk.dts
+++ b/arch/arm/dts/imx7ulp-evk.dts
@@ -156,7 +156,7 @@
 
pinctrl_backlight: backlight_grp {
fsl,pins = <
-   IMX7ULP_PAD_PTF2__PTF2  0x20100
+   IMX7ULP_PAD_PTF2__PTF2  0x2
>;
};
 
-- 
2.17.1

Re: [PATCH 3/3] riscv: sifive: fu540: add SPL configuration

[Lukas Auer]

On Tue, 2020-01-14 at 23:12 -0600, Troy Benjegerdes wrote:
> > On Jan 13, 2020, at 4:31 PM, Lukas Auer  wrote:
> > 
> > +Troy
> > 
> > On Mon, 2020-01-13 at 14:32 +, Pragnesh Patel wrote:
> > > > > > +#include 
> > > > > > +
> > > > > > +u32 DENALI_PHY_DATA[1215] = {
> > > > > > +   DENALI_PHY_00_DATA, DENALI_PHY_01_DATA,
> > > > > DENALI_PHY_02_DATA,
> > > > > > +   DENALI_PHY_03_DATA, DENALI_PHY_04_DATA,
> > > > > DENALI_PHY_05_DATA,
> > > > > > +   DENALI_PHY_06_DATA, DENALI_PHY_07_DATA,
> > > > > DENALI_PHY_08_DATA,
> > > > > 
> > > > > Can this handle to write separate driver for ram like drivers/ram ?
> > > 
> > > We can add DM driver for RAM later. Right now, I want to get U-boot SPL 
> > > running for FU540.
> > 
> > Troy was working on a DM RAM driver that, from a first glance, already
> > looked good [1]. What is the status of the driver, can it be used here?
> > 
> > [1]: 
> > https://github.com/sifive/u-boot/blob/sandbox/drivers/ram/sifive/sdram_denali.c
> 
> It was unfortunately only a first attempt, and I never got it working.
> 
> I am hoping that someone else has time to pick it up and complete the work.
> 

Ah ok, that would have been great. It is already a very good start and
seems to be close to being complete. Perhaps it is just a matter of
debugging the code.

At the moment the driver is hard to find. It might therefore be a good
idea to post it somewhere for discussion, though I am not sure what the
best way / place of doing that is.

> Are there any other SoCs we know of besides RockChip that use this
> controller and have some sort of open boot firmware and/or U-boot support?
> 

I am not aware of any, but also don't have a good overview of what's
available.

Re: [GIT PULL] Pull request: u-boot-imx u-boot-imx-20200115

[Tom Rini]

On Wed, Jan 15, 2020 at 02:05:43PM +0100, Stefano Babic wrote:

> Hi Tom,
> 
> please pull from i.MX, thanks !
> 
> The following changes since commit 88366b96ee0d8640b2af53e4026dbaeed0fab5e0:
> 
>   travis: Switch to QEMU v4.2.0 globally (2020-01-11 08:07:03 -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git
> tags/u-boot-imx-20200115
> 
> for you to fetch changes up to 8d9c0762a8cf0a5027e7cd3c6794693f2d64d007:
> 
>   imx: imxrt1050-evk: Add support for the NXP i.MXRT1050-EVK (2020-01-14
> 22:54:00 +0100)
> 

Applied to u-boot/master, thanks!

That said:
w+(imx8qm_rom7720_a1_4G,imx8qm_mek,imx8qxp_mek,deneb,giedi,apalis-imx8qm,colibri-imx8qxp)
arch/arm/dts/imx8-deneb.dtb: Warning (cooling_device_property):
/thermal-zones/cpu-thermal0/cooling-maps/map0: Missing property
'#cooling-cells' in node /cpus/cpu@0 or bad phandle (referred from
cooling-device[0])
w+(imx8qm_rom7720_a1_4G,imx8qm_mek,imx8qxp_mek,deneb,giedi,apalis-imx8qm,colibri-imx8qxp)
arch/arm/dts/imx8-giedi.dtb: Warning (cooling_device_property):
/thermal-zones/cpu-thermal0/cooling-maps/map0: Missing property
'#cooling-cells' in node /cpus/cpu@0 or bad phandle (referred from
cooling-device[0])

Should be addressed and fixed upstream too.


-- 
Tom


signature.asc
Description: PGP signature

Re: Debugging VoCore2 ROM Startup

[Mauro Condarelli]

On 1/15/20 5:20 PM, Stefan Roese wrote:
> On 15.01.20 16:55, Mauro Condarelli wrote:
>
> 
===8<--
> in particular:
>>
>> b010: 00065144
>> System Configuration Register 0 ->   0110 0101 0001 0100
>> 0100
>>     TEST_CODE : None
>> 000 Reserved
>> 0 0110 0101 BS_SHADOW : ???
>> 000 Rseserved
>> 1   DBG_JTAG_MODE    1: Normal Boot-up
>> 0   TEST_MODE_1   : ???
>> 1   XTAL_FREQ_SEL    1: 40MHz SMD (3225)
>> 0   EXT_BG   0: BG clock from PMU
>> 0   TEST_MODE_0  0: SUTIF
>> 010 CHIP_MODE  010: Boot from XTAL (boot from SPI 3-Byte
>> ADR)
>> 0   DRAM_TYPE    0: DDR2
>>
>> which looks good to me; as said the only difference is
>> the 3-Byte SPI Addr vs. 4-Byte SPI Addr; is it relevant?
>> AFAIK my soldered SPI NOR:
>>
>> SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total
>>
>> has 3-Byte SPI Address. From data sheet:
>> The Read Data Bytes (READ) command is followed by a 3-byte address
>> (A23-A0), ...
>> What is on LinkIt?
>
> Its strapped to 4-byte. And on the GARDENA board as well.
>
>> Does that change anything in u-boot?
>
> I would not expect this to change anything, if its configured to 3-byte
> other that that you can't access anything above 16 MiB.
My SPI NOR is 16 MiB, so I cannot access anything beyond that ;)

> If you are really out of ideas and its possible for you, then please
> change
> the strapping to 4-byte "chapter 3.4 Bootstrapping Pins Description".
That wouldn't be easy as it's a SMD resistor soldered directly on the
Module.
Let's keep that as "last resort".
 
===8<--
>>
 Note: I assumed u-boot-mtmips.bin is linked at 9c00, right?
>>>
>>> You don't need to know where it is linked to if you program it into
>>> SPI NOR. But yes, the first stage the SPL is linked to 0x9c00.
>> Can You elaborate, please?
>
> Each image generated to boot from SPI NOR needs to be linked to 9c00.
> This is what the ROM image (non-RAM) of mainline does and the SPL image
> of the dual image version (SPL plus main U-Boot proper) does.
>
>> I know for sure that if I flash at 3 a u-boot that has been compiled
>> with SYS_TEXT_BASE = 0x9c00 it will not start with "go 9c03"
>> I need to rebuild with SYS_TEXT_BASE = 0x9c03.
>
> But you flash at offset 0 in SPI NOR, right? That's where the SoC starts
> reading the bootloader binary after a reset or on power-up.
I was trying to say that, in my "secondary u-boot" attempts, where I
start from "paleolithic" and then do a "go " I need to put the
secondary at the same address specified in SYS_TEXT_BASE.
I mean:
if I want to boot directly from new then
    SYS_TEXT_BASE = 0x9c00
    flash at start of SPI NOR
    go 9c00
else if I want to start "secondary" then
    SYS_TEXT_BASE = 0x9c03
    flash at offset 3 in SPI NOR
    go 9c03
Any other combination does not work (i.e.: I cannot flash and run at
start an u-boot compiled with SYS_TEXT_BASE = 0x9c03 and
vice versa).

Note: I had to edit directly .config to change SYS_TEXT_BASE, apparently
it is visible in menuconfig only for ARM; am I missing something?
>  
===8<--

I do have a led I can use for crude signalling, but I'm not really familiar
with mips Assembly.
Can You share the code to turn it on? (it is connected to
GPIO44/WLED(pin144).
>
> Thanks,
> Stefan
>
TiA!
Mauro

Re: [PATCH v2 1/2] Kconfig: add btrfs to distro boot

[Matthias Brugger]

On 15/01/2020 17:07, Adam Ford wrote:
> On Wed, Jan 15, 2020 at 9:55 AM  wrote:
>>
>> From: Matthias Brugger 
>>
>> Some distributions use btrfs as the default file system.
>> Enable btrfs support by default when using distro boot for all
>> architectures but riscv, as it breaks compilation due to size problems.
>>
>> Signed-off-by: Matthias Brugger 
>>
>> ---
>>
>> Changes in v2:
>> - disable default btrfs support riscv
>>
>>  Kconfig | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/Kconfig b/Kconfig
>> index 99cc56f3c2..f0abf91e99 100644
>> --- a/Kconfig
>> +++ b/Kconfig
>> @@ -79,6 +79,7 @@ config DISTRO_DEFAULTS
>> select CMDLINE_EDITING
>> select CMD_BOOTI if ARM64
>> select CMD_BOOTZ if ARM && !ARM64
>> +   select CMD_BTRFS if !RISCV
> 
> Any chance this could be done with 'imply' instead of 'select' to give
> people the ability to turn it off if they want?
> 

Sounds reasonable. I'll change that in v3.

Thanks for the feedback!

Matthias

Re: [PATCH] arm: exynos: Use proper ADC device name

[Anand Moon]

Hi Marek,

On Tue, 14 Jan 2020 at 19:34, Marek Szyprowski  wrote:
>
> Since commit 4213609cc7 ("drivers: core: use strcmp when find device by
> name") one has to provide full name to get requested object. Fix the code
> used to detect Odroid board revision to use proper ADC device name then.
>
> Signed-off-by: Marek Szyprowski 
> ---
>  board/samsung/common/exynos5-dt-types.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/board/samsung/common/exynos5-dt-types.c 
> b/board/samsung/common/exynos5-dt-types.c
> index 516c32923e..d51cc4eedc 100644
> --- a/board/samsung/common/exynos5-dt-types.c
> +++ b/board/samsung/common/exynos5-dt-types.c
> @@ -67,7 +67,7 @@ static int odroid_get_adc_val(unsigned int *adcval)
> unsigned int adcval_prev = 0;
> int ret, retries = 20;
>
> -   ret = adc_channel_single_shot("adc", CONFIG_ODROID_REV_AIN,
> +   ret = adc_channel_single_shot("adc@12D1", CONFIG_ODROID_REV_AIN,
>   _prev);
> if (ret)
> return ret;
> @@ -75,8 +75,8 @@ static int odroid_get_adc_val(unsigned int *adcval)
> while (retries--) {
> mdelay(5);
>
> -   ret = adc_channel_single_shot("adc", CONFIG_ODROID_REV_AIN,
> - adcval);
> +   ret = adc_channel_single_shot("adc@12D1",
> + CONFIG_ODROID_REV_AIN, adcval);
> if (ret)
> return ret;
>
> --
> 2.17.1
>

Please add my
Reviewed-by: Anand Moon 

-Anand

Re: [PATCH] arm: exynos: Read default MMC device from XOM[7:5] pins

[Anand Moon]

Hi Marek,

On Wed, 15 Jan 2020 at 19:36, Marek Szyprowski  wrote:
>
> XOM pins provide information for iROM bootloader about the boot device.
> Those pins are mapped to lower bits of OP_MODE register (0x1008),
> which is common for all Exynos SoC variants. Set the default MMC device id
> to reflect the boot device selected by XOM[7:5] pins (2 for the SD or 0 for
> the eMMC).
>
> Signed-off-by: Marek Szyprowski 
> ---
>  arch/arm/mach-exynos/include/mach/cpu.h |  1 +
>  board/samsung/common/board.c| 14 ++
>  2 files changed, 15 insertions(+)
>
> diff --git a/arch/arm/mach-exynos/include/mach/cpu.h 
> b/arch/arm/mach-exynos/include/mach/cpu.h
> index 766edeeb29..fb5fdaf3ba 100644
> --- a/arch/arm/mach-exynos/include/mach/cpu.h
> +++ b/arch/arm/mach-exynos/include/mach/cpu.h
> @@ -17,6 +17,7 @@
>
>  #define EXYNOS4_GPIO_PART3_BASE0x0386
>  #define EXYNOS4_PRO_ID 0x1000
> +#define EXYNOS4_OP_MODE0x1008
>  #define EXYNOS4_SYSREG_BASE0x1001
>  #define EXYNOS4_POWER_BASE 0x1002
>  #define EXYNOS4_SWRESET0x10020400
> diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
> index ee2fc7971e..ac91c0a6fb 100644
> --- a/board/samsung/common/board.c
> +++ b/board/samsung/common/board.c
> @@ -359,3 +359,17 @@ int board_usb_cleanup(int index, enum usb_init_type init)
>  #endif
> return 0;
>  }
> +
> +/**
> + * mmc_get_env_dev() - read boot MMC device id from XOM[7:5] pins.
> + */
> +int mmc_get_env_dev(void)
> +{
> +   u32 mode = readl(EXYNOS4_OP_MODE) & 0x1C;
> +
> +   if (mode == 0x04)
> +   return 2; /* MMC2: SD */
> +
> +   /* MMC0: eMMC or unknown */
> +   return 0;
> +}
> --
> 2.17.1
>
If you could add some debug prints which boot mode got selected,
It will be much help. Please add my

Reviewed-by: Anand Moon 

-Anand

Re: Debugging VoCore2 ROM Startup

[Stefan Roese]

On 15.01.20 16:55, Mauro Condarelli wrote:




=> md b000
b000: 3637544d 20203832 0010 00010102    MT7628  
b010: 00156156 02605500      Va...U`.
b020: 1024  0071 0020100c    ..$.q. .
b030: ffc0 0400 c0030004 00fe00ff    
b040:  0001      
b050:    0810    
b060: 50050404 05550551      ...PQ.U.

This is my register dump, for reference:
VoCore2 > md b000
b000: 3637544d 20203832 0001 00010102    MT7628  
b010: 00144144 02605500      DA...U`.
b020: 1024  0071 0020100c    ..$.q. .
b030: f9bfffc0 0640 c0030200 00fe01ff    ..@.
b040:  0001      
b050:    0810    
b060: 5505040c 05540555      ...UU.T.


Okay, thanks. We can compare this now in depth.

On this machine (theoretically identical to the previous one; now
useless till
I reflash it) register dump is a bit different:

VoCore2 > md b000
b000: 3637544d 20203832 0001 00010102    MT7628  
b010: 00065144 02605500      DQ...U`.
b020: 1024  0071 0020100c    ..$.q. .
b030: f9bfffc0 0640 c0030200 00fe01ff    ..@.
b040:  0001      
b050:    0810    
b060: 5505040c 05540555      ...UU.T.

in particular:

b010: 00065144
System Configuration Register 0 ->   0110 0101 0001 0100 0100
    TEST_CODE : None
000 Reserved
0 0110 0101 BS_SHADOW : ???
000 Rseserved
1   DBG_JTAG_MODE1: Normal Boot-up
0   TEST_MODE_1   : ???
1   XTAL_FREQ_SEL1: 40MHz SMD (3225)
0   EXT_BG   0: BG clock from PMU
0   TEST_MODE_0  0: SUTIF
010 CHIP_MODE  010: Boot from XTAL (boot from SPI 3-Byte ADR)
0   DRAM_TYPE0: DDR2

which looks good to me; as said the only difference is
the 3-Byte SPI Addr vs. 4-Byte SPI Addr; is it relevant?
AFAIK my soldered SPI NOR:

SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total

has 3-Byte SPI Address. From data sheet:
The Read Data Bytes (READ) command is followed by a 3-byte address
(A23-A0), ...
What is on LinkIt?


Its strapped to 4-byte. And on the GARDENA board as well.


Does that change anything in u-boot?


I would not expect this to change anything, if its configured to 3-byte
other that that you can't access anything above 16 MiB.

If you are really out of ideas and its possible for you, then please change
the strapping to 4-byte "chapter 3.4 Bootstrapping Pins Description".
 

SYSCFG0: 00156156

CHIP_MODE: 011: XTAL with 4-byte ADR.

Mainline U-Boot reports this:

CPU:   MT7628 Rev 1.2 - Boot from XTAL (4-Byte SPI Addr)

My mainline (RAM) reports:
  CPU:   MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)


and the new code from Weijie reports this:

CPU:   MediaTek MT7688A ver:1 eco:2
Boot:  DDR2, SPI-NOR 4-Byte Addr, CPU clock from XTAL
Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz

One important difference which might explain a lot, it XTAL_FREQ_SEL
which is 0 in your case and 1 in my case.

IIUTC, then the new code from Weijie takes this XTAL selection
into account. Weijie might comment on this. I suggest that you give
this "u-boot-mtmips.bin" binary a try. Good luck. :)

No good ;(


Ughhh. Too bad. :-(

Don't tell me ;(
  

Here's transcript:

VoCore2 > usb reset; fatload usb 0 8001 u-boot-ram.bin; go 8001
(Re)start USB...
USB0:  Mediatek/Ralink USB EHCI
Register  NbrPorts 1
USB EHCI 1.00
scanning bus 0 for devices... 3 USB Device(s) found
     scanning bus for storage devices... 1 Storage Device(s) found
reading u-boot-ram.bin
...


387097 bytes read
## Starting application at 0x8001 ...
 board_debug_uart_init():
board_early_init_f():


U-Boot 2020.01-00370-g97a60844bd-dirty (Jan 13 2020 - 01:03:59 +0100)

CPU:   MT7628 Rev 1.2 - Boot from XTAL (3-Byte SPI Addr)
Model: VoCore2
DRAM:  128 MiB
WDT:   Started with servicing (60s timeout)
board_early_init_r():
arch_early_init_r():
MMC:   pinctrl_select_state_full('mmc@1013', 'default'):
mmc@1013: 0
Loading Environment from FAT... *** Warning - bad CRC, using default
environment

In:    uart2@e00
Out:   uart2@e00
Err:   uart2@e00
Model: VoCore2
arch_misc_init():
=> usb start; load usb 0:1 8500 u-boot-mtmips.bin
starting USB...
Bus ehci@101c: USB EHCI 1.00
scanning bus ehci@101c for devices... 3 USB Device(s) found
     scanning usb for storage devices... 1 Storage 

Re: [meta-freescale] Ramdisk booting: EXT4-fs (ram0): bad geometry error.

[Michael Donahoe]

What is BLK_DEV_RAM_SIZE set to in the kernel?


Michael Donahoe
Senior Developer
Systematic Consulting Group
p:  314-558-6271 ext. 106  m: 815-904-4337
a:  345 Marshall Avenue, Suite 103
St louis, MO 63119
e:  
michael.dona...@systematicgroup.com



From: meta-freesc...@lists.yoctoproject.org 
 on behalf of Yusuf 

Sent: Tuesday, January 14, 2020 11:31 PM
To: u-boot@lists.denx.de ; 
meta-freesc...@lists.yoctoproject.org 
Subject: [meta-freescale] Ramdisk booting: EXT4-fs (ram0): bad geometry error.


Hello

With t1042d4rdb-64b and yocto 2.7 ( 
https://source.codeaurora.org/external/qoriq/qoriq-components/yocto-sdk/tree/readme?h=warrior
 ) I am having bad geometry error while booting and U-boot is freezing. I 
declared "setenv intrd_high=0x" to use large rootfs but I am unable to 
reach root login. Can anyone help me about this situation ?

Full error console log is here:

RAMDISK: gzip image found at block 0
RAMDISK: incomplete write (17195 != 32768)
write error
EXT4-fs (ram0): bad geometry: block count 435752 exceeds size of device (131072 
blocks)
VFS: Mounted root (ext2 filesystem) on device 1:0.
devtmpfs: mounted
Freeing unused kernel memory: 536K
This architecture does not have kernel memory protection.
Run /sbin/init as init process
attempt to access beyond end of device
ram0: rw=0, want=450632, limit=262144
Buffer I/O error on dev ram0, logical block 225315, async page read
attempt to access beyond end of device
ram0: rw=0, want=454376, limit=262144
Buffer I/O error on dev ram0, logical block 227187, async page read
attempt to access beyond end of device
ram0: rw=0, want=458082, limit=262144
Buffer I/O error on dev ram0, logical block 229040, async page read
attempt to access beyond end of device
ram0: rw=0, want=458084, limit=262144
Buffer I/O error on dev ram0, logical block 229041, async page read
Run /etc/init as init process
attempt to access beyond end of device
ram0: rw=0, want=456378, limit=262144
Buffer I/O error on dev ram0, logical block 228188, async page read
attempt to access beyond end of device
ram0: rw=0, want=457688, limit=262144
Buffer I/O error on dev ram0, logical block 228843, async page read
attempt to access beyond end of device
ram0: rw=0, want=458086, limit=262144
Buffer I/O error on dev ram0, logical block 229042, async page read
Run /bin/init as init process
attempt to access beyond end of device
ram0: rw=0, want=457942, limit=262144
Buffer I/O error on dev ram0, logical block 228970, async page read
Run /bin/sh as init process
attempt to access beyond end of device
ram0: rw=0, want=457942, limit=262144
Buffer I/O error on dev ram0, logical block 228970, async page read
Kernel panic - not syncing: No working init found.  Try passing init= option to 
kernel. See Linux Documentation/admin.
CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.19.26+gc0c2141 #1
Call Trace:
[c001f3107c70] [c0a69bf4] .dump_stack+0xa8/0xec (unreliable)
[c001f3107d00] [c004b580] .panic+0x12c/0x2e8
[c001f3107db0] [c0002464] .kernel_init+0x10c/0x128
[c001f3107e30] [c9f4] .ret_from_kernel_thread+0x58/0x64
Rebooting in 180 seconds..

printenv output:

baudrate=115200
bdev=sda3
bootargs=root=/dev/ram rw console=ttyS0,115200
bootcmd=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate 
$othbootargs;bootm e802 e930 e880
bootdelay=3
bootfile=uImage
c=ffe
consoledev=ttyS0
eth1addr=00:04:9F:05:B7:B1
eth2addr=00:04:9F:05:B7:B2
eth3addr=00:04:9F:05:B7:B3
eth4addr=00:04:9F:05:B7:B4
eth5addr=00:04:9f:8e:7b:b4
ethact=FM1@DTSEC1
ethaddr=00:04:9F:05:B7:B0
ethprime=e1000#0
fdtaddr=200
fdtfile=uImage-t1042d4rdb.dtb
fileaddr=200
filesize=9a83
fman_ucode=eff0
gatewayip=192.168.10.4
hvboot=setenv bootargs console=$consoledev,$baudrate 
config-addr=0xfe890;bootm 0xfe870 - 0xfe880
hwconfig=fsl_ddr:bank_intlv=cs0_cs1
initrd_high=0x
ipaddr=192.168.10.99
loadaddr=100
netdev=eth0
netmask=255.255.255.0
nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath 
ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostnar
nohvboot=tftp 100 $dir/$bootfile;tftp 500 $dir/$ramdiskfile;tftp 
200 $dir/$fdtfile;setenv bootargs root=/;
othbootargs=ramdisk_size=100
ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate 
$othbootargs;tftp $ramdiskaddr $ramdiskfile;tfr
ramdisk_size=41943040
ramdiskaddr=500
ramdiskfile=fsl-image-core-t1042d4rdb.ext2.gz.u-boot
rootpath=/opt/nfsroot
serverip=192.168.10.50
tftpflash=tftpboot $loadaddr $uboot && protect off $ubootaddr +$filesize && 
erase $ubootaddr +$filesize && cp.b $loade
uboot=u-boot.bin
ubootaddr=0xeff4

Environment size: 1871/8188 bytes

and the commands I used:

tftp 1000 uImage--4.19-r0-t1042d4rdb-64b-20200106043637.bin
tftp 1f00 t1042d4rdb--4.19-r0-t1042d4rdb-64b-20200106043637.dtb
tftp 2000 rootfs.ext2.gz.u-boot
bootm 1000 

Re: [PATCH v2 1/2] Kconfig: add btrfs to distro boot

[Adam Ford]

On Wed, Jan 15, 2020 at 9:55 AM  wrote:
>
> From: Matthias Brugger 
>
> Some distributions use btrfs as the default file system.
> Enable btrfs support by default when using distro boot for all
> architectures but riscv, as it breaks compilation due to size problems.
>
> Signed-off-by: Matthias Brugger 
>
> ---
>
> Changes in v2:
> - disable default btrfs support riscv
>
>  Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Kconfig b/Kconfig
> index 99cc56f3c2..f0abf91e99 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -79,6 +79,7 @@ config DISTRO_DEFAULTS
> select CMDLINE_EDITING
> select CMD_BOOTI if ARM64
> select CMD_BOOTZ if ARM && !ARM64
> +   select CMD_BTRFS if !RISCV

Any chance this could be done with 'imply' instead of 'select' to give
people the ability to turn it off if they want?

> select CMD_DHCP if CMD_NET
> select CMD_ENV_EXISTS
> select CMD_EXT2
> --

adam

> 2.24.0
>

Re: [PATCH v2] arm: exynos: Use proper PMIC device name

[Lukasz Majewski]

On Wed, 15 Jan 2020 16:39:09 +0100
Marek Szyprowski  wrote:

> Since commit 4213609cc7 ("drivers: core: use strcmp when find device
> by name") one has to provide full name to get requested object. Fix
> the code used to detect enable power regulators on Odroid boards to
> use proper PMIC device device name then.
> 
> Signed-off-by: Marek Szyprowski 
> Reviewed-by: Anand Moon 
> ---
>  board/samsung/common/exynos5-dt-types.c | 2 +-
>  board/samsung/common/exynos5-dt.c   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/board/samsung/common/exynos5-dt-types.c
> b/board/samsung/common/exynos5-dt-types.c index
> d51cc4eedc..31e23e8b07 100644 ---
> a/board/samsung/common/exynos5-dt-types.c +++
> b/board/samsung/common/exynos5-dt-types.c @@ -129,7 +129,7 @@ static
> const char *odroid_get_type_str(void) if (gd->board_type !=
> EXYNOS5_BOARD_ODROID_XU3_REV02) goto exit;
>  
> - ret = pmic_get("s2mps11", );
> + ret = pmic_get("s2mps11_pmic@66", );
>   if (ret)
>   goto exit;
>  
> diff --git a/board/samsung/common/exynos5-dt.c
> b/board/samsung/common/exynos5-dt.c index 87eb381345..c5e77480f5
> 100644 --- a/board/samsung/common/exynos5-dt.c
> +++ b/board/samsung/common/exynos5-dt.c
> @@ -64,7 +64,7 @@ int exynos_power_init(void)
>   int ret;
>  
>  #ifdef CONFIG_PMIC_S2MPS11
> - ret = pmic_get("s2mps11_pmic", );
> + ret = pmic_get("s2mps11_pmic@66", );
>  #else
>   ret = pmic_get("max77686", );
>   if (!ret) {

Reviewed-by: Lukasz Majewski 


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgpflD7QVowSm.pgp
Description: OpenPGP digital signature