Re: [U-Boot] [PATCH v4 2/5] omap: mmc: Avoid using libfdt with of-platdata

[Peter Howard]

On Thu, 2019-11-07 at 15:05 -0500, Tom Rini wrote:
> On Thu, Nov 07, 2019 at 08:53:09AM -0700, Simon Glass wrote:
> 
> > At present this driver is enabled in SPL on omapl138_lcdk, which
> > uses
> > of-platdata. The driver needs to be ported to use of-platdata
> > properly.
> > For now, avoid a build error by returning an error.
> > 
> > Signed-off-by: Simon Glass 
> > 
> > ---
> > 
> > Changes in v4:
> > - Add new patch for omap MMC build errors
> > 
> > Changes in v3: None
> > 
> >  drivers/mmc/davinci_mmc.c | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/drivers/mmc/davinci_mmc.c b/drivers/mmc/davinci_mmc.c
> > index 0d63279db0..79a7f50d25 100644
> > --- a/drivers/mmc/davinci_mmc.c
> > +++ b/drivers/mmc/davinci_mmc.c
> > @@ -507,6 +507,12 @@ static int davinci_mmc_probe(struct udevice
> > *dev)
> > priv->version = data->version;
> > }
> >  
> > +   /* FIXME: Cannot read from device tree with of-platdata */
> > +   if (CONFIG_IS_ENABLED(OF_PLATDATA)) {
> > +   printf("Please fix this driver to use of-platdata");
> > +   return -ENOSYS;
> > +   }
> > +
> > priv->reg_base = (struct davinci_mmc_regs *)dev_read_addr(dev);
> > priv->input_clk = clk_get(DAVINCI_MMCSD_CLKID);
> 
> Let me add the board maintainer here.

Re-replying (and not from %&$! Outlook)  after having a look at the
situation.

>   Peter, are we even using MMC in SPL on the omapl138_lcdk?  

The OMAP L138 LCDK can boot from MMC - so the MMC driver is used inthe
SPL. However, going back over the patches from this year, MMC usage was
broken back in July - refer https://patchwork.ozlabs.org/patch/1138200/
 
Bartosz is working on this but has hit problems.

Given that MMC access in the SPL is effectively broken right now, I
don't see that _this_ patch makes things any worse, so if this is the
only problem with the series I'd let it go through.  Bartosz, Adam:
Given you were discussing this at almost the same time Tom sent his
email, do you have any problem with this patch being applied.  If we
solve the overall problem with the davinci driver, adding the platdata
is trivial.

Peter

> If so, I believe we need to add platdata ala
> other platforms like board/ti/am335x/board.c for example.  Thanks!
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot


signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/1] sunxi: psci: avoid error address-of-packed-member

[Heinrich Schuchardt]

Compiling with GCC 9.2.1 leads to build errors:

arch/arm/cpu/armv7/sunxi/psci.c: In function ‘sunxi_cpu_set_power’:
arch/arm/cpu/armv7/sunxi/psci.c:144:21: error: taking address of packed
member of ‘struct sunxi_cpucfg_reg’ may result in an unaligned pointer
value [-Werror=address-of-packed-member]
  144 |  sunxi_power_switch(>cpu1_pwr_clamp, >cpu1_pwroff,
  | ^~~
arch/arm/cpu/armv7/sunxi/psci.c:144:46: error: taking address of packed
member of ‘struct sunxi_cpucfg_reg’ may result in an unaligned pointer
value [-Werror=address-of-packed-member]
  144 |  sunxi_power_switch(>cpu1_pwr_clamp, >cpu1_pwroff,
  |  ^~~~

Use memcpy() and void* pointers to resolve the problem caused by packing
the struct sunxi_cpucfg_reg.

Signed-off-by: Heinrich Schuchardt 
---
 arch/arm/cpu/armv7/sunxi/psci.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/arch/arm/cpu/armv7/sunxi/psci.c b/arch/arm/cpu/armv7/sunxi/psci.c
index 2c5d99e9ac..5b689004e8 100644
--- a/arch/arm/cpu/armv7/sunxi/psci.c
+++ b/arch/arm/cpu/armv7/sunxi/psci.c
@@ -75,7 +75,7 @@ static void __secure __mdelay(u32 ms)
isb();
 }

-static void __secure clamp_release(u32 __maybe_unused *clamp)
+static void __secure clamp_release(void __maybe_unused *clamp)
 {
 #if defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN7I) || \
defined(CONFIG_MACH_SUN8I_H3) || \
@@ -90,7 +90,7 @@ static void __secure clamp_release(u32 __maybe_unused *clamp)
 #endif
 }

-static void __secure clamp_set(u32 __maybe_unused *clamp)
+static void __secure clamp_set(void __maybe_unused *clamp)
 {
 #if defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN7I) || \
defined(CONFIG_MACH_SUN8I_H3) || \
@@ -99,22 +99,28 @@ static void __secure clamp_set(u32 __maybe_unused *clamp)
 #endif
 }

-static void __secure sunxi_power_switch(u32 *clamp, u32 *pwroff, bool on,
+static void __secure sunxi_power_switch(void *clamp, void *pwroff_ptr, bool on,
int cpu)
 {
+   u32 pwroff;
+
+   memcpy(, pwroff_ptr, sizeof(u32));
+
if (on) {
/* Release power clamp */
clamp_release(clamp);

/* Clear power gating */
-   clrbits_le32(pwroff, BIT(cpu));
+   clrbits_le32(, BIT(cpu));
} else {
/* Set power gating */
-   setbits_le32(pwroff, BIT(cpu));
+   setbits_le32(, BIT(cpu));

/* Activate power clamp */
clamp_set(clamp);
}
+
+   memcpy(pwroff_ptr, , sizeof(u32));
 }

 #ifdef CONFIG_MACH_SUN8I_R40
--
2.24.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [BUG] U-Boot hangs on fatload, commit ee88eacbdd840199a3dec707234579fb15ddd46a

[Gray Remlin]

On Sat, 9 Nov 2019 at 20:50, Heinrich Schuchardt  wrote:

> On 11/9/19 8:42 PM, Gray Remlin wrote:
> > On Sat, 9 Nov 2019 at 18:40, Heinrich Schuchardt  > > wrote:
> >
> > On 11/9/19 6:08 PM, Heinrich Schuchardt wrote:
> >  > On 11/9/19 4:11 PM, Gray Remlin wrote:
> >  >> On Fri, 8 Nov 2019 at 20:08, Heinrich Schuchardt
> > mailto:xypron.g...@gmx.de>
> >  >> >> wrote:
> >  >>
> >  >> On 11/8/19 7:32 PM, Gray Remlin wrote:
> >  >>  > Please excuse the noise. I would like to file a bug report
> >  >> against the
> >  >>  > above commit, a quick search of www.denx.de
> >  
> >  >>  did not
> >  >>  > reveal how I should proceed. Please point me in the right
> >  >> direction.
> >  >>  >
> >  >>  >
> >  >>  > Issue:
> >  >>  > U-Boot hangs (i.e. during boot) whenever the command
> > 'fatload' is
> >  >> used.
> >  >>  >
> >  >>  > Details:
> >  >>  > U-Boot 2019.10 compiled with either dreamplug_defconfig or
> >  >>  > guruplug_defconfig.
> >  >>  >
> >  >>  > After the commit do_load() now additionally calls
> >  >> efi_set_bootdev()
> >  >>  > which was moved out of do_load_wrapper() which is only
> called
> >  >> by the
> >  >>  > 'load' command.
> >  >>  >
> >  >>  > Reverting the commit fixes this issue for me.
> >  >>  >
> >  >>
> >  >> Dear Gray,
> >  >>
> >  >> thanks for reporting the issue with commit
> >  >> fs: do_load: pass device path for efi payload
> >  >> ee88eacbdd840199a3dec707234579fb15ddd46a
> >  >>
> >  >> Is it only the fatload command that fails on your device or
> > also the
> >  >> load command?
> >  >>
> >  >> There is no bug tracker for U-Boot. So sending a mail to the
> > U-Boot
> >  >> mailing list, the patch author, and the maintainer is the
> > best way to
> >  >> inform the developers about bugs.
> >  >>
> >  >> Best regards
> >  >>
> >  >> Heinrich
> >  >>
> >  >>
> >  >> Additional information:
> >  >> cross-compiler gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabi
> >  >>
> >  >> The U-Boot environment being used is the default obtained by
> >  >> compiling U-Boot 2020.01-rc1-00100-gee93ef0c4b as
> > dreamplug_defconfig
> >  >>
> >  >> => printenv
> >  >> baudrate=115200
> >  >> bootcmd=setenv ethact egiga0; ${x_bootcmd_ethernet}; setenv
> ethact
> >  >> egiga1; ${x_bootcmd_ethernet}; ${x_bootcmd_usb};
> > ${x_bootcmd_kernel};
> >  >> setenv bootargs ${x_bootargs} ${x_bootargs_root}; bootm
> 0x640;
> >  >> bootdelay=3
> >  >> ethact=egiga0
> >  >> fdtcontroladdr=1fb8e7c8
> >  >> stderr=serial
> >  >> stdin=serial
> >  >> stdout=serial
> >  >> x_bootargs=console=ttyS0,115200
> >  >> x_bootargs_root=root=/dev/sda2 rootdelay=10
> >  >> x_bootcmd_ethernet=ping 192.168.2.1
> >  >> x_bootcmd_kernel=fatload usb 0 0x640 uImage
> >  >> x_bootcmd_usb=usb start
> >  >>
> >  >> U-Boot hangs for other syntactically correct invocations of
> either
> >  >> 'fatload' or 'load'
> >  >> Other commands such as 'fatls' function as expected.
> >  >>
> >  >> Program flow is as follows:
> >  >>
> >  >> command 'fatload' (or 'load')
> >  >>  efi_set_bootdev()
> >  >>  ...
> >  >>  efi_dp_split_file_path()
> >  >>  ...
> >  >>  efi_dp_dup()
> >  >>  
> >  >>  efi_dp_size()
> >  >>  *while exit condition never met*
> >  >>  *infinite loop*
> >  >>
> >  >>
> >  >> This is not an attempted EFI boot, why is EFI code being invoked
> ?
> >  >
> >  > Thanks for debugging.
> >  >
> >  > When booting from EFI we need to know from which device the EFI
> > binary
> >  > was loaded. We use this information to install the loaded image
> >  > protocol. At the time of the load command we do no know if you
> will
> >  > invoke bootz or bootefi.
> >
> >
> > Isn't that the purpose of the 'load' command ?
> >
> >  >
> >  > It might be that we have a problem with creating device paths for
> > USB. I
> >  > will try to reproduce this.
> >  >
> >  > You could add
> >  >
> >  > printf("efi_dp_split_file_path(%pD)\n", full_path);
> >  >
> >  > at the beginning of efi_dp_split_file_path() to identify what
> device
> >  > path is passed to the function. This 

Re: [U-Boot] [PATCH] rockchip: Fix spl boot order path of booting device

[Mark Kettenis]

> From: Michael Trimarchi 
> Date: Sat,  9 Nov 2019 13:26:25 +0100
> 
> Fix rk3288, rk3188, rk322x, rk3368
> 
> Tested on rk3288
> 
> U-Boot SPL 2019.10-rc4-00014-g0493073dc4-dirty (Nov 09 2019 - 13:04:06 +0100)
> board_spl_was_booted_from: brom_bootdevice_id 2 maps to 'dwmmc@ff0f'
> board_boot_order: could not find dwmmc@ff0f in FDT
> 
> Signed-off-by: Michael Trimarchi 
> ---
>  arch/arm/mach-rockchip/rk3188/rk3188.c | 4 ++--
>  arch/arm/mach-rockchip/rk322x/rk322x.c | 4 ++--
>  arch/arm/mach-rockchip/rk3288/rk3288.c | 4 ++--
>  arch/arm/mach-rockchip/rk3368/rk3368.c | 4 ++--
>  4 files changed, 8 insertions(+), 8 deletions(-)

Reviewed-by: Mark Kettenis 

> diff --git a/arch/arm/mach-rockchip/rk3188/rk3188.c 
> b/arch/arm/mach-rockchip/rk3188/rk3188.c
> index 95f0e3ccbe..1b012f7f67 100644
> --- a/arch/arm/mach-rockchip/rk3188/rk3188.c
> +++ b/arch/arm/mach-rockchip/rk3188/rk3188.c
> @@ -14,8 +14,8 @@
>  #define GRF_BASE 0x20008000
>  
>  const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
> - [BROM_BOOTSOURCE_EMMC] = "dwmmc@1021c000",
> - [BROM_BOOTSOURCE_SD] = "dwmmc@10214000",
> + [BROM_BOOTSOURCE_EMMC] = "/dwmmc@1021c000",
> + [BROM_BOOTSOURCE_SD] = "/dwmmc@10214000",
>  };
>  
>  #ifdef CONFIG_DEBUG_UART_BOARD_INIT
> diff --git a/arch/arm/mach-rockchip/rk322x/rk322x.c 
> b/arch/arm/mach-rockchip/rk322x/rk322x.c
> index cd0bf8a70c..562117e6c1 100644
> --- a/arch/arm/mach-rockchip/rk322x/rk322x.c
> +++ b/arch/arm/mach-rockchip/rk322x/rk322x.c
> @@ -8,8 +8,8 @@
>  #include 
>  
>  const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
> - [BROM_BOOTSOURCE_EMMC] = "dwmmc@3002",
> - [BROM_BOOTSOURCE_SD] = "dwmmc@3000",
> + [BROM_BOOTSOURCE_EMMC] = "/dwmmc@3002",
> + [BROM_BOOTSOURCE_SD] = "/dwmmc@3000",
>  };
>  
>  #ifdef CONFIG_DEBUG_UART_BOARD_INIT
> diff --git a/arch/arm/mach-rockchip/rk3288/rk3288.c 
> b/arch/arm/mach-rockchip/rk3288/rk3288.c
> index 057ce92080..987b4e0d58 100644
> --- a/arch/arm/mach-rockchip/rk3288/rk3288.c
> +++ b/arch/arm/mach-rockchip/rk3288/rk3288.c
> @@ -22,8 +22,8 @@ DECLARE_GLOBAL_DATA_PTR;
>  #define GRF_BASE 0xff77
>  
>  const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
> - [BROM_BOOTSOURCE_EMMC] = "dwmmc@ff0f",
> - [BROM_BOOTSOURCE_SD] = "dwmmc@ff0c",
> + [BROM_BOOTSOURCE_EMMC] = "/dwmmc@ff0f",
> + [BROM_BOOTSOURCE_SD] = "/dwmmc@ff0c",
>  };
>  
>  #ifdef CONFIG_SPL_BUILD
> diff --git a/arch/arm/mach-rockchip/rk3368/rk3368.c 
> b/arch/arm/mach-rockchip/rk3368/rk3368.c
> index 7ccd417a18..20ae797794 100644
> --- a/arch/arm/mach-rockchip/rk3368/rk3368.c
> +++ b/arch/arm/mach-rockchip/rk3368/rk3368.c
> @@ -54,8 +54,8 @@ static struct mm_region rk3368_mem_map[] = {
>  struct mm_region *mem_map = rk3368_mem_map;
>  
>  const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
> - [BROM_BOOTSOURCE_EMMC] = "dwmmc@ff0f",
> - [BROM_BOOTSOURCE_SD] = "dwmmc@ff0c",
> + [BROM_BOOTSOURCE_EMMC] = "/dwmmc@ff0f",
> + [BROM_BOOTSOURCE_SD] = "/dwmmc@ff0c",
>  };
>  
>  #ifdef CONFIG_ARCH_EARLY_INIT_R
> -- 
> 2.17.1
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [BUG] U-Boot hangs on fatload, commit ee88eacbdd840199a3dec707234579fb15ddd46a

[Heinrich Schuchardt]

On 11/9/19 8:42 PM, Gray Remlin wrote:

On Sat, 9 Nov 2019 at 18:40, Heinrich Schuchardt mailto:xypron.g...@gmx.de>> wrote:

On 11/9/19 6:08 PM, Heinrich Schuchardt wrote:
 > On 11/9/19 4:11 PM, Gray Remlin wrote:
 >> On Fri, 8 Nov 2019 at 20:08, Heinrich Schuchardt
mailto:xypron.g...@gmx.de>
 >> >> wrote:
 >>
 >>     On 11/8/19 7:32 PM, Gray Remlin wrote:
 >>  > Please excuse the noise. I would like to file a bug report
 >>     against the
 >>  > above commit, a quick search of www.denx.de
 
 >>      did not
 >>  > reveal how I should proceed. Please point me in the right
 >> direction.
 >>  >
 >>  >
 >>  > Issue:
 >>  > U-Boot hangs (i.e. during boot) whenever the command
'fatload' is
 >>     used.
 >>  >
 >>  > Details:
 >>  > U-Boot 2019.10 compiled with either dreamplug_defconfig or
 >>  > guruplug_defconfig.
 >>  >
 >>  > After the commit do_load() now additionally calls
 >> efi_set_bootdev()
 >>  > which was moved out of do_load_wrapper() which is only called
 >> by the
 >>  > 'load' command.
 >>  >
 >>  > Reverting the commit fixes this issue for me.
 >>  >
 >>
 >>     Dear Gray,
 >>
 >>     thanks for reporting the issue with commit
 >>     fs: do_load: pass device path for efi payload
 >>     ee88eacbdd840199a3dec707234579fb15ddd46a
 >>
 >>     Is it only the fatload command that fails on your device or
also the
 >>     load command?
 >>
 >>     There is no bug tracker for U-Boot. So sending a mail to the
U-Boot
 >>     mailing list, the patch author, and the maintainer is the
best way to
 >>     inform the developers about bugs.
 >>
 >>     Best regards
 >>
 >>     Heinrich
 >>
 >>
 >> Additional information:
 >> cross-compiler gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabi
 >>
 >> The U-Boot environment being used is the default obtained by
 >> compiling U-Boot 2020.01-rc1-00100-gee93ef0c4b as
dreamplug_defconfig
 >>
 >> => printenv
 >> baudrate=115200
 >> bootcmd=setenv ethact egiga0; ${x_bootcmd_ethernet}; setenv ethact
 >> egiga1; ${x_bootcmd_ethernet}; ${x_bootcmd_usb};
${x_bootcmd_kernel};
 >> setenv bootargs ${x_bootargs} ${x_bootargs_root}; bootm 0x640;
 >> bootdelay=3
 >> ethact=egiga0
 >> fdtcontroladdr=1fb8e7c8
 >> stderr=serial
 >> stdin=serial
 >> stdout=serial
 >> x_bootargs=console=ttyS0,115200
 >> x_bootargs_root=root=/dev/sda2 rootdelay=10
 >> x_bootcmd_ethernet=ping 192.168.2.1
 >> x_bootcmd_kernel=fatload usb 0 0x640 uImage
 >> x_bootcmd_usb=usb start
 >>
 >> U-Boot hangs for other syntactically correct invocations of either
 >> 'fatload' or 'load'
 >> Other commands such as 'fatls' function as expected.
 >>
 >> Program flow is as follows:
 >>
 >> command 'fatload' (or 'load')
 >>          efi_set_bootdev()
 >>                  ...
 >>                  efi_dp_split_file_path()
 >>                          ...
 >>                          efi_dp_dup()
 >>                                  
 >>                                  efi_dp_size()
 >>                                  *while exit condition never met*
 >>                                          *infinite loop*
 >>
 >>
 >> This is not an attempted EFI boot, why is EFI code being invoked ?
 >
 > Thanks for debugging.
 >
 > When booting from EFI we need to know from which device the EFI
binary
 > was loaded. We use this information to install the loaded image
 > protocol. At the time of the load command we do no know if you will
 > invoke bootz or bootefi.


Isn't that the purpose of the 'load' command ?

 >
 > It might be that we have a problem with creating device paths for
USB. I
 > will try to reproduce this.
 >
 > You could add
 >
 > printf("efi_dp_split_file_path(%pD)\n", full_path);
 >
 > at the beginning of efi_dp_split_file_path() to identify what device
 > path is passed to the function. This should produce an output like
 >
 > => load scsi 0:2 $kernel_addr_r description.txt
 >

efi_dp_split_file_path(/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(0,0)/HD(2,MBR,0x6fe3a999,0x400,0x400)/description.txt)
 >
 >
 > Best regards
 >
 > Heinrich

I just tested on an OrangePi PC with v2019.10 and got this:

=> fatload usb 0:1 $kernel_addr_r test.txt

[U-Boot] [PATCH 3/3] rockchip: dts: rk3399-firefly: move u-boot, spl-boot-order to to the u-boot.dtsi

[Peter Robinson]

The u-boot specific device tree directives should be in u-boot.dtsi

Signed-off-by: Peter Robinson 
---
 arch/arm/dts/rk3399-firefly-u-boot.dtsi | 6 ++
 arch/arm/dts/rk3399-firefly.dts | 1 -
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/rk3399-firefly-u-boot.dtsi 
b/arch/arm/dts/rk3399-firefly-u-boot.dtsi
index 67b63a8352..38e0897db9 100644
--- a/arch/arm/dts/rk3399-firefly-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-firefly-u-boot.dtsi
@@ -5,3 +5,9 @@
 
 #include "rk3399-u-boot.dtsi"
 #include "rk3399-sdram-ddr3-1600.dtsi"
+
+/ {
+   chosen {
+   u-boot,spl-boot-order = "same-as-spl", , 
+   };
+};
diff --git a/arch/arm/dts/rk3399-firefly.dts b/arch/arm/dts/rk3399-firefly.dts
index a4cb64f8bd..89c67fd24c 100644
--- a/arch/arm/dts/rk3399-firefly.dts
+++ b/arch/arm/dts/rk3399-firefly.dts
@@ -14,7 +14,6 @@
 
chosen {
stdout-path = 
-   u-boot,spl-boot-order = "same-as-spl", , 
};
 
backlight: backlight {
-- 
2.23.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/3] rockchip: dts: rk3399-evb: move u-boot, spl-boot-order to to the u-boot.dtsi

[Peter Robinson]

The u-boot specific device tree directives should be in u-boot.dtsi

Signed-off-by: Peter Robinson 
---
 arch/arm/dts/rk3399-evb-u-boot.dtsi | 6 ++
 arch/arm/dts/rk3399-evb.dts | 2 --
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/rk3399-evb-u-boot.dtsi 
b/arch/arm/dts/rk3399-evb-u-boot.dtsi
index 20910e744b..ccb33d34d1 100644
--- a/arch/arm/dts/rk3399-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-evb-u-boot.dtsi
@@ -5,3 +5,9 @@
 
 #include "rk3399-u-boot.dtsi"
 #include "rk3399-sdram-lpddr3-4GB-1600.dtsi"
+
+/ {
+   chosen {
+   u-boot,spl-boot-order = , 
+   };
+};
diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
index a506e8da37..8e887f3a17 100644
--- a/arch/arm/dts/rk3399-evb.dts
+++ b/arch/arm/dts/rk3399-evb.dts
@@ -15,8 +15,6 @@
 
chosen {
stdout-path = 
-   u-boot,spl-boot-order = \
-   , 
};
 
vdd_center: vdd-center {
-- 
2.23.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/3] rockchip: dts: rk3399: move the u-boot, dm-pre-reloc to the u-boot.dtsi

[Peter Robinson]

The u-boot specific pieces in the dts files should be in u-boot.dtsi
not the main files, this allows easier sync with upstream. The
rk3399.dtsi has a mix of both so move them all for consistency.

Signed-off-by: Peter Robinson 
---
 arch/arm/dts/rk3399-u-boot.dtsi | 44 +
 arch/arm/dts/rk3399.dtsi| 11 -
 2 files changed, 44 insertions(+), 11 deletions(-)

diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
index 2738a3889e..3ec66c6fc3 100644
--- a/arch/arm/dts/rk3399-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -3,10 +3,46 @@
  * Copyright (C) 2019 Jagan Teki 
  */
 
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
  {
u-boot,dm-pre-reloc;
 };
 
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
  {
u-boot,dm-pre-reloc;
 };
@@ -22,3 +58,11 @@
  {
u-boot,dm-pre-reloc;
 };
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
index b73442ee34..3f773b10f4 100644
--- a/arch/arm/dts/rk3399.dtsi
+++ b/arch/arm/dts/rk3399.dtsi
@@ -275,7 +275,6 @@
};
 
sdhci: sdhci@fe33 {
-   u-boot,dm-pre-reloc;
compatible = "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1";
reg = <0x0 0xfe33 0x0 0x1>;
interrupts = ;
@@ -1072,7 +1071,6 @@
};
 
pmugrf: syscon@ff32 {
-   u-boot,dm-pre-reloc;
compatible = "rockchip,rk3399-pmugrf", "syscon", "simple-mfd";
reg = <0x0 0xff32 0x0 0x1000>;
 
@@ -1083,7 +1081,6 @@
};
 
pmusgrf: syscon@ff33 {
-   u-boot,dm-pre-reloc;
compatible = "rockchip,rk3399-pmusgrf", "syscon";
reg = <0x0 0xff33 0x0 0xe3d4>;
};
@@ -1204,7 +1201,6 @@
};
 
cic: syscon@ff62 {
-   u-boot,dm-pre-reloc;
compatible = "rockchip,rk3399-cic", "syscon";
reg = <0x0 0xff62 0x0 0x100>;
};
@@ -1219,7 +1215,6 @@
};
 
dmc: dmc {
-   u-boot,dm-pre-reloc;
compatible = "rockchip,rk3399-dmc";
devfreq-events = <>;
interrupts = ;
@@ -1268,7 +1263,6 @@
};
 
pmucru: pmu-clock-controller@ff75 {
-   u-boot,dm-pre-reloc;
compatible = "rockchip,rk3399-pmucru";
reg = <0x0 0xff75 0x0 0x1000>;
rockchip,grf = <>;
@@ -1279,7 +1273,6 @@
};
 
cru: clock-controller@ff76 {
-   u-boot,dm-pre-reloc;
compatible = "rockchip,rk3399-cru";
reg = <0x0 0xff76 0x0 0x1000>;
rockchip,grf = <>;
@@ -1310,7 +1303,6 @@
};
 
grf: syscon@ff77 {
-   u-boot,dm-pre-reloc;
compatible = "rockchip,rk3399-grf", "syscon", "simple-mfd";
reg = <0x0 0xff77 0x0 0x1>;
#address-cells = <1>;
@@ -1520,7 +1512,6 @@
};
 
vopl: vop@ff8f {
-   u-boot,dm-pre-reloc;
compatible = "rockchip,rk3399-vop-lit";
reg = <0x0 0xff8f 0x0 0x3efc>;
interrupts = ;
@@ -1578,7 +1569,6 @@
};
 
vopb: vop@ff90 {
-   u-boot,dm-pre-reloc;
compatible = "rockchip,rk3399-vop-big";
reg = <0x0 0xff90 0x0 0x3efc>;
interrupts = ;
@@ -1818,7 +1808,6 @@
};
 
pinctrl: pinctrl {
-   u-boot,dm-pre-reloc;
compatible = "rockchip,rk3399-pinctrl";
rockchip,grf = <>;
rockchip,pmu = <>;
-- 
2.23.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [BUG] U-Boot hangs on fatload, commit ee88eacbdd840199a3dec707234579fb15ddd46a

[Gray Remlin]

On Sat, 9 Nov 2019 at 18:40, Heinrich Schuchardt  wrote:

> On 11/9/19 6:08 PM, Heinrich Schuchardt wrote:
> > On 11/9/19 4:11 PM, Gray Remlin wrote:
> >> On Fri, 8 Nov 2019 at 20:08, Heinrich Schuchardt  >> > wrote:
> >>
> >> On 11/8/19 7:32 PM, Gray Remlin wrote:
> >>  > Please excuse the noise. I would like to file a bug report
> >> against the
> >>  > above commit, a quick search of www.denx.de 
> >>  did not
> >>  > reveal how I should proceed. Please point me in the right
> >> direction.
> >>  >
> >>  >
> >>  > Issue:
> >>  > U-Boot hangs (i.e. during boot) whenever the command 'fatload' is
> >> used.
> >>  >
> >>  > Details:
> >>  > U-Boot 2019.10 compiled with either dreamplug_defconfig or
> >>  > guruplug_defconfig.
> >>  >
> >>  > After the commit do_load() now additionally calls
> >> efi_set_bootdev()
> >>  > which was moved out of do_load_wrapper() which is only called
> >> by the
> >>  > 'load' command.
> >>  >
> >>  > Reverting the commit fixes this issue for me.
> >>  >
> >>
> >> Dear Gray,
> >>
> >> thanks for reporting the issue with commit
> >> fs: do_load: pass device path for efi payload
> >> ee88eacbdd840199a3dec707234579fb15ddd46a
> >>
> >> Is it only the fatload command that fails on your device or also the
> >> load command?
> >>
> >> There is no bug tracker for U-Boot. So sending a mail to the U-Boot
> >> mailing list, the patch author, and the maintainer is the best way
> to
> >> inform the developers about bugs.
> >>
> >> Best regards
> >>
> >> Heinrich
> >>
> >>
> >> Additional information:
> >> cross-compiler gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabi
> >>
> >> The U-Boot environment being used is the default obtained by
> >> compiling U-Boot 2020.01-rc1-00100-gee93ef0c4b as dreamplug_defconfig
> >>
> >> => printenv
> >> baudrate=115200
> >> bootcmd=setenv ethact egiga0; ${x_bootcmd_ethernet}; setenv ethact
> >> egiga1; ${x_bootcmd_ethernet}; ${x_bootcmd_usb}; ${x_bootcmd_kernel};
> >> setenv bootargs ${x_bootargs} ${x_bootargs_root}; bootm 0x640;
> >> bootdelay=3
> >> ethact=egiga0
> >> fdtcontroladdr=1fb8e7c8
> >> stderr=serial
> >> stdin=serial
> >> stdout=serial
> >> x_bootargs=console=ttyS0,115200
> >> x_bootargs_root=root=/dev/sda2 rootdelay=10
> >> x_bootcmd_ethernet=ping 192.168.2.1
> >> x_bootcmd_kernel=fatload usb 0 0x640 uImage
> >> x_bootcmd_usb=usb start
> >>
> >> U-Boot hangs for other syntactically correct invocations of either
> >> 'fatload' or 'load'
> >> Other commands such as 'fatls' function as expected.
> >>
> >> Program flow is as follows:
> >>
> >> command 'fatload' (or 'load')
> >>  efi_set_bootdev()
> >>  ...
> >>  efi_dp_split_file_path()
> >>  ...
> >>  efi_dp_dup()
> >>  
> >>  efi_dp_size()
> >>  *while exit condition never met*
> >>  *infinite loop*
> >>
> >>
> >> This is not an attempted EFI boot, why is EFI code being invoked ?
> >
> > Thanks for debugging.
> >
> > When booting from EFI we need to know from which device the EFI binary
> > was loaded. We use this information to install the loaded image
> > protocol. At the time of the load command we do no know if you will
> > invoke bootz or bootefi.
>

Isn't that the purpose of the 'load' command ?

>
> > It might be that we have a problem with creating device paths for USB. I
> > will try to reproduce this.
> >
> > You could add
> >
> > printf("efi_dp_split_file_path(%pD)\n", full_path);
> >
> > at the beginning of efi_dp_split_file_path() to identify what device
> > path is passed to the function. This should produce an output like
> >
> > => load scsi 0:2 $kernel_addr_r description.txt
> >
> efi_dp_split_file_path(/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(0,0)/HD(2,MBR,0x6fe3a999,0x400,0x400)/description.txt)
> >
> >
> > Best regards
> >
> > Heinrich
>
> I just tested on an OrangePi PC with v2019.10 and got this:
>
> => fatload usb 0:1 $kernel_addr_r test.txt
>
> efi_dp_split_file_path(/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x1)/UsbClass(0x781,0x5571,0x0,0x0,0x0)/HD(1,MBR,0xfae8c6af,0x800,0x3b9f800)/test.txt)
> device path =
>
> /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x1)/UsbClass(0x781,0x5571,0x0,0x0,0x0)/HD(1,MBR,0xfae8c6af,0x800,0x3b9f800)
> file path = /test.txt
> 12 bytes read in 26 ms (0 Bytes/s)
> => md.b $kernel_addr_r 0c
> 4200: 4a 75 73 74 20 61 20 74 65 73 74 0a  Just a test.
>
> So debugging on your specific device is needed.
>

Why do you want to debug EFI code on a device that does not support EFI ?
I am not reporting a bug with EFI, the issue is 'fatload' is now broken 

[U-Boot] [PATCH v2] rockchip: rk3399: split rockpro64 out of evb_rk3399

[Vasily Khoruzhick]

rockpro64 needs to setup I/O domains in order for USB to work in u-boot.
Since we currently don't have a driver to do that, split it into its own
board file and initialize I/O domains here.

Signed-off-by: Vasily Khoruzhick 
---
v2: add missing include/configs/rockpro64_rk3399.h

 arch/arm/mach-rockchip/rk3399/Kconfig | 20 +++
 board/pine64/rockpro64_rk3399/Kconfig | 15 +
 board/pine64/rockpro64_rk3399/MAINTAINERS |  8 +++
 board/pine64/rockpro64_rk3399/Makefile|  7 +++
 .../rockpro64_rk3399/rockpro64-rk3399.c   | 55 +++
 board/rockchip/evb_rk3399/MAINTAINERS |  7 ---
 configs/rockpro64-rk3399_defconfig|  1 +
 include/configs/rockpro64_rk3399.h| 15 +
 8 files changed, 121 insertions(+), 7 deletions(-)
 create mode 100644 board/pine64/rockpro64_rk3399/Kconfig
 create mode 100644 board/pine64/rockpro64_rk3399/MAINTAINERS
 create mode 100644 board/pine64/rockpro64_rk3399/Makefile
 create mode 100644 board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
 create mode 100644 include/configs/rockpro64_rk3399.h

diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig 
b/arch/arm/mach-rockchip/rk3399/Kconfig
index 6660d05349..db67440c11 100644
--- a/arch/arm/mach-rockchip/rk3399/Kconfig
+++ b/arch/arm/mach-rockchip/rk3399/Kconfig
@@ -62,6 +62,25 @@ config TARGET_CHROMEBOOK_BOB
  display. It includes a Chrome OS EC (Cortex-M3) to provide access to
  the keyboard and battery functions.
 
+config TARGET_ROCKPRO64_RK3399
+   bool "Pine64 Rockpro64 board"
+   help
+ Rockro64 is SBC produced by Pine64. Key features:
+
+  * Rockchip RK3399
+  * 2/4GB Dual-Channel LPDDR3
+  * SD card slot
+  * eMMC socket
+  * 128Mb SPI Flash
+  * Gigabit ethernet
+  * PCIe 4X slot
+  * WiFI/BT module socket
+  * HDMI In/Out, DP, MIPI DSI/CSI, eDP
+  * USB 3.0, 2.0
+  * USB Type C power and data
+  * GPIO expansion ports
+  * DC 12V/2A
+
 endchoice
 
 config ROCKCHIP_BOOT_MODE_REG
@@ -95,5 +114,6 @@ source "board/rockchip/evb_rk3399/Kconfig"
 source "board/theobroma-systems/puma_rk3399/Kconfig"
 source "board/vamrs/rock960_rk3399/Kconfig"
 source "board/google/gru/Kconfig"
+source "board/pine64/rockpro64_rk3399/Kconfig"
 
 endif
diff --git a/board/pine64/rockpro64_rk3399/Kconfig 
b/board/pine64/rockpro64_rk3399/Kconfig
new file mode 100644
index 00..3353f1fd09
--- /dev/null
+++ b/board/pine64/rockpro64_rk3399/Kconfig
@@ -0,0 +1,15 @@
+if TARGET_ROCKPRO64_RK3399
+
+config SYS_BOARD
+   default "rockpro64_rk3399"
+
+config SYS_VENDOR
+   default "pine64"
+
+config SYS_CONFIG_NAME
+   default "rockpro64_rk3399"
+
+config BOARD_SPECIFIC_OPTIONS # dummy
+   def_bool y
+
+endif
diff --git a/board/pine64/rockpro64_rk3399/MAINTAINERS 
b/board/pine64/rockpro64_rk3399/MAINTAINERS
new file mode 100644
index 00..303db144aa
--- /dev/null
+++ b/board/pine64/rockpro64_rk3399/MAINTAINERS
@@ -0,0 +1,8 @@
+ROCKPRO64
+M: Akash Gajjar 
+M: Jagan Teki 
+S: Maintained
+F: board/pine64/rockpro64_rk3399
+F: include/configs/rockpro64_rk3399.h
+F: arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
+F: configs/rockpro64-rk3399_defconfig
diff --git a/board/pine64/rockpro64_rk3399/Makefile 
b/board/pine64/rockpro64_rk3399/Makefile
new file mode 100644
index 00..b015c47e6f
--- /dev/null
+++ b/board/pine64/rockpro64_rk3399/Makefile
@@ -0,0 +1,7 @@
+#
+# (C) Copyright 2019 Vasily Khoruzhick
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y  += rockpro64-rk3399.o
diff --git a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c 
b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
new file mode 100644
index 00..3f60235771
--- /dev/null
+++ b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2019 Vasily Khoruzhick 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GRF_IO_VSEL_BT565_SHIFT 0
+#define PMUGRF_CON0_VSEL_SHIFT 8
+
+#ifdef CONFIG_MISC_INIT_R
+static void setup_iodomain(void)
+{
+   struct rk3399_grf_regs *grf =
+   syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+   struct rk3399_pmugrf_regs *pmugrf =
+   syscon_get_first_range(ROCKCHIP_SYSCON_PMUGRF);
+
+   /* BT565 is in 1.8v domain */
+   rk_setreg(>io_vsel, 1 << GRF_IO_VSEL_BT565_SHIFT);
+
+   /* Set GPIO1 1.8v/3.0v source select to PMU1830_VOL */
+   rk_setreg(>soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
+}
+
+int misc_init_r(void)
+{
+   const u32 cpuid_offset = 0x7;
+   const u32 cpuid_length = 0x10;
+   u8 cpuid[cpuid_length];
+   int ret;
+
+   setup_iodomain();
+
+   ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
+   if (ret)
+   return ret;
+
+   ret = rockchip_cpuid_set(cpuid, cpuid_length);
+   

[U-Boot] [PATCH] .gitignore: Ignore .img files

[Michael Trimarchi]

The generated idbloader.img file that rockchip uses should
be not included in git status report

Signed-off-by: Michael Trimarchi 
---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index d8b7b77844..f980ae6f70 100644
--- a/.gitignore
+++ b/.gitignore
@@ -17,6 +17,7 @@
 *.gcda
 *.gcno
 *.i
+*.img
 *.lex.c
 *.lst
 *.mod.c
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] .gitignore: Ignore .img files

[Michael Trimarchi]

The generated idbloader.img file that rockchip uses should
be not included in git status report

Signed-off-by: Michael Trimarchi 
---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index d8b7b77844..f980ae6f70 100644
--- a/.gitignore
+++ b/.gitignore
@@ -17,6 +17,7 @@
 *.gcda
 *.gcno
 *.i
+*.img
 *.lex.c
 *.lst
 *.mod.c
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH V2] rockchip: dts: tinker: Add tinker-s board support

[Michael Trimarchi]

Support tinker-s board. The board is equivalent of tinker board
except of emmc.

TODO:
- support of usb current burst when the board is powered from pc

Signed-off-by: Michael Trimarchi 
---
Changes V1->V2:
emmc: Add boot device

---
 arch/arm/dts/Makefile|  1 +
 arch/arm/dts/rk3288-tinker-s-u-boot.dtsi | 34 
 arch/arm/dts/rk3288-tinker-s.dts | 40 ++
 configs/tinker-s-rk3288_defconfig| 99 
 include/configs/tinker_rk3288.h  |  1 +
 5 files changed, 175 insertions(+)
 create mode 100644 arch/arm/dts/rk3288-tinker-s-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3288-tinker-s.dts
 create mode 100644 configs/tinker-s-rk3288_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 89ab8001ce..7e9d6809ea 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -87,6 +87,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3288) += \
rk3288-popmetal.dtb \
rk3288-rock2-square.dtb \
rk3288-tinker.dtb \
+   rk3288-tinker-s.dtb \
rk3288-veyron-jerry.dtb \
rk3288-veyron-mickey.dtb \
rk3288-veyron-minnie.dtb \
diff --git a/arch/arm/dts/rk3288-tinker-s-u-boot.dtsi 
b/arch/arm/dts/rk3288-tinker-s-u-boot.dtsi
new file mode 100644
index 00..a177fca73a
--- /dev/null
+++ b/arch/arm/dts/rk3288-tinker-s-u-boot.dtsi
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Amarula Solutions SRO
+ */
+
+#include "rk3288-u-boot.dtsi"
+#include "rk3288-tinker-u-boot.dtsi"
+
+/ {
+   chosen {
+   u-boot,spl-boot-order = \
+   "same-as-spl", , 
+   };
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+_clk {
+   u-boot,dm-spl;
+};
+
+_cmd {
+   u-boot,dm-spl;
+};
+
+_pwr {
+   u-boot,dm-spl;
+};
+
+_bus8 {
+   u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/rk3288-tinker-s.dts b/arch/arm/dts/rk3288-tinker-s.dts
new file mode 100644
index 00..5884e280d2
--- /dev/null
+++ b/arch/arm/dts/rk3288-tinker-s.dts
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ */
+
+/dts-v1/;
+
+#include "rk3288-tinker.dtsi"
+
+/ {
+   model = "Rockchip RK3288 Asus Tinker Board S";
+   compatible = "asus,rk3288-tinker-s", "rockchip,rk3288";
+
+   chosen {
+   stdout-path = 
+   };
+};
+
+ {
+   rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
+   0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
+   0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0
+   0x1 0x2 0x2 0x4 0x0 0x0 0xc0 0x4
+   0x8 0x1f4>;
+   rockchip,phy-timing = <0x48d7dd93 0x187008d8 0x121076
+   0x0 0xc3 0x6 0x2>;
+   rockchip,sdram-params = <0x20d266a4 0x5b6 2 53300 6 9 0>;
+};
+
+ {
+   bus-width = <8>;
+   cap-mmc-highspeed;
+   non-removable;
+   pinctrl-names = "default";
+   pinctrl-0 = <_clk _cmd _pwr _bus8>;
+   max-frequency = <15000>;
+   mmc-hs200-1_8v;
+   mmc-ddr-1_8v;
+   status = "okay";
+};
diff --git a/configs/tinker-s-rk3288_defconfig 
b/configs/tinker-s-rk3288_defconfig
new file mode 100644
index 00..c851a93f31
--- /dev/null
+++ b/configs/tinker-s-rk3288_defconfig
@@ -0,0 +1,99 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x0100
+CONFIG_SPL_GPIO_SUPPORT=y
+CONFIG_ROCKCHIP_RK3288=y
+CONFIG_TARGET_TINKER_RK3288=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL_SIZE_LIMIT=307200
+CONFIG_SPL_STACK_R_ADDR=0x80
+CONFIG_DEBUG_UART_BASE=0xff69
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_DEBUG_UART=y
+CONFIG_TPL_SYS_MALLOC_F_LEN=0x4000
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x4000
+CONFIG_SYS_MALLOC_F_LEN=0x4000
+# CONFIG_ANDROID_BOOT_IMAGE is not set
+CONFIG_USE_PREBOOT=y
+CONFIG_SILENT_CONSOLE=y
+CONFIG_CONSOLE_MUX=y
+CONFIG_DEFAULT_FDT_FILE="rk3288-tinker-s.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x30
+CONFIG_SPL_I2C_SUPPORT=y
+CONFIG_SPL_POWER_SUPPORT=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_USB_MASS_STORAGE=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_BMP=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_PMIC=y
+CONFIG_CMD_REGULATOR=y
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_SPL_PARTITION_UUIDS=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3288-tinker-s"
+CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks 
assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_SPL_SYSCON=y
+# CONFIG_SPL_SIMPLE_BUS is not set
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_FASTBOOT_FLASH=y
+CONFIG_FASTBOOT_FLASH_MMC_DEV=0
+CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
+CONFIG_ROCKCHIP_GPIO=y

Re: [U-Boot] [BUG] U-Boot hangs on fatload, commit ee88eacbdd840199a3dec707234579fb15ddd46a

[Heinrich Schuchardt]

On 11/9/19 6:08 PM, Heinrich Schuchardt wrote:

On 11/9/19 4:11 PM, Gray Remlin wrote:

On Fri, 8 Nov 2019 at 20:08, Heinrich Schuchardt mailto:xypron.g...@gmx.de>> wrote:

    On 11/8/19 7:32 PM, Gray Remlin wrote:
 > Please excuse the noise. I would like to file a bug report
    against the
 > above commit, a quick search of www.denx.de 
     did not
 > reveal how I should proceed. Please point me in the right
direction.
 >
 >
 > Issue:
 > U-Boot hangs (i.e. during boot) whenever the command 'fatload' is
    used.
 >
 > Details:
 > U-Boot 2019.10 compiled with either dreamplug_defconfig or
 > guruplug_defconfig.
 >
 > After the commit do_load() now additionally calls
efi_set_bootdev()
 > which was moved out of do_load_wrapper() which is only called
by the
 > 'load' command.
 >
 > Reverting the commit fixes this issue for me.
 >

    Dear Gray,

    thanks for reporting the issue with commit
    fs: do_load: pass device path for efi payload
    ee88eacbdd840199a3dec707234579fb15ddd46a

    Is it only the fatload command that fails on your device or also the
    load command?

    There is no bug tracker for U-Boot. So sending a mail to the U-Boot
    mailing list, the patch author, and the maintainer is the best way to
    inform the developers about bugs.

    Best regards

    Heinrich


Additional information:
cross-compiler gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabi

The U-Boot environment being used is the default obtained by
compiling U-Boot 2020.01-rc1-00100-gee93ef0c4b as dreamplug_defconfig

=> printenv
baudrate=115200
bootcmd=setenv ethact egiga0; ${x_bootcmd_ethernet}; setenv ethact
egiga1; ${x_bootcmd_ethernet}; ${x_bootcmd_usb}; ${x_bootcmd_kernel};
setenv bootargs ${x_bootargs} ${x_bootargs_root}; bootm 0x640;
bootdelay=3
ethact=egiga0
fdtcontroladdr=1fb8e7c8
stderr=serial
stdin=serial
stdout=serial
x_bootargs=console=ttyS0,115200
x_bootargs_root=root=/dev/sda2 rootdelay=10
x_bootcmd_ethernet=ping 192.168.2.1
x_bootcmd_kernel=fatload usb 0 0x640 uImage
x_bootcmd_usb=usb start

U-Boot hangs for other syntactically correct invocations of either
'fatload' or 'load'
Other commands such as 'fatls' function as expected.

Program flow is as follows:

command 'fatload' (or 'load')
         efi_set_bootdev()
                 ...
                 efi_dp_split_file_path()
                         ...
                         efi_dp_dup()
                                 
                                 efi_dp_size()
                                 *while exit condition never met*
                                         *infinite loop*


This is not an attempted EFI boot, why is EFI code being invoked ?


Thanks for debugging.

When booting from EFI we need to know from which device the EFI binary
was loaded. We use this information to install the loaded image
protocol. At the time of the load command we do no know if you will
invoke bootz or bootefi.

It might be that we have a problem with creating device paths for USB. I
will try to reproduce this.

You could add

printf("efi_dp_split_file_path(%pD)\n", full_path);

at the beginning of efi_dp_split_file_path() to identify what device
path is passed to the function. This should produce an output like

=> load scsi 0:2 $kernel_addr_r description.txt
efi_dp_split_file_path(/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(0,0)/HD(2,MBR,0x6fe3a999,0x400,0x400)/description.txt)


Best regards

Heinrich


I just tested on an OrangePi PC with v2019.10 and got this:

=> fatload usb 0:1 $kernel_addr_r test.txt
efi_dp_split_file_path(/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x1)/UsbClass(0x781,0x5571,0x0,0x0,0x0)/HD(1,MBR,0xfae8c6af,0x800,0x3b9f800)/test.txt)
device path =
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x1)/UsbClass(0x781,0x5571,0x0,0x0,0x0)/HD(1,MBR,0xfae8c6af,0x800,0x3b9f800)
file path = /test.txt
12 bytes read in 26 ms (0 Bytes/s)
=> md.b $kernel_addr_r 0c
4200: 4a 75 73 74 20 61 20 74 65 73 74 0a  Just a test.

So debugging on your specific device is needed.

> x_bootcmd_kernel=fatload usb 0 0x640 uImage
You do not specify a partition number. Do you have a partition table?
Than the partition defaults to 1. Or does the file system sit directly
on the device?

Best regards

Heinrich





Whilst the proposition 'EFI boot = FAT filesystem' is True
the converse 'FAT filesystem = EFI boot' is Not True

I am willing to help, but that may require some EFI hand-holding.
Gray

PS. If anyone knows how to set '>' on reply content in GMail, please
email me off list.






___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] rockchip: rk3399: split rockpro64 out of evb_rk3399

[Vasily Khoruzhick]

On Sat, Nov 9, 2019 at 12:41 AM Vasily Khoruzhick  wrote:
>
> rockpro64 needs to setup I/O domains in order for USB to work in u-boot.
> Since we currently don't have a driver to do that, split it into its own
> board file and initialize I/O domains here.

Please discard this patch, I forgot to git add one file. Will send v2 shortly.

> Signed-off-by: Vasily Khoruzhick 
> ---
>  arch/arm/mach-rockchip/rk3399/Kconfig | 20 +++
>  board/pine64/rockpro64_rk3399/Kconfig | 15 +
>  board/pine64/rockpro64_rk3399/MAINTAINERS |  8 +++
>  board/pine64/rockpro64_rk3399/Makefile|  7 +++
>  .../rockpro64_rk3399/rockpro64-rk3399.c   | 55 +++
>  board/rockchip/evb_rk3399/MAINTAINERS |  7 ---
>  configs/rockpro64-rk3399_defconfig|  1 +
>  7 files changed, 106 insertions(+), 7 deletions(-)
>  create mode 100644 board/pine64/rockpro64_rk3399/Kconfig
>  create mode 100644 board/pine64/rockpro64_rk3399/MAINTAINERS
>  create mode 100644 board/pine64/rockpro64_rk3399/Makefile
>  create mode 100644 board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
>
> diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig 
> b/arch/arm/mach-rockchip/rk3399/Kconfig
> index 6660d05349..db67440c11 100644
> --- a/arch/arm/mach-rockchip/rk3399/Kconfig
> +++ b/arch/arm/mach-rockchip/rk3399/Kconfig
> @@ -62,6 +62,25 @@ config TARGET_CHROMEBOOK_BOB
>   display. It includes a Chrome OS EC (Cortex-M3) to provide access to
>   the keyboard and battery functions.
>
> +config TARGET_ROCKPRO64_RK3399
> +   bool "Pine64 Rockpro64 board"
> +   help
> + Rockro64 is SBC produced by Pine64. Key features:
> +
> +  * Rockchip RK3399
> +  * 2/4GB Dual-Channel LPDDR3
> +  * SD card slot
> +  * eMMC socket
> +  * 128Mb SPI Flash
> +  * Gigabit ethernet
> +  * PCIe 4X slot
> +  * WiFI/BT module socket
> +  * HDMI In/Out, DP, MIPI DSI/CSI, eDP
> +  * USB 3.0, 2.0
> +  * USB Type C power and data
> +  * GPIO expansion ports
> +  * DC 12V/2A
> +
>  endchoice
>
>  config ROCKCHIP_BOOT_MODE_REG
> @@ -95,5 +114,6 @@ source "board/rockchip/evb_rk3399/Kconfig"
>  source "board/theobroma-systems/puma_rk3399/Kconfig"
>  source "board/vamrs/rock960_rk3399/Kconfig"
>  source "board/google/gru/Kconfig"
> +source "board/pine64/rockpro64_rk3399/Kconfig"
>
>  endif
> diff --git a/board/pine64/rockpro64_rk3399/Kconfig 
> b/board/pine64/rockpro64_rk3399/Kconfig
> new file mode 100644
> index 00..3353f1fd09
> --- /dev/null
> +++ b/board/pine64/rockpro64_rk3399/Kconfig
> @@ -0,0 +1,15 @@
> +if TARGET_ROCKPRO64_RK3399
> +
> +config SYS_BOARD
> +   default "rockpro64_rk3399"
> +
> +config SYS_VENDOR
> +   default "pine64"
> +
> +config SYS_CONFIG_NAME
> +   default "rockpro64_rk3399"
> +
> +config BOARD_SPECIFIC_OPTIONS # dummy
> +   def_bool y
> +
> +endif
> diff --git a/board/pine64/rockpro64_rk3399/MAINTAINERS 
> b/board/pine64/rockpro64_rk3399/MAINTAINERS
> new file mode 100644
> index 00..303db144aa
> --- /dev/null
> +++ b/board/pine64/rockpro64_rk3399/MAINTAINERS
> @@ -0,0 +1,8 @@
> +ROCKPRO64
> +M: Akash Gajjar 
> +M: Jagan Teki 
> +S: Maintained
> +F: board/pine64/rockpro64_rk3399
> +F: include/configs/rockpro64_rk3399.h
> +F: arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> +F: configs/rockpro64-rk3399_defconfig
> diff --git a/board/pine64/rockpro64_rk3399/Makefile 
> b/board/pine64/rockpro64_rk3399/Makefile
> new file mode 100644
> index 00..b015c47e6f
> --- /dev/null
> +++ b/board/pine64/rockpro64_rk3399/Makefile
> @@ -0,0 +1,7 @@
> +#
> +# (C) Copyright 2019 Vasily Khoruzhick
> +#
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +
> +obj-y  += rockpro64-rk3399.o
> diff --git a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c 
> b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
> new file mode 100644
> index 00..3f60235771
> --- /dev/null
> +++ b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
> @@ -0,0 +1,55 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2019 Vasily Khoruzhick 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define GRF_IO_VSEL_BT565_SHIFT 0
> +#define PMUGRF_CON0_VSEL_SHIFT 8
> +
> +#ifdef CONFIG_MISC_INIT_R
> +static void setup_iodomain(void)
> +{
> +   struct rk3399_grf_regs *grf =
> +   syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
> +   struct rk3399_pmugrf_regs *pmugrf =
> +   syscon_get_first_range(ROCKCHIP_SYSCON_PMUGRF);
> +
> +   /* BT565 is in 1.8v domain */
> +   rk_setreg(>io_vsel, 1 << GRF_IO_VSEL_BT565_SHIFT);
> +
> +   /* Set GPIO1 1.8v/3.0v source select to PMU1830_VOL */
> +   rk_setreg(>soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
> +}
> +
> +int misc_init_r(void)
> +{
> +   const u32 cpuid_offset = 0x7;
> +   const u32 cpuid_length 

[U-Boot] [PATCH] rockchip: dts: tinker: Add tinker-s board support

[Michael Trimarchi]

Support tinker-s board. The board is equivalent of tinker board
except of emmc.

TODO:
- support of usb current burst when the board is powered from pc

Signed-off-by: Michael Trimarchi 
---
 arch/arm/dts/Makefile|  1 +
 arch/arm/dts/rk3288-tinker-s-u-boot.dtsi | 34 
 arch/arm/dts/rk3288-tinker-s.dts | 40 ++
 configs/tinker-s-rk3288_defconfig| 99 
 4 files changed, 174 insertions(+)
 create mode 100644 arch/arm/dts/rk3288-tinker-s-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3288-tinker-s.dts
 create mode 100644 configs/tinker-s-rk3288_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 89ab8001ce..7e9d6809ea 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -87,6 +87,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3288) += \
rk3288-popmetal.dtb \
rk3288-rock2-square.dtb \
rk3288-tinker.dtb \
+   rk3288-tinker-s.dtb \
rk3288-veyron-jerry.dtb \
rk3288-veyron-mickey.dtb \
rk3288-veyron-minnie.dtb \
diff --git a/arch/arm/dts/rk3288-tinker-s-u-boot.dtsi 
b/arch/arm/dts/rk3288-tinker-s-u-boot.dtsi
new file mode 100644
index 00..a177fca73a
--- /dev/null
+++ b/arch/arm/dts/rk3288-tinker-s-u-boot.dtsi
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Amarula Solutions SRO
+ */
+
+#include "rk3288-u-boot.dtsi"
+#include "rk3288-tinker-u-boot.dtsi"
+
+/ {
+   chosen {
+   u-boot,spl-boot-order = \
+   "same-as-spl", , 
+   };
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+_clk {
+   u-boot,dm-spl;
+};
+
+_cmd {
+   u-boot,dm-spl;
+};
+
+_pwr {
+   u-boot,dm-spl;
+};
+
+_bus8 {
+   u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/rk3288-tinker-s.dts b/arch/arm/dts/rk3288-tinker-s.dts
new file mode 100644
index 00..5884e280d2
--- /dev/null
+++ b/arch/arm/dts/rk3288-tinker-s.dts
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ */
+
+/dts-v1/;
+
+#include "rk3288-tinker.dtsi"
+
+/ {
+   model = "Rockchip RK3288 Asus Tinker Board S";
+   compatible = "asus,rk3288-tinker-s", "rockchip,rk3288";
+
+   chosen {
+   stdout-path = 
+   };
+};
+
+ {
+   rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
+   0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
+   0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0
+   0x1 0x2 0x2 0x4 0x0 0x0 0xc0 0x4
+   0x8 0x1f4>;
+   rockchip,phy-timing = <0x48d7dd93 0x187008d8 0x121076
+   0x0 0xc3 0x6 0x2>;
+   rockchip,sdram-params = <0x20d266a4 0x5b6 2 53300 6 9 0>;
+};
+
+ {
+   bus-width = <8>;
+   cap-mmc-highspeed;
+   non-removable;
+   pinctrl-names = "default";
+   pinctrl-0 = <_clk _cmd _pwr _bus8>;
+   max-frequency = <15000>;
+   mmc-hs200-1_8v;
+   mmc-ddr-1_8v;
+   status = "okay";
+};
diff --git a/configs/tinker-s-rk3288_defconfig 
b/configs/tinker-s-rk3288_defconfig
new file mode 100644
index 00..c851a93f31
--- /dev/null
+++ b/configs/tinker-s-rk3288_defconfig
@@ -0,0 +1,99 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x0100
+CONFIG_SPL_GPIO_SUPPORT=y
+CONFIG_ROCKCHIP_RK3288=y
+CONFIG_TARGET_TINKER_RK3288=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL_SIZE_LIMIT=307200
+CONFIG_SPL_STACK_R_ADDR=0x80
+CONFIG_DEBUG_UART_BASE=0xff69
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_DEBUG_UART=y
+CONFIG_TPL_SYS_MALLOC_F_LEN=0x4000
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x4000
+CONFIG_SYS_MALLOC_F_LEN=0x4000
+# CONFIG_ANDROID_BOOT_IMAGE is not set
+CONFIG_USE_PREBOOT=y
+CONFIG_SILENT_CONSOLE=y
+CONFIG_CONSOLE_MUX=y
+CONFIG_DEFAULT_FDT_FILE="rk3288-tinker-s.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x30
+CONFIG_SPL_I2C_SUPPORT=y
+CONFIG_SPL_POWER_SUPPORT=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_USB_MASS_STORAGE=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_BMP=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_PMIC=y
+CONFIG_CMD_REGULATOR=y
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_SPL_PARTITION_UUIDS=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3288-tinker-s"
+CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks 
assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_SPL_SYSCON=y
+# CONFIG_SPL_SIMPLE_BUS is not set
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_FASTBOOT_FLASH=y
+CONFIG_FASTBOOT_FLASH_MMC_DEV=0
+CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MISC=y
+CONFIG_I2C_EEPROM=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y

Re: [U-Boot] [BUG] U-Boot hangs on fatload, commit ee88eacbdd840199a3dec707234579fb15ddd46a

[Gray Remlin]

On Sat, 9 Nov 2019 at 17:08, Heinrich Schuchardt  wrote:

> On 11/9/19 4:11 PM, Gray Remlin wrote:
> > On Fri, 8 Nov 2019 at 20:08, Heinrich Schuchardt  > > wrote:
> >
> > On 11/8/19 7:32 PM, Gray Remlin wrote:
> >  > Please excuse the noise. I would like to file a bug report
> > against the
> >  > above commit, a quick search of www.denx.de 
> >  did not
> >  > reveal how I should proceed. Please point me in the right
> direction.
> >  >
> >  >
> >  > Issue:
> >  > U-Boot hangs (i.e. during boot) whenever the command 'fatload' is
> > used.
> >  >
> >  > Details:
> >  > U-Boot 2019.10 compiled with either dreamplug_defconfig or
> >  > guruplug_defconfig.
> >  >
> >  > After the commit do_load() now additionally calls
> efi_set_bootdev()
> >  > which was moved out of do_load_wrapper() which is only called by
> the
> >  > 'load' command.
> >  >
> >  > Reverting the commit fixes this issue for me.
> >  >
> >
> > Dear Gray,
> >
> > thanks for reporting the issue with commit
> > fs: do_load: pass device path for efi payload
> > ee88eacbdd840199a3dec707234579fb15ddd46a
> >
> > Is it only the fatload command that fails on your device or also the
> > load command?
> >
> > There is no bug tracker for U-Boot. So sending a mail to the U-Boot
> > mailing list, the patch author, and the maintainer is the best way to
> > inform the developers about bugs.
> >
> > Best regards
> >
> > Heinrich
> >
> >
> > Additional information:
> > cross-compiler gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabi
> >
> > The U-Boot environment being used is the default obtained by
> > compiling U-Boot 2020.01-rc1-00100-gee93ef0c4b as dreamplug_defconfig
> >
> > => printenv
> > baudrate=115200
> > bootcmd=setenv ethact egiga0; ${x_bootcmd_ethernet}; setenv ethact
> > egiga1; ${x_bootcmd_ethernet}; ${x_bootcmd_usb}; ${x_bootcmd_kernel};
> > setenv bootargs ${x_bootargs} ${x_bootargs_root}; bootm 0x640;
> > bootdelay=3
> > ethact=egiga0
> > fdtcontroladdr=1fb8e7c8
> > stderr=serial
> > stdin=serial
> > stdout=serial
> > x_bootargs=console=ttyS0,115200
> > x_bootargs_root=root=/dev/sda2 rootdelay=10
> > x_bootcmd_ethernet=ping 192.168.2.1
> > x_bootcmd_kernel=fatload usb 0 0x640 uImage
> > x_bootcmd_usb=usb start
> >
> > U-Boot hangs for other syntactically correct invocations of either
> > 'fatload' or 'load'
> > Other commands such as 'fatls' function as expected.
> >
> > Program flow is as follows:
> >
> > command 'fatload' (or 'load')
> >  efi_set_bootdev()
> >  ...
> >  efi_dp_split_file_path()
> >  ...
> >  efi_dp_dup()
> >  
> >  efi_dp_size()
> >  *while exit condition never met*
> >  *infinite loop*
> >
> >
> > This is not an attempted EFI boot, why is EFI code being invoked ?
>
> Thanks for debugging.
>
> When booting from EFI we need to know from which device the EFI binary
> was loaded. We use this information to install the loaded image
> protocol. At the time of the load command we do no know if you will
> invoke bootz or bootefi.
>

Wasn't that the reason for the load wrapper ?

'load' for bootefi
and
'fatload' for 'bootz' | 'bootm'


>
> It might be that we have a problem with creating device paths for USB. I
> will try to reproduce this.
>
> You could add
>
> printf("efi_dp_split_file_path(%pD)\n", full_path);
>
> at the beginning of efi_dp_split_file_path() to identify what device
> path is passed to the function. This should produce an output like
>
> => load scsi 0:2 $kernel_addr_r description.txt
>
> efi_dp_split_file_path(/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(0,0)/HD(2,MBR,0x6fe3a999,0x400,0x400)/description.txt)
>
>
efi_dp_split_file_path(/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x1)/UsbClass(0x1a40,0x101,0x9,0x0,0x1)/UsbClass(0x5e3,0x726,0x0,0x0,0x0)/HD(1,MBR,0x000f2899,0x800,0x1f800)/uImage/UNKNOWN(,)/UNKNOWN(,)/UNKNOWN(,)/UNKNOWN(,)/UNKNOWN(,)/UNKNOWN(,)/UNKNOWN(,)/UNKNOWN(,)/UNKNOWN(,)/UNKNOWN(,)/UNKNOWN(,)/UNKNOWN(,)/UNKNOWN(,)/UNKNOWN(,)/UNKNOWN(,)/UNKNOWN(,)/UNKNOWN(,)/UNKNOWN(,))


> Best regards
>
> Heinrich
>


>
> > Whilst the proposition 'EFI boot = FAT filesystem' is True
> > the converse 'FAT filesystem = EFI boot' is Not True
> >
> > I am willing to help, but that may require some EFI hand-holding.
> > Gray
> >
> > PS. If anyone knows how to set '>' on reply content in GMail, please
> > email me off list.
> >
>
>
___
U-Boot mailing list

Re: [U-Boot] [BUG] U-Boot hangs on fatload, commit ee88eacbdd840199a3dec707234579fb15ddd46a

[Heinrich Schuchardt]

On 11/9/19 4:11 PM, Gray Remlin wrote:

On Fri, 8 Nov 2019 at 20:08, Heinrich Schuchardt mailto:xypron.g...@gmx.de>> wrote:

On 11/8/19 7:32 PM, Gray Remlin wrote:
 > Please excuse the noise. I would like to file a bug report
against the
 > above commit, a quick search of www.denx.de 
 did not
 > reveal how I should proceed. Please point me in the right direction.
 >
 >
 > Issue:
 > U-Boot hangs (i.e. during boot) whenever the command 'fatload' is
used.
 >
 > Details:
 > U-Boot 2019.10 compiled with either dreamplug_defconfig or
 > guruplug_defconfig.
 >
 > After the commit do_load() now additionally calls efi_set_bootdev()
 > which was moved out of do_load_wrapper() which is only called by the
 > 'load' command.
 >
 > Reverting the commit fixes this issue for me.
 >

Dear Gray,

thanks for reporting the issue with commit
fs: do_load: pass device path for efi payload
ee88eacbdd840199a3dec707234579fb15ddd46a

Is it only the fatload command that fails on your device or also the
load command?

There is no bug tracker for U-Boot. So sending a mail to the U-Boot
mailing list, the patch author, and the maintainer is the best way to
inform the developers about bugs.

Best regards

Heinrich


Additional information:
cross-compiler gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabi

The U-Boot environment being used is the default obtained by
compiling U-Boot 2020.01-rc1-00100-gee93ef0c4b as dreamplug_defconfig

=> printenv
baudrate=115200
bootcmd=setenv ethact egiga0; ${x_bootcmd_ethernet}; setenv ethact
egiga1; ${x_bootcmd_ethernet}; ${x_bootcmd_usb}; ${x_bootcmd_kernel};
setenv bootargs ${x_bootargs} ${x_bootargs_root}; bootm 0x640;
bootdelay=3
ethact=egiga0
fdtcontroladdr=1fb8e7c8
stderr=serial
stdin=serial
stdout=serial
x_bootargs=console=ttyS0,115200
x_bootargs_root=root=/dev/sda2 rootdelay=10
x_bootcmd_ethernet=ping 192.168.2.1
x_bootcmd_kernel=fatload usb 0 0x640 uImage
x_bootcmd_usb=usb start

U-Boot hangs for other syntactically correct invocations of either
'fatload' or 'load'
Other commands such as 'fatls' function as expected.

Program flow is as follows:

command 'fatload' (or 'load')
         efi_set_bootdev()
                 ...
                 efi_dp_split_file_path()
                         ...
                         efi_dp_dup()
                                 
                                 efi_dp_size()
                                 *while exit condition never met*
                                         *infinite loop*


This is not an attempted EFI boot, why is EFI code being invoked ?


Thanks for debugging.

When booting from EFI we need to know from which device the EFI binary
was loaded. We use this information to install the loaded image
protocol. At the time of the load command we do no know if you will
invoke bootz or bootefi.

It might be that we have a problem with creating device paths for USB. I
will try to reproduce this.

You could add

printf("efi_dp_split_file_path(%pD)\n", full_path);

at the beginning of efi_dp_split_file_path() to identify what device
path is passed to the function. This should produce an output like

=> load scsi 0:2 $kernel_addr_r description.txt
efi_dp_split_file_path(/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(0,0)/HD(2,MBR,0x6fe3a999,0x400,0x400)/description.txt)

Best regards

Heinrich


Whilst the proposition 'EFI boot = FAT filesystem' is True
the converse 'FAT filesystem = EFI boot' is Not True

I am willing to help, but that may require some EFI hand-holding.
Gray

PS. If anyone knows how to set '>' on reply content in GMail, please
email me off list.



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/4] usb: host: dwc2: use driver model for PHY and CLOCK

[Patrick Delaunay]

Hi Marek,

My ci travis build is failing after the last updates (raspberry pi). I am
testing a update with sub for clk disable bulk function:

https://github.com/patrickdelaunay/u-boot/commit/1d053dd96e6623d02b84654398655a5563ccfdcb

Now buikd is ok:
https://travis-ci.org/patrickdelaunay/u-boot/builds/609496187

I will push it after the Week end (tuesday).

Sorry.

Patrick.



Le ven. 8 nov. 2019 à 16:55, Simon Goldschmidt <
simon.k.r.goldschm...@gmail.com> a écrit :

> Marek Vasut  schrieb am Fr., 8. Nov. 2019, 16:46:
>
> > On 11/8/19 3:47 PM, Patrick Delaunay wrote:
> > >
> > > In this serie I update the DWC2 host driver to use the device tree
> > > information and the associated PHY and CLOCK drivers when they are
> > > available.
> >
> > I'm kinda on the fence whether to add it into current release or not.
> > The patches look generally OK to me.
> >
> > Ley, Simon, can you check this on SoCFPGA ?
> >
>
> Gmm, so can try, but I don't have a working setup with USB peripherals
> attached... I do have USB on the socrates, but currently no cable to
> connect anything...
>
> I could test it to see if I can get the same result saying no attached
> devices are found, that would mean probing still works correctly...
>
> Regards,
> Simon
>
> Bin, can you give it a once-over ?
> >
> > If this looks OK to you, I will add it.
> >
> > [...]
> >
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [BUG] U-Boot hangs on fatload, commit ee88eacbdd840199a3dec707234579fb15ddd46a

[Gray Remlin]

On Fri, 8 Nov 2019 at 20:08, Heinrich Schuchardt  wrote:

> On 11/8/19 7:32 PM, Gray Remlin wrote:
> > Please excuse the noise. I would like to file a bug report against the
> > above commit, a quick search of www.denx.de  did not
> > reveal how I should proceed. Please point me in the right direction.
> >
> >
> > Issue:
> > U-Boot hangs (i.e. during boot) whenever the command 'fatload' is used.
> >
> > Details:
> > U-Boot 2019.10 compiled with either dreamplug_defconfig or
> > guruplug_defconfig.
> >
> > After the commit do_load() now additionally calls efi_set_bootdev()
> > which was moved out of do_load_wrapper() which is only called by the
> > 'load' command.
> >
> > Reverting the commit fixes this issue for me.
> >
>
> Dear Gray,
>
> thanks for reporting the issue with commit
> fs: do_load: pass device path for efi payload
> ee88eacbdd840199a3dec707234579fb15ddd46a
>
> Is it only the fatload command that fails on your device or also the
> load command?
>
> There is no bug tracker for U-Boot. So sending a mail to the U-Boot
> mailing list, the patch author, and the maintainer is the best way to
> inform the developers about bugs.
>
> Best regards
>
> Heinrich
>

Additional information:
cross-compiler gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabi

The U-Boot environment being used is the default obtained by
compiling U-Boot 2020.01-rc1-00100-gee93ef0c4b as dreamplug_defconfig

=> printenv
baudrate=115200
bootcmd=setenv ethact egiga0; ${x_bootcmd_ethernet}; setenv ethact egiga1;
${x_bootcmd_ethernet}; ${x_bootcmd_usb}; ${x_bootcmd_kernel}; setenv
bootargs ${x_bootargs} ${x_bootargs_root}; bootm 0x640;
bootdelay=3
ethact=egiga0
fdtcontroladdr=1fb8e7c8
stderr=serial
stdin=serial
stdout=serial
x_bootargs=console=ttyS0,115200
x_bootargs_root=root=/dev/sda2 rootdelay=10
x_bootcmd_ethernet=ping 192.168.2.1
x_bootcmd_kernel=fatload usb 0 0x640 uImage
x_bootcmd_usb=usb start

U-Boot hangs for other syntactically correct invocations of either
'fatload' or 'load'
Other commands such as 'fatls' function as expected.

Program flow is as follows:

command 'fatload' (or 'load')
efi_set_bootdev()
...
efi_dp_split_file_path()
...
efi_dp_dup()

efi_dp_size()
*while exit condition never met*
*infinite loop*


This is not an attempted EFI boot, why is EFI code being invoked ?
Whilst the proposition 'EFI boot = FAT filesystem' is True
the converse 'FAT filesystem = EFI boot' is Not True

I am willing to help, but that may require some EFI hand-holding.
Gray

PS. If anyone knows how to set '>' on reply content in GMail, please email
me off list.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] RK3399 boards (rockpi4 and rockpro64) kernel SError using upstream U-boot

[Qu Wenruo]

On 2019/11/9 下午9:45, Jagan Teki wrote:
> On Sat, Nov 9, 2019 at 6:48 PM Qu Wenruo  wrote:
>>
>>
>>
>> On 2019/11/9 下午8:25, Jagan Teki wrote:
>>> On Sat, Nov 9, 2019 at 12:08 PM Qu Wenruo  wrote:

 Hi,

 Although recent U-boot upstream has merged the rk3399 ram patchset to
 initial DDR4 properly, but strangely I can still trigger SError for
 RockPi4 and RockPro64 boards using upstream U-boot with upstream kernel
 (v5.4-rc). The dmesg is attached at the end.

 This is pretty easy to trigger if using "memtester 3584M" (both boards
 are 4G RAM variants).
 The strange part is, if using the vendor uboot (like Armbian does), then
 the kernel SError just goes away, so it looks like a bug in Uboot.
>>>
>>> Can you check u-boot memtest, past me the result.
>>
>> Looks like rockpi4 (maybe the whole rk3399 family) doesn't define
>> CONFIG_SYS_MEMTEST_START/END, thus enabling CONFIG_CMD_MEMTEST will
>> easily break the compile.
>>
>> Or any magic number for me to try?
> 
> Better try START with ddr base, and END some 256M set for basic test.

Not familiar enough for setting this up. :(

Is that memtest the best way to pin down the bug?

> 
>>
>>>

 The U-boot I built follows the README.rockchip, using the SD card and
 boot option 1 (miniloader + Uboot + rkbin).
 The script build script (arch PKGBUILD) can be found here:

 https://github.com/adam900710/PKGBUILDs/blob/rockpi4/alarm/uboot-rockpi4/PKGBUILD

 Any clue for the problem?
>>>
>>> Would you check this series [1]
>>>
>>> [1] https://patchwork.ozlabs.org/cover/1183700/
>>>
>> Any git repo? I hate to apply large patchset especially when there are
>> conflicts...
> 
> Hmm.. I didn't find the repo on the cover-letter. Did you check the
> u-boot-kerveryang github, may be Kever would place these on that repo
> I think.
> 

No luck. Anyway I'll try to solve the conflicts, as that's more feasible
to me.

Thanks,
Qu



signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] RK3399 boards (rockpi4 and rockpro64) kernel SError using upstream U-boot

[Jagan Teki]

On Sat, Nov 9, 2019 at 6:48 PM Qu Wenruo  wrote:
>
>
>
> On 2019/11/9 下午8:25, Jagan Teki wrote:
> > On Sat, Nov 9, 2019 at 12:08 PM Qu Wenruo  wrote:
> >>
> >> Hi,
> >>
> >> Although recent U-boot upstream has merged the rk3399 ram patchset to
> >> initial DDR4 properly, but strangely I can still trigger SError for
> >> RockPi4 and RockPro64 boards using upstream U-boot with upstream kernel
> >> (v5.4-rc). The dmesg is attached at the end.
> >>
> >> This is pretty easy to trigger if using "memtester 3584M" (both boards
> >> are 4G RAM variants).
> >> The strange part is, if using the vendor uboot (like Armbian does), then
> >> the kernel SError just goes away, so it looks like a bug in Uboot.
> >
> > Can you check u-boot memtest, past me the result.
>
> Looks like rockpi4 (maybe the whole rk3399 family) doesn't define
> CONFIG_SYS_MEMTEST_START/END, thus enabling CONFIG_CMD_MEMTEST will
> easily break the compile.
>
> Or any magic number for me to try?

Better try START with ddr base, and END some 256M set for basic test.

>
> >
> >>
> >> The U-boot I built follows the README.rockchip, using the SD card and
> >> boot option 1 (miniloader + Uboot + rkbin).
> >> The script build script (arch PKGBUILD) can be found here:
> >>
> >> https://github.com/adam900710/PKGBUILDs/blob/rockpi4/alarm/uboot-rockpi4/PKGBUILD
> >>
> >> Any clue for the problem?
> >
> > Would you check this series [1]
> >
> > [1] https://patchwork.ozlabs.org/cover/1183700/
> >
> Any git repo? I hate to apply large patchset especially when there are
> conflicts...

Hmm.. I didn't find the repo on the cover-letter. Did you check the
u-boot-kerveryang github, may be Kever would place these on that repo
I think.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] RK3399 boards (rockpi4 and rockpro64) kernel SError using upstream U-boot

[Qu Wenruo]

On 2019/11/9 下午8:25, Jagan Teki wrote:
> On Sat, Nov 9, 2019 at 12:08 PM Qu Wenruo  wrote:
>>
>> Hi,
>>
>> Although recent U-boot upstream has merged the rk3399 ram patchset to
>> initial DDR4 properly, but strangely I can still trigger SError for
>> RockPi4 and RockPro64 boards using upstream U-boot with upstream kernel
>> (v5.4-rc). The dmesg is attached at the end.
>>
>> This is pretty easy to trigger if using "memtester 3584M" (both boards
>> are 4G RAM variants).
>> The strange part is, if using the vendor uboot (like Armbian does), then
>> the kernel SError just goes away, so it looks like a bug in Uboot.
> 
> Can you check u-boot memtest, past me the result.

Looks like rockpi4 (maybe the whole rk3399 family) doesn't define
CONFIG_SYS_MEMTEST_START/END, thus enabling CONFIG_CMD_MEMTEST will
easily break the compile.

Or any magic number for me to try?

> 
>>
>> The U-boot I built follows the README.rockchip, using the SD card and
>> boot option 1 (miniloader + Uboot + rkbin).
>> The script build script (arch PKGBUILD) can be found here:
>>
>> https://github.com/adam900710/PKGBUILDs/blob/rockpi4/alarm/uboot-rockpi4/PKGBUILD
>>
>> Any clue for the problem?
> 
> Would you check this series [1]
> 
> [1] https://patchwork.ozlabs.org/cover/1183700/
> 
Any git repo? I hate to apply large patchset especially when there are
conflicts...

Thanks,
Qu



signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] rockchip: Fix spl boot order path of booting device

[Michael Trimarchi]

Fix rk3288, rk3188, rk322x, rk3368

Tested on rk3288

U-Boot SPL 2019.10-rc4-00014-g0493073dc4-dirty (Nov 09 2019 - 13:04:06 +0100)
board_spl_was_booted_from: brom_bootdevice_id 2 maps to 'dwmmc@ff0f'
board_boot_order: could not find dwmmc@ff0f in FDT

Signed-off-by: Michael Trimarchi 
---
 arch/arm/mach-rockchip/rk3188/rk3188.c | 4 ++--
 arch/arm/mach-rockchip/rk322x/rk322x.c | 4 ++--
 arch/arm/mach-rockchip/rk3288/rk3288.c | 4 ++--
 arch/arm/mach-rockchip/rk3368/rk3368.c | 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-rockchip/rk3188/rk3188.c 
b/arch/arm/mach-rockchip/rk3188/rk3188.c
index 95f0e3ccbe..1b012f7f67 100644
--- a/arch/arm/mach-rockchip/rk3188/rk3188.c
+++ b/arch/arm/mach-rockchip/rk3188/rk3188.c
@@ -14,8 +14,8 @@
 #define GRF_BASE   0x20008000
 
 const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
-   [BROM_BOOTSOURCE_EMMC] = "dwmmc@1021c000",
-   [BROM_BOOTSOURCE_SD] = "dwmmc@10214000",
+   [BROM_BOOTSOURCE_EMMC] = "/dwmmc@1021c000",
+   [BROM_BOOTSOURCE_SD] = "/dwmmc@10214000",
 };
 
 #ifdef CONFIG_DEBUG_UART_BOARD_INIT
diff --git a/arch/arm/mach-rockchip/rk322x/rk322x.c 
b/arch/arm/mach-rockchip/rk322x/rk322x.c
index cd0bf8a70c..562117e6c1 100644
--- a/arch/arm/mach-rockchip/rk322x/rk322x.c
+++ b/arch/arm/mach-rockchip/rk322x/rk322x.c
@@ -8,8 +8,8 @@
 #include 
 
 const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
-   [BROM_BOOTSOURCE_EMMC] = "dwmmc@3002",
-   [BROM_BOOTSOURCE_SD] = "dwmmc@3000",
+   [BROM_BOOTSOURCE_EMMC] = "/dwmmc@3002",
+   [BROM_BOOTSOURCE_SD] = "/dwmmc@3000",
 };
 
 #ifdef CONFIG_DEBUG_UART_BOARD_INIT
diff --git a/arch/arm/mach-rockchip/rk3288/rk3288.c 
b/arch/arm/mach-rockchip/rk3288/rk3288.c
index 057ce92080..987b4e0d58 100644
--- a/arch/arm/mach-rockchip/rk3288/rk3288.c
+++ b/arch/arm/mach-rockchip/rk3288/rk3288.c
@@ -22,8 +22,8 @@ DECLARE_GLOBAL_DATA_PTR;
 #define GRF_BASE   0xff77
 
 const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
-   [BROM_BOOTSOURCE_EMMC] = "dwmmc@ff0f",
-   [BROM_BOOTSOURCE_SD] = "dwmmc@ff0c",
+   [BROM_BOOTSOURCE_EMMC] = "/dwmmc@ff0f",
+   [BROM_BOOTSOURCE_SD] = "/dwmmc@ff0c",
 };
 
 #ifdef CONFIG_SPL_BUILD
diff --git a/arch/arm/mach-rockchip/rk3368/rk3368.c 
b/arch/arm/mach-rockchip/rk3368/rk3368.c
index 7ccd417a18..20ae797794 100644
--- a/arch/arm/mach-rockchip/rk3368/rk3368.c
+++ b/arch/arm/mach-rockchip/rk3368/rk3368.c
@@ -54,8 +54,8 @@ static struct mm_region rk3368_mem_map[] = {
 struct mm_region *mem_map = rk3368_mem_map;
 
 const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
-   [BROM_BOOTSOURCE_EMMC] = "dwmmc@ff0f",
-   [BROM_BOOTSOURCE_SD] = "dwmmc@ff0c",
+   [BROM_BOOTSOURCE_EMMC] = "/dwmmc@ff0f",
+   [BROM_BOOTSOURCE_SD] = "/dwmmc@ff0c",
 };
 
 #ifdef CONFIG_ARCH_EARLY_INIT_R
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] RK3399 boards (rockpi4 and rockpro64) kernel SError using upstream U-boot

[Jagan Teki]

On Sat, Nov 9, 2019 at 12:08 PM Qu Wenruo  wrote:
>
> Hi,
>
> Although recent U-boot upstream has merged the rk3399 ram patchset to
> initial DDR4 properly, but strangely I can still trigger SError for
> RockPi4 and RockPro64 boards using upstream U-boot with upstream kernel
> (v5.4-rc). The dmesg is attached at the end.
>
> This is pretty easy to trigger if using "memtester 3584M" (both boards
> are 4G RAM variants).
> The strange part is, if using the vendor uboot (like Armbian does), then
> the kernel SError just goes away, so it looks like a bug in Uboot.

Can you check u-boot memtest, past me the result.

>
> The U-boot I built follows the README.rockchip, using the SD card and
> boot option 1 (miniloader + Uboot + rkbin).
> The script build script (arch PKGBUILD) can be found here:
>
> https://github.com/adam900710/PKGBUILDs/blob/rockpi4/alarm/uboot-rockpi4/PKGBUILD
>
> Any clue for the problem?

Would you check this series [1]

[1] https://patchwork.ozlabs.org/cover/1183700/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash support

[Jagan Teki]

Hi Bin,

On Tue, Oct 29, 2019 at 3:50 PM Bin Meng  wrote:
>
> Hi Jagan,
>
> On Tue, Oct 29, 2019 at 5:38 PM Bin Meng  wrote:
> >
> > Hi Jagan,
> >
> > On Wed, Oct 16, 2019 at 10:58 PM Jagan Teki  
> > wrote:
> > >
> > > HiFive Unleashed A00 support is25wp256 spi-nor flash,
> > > So enable the same and add test result log for future
> > > reference.
> > >
> > > Tested on SiFive FU540 board.
> > >
> > > Signed-off-by: Jagan Teki 
> > > Reviewed-by: Bin Meng 
> > > Tested-by: Bin Meng 
> > > ---
> > >  .../dts/hifive-unleashed-a00-u-boot.dtsi  |  1 +
> > >  board/sifive/fu540/Kconfig|  3 +++
> > >  doc/board/sifive/fu540.rst| 19 +++
> > >  3 files changed, 23 insertions(+)
> > >
> > > diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi 
> > > b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > index 25ec8265a5..d7a64134db 100644
> > > --- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > +++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
> > > @@ -5,6 +5,7 @@
> > >
> > >  / {
> > > aliases {
> > > +   spi0 = 
> > > spi2 = 
> > > };
> > >  };
> > > diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
> > > index 5d65080429..c5a1bca03c 100644
> > > --- a/board/sifive/fu540/Kconfig
> > > +++ b/board/sifive/fu540/Kconfig
> > > @@ -26,6 +26,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> > > imply CMD_FS_GENERIC
> > > imply CMD_NET
> > > imply CMD_PING
> > > +   imply CMD_SF
> > > imply CLK_SIFIVE
> > > imply CLK_SIFIVE_FU540_PRCI
> > > imply DOS_PARTITION
> > > @@ -40,6 +41,8 @@ config BOARD_SPECIFIC_OPTIONS # dummy
> > > imply SIFIVE_SERIAL
> > > imply SPI
> > > imply SPI_SIFIVE
> > > +   imply SPI_FLASH
> > > +   imply SPI_FLASH_ISSI
> > > imply MMC
> > > imply MMC_SPI
> > > imply MMC_BROKEN_CD
> > > diff --git a/doc/board/sifive/fu540.rst b/doc/board/sifive/fu540.rst
> > > index 91b94ee06f..2e70cad02e 100644
> > > --- a/doc/board/sifive/fu540.rst
> > > +++ b/doc/board/sifive/fu540.rst
> > > @@ -366,3 +366,22 @@ load uImage.
> > >
> > > Please press Enter to activate this console.
> > > / #
> > > +
> > > +Sample spi nor flash test
> > > +-
> > > +
> > > +.. code-block:: none
> > > +
> > > +   => sf probe 0:2
> >
> > The cs number can't be 2. It should be zero.
>
> With this patch series, we got crazy duplicated flash devices created,
> see below:
>
> => sf probe
> unrecognized JEDEC id bytes: ff, ff, ff
> Failed to initialize SPI flash at 0:0 (error -2)
> => sf probe 0:2
> SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 32 
> MiB
> => sf probe 0:4
> SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 32 
> MiB
> => sf probe 0:6
> SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 32 
> MiB
> => dm tree
>  Class Index  Probed  DriverName
> ---
>  root  0  [ + ]   root_driver   root_driver
>  simple_bus0  [ + ]   generic_simple_bus|-- soc
>  clk   0  [ + ]   sifive-fu540-prci |   |--
> clock-controller@1000
>  serial0  [ + ]   serial_sifive |   |-- serial@1001
>  serial1  [   ]   serial_sifive |   |-- serial@10011000
>  spi   0  [ + ]   sifive_spi|   |-- spi@1004
>  spi_flash 0  [   ]   spi_flash_std |   |   |-- flash@0
>  spi_flash 1  [ + ]   spi_flash_std |   |   |-- spi_flash@0:2
>  spi_flash 2  [ + ]   spi_flash_std |   |   |-- spi_flash@0:4
>  spi_flash 3  [ + ]   spi_flash_std |   |   `-- spi_flash@0:6
>
> With my patch series below
> http://patchwork.ozlabs.org/project/uboot/list/?series=129736
>
> the CS number check was added to the SPI flash hence we got:
>
> => sf probe
> unrecognized JEDEC id bytes: ff, ff, ff
> Failed to initialize SPI flash at 0:0 (error -2)
> => sf probe 2
> Invalid cs 2 (err=-22)
> Invalid cs 2 (err=-22)
> Invalid chip select 0:2 (err=-22)
> Failed to initialize SPI flash at 0:2 (error -22)
> => sf probe 4
> Invalid cs 4 (err=-22)
> Invalid cs 4 (err=-22)
> Invalid chip select 0:4 (err=-22)
> Failed to initialize SPI flash at 0:4 (error -22)
>
> So we still need figure out why CS number 0 cannot work on SiFive.

The existing quad wire that driver pushing for flash seems not
detecting flash at CS 0 so making cr to single wire detecting flash at
CS0. One more point is that flash seems available in different CS, not
sure whether the hardware wired this logic or it has flash really on
those CS's.

=> sf probe 0:0
SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB
=> sf probe 0:1
unrecognized JEDEC id bytes: ff, ff, ff
Failed to initialize SPI flash at 0:1 (error -2)
=> sf probe 0:2
SF: Detected 

[U-Boot] [PATCH v3 1/2] riscv: dts: Add hifive-unleashed-a00 dts from Linux

[Jagan Teki]

Sync the hifive-unleashed-a00 dts from Linux with
below commit details:

commit <2993c9b04e616df0848b655d7202a707a70fc876> ("riscv: dts: HiFive
Unleashed: add default chosen/stdout-path")

Idea is to periodically sync the dts from Linux instead of
tweaking internal changes one after another, so better not
add any intermediate changes in between. This would help to
maintain the dts files easy and meaningful since we are
reusing device tree files from Linux.

Signed-off-by: Jagan Teki 
---
Changes for v3:
- none

 arch/riscv/dts/Makefile |   1 +
 arch/riscv/dts/fu540-c000.dtsi  | 251 
 arch/riscv/dts/hifive-unleashed-a00.dts |  96 +
 3 files changed, 348 insertions(+)
 create mode 100644 arch/riscv/dts/fu540-c000.dtsi
 create mode 100644 arch/riscv/dts/hifive-unleashed-a00.dts

diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
index f9cd606a9a..4f30e6936f 100644
--- a/arch/riscv/dts/Makefile
+++ b/arch/riscv/dts/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0+
 
 dtb-$(CONFIG_TARGET_AX25_AE350) += ae350_32.dtb ae350_64.dtb
+dtb-$(CONFIG_TARGET_SIFIVE_FU540) += hifive-unleashed-a00.dtb
 
 targets += $(dtb-y)
 
diff --git a/arch/riscv/dts/fu540-c000.dtsi b/arch/riscv/dts/fu540-c000.dtsi
new file mode 100644
index 00..afa43c7ea3
--- /dev/null
+++ b/arch/riscv/dts/fu540-c000.dtsi
@@ -0,0 +1,251 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/* Copyright (c) 2018-2019 SiFive, Inc */
+
+/dts-v1/;
+
+#include 
+
+/ {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   compatible = "sifive,fu540-c000", "sifive,fu540";
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   ethernet0 = 
+   };
+
+   chosen {
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   cpu0: cpu@0 {
+   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";
+   cpu0_intc: interrupt-controller {
+   #interrupt-cells = <1>;
+   compatible = "riscv,cpu-intc";
+   interrupt-controller;
+   };
+   };
+   cpu1: cpu@1 {
+   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;
+   cpu1_intc: interrupt-controller {
+   #interrupt-cells = <1>;
+   compatible = "riscv,cpu-intc";
+   interrupt-controller;
+   };
+   };
+   cpu2: cpu@2 {
+   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 = <2>;
+   riscv,isa = "rv64imafdc";
+   tlb-split;
+   cpu2_intc: interrupt-controller {
+   #interrupt-cells = <1>;
+   compatible = "riscv,cpu-intc";
+   interrupt-controller;
+   };
+   };
+   cpu3: cpu@3 {
+   compatible = "sifive,u54-mc", "sifive,rocket0", "riscv";
+   d-cache-block-size = <64>;
+   d-cache-sets = <64>;
+   d-cache-size = <32768>;
+   d-tlb-sets = <1>;
+

[U-Boot] [PATCH v3 2/2] sifive: fu540: Enable OF_SEPARATE

[Jagan Teki]

Use dts support from U-Boot via OF_SEPARATE instead of depending from
opensbi.

This would help to make the necessary changes in drivers and device trees
in U-Boot tree itself. This feature would also be helpful to not pass
dtb during opensbi builds.

Signed-off-by: Jagan Teki 
---
Changes for v3:
- fixed typo changes.

 configs/sifive_fu540_defconfig | 3 ++-
 doc/board/sifive/fu540.rst | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig
index 48865e5f11..979d0a0418 100644
--- a/configs/sifive_fu540_defconfig
+++ b/configs/sifive_fu540_defconfig
@@ -6,6 +6,7 @@ CONFIG_RISCV_SMODE=y
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_FIT=y
 CONFIG_MISC_INIT_R=y
+CONFIG_DEFAULT_DEVICE_TREE="hifive-unleashed-a00"
 CONFIG_DISPLAY_CPUINFO=y
 CONFIG_DISPLAY_BOARDINFO=y
-CONFIG_OF_PRIOR_STAGE=y
+CONFIG_OF_SEPARATE=y
diff --git a/doc/board/sifive/fu540.rst b/doc/board/sifive/fu540.rst
index 7807f5b2c1..91b94ee06f 100644
--- a/doc/board/sifive/fu540.rst
+++ b/doc/board/sifive/fu540.rst
@@ -58,7 +58,7 @@ firmware. We need to compile OpenSBI with below command:
 
 .. code-block:: none
 
-make PLATFORM=sifive/fu540 FW_PAYLOAD_PATH= 
FW_PAYLOAD_FDT_PATH=
+make PLATFORM=sifive/fu540 FW_PAYLOAD_PATH=
 
 (Note: Prefer hifive-unleashed-a00.dtb from Linux-5.3 or higher)
 (Note: Linux-5.2 is also fine but it does not have ethernet DT node)
-- 
2.18.0.321.gffc6fa0e3

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] serial: sandbox: support Unicode

[Andy Shevchenko]

On Sat, Nov 9, 2019 at 11:59 AM Heinrich Schuchardt  wrote:
>
> Due to a conversion error the sandbox does not accept byte values 0x80-0xff
> from the keyboard. The UEFI extended text input unit test requires Unicode
> support.
>
> Use unsigned char for the serial buffer.
>

FWIW,
Reviewed-by: Andy Shevchenko 

> Signed-off-by: Heinrich Schuchardt 
> ---
>  drivers/serial/sandbox.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/serial/sandbox.c b/drivers/serial/sandbox.c
> index 2f7bc24887..1af5cc12f3 100644
> --- a/drivers/serial/sandbox.c
> +++ b/drivers/serial/sandbox.c
> @@ -33,7 +33,7 @@ DECLARE_GLOBAL_DATA_PTR;
>   *   serial_buf_write   == serial_buf_read -> empty buffer
>   *   (serial_buf_write + 1) % 16 == serial_buf_read -> full buffer
>   */
> -static char serial_buf[16];
> +static unsigned char serial_buf[16];
>  static unsigned int serial_buf_write;
>  static unsigned int serial_buf_read;
>
> --
> 2.24.0
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot



-- 
With Best Regards,
Andy Shevchenko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/1] serial: sandbox: support Unicode

[Heinrich Schuchardt]

Due to a conversion error the sandbox does not accept byte values 0x80-0xff
from the keyboard. The UEFI extended text input unit test requires Unicode
support.

Use unsigned char for the serial buffer.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/serial/sandbox.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/serial/sandbox.c b/drivers/serial/sandbox.c
index 2f7bc24887..1af5cc12f3 100644
--- a/drivers/serial/sandbox.c
+++ b/drivers/serial/sandbox.c
@@ -33,7 +33,7 @@ DECLARE_GLOBAL_DATA_PTR;
  *   serial_buf_write   == serial_buf_read -> empty buffer
  *   (serial_buf_write + 1) % 16 == serial_buf_read -> full buffer
  */
-static char serial_buf[16];
+static unsigned char serial_buf[16];
 static unsigned int serial_buf_write;
 static unsigned int serial_buf_read;

--
2.24.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] USB doesn't work on Rockpro64 in u-boot

[Vasily Khoruzhick]

On Thu, Nov 7, 2019 at 10:33 PM Jagan Teki  wrote:
>
> Hi Vasily,
>
> On Fri, Nov 8, 2019 at 9:18 AM Vasily Khoruzhick  wrote:
> >
> > I checked voltage on regulator enable pin and it's 1.5v in u-boot (and it's
> > not enough to enable regulator!) and in linux it's 3v. That's why USB
> > ports have no power in u-boot.
> >
> > Looks like u-boot doesn't switch GPIO voltage from 1.8v to 3.3v. Any
> > ideas how to fix this?
>
> I think I need to clock look of this, will look into it next week. I'm
> travelling till that time.

I figured it out, rockpro64 needs I/O domains to be configured in
order for USB to work.

See "rockchip: rk3399: split rockpro64 out of evb_rk3399" patch on ML.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] rockchip: rk3399: split rockpro64 out of evb_rk3399

[Vasily Khoruzhick]

rockpro64 needs to setup I/O domains in order for USB to work in u-boot.
Since we currently don't have a driver to do that, split it into its own
board file and initialize I/O domains here.

Signed-off-by: Vasily Khoruzhick 
---
 arch/arm/mach-rockchip/rk3399/Kconfig | 20 +++
 board/pine64/rockpro64_rk3399/Kconfig | 15 +
 board/pine64/rockpro64_rk3399/MAINTAINERS |  8 +++
 board/pine64/rockpro64_rk3399/Makefile|  7 +++
 .../rockpro64_rk3399/rockpro64-rk3399.c   | 55 +++
 board/rockchip/evb_rk3399/MAINTAINERS |  7 ---
 configs/rockpro64-rk3399_defconfig|  1 +
 7 files changed, 106 insertions(+), 7 deletions(-)
 create mode 100644 board/pine64/rockpro64_rk3399/Kconfig
 create mode 100644 board/pine64/rockpro64_rk3399/MAINTAINERS
 create mode 100644 board/pine64/rockpro64_rk3399/Makefile
 create mode 100644 board/pine64/rockpro64_rk3399/rockpro64-rk3399.c

diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig 
b/arch/arm/mach-rockchip/rk3399/Kconfig
index 6660d05349..db67440c11 100644
--- a/arch/arm/mach-rockchip/rk3399/Kconfig
+++ b/arch/arm/mach-rockchip/rk3399/Kconfig
@@ -62,6 +62,25 @@ config TARGET_CHROMEBOOK_BOB
  display. It includes a Chrome OS EC (Cortex-M3) to provide access to
  the keyboard and battery functions.
 
+config TARGET_ROCKPRO64_RK3399
+   bool "Pine64 Rockpro64 board"
+   help
+ Rockro64 is SBC produced by Pine64. Key features:
+
+  * Rockchip RK3399
+  * 2/4GB Dual-Channel LPDDR3
+  * SD card slot
+  * eMMC socket
+  * 128Mb SPI Flash
+  * Gigabit ethernet
+  * PCIe 4X slot
+  * WiFI/BT module socket
+  * HDMI In/Out, DP, MIPI DSI/CSI, eDP
+  * USB 3.0, 2.0
+  * USB Type C power and data
+  * GPIO expansion ports
+  * DC 12V/2A
+
 endchoice
 
 config ROCKCHIP_BOOT_MODE_REG
@@ -95,5 +114,6 @@ source "board/rockchip/evb_rk3399/Kconfig"
 source "board/theobroma-systems/puma_rk3399/Kconfig"
 source "board/vamrs/rock960_rk3399/Kconfig"
 source "board/google/gru/Kconfig"
+source "board/pine64/rockpro64_rk3399/Kconfig"
 
 endif
diff --git a/board/pine64/rockpro64_rk3399/Kconfig 
b/board/pine64/rockpro64_rk3399/Kconfig
new file mode 100644
index 00..3353f1fd09
--- /dev/null
+++ b/board/pine64/rockpro64_rk3399/Kconfig
@@ -0,0 +1,15 @@
+if TARGET_ROCKPRO64_RK3399
+
+config SYS_BOARD
+   default "rockpro64_rk3399"
+
+config SYS_VENDOR
+   default "pine64"
+
+config SYS_CONFIG_NAME
+   default "rockpro64_rk3399"
+
+config BOARD_SPECIFIC_OPTIONS # dummy
+   def_bool y
+
+endif
diff --git a/board/pine64/rockpro64_rk3399/MAINTAINERS 
b/board/pine64/rockpro64_rk3399/MAINTAINERS
new file mode 100644
index 00..303db144aa
--- /dev/null
+++ b/board/pine64/rockpro64_rk3399/MAINTAINERS
@@ -0,0 +1,8 @@
+ROCKPRO64
+M: Akash Gajjar 
+M: Jagan Teki 
+S: Maintained
+F: board/pine64/rockpro64_rk3399
+F: include/configs/rockpro64_rk3399.h
+F: arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
+F: configs/rockpro64-rk3399_defconfig
diff --git a/board/pine64/rockpro64_rk3399/Makefile 
b/board/pine64/rockpro64_rk3399/Makefile
new file mode 100644
index 00..b015c47e6f
--- /dev/null
+++ b/board/pine64/rockpro64_rk3399/Makefile
@@ -0,0 +1,7 @@
+#
+# (C) Copyright 2019 Vasily Khoruzhick
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y  += rockpro64-rk3399.o
diff --git a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c 
b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
new file mode 100644
index 00..3f60235771
--- /dev/null
+++ b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2019 Vasily Khoruzhick 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GRF_IO_VSEL_BT565_SHIFT 0
+#define PMUGRF_CON0_VSEL_SHIFT 8
+
+#ifdef CONFIG_MISC_INIT_R
+static void setup_iodomain(void)
+{
+   struct rk3399_grf_regs *grf =
+   syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+   struct rk3399_pmugrf_regs *pmugrf =
+   syscon_get_first_range(ROCKCHIP_SYSCON_PMUGRF);
+
+   /* BT565 is in 1.8v domain */
+   rk_setreg(>io_vsel, 1 << GRF_IO_VSEL_BT565_SHIFT);
+
+   /* Set GPIO1 1.8v/3.0v source select to PMU1830_VOL */
+   rk_setreg(>soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
+}
+
+int misc_init_r(void)
+{
+   const u32 cpuid_offset = 0x7;
+   const u32 cpuid_length = 0x10;
+   u8 cpuid[cpuid_length];
+   int ret;
+
+   setup_iodomain();
+
+   ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
+   if (ret)
+   return ret;
+
+   ret = rockchip_cpuid_set(cpuid, cpuid_length);
+   if (ret)
+   return ret;
+
+   ret = rockchip_setup_macaddr();
+
+   return ret;
+}
+
+#endif
diff --git 

[U-Boot] [PATCH 1/2] sandbox: add missing compatible property in device tree

[Heinrich Schuchardt]

In the device tree UEFI unit test the compatible property of the device is
read.

Provide the missing property.

Signed-off-by: Heinrich Schuchardt 
---
 arch/sandbox/dts/sandbox.dts   | 1 +
 arch/sandbox/dts/sandbox64.dts | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/sandbox/dts/sandbox.dts b/arch/sandbox/dts/sandbox.dts
index f1637c80f6..4dd82f6a32 100644
--- a/arch/sandbox/dts/sandbox.dts
+++ b/arch/sandbox/dts/sandbox.dts
@@ -6,6 +6,7 @@
#address-cells = <1>;
#size-cells = <1>;
model = "sandbox";
+   compatible = "sandbox";

aliases {
i2c0 = _0;
diff --git a/arch/sandbox/dts/sandbox64.dts b/arch/sandbox/dts/sandbox64.dts
index 37a5539ff4..5c95cee9d7 100644
--- a/arch/sandbox/dts/sandbox64.dts
+++ b/arch/sandbox/dts/sandbox64.dts
@@ -6,6 +6,7 @@
#address-cells = <2>;
#size-cells = <2>;
model = "sandbox";
+   compatible = "sandbox";

aliases {
i2c0 = _0;
--
2.24.0.rc1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/2] configs: sandbox: enable CONFIG_CMD_BOOTEFI_SELFTEST

[Heinrich Schuchardt]

Activate UEFI unit tests on the sandbox.

Signed-off-by: Heinrich Schuchardt 
---
 configs/sandbox64_defconfig| 1 +
 configs/sandbox_defconfig  | 1 +
 configs/sandbox_flattree_defconfig | 1 +
 configs/sandbox_spl_defconfig  | 1 +
 4 files changed, 4 insertions(+)

diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index 1fea683d89..329645d362 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -21,6 +21,7 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_CMD_CPU=y
 CONFIG_CMD_LICENSE=y
 CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_BOOTEFI_SELFTEST=y
 # CONFIG_CMD_ELF is not set
 CONFIG_CMD_ASKENV=y
 CONFIG_CMD_GREPENV=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 20ebc68997..b6d0d3f2fa 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -24,6 +24,7 @@ CONFIG_ANDROID_AB=y
 CONFIG_CMD_CPU=y
 CONFIG_CMD_LICENSE=y
 CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_BOOTEFI_SELFTEST=y
 # CONFIG_CMD_ELF is not set
 CONFIG_CMD_ASKENV=y
 CONFIG_CMD_GREPENV=y
diff --git a/configs/sandbox_flattree_defconfig 
b/configs/sandbox_flattree_defconfig
index 898815fe53..02bbda071e 100644
--- a/configs/sandbox_flattree_defconfig
+++ b/configs/sandbox_flattree_defconfig
@@ -18,6 +18,7 @@ CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_CMD_CPU=y
 CONFIG_CMD_LICENSE=y
 CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_BOOTEFI_SELFTEST=y
 # CONFIG_CMD_ELF is not set
 CONFIG_CMD_ASKENV=y
 CONFIG_CMD_GREPENV=y
diff --git a/configs/sandbox_spl_defconfig b/configs/sandbox_spl_defconfig
index 409b8a38d5..9c24ea89ea 100644
--- a/configs/sandbox_spl_defconfig
+++ b/configs/sandbox_spl_defconfig
@@ -27,6 +27,7 @@ CONFIG_SPL_ENV_SUPPORT=y
 CONFIG_CMD_CPU=y
 CONFIG_CMD_LICENSE=y
 CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_BOOTEFI_SELFTEST=y
 # CONFIG_CMD_ELF is not set
 CONFIG_CMD_ASKENV=y
 CONFIG_CMD_GREPENV=y
--
2.24.0.rc1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 0/2] sandbox: enable UEFI unit tests

[Heinrich Schuchardt]

This patch series enables the UEFI unit tests on the sandbox.

The first patch add the missing compatible property in the device trees
which is required by on of the unit tests.

The real time clock unit test will fail if the sandbox is openend without
passing a device tree (parameter -D).

A separate series will enable building UEFI binaries for the sandbox and
enable the corresponding UEFI unit tests.

Heinrich Schuchardt (2):
  sandbox: add missing compatible property in device tree
  configs: sandbox: enable CONFIG_CMD_BOOTEFI_SELFTEST

 arch/sandbox/dts/sandbox.dts   | 1 +
 arch/sandbox/dts/sandbox64.dts | 1 +
 configs/sandbox64_defconfig| 1 +
 configs/sandbox_defconfig  | 1 +
 configs/sandbox_flattree_defconfig | 1 +
 configs/sandbox_spl_defconfig  | 1 +
 6 files changed, 6 insertions(+)

--
2.24.0.rc1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot