Re: [PATCH v2 4/7] clk: Add Microchip PolarFire SoC clock driver

2020-10-24 Thread Anup Patel
On Thu, Oct 22, 2020 at 1:11 PM Padmarao Begari
 wrote:
>
> Add clock driver code for the Microchip PolarFire SoC. This driver
> handles reset and clock control of the Microchip PolarFire SoC device.
>
> Signed-off-by: Padmarao Begari 
> ---
>  drivers/clk/Kconfig   |   1 +
>  drivers/clk/Makefile  |   1 +
>  drivers/clk/microchip/Kconfig |   5 +
>  drivers/clk/microchip/Makefile|   1 +
>  drivers/clk/microchip/clk_pfsoc.c | 127 +
>  drivers/clk/microchip/clk_pfsoc.h |  19 ++
>  drivers/clk/microchip/clk_pfsoc_cfg.c | 134 ++
>  drivers/clk/microchip/clk_pfsoc_periph.c  | 173 ++
>  .../dt-bindings/clock/microchip,pfsoc-clock.h |  45 +
>  9 files changed, 506 insertions(+)
>  create mode 100644 drivers/clk/microchip/Kconfig
>  create mode 100644 drivers/clk/microchip/Makefile
>  create mode 100644 drivers/clk/microchip/clk_pfsoc.c
>  create mode 100644 drivers/clk/microchip/clk_pfsoc.h
>  create mode 100644 drivers/clk/microchip/clk_pfsoc_cfg.c
>  create mode 100644 drivers/clk/microchip/clk_pfsoc_periph.c
>  create mode 100644 include/dt-bindings/clock/microchip,pfsoc-clock.h
>
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 4dfbad7986..1161fe7b5a 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -173,6 +173,7 @@ source "drivers/clk/exynos/Kconfig"
>  source "drivers/clk/imx/Kconfig"
>  source "drivers/clk/kendryte/Kconfig"
>  source "drivers/clk/meson/Kconfig"
> +source "drivers/clk/microchip/Kconfig"
>  source "drivers/clk/mvebu/Kconfig"
>  source "drivers/clk/owl/Kconfig"
>  source "drivers/clk/renesas/Kconfig"
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index d1e295ac7c..bd8a6eed88 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -28,6 +28,7 @@ obj-$(CONFIG_CLK_EXYNOS) += exynos/
>  obj-$(CONFIG_$(SPL_TPL_)CLK_INTEL) += intel/
>  obj-$(CONFIG_CLK_HSDK) += clk-hsdk-cgu.o
>  obj-$(CONFIG_CLK_K210) += kendryte/
> +obj-$(CONFIG_CLK_MPFS) += microchip/
>  obj-$(CONFIG_CLK_MPC83XX) += mpc83xx_clk.o
>  obj-$(CONFIG_CLK_OCTEON) += clk_octeon.o
>  obj-$(CONFIG_CLK_OWL) += owl/
> diff --git a/drivers/clk/microchip/Kconfig b/drivers/clk/microchip/Kconfig
> new file mode 100644
> index 00..b70241559d
> --- /dev/null
> +++ b/drivers/clk/microchip/Kconfig
> @@ -0,0 +1,5 @@
> +config CLK_MPFS
> +   bool "Clock support for Microchip PolarFire SoC"
> +   depends on CLK && CLK_CCF
> +   help
> + This enables support clock driver for Microchip PolarFire SoC 
> platform.
> diff --git a/drivers/clk/microchip/Makefile b/drivers/clk/microchip/Makefile
> new file mode 100644
> index 00..c7f5ad21ae
> --- /dev/null
> +++ b/drivers/clk/microchip/Makefile
> @@ -0,0 +1 @@
> +obj-y += clk_pfsoc.o clk_pfsoc_cfg.o clk_pfsoc_periph.o
> diff --git a/drivers/clk/microchip/clk_pfsoc.c 
> b/drivers/clk/microchip/clk_pfsoc.c
> new file mode 100644
> index 00..dd0e9cacb8
> --- /dev/null
> +++ b/drivers/clk/microchip/clk_pfsoc.c
> @@ -0,0 +1,127 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2020 Microchip Technology Inc.
> + * Padmarao Begari 
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "clk_pfsoc.h"
> +
> +/* All methods are delegated to CCF clocks */
> +
> +static ulong pfsoc_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 pfsoc_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 pfsoc_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 pfsoc_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 pfsoc_clk_enable(struct clk *clk)
> +{
> +   return pfsoc_clk_endisable(clk, true);
> +}
> +
> +static int pfsoc_clk_disable(struct clk *clk)
> +{
> +   return pfsoc_clk_endisable(clk, false);
> +}
> +
> +static int pfsoc_clk_probe(struct udevice *dev)
> +{
> +   int ret;
> +   void __iomem *base;
> +   u32 clk_rate;
> +   struct clk *clk;
> +   const char *parent_clk_name;
> +
> 

Re: [PATCH v2 5/7] riscv: dts: Add device tree for Microchip Icicle Kit

2020-10-24 Thread Anup Patel
On Thu, Oct 22, 2020 at 12:53 PM Padmarao Begari
 wrote:
>
> Add device tree for Microchip PolarFire SoC Icicle Kit.
>
> Signed-off-by: Padmarao Begari 
> ---
>  arch/riscv/dts/Makefile  |   1 +
>  arch/riscv/dts/microchip-icicle-kit-a000.dts | 426 +++
>  2 files changed, 427 insertions(+)
>  create mode 100644 arch/riscv/dts/microchip-icicle-kit-a000.dts
>
> diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
> index 3a6f96c67d..48c43bd122 100644
> --- a/arch/riscv/dts/Makefile
> +++ b/arch/riscv/dts/Makefile
> @@ -3,6 +3,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
> +dtb-$(CONFIG_TARGET_MICROCHIP_ICICLE) += microchip-icicle-kit-a000.dtb
>
>  targets += $(dtb-y)
>
> diff --git a/arch/riscv/dts/microchip-icicle-kit-a000.dts 
> b/arch/riscv/dts/microchip-icicle-kit-a000.dts
> new file mode 100644
> index 00..7110d2a78b
> --- /dev/null
> +++ b/arch/riscv/dts/microchip-icicle-kit-a000.dts
> @@ -0,0 +1,426 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/* Copyright (c) 2020 Microchip Technology Inc */
> +
> +/dts-v1/;
> +#include "dt-bindings/clock/microchip,pfsoc-clock.h"
> +
> +/* Clock frequency (in Hz) of the rtcclk */
> +#define RTCCLK_FREQ100
> +
> +/ {
> +   #address-cells = <2>;
> +   #size-cells = <2>;
> +   model = "Microchip PolarFire-SoC";
> +   compatible = "microchip,polarfire-soc";
> +
> +   aliases {
> +   serial0 = 
> +   ethernet0 = 
> +   };
> +
> +   chosen {
> +   stdout-path = "serial0";
> +   };
> +
> +   cpucomplex: cpus {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   timebase-frequency = ;
> +   cpu0: cpu@0 {
> +   clocks = < CLK_CPU>;
> +   compatible = "sifive,e51", "sifive,rocket0", "riscv";
> +   device_type = "cpu";
> +   i-cache-block-size = <64>;
> +   i-cache-sets = <128>;
> +   i-cache-size = <16384>;
> +   reg = <0>;
> +   riscv,isa = "rv64imac";
> +   status = "disabled";
> +   operating-points = <
> +   /* kHz  uV */
> +   60  110
> +   30   95
> +   15   75
> +   >;
> +   cpu0intc: interrupt-controller {
> +   #interrupt-cells = <1>;
> +   compatible = "riscv,cpu-intc";
> +   interrupt-controller;
> +   };
> +   };
> +   cpu1: cpu@1 {
> +   clocks = < CLK_CPU>;
> +   compatible = "sifive,u54-mc", "sifive,rocket0", 
> "riscv";
> +   d-cache-block-size = <64>;
> +   d-cache-sets = <64>;
> +   d-cache-size = <32768>;
> +   d-tlb-sets = <1>;
> +   d-tlb-size = <32>;
> +   device_type = "cpu";
> +   i-cache-block-size = <64>;
> +   i-cache-sets = <64>;
> +   i-cache-size = <32768>;
> +   i-tlb-sets = <1>;
> +   i-tlb-size = <32>;
> +   mmu-type = "riscv,sv39";
> +   reg = <1>;
> +   riscv,isa = "rv64imafdc";
> +   tlb-split;
> +   status = "okay";
> +   operating-points = <
> +   /* kHz  uV */
> +   60  110
> +   30   95
> +   15   75
> +   >;
> +   cpu1intc: interrupt-controller {
> +   #interrupt-cells = <1>;
> +   compatible = "riscv,cpu-intc";
> +   interrupt-controller;
> +   };
> +   };
> +   cpu2: cpu@2 {
> +   clocks = < CLK_CPU>;
> +   compatible = "sifive,u54-mc", "sifive,rocket0", 
> "riscv";
> +   d-cache-block-size = <64>;
> +   d-cache-sets = <64>;
> +   d-cache-size = <32768>;
> +   d-tlb-sets = <1>;
> +   d-tlb-size = <32>;
> +   device_type = "cpu";
> +   i-cache-block-size = <64>;
> +   i-cache-sets = <64>;
> +   i-cache-size = 

Re: [PATCH v2 1/7] riscv: Add DMA 64-bit address support

2020-10-24 Thread Anup Patel
On Thu, Oct 22, 2020 at 1:23 PM Padmarao Begari
 wrote:
>
> dma_addr_t holds any valid DMA address. If the DMA API only uses 32/64-bit
> addresses, dma_addr_t need only be 32/64 bits wide.
>
> Signed-off-by: Padmarao Begari 
> ---
>  arch/riscv/Kconfig | 5 +
>  arch/riscv/include/asm/types.h | 4 
>  2 files changed, 9 insertions(+)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index aaa3b833a5..7ab1ccff40 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -152,6 +152,11 @@ config 32BIT
>  config 64BIT
> bool
>
> +config DMA_ADDR_T_64BIT
> +   bool
> +   depends on 64BIT
> +   default n

This should be "default y if 64BIT".

> +
>  config SIFIVE_CLINT
> bool
> depends on RISCV_MMODE || SPL_RISCV_MMODE
> diff --git a/arch/riscv/include/asm/types.h b/arch/riscv/include/asm/types.h
> index 403cf9a48f..b800b2d221 100644
> --- a/arch/riscv/include/asm/types.h
> +++ b/arch/riscv/include/asm/types.h
> @@ -29,7 +29,11 @@ typedef unsigned short umode_t;
>
>  #include 
>
> +#ifdef CONFIG_DMA_ADDR_T_64BIT
> +typedef u64 dma_addr_t;
> +#else
>  typedef u32 dma_addr_t;
> +#endif
>
>  typedef unsigned long phys_addr_t;
>  typedef unsigned long phys_size_t;
> --
> 2.17.1
>

Apart from above, looks good to me.

Reviewed-by: Anup Patel 

Regards,
Anup


Re: [PATCH 2/2] rockchip: gru: Allow setting up clocks in U-Boot proper

2020-10-24 Thread Alper Nebi Yasak
On 24/10/2020 03:05, Simon Glass wrote:
> Hi Alper,
> 
> On Thu, 22 Oct 2020 at 14:38, Alper Nebi Yasak  
> wrote:
>>
>> Commit fe974716326c ("rockchip: rk3288: Allow setting up clocks in
>> U-Boot proper") fixes some clock issues when chainloading U-Boot on
>> rk3288 chromebooks. Part of that change is still available in veyron's
>> board_early_init_r() function. Since chain-loading U-Boot proper from
>> vendor firmware is possible on gru boards as well, do the same thing for
>> them too.
>>
>> Signed-off-by: Alper Nebi Yasak 
>> ---
>>
>>  board/google/gru/gru.c   | 23 +++
>>  configs/chromebook_bob_defconfig |  1 +
>>  2 files changed, 24 insertions(+)
> 
> Similar comment here.

I can do the same HANDOFF checks here, but to me it looks like this
wouldn't need them if we're already checking things in the probe
function.


Re: [PATCH 1/2] rockchip: rk3399: Re-init clocks in U-Boot proper

2020-10-24 Thread Alper Nebi Yasak
On 24/10/2020 03:05, Simon Glass wrote:
> Hi Alper,
> 
> On Thu, 22 Oct 2020 at 14:37, Alper Nebi Yasak  
> wrote:
>>
>> It's possible to chainload U-Boot proper from the vendor firmware in
>> rk3399 chromebooks, but the way the vendor firmware sets up clocks is
>> somehow different than what U-Boot expects. This causes the display to
>> stay devoid of content even though vidconsole claims to work (with
>> patches in process of being upstreamed).
>>
>> This is meant to be a rk3399 version of commit d3cb46aa8c41 ("rockchip:
>> Init clocks again when chain-loading") which can detect the discrepancy,
>> but this patch can not so it always re-inits.
>>
>> Signed-off-by: Alper Nebi Yasak 
>> ---
>> The rk3288 version has rockchip_vop_set_clk in #ifndef CONFIG_BUILD_SPL,
>> and checks if that setup is already done before that's called. I think I
>> can do the #ifndef to avoid unnecessary re-inits for rk3399 as well, but
>> the vop clocks are set differently for each chip so I don't know how
>> correct that'd be.
>>
>> The pmucru setup is #ifndef CONFIG_BUILD_SPL on rk3399, so I think I can
>> also check for that, but that's technically in a different driver and I
>> don't know how best to do that.
>>
>>  drivers/clk/rockchip/clk_rk3399.c | 7 +--
>>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> Could we make this conditional on SPL not running? We could check that
> by enabling CONFIG_HANDOFF, for example.

Using CONFIG_HANDOFF in the probe function like this works on my side:

static int rk3399_clk_probe(struct udevice *dev)
{
struct rk3399_clk_priv *priv = dev_get_priv(dev);
bool init_clocks = false;

#if CONFIG_IS_ENABLED(OF_PLATDATA)
struct rk3399_clk_plat *plat = dev_get_platdata(dev);

priv->cru = map_sysmem(plat->dtd.reg[0], plat->dtd.reg[1]);
#endif

#if defined(CONFIG_SPL_BUILD)
init_clocks = true;
#elif CONFIG_IS_ENABLED(HANDOFF)
if (!(gd->spl_handoff))
init_clocks = true;
#endif

if (init_clocks)
rkclk_init(priv->cru);

return 0;
}

The clk_rk3288 code also checks for GD_FLG_RELOC, adding that didn't
look like it did anything good/bad for me. Should I add that too? I
mean:

#elif CONFIG_IS_ENABLED(HANDOFF)
if (!(gd->flags & GD_FLG_RELOC)) {
if (!(gd->spl_handoff))
init_clocks = true;
}
#endif

Also, HANDOFF depends on BLOBLIST (maybe it shouldn't?), so I added
these values from chromebook_coral to my config, are they OK?

CONFIG_BLOBLIST=y
CONFIG_BLOBLIST_SIZE=0x3
CONFIG_BLOBLIST_ADDR=0x10


Re: [PATCH 0/8] PinePhone automatic device tree selection

2020-10-24 Thread Peter Robinson
On Mon, Sep 7, 2020 at 1:01 AM André Przywara  wrote:
>
> On 03/09/2020 06:07, Samuel Holland wrote:
>
> Hi Samuel,
>
> > This patch series implements a feature to automatically choose the
> > right PinePhone device tree by probing the hardware. It then extends
> > the functionality to pass the chosen DTB name to the boot command.
> > Finally, I add device trees and a defconfig for the PinePhone.
> >
> > I'm aware that Andre has concerns about updating the device tree files.
> > It would be unfortunate for this to block new hardware support.
>
> I agree that it shouldn't block it.
>
> > Since
> > the device trees are primarily maintained in the Linux repository, and
> > only copied here, I believe compatibility concerns should be directed
> > there, not here.
>
> Sigh. I tried that there, multiple times, and was basically dismissed.
> IIRC the main argument was that we (as the sunxi community) do not have
> the resources to pull off something like compatible DTs. The DTs are
> being created and written as we go, so maintaining forward compatibility
> is not something the Linux maintainers wanted to subscribe to.
> And while I see that's *some* extra effort, I argued that it's worth it,
> even providing solutions. Otherwise I am afraid that we end up in the
> embedded rabbit hole that we see today, where dozens of images are
> traded around, even though there are generic distributions available.
>
> We parted by agreeing on putting those necessary DT changes into U-Boot
> instead. Commit ababb5920e899 is one example of this. I tried to prevent
> further changes, but failed.
>
> > In any case, the first 6 patches can be merged
> > independently, so I request that they be merged even if patches 7-8 are
> > not. I am mainly including the last two patches for ease of testing.
>
> So I have some easy patches that improve DT compatibility, I guess we
> can just apply them later. The most prominent issue is the change of the
> RTC compatible name. This seems to cost us the RTC (bearable?) and, in
> turn, the debouncing feature of the GPIO controller (through the newly
> introduced clock in the RTC).

Can those fixes go into -u-boot.dtsi files, that would then make
syncing with upstream easier while having less chances to regress the
compatibility.

> There seem to be more issues that popped up in testing. I guess we would
> need to define some supported kernels, and test them. The effort for
> this depends on how far back we want to support Linux kernels and with
> what feature set. I ran a headless board fine here with Ubuntu's 18.04
> original kernel, which is 4.15 based. I might concede to give this up,
> if needed, to go back to only 4.19 (Debian), or maybe 4.18 (Ubuntu
> 18.04.2 HWE kernel).

I feel it should be the people that want to run newer U-Boot on those
older releases with older kernels to do the work. In reality what is
the actual demand for those use cases?

> I will have a look at the other patches later. It seems like you jump
> through some hoops to be able to set fdtfile in U-Boot proper later? I
> consider this conceptually dodgy ($fdtcontroladdr should be all you
> need), but don't care enough, as it does not seem to break things.
>
> Cheers,
> Andre
>
> > Samuel Holland (8):
> >   sunxi: board: Use a more descriptive variable name
> >   sunxi: board: Add a helper to get the SPL DT name
> >   sunxi: board: Simplify Pine A64 DT selection logic
> >   sunxi: board: Add PinePhone DT selection logic
> >   sunxi: board: Save the chosen DT name in the SPL header
> >   sunxi: board: Set fdtfile to match the DT chosen by SPL
> >   sunxi: DT: A64: update device tree files
> >   sunxi: a64: Add a defconfig for the PinePhone
> >
> >  arch/arm/dts/Makefile |   4 +
> >  arch/arm/dts/axp803.dtsi  |  82 +--
> >  arch/arm/dts/sun50i-a64-amarula-relic.dts | 109 +++-
> >  arch/arm/dts/sun50i-a64-bananapi-m64.dts  | 118 ++--
> >  arch/arm/dts/sun50i-a64-cpu-opp.dtsi  |  75 +++
> >  arch/arm/dts/sun50i-a64-nanopi-a64.dts|  70 +--
> >  .../dts/sun50i-a64-oceanic-5205-5inmfd.dts|  31 +-
> >  arch/arm/dts/sun50i-a64-olinuxino-emmc.dts|  12 +-
> >  arch/arm/dts/sun50i-a64-olinuxino.dts | 113 ++--
> >  arch/arm/dts/sun50i-a64-orangepi-win.dts  | 127 +++--
> >  arch/arm/dts/sun50i-a64-pine64-lts.dts|   7 +-
> >  arch/arm/dts/sun50i-a64-pine64-plus.dts   |  52 +-
> >  arch/arm/dts/sun50i-a64-pine64.dts|  97 ++--
> >  arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi  |  17 -
> >  arch/arm/dts/sun50i-a64-pinebook.dts  | 237 ++--
> >  arch/arm/dts/sun50i-a64-pinephone-1.0.dts |  11 +
> >  arch/arm/dts/sun50i-a64-pinephone-1.1.dts |  30 +
> >  arch/arm/dts/sun50i-a64-pinephone-1.2.dts |  40 ++
> >  arch/arm/dts/sun50i-a64-pinephone.dtsi| 429 ++
> >  arch/arm/dts/sun50i-a64-pinetab.dts   | 460 +++
> >  arch/arm/dts/sun50i-a64-sopine-baseboard.dts  | 113 

[PATCH] rockchip: mkimage: Remove host endianness dependency

2020-10-24 Thread Samuel Holland
The Rockchip boot ROM expects little-endian values in the image header.
When running mkimage on a big-endian machine, these values need to be
byteswapped before writing or verifying the header.

This change fixes cross-compiling U-Boot SPL for the RK3399 SoC from a
big-endian ppc64 host machine.

Signed-off-by: Samuel Holland 
---
 tools/rkcommon.c | 29 +++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/tools/rkcommon.c b/tools/rkcommon.c
index 61c392e27d5..d55cd2c2d5a 100644
--- a/tools/rkcommon.c
+++ b/tools/rkcommon.c
@@ -221,12 +221,13 @@ bool rkcommon_need_rc4_spl(struct image_tool_params 
*params)
 static void rkcommon_set_header0(void *buf, struct image_tool_params *params)
 {
struct header0_info *hdr = buf;
+   uint32_t init_boot_size;
 
memset(buf, '\0', RK_INIT_OFFSET * RK_BLK_SIZE);
-   hdr->signature = RK_SIGNATURE;
-   hdr->disable_rc4 = !rkcommon_need_rc4_spl(params);
-   hdr->init_offset = RK_INIT_OFFSET;
-   hdr->init_size = spl_params.init_size / RK_BLK_SIZE;
+   hdr->signature   = cpu_to_le32(RK_SIGNATURE);
+   hdr->disable_rc4 = cpu_to_le32(!rkcommon_need_rc4_spl(params));
+   hdr->init_offset = cpu_to_le16(RK_INIT_OFFSET);
+   hdr->init_size   = cpu_to_le16(spl_params.init_size / RK_BLK_SIZE);
 
/*
 * init_boot_size needs to be set, as it is read by the BootROM
@@ -237,11 +238,10 @@ static void rkcommon_set_header0(void *buf, struct 
image_tool_params *params)
 * for a more detailed explanation by Andy Yan
 */
if (spl_params.boot_file)
-   hdr->init_boot_size =
-   hdr->init_size + spl_params.boot_size / RK_BLK_SIZE;
+   init_boot_size = spl_params.init_size + spl_params.boot_size;
else
-   hdr->init_boot_size =
-   hdr->init_size + RK_MAX_BOOT_SIZE / RK_BLK_SIZE;
+   init_boot_size = spl_params.init_size + RK_MAX_BOOT_SIZE;
+   hdr->init_boot_size = cpu_to_le16(init_boot_size / RK_BLK_SIZE);
 
rc4_encode(buf, RK_BLK_SIZE, rc4_key);
 }
@@ -294,14 +294,14 @@ static int rkcommon_parse_header(const void *buf, struct 
header0_info *header0,
memcpy((void *)header0, buf, sizeof(struct header0_info));
rc4_encode((void *)header0, sizeof(struct header0_info), rc4_key);
 
-   if (header0->signature != RK_SIGNATURE)
+   if (le32_to_cpu(header0->signature) != RK_SIGNATURE)
return -EPROTO;
 
/* We don't support RC4 encoded image payloads here, yet... */
-   if (header0->disable_rc4 == 0)
+   if (le32_to_cpu(header0->disable_rc4) == 0)
return -ENOSYS;
 
-   hdr1_offset = header0->init_offset * RK_BLK_SIZE;
+   hdr1_offset = le16_to_cpu(header0->init_offset) * RK_BLK_SIZE;
hdr1_sdmmc = (struct header1_info *)(buf + hdr1_offset);
hdr1_spi = (struct header1_info *)(buf +
   rkcommon_offset_to_spi(hdr1_offset));
@@ -359,7 +359,7 @@ void rkcommon_print_header(const void *buf)
struct header0_info header0;
struct spl_info *spl_info;
uint8_t image_type;
-   int ret, boot_size;
+   int ret, boot_size, init_size;
 
ret = rkcommon_parse_header(buf, , _info);
 
@@ -377,9 +377,10 @@ void rkcommon_print_header(const void *buf)
printf("Image Type:   Rockchip %s (%s) boot image\n",
   spl_info->spl_hdr,
   (image_type == IH_TYPE_RKSD) ? "SD/MMC" : "SPI");
-   printf("Init Data Size: %d bytes\n", header0.init_size * RK_BLK_SIZE);
+   init_size = le16_to_cpu(header0.init_size) * RK_BLK_SIZE;
+   printf("Init Data Size: %d bytes\n", init_size);
 
-   boot_size = (header0.init_boot_size - header0.init_size) * RK_BLK_SIZE;
+   boot_size = le16_to_cpu(header0.init_boot_size) * RK_BLK_SIZE - 
init_size;
if (boot_size != RK_MAX_BOOT_SIZE)
printf("Boot Data Size: %d bytes\n", boot_size);
 }
-- 
2.26.2



[PATCH v2 7/8] sunxi: DT: A64: update device tree files

2020-10-24 Thread Samuel Holland
Import updated device trees from Linux tag v5.9. This picks up new
hardware (PinePhone, PineTab); and it drops the U-Boot specific DTSI
files for the Pinebook and the Teres-I, since the ANX6345 bridge is
now supported upstream.

A couple of headers needed updates for recently-added hardware support.

Acked-by: Maxime Ripard 
Signed-off-by: Samuel Holland 
---
 arch/arm/dts/Makefile |   4 +
 arch/arm/dts/axp803.dtsi  |  82 +--
 arch/arm/dts/sun50i-a64-amarula-relic.dts | 109 +++-
 arch/arm/dts/sun50i-a64-bananapi-m64.dts  | 118 ++--
 arch/arm/dts/sun50i-a64-cpu-opp.dtsi  |  75 +++
 arch/arm/dts/sun50i-a64-nanopi-a64.dts|  70 +--
 .../dts/sun50i-a64-oceanic-5205-5inmfd.dts|  31 +-
 arch/arm/dts/sun50i-a64-olinuxino-emmc.dts|  12 +-
 arch/arm/dts/sun50i-a64-olinuxino.dts | 113 ++--
 arch/arm/dts/sun50i-a64-orangepi-win.dts  | 127 +++--
 arch/arm/dts/sun50i-a64-pine64-lts.dts|   7 +-
 arch/arm/dts/sun50i-a64-pine64-plus.dts   |  52 +-
 arch/arm/dts/sun50i-a64-pine64.dts|  97 ++--
 arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi  |  17 -
 arch/arm/dts/sun50i-a64-pinebook.dts  | 237 ++--
 arch/arm/dts/sun50i-a64-pinephone-1.0.dts |  11 +
 arch/arm/dts/sun50i-a64-pinephone-1.1.dts |  30 +
 arch/arm/dts/sun50i-a64-pinephone-1.2.dts |  40 ++
 arch/arm/dts/sun50i-a64-pinephone.dtsi| 429 ++
 arch/arm/dts/sun50i-a64-pinetab.dts   | 460 +++
 arch/arm/dts/sun50i-a64-sopine-baseboard.dts  | 113 ++--
 arch/arm/dts/sun50i-a64-sopine.dtsi   |  69 +--
 arch/arm/dts/sun50i-a64-teres-i-u-boot.dtsi   |  41 --
 arch/arm/dts/sun50i-a64-teres-i.dts   | 138 -
 arch/arm/dts/sun50i-a64.dtsi  | 532 ++
 include/dt-bindings/clock/sun50i-a64-ccu.h|   4 +-
 include/dt-bindings/clock/sun8i-de2.h |   3 +
 include/dt-bindings/reset/sun8i-de2.h |   1 +
 28 files changed, 2390 insertions(+), 632 deletions(-)
 create mode 100644 arch/arm/dts/sun50i-a64-cpu-opp.dtsi
 delete mode 100644 arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi
 create mode 100644 arch/arm/dts/sun50i-a64-pinephone-1.0.dts
 create mode 100644 arch/arm/dts/sun50i-a64-pinephone-1.1.dts
 create mode 100644 arch/arm/dts/sun50i-a64-pinephone-1.2.dts
 create mode 100644 arch/arm/dts/sun50i-a64-pinephone.dtsi
 create mode 100644 arch/arm/dts/sun50i-a64-pinetab.dts
 delete mode 100644 arch/arm/dts/sun50i-a64-teres-i-u-boot.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b195723f164..d15511c699e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -610,6 +610,10 @@ dtb-$(CONFIG_MACH_SUN50I) += \
sun50i-a64-pine64-plus.dtb \
sun50i-a64-pine64.dtb \
sun50i-a64-pinebook.dtb \
+   sun50i-a64-pinephone-1.0.dtb \
+   sun50i-a64-pinephone-1.1.dtb \
+   sun50i-a64-pinephone-1.2.dtb \
+   sun50i-a64-pinetab.dtb \
sun50i-a64-sopine-baseboard.dtb \
sun50i-a64-teres-i.dtb
 dtb-$(CONFIG_MACH_SUN9I) += \
diff --git a/arch/arm/dts/axp803.dtsi b/arch/arm/dts/axp803.dtsi
index e5eae8bafc4..10e9186a76b 100644
--- a/arch/arm/dts/axp803.dtsi
+++ b/arch/arm/dts/axp803.dtsi
@@ -1,44 +1,5 @@
-/*
- * Copyright 2017 Icenowy Zheng 
- *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- *  a) This file is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This file is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * Or, alternatively,
- *
- *  b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use,
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO 

Re: [PATCH v2 7/7] doc: board: Add Microchip MPFS Icicle Kit doc

2020-10-24 Thread Jagan Teki
On Thu, Oct 22, 2020 at 1:22 PM Padmarao Begari
 wrote:
>
> This doc describes the procedure to build, flash and
> boot Linux using U-boot on Microchip MPFS Icicle Kit.
>
> Signed-off-by: Padmarao Begari 
> ---
>  doc/board/index.rst |   1 +
>  doc/board/microchip/index.rst   |   9 +
>  doc/board/microchip/mpfs_icicle.rst | 605 
>  3 files changed, 615 insertions(+)
>  create mode 100644 doc/board/microchip/index.rst
>  create mode 100644 doc/board/microchip/mpfs_icicle.rst
>
> diff --git a/doc/board/index.rst b/doc/board/index.rst
> index 63935abcd7..e50a78d752 100644
> --- a/doc/board/index.rst
> +++ b/doc/board/index.rst
> @@ -15,6 +15,7 @@ Board-specific doc
> freescale/index
> google/index
> intel/index
> +   microchip/index
> renesas/index
> rockchip/index
> sifive/index
> diff --git a/doc/board/microchip/index.rst b/doc/board/microchip/index.rst
> new file mode 100644
> index 00..b09e6788af
> --- /dev/null
> +++ b/doc/board/microchip/index.rst
> @@ -0,0 +1,9 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +Microchip
> +==
> +
> +.. toctree::
> +   :maxdepth: 2
> +
> +   mpfs_icicle
> diff --git a/doc/board/microchip/mpfs_icicle.rst 
> b/doc/board/microchip/mpfs_icicle.rst
> new file mode 100644
> index 00..a4876b02f7
> --- /dev/null
> +++ b/doc/board/microchip/mpfs_icicle.rst
> @@ -0,0 +1,605 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +Microchip PolarFire SoC Icicle Kit
> +==
> +
> +RISC-V PolarFire SoC
> +-
> +The PolarFire SoC is the 4+1 64-bit RISC-V SoC from Microchip.
> +
> +The Icicle Kit development platform is based on PolarFire SoC and capable
> +of running Linux.
> +
> +Mainline support
> +
> +The support for following drivers are already enabled:
> +
> +1. NS16550 UART Driver.
> +2. Microchip Clock Driver.
> +3. Cadence MACB ethernet driver for networking support.
> +4. Cadence MMC Driver for eMMC/SD support.
> +
> +Booting from eMMC using HSS
> +---
> +
> +Building
> +
> +
> +1. Add the RISC-V toolchain to your PATH.
> +2. Setup ARCH & cross compilation environment variable:
> +
> +.. code-block:: none
> +
> +   export CROSS_COMPILE=
> +
> +3. make microchip_mpfs_icicle_defconfig
> +4. make
> +
> +Flashing
> +
> +
> +The current U-Boot port is supported in S-mode only and loaded from DRAM.
> +
> +A prior stage M-mode firmware/bootloader (e.g HSS with OpenSBI) is required 
> to
> +boot the u-boot.bin in S-mode.
> +
> +Currently, the u-boot.bin is used as a payload of the HSS firmware.
> +
> +You will be creating a payload from `u-boot-dtb.bin`.
> +Copy this file to the toplevel HSS (Hart Software Services) directory.

It might be a strange question, but in order to support standardized
bootflow with SPL

I think the DRAM initialization is part of HSS, can we able to build
move that DRAM init part out of HSS? If so we can have SPL that loads
HSS. This might be a strange question but it would be a final goal in
order to standardize bootflow like other RISC-V targets in Mainline.

Jagan.


Re: [PATCH v10 1/2] spi: ca_sflash: Add CAxxxx SPI Flash Controller

2020-10-24 Thread Jagan Teki
On Fri, Jul 31, 2020 at 1:23 AM Alex Nemirovsky
 wrote:
>
> From: Pengpeng Chen 
>
> Add SPI Flash controller driver for Cortina Access
> CA SoCs
>
> Signed-off-by: Pengpeng Chen 
> Signed-off-by: Alex Nemirovsky 
> CC: Jagan Teki 
> CC: Vignesh R 

Applied to u-boot-spi/master


[PATCH v2 4/8] sunxi: board: Add PinePhone DT selection logic

2020-10-24 Thread Samuel Holland
There are two different publicly-released revisions of the PinePhone
hardware, versions 1.1 and 1.2; and they need different device trees.
Since some GPIO pins were rerouted, we can use that to distinguish
between them.

Acked-by: Maxime Ripard 
Reviewed-by: Andre Przywara 
Signed-off-by: Samuel Holland 
---
 arch/arm/mach-sunxi/Kconfig |  7 +++
 board/sunxi/board.c | 21 +
 2 files changed, 28 insertions(+)

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index be0822bfb7d..8421f3b6854 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -1010,4 +1010,11 @@ config PINE64_DT_SELECTION
  option, the device tree selection code specific to Pine64 which
  utilizes the DRAM size will be enabled.
 
+config PINEPHONE_DT_SELECTION
+   bool "Enable PinePhone device tree selection code"
+   depends on MACH_SUN50I
+   help
+ Enable this option to automatically select the device tree for the
+ correct PinePhone hardware revision during boot.
+
 endif
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index ec1920c3a39..bff5135c1a1 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -920,6 +921,26 @@ int board_fit_config_name_match(const char *name)
best_dt_name = "sun50i-a64-pine64";
}
 #endif
+#ifdef CONFIG_PINEPHONE_DT_SELECTION
+   if (strstr(best_dt_name, "-pinephone")) {
+   /* Differentiate the PinePhone revisions by GPIO inputs. */
+   prcm_apb0_enable(PRCM_APB0_GATE_PIO);
+   sunxi_gpio_set_pull(SUNXI_GPL(6), SUNXI_GPIO_PULL_UP);
+   sunxi_gpio_set_cfgpin(SUNXI_GPL(6), SUNXI_GPIO_INPUT);
+   udelay(100);
+
+   /* PL6 is pulled low by the modem on v1.2. */
+   if (gpio_get_value(SUNXI_GPL(6)) == 0)
+   best_dt_name = "sun50i-a64-pinephone-1.2";
+   else
+   best_dt_name = "sun50i-a64-pinephone-1.1";
+
+   sunxi_gpio_set_cfgpin(SUNXI_GPL(6), SUNXI_GPIO_DISABLE);
+   sunxi_gpio_set_pull(SUNXI_GPL(6), SUNXI_GPIO_PULL_DISABLE);
+   prcm_apb0_disable(PRCM_APB0_GATE_PIO);
+   }
+#endif
+
return strcmp(name, best_dt_name);
 }
 #endif
-- 
2.26.2



[PATCH v2 6/8] sunxi: board: Set fdtfile to match the DT chosen by SPL

2020-10-24 Thread Samuel Holland
Previously, fdtfile was always the value in CONFIG_DEFAULT_DEVICE_TREE.
This meant that, regardless of the DT chosen by SPL (either by changing
the header in the image or by the selection code at runtime), Linux
always used the default DT.

By using the name from the SPL header (which, because of the previous
commit, always matches the DT used by U-Boot proper), Linux also sees
the same board as U-Boot/SPL, even if the boot script later loads a DT
from disk.

Acked-by: Maxime Ripard 
Reviewed-by: Andre Przywara 
Signed-off-by: Samuel Holland 
---
 board/sunxi/board.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 9d0e29788b1..d7ec66ed847 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -870,6 +870,7 @@ static void setup_environment(const void *fdt)
 
 int misc_init_r(void)
 {
+   const char *spl_dt_name;
uint boot;
 
env_set("fel_booted", NULL);
@@ -888,6 +889,16 @@ int misc_init_r(void)
env_set("mmc_bootdev", "1");
}
 
+   /* Set fdtfile to match the FIT configuration chosen in SPL. */
+   spl_dt_name = get_spl_dt_name();
+   if (spl_dt_name) {
+   char *prefix = IS_ENABLED(CONFIG_ARM64) ? "allwinner/" : "";
+   char str[64];
+
+   snprintf(str, sizeof(str), "%s%s.dtb", prefix, spl_dt_name);
+   env_set("fdtfile", str);
+   }
+
setup_environment(gd->fdt_blob);
 
 #ifdef CONFIG_USB_ETHER
-- 
2.26.2



[PATCH v2 2/8] sunxi: board: Add a helper to get the SPL DT name

2020-10-24 Thread Samuel Holland
This moves the validity checking and typecasts all to one place away
from the string comparison logic, and it detangles the compile-time
and runtime control flow.

The new helper will also be used by U-Boot proper in a future commit.

Acked-by: Maxime Ripard 
Reviewed-by: Andre Przywara 
Signed-off-by: Samuel Holland 
---
 board/sunxi/board.c | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index d7dfcc78eab..a8a05ec59c8 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -319,6 +319,17 @@ static struct boot_file_head * get_spl_header(uint8_t 
req_version)
return spl;
 }
 
+static const char *get_spl_dt_name(void)
+{
+   struct boot_file_head *spl = get_spl_header(SPL_DT_HEADER_VERSION);
+
+   /* Check if there is a DT name stored in the SPL header. */
+   if (spl != INVALID_SPL_HEADER && spl->dt_name_offset)
+   return (char *)spl + spl->dt_name_offset;
+
+   return NULL;
+}
+
 int dram_init(void)
 {
struct boot_file_head *spl = get_spl_header(SPL_DRAM_HEADER_VERSION);
@@ -891,20 +902,17 @@ int ft_board_setup(void *blob, struct bd_info *bd)
 #ifdef CONFIG_SPL_LOAD_FIT
 int board_fit_config_name_match(const char *name)
 {
-   struct boot_file_head *spl = get_spl_header(SPL_DT_HEADER_VERSION);
-   const char *best_dt_name = (const char *)spl;
+   const char *best_dt_name = get_spl_dt_name();
 
-   /* Check if there is a DT name stored in the SPL header and use that. */
-   if (spl != INVALID_SPL_HEADER && spl->dt_name_offset) {
-   best_dt_name += spl->dt_name_offset;
-   } else {
 #ifdef CONFIG_DEFAULT_DEVICE_TREE
+   if (best_dt_name == NULL)
best_dt_name = CONFIG_DEFAULT_DEVICE_TREE;
-#else
-   return 0;
 #endif
-   };
 
+   if (best_dt_name == NULL) {
+   /* No DT name was provided, so accept the first config. */
+   return 0;
+   }
 #ifdef CONFIG_PINE64_DT_SELECTION
 /* Differentiate the two Pine64 board DTs by their DRAM size. */
if (strstr(name, "-pine64") && strstr(best_dt_name, "-pine64")) {
-- 
2.26.2



[PATCH v2 0/8] PinePhone automatic device tree selection

2020-10-24 Thread Samuel Holland
This patch series implements a feature to automatically choose the
right PinePhone device tree by probing the hardware. It then extends
the functionality to pass the chosen DTB name to the boot command.
Finally, I add device trees and a defconfig for the PinePhone.

Changes from v1 to v2:
  - Removed unnecessary "else"s in DT selection logic
  - Updated DT tag reference from v5.9-rc3 to v5.9 (no code change)
  - Regenerated defconfig with `make savedefconfig`
  - Added Acked-by and Reviewed-by tags

Samuel Holland (8):
  sunxi: board: Use a more descriptive variable name
  sunxi: board: Add a helper to get the SPL DT name
  sunxi: board: Simplify Pine A64 DT selection logic
  sunxi: board: Add PinePhone DT selection logic
  sunxi: board: Save the chosen DT name in the SPL header
  sunxi: board: Set fdtfile to match the DT chosen by SPL
  sunxi: DT: A64: update device tree files
  sunxi: a64: Add a defconfig for the PinePhone

 arch/arm/dts/Makefile |   4 +
 arch/arm/dts/axp803.dtsi  |  82 +--
 arch/arm/dts/sun50i-a64-amarula-relic.dts | 109 +++-
 arch/arm/dts/sun50i-a64-bananapi-m64.dts  | 118 ++--
 arch/arm/dts/sun50i-a64-cpu-opp.dtsi  |  75 +++
 arch/arm/dts/sun50i-a64-nanopi-a64.dts|  70 +--
 .../dts/sun50i-a64-oceanic-5205-5inmfd.dts|  31 +-
 arch/arm/dts/sun50i-a64-olinuxino-emmc.dts|  12 +-
 arch/arm/dts/sun50i-a64-olinuxino.dts | 113 ++--
 arch/arm/dts/sun50i-a64-orangepi-win.dts  | 127 +++--
 arch/arm/dts/sun50i-a64-pine64-lts.dts|   7 +-
 arch/arm/dts/sun50i-a64-pine64-plus.dts   |  52 +-
 arch/arm/dts/sun50i-a64-pine64.dts|  97 ++--
 arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi  |  17 -
 arch/arm/dts/sun50i-a64-pinebook.dts  | 237 ++--
 arch/arm/dts/sun50i-a64-pinephone-1.0.dts |  11 +
 arch/arm/dts/sun50i-a64-pinephone-1.1.dts |  30 +
 arch/arm/dts/sun50i-a64-pinephone-1.2.dts |  40 ++
 arch/arm/dts/sun50i-a64-pinephone.dtsi| 429 ++
 arch/arm/dts/sun50i-a64-pinetab.dts   | 460 +++
 arch/arm/dts/sun50i-a64-sopine-baseboard.dts  | 113 ++--
 arch/arm/dts/sun50i-a64-sopine.dtsi   |  69 +--
 arch/arm/dts/sun50i-a64-teres-i-u-boot.dtsi   |  41 --
 arch/arm/dts/sun50i-a64-teres-i.dts   | 138 -
 arch/arm/dts/sun50i-a64.dtsi  | 532 ++
 arch/arm/mach-sunxi/Kconfig   |   7 +
 board/sunxi/board.c   |  97 +++-
 configs/pinephone_defconfig   |  12 +
 include/dt-bindings/clock/sun50i-a64-ccu.h|   4 +-
 include/dt-bindings/clock/sun8i-de2.h |   3 +
 include/dt-bindings/reset/sun8i-de2.h |   1 +
 31 files changed, 2488 insertions(+), 650 deletions(-)
 create mode 100644 arch/arm/dts/sun50i-a64-cpu-opp.dtsi
 delete mode 100644 arch/arm/dts/sun50i-a64-pinebook-u-boot.dtsi
 create mode 100644 arch/arm/dts/sun50i-a64-pinephone-1.0.dts
 create mode 100644 arch/arm/dts/sun50i-a64-pinephone-1.1.dts
 create mode 100644 arch/arm/dts/sun50i-a64-pinephone-1.2.dts
 create mode 100644 arch/arm/dts/sun50i-a64-pinephone.dtsi
 create mode 100644 arch/arm/dts/sun50i-a64-pinetab.dts
 delete mode 100644 arch/arm/dts/sun50i-a64-teres-i-u-boot.dtsi
 create mode 100644 configs/pinephone_defconfig

-- 
2.26.2



[PATCH v2 5/8] sunxi: board: Save the chosen DT name in the SPL header

2020-10-24 Thread Samuel Holland
This overwrites the name loaded from the SPL image. It will be different
if there was previously no name provided, or if a more accurate name was
determined by the board variant selection logic. This means that the DT
name in the SPL header now always matches the DT appended to U-Boot.

Acked-by: Maxime Ripard 
Reviewed-by: Andre Przywara 
Signed-off-by: Samuel Holland 
---
 board/sunxi/board.c | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index bff5135c1a1..9d0e29788b1 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -331,6 +331,21 @@ static const char *get_spl_dt_name(void)
return NULL;
 }
 
+static void set_spl_dt_name(const char *name)
+{
+   struct boot_file_head *spl = get_spl_header(SPL_ENV_HEADER_VERSION);
+
+   if (spl == INVALID_SPL_HEADER)
+   return;
+
+   /* Promote the header version for U-Boot proper, if needed. */
+   if (spl->spl_signature[3] < SPL_DT_HEADER_VERSION)
+   spl->spl_signature[3] = SPL_DT_HEADER_VERSION;
+
+   strcpy((char *)>string_pool, name);
+   spl->dt_name_offset = offsetof(struct boot_file_head, string_pool);
+}
+
 int dram_init(void)
 {
struct boot_file_head *spl = get_spl_header(SPL_DRAM_HEADER_VERSION);
@@ -904,6 +919,7 @@ int ft_board_setup(void *blob, struct bd_info *bd)
 int board_fit_config_name_match(const char *name)
 {
const char *best_dt_name = get_spl_dt_name();
+   int ret;
 
 #ifdef CONFIG_DEFAULT_DEVICE_TREE
if (best_dt_name == NULL)
@@ -941,6 +957,15 @@ int board_fit_config_name_match(const char *name)
}
 #endif
 
-   return strcmp(name, best_dt_name);
+   ret = strcmp(name, best_dt_name);
+
+   /*
+* If one of the FIT configurations matches the most accurate DT name,
+* update the SPL header to provide that DT name to U-Boot proper.
+*/
+   if (ret == 0)
+   set_spl_dt_name(best_dt_name);
+
+   return ret;
 }
 #endif
-- 
2.26.2



[PATCH v2 8/8] sunxi: a64: Add a defconfig for the PinePhone

2020-10-24 Thread Samuel Holland
The PinePhone is a smartphone produced by Pine64, with an A64 SoC,
2 or 3 GiB LPDDR3 RAM, 16 or 32 GiB eMMC, 720x1440 MIPI-DSI panel,
and Quectel EG25-G modem.

There are two main board revisions: 1.1 for early adopters, and 1.2
for mass production. Since there is code to detect the board revision
at boot, one config/image can support both boards.

Acked-by: Maxime Ripard 
Signed-off-by: Samuel Holland 
---
 configs/pinephone_defconfig | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 configs/pinephone_defconfig

diff --git a/configs/pinephone_defconfig b/configs/pinephone_defconfig
new file mode 100644
index 000..64ecef59c90
--- /dev/null
+++ b/configs/pinephone_defconfig
@@ -0,0 +1,12 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_SPL=y
+CONFIG_MACH_SUN50I=y
+CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y
+CONFIG_DRAM_CLK=552
+CONFIG_DRAM_ZQ=3881949
+CONFIG_MMC_SUNXI_SLOT_EXTRA=2
+CONFIG_PINEPHONE_DT_SELECTION=y
+CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pinephone-1.2"
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_OF_LIST="sun50i-a64-pinephone-1.1 sun50i-a64-pinephone-1.2"
-- 
2.26.2



[PATCH v2 1/8] sunxi: board: Use a more descriptive variable name

2020-10-24 Thread Samuel Holland
The variable "cmp_str" always leaves me wondering if it is the DT name
of the current board (yes) or DT name in the FIT config entry (no).

In preparation for expanding the functionality here, rename it to
something that obviously means "this is the DT name we are looking for".

Acked-by: Maxime Ripard 
Reviewed-by: Andre Przywara 
Signed-off-by: Samuel Holland 
---
 board/sunxi/board.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index a5cf0b65c7b..d7dfcc78eab 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -892,14 +892,14 @@ int ft_board_setup(void *blob, struct bd_info *bd)
 int board_fit_config_name_match(const char *name)
 {
struct boot_file_head *spl = get_spl_header(SPL_DT_HEADER_VERSION);
-   const char *cmp_str = (const char *)spl;
+   const char *best_dt_name = (const char *)spl;
 
/* Check if there is a DT name stored in the SPL header and use that. */
if (spl != INVALID_SPL_HEADER && spl->dt_name_offset) {
-   cmp_str += spl->dt_name_offset;
+   best_dt_name += spl->dt_name_offset;
} else {
 #ifdef CONFIG_DEFAULT_DEVICE_TREE
-   cmp_str = CONFIG_DEFAULT_DEVICE_TREE;
+   best_dt_name = CONFIG_DEFAULT_DEVICE_TREE;
 #else
return 0;
 #endif
@@ -907,15 +907,15 @@ int board_fit_config_name_match(const char *name)
 
 #ifdef CONFIG_PINE64_DT_SELECTION
 /* Differentiate the two Pine64 board DTs by their DRAM size. */
-   if (strstr(name, "-pine64") && strstr(cmp_str, "-pine64")) {
+   if (strstr(name, "-pine64") && strstr(best_dt_name, "-pine64")) {
if ((gd->ram_size > 512 * 1024 * 1024))
return !strstr(name, "plus");
else
return !!strstr(name, "plus");
} else {
-   return strcmp(name, cmp_str);
+   return strcmp(name, best_dt_name);
}
 #endif
-   return strcmp(name, cmp_str);
+   return strcmp(name, best_dt_name);
 }
 #endif
-- 
2.26.2



[PATCH v2 3/8] sunxi: board: Simplify Pine A64 DT selection logic

2020-10-24 Thread Samuel Holland
Instead of using an entirely separate matching algorithm, simply update
the name of the DT we want to match. Enabling this logic does not depend
on the FIT config name, only on the initial guess of the board name.

Importantly, the initial guess must be "sun50i-a64-pine64-plus", because
otherwise the logic would trigger when "sun50i-a64-pine64-lts" was
written to the SPL header.

Acked-by: Maxime Ripard 
Reviewed-by: Andre Przywara 
Signed-off-by: Samuel Holland 
---
 board/sunxi/board.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index a8a05ec59c8..ec1920c3a39 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -914,14 +914,10 @@ int board_fit_config_name_match(const char *name)
return 0;
}
 #ifdef CONFIG_PINE64_DT_SELECTION
-/* Differentiate the two Pine64 board DTs by their DRAM size. */
-   if (strstr(name, "-pine64") && strstr(best_dt_name, "-pine64")) {
-   if ((gd->ram_size > 512 * 1024 * 1024))
-   return !strstr(name, "plus");
-   else
-   return !!strstr(name, "plus");
-   } else {
-   return strcmp(name, best_dt_name);
+   if (strstr(best_dt_name, "-pine64-plus")) {
+   /* Differentiate the Pine A64 boards by their DRAM size. */
+   if ((gd->ram_size == 512 * 1024 * 1024))
+   best_dt_name = "sun50i-a64-pine64";
}
 #endif
return strcmp(name, best_dt_name);
-- 
2.26.2



Re: [PATCH v10 2/2] board: presidio-asic: Add SPI NOR support

2020-10-24 Thread Jagan Teki
On Fri, Jul 31, 2020 at 1:23 AM Alex Nemirovsky
 wrote:
>
> Add SPI NOR support for Cortina Access
> Presidio Engineering Board
>
> Signed-off-by: Alex Nemirovsky 
> CC: Jagan Teki 
> CC: Vignesh R 
> CC: Tom Rini 
>
> Add err processing while probe sf device
>
> ---
>
> Changes in v10:
> - Change forced driver probe call to error handling check

Look like you sent v10 w/o answering v7. Please check.

Jagan.


Re: [PATCH v4 00/13] riscv: Add SPI support for Kendryte K210

2020-10-24 Thread Jagan Teki
On Sat, Oct 24, 2020 at 12:14 AM Jagan Teki  wrote:
>
> On Sat, Oct 17, 2020 at 4:28 AM Sean Anderson  wrote:
> >
> > This series adds support for SPI on the Kendryte K210. This covers the MMC
> > slot and SPI flash on the Sipeed Maix Bit.
> >
> > This series makes significant changes to the designware SPI driver. I would
> > really appreciate if the maintainers I CC'd could test this series and 
> > ensure
> > that SPI still works on all their devices. I have tried my best not to 
> > affect
> > existing devices, but I'd rather find out if this breaks stuff now rather 
> > than
> > later. In particular, the method of detecting SSI_MAX_XFER_SIZE has changed
> > since the last revision, and will need to be re-tested.
> >
> > This series was previously part of
> > https://patchwork.ozlabs.org/project/uboot/list/?series=161576
> >
> > Changes in v4:
> > - Auto-detect SSI_MAX_XFER_SIZE
> > - Consolidate log messages in dw_spi_xfer. We don't need to print twice in 
> > such
> >   short succession.
> > - Convert most log_xxx messages to dev_xxx. Since ceb70bb870 ("dm: Print 
> > device
> >   name in dev_xxx like Linux"), dev_xxx can be controlled at runtime in the 
> > same
> >   way as log_xxx. The log messages in dw_reader/dw_writer are not converted 
> > to
> >   reduce the amount of instructions in those loops, even with logging 
> > enabled.
> > - Enable booting from MMC
> > - Fix MMC transfer errors
> > - Place env in spi flash
> > - Rearrange headers in designware_spi.c
> > - Remove spi_enable_chip
> > - Update documentation
> >
> > Changes in v3:
> > - Lower the log level of some messages
> > - Prefix user-facing logs with SPI@
> > - Rebase onto U-Boot master
> > - Remove env and bootcmd configuration. I'm going to punt on those for now,
> >   since I haven't worked out the best way to boot with SPI yet. Those
> >   settings may be added back in a follow-up patch.
> > - Reword error messages as "message (error %d)"
> > - Synchronize compatible strings between docs and driver
> > - Use constant 0x1 instead of SZ_64K. The latter is not included on
> >   some platforms and I'm too lazy to figure out what the correct header is.
> >
> > Changes in v2:
> > - Add Gigadevice SPI chips to dependencies
> > - Add external gpio cs support
> > - Clean up exec_op
> > - Configure ctrlr0 register layout based on compatible string
> > - Convert debug calls to log_ instead of removing the ones which affect
> >   timing
> > - Document new compatible strings
> > - Limit data transfers to 64k
> > - Remove broken-wp property (implicit due to no wp gpio)
> > - Remove ctrl0 field offsets from device tree
> > - Switch to new compatible strings
> > - Switch to new pinmux binding style
> >
> > Sean Anderson (13):
> >   spi: dw: Fix driving MOSI low while recieving
> >   spi: dw: Convert calls to debug to dev_*
> >   spi: dw: Rename "cs-gpio" to "cs-gpios"
> >   spi: dw: Use generic function to read reg address
> >   spi: dw: Rename registers to match datasheet
> >   spi: dw: Remove spi_enable_chip
> >   spi: dw: Rearrange struct dw_spi_priv
> >   spi: dw: Add SoC-specific compatible strings
> >   spi: dw: Add support for multiple CTRLR0 layouts
> >   spi: dw: Document devicetree binding
> >   spi: dw: Add mem_ops
> >   riscv: Add device tree bindings for SPI
> >   riscv: Add support for SPI on Kendryte K210
>
> Except for this patch with HUSH PARSER missing rest look fine for me.
>
> Reviewed-by: Jagan Teki 

Applied to u-boot-spi/master


Re: [PATCH 2/2] test: unit tests for print_freq(), print_size()

2020-10-24 Thread Tom Rini
On Thu, Oct 22, 2020 at 09:45:28PM +0200, Heinrich Schuchardt wrote:

> Provide unit tests for functions print_freq() and print_size().
> 
> Signed-off-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2] cmd: fat: Use do_save() for fatwrite

2020-10-24 Thread Tom Rini
On Tue, Oct 20, 2020 at 08:45:46AM +0100, Lad Prabhakar wrote:

> do_save() function defined in fs.c also supports FAT file system
> re-use the same for fatwrite command.
> 
> Also fix the FAT test script to match the expected output.
> 
> Signed-off-by: Lad Prabhakar 
> Reviewed-by: Biju Das 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] bootm: fix wrong conditions about images overlap

2020-10-24 Thread Tom Rini
On Wed, Oct 21, 2020 at 02:17:03PM +0900, Jaehoon Chung wrote:

> It doesn't need to consider start byte address.
> If ramdisk size is 0x80 and start address is 0x270, then it's
> used until 0x02ef, not 0x02f0. But it's detected to overlapt RD
> image, when kernel start address is 0x02f0.
> Because it's doing wrong calculation about rd_len.
> This patch fixed wrong calculation address position when check
> condition.
> 
> In addition, it needs to check one more condition about overlapping
> entire area.
> 
> Fixes: commit fbde7589ce30 ("common: bootm: add checks to verify if ramdisk / 
> fdtimage overlaps OS image")
> 
> Signed-off-by: Jaehoon Chung 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] phy: nop-phy: add clk bulk

2020-10-24 Thread Tom Rini
On Thu, Oct 15, 2020 at 06:05:58PM +0800, Peng Fan wrote:

> Add clk bulk for nop-phy driver.
> 
> Signed-off-by: Peng Fan 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 2/2] cmd: Split out timer command from the sleep command

2020-10-24 Thread Tom Rini
On Tue, Oct 13, 2020 at 06:45:06PM +0800, Bin Meng wrote:

> From: Bin Meng 
> 
> CONFIG_CMD_TIMER merits a single file instead of co-exist in the
> sleep command file.
> 
> Signed-off-by: Bin Meng 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] cmd: Add a 'misc' command to access miscellaneous devices

2020-10-24 Thread Tom Rini
On Wed, Oct 14, 2020 at 02:34:52PM +0800, Bin Meng wrote:

> From: Bin Meng 
> 
> Enable the command "misc" for accessing miscellaneous devices with
> a MISC uclass driver. The command provides listing all MISC devices
> as well as read and write functionalities via their drivers.
> 
> Signed-off-by: Bin Meng 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] Makefile: Fix u-boot-nodtb.bin target

2020-10-24 Thread Tom Rini
On Wed, Oct 07, 2020 at 03:39:40PM +0200, Pali Rohár wrote:

> This change fixes two issues when building u-boot-nodtb.bin target:
> 
> * Remove intermediate binary u-boot-nodtb.bin from disk when static_rela
>   call (which modifies u-boot-nodtb.bin binary) failed. It is required
>   because previous objcopy call creates binary and static_rela finish it.
> 
> * Do not call static_rela cmd when u-boot-nodtb.bin binary was not
>   created/updated by previous objcopy call.
> 
> Second fix would ensure that u-boot-nodtb.bin binary is not updated when
> all prerequisites were up-to-date. And therefore final binary u-boot.bin
> is not updated in case all prerequisites were not modified and were
> up-to-date.
> 
> Now running 'make SOURCE_DATE_EPOCH=0 u-boot.bin' second time now does not
> touch u-boot.bin binary in case nothing was modified, so GNU make can
> correctly detect that everything is up-to-date.
> 
> Signed-off-by: Pali Rohár 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 1/2] cmd: Rename CMD_MISC to CMD_SLEEP

2020-10-24 Thread Tom Rini
On Tue, Oct 13, 2020 at 06:45:05PM +0800, Bin Meng wrote:

> From: Bin Meng 
> 
> The "cmd/Kconfig" has a TODO description for CMD_MISC that it should
> really be named as CMD_SLEEP. Change it in the whole source tree.
> 
> Signed-off-by: Bin Meng 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] i2c: i2c-gpio: Convert to use APIs which support live DT

2020-10-24 Thread Tom Rini
On Thu, Sep 10, 2020 at 06:25:09PM +0200, Patrick Delaunay wrote:

> Use ofnode_ or dev_ APIs instead of fdt_ and fdtdec_ APIs so that the
> driver can support live DT.
> 
> Signed-off-by: Patrick Delaunay 
> Reviewed-by: Heiko Schocher 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/2] power: regulator: gpio-regulator: protect count value

2020-10-24 Thread Tom Rini
On Thu, Sep 10, 2020 at 06:18:16PM +0200, Patrick Delaunay wrote:

> Update the size of states_array to avoid overflow for
> dev_pdata->voltages[j] and dev_pdata->states[j].
> 
> As the size of array is GPIO_REGULATOR_MAX_STATES, the size of
> states_array is limited by GPIO_REGULATOR_MAX_STATES * 2 = 4
> instead of 8 previously.
> 
> The value of the "count" variable is limited by the third parameter of
> fdtdec_get_int_array_count.
> 
> Signed-off-by: Patrick Delaunay 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 1/1] post: remove redundant condition

2020-10-24 Thread Tom Rini
On Mon, Aug 03, 2020 at 10:12:13PM +0200, Heinrich Schuchardt wrote:

> (A && A == 0x20) is only true for (A == 0x20).
> 
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 2/2] power: regulator: gpio-regulator: Convert to use APIs which support live DT

2020-10-24 Thread Tom Rini
On Thu, Sep 10, 2020 at 06:18:17PM +0200, Patrick Delaunay wrote:

> Use ofnode_ or dev_ APIs instead of fdt_ and fdtdec_ APIs so that the
> driver can support live DT.
> 
> Signed-off-by: Patrick Delaunay 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 0/8] PinePhone automatic device tree selection

2020-10-24 Thread Jagan Teki
On Thu, Sep 3, 2020 at 10:37 AM Samuel Holland  wrote:
>
> All,
>
> This patch series implements a feature to automatically choose the
> right PinePhone device tree by probing the hardware. It then extends
> the functionality to pass the chosen DTB name to the boot command.
> Finally, I add device trees and a defconfig for the PinePhone.
>
> I'm aware that Andre has concerns about updating the device tree files.
> It would be unfortunate for this to block new hardware support. Since
> the device trees are primarily maintained in the Linux repository, and
> only copied here, I believe compatibility concerns should be directed
> there, not here. In any case, the first 6 patches can be merged
> independently, so I request that they be merged even if patches 7-8 are
> not. I am mainly including the last two patches for ease of testing.
>
> Samuel Holland (8):
>   sunxi: board: Use a more descriptive variable name
>   sunxi: board: Add a helper to get the SPL DT name
>   sunxi: board: Simplify Pine A64 DT selection logic
>   sunxi: board: Add PinePhone DT selection logic
>   sunxi: board: Save the chosen DT name in the SPL header
>   sunxi: board: Set fdtfile to match the DT chosen by SPL
>   sunxi: DT: A64: update device tree files
>   sunxi: a64: Add a defconfig for the PinePhone

I can see some comments from Andre, please fix and send next version.

Jagan.


Re: [maemo-leste] [PATCH] nokia_rx51: disable obsolete VIDEO config

2020-10-24 Thread Tom Rini
On Sat, Oct 24, 2020 at 12:46:45PM +0200, Merlijn Wajer wrote:
> Hi,
> 
> On 24/10/2020 12:06, Pali Rohár wrote:
> > On Wednesday 21 October 2020 08:47:02 Tom Rini wrote:
> >> On Wed, Oct 21, 2020 at 11:08:37AM +0200, Pali Rohár wrote:
> >>> On Tuesday 20 October 2020 10:17:07 Tom Rini wrote:
>  On Tue, Oct 20, 2020 at 11:30:51AM +0200, Pali Rohár wrote:
> 
> >>> Yes, there is mmc issue, I have found which commit caused it and
> >>> because nobody was able to debug / understand what is happening I have
> >>> sent revert patch, which fixes that issue, until somebody solve issue in
> >>> original patch.
> >>>
> >>> But I do not see any progress on either applying revert patch or fixing
> >>> original patch.
> >>>
> >>> And I do not like to have custom patch in my local branch (and
> >>> periodically rebasing it) as it just another layer of complication.
> >>>
> >>> Could we move somehow in this issue?
> >>
> >> No, it's probably stuck until you can fix the problem or otherwise add a
> >> "quirk" for your platform.  What does Linux do in this case?
> > 
> > Well, I provided all requested information, just I'm lacking any new
> > response from developers / maintainers of particular code.
> > 
> > I have already identified problematic place / commit and I have already
> > sent revert patch which fixing this issue.
> > 
> > Tom, what else do you need?
> > 
> > I see the main issue now that nobody reviewed / merged patch and nobody
> > responded to emails which I have sent more then 2 months ago.
> 
> I would like to add my voice for reverting the patches that break the
> support, and work from that point to improve support and eventually
> migrate to DT.
> 
> Maemo Leste has a lot of Nokia N900 users, and this is blocking us from
> moving to mainline u-boot. Is it possible to get the opinion of the
> original patch authors on this?
> 
> I am set up with a serial module on the Nokia N900, so I can help
> provide specific debug info.

Let me add in the TI folks that might be able to look in to any of this
today.  But the next problem is that the rx51 needs to be converted to
use DM in U-Boot.  It's throwing up a ton of "you need to convert to X
by  or this board may be removed" warnings at
build.  I really really want to see some of this start to be addressed.

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] nokia_rx51: disable obsolete VIDEO config

2020-10-24 Thread Pali Rohár
On Wednesday 21 October 2020 08:47:02 Tom Rini wrote:
> On Wed, Oct 21, 2020 at 11:08:37AM +0200, Pali Rohár wrote:
> > On Tuesday 20 October 2020 10:17:07 Tom Rini wrote:
> > > On Tue, Oct 20, 2020 at 11:30:51AM +0200, Pali Rohár wrote:
> > > > Hello!
> > > > 
> > > > On Sunday 18 October 2020 21:17:43 Tom Rini wrote:
> > > > > On Sun, Oct 18, 2020 at 10:59:36PM +0200, Pali Rohár wrote:
> > > > > > On Sunday 18 October 2020 22:54:41 Anatolij Gustschin wrote:
> > > > > > > If you need video console support, then please convert to 
> > > > > > > DM_VIDEO.
> > > > > > 
> > > > > > Ok, but I'm waiting until other N900 issues are fixed. There are 
> > > > > > pending
> > > > > > patches which needs to be reviewed and merged.
> > > > > 
> > > > > Can you please list which?
> > > > 
> > > > U-Boot is crashing and board is automatically rebooted:
> > > > 
> > > > https://lists.denx.de/pipermail/u-boot/2020-August/422968.html
> > > > 
> > > > Last email in that thread:
> > > > 
> > > > https://lists.denx.de/pipermail/u-boot/2020-September/427704.html
> > > 
> > > So there's the unresolved MMC issue, but you can work-around that it
> > > sounded like?
> > 
> > Yes, there is mmc issue, I have found which commit caused it and
> > because nobody was able to debug / understand what is happening I have
> > sent revert patch, which fixes that issue, until somebody solve issue in
> > original patch.
> > 
> > But I do not see any progress on either applying revert patch or fixing
> > original patch.
> > 
> > And I do not like to have custom patch in my local branch (and
> > periodically rebasing it) as it just another layer of complication.
> > 
> > Could we move somehow in this issue?
> 
> No, it's probably stuck until you can fix the problem or otherwise add a
> "quirk" for your platform.  What does Linux do in this case?

Well, I provided all requested information, just I'm lacking any new
response from developers / maintainers of particular code.

I have already identified problematic place / commit and I have already
sent revert patch which fixing this issue.

Tom, what else do you need?

I see the main issue now that nobody reviewed / merged patch and nobody
responded to emails which I have sent more then 2 months ago.