[U-Boot] [PATCH] board, zynqmp: Fix for wrong AMS setting by ROM

[Mike Looijmans]

A bug in the ZynqMP bootrom sets the PS_SYSMON_ANALOG_BUS register
at 0xFFA50914 to the wrong value 0x3201. This causes the AMS to
exchange the PS supply voltages 0 and 1. On Xilinx boards this is
not noticable since these are tied together, it's only really
noticable if banks 500 and 501 have different supplies. Xilinx' tech
support reported this undocumented register to be the cause, and
this patch applies a fix for all boards by programming the correct
value.

Signed-off-by: Mike Looijmans 
---
 board/xilinx/zynqmp/zynqmp.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index b94936474d..8d926c803b 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -326,6 +326,9 @@ int board_early_init_f(void)
return ret;
 }
 
+#define PS_SYSMON_ANALOG_BUS_VAL   0x3210
+#define PS_SYSMON_ANALOG_BUS_REG   0xFFA50914
+
 int board_init(void)
 {
struct udevice *dev;
@@ -343,6 +346,9 @@ int board_init(void)
 
printf("EL Level:\tEL%d\n", current_el());
 
+   /* Bug in ROM sets wrong value in this register */
+   writel(PS_SYSMON_ANALOG_BUS_VAL, PS_SYSMON_ANALOG_BUS_REG);
+
 #if defined(CONFIG_FPGA) && defined(CONFIG_FPGA_ZYNQMPPL) && \
 !defined(CONFIG_SPL_BUILD) || (defined(CONFIG_SPL_FPGA_SUPPORT) && \
 defined(CONFIG_SPL_BUILD))
-- 
2.17.1

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

Re: [U-Boot] problems with building u-boot-fit-dtb.bin

[Heiko Schocher]

Hello Tom,

Am 16.10.2019 um 10:45 schrieb Heiko Schocher:

Hello Tom,

Am 16.10.2019 um 06:56 schrieb Heiko Schocher:

Hello Tom,

I planned to send my patches which convert the imx6 based aristainetos
boards to support DM ... building U-Boot works fine on 2 different build
machines at home, also on 2 build machines in munich @ denx ...

So I startet as usual a travi build and I get:

https://travis-ci.org/hsdenx/u-boot-test/jobs/596917922


arm:  +   aristainetos2b
+make[2]: *** No rule to make target 'u-boot-fit-dtb.bin', needed by 
'u-boot-dtb.imx'.  Stop.
+make[1]: *** [u-boot-dtb.imx] Error 2
+make: *** [sub-make] Error 2

(for all aristainetos boards)

:-(

Unfortunately I cannot reproduce this on my machines...
(builds with "-j 64" or "-j 1" working fine)

I think it is a timing/sync issue, but how to debug ?

Checked make versions:

make on one of my build machines:

pollux:~ hs $ make --version
GNU Make 4.2.1
Gebaut für x86_64-redhat-linux-gnu
Copyright (C) 1988-2016 Free Software Foundation, Inc.
Lizenz GPLv3+: GNU GPL Version 3 oder später 
Dies ist freie Software: Sie können sie nach Belieben ändern und weiter 
verteilen.
Soweit es die Gesetze erlauben gibt es KEINE GARANTIE.
pollux:~ hs $ cd abb/mainlining/u-boot
pollux:u-boot

make on travis:

Tool chain test:  OK, arch='aarch64', priority 5
GNU Make 4.1
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Ok, for faster "debugging travis" I removed all other jobs from the
travis file and started build again:

https://travis-ci.org/hsdenx/u-boot-test/builds/597504777

The error for the aristainetos boards are gone  ?!?!?
(Ok, there are others, but not related to my changes)

I think it has to do with the config options:

CONFIG_OF_CONTROL=y
CONFIG_DEFAULT_DEVICE_TREE="imx6dl-aristainetos2_4"
CONFIG_OF_LIST="imx6dl-aristainetos2_4 imx6dl-aristainetos2_7"
CONFIG_DTB_RESELECT=y
CONFIG_MULTI_DTB_FIT=y

and I can only find mips boards, which has this settings. Difference
for imx boards to mips Makefile is, imx has make target in 2 Makefiles:

Makefile
arch/arm/mach-imx/Makefile

So the "u-boot-fit-dtb.bin" target is definitely there ...


Ok, I made a mistake in the travis.yml file, corrected it, and
started a new travis build now:

https://travis-ci.org/hsdenx/u-boot-test/builds/598489923

This job worked ...


build with all travis jobs fails:

https://travis-ci.org/hsdenx/u-boot-test/jobs/599459825

Any ideas?

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] pci: layerscape: remove multiple definitions of SVR

[Priyanka Jain]

>-Original Message-
>From: U-Boot  On Behalf Of Priyanka Jain
>Sent: Friday, October 18, 2019 10:46 AM
>To: Pankaj Bansal ; Xiaowei Bao
>; Tom Rini ; Z.q. Hou
>
>Cc: u-boot@lists.denx.de
>Subject: Re: [U-Boot] [PATCH v2] pci: layerscape: remove multiple definitions
>of SVR
>
>
>
>>-Original Message-
>>From: Pankaj Bansal
>>Sent: Wednesday, October 16, 2019 3:43 PM
>>To: Priyanka Jain ; Xiaowei Bao
>>; Tom Rini ; Z.q. Hou
>>
>>Cc: u-boot@lists.denx.de; Pankaj Bansal 
>>Subject: [PATCH v2] pci: layerscape: remove multiple definitions of SVR
>>
>>SVR values for various nxp SOCs are defined in asm/arch/soc.h we can
>>use these values in any peripheral driver.
>>we need not to redefine these values in peripheral driver, as this
>>becomes difficult to manage (add or change new values)
>>
>>Signed-off-by: Pankaj Bansal 
>>---
>>
>>Notes:
>>V2:
>>- fixed compilation errors in LS1021A based targets by adding SVR checking
>>  for layerscape series SOCs under LAYERSCAPE Macro.
>>[Dependencies]
>>-
>>https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
>>work.ozlabs.org%2Fpatch%2F1177732%2Fdata=02%7C01%7Cpriyanka.j
>ain%4
>>0nxp.com%7C086fd8c5509d455a0eb708d7538a5cb3%7C686ea1d3bc2b4c6fa9
>2cd99c5
>>c301635%7C0%7C0%7C637069726040396790sdata=21jhOzjm27k4aQW
>AK9BYhcoI
>>l6M78KAV3t9ImmlgSdw%3Dreserved=0
>>
>> drivers/pci/pcie_layerscape.c   | 18 --
>> drivers/pci/pcie_layerscape.h   |  9 +
>> drivers/pci/pcie_layerscape_fixup.c | 16 ++--
>> 3 files changed, 23 insertions(+), 20 deletions(-)
>>
>>diff --git a/drivers/pci/pcie_layerscape.c
>>b/drivers/pci/pcie_layerscape.c index
>>5ad7c28773..12357127a8 100644
>>--- a/drivers/pci/pcie_layerscape.c
>>+++ b/drivers/pci/pcie_layerscape.c
>>@@ -1,6 +1,6 @@
>> // SPDX-License-Identifier: GPL-2.0+
>> /*
>>- * Copyright 2017 NXP
>>+ * Copyright 2017, 2019 NXP
>Were there changes in this file in 2018? If yes, please update to 2017-2019
>>  * Copyright 2014-2015 Freescale Semiconductor, Inc.
>>  * Layerscape PCIe driver
>>  */
>>@@ -15,6 +15,7 @@
>> #if defined(CONFIG_FSL_LSCH2) || defined(CONFIG_FSL_LSCH3) || \
>>  defined(CONFIG_ARM)
>> #include 
>>+#include 
>> #endif
>> #include "pcie_layerscape.h"
>>
>>@@ -56,7 +57,7 @@ static int ls_pcie_ltssm(struct ls_pcie *pcie)
>>  uint svr;
>>
>>  svr = get_svr();
>>- if (((svr >> SVR_VAR_PER_SHIFT) & SVR_LS102XA_MASK) ==
>>SVR_LS102XA) {
>>+ if ((SVR_DEV(svr) & SVR_LS102XA_MASK) == SVR_LS102XA) {
>Is "SVR_LS102XA_MASK" LS102XA specific? Can we make it generic across
>other SoCs?
>
>>  state = ctrl_readl(pcie, LS1021_PEXMSCPORTSR(pcie->idx));
>>  state = (state >> LS1021_LTSSM_STATE_SHIFT) &
>LTSSM_STATE_MASK;
>>  } else {
>>@@ -149,7 +150,7 @@ static void ls_pcie_setup_atu(struct ls_pcie *pcie)
>>  uint svr;
>>
>>  svr = get_svr();
>>- if (((svr >> SVR_VAR_PER_SHIFT) & SVR_LS102XA_MASK) ==
>>SVR_LS102XA) {
>>+ if ((SVR_DEV(svr) & SVR_LS102XA_MASK) == SVR_LS102XA) {
>Same as above
>>  offset = LS1021_PCIE_SPACE_OFFSET +
>>   LS1021_PCIE_SPACE_SIZE * pcie->idx;
>>  }
>>@@ -172,7 +173,8 @@ static void ls_pcie_setup_atu(struct ls_pcie *pcie)
>>  idx = PCIE_ATU_REGION_INDEX1 + 1;
>>
>>  /* Fix the pcie memory map for LS2088A series SoCs */
>>- svr = (svr >> SVR_VAR_PER_SHIFT) & 0xFE;
>>+#if defined(CONFIG_FSL_LAYERSCAPE)
One more comment: use device tree instead of CONFIG

--priyankajain
>>+ svr = SVR_SOC_VER(svr);
>Please confirm that svr vaue is used only inside "CONFIG_FSL_LAYERSCAPE"
>>  if (svr == SVR_LS2088A || svr == SVR_LS2084A ||
>>  svr == SVR_LS2048A || svr == SVR_LS2044A ||
>>  svr == SVR_LS2081A || svr == SVR_LS2041A) { @@ -192,6 +194,7
>@@
>>static void ls_pcie_setup_atu(struct ls_pcie *pcie)
>>   LS2088A_PCIE1_PHYS_ADDR +
>>   LS2088A_PCIE_PHYS_SIZE * pcie->idx;
>>  }
>>+#endif /* CONFIG_FSL_LAYERSCAPE */
>>
>>  if (io)
>>  /* ATU : OUTBOUND : IO */
>>@@ -446,9 +449,7 @@ static int ls_pcie_probe(struct udevice *dev)
>>  const void *fdt = gd->fdt_blob;
>>  int node = dev_of_offset(dev);
>>  u16 link_sta;
>>- uint svr;
>>  int ret;
>>- fdt_size_t cfg_size;
>>
>>  pcie->bus = dev;
>>
>>@@ -501,6 +502,10 @@ static int ls_pcie_probe(struct udevice *dev)
>>  return ret;
>>  }
>>
>>+#if defined(CONFIG_FSL_LAYERSCAPE)
>>+ uint svr;
>>+ fdt_size_t cfg_size;
>>+
>As per u-boot coding style the preference, is to define variables in start of
>function
>>  /*
>>   * Fix the pcie memory map address and PF control registers address
>>   * for LS2088A series SoCs
>>@@ -516,6 +521,7 @@ static int ls_pcie_probe(struct udevice *dev)
>>  pcie->cfg_res.end = pcie->cfg_res.start + cfg_size;
>>  pcie->ctrl = pcie->lut + 0x4;
>> 

Re: [U-Boot] [PATCH] arm: freescale: ls102xa: add helper Macro to get the SVR

[Priyanka Jain]

>-Original Message-
>From: Pankaj Bansal
>Sent: Wednesday, October 16, 2019 3:40 PM
>To: Priyanka Jain ; Albert Aribaud
>; Simon Glass 
>Cc: u-boot@lists.denx.de; Pankaj Bansal 
>Subject: [PATCH] arm: freescale: ls102xa: add helper Macro to get the SVR
>
>32 bit System Version Register (SVR) in NXP SOCs contains information about
>SOC such as:
>1. SOC type (bits 8 - 31)
>2. SOC Major Revision (bits 4 - 7)
>3. SOC Minor Revision (bits 0 - 3)
>
>This Macro (SVR_DEV) strips the Major and Minor revision info, so that SOC
>can be correctly identified.
>This Macro is borrowed from Macro defined in arch/arm/include/asm/arch-
>fsl-layerscape/soc.h
>
>Additinally this file doesn't contain any valid license. Therefore, add
>GPLv2+ license in the file.
>same as arch/arm/include/asm/arch-fsl-layerscape/soc.h
>
>Signed-off-by: Pankaj Bansal 
>---
> arch/arm/include/asm/arch-ls102xa/soc.h | 6 ++
> 1 file changed, 6 insertions(+)
>
>diff --git a/arch/arm/include/asm/arch-ls102xa/soc.h
>b/arch/arm/include/asm/arch-ls102xa/soc.h
>index e69de29bb2..672f126bba 100644
>--- a/arch/arm/include/asm/arch-ls102xa/soc.h
>+++ b/arch/arm/include/asm/arch-ls102xa/soc.h
>@@ -0,0 +1,6 @@
>+/* SPDX-License-Identifier: GPL-2.0+ */
>+/*
>+ * Copyright 2019 NXP
>+ */
The file have existed before 2019. Please check git log and update accordingly
>+#define SVR_DEV(svr)  ((svr) >> 8)
Is this something ls102xa specific. Can't we make it generic?
>+
>--
>2.17.1
--priyankajain 


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

Re: [U-Boot] [PATCH v2] pci: layerscape: remove multiple definitions of SVR

[Priyanka Jain]

>-Original Message-
>From: Pankaj Bansal
>Sent: Wednesday, October 16, 2019 3:43 PM
>To: Priyanka Jain ; Xiaowei Bao
>; Tom Rini ; Z.q. Hou
>
>Cc: u-boot@lists.denx.de; Pankaj Bansal 
>Subject: [PATCH v2] pci: layerscape: remove multiple definitions of SVR
>
>SVR values for various nxp SOCs are defined in asm/arch/soc.h we can use
>these values in any peripheral driver.
>we need not to redefine these values in peripheral driver, as this becomes
>difficult to manage (add or change new values)
>
>Signed-off-by: Pankaj Bansal 
>---
>
>Notes:
>V2:
>- fixed compilation errors in LS1021A based targets by adding SVR checking
>  for layerscape series SOCs under LAYERSCAPE Macro.
>[Dependencies]
>- https://patchwork.ozlabs.org/patch/1177732/
>
> drivers/pci/pcie_layerscape.c   | 18 --
> drivers/pci/pcie_layerscape.h   |  9 +
> drivers/pci/pcie_layerscape_fixup.c | 16 ++--
> 3 files changed, 23 insertions(+), 20 deletions(-)
>
>diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c 
>index
>5ad7c28773..12357127a8 100644
>--- a/drivers/pci/pcie_layerscape.c
>+++ b/drivers/pci/pcie_layerscape.c
>@@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
>- * Copyright 2017 NXP
>+ * Copyright 2017, 2019 NXP
Were there changes in this file in 2018? If yes, please update to 2017-2019
>  * Copyright 2014-2015 Freescale Semiconductor, Inc.
>  * Layerscape PCIe driver
>  */
>@@ -15,6 +15,7 @@
> #if defined(CONFIG_FSL_LSCH2) || defined(CONFIG_FSL_LSCH3) || \
>   defined(CONFIG_ARM)
> #include 
>+#include 
> #endif
> #include "pcie_layerscape.h"
>
>@@ -56,7 +57,7 @@ static int ls_pcie_ltssm(struct ls_pcie *pcie)
>   uint svr;
>
>   svr = get_svr();
>-  if (((svr >> SVR_VAR_PER_SHIFT) & SVR_LS102XA_MASK) ==
>SVR_LS102XA) {
>+  if ((SVR_DEV(svr) & SVR_LS102XA_MASK) == SVR_LS102XA) {
Is "SVR_LS102XA_MASK" LS102XA specific? Can we make it generic across other 
SoCs?

>   state = ctrl_readl(pcie, LS1021_PEXMSCPORTSR(pcie->idx));
>   state = (state >> LS1021_LTSSM_STATE_SHIFT) &
>LTSSM_STATE_MASK;
>   } else {
>@@ -149,7 +150,7 @@ static void ls_pcie_setup_atu(struct ls_pcie *pcie)
>   uint svr;
>
>   svr = get_svr();
>-  if (((svr >> SVR_VAR_PER_SHIFT) & SVR_LS102XA_MASK) ==
>SVR_LS102XA) {
>+  if ((SVR_DEV(svr) & SVR_LS102XA_MASK) == SVR_LS102XA) {
Same as above
>   offset = LS1021_PCIE_SPACE_OFFSET +
>LS1021_PCIE_SPACE_SIZE * pcie->idx;
>   }
>@@ -172,7 +173,8 @@ static void ls_pcie_setup_atu(struct ls_pcie *pcie)
>   idx = PCIE_ATU_REGION_INDEX1 + 1;
>
>   /* Fix the pcie memory map for LS2088A series SoCs */
>-  svr = (svr >> SVR_VAR_PER_SHIFT) & 0xFE;
>+#if defined(CONFIG_FSL_LAYERSCAPE)
>+  svr = SVR_SOC_VER(svr);
Please confirm that svr vaue is used only inside "CONFIG_FSL_LAYERSCAPE"
>   if (svr == SVR_LS2088A || svr == SVR_LS2084A ||
>   svr == SVR_LS2048A || svr == SVR_LS2044A ||
>   svr == SVR_LS2081A || svr == SVR_LS2041A) { @@ -192,6 +194,7
>@@ static void ls_pcie_setup_atu(struct ls_pcie *pcie)
>LS2088A_PCIE1_PHYS_ADDR +
>LS2088A_PCIE_PHYS_SIZE * pcie->idx;
>   }
>+#endif /* CONFIG_FSL_LAYERSCAPE */
>
>   if (io)
>   /* ATU : OUTBOUND : IO */
>@@ -446,9 +449,7 @@ static int ls_pcie_probe(struct udevice *dev)
>   const void *fdt = gd->fdt_blob;
>   int node = dev_of_offset(dev);
>   u16 link_sta;
>-  uint svr;
>   int ret;
>-  fdt_size_t cfg_size;
>
>   pcie->bus = dev;
>
>@@ -501,6 +502,10 @@ static int ls_pcie_probe(struct udevice *dev)
>   return ret;
>   }
>
>+#if defined(CONFIG_FSL_LAYERSCAPE)
>+  uint svr;
>+  fdt_size_t cfg_size;
>+
As per u-boot coding style the preference, is to define variables in start of 
function
>   /*
>* Fix the pcie memory map address and PF control registers address
>* for LS2088A series SoCs
>@@ -516,6 +521,7 @@ static int ls_pcie_probe(struct udevice *dev)
>   pcie->cfg_res.end = pcie->cfg_res.start + cfg_size;
>   pcie->ctrl = pcie->lut + 0x4;
>   }
>+#endif /* CONFIG_FSL_LAYERSCAPE */
>
>   pcie->cfg0 = map_physmem(pcie->cfg_res.start,
>fdt_resource_size(>cfg_res),
>diff --git a/drivers/pci/pcie_layerscape.h b/drivers/pci/pcie_layerscape.h 
>index
>ddfbba6538..9a19993568 100644
>--- a/drivers/pci/pcie_layerscape.h
>+++ b/drivers/pci/pcie_layerscape.h
>@@ -1,6 +1,6 @@
> /* SPDX-License-Identifier: GPL-2.0+ */
> /*
>- * Copyright 2017 NXP
>+ * Copyright 2017, 2019 NXP
Same as above
>  * Copyright 2014-2015 Freescale Semiconductor, Inc.
>  * Layerscape PCIe driver
>  */
>@@ -111,14 +111,7 @@
> #define PCIE_CS2_OFFSET   0x1000 /* For PCIe without SR-IOV */
>
> #define SVR_LS102XA   0
>-#define 

[U-Boot] [PATCH 1/2] armv8: dts: ls1088a: add PSCI binding for LS1088A

[Mathew McBride]

This allows the use of PSCI calls to trusted firmware to
initiate reset and poweroff events with CONFIG_PSCI_RESET and
CONFIG_ARM_PSCI_FW. This is desirable, for example, if the target
board has implemented a custom reset or poweroff procedure in EL3.

Signed-off-by: Mathew McBride 
Cc: Priyanka Jain 
---
 arch/arm/dts/fsl-ls1088a.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/dts/fsl-ls1088a.dtsi b/arch/arm/dts/fsl-ls1088a.dtsi
index 4be1ab87d2..abc8b21a11 100644
--- a/arch/arm/dts/fsl-ls1088a.dtsi
+++ b/arch/arm/dts/fsl-ls1088a.dtsi
@@ -192,4 +192,9 @@
status = "disabled";
};
 
+   psci {
+   compatible = "arm,psci-0.2";
+   method = "smc";
+   };
+
 };
-- 
2.19.1

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

[U-Boot] [PATCH 2/2] armv8: fsl-layerscape: do not use layerscape EFI reset if PSCI used

[Mathew McBride]

If the secure world reset handlers are used (via CONFIG_PSCI_RESET),
then do not use the layerscape-specific implementation.

Signed-off-by: Mathew McBride 
Cc: Priyanka Jain 
---
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index a5d0b5370f..b4012793fd 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -1218,7 +1218,7 @@ void __efi_runtime reset_cpu(ulong addr)
 #endif
 }
 
-#ifdef CONFIG_EFI_LOADER
+#if defined(CONFIG_EFI_LOADER) && !defined(CONFIG_PSCI_RESET)
 
 void __efi_runtime EFIAPI efi_reset_system(
   enum efi_reset_type reset_type,
-- 
2.19.1

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

[U-Boot] [PATCH 0/2] armv8: fsl-layerscape: Allow use of PSCI handlers for ls1088a

[Mathew McBride]

This patch allows the use of PSCI for power operations - this is
desirable if the target board has implemented it's own power operation
handlers in Trusted Firmware/EL3.

Layerscape has it's own EFI service handlers for power operations - if
PSCI is used the generic handlers will be used instead.

Note that all of the existing Layerscape boards in-tree are blacklisted
from PSCI_RESET by default - to use this you must enable it for your
board.

Mathew McBride (2):
  armv8: dts: ls1088a: add PSCI binding for LS1088A
  armv8: fsl-layerscape: do not use layerscape EFI reset if PSCI used

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 2 +-
 arch/arm/dts/fsl-ls1088a.dtsi   | 5 +
 2 files changed, 6 insertions(+), 1 deletion(-)

-- 
2.19.1

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

Re: [U-Boot] [PATCH v2 14/38] spi: Add support for memory-mapped flash

[Bin Meng]

Hi Simon,

On Fri, Oct 18, 2019 at 10:22 AM Simon Glass  wrote:
>
> Hi,
>
> On Thu, 17 Oct 2019 at 08:28, Simon Glass  wrote:
> >
> > Hi Vignesh,
> >
> > On Wed, 16 Oct 2019 at 04:28, Vignesh Raghavendra  wrote:
> > >
> > > Hi Simon,
> > >
> > > On 12/10/19 10:03 AM, Bin Meng wrote:
> > > > Hi Simon,
> > > >
> > > > On Sat, Oct 12, 2019 at 11:08 AM Simon Glass  wrote:
> > > >>
> > > >> Hi Bin,
> > > >>
> > > >> On Wed, 9 Oct 2019 at 07:55, Bin Meng  wrote:
> > > >>>
> > > >>> Hi Simon,
> > > >>>
> > > >>> On Wed, Sep 25, 2019 at 10:12 PM Simon Glass  
> > > >>> wrote:
> > > 
> > >  On x86 platforms the SPI flash can be mapped into memory so that the
> > >  contents can be read with normal memory accesses.
> > > 
> > >  Add a new SPI flash method to find the location of the SPI flash in
> > >  memory. This differs from the existing device-tree "memory-map" 
> > >  mechanism
> > >  in that the location can be discovered at run-time.
> > > 
> > >
> > > Whats is the usecase? Why can't spi_flash_read() be used instead?
> > > Flash + Controller driver can underneath take care of using memory
> > > mapped mode to read data from flash right while making sure that access
> > > is within valid window?
> >
> > I can see spi_flash_read_dm() but it does not support returning a
> > pointer to the data, only reading it.
> >
> > Also I cannot find any documentation about any of this. I've been
> > looking in the doc/ directory.
> >
> > I found the spi_mem.h file but it doesn't mention the meaning of the
> > in and out buffer pointers so I don't know how to use them.
> >
> > Is there an API missing or just comments/documentation?
>
> Apart from this I have found that the ich_spi driver does not work for
> APL since it apparently only supports 'hardware sequencing'. I did try
> getting software sequencing to work, but no dice.
>
> In addition, I found that enabling SPI flash, etc. added about 6KB of code!
>
> So I think it might be best to have two SPI drivers for x86 - one for
> software sequencing and one for hardware?

So if this is true, I think we can create Kconfig options (HW_SEQ and
SW_SEQ) for ICH SPI driver, and select either one in the SoC Kconfig
file.

But I see from the Linux kernel driver, it has:

300static int intel_spi_init(struct intel_spi *ispi)
301{
302u32 opmenu0, opmenu1, lvscc, uvscc, val;
303int i;
304
305switch (ispi->info->type) {
306case INTEL_SPI_BYT:
307ispi->sregs = ispi->base + BYT_SSFSTS_CTL;
308ispi->pregs = ispi->base + BYT_PR;
309ispi->nregions = BYT_FREG_NUM;
310ispi->pr_num = BYT_PR_NUM;
311ispi->swseq_reg = true;
312
313if (writeable) {
314/* Disable write protection */
315val = readl(ispi->base + BYT_BCR);
316if (!(val & BYT_BCR_WPD)) {
317val |= BYT_BCR_WPD;
318writel(val, ispi->base + BYT_BCR);
319val = readl(ispi->base + BYT_BCR);
320}
321
322ispi->writeable = !!(val & BYT_BCR_WPD);
323}
324
325break;
326
327case INTEL_SPI_LPT:
328ispi->sregs = ispi->base + LPT_SSFSTS_CTL;
329ispi->pregs = ispi->base + LPT_PR;
330ispi->nregions = LPT_FREG_NUM;
331ispi->pr_num = LPT_PR_NUM;
332ispi->swseq_reg = true;
333break;
334
335case INTEL_SPI_BXT:
336ispi->sregs = ispi->base + BXT_SSFSTS_CTL;
337ispi->pregs = ispi->base + BXT_PR;
338ispi->nregions = BXT_FREG_NUM;
339ispi->pr_num = BXT_PR_NUM;
340ispi->erase_64k = true;
341break;

So for INTEL_SPI_BXT (which is for ApolloLake I believe)
ispi->swseq_reg is not set to true which means it uses hardware
sequencer, which seems to contradict with what you found.

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

Re: [U-Boot] [PATCH v2 14/38] spi: Add support for memory-mapped flash

[Simon Glass]

Hi,

On Thu, 17 Oct 2019 at 08:28, Simon Glass  wrote:
>
> Hi Vignesh,
>
> On Wed, 16 Oct 2019 at 04:28, Vignesh Raghavendra  wrote:
> >
> > Hi Simon,
> >
> > On 12/10/19 10:03 AM, Bin Meng wrote:
> > > Hi Simon,
> > >
> > > On Sat, Oct 12, 2019 at 11:08 AM Simon Glass  wrote:
> > >>
> > >> Hi Bin,
> > >>
> > >> On Wed, 9 Oct 2019 at 07:55, Bin Meng  wrote:
> > >>>
> > >>> Hi Simon,
> > >>>
> > >>> On Wed, Sep 25, 2019 at 10:12 PM Simon Glass  wrote:
> > 
> >  On x86 platforms the SPI flash can be mapped into memory so that the
> >  contents can be read with normal memory accesses.
> > 
> >  Add a new SPI flash method to find the location of the SPI flash in
> >  memory. This differs from the existing device-tree "memory-map" 
> >  mechanism
> >  in that the location can be discovered at run-time.
> > 
> >
> > Whats is the usecase? Why can't spi_flash_read() be used instead?
> > Flash + Controller driver can underneath take care of using memory
> > mapped mode to read data from flash right while making sure that access
> > is within valid window?
>
> I can see spi_flash_read_dm() but it does not support returning a
> pointer to the data, only reading it.
>
> Also I cannot find any documentation about any of this. I've been
> looking in the doc/ directory.
>
> I found the spi_mem.h file but it doesn't mention the meaning of the
> in and out buffer pointers so I don't know how to use them.
>
> Is there an API missing or just comments/documentation?

Apart from this I have found that the ich_spi driver does not work for
APL since it apparently only supports 'hardware sequencing'. I did try
getting software sequencing to work, but no dice.

In addition, I found that enabling SPI flash, etc. added about 6KB of code!

So I think it might be best to have two SPI drivers for x86 - one for
software sequencing and one for hardware?

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

Re: [U-Boot] [PATCH 5/5] doc: Add documentation for how to build U-Boot host tools

[Bin Meng]

Hi Tom,

On Thu, Oct 17, 2019 at 11:12 PM Tom Rini  wrote:
>
> On Thu, Oct 17, 2019 at 11:02:47PM +0800, Bin Meng wrote:
> > Hi Tom,
> >
> > On Thu, Oct 17, 2019 at 10:10 PM Tom Rini  wrote:
> > >
> > > On Thu, Oct 17, 2019 at 09:50:57AM +0800, Bin Meng wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, Oct 17, 2019 at 2:20 AM Tom Rini  wrote:
> > > > >
> > > > > On Wed, Oct 16, 2019 at 09:27:25AM -0700, Bin Meng wrote:
> > > > >
> > > > > > This adds a reST document for how to build U-Boot host tools,
> > > > > > including information for both Linux and Windows.
> > > > > >
> > > > > > Signed-off-by: Bin Meng 
> > > > >
> > > > > So here's where I think things get interesting.  Off the top of my 
> > > > > head,
> > > > > I think we can use the free GitLab.com-provided hosts of which there 
> > > > > are
> > > > > Windows-based ones (we would need to do some labeling of jobs so that
> > > > > most things only run on our Linux hosts but one job runs on the 
> > > > > Windows
> > > > > infra).  I'm less sure we can do such a matrix with Travis.  But is
> > > > > there some way we could get this Windows tool build into CI and thus
> > > > > keep it from breaking in the future?  Thanks!
> > > >
> > > > Yes, I would like to have GitLab CI to do the Windows build for us.
> > > > However I did not find the free GitLab.com-provided hosts. Any hints?
> > >
> > > Yeah, OK, I was wrong.  You have to be on gitlab.com and they don't have
> > > Windows.  And I don't know enough Windows to figure out how to automate
> > > going from a Microsoft-provided free VirtualBox image to having that
> > > have GitLab Runner also installed.
> >
> > Ah that's bad we can't find a GitLab hosted free Windows VM.
> >
> > So I looked at Microsoft Azure pipeline and it looks we can set up a
> > free account for U-Boot.
> > See 
> > https://azure.microsoft.com/en-us/blog/announcing-azure-pipelines-with-unlimited-ci-cd-minutes-for-open-source/
>
> That's interesting.  Would you mind trying to get something going with
> that?  Maybe long term we can use that as an alternative to travis too.

Sure, I will give a try.

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

Re: [U-Boot] [PATCH v3] arm: add initial support for the Phytium Durian Board

[Tom Rini]

On Thu, Oct 17, 2019 at 02:05:05PM +, liu hao wrote:

> This adds platform code and the device tree for the Phytium Durian Board.
> The initial support comprises the UART the GMAC and the PCIE.
> 
> v3:
> - Change the board name from ft2004 to durian.
>   The dts does not on mainline Kernel. @ Kever Yang
> - Add pcie driver and boot kernel from scsi-pci card.
>   Add README about durian board.
>   The system initialization is worked in BPF that
>   we do not want to open source.
>   But the hex file can be gitted referring to the board README. @Tom
> 
> v2:
> - Some printf() are removed or replaced by debug(). @Tom
> - The ft2004_defconfig file is generated with savedefconfig.
>   @Tom, @Heinrich
> 
> Cc: Kever Yang 
> Cc: Tom Rini 
> Cc: Heinrich Schuchardt 
> 
> Signed-off-by: Steven Hao 

Reviewed-by: Tom Rini 

-- 
Tom


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

[U-Boot] [PATCH] Enable building of u-boot.itb on Rockchip RK3328 platforms.

[Vagrant Cascadian]

The instructions in doc/README.rockchip for installing rock64-rk3328
make use of u-boot.itb, but it is not built by default.

Add u-boot.itb to BUILD_TARGET for RK3328 platforms.

Signed-off-by: Vagrant Cascadian 
---

 Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Kconfig b/Kconfig
index 66b059f749..16491de83d 100644
--- a/Kconfig
+++ b/Kconfig
@@ -253,7 +253,7 @@ config BUILD_TARGET
default "u-boot-spl.kwb" if ARCH_MVEBU && SPL
default "u-boot-elf.srec" if RCAR_GEN3
default "u-boot.itb" if SPL_LOAD_FIT && (ROCKCHIP_RK3399 || \
-   ARCH_SUNXI || RISCV)
+   ARCH_SUNXI || RISCV || ROCKCHIP_RK3328)
default "u-boot.kwb" if KIRKWOOD
default "u-boot-with-spl.bin" if ARCH_AT91 && SPL_NAND_SUPPORT
default "u-boot-with-spl.imx" if ARCH_MX6 && SPL
-- 
2.20.1

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

[U-Boot] [PATCH v3 5/5] doc: boards: Add rockchip documentation

[Jagan Teki]

Rockchip has documentation file, doc/README.rockchip but
which is not so readable to add or understand the existing
contents. Even the format that support is legacy readme
in U-Boot.

Add rockchip specific documentation file using new rst
format, which describes the information about Rockchip
supported boards and it's usage steps.

Added minimal information about rk3288, rk3328, rk3368
and rk3399 boards and usage. This would indeed updated
further based on the requirements and updates.

Cc: Kever Yang 
Cc: Matwey V. Kornilov 
Signed-off-by: Jagan Teki 
---
 doc/board/rockchip/index.rst|  10 +++
 doc/board/rockchip/rockchip.rst | 125 
 2 files changed, 135 insertions(+)
 create mode 100644 doc/board/rockchip/index.rst
 create mode 100644 doc/board/rockchip/rockchip.rst

diff --git a/doc/board/rockchip/index.rst b/doc/board/rockchip/index.rst
new file mode 100644
index 00..0c377e9bbb
--- /dev/null
+++ b/doc/board/rockchip/index.rst
@@ -0,0 +1,10 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (C) 2019 Jagan Teki 
+
+Rockchip
+
+
+.. toctree::
+   :maxdepth: 2
+
+   rockchip
diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst
new file mode 100644
index 00..782a0f1c7a
--- /dev/null
+++ b/doc/board/rockchip/rockchip.rst
@@ -0,0 +1,125 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (C) 2019 Jagan Teki 
+
+ROCKCHIP
+
+
+About this
+--
+
+This document describes the information about Rockchip supported boards
+and it's usage steps.
+
+Rockchip boards
+---
+
+Rockchip is SoC solutions provider for tablets & PCs, streaming media
+TV boxes, AI audio & vision, IoT hardware.
+
+A wide range of Rockchip SoCs with associated boardsare supported in
+mainline U-Boot.
+
+List of mainline supported rockchip boards:
+
+* rk3288
+ - Evb-RK3288
+ - Firefly-RK3288
+ - mqmaker MiQi
+ - Phytec RK3288 PCM-947
+ - PopMetal-RK3288
+ - Radxa Rock 2 Square
+ - Tinker-RK3288
+ - Google Jerry
+ - Google Mickey
+ - Google Minnie
+ - Google Speedy
+ - Amarula Vyasa-RK3288
+* rk3328
+ - Rockchip RK3328 EVB
+ - Pine64 Rock64
+* rk3368
+ - GeekBox
+ - PX5 EVB
+ - Rockchip sheep board
+ - Theobroma Systems RK3368-uQ7 SoM
+* rk3399
+ - 96boards RK3399 Ficus
+ - 96boards Rock960
+ - Firefly-RK3399 Board
+ - Firefly ROC-RK3399-PC Board
+ - FriendlyElec NanoPC-T4
+ - FriendlyElec NanoPi M4
+ - FriendlyARM NanoPi NEO4
+ - Google Bob
+ - Khadas Edge
+ - Khadas Edge-Captain
+ - Khadas Edge-V
+ - Orange Pi RK3399 Board
+ - Pine64 RockPro64
+ - Radxa ROCK Pi 4
+ - Rockchip RK3399 Evaluation Board
+ - Theobroma Systems RK3399-Q7 SoM
+
+Building
+
+
+TF-A
+
+
+TF-A would require to build for ARM64 Rockchip SoCs platforms.
+
+To build TF-A::
+
+git clone https://github.com/ARM-software/arm-trusted-firmware.git
+cd arm-trusted-firmware
+make realclean
+make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399
+
+Specify the PLAT= with desired rockchip platform to build TF-A for.
+
+U-Boot
+^^
+
+To build rk3328 boards::
+
+export BL31=/path/to/arm-trusted-firmware/to/bl31.elf
+make evb-rk3328_defconfig
+make
+
+To build rk3288 boards::
+
+make evb-rk3288_defconfig
+make
+
+To build rk3368 boards::
+
+export BL31=/path/to/arm-trusted-firmware/to/bl31.elf
+make evb-px5_defconfig
+make
+
+To build rk3399 boards::
+
+export BL31=/path/to/arm-trusted-firmware/to/bl31.elf
+make evb-rk3399_defconfig
+make
+
+SD Card Flashing
+
+
+To write an image that boots from an SD card (assumed to be /dev/sda):
+
+TPL + SPL::
+
+sudo dd if=u-boot-rockchip-with-tpl-spl.bin of=/dev/sda seek=64
+sync
+
+TODO
+
+
+- Add SPL-alone SD Card flashing steps
+- Add rockchip idbloader image building
+- Describe steps for eMMC flashing
+- Add missing SoC's with it boards list
+
+.. Jagan Teki 
+.. Thu Oct 17 22:36:14 IST 2019
-- 
2.18.0.321.gffc6fa0e3

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

[U-Boot] [PATCH v3 2/5] Makefile: Rename idbloader.img with u-boot-spl-rockchip.bin

[Jagan Teki]

idbloader.img name is specific to rockchip, where it usually
created using rockchip tools. Since the image is created as
per U-Boot generic builds like SPL, better to follow the
generic U-Boot naming notation like other SoC's following.

Enable idbloader.img with u-boot-spl-rockchip.bin and create
the same in spl directory since it is SPL file and Makefile.spl
will clean it by default.

Cc: Kever Yang 
Cc: Matwey V. Kornilov 
Signed-off-by: Jagan Teki 
---
 Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index ec55e0f6a4..918b5d53e0 100644
--- a/Makefile
+++ b/Makefile
@@ -887,7 +887,7 @@ ALL-y += u-boot-with-dtb.bin
 endif
 
 ifeq ($(CONFIG_ARCH_ROCKCHIP)$(CONFIG_SPL)$(CONFIG_TPL),yyy)
-ALL-y += idbloader.img
+ALL-y += spl/u-boot-spl-rockchip.bin
 endif
 
 LDFLAGS_u-boot += $(LDFLAGS_FINAL)
@@ -1344,7 +1344,7 @@ endif
 MKIMAGEFLAGS_u-boot-tpl.img = -n $(CONFIG_SYS_SOC) -T $(ROCKCHIP_IMG_TYPE)
 tpl/u-boot-tpl.img: tpl/u-boot-tpl.bin FORCE
$(call if_changed,mkimage)
-idbloader.img: tpl/u-boot-tpl.img spl/u-boot-spl.bin FORCE
+spl/u-boot-spl-rockchip.bin: tpl/u-boot-tpl.img spl/u-boot-spl.bin FORCE
$(call if_changed,cat)
 endif
 
-- 
2.18.0.321.gffc6fa0e3

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

[U-Boot] [PATCH v3 4/5] rockchip: Add Binman support

[Jagan Teki]

TPL-based rockchip platform like rk3288, rk3328, rk3368
and rk3399 has three stage boot loaders like TPL, SPL and
U-Boot proper. For each stage we need to burn the image
on to flash with respective offsets.

This patch create a single image using binman, so that
user can get rid of burning different stage boot images.

The new image called 'u-boot-rockchip-with-tpl-spl.bin'
which can burn into flash like:

₹ sudo dd if=u-boot-rockchip-with-tpl-spl.bin of=/dev/sda seek=64

This would easily extend if other rockchip family SoC's would
make use of single image creation.

Cc: Kever Yang 
Cc: Matwey V. Kornilov 
Signed-off-by: Jagan Teki 
---
 Makefile  | 10 ++
 arch/arm/Kconfig  |  1 +
 arch/arm/dts/rk3288-u-boot.dtsi   |  2 ++
 arch/arm/dts/rk3328-u-boot.dtsi   |  2 ++
 arch/arm/dts/rk3368-u-boot.dtsi   |  2 ++
 arch/arm/dts/rk3399-u-boot.dtsi   |  2 ++
 arch/arm/dts/rockchip-u-boot.dtsi | 21 +
 include/configs/rockchip-common.h |  2 ++
 8 files changed, 42 insertions(+)
 create mode 100644 arch/arm/dts/rockchip-u-boot.dtsi

diff --git a/Makefile b/Makefile
index 918b5d53e0..049781e0ba 100644
--- a/Makefile
+++ b/Makefile
@@ -888,6 +888,7 @@ endif
 
 ifeq ($(CONFIG_ARCH_ROCKCHIP)$(CONFIG_SPL)$(CONFIG_TPL),yyy)
 ALL-y += spl/u-boot-spl-rockchip.bin
+ALL-y += u-boot-rockchip-with-tpl-spl.bin
 endif
 
 LDFLAGS_u-boot += $(LDFLAGS_FINAL)
@@ -1346,6 +1347,15 @@ tpl/u-boot-tpl.img: tpl/u-boot-tpl.bin FORCE
$(call if_changed,mkimage)
 spl/u-boot-spl-rockchip.bin: tpl/u-boot-tpl.img spl/u-boot-spl.bin FORCE
$(call if_changed,cat)
+
+ifdef CONFIG_SPL_LOAD_FIT
+ROCKCHIP_UBOOT_IMG := u-boot.itb
+else
+ROCKCHIP_UBOOT_IMG := u-boot.img
+endif
+
+u-boot-rockchip-with-tpl-spl.bin: spl/u-boot-spl-rockchip.bin 
$(ROCKCHIP_UBOOT_IMG) FORCE
+   $(call if_changed,binman)
 endif
 
 ifeq ($(CONFIG_ARCH_LPC32XX)$(CONFIG_SPL),yy)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1df2aba3c2..87fa1f43f4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1594,6 +1594,7 @@ config ARCH_STM32MP
 config ARCH_ROCKCHIP
bool "Support Rockchip SoCs"
select BLK
+   select BINMAN if TPL && SPL
select DM
select DM_GPIO
select DM_I2C
diff --git a/arch/arm/dts/rk3288-u-boot.dtsi b/arch/arm/dts/rk3288-u-boot.dtsi
index 3f00a3b6d3..6d31735362 100644
--- a/arch/arm/dts/rk3288-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-u-boot.dtsi
@@ -3,6 +3,8 @@
  * Copyright (C) 2019 Rockchip Electronics Co., Ltd
  */
 
+#include "rockchip-u-boot.dtsi"
+
 / {
chosen {
u-boot,spl-boot-order = \
diff --git a/arch/arm/dts/rk3328-u-boot.dtsi b/arch/arm/dts/rk3328-u-boot.dtsi
index ffbd657e31..0c51a8dbfb 100644
--- a/arch/arm/dts/rk3328-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-u-boot.dtsi
@@ -3,6 +3,8 @@
  * (C) Copyright 2019 Rockchip Electronics Co., Ltd
  */
 
+#include "rockchip-u-boot.dtsi"
+
 / {
aliases {
mmc0 = 
diff --git a/arch/arm/dts/rk3368-u-boot.dtsi b/arch/arm/dts/rk3368-u-boot.dtsi
index 1e7d079315..41ac054b81 100644
--- a/arch/arm/dts/rk3368-u-boot.dtsi
+++ b/arch/arm/dts/rk3368-u-boot.dtsi
@@ -2,3 +2,5 @@
 /*
  * Copyright (C) 2019 Jagan Teki 
  */
+
+#include "rockchip-u-boot.dtsi"
diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
index 2738a3889e..fe8a73d653 100644
--- a/arch/arm/dts/rk3399-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -3,6 +3,8 @@
  * Copyright (C) 2019 Jagan Teki 
  */
 
+#include "rockchip-u-boot.dtsi"
+
  {
u-boot,dm-pre-reloc;
 };
diff --git a/arch/arm/dts/rockchip-u-boot.dtsi 
b/arch/arm/dts/rockchip-u-boot.dtsi
new file mode 100644
index 00..c496107119
--- /dev/null
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki 
+ */
+
+#include 
+
+/ {
+   binman {
+   filename = "u-boot-rockchip-with-tpl-spl.bin";
+   pad-byte = <0xff>;
+
+   blob {
+   filename = "spl/u-boot-spl-rockchip.bin";
+   };
+
+   u-boot-img {
+   offset = ;
+   };
+   };
+};
diff --git a/include/configs/rockchip-common.h 
b/include/configs/rockchip-common.h
index 68e1105a4b..d7f5ca9fa4 100644
--- a/include/configs/rockchip-common.h
+++ b/include/configs/rockchip-common.h
@@ -9,6 +9,8 @@
 
 #define CONFIG_SYS_NS16550_MEM32
 
+#define CONFIG_SPL_PAD_TO  8355840
+
 #ifndef CONFIG_SPL_BUILD
 
 /* First try to boot from SD (index 0), then eMMC (index 1) */
-- 
2.18.0.321.gffc6fa0e3

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

[U-Boot] [PATCH v3 3/5] arm: dts: rk3368: Add rk3368-u-boot.dtsi

[Jagan Teki]

Add U-Boot specific dtsi file for rk3368 SoC. This
would help to add U-Boot specific dts nodes, properties
which are common across rk3368.

Right now, the file is empty, will add required changes
in future patches.

Signed-off-by: Jagan Teki 
---
 arch/arm/dts/rk3368-geekbox-u-boot.dtsi | 2 ++
 arch/arm/dts/rk3368-lion-u-boot.dtsi| 2 ++
 arch/arm/dts/rk3368-px5-evb-u-boot.dtsi | 3 +++
 arch/arm/dts/rk3368-sheep-u-boot.dtsi   | 2 ++
 arch/arm/dts/rk3368-u-boot.dtsi | 4 
 5 files changed, 13 insertions(+)
 create mode 100644 arch/arm/dts/rk3368-u-boot.dtsi

diff --git a/arch/arm/dts/rk3368-geekbox-u-boot.dtsi 
b/arch/arm/dts/rk3368-geekbox-u-boot.dtsi
index 30ea9e433a..0b724fa45f 100644
--- a/arch/arm/dts/rk3368-geekbox-u-boot.dtsi
+++ b/arch/arm/dts/rk3368-geekbox-u-boot.dtsi
@@ -3,6 +3,8 @@
  * (C) Copyright 2017 Theobroma Systems Design und Consulting GmbH
  */
 
+#include "rk3368-u-boot.dtsi"
+
  {
u-boot,dm-pre-reloc;
 };
diff --git a/arch/arm/dts/rk3368-lion-u-boot.dtsi 
b/arch/arm/dts/rk3368-lion-u-boot.dtsi
index edc93e438f..5050d3dee8 100644
--- a/arch/arm/dts/rk3368-lion-u-boot.dtsi
+++ b/arch/arm/dts/rk3368-lion-u-boot.dtsi
@@ -3,6 +3,8 @@
  * (C) Copyright 2017 Theobroma Systems Design und Consulting GmbH
  */
 
+#include "rk3368-u-boot.dtsi"
+
 / {
config {
u-boot,spl-payload-offset = <0x4>; /* @ 256KB */
diff --git a/arch/arm/dts/rk3368-px5-evb-u-boot.dtsi 
b/arch/arm/dts/rk3368-px5-evb-u-boot.dtsi
index 002767a033..5fee02a65b 100644
--- a/arch/arm/dts/rk3368-px5-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3368-px5-evb-u-boot.dtsi
@@ -2,6 +2,9 @@
 /*
  * (C) Copyright 2017 Theobroma Systems Design und Consulting GmbH
  */
+
+#include "rk3368-u-boot.dtsi"
+
 / {
chosen {
u-boot,spl-boot-order = 
diff --git a/arch/arm/dts/rk3368-sheep-u-boot.dtsi 
b/arch/arm/dts/rk3368-sheep-u-boot.dtsi
index 30ea9e433a..0b724fa45f 100644
--- a/arch/arm/dts/rk3368-sheep-u-boot.dtsi
+++ b/arch/arm/dts/rk3368-sheep-u-boot.dtsi
@@ -3,6 +3,8 @@
  * (C) Copyright 2017 Theobroma Systems Design und Consulting GmbH
  */
 
+#include "rk3368-u-boot.dtsi"
+
  {
u-boot,dm-pre-reloc;
 };
diff --git a/arch/arm/dts/rk3368-u-boot.dtsi b/arch/arm/dts/rk3368-u-boot.dtsi
new file mode 100644
index 00..1e7d079315
--- /dev/null
+++ b/arch/arm/dts/rk3368-u-boot.dtsi
@@ -0,0 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki 
+ */
-- 
2.18.0.321.gffc6fa0e3

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

[U-Boot] [PATCH v3 1/5] Makefile: Add rockchip image type

[Jagan Teki]

Add rockchip image type support. right now the image
type marked with rksd, So create image type variable
with required image type like rksd or rkspi.

Cc: Kever Yang 
Cc: Matwey V. Kornilov 
Signed-off-by: Jagan Teki 
---
 Makefile | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 6fda3268e7..ec55e0f6a4 100644
--- a/Makefile
+++ b/Makefile
@@ -1334,7 +1334,14 @@ u-boot-with-spl.bin: $(SPL_IMAGE) $(SPL_PAYLOAD) FORCE
$(call if_changed,pad_cat)
 
 ifeq ($(CONFIG_ARCH_ROCKCHIP),y)
-MKIMAGEFLAGS_u-boot-tpl.img = -n $(CONFIG_SYS_SOC) -T rksd
+
+ifeq ($(CONFIG_SPI_FLASH_SUPPORT),y)
+ROCKCHIP_IMG_TYPE := rkspi
+else
+ROCKCHIP_IMG_TYPE := rksd
+endif
+
+MKIMAGEFLAGS_u-boot-tpl.img = -n $(CONFIG_SYS_SOC) -T $(ROCKCHIP_IMG_TYPE)
 tpl/u-boot-tpl.img: tpl/u-boot-tpl.bin FORCE
$(call if_changed,mkimage)
 idbloader.img: tpl/u-boot-tpl.img spl/u-boot-spl.bin FORCE
-- 
2.18.0.321.gffc6fa0e3

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

[U-Boot] [PATCH v3 0/5] rockchip: Add Binman support

[Jagan Teki]

This is v3 set for Binman support in rockchip, [1] here is
previous patchset.

This series add binman support for TPL-based targets, 
binman for SPL-alone boards add in future.

Changes for v3:
- rebase on master
- add binman for rk3288, rk3328, rk3368, rk3399
- added rst documentation for rockchip
Changes for v2:
- Add few clean target patches
- update bl31.elf env handling code, with logging
- support puma itb, via BL31 and PMUM0 env
- enable BUILD_TARGET for ROCKCHIP_RK3399
- add patch to build rockchip dtbs based on SoC types
- update binman patch

[1] http://patchwork.ozlabs.org/cover/1092198/

Any inputs?
Jagan.

Jagan Teki (5):
  Makefile: Add rockchip image type
  Makefile: Rename idbloader.img with u-boot-spl-rockchip.bin
  arm: dts: rk3368: Add rk3368-u-boot.dtsi
  rockchip: Add Binman support
  doc: boards: Add rockchip documentation

 Makefile|  23 -
 arch/arm/Kconfig|   1 +
 arch/arm/dts/rk3288-u-boot.dtsi |   2 +
 arch/arm/dts/rk3328-u-boot.dtsi |   2 +
 arch/arm/dts/rk3368-geekbox-u-boot.dtsi |   2 +
 arch/arm/dts/rk3368-lion-u-boot.dtsi|   2 +
 arch/arm/dts/rk3368-px5-evb-u-boot.dtsi |   3 +
 arch/arm/dts/rk3368-sheep-u-boot.dtsi   |   2 +
 arch/arm/dts/rk3368-u-boot.dtsi |   6 ++
 arch/arm/dts/rk3399-u-boot.dtsi |   2 +
 arch/arm/dts/rockchip-u-boot.dtsi   |  21 
 doc/board/rockchip/index.rst|  10 ++
 doc/board/rockchip/rockchip.rst | 125 
 include/configs/rockchip-common.h   |   2 +
 14 files changed, 200 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/dts/rk3368-u-boot.dtsi
 create mode 100644 arch/arm/dts/rockchip-u-boot.dtsi
 create mode 100644 doc/board/rockchip/index.rst
 create mode 100644 doc/board/rockchip/rockchip.rst

-- 
2.18.0.321.gffc6fa0e3

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

[U-Boot] [PATCH] clk: mediatek: use unsigned type for returning the clk rate

[Fabien Parent]

mtk_clk_find_parent_rate is calling clk_get_rate to know the rate
of a parent clock. clk_get_rate returns a ulong, while
mtk_clk_find_parent_rate returns an int. This implicit cast creates
an issue for clock rates big enough to need the full 32 bits to
store its data. When that happen the clk rate will become incorrect
because of the implicit cast between ulong -> int -> ulong.

This commit change the return type of mtk_clk_find_parent_rate to
ulong.

Signed-off-by: Fabien Parent 
---
 drivers/clk/mediatek/clk-mtk.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 6c6b500d9b71..c74766dd22c7 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -39,8 +39,8 @@
  * this function is recursively called to find the parent to calculate
  * the accurate frequency.
  */
-static int mtk_clk_find_parent_rate(struct clk *clk, int id,
-   const struct driver *drv)
+static ulong mtk_clk_find_parent_rate(struct clk *clk, int id,
+ const struct driver *drv)
 {
struct clk parent = { .id = id, };
 
-- 
2.23.0

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

Re: [U-Boot] [PATCH v3] arm: add initial support for the Phytium Durian Board

[Heinrich Schuchardt]

On 10/17/19 4:05 PM, liu hao wrote:

v3:
- Change the board name from ft2004 to durian.
   The dts does not on mainline Kernel. @ Kever Yang
- Add pcie driver and boot kernel from scsi-pci card.
   Add README about durian board.
   The system initialization is worked in BPF that
   we do not want to open source.
   But the hex file can be gitted referring to the board README. @Tom


Hello Hao,

for U-Boot this is fine.

Please, chmod 755 dopack in the https://github.com/phytium-durian/bpf
Git repository.

The ft-all.bin binary file seems to be based on the ARM Trusted
Firmware. Other companies like Marvell have opted to provide the ATF
source code and only keep BL2 closed source. This provides a bit more
flexibility.

Best regards

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

Re: [U-Boot] [PATCH] nvme: add more cache flushes

[J. William Campbell]

Hi All,
On 10/17/2019 12:12 AM, Patrick Wildt wrote:

On Thu, Oct 17, 2019 at 03:08:59PM +0800, Bin Meng wrote:

Hi Patrick,

On Thu, Oct 17, 2019 at 2:44 PM Patrick Wildt  wrote:

On Thu, Oct 17, 2019 at 10:55:11AM +0800, Bin Meng wrote:

Hi Patrick,

On Wed, Oct 16, 2019 at 11:35 PM Patrick Wildt  wrote:

On Wed, Oct 16, 2019 at 06:11:23PM +0800, Bin Meng wrote:

On Mon, Oct 14, 2019 at 7:11 PM Patrick Wildt  wrote:

On an i.MX8MQ our nvme driver doesn't completely work since we are
missing a few cache flushes.  One is the prp list, which is an extra
buffer that we need to flush before handing it to the hardware.  Also
the block read/write operations needs more cache flushes on this SoC.

Signed-off-by: Patrick Wildt 
---
  drivers/nvme/nvme.c | 15 +--
  1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index 2444e0270f..69d5e3eedc 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -123,6 +123,9 @@ static int nvme_setup_prps(struct nvme_dev *dev, u64 *prp2,
 }
 *prp2 = (ulong)dev->prp_pool;

+   flush_dcache_range((ulong)dev->prp_pool, (ulong)dev->prp_pool +
+  dev->prp_entry_num * sizeof(u64));
+
 return 0;
  }

@@ -717,9 +720,10 @@ static ulong nvme_blk_rw(struct udevice *udev, lbaint_t 
blknr,
 u16 lbas = 1 << (dev->max_transfer_shift - ns->lba_shift);
 u64 total_lbas = blkcnt;

-   if (!read)
-   flush_dcache_range((unsigned long)buffer,
-  (unsigned long)buffer + total_len);
+   flush_dcache_range((unsigned long)buffer,
+  (unsigned long)buffer + total_len);

Why we need this for read?

I'm no processor engineer, but I have read (and "seen") the following
on ARMs.  If I'm wrong. please correct me.

Since the buffer is usually allocated cache-aligned on the stack,
it is very possible that this buffer was previously still used
as it's supposed to be used: as stack.  Thus, the caches can still
be filled, and are not yet evicted/flushed to memory.  Now it is
possible that between the DMA access from the device and our cache
invalidation, the CPU cache writes back its contents to memory,
overwriting whatever the NVMe just gave us.

OK, this makes sense. So if we allocate the buffer from the heap, we
should only care about flush on write, right? Can you test this?

If you're talking about having a bounce buffer:  You'd need to flush
it once upon allocation, because that part of the heap could have also
be used earlier by someone else.


I was not talking about bounce buffer. I mean the buffer allocated
from help and use that directly for DMA.

Regards,
Bin

If you allocate a buffer from the heap, you still need to make sure
to flush it once, since there's still the chance that you have used
it shortly earlier.  But it's less of an issue as on the stack.


The "rules" for cache management of DMA buffers for non-cache-coherent 
CPUs are immutable. It doesn't matter where the memory came from 
(static, heap, or stack). It may be in cache, and it may be dirty. You 
can't know  it is for sure "clean". It is assumed that the DMA buffers 
are allocated to begin on a cache line boundary and are a multiple of a 
cache line in length. If this is not the case, references by the CPU to 
locations outside the buffer can make the cache state of the buffer 
dirty, which is an error. It is also required that there be no accesses 
to the DMA buffer by the CPU while DMA is in progress. This is normally 
true by default, and if it isn't true, it is an error. The rules are 
then as follows:


On write, before DMA is started. the cache corresponding to the DMA 
buffer addresses MUST be flushed to ensure the desired content is 
transferred from cache to RAM before write DMA begins.


On read, before DMA is started, the cache corresponding to the DMA 
buffer addresses MUST be either invalidated or flushed to ensure that no 
cache system initiated writes to RAM will occur while read DMA is in 
progress. Normally, invalidate is preferred because it is faster. 
However, for programming simplicity some drivers choose to flush before 
both read or write DMA is started. If that is the case, it is good 
practice to note that choice in a comment.


On write, after DMA is completed, no additional cache actions are required.

On read, after DMA is completed, the cache corresponding to the DMA 
buffer addresses MUST be invalidated. This is necessary to ensure that 
stale data in the cache will not be used instead of the new read data in 
RAM. If one elected to invalidate the cache before the read DMA started, 
one may wonder why a second invalidate is necessary.  Since the buffer 
is not allowed to be referenced by the program in the interim, the cache 
should not contain any data from the DMA buffer area. The reason is that 
modern CPUs, may load data from the DMA buffer into cache while DMA is 
in progress. This can 

Re: [U-Boot] [PATCH v1 00/11] import x509/pkcs7 parsers from linux

[Tom Rini]

On Tue, Oct 15, 2019 at 06:25:19PM +0900, AKASHI Takahiro wrote:
> On Tue, Oct 15, 2019 at 07:33:18AM +0200, Heinrich Schuchardt wrote:
> > On 10/15/19 5:18 AM, AKASHI Takahiro wrote:
> > >On Sat, Oct 12, 2019 at 03:02:09PM +0200, Heinrich Schuchardt wrote:
> > >>On 10/11/19 9:55 AM, AKASHI Takahiro wrote:
> > >>>I hope this patch set will be reviewed promptly as I'm aiming to
> > >>>push my "UEFI secure boot" patch for v2020.01.
> > >>>
> > >>
> > >>How can I make all of these new files being built to check for build
> > >>warnings?
> > >
> > >As always in my case of UEFI secure boot, they have gone through build and
> > >run/tests as part of UEFI secure boot. This is also true for RSA
> > >extension as UEFI secure boot is the only user of those features.
> > 
> > Did you run them through Travis?
> 
> As far as this patch set is concerned, no configuration enables
> any of kconfig options listed below and running Travis doesn't make sense.

That's a problem that needs to be fixed.  I am not OK with the idea of
adding a new feature that will not be put through our CI and so when
things break it (which will happen, inadvertently) it won't be caught
until much later.  Figuring out how to extend our CI to test this is a
must.  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 5/5] doc: Add documentation for how to build U-Boot host tools

[Tom Rini]

On Thu, Oct 17, 2019 at 11:02:47PM +0800, Bin Meng wrote:
> Hi Tom,
> 
> On Thu, Oct 17, 2019 at 10:10 PM Tom Rini  wrote:
> >
> > On Thu, Oct 17, 2019 at 09:50:57AM +0800, Bin Meng wrote:
> > > Hi Tom,
> > >
> > > On Thu, Oct 17, 2019 at 2:20 AM Tom Rini  wrote:
> > > >
> > > > On Wed, Oct 16, 2019 at 09:27:25AM -0700, Bin Meng wrote:
> > > >
> > > > > This adds a reST document for how to build U-Boot host tools,
> > > > > including information for both Linux and Windows.
> > > > >
> > > > > Signed-off-by: Bin Meng 
> > > >
> > > > So here's where I think things get interesting.  Off the top of my head,
> > > > I think we can use the free GitLab.com-provided hosts of which there are
> > > > Windows-based ones (we would need to do some labeling of jobs so that
> > > > most things only run on our Linux hosts but one job runs on the Windows
> > > > infra).  I'm less sure we can do such a matrix with Travis.  But is
> > > > there some way we could get this Windows tool build into CI and thus
> > > > keep it from breaking in the future?  Thanks!
> > >
> > > Yes, I would like to have GitLab CI to do the Windows build for us.
> > > However I did not find the free GitLab.com-provided hosts. Any hints?
> >
> > Yeah, OK, I was wrong.  You have to be on gitlab.com and they don't have
> > Windows.  And I don't know enough Windows to figure out how to automate
> > going from a Microsoft-provided free VirtualBox image to having that
> > have GitLab Runner also installed.
> 
> Ah that's bad we can't find a GitLab hosted free Windows VM.
> 
> So I looked at Microsoft Azure pipeline and it looks we can set up a
> free account for U-Boot.
> See 
> https://azure.microsoft.com/en-us/blog/announcing-azure-pipelines-with-unlimited-ci-cd-minutes-for-open-source/

That's interesting.  Would you mind trying to get something going with
that?  Maybe long term we can use that as an alternative to travis too.

-- 
Tom


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

Re: [U-Boot] [PATCH 5/5] doc: Add documentation for how to build U-Boot host tools

[Bin Meng]

Hi Tom,

On Thu, Oct 17, 2019 at 10:10 PM Tom Rini  wrote:
>
> On Thu, Oct 17, 2019 at 09:50:57AM +0800, Bin Meng wrote:
> > Hi Tom,
> >
> > On Thu, Oct 17, 2019 at 2:20 AM Tom Rini  wrote:
> > >
> > > On Wed, Oct 16, 2019 at 09:27:25AM -0700, Bin Meng wrote:
> > >
> > > > This adds a reST document for how to build U-Boot host tools,
> > > > including information for both Linux and Windows.
> > > >
> > > > Signed-off-by: Bin Meng 
> > >
> > > So here's where I think things get interesting.  Off the top of my head,
> > > I think we can use the free GitLab.com-provided hosts of which there are
> > > Windows-based ones (we would need to do some labeling of jobs so that
> > > most things only run on our Linux hosts but one job runs on the Windows
> > > infra).  I'm less sure we can do such a matrix with Travis.  But is
> > > there some way we could get this Windows tool build into CI and thus
> > > keep it from breaking in the future?  Thanks!
> >
> > Yes, I would like to have GitLab CI to do the Windows build for us.
> > However I did not find the free GitLab.com-provided hosts. Any hints?
>
> Yeah, OK, I was wrong.  You have to be on gitlab.com and they don't have
> Windows.  And I don't know enough Windows to figure out how to automate
> going from a Microsoft-provided free VirtualBox image to having that
> have GitLab Runner also installed.

Ah that's bad we can't find a GitLab hosted free Windows VM.

So I looked at Microsoft Azure pipeline and it looks we can set up a
free account for U-Boot.
See 
https://azure.microsoft.com/en-us/blog/announcing-azure-pipelines-with-unlimited-ci-cd-minutes-for-open-source/

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

Re: [U-Boot] [PATCH 16/37] i2c: add support for offset overflow in to address

[Robert Beckett]

On Tue, 2019-10-15 at 21:40 -0600, Simon Glass wrote:
> Hi Robert,
> 
> On Tue, 15 Oct 2019 at 09:55, Robert Beckett <
> bob.beck...@collabora.com> wrote:
> > Some devices (2 wire eeproms for example) use some bits from the
> > chip
> > address to represent the high bits of the offset instead of or as
> > well
> > as using multiple bytes for the offset, effectively stealing chip
> > addresses on the bus.
> > 
> > Add a chip offset mask that can be set for any i2c chip which gets
> > filled with the offset overflow during offset setup.
> > 
> > Signed-off-by: Robert Beckett 
> > Signed-off-by: Ian Ray 
> > ---
> >  drivers/i2c/i2c-uclass.c | 32 ++--
> >  include/i2c.h| 24 
> >  2 files changed, 50 insertions(+), 6 deletions(-)
> 
> Please can you update the i2c tests to cover this new feature?

Sure, will do.
Having looked at the i2c testing available in test/dm/i2c.c, I'm
struggling to see how the current tests are valid.
The changes in offset leng for 3 and 4 byte offsets don't set the
correct offset length in dm_test_i2c_offset.

Also, there is no visibility of the effect under test to verify the
correct behaviour. It seems to be relying on predictable offset mapping
in to an assumed 256 byte storage in drivers/misc/i2c_eeprom_emul.c,
but as long as the mapping is consistent between read and write, it
could be all sorts of wrong and the test would not show any issue.

Also there appears to be a bug in the loop for offset mapping, I think
it should be ">=", rather than ">". Currently wouldn't it overflow the
storage if an offset of 256 is used?

Am I missing something in how it is meant to work? If not, I can modify
the tests while I'm adding a new one for the new addressing mode, I
just wanted to check first.

Thanks for the review, Ill fix the rest up for v2.

> 
> > diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
> > index e47abf1833..7580867dc1 100644
> > --- a/drivers/i2c/i2c-uclass.c
> > +++ b/drivers/i2c/i2c-uclass.c
> > @@ -52,16 +52,19 @@ void i2c_dump_msgs(struct i2c_msg *msg, int
> > nmsgs)
> >  static int i2c_setup_offset(struct dm_i2c_chip *chip, uint offset,
> > uint8_t offset_buf[], struct i2c_msg
> > *msg)
> >  {
> > -   int offset_len;
> > +   int offset_len = chip->offset_len;
> > 
> > msg->addr = chip->chip_addr;
> > +   if (chip->chip_addr_offset_mask)
> > +   msg->addr |= (offset >> (8 * offset_len)) &
> > +   chip->chip_addr_offset_mask;
> > msg->flags = chip->flags & DM_I2C_CHIP_10BIT ? I2C_M_TEN :
> > 0;
> > msg->len = chip->offset_len;
> > msg->buf = offset_buf;
> > -   if (!chip->offset_len)
> > +   if (!offset_len)
> > return -EADDRNOTAVAIL;
> > -   assert(chip->offset_len <= I2C_MAX_OFFSET_LEN);
> > -   offset_len = chip->offset_len;
> > +   assert(offset_len <= I2C_MAX_OFFSET_LEN);
> > +
> > while (offset_len--)
> > *offset_buf++ = offset >> (8 * offset_len);
> > 
> > @@ -83,7 +86,7 @@ static int i2c_read_bytewise(struct udevice *dev,
> > uint offset,
> > if (i2c_setup_offset(chip, offset + i, offset_buf,
> > msg))
> > return -EINVAL;
> > ptr = msg + 1;
> > -   ptr->addr = chip->chip_addr;
> > +   ptr->addr = msg->addr;
> > ptr->flags = msg->flags | I2C_M_RD;
> > ptr->len = 1;
> > ptr->buf = [i];
> > @@ -132,6 +135,7 @@ int dm_i2c_read(struct udevice *dev, uint
> > offset, uint8_t *buffer, int len)
> > 
> > if (!ops->xfer)
> > return -ENOSYS;
> > +
> 
> Unrelated change
> 
> > if (chip->flags & DM_I2C_CHIP_RD_ADDRESS)
> > return i2c_read_bytewise(dev, offset, buffer, len);
> > ptr = msg;
> > @@ -139,7 +143,7 @@ int dm_i2c_read(struct udevice *dev, uint
> > offset, uint8_t *buffer, int len)
> > ptr++;
> > 
> > if (len) {
> > -   ptr->addr = chip->chip_addr;
> > +   ptr->addr = msg->addr;
> > ptr->flags = chip->flags & DM_I2C_CHIP_10BIT ?
> > I2C_M_TEN : 0;
> > ptr->flags |= I2C_M_RD;
> > ptr->len = len;
> > @@ -465,6 +469,22 @@ int i2c_get_chip_offset_len(struct udevice
> > *dev)
> > return chip->offset_len;
> >  }
> > 
> > +int i2c_set_chip_addr_offset_mask(struct udevice *dev, uint mask)
> > +{
> > +   struct dm_i2c_chip *chip = dev_get_parent_platdata(dev);
> > +
> > +   chip->chip_addr_offset_mask = mask;
> > +
> > +   return 0;
> > +}
> > +
> > +uint i2c_get_chip_addr_offset_mask(struct udevice *dev)
> > +{
> > +   struct dm_i2c_chip *chip = dev_get_parent_platdata(dev);
> > +
> > +   return chip->chip_addr_offset_mask;
> > +}
> > +
> >  #ifdef CONFIG_DM_GPIO
> >  static void i2c_gpio_set_pin(struct gpio_desc *pin, int bit)
> >  

Re: [U-Boot] [PATCH v2 14/38] spi: Add support for memory-mapped flash

[Simon Glass]

Hi Vignesh,

On Wed, 16 Oct 2019 at 04:28, Vignesh Raghavendra  wrote:
>
> Hi Simon,
>
> On 12/10/19 10:03 AM, Bin Meng wrote:
> > Hi Simon,
> >
> > On Sat, Oct 12, 2019 at 11:08 AM Simon Glass  wrote:
> >>
> >> Hi Bin,
> >>
> >> On Wed, 9 Oct 2019 at 07:55, Bin Meng  wrote:
> >>>
> >>> Hi Simon,
> >>>
> >>> On Wed, Sep 25, 2019 at 10:12 PM Simon Glass  wrote:
> 
>  On x86 platforms the SPI flash can be mapped into memory so that the
>  contents can be read with normal memory accesses.
> 
>  Add a new SPI flash method to find the location of the SPI flash in
>  memory. This differs from the existing device-tree "memory-map" mechanism
>  in that the location can be discovered at run-time.
> 
>
> Whats is the usecase? Why can't spi_flash_read() be used instead?
> Flash + Controller driver can underneath take care of using memory
> mapped mode to read data from flash right while making sure that access
> is within valid window?

I can see spi_flash_read_dm() but it does not support returning a
pointer to the data, only reading it.

Also I cannot find any documentation about any of this. I've been
looking in the doc/ directory.

I found the spi_mem.h file but it doesn't mention the meaning of the
in and out buffer pointers so I don't know how to use them.

Is there an API missing or just comments/documentation?

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

Re: [U-Boot] [PATCH 5/5] doc: Add documentation for how to build U-Boot host tools

[Tom Rini]

On Thu, Oct 17, 2019 at 09:50:57AM +0800, Bin Meng wrote:
> Hi Tom,
> 
> On Thu, Oct 17, 2019 at 2:20 AM Tom Rini  wrote:
> >
> > On Wed, Oct 16, 2019 at 09:27:25AM -0700, Bin Meng wrote:
> >
> > > This adds a reST document for how to build U-Boot host tools,
> > > including information for both Linux and Windows.
> > >
> > > Signed-off-by: Bin Meng 
> >
> > So here's where I think things get interesting.  Off the top of my head,
> > I think we can use the free GitLab.com-provided hosts of which there are
> > Windows-based ones (we would need to do some labeling of jobs so that
> > most things only run on our Linux hosts but one job runs on the Windows
> > infra).  I'm less sure we can do such a matrix with Travis.  But is
> > there some way we could get this Windows tool build into CI and thus
> > keep it from breaking in the future?  Thanks!
> 
> Yes, I would like to have GitLab CI to do the Windows build for us.
> However I did not find the free GitLab.com-provided hosts. Any hints?

Yeah, OK, I was wrong.  You have to be on gitlab.com and they don't have
Windows.  And I don't know enough Windows to figure out how to automate
going from a Microsoft-provided free VirtualBox image to having that
have GitLab Runner also installed.

-- 
Tom


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

[U-Boot] [PATCH v3] arm: add initial support for the Phytium Durian Board

[liu hao]

This adds platform code and the device tree for the Phytium Durian Board.
The initial support comprises the UART the GMAC and the PCIE.

v3:
- Change the board name from ft2004 to durian.
  The dts does not on mainline Kernel. @ Kever Yang
- Add pcie driver and boot kernel from scsi-pci card.
  Add README about durian board.
  The system initialization is worked in BPF that
  we do not want to open source.
  But the hex file can be gitted referring to the board README. @Tom

v2:
- Some printf() are removed or replaced by debug(). @Tom
- The ft2004_defconfig file is generated with savedefconfig.
  @Tom, @Heinrich

Cc: Kever Yang 
Cc: Tom Rini 
Cc: Heinrich Schuchardt 

Signed-off-by: Steven Hao 
---
 MAINTAINERS  |   7 ++
 arch/arm/Kconfig |   8 ++
 arch/arm/dts/Makefile|   2 +
 arch/arm/dts/phytium-durian.dts  |  45 +
 board/phytium/durian/Kconfig |  12 +++
 board/phytium/durian/MAINTAINERS |   8 ++
 board/phytium/durian/Makefile|   9 ++
 board/phytium/durian/README  |  65 +
 board/phytium/durian/cpu.h   |  23 +
 board/phytium/durian/durian.c| 110 +
 configs/durian_defconfig |  36 +++
 drivers/pci/Kconfig  |   7 ++
 drivers/pci/Makefile |   1 +
 drivers/pci/pcie_phytium.c   | 200 +++
 include/configs/durian.h |  44 +
 15 files changed, 577 insertions(+)
 create mode 100644 arch/arm/dts/phytium-durian.dts
 create mode 100644 board/phytium/durian/Kconfig
 create mode 100644 board/phytium/durian/MAINTAINERS
 create mode 100644 board/phytium/durian/Makefile
 create mode 100644 board/phytium/durian/README
 create mode 100644 board/phytium/durian/cpu.h
 create mode 100644 board/phytium/durian/durian.c
 create mode 100644 configs/durian_defconfig
 create mode 100644 drivers/pci/pcie_phytium.c
 create mode 100644 include/configs/durian.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 2ef2976..1ce7498 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -472,6 +472,13 @@ S: Maintained
 T: git https://gitlab.denx.de/u-boot/custodians/u-boot-microblaze.git
 F: arch/arm/mach-zynqmp-r5/
 
+ARM PHYTIUM
+M: liuhao 
+M: shuyiqi 
+S: Maintained
+F: drivers/pci/pcie_phytium.c
+F: arch/arm/dts/phytium-durian.dts
+
 BINMAN
 M: Simon Glass 
 S: Maintained
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1df2aba..2e2416b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1635,6 +1635,13 @@ config ARCH_ASPEED
select OF_CONTROL
imply CMD_DM
 
+config TARGET_DURIAN
+   bool "Support Phytium Durian Platform"
+   select ARM64
+   help
+ Support for durian platform.
+ It has 2GB Sdram, uart, gmac and pcie.
+
 endchoice
 
 config ARCH_SUPPORT_TFABOOT
@@ -1835,6 +1842,7 @@ source "board/woodburn/Kconfig"
 source "board/xilinx/Kconfig"
 source "board/xilinx/zynq/Kconfig"
 source "board/xilinx/zynqmp/Kconfig"
+source "board/phytium/durian/Kconfig"
 
 source "arch/arm/Kconfig.debug"
 
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 7d1de94..9336426 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -822,6 +822,8 @@ dtb-$(CONFIG_TARGET_VEXPRESS_CA5X2) += vexpress-v2p-ca5s.dtb
 dtb-$(CONFIG_TARGET_VEXPRESS_CA9X4) += vexpress-v2p-ca9.dtb
 dtb-$(CONFIG_TARGET_VEXPRESS_CA15_TC2) += vexpress-v2p-ca15_a7.dtb
 
+dtb-$(CONFIG_TARGET_DURIAN) += phytium-durian.dtb
+
 targets += $(dtb-y)
 
 # Add any required device tree compiler flags here
diff --git a/arch/arm/dts/phytium-durian.dts b/arch/arm/dts/phytium-durian.dts
new file mode 100644
index 000..811d50b
--- /dev/null
+++ b/arch/arm/dts/phytium-durian.dts
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019, Phytium Ltd.
+ * shuyiqi  
+ */
+
+/dts-v1/;
+
+/ {
+   model = "Phytium Durian";
+   compatible = "phytium,durian";
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   pcie-controller@4000 {
+   compatible = "phytium,pcie-host-1.0";
+   device_type = "pci";
+   #address-cells = <3>;
+   #size-cells = <2>;
+   reg = <0x0 0x4000 0x0 0x1000>;
+   bus-range = <0x0 0xff>;
+   ranges = <0x100 0x0 0x0 0x0 0x5000 0x0 0xF0>,
+   <0x200 0x0 0x5800 0x0 0x5800 0x0 0x2800>,
+   <0x4300 0x10 0x 0x10 0x 0x10  0x>;
+   };
+
+   ethernet@2820c000 {
+   compatible = "st,stm32-dwmac";
+   reg = <0x0 0x2820C000 0x0 0x2000>;
+   phy-mode = "rgmii";
+   };
+
+   ethernet@2821 {
+   compatible = "st,stm32-dwmac";
+   reg = <0x0 0x2821 0x0 0x2000>;
+   phy-mode = "rgmii";
+   };
+
+   uart@28001000 {
+   compatible = "arm,pl011";
+   reg = <0x0 

Re: [U-Boot] [PATCH 1/2] spi: cadence_qspi: Move to spi-mem framework

[Tudor.Ambarus]

Hi, Simon, Vignesh,

On 10/17/2019 02:20 PM, Simon Goldschmidt wrote:
> On Mon, Oct 14, 2019 at 3:27 PM Vignesh Raghavendra  wrote:
>> Current Cadence QSPI driver has few limitations. It assumes all read
>> operations to be in Quad mode and thus does not support SFDP parsing.
>> Also, adding support for new mode such as Octal mode would not be
>> possible with current configuration. Therefore move the driver over to 
>> spi-mem
>> framework. This has added advantage that driver can be used to support
>> SPI NAND memories too.
>> Hence, move driver over to new spi-mem APIs.
>>
>> Please note that this gets rid of mode bit setting done when
>> CONFIG_SPL_SPI_XIP is defined as there does not seem to be any user to
>> that config option.
> I just have tried this on an socfgpa cylone5 board with an mt25ql256a, but
> it does not seem to work: when leaving spi-rx-bus-width and spi-tx-bus-width
> at 4 in my devicetree, SFDP parsing works, but reading data afterwards
> produces invalid results (I haven't tested what's wrong there).
> 
> It works as expected when not parsing SFDP or setting the bus-width to 1.
> So the change itself probably works, but SFDP parsing is broken?

This can happen if the quad enable method is not correctly set/called. Would you
try the patch form below?

I don't see much benefit in having those guards, especially that we have
SPI_FLASH_SFDP_SUPPORT defined - it trims most of the SFDP logic.

More, these #ifdef guards are not scalable and with the addition of flashes that
support SFDP the #ifdefs will look uglier and uglier.

Cheers,
ta

diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index e5b9899c64b2..3002f97a7342 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -188,7 +188,6 @@ static int read_fsr(struct spi_nor *nor)
  * location. Return the configuration register value.
  * Returns negative if error occurred.
  */
-#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
 static int read_cr(struct spi_nor *nor)
 {
int ret;
@@ -202,7 +201,6 @@ static int read_cr(struct spi_nor *nor)

return val;
 }
-#endif

 /*
  * Write status register 1 byte
@@ -591,7 +589,6 @@ erase_err:
return ret;
 }

-#if defined(CONFIG_SPI_FLASH_STMICRO) || defined(CONFIG_SPI_FLASH_SST)
 /* Write status register and ensure bits in mask match written values */
 static int write_sr_and_check(struct spi_nor *nor, u8 status_new, u8 mask)
 {
@@ -877,7 +874,6 @@ static int stm_is_locked(struct spi_nor *nor, loff_t ofs,
uint64_t len)

return stm_is_locked_sr(nor, ofs, len, status);
 }
-#endif /* CONFIG_SPI_FLASH_STMICRO */

 static const struct flash_info *spi_nor_read_id(struct spi_nor *nor)
 {
@@ -1116,7 +1112,6 @@ write_err:
return ret;
 }

-#ifdef CONFIG_SPI_FLASH_MACRONIX
 /**
  * macronix_quad_enable() - set QE bit in Status Register.
  * @nor:   pointer to a 'struct spi_nor'
@@ -1153,9 +1148,7 @@ static int macronix_quad_enable(struct spi_nor *nor)

return 0;
 }
-#endif

-#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
 /*
  * Write status Register and configuration register with 2 bytes
  * The first byte will be written to the status register, while the
@@ -1269,7 +1262,6 @@ static int spansion_no_read_cr_quad_enable(struct spi_nor
*nor)
 }

 #endif /* CONFIG_SPI_FLASH_SFDP_SUPPORT */
-#endif /* CONFIG_SPI_FLASH_SPANSION */

 struct spi_nor_read_command {
u8  num_mode_clocks;
@@ -1787,22 +1779,16 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor,
case BFPT_DWORD15_QER_NONE:
params->quad_enable = NULL;
break;
-#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
case BFPT_DWORD15_QER_SR2_BIT1_BUGGY:
case BFPT_DWORD15_QER_SR2_BIT1_NO_RD:
params->quad_enable = spansion_no_read_cr_quad_enable;
break;
-#endif
-#ifdef CONFIG_SPI_FLASH_MACRONIX
case BFPT_DWORD15_QER_SR1_BIT6:
params->quad_enable = macronix_quad_enable;
break;
-#endif
-#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
case BFPT_DWORD15_QER_SR2_BIT1:
params->quad_enable = spansion_read_cr_quad_enable;
break;
-#endif
default:
return -EINVAL;
}
@@ -2013,20 +1999,16 @@ static int spi_nor_init_params(struct spi_nor *nor,
if (params->hwcaps.mask & (SNOR_HWCAPS_READ_QUAD |
   SNOR_HWCAPS_PP_QUAD)) {
switch (JEDEC_MFR(info)) {
-#ifdef CONFIG_SPI_FLASH_MACRONIX
case SNOR_MFR_MACRONIX:
params->quad_enable = macronix_quad_enable;
break;
-#endif
case SNOR_MFR_ST:
case SNOR_MFR_MICRON:
break;

default:
-#if 

Re: [U-Boot] [PATCH 3/3] pico-imx7d: polish uart clock id definition

[Stefano Babic]

On 16/10/19 16:57, Jun Nie wrote:
> Stefano Babic  于2019年10月13日周日 下午9:35写道：
>>
>> Hi Jun,
>>
>> I am just trying to check if some patch was silently lost, I found yours:
>>
>> On 16/07/19 09:42, Jun Nie wrote:
>>> Polish uart clock id definition. Default IMX7 UART ID is UART1
>>> as original parameter in imx_get_uartclk().
>>>
>>> Signed-off-by: Jun Nie 
>>> ---
>>>  arch/arm/include/asm/arch-mx7/clock.h | 18 +-
>>>  1 file changed, 1 insertion(+), 17 deletions(-)
>>>
>>> diff --git a/arch/arm/include/asm/arch-mx7/clock.h 
>>> b/arch/arm/include/asm/arch-mx7/clock.h
>>> index 1d07fde..a8e6097 100644
>>> --- a/arch/arm/include/asm/arch-mx7/clock.h
>>> +++ b/arch/arm/include/asm/arch-mx7/clock.h
>>> @@ -175,23 +175,7 @@ enum clk_root_index {
>>>   CLK_ROOT_MAX,
>>>  };
>>>
>>> -#if (CONFIG_CONS_INDEX == 0)
>>> -#define UART_CLK_ROOT UART1_CLK_ROOT
>>> -#elif (CONFIG_CONS_INDEX == 1)
>>> -#define UART_CLK_ROOT UART2_CLK_ROOT
>>> -#elif (CONFIG_CONS_INDEX == 2)
>>> -#define UART_CLK_ROOT UART3_CLK_ROOT
>>> -#elif (CONFIG_CONS_INDEX == 3)
>>> -#define UART_CLK_ROOT UART4_CLK_ROOT
>>> -#elif (CONFIG_CONS_INDEX == 4)
>>> -#define UART_CLK_ROOT UART5_CLK_ROOT
>>> -#elif (CONFIG_CONS_INDEX == 5)
>>> -#define UART_CLK_ROOT UART6_CLK_ROOT
>>> -#elif (CONFIG_CONS_INDEX == 6)
>>> -#define UART_CLK_ROOT UART7_CLK_ROOT
>>> -#else
>>> -#error "Invalid IMX UART ID for serial console is defined"
>>> -#endif
>>> +#define UART_CLK_ROOT (UART1_CLK_ROOT + CONFIG_CONS_INDEX)
>>>
>>>  struct clk_root_setting {
>>>   enum clk_root_index root;
>>>
>>
>> It looks ok but CONFIG_CONS_INDEX *must* be set, else it breaks boards.
>> Patch breaks at least the colibri boards.
>>
>> Best regards,
>> Stefano
> 
> Thanks for finding the bug! I will test more boards in next round.
> This patch is an independent optimization patch to other patches. So I
> will sumit next version later.

Ok, thanks !

Regards,
Stefano

> 
> Regards,
> Jun
> 


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: mxs: Increase VDDD voltage to match specification

[Fabio Estevam]

Hi Marek,

On Tue, Oct 15, 2019 at 1:27 PM Marek Vasut  wrote:
>
> According to IMX28CEC rev. 4, 10/2018, Table 15. Recommended Operating
> Conditions, page 16, the VDDD should be set to 1.55V when the CPU is
> operating at 454MHz. This is the case in U-Boot, hence increase the
> VDDD voltage. This fixes instability when performing TFTP transfers.
> Increase the brownout threshold to 1.4V. The documentation recommends
> 1.45V setting for the brownout, however, this triggers failure during
> power block init, so keep the brownout slightly lower.
>
> Signed-off-by: Marek Vasut 
> Cc: Stefano Babic 

Looks good, thanks:

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

Re: [U-Boot] [PATCH 2/2] spi: cadence-qspi: Add direct mode support

[Simon Goldschmidt]

On Thu, Oct 17, 2019 at 2:44 PM Vignesh Raghavendra  wrote:
>
> Hi,
>
> On 17/10/19 5:09 PM, Simon Goldschmidt wrote:
> > On Mon, Oct 14, 2019 at 3:27 PM Vignesh Raghavendra  wrote:
> >>
> >> Add support for Direct Access Controller mode of Cadence QSPI. This
> >> allows MMIO access to SPI NOR flash providing better read performance.
> >>
> >> Signed-off-by: Vignesh R 
> >> Signed-off-by: Vignesh Raghavendra 
> >
> > I've tested this on my socfpga cyclone5 board with an mt25ql256a (running at
> > 50MHz) and it seems to work fine.
> >
> > However, I had the impression it was a bit slower, not faster, although I
> > haven't measured, and running at 50MHz with 4 data lines, reading the whole
> > flash takes about 1.5 seconds only, so without actually measureing it, it's
> > hard to tell if this performance is really worth the 440 bytes of extra code
> > it adds?
> >
>
> I should have noted in the commit msg that direct mode is used only when
> AHB window is at least 8MB. Working with smaller window sizes would mean
> code would fall back to indirect mode most of the time.
> I see that socfgpa don't seem to have large AHB windows and therefore
> would not use direct access mode.

Aha. Yes, socfpga gen5 has a 1MB window only, I think. So the speed hasn't
changed.

>
> On TI platforms its possible to use DMA to read data from memory mapped
> region using mem to mem DMA channels which improves throughput by 5 times.

Hmm, I'm using a QSPI at 50 MHz and transferring 31 MByte takes about 1.5
seconds. The maximum speed of that setup would be 25 MByte/s without any
overhead (1.24 seconds for 31 MB). There's no way I could achieve an improvement
by 5 on my platform!

>
> > Note that I'm already short on RAM in SPL (socfpga gen5), so these 440 bytes
> > do hurt. Note that patch 1/2 of this series reduced SPL code size by 320 
> > bytes
> > for me :-)
> >
>
> Hmm, I read this as patch 1 brings down memory consumption by 320 bytes
> and patch 2 adds 440 bytes (delta being +120 bytes for entire series).
> I can see if size can be optimized, but would like to avoid #ifdef'ery
> within the driver if possible.

Well, I can only say I'm currently struggling to keep SPI-NOR and MMC enabled
at the same time in socfpga_socrates (moving more code to DM). And even if it
sounds like not much, 440 bytes *are* much for me at this point.

I still would prefer having a Kconfig option for this that can be disabled
for socfpga.

Regards,
Simon

>
> Regards
> Vignesh
>
> > Regards,
> > Simon
> >
> >
> >> ---
> >>  drivers/spi/cadence_qspi.c | 40 --
> >>  drivers/spi/cadence_qspi.h | 19 ++-
> >>  drivers/spi/cadence_qspi_apb.c | 61 +-
> >>  3 files changed, 87 insertions(+), 33 deletions(-)
> >>
> >> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> >> index 673a2e9a6c4c..6c98cbf39ae4 100644
> >> --- a/drivers/spi/cadence_qspi.c
> >> +++ b/drivers/spi/cadence_qspi.c
> >> @@ -12,12 +12,13 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include "cadence_qspi.h"
> >>
> >>  #define CQSPI_STIG_READ0
> >>  #define CQSPI_STIG_WRITE   1
> >> -#define CQSPI_INDIRECT_READ2
> >> -#define CQSPI_INDIRECT_WRITE   3
> >> +#define CQSPI_READ 2
> >> +#define CQSPI_WRITE3
> >>
> >>  static int cadence_spi_write_speed(struct udevice *bus, uint hz)
> >>  {
> >> @@ -189,6 +190,7 @@ static int cadence_spi_remove(struct udevice *dev)
> >>
> >>  static int cadence_spi_set_mode(struct udevice *bus, uint mode)
> >>  {
> >> +   struct cadence_spi_platdata *plat = bus->platdata;
> >> struct cadence_spi_priv *priv = dev_get_priv(bus);
> >>
> >> /* Disable QSPI */
> >> @@ -197,6 +199,10 @@ static int cadence_spi_set_mode(struct udevice *bus, 
> >> uint mode)
> >> /* Set SPI mode */
> >> cadence_qspi_apb_set_clk_mode(priv->regbase, mode);
> >>
> >> +   /* Enable Direct Access Controller */
> >> +   if (plat->use_dac_mode)
> >> +   cadence_qspi_apb_dac_mode_enable(priv->regbase);
> >> +
> >> /* Enable QSPI */
> >> cadence_qspi_apb_controller_enable(priv->regbase);
> >>
> >> @@ -221,12 +227,12 @@ static int cadence_spi_mem_exec_op(struct spi_slave 
> >> *spi,
> >> if (!op->addr.nbytes)
> >> mode = CQSPI_STIG_READ;
> >> else
> >> -   mode = CQSPI_INDIRECT_READ;
> >> +   mode = CQSPI_READ;
> >> } else {
> >> if (!op->addr.nbytes || !op->data.buf.out)
> >> mode = CQSPI_STIG_WRITE;
> >> else
> >> -   mode = CQSPI_INDIRECT_WRITE;
> >> +   mode = CQSPI_WRITE;
> >> }
> >>
> >> switch (mode) {
> >> @@ -236,19 +242,15 @@ static int cadence_spi_mem_exec_op(struct spi_slave 
> >> *spi,
> >>   

Re: [U-Boot] [PATCH 2/2] spi: cadence-qspi: Add direct mode support

[Vignesh Raghavendra]

Hi,

On 17/10/19 5:09 PM, Simon Goldschmidt wrote:
> On Mon, Oct 14, 2019 at 3:27 PM Vignesh Raghavendra  wrote:
>>
>> Add support for Direct Access Controller mode of Cadence QSPI. This
>> allows MMIO access to SPI NOR flash providing better read performance.
>>
>> Signed-off-by: Vignesh R 
>> Signed-off-by: Vignesh Raghavendra 
> 
> I've tested this on my socfpga cyclone5 board with an mt25ql256a (running at
> 50MHz) and it seems to work fine.
> 
> However, I had the impression it was a bit slower, not faster, although I
> haven't measured, and running at 50MHz with 4 data lines, reading the whole
> flash takes about 1.5 seconds only, so without actually measureing it, it's
> hard to tell if this performance is really worth the 440 bytes of extra code
> it adds?
> 

I should have noted in the commit msg that direct mode is used only when
AHB window is at least 8MB. Working with smaller window sizes would mean
code would fall back to indirect mode most of the time.
I see that socfgpa don't seem to have large AHB windows and therefore
would not use direct access mode.

On TI platforms its possible to use DMA to read data from memory mapped
region using mem to mem DMA channels which improves throughput by 5 times.

> Note that I'm already short on RAM in SPL (socfpga gen5), so these 440 bytes
> do hurt. Note that patch 1/2 of this series reduced SPL code size by 320 bytes
> for me :-)
> 

Hmm, I read this as patch 1 brings down memory consumption by 320 bytes
and patch 2 adds 440 bytes (delta being +120 bytes for entire series).
I can see if size can be optimized, but would like to avoid #ifdef'ery
within the driver if possible.

Regards
Vignesh

> Regards,
> Simon
> 
> 
>> ---
>>  drivers/spi/cadence_qspi.c | 40 --
>>  drivers/spi/cadence_qspi.h | 19 ++-
>>  drivers/spi/cadence_qspi_apb.c | 61 +-
>>  3 files changed, 87 insertions(+), 33 deletions(-)
>>
>> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
>> index 673a2e9a6c4c..6c98cbf39ae4 100644
>> --- a/drivers/spi/cadence_qspi.c
>> +++ b/drivers/spi/cadence_qspi.c
>> @@ -12,12 +12,13 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include "cadence_qspi.h"
>>
>>  #define CQSPI_STIG_READ0
>>  #define CQSPI_STIG_WRITE   1
>> -#define CQSPI_INDIRECT_READ2
>> -#define CQSPI_INDIRECT_WRITE   3
>> +#define CQSPI_READ 2
>> +#define CQSPI_WRITE3
>>
>>  static int cadence_spi_write_speed(struct udevice *bus, uint hz)
>>  {
>> @@ -189,6 +190,7 @@ static int cadence_spi_remove(struct udevice *dev)
>>
>>  static int cadence_spi_set_mode(struct udevice *bus, uint mode)
>>  {
>> +   struct cadence_spi_platdata *plat = bus->platdata;
>> struct cadence_spi_priv *priv = dev_get_priv(bus);
>>
>> /* Disable QSPI */
>> @@ -197,6 +199,10 @@ static int cadence_spi_set_mode(struct udevice *bus, 
>> uint mode)
>> /* Set SPI mode */
>> cadence_qspi_apb_set_clk_mode(priv->regbase, mode);
>>
>> +   /* Enable Direct Access Controller */
>> +   if (plat->use_dac_mode)
>> +   cadence_qspi_apb_dac_mode_enable(priv->regbase);
>> +
>> /* Enable QSPI */
>> cadence_qspi_apb_controller_enable(priv->regbase);
>>
>> @@ -221,12 +227,12 @@ static int cadence_spi_mem_exec_op(struct spi_slave 
>> *spi,
>> if (!op->addr.nbytes)
>> mode = CQSPI_STIG_READ;
>> else
>> -   mode = CQSPI_INDIRECT_READ;
>> +   mode = CQSPI_READ;
>> } else {
>> if (!op->addr.nbytes || !op->data.buf.out)
>> mode = CQSPI_STIG_WRITE;
>> else
>> -   mode = CQSPI_INDIRECT_WRITE;
>> +   mode = CQSPI_WRITE;
>> }
>>
>> switch (mode) {
>> @@ -236,19 +242,15 @@ static int cadence_spi_mem_exec_op(struct spi_slave 
>> *spi,
>> case CQSPI_STIG_WRITE:
>> err = cadence_qspi_apb_command_write(base, op);
>> break;
>> -   case CQSPI_INDIRECT_READ:
>> -   err = cadence_qspi_apb_indirect_read_setup(plat, op);
>> -   if (!err) {
>> -   err = cadence_qspi_apb_indirect_read_execute
>> -   (plat, op->data.nbytes, op->data.buf.in);
>> -   }
>> +   case CQSPI_READ:
>> +   err = cadence_qspi_apb_read_setup(plat, op);
>> +   if (!err)
>> +   err = cadence_qspi_apb_read_execute(plat, op);
>> break;
>> -   case CQSPI_INDIRECT_WRITE:
>> -   err = cadence_qspi_apb_indirect_write_setup(plat, op);
>> -   if (!err) {
>> -   err = cadence_qspi_apb_indirect_write_execute
>> -   (plat, op->data.nbytes, op->data.buf.out);
>> 

Re: [U-Boot] [PATCH 1/2] spi: cadence_qspi: Move to spi-mem framework

[Vignesh Raghavendra]

Hi Simon,

On 17/10/19 4:50 PM, Simon Goldschmidt wrote:
> On Mon, Oct 14, 2019 at 3:27 PM Vignesh Raghavendra  wrote:
>>
>> Current Cadence QSPI driver has few limitations. It assumes all read
>> operations to be in Quad mode and thus does not support SFDP parsing.
>> Also, adding support for new mode such as Octal mode would not be
>> possible with current configuration. Therefore move the driver over to 
>> spi-mem
>> framework. This has added advantage that driver can be used to support
>> SPI NAND memories too.
>> Hence, move driver over to new spi-mem APIs.
>>
>> Please note that this gets rid of mode bit setting done when
>> CONFIG_SPL_SPI_XIP is defined as there does not seem to be any user to
>> that config option.
> 
> I just have tried this on an socfgpa cylone5 board with an mt25ql256a, but
> it does not seem to work: when leaving spi-rx-bus-width and spi-tx-bus-width
> at 4 in my devicetree, SFDP parsing works, but reading data afterwards
> produces invalid results (I haven't tested what's wrong there).
> 

Thanks for testing!

spi-tx-bus-width = 4 was not supported before so I haven't added support
for that mode in this series. That change will be a separate series.

Could you try with spi-tx-bus-width = 1 and spi-rx-bus-width = 4 and see
if that works?

If that does not work then could you disable SFDP parsing (but keep
spi-rx-bus-width = 4) and see if that works. This should narrow down
whether SFDP parsing is broken or if driver has an issue.

Regards
Vignesh

> It works as expected when not parsing SFDP or setting the bus-width to 1.
> So the change itself probably works, but SFDP parsing is broken?
> 
> I did the tests with this applied first:
> https://patchwork.ozlabs.org/project/uboot/list/?series=135505
> 
> Regards,
> Simon
> 
> 
>>
>> Signed-off-by: Vignesh Raghavendra 
>> ---
>>  drivers/spi/cadence_qspi.c | 136 +
>>  drivers/spi/cadence_qspi.h |   9 +--
>>  drivers/spi/cadence_qspi_apb.c | 124 --
>>  3 files changed, 91 insertions(+), 178 deletions(-)
>>
>> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
>> index e2e54cd27723..673a2e9a6c4c 100644
>> --- a/drivers/spi/cadence_qspi.c
>> +++ b/drivers/spi/cadence_qspi.c
>> @@ -10,6 +10,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include "cadence_qspi.h"
>>
>> @@ -34,12 +35,21 @@ static int cadence_spi_write_speed(struct udevice *bus, 
>> uint hz)
>> return 0;
>>  }
>>
>> +static int cadence_spi_read_id(void *reg_base, u8 len, u8 *idcode)
>> +{
>> +   struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(0x9F, 1),
>> + SPI_MEM_OP_NO_ADDR,
>> + SPI_MEM_OP_NO_DUMMY,
>> + SPI_MEM_OP_DATA_IN(len, idcode, 
>> 1));
>> +
>> +   return cadence_qspi_apb_command_read(reg_base, );
>> +}
>> +
>>  /* Calibration sequence to determine the read data capture delay register */
>>  static int spi_calibration(struct udevice *bus, uint hz)
>>  {
>> struct cadence_spi_priv *priv = dev_get_priv(bus);
>> void *base = priv->regbase;
>> -   u8 opcode_rdid = 0x9F;
>> unsigned int idcode = 0, temp = 0;
>> int err = 0, i, range_lo = -1, range_hi = -1;
>>
>> @@ -53,8 +63,7 @@ static int spi_calibration(struct udevice *bus, uint hz)
>> cadence_qspi_apb_controller_enable(base);
>>
>> /* read the ID which will be our golden value */
>> -   err = cadence_qspi_apb_command_read(base, 1, _rdid,
>> -   3, (u8 *));
>> +   err = cadence_spi_read_id(base, 3, (u8 *));
>> if (err) {
>> puts("SF: Calibration failed (read)\n");
>> return err;
>> @@ -73,8 +82,7 @@ static int spi_calibration(struct udevice *bus, uint hz)
>> cadence_qspi_apb_controller_enable(base);
>>
>> /* issue a RDID to get the ID value */
>> -   err = cadence_qspi_apb_command_read(base, 1, _rdid,
>> -   3, (u8 *));
>> +   err = cadence_spi_read_id(base, 3, (u8 *));
>> if (err) {
>> puts("SF: Calibration failed (read)\n");
>> return err;
>> @@ -195,96 +203,56 @@ static int cadence_spi_set_mode(struct udevice *bus, 
>> uint mode)
>> return 0;
>>  }
>>
>> -static int cadence_spi_xfer(struct udevice *dev, unsigned int bitlen,
>> -   const void *dout, void *din, unsigned long flags)
>> +static int cadence_spi_mem_exec_op(struct spi_slave *spi,
>> +  const struct spi_mem_op *op)
>>  {
>> -   struct udevice *bus = dev->parent;
>> +   struct udevice *bus = spi->dev->parent;
>> struct cadence_spi_platdata *plat = bus->platdata;
>> struct cadence_spi_priv *priv = dev_get_priv(bus);
>> -   struct dm_spi_slave_platdata *dm_plat = 

Re: [U-Boot] [PATCH v2 2/3] ARM: imx: Fix bmode detection from grp10

[Fabio Estevam]

On Thu, Oct 17, 2019 at 5:52 AM Claudius Heine  wrote:
>
> imx6_is_bmode_from_gpr10 always returns false, because
> IMX6_SRC_GPR10_BMODE is 1<<28 and gets casted to u8 on return.
>
> This changes the return type to bool in order to cast correctly.
>
> Signed-off-by: Claudius Heine 

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

Re: [U-Boot] [PATCH 3/3] ARM: imx: Use IMX6_SRC_GPR10_BMODE instead of magic number

[Fabio Estevam]

On Wed, Oct 16, 2019 at 10:28 AM Claudius Heine  wrote:
>
> Signed-off-by: Claudius Heine 

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

Re: [U-Boot] [PATCH v2 1/3] ARM: imx: Rename imx6_is_bmode_from_gpr9 to imx6_is_bmode_from_gpr10

[Fabio Estevam]

On Thu, Oct 17, 2019 at 5:52 AM Claudius Heine  wrote:
>
> The only register used in that function is gpr10, which is used to store
> the flag. So naming it after this makes sense.
>
> Signed-off-by: Claudius Heine 

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

Re: [U-Boot] [PATCH 2/2] spi: cadence-qspi: Add direct mode support

[Simon Goldschmidt]

On Mon, Oct 14, 2019 at 3:27 PM Vignesh Raghavendra  wrote:
>
> Add support for Direct Access Controller mode of Cadence QSPI. This
> allows MMIO access to SPI NOR flash providing better read performance.
>
> Signed-off-by: Vignesh R 
> Signed-off-by: Vignesh Raghavendra 

I've tested this on my socfpga cyclone5 board with an mt25ql256a (running at
50MHz) and it seems to work fine.

However, I had the impression it was a bit slower, not faster, although I
haven't measured, and running at 50MHz with 4 data lines, reading the whole
flash takes about 1.5 seconds only, so without actually measureing it, it's
hard to tell if this performance is really worth the 440 bytes of extra code
it adds?

Note that I'm already short on RAM in SPL (socfpga gen5), so these 440 bytes
do hurt. Note that patch 1/2 of this series reduced SPL code size by 320 bytes
for me :-)

Regards,
Simon


> ---
>  drivers/spi/cadence_qspi.c | 40 --
>  drivers/spi/cadence_qspi.h | 19 ++-
>  drivers/spi/cadence_qspi_apb.c | 61 +-
>  3 files changed, 87 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> index 673a2e9a6c4c..6c98cbf39ae4 100644
> --- a/drivers/spi/cadence_qspi.c
> +++ b/drivers/spi/cadence_qspi.c
> @@ -12,12 +12,13 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "cadence_qspi.h"
>
>  #define CQSPI_STIG_READ0
>  #define CQSPI_STIG_WRITE   1
> -#define CQSPI_INDIRECT_READ2
> -#define CQSPI_INDIRECT_WRITE   3
> +#define CQSPI_READ 2
> +#define CQSPI_WRITE3
>
>  static int cadence_spi_write_speed(struct udevice *bus, uint hz)
>  {
> @@ -189,6 +190,7 @@ static int cadence_spi_remove(struct udevice *dev)
>
>  static int cadence_spi_set_mode(struct udevice *bus, uint mode)
>  {
> +   struct cadence_spi_platdata *plat = bus->platdata;
> struct cadence_spi_priv *priv = dev_get_priv(bus);
>
> /* Disable QSPI */
> @@ -197,6 +199,10 @@ static int cadence_spi_set_mode(struct udevice *bus, 
> uint mode)
> /* Set SPI mode */
> cadence_qspi_apb_set_clk_mode(priv->regbase, mode);
>
> +   /* Enable Direct Access Controller */
> +   if (plat->use_dac_mode)
> +   cadence_qspi_apb_dac_mode_enable(priv->regbase);
> +
> /* Enable QSPI */
> cadence_qspi_apb_controller_enable(priv->regbase);
>
> @@ -221,12 +227,12 @@ static int cadence_spi_mem_exec_op(struct spi_slave 
> *spi,
> if (!op->addr.nbytes)
> mode = CQSPI_STIG_READ;
> else
> -   mode = CQSPI_INDIRECT_READ;
> +   mode = CQSPI_READ;
> } else {
> if (!op->addr.nbytes || !op->data.buf.out)
> mode = CQSPI_STIG_WRITE;
> else
> -   mode = CQSPI_INDIRECT_WRITE;
> +   mode = CQSPI_WRITE;
> }
>
> switch (mode) {
> @@ -236,19 +242,15 @@ static int cadence_spi_mem_exec_op(struct spi_slave 
> *spi,
> case CQSPI_STIG_WRITE:
> err = cadence_qspi_apb_command_write(base, op);
> break;
> -   case CQSPI_INDIRECT_READ:
> -   err = cadence_qspi_apb_indirect_read_setup(plat, op);
> -   if (!err) {
> -   err = cadence_qspi_apb_indirect_read_execute
> -   (plat, op->data.nbytes, op->data.buf.in);
> -   }
> +   case CQSPI_READ:
> +   err = cadence_qspi_apb_read_setup(plat, op);
> +   if (!err)
> +   err = cadence_qspi_apb_read_execute(plat, op);
> break;
> -   case CQSPI_INDIRECT_WRITE:
> -   err = cadence_qspi_apb_indirect_write_setup(plat, op);
> -   if (!err) {
> -   err = cadence_qspi_apb_indirect_write_execute
> -   (plat, op->data.nbytes, op->data.buf.out);
> -   }
> +   case CQSPI_WRITE:
> +   err = cadence_qspi_apb_write_setup(plat, op);
> +   if (!err)
> +   err = cadence_qspi_apb_write_execute(plat, op);
> break;
> default:
> err = -1;
> @@ -264,13 +266,17 @@ static int cadence_spi_ofdata_to_platdata(struct 
> udevice *bus)
> ofnode subnode;
>
> plat->regbase = (void *)devfdt_get_addr_index(bus, 0);
> -   plat->ahbbase = (void *)devfdt_get_addr_index(bus, 1);
> +   plat->ahbbase = (void *)devfdt_get_addr_size_index(bus, 1,
> +   >ahbsize);
> plat->is_decoded_cs = dev_read_bool(bus, "cdns,is-decoded-cs");
> plat->fifo_depth = dev_read_u32_default(bus, "cdns,fifo-depth", 128);
> plat->fifo_width = dev_read_u32_default(bus, "cdns,fifo-width", 4);
> 

Re: [U-Boot] [PATCH v2 3/5] spl: nor: Provide falcon boot support for NOR memories

[Tom Rini]

On Tue, Oct 15, 2019 at 10:28:45AM +0200, Lukasz Majewski wrote:

> This commit adds falcon boot support (by also copying args necessary for
> booting) to the SPL NOR memory driver.
> 
> After this change it is possible to use the falcon boot in the same way
> as on NAND memories. The necessary configs (i.e. CONFIG_CMD_SPL_NOR_OFS)
> are now defined in Kconfig.
> 
> Signed-off-by: Lukasz Majewski 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 1/3] travis: Split i.MX jobs a bit more

[Tom Rini]

On Tue, Oct 15, 2019 at 07:27:13AM -0400, Tom Rini wrote:

> - Split "tqc" and "technexion" out into their own jobs and exclude
>   them from the catch-all jobs
> - Clarify the job labels a little more.
> 
> Cc: Stefano Babic 
> Signed-off-by: Tom Rini 
> Acked-by: Stefano Babic 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 2/3] travis: Split sun8i in to two jobs

[Tom Rini]

On Tue, Oct 15, 2019 at 07:27:14AM -0400, Tom Rini wrote:

> Split the 32bit and 64bit platforms into separate jobs, to avoid them
> taking too long to build overall.
> 
> Cc: Jagan Teki 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCHv3 3/3] travis: Split and rename xilinx ARM in to two jobs

[Tom Rini]

On Tue, Oct 15, 2019 at 09:53:22AM -0400, Tom Rini wrote:

> Split the ARMv7 and AArch64 platforms into separate jobs, to avoid them
> taking too long to build overall.  Also rename them from "Xilinx" to
> "Zynq*" to reflect slightly better what is being built and to pull in a
> few more board matches.
> 
> Reviewed-by: Michal Simek 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 1/1] arm: remove the H2200 board

[Tom Rini]

On Tue, Oct 08, 2019 at 08:54:49PM +0200, Heinrich Schuchardt wrote:

> U-Boot cannot be built for h2200_defconfig with CONFIG_DM=y.
> 
> The maintainer Lukasz Dalek suggested to remove the board.
> https://lists.denx.de/pipermail/u-boot/2019-August/380685.html
> 
> Cc: Lukasz Dalek 
> Signed-off-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] image: android: Support boot image v1 and v2

[Tom Rini]

On Thu, Aug 15, 2019 at 08:25:07PM +0300, Sam Protsenko wrote:

> In new versions of Android Boot Image next fields are added to the
> header (and corresponding payloads are added to the image itself):
>   - v1: Recovery DTBO
>   - v2: DTB
> 
> Account for these new fields in next functions:
>   1. android_image_get_end(): as v1 and v2 have new payloads in the
>  image, the calculation of image end address should be extended
>  correspondingly; this is used e.g. by "bootm" command when booting
>  the kernel from Android Boot Image
>   2. android_print_contents(): new fields values in v1 and v2 should be
>  printed; the result of this function can be seen e.g. in "iminfo"
>  command
> 
> This commit doesn't add the means for working with new payloads in v1
> and v2 images (it will be done in further commits), it only updates
> existing functions w.r.t. changes in boot image v1/v2.
> 
> Signed-off-by: Sam Protsenko 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] image: android: Fix possible build errors

[Tom Rini]

On Fri, Aug 09, 2019 at 03:31:29PM +0300, Sam Protsenko wrote:

> As android_image.h uses types like u32, we need to include corresponding
> headers in place. Otherwise the user will be forced to include those in
> C file, or next build error can occur:
> 
> include/android_image.h:32:5: error: unknown type name 'u32'
>  u32 kernel_size; /* size in bytes */
> 
> Include required headers for data types used. While at it, remove
> typedef struct, which is prohibited by kernel coding style, and fix the
> comment.
> 
> Signed-off-by: Sam Protsenko 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] MAINTAINERS: Update ARM entry

[Tom Rini]

On Thu, Oct 10, 2019 at 05:33:09PM -0400, Tom Rini wrote:

> Fully take over the ARM maintainers entry.
> 
> Signed-off-by: Tom Rini 
> Reviewed-by: Bin Meng 
> Reviewed-by: Neil Armstrong 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v1] Makefile: Skip symbolic links to files for cscope

[Tom Rini]

On Tue, Oct 08, 2019 at 09:12:45PM +0300, Andy Shevchenko wrote:

> cscope complains that it can't find files that appears to be symbolic links
> 
> cscope: cannot find file tools/binman/test/u_boot_binman_syms_bad.c
> cscope: cannot find file tools/version.h
> 
> `find -L` tests properties, but name, and cscope can't cope with symbolic
> links (a lot of bugs in upstream were simple closed as kinda invalid).
> 
> To work around the problem, exclude symbolic links from the cscope.files.
> Note, it's done in two pass to speed up the process (`-exec realpath ...`
> approach is not portable and introduces a 3x delay).
> 
> Signed-off-by: Andy Shevchenko 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Please pull u-boot-dm

[Tom Rini]

On Tue, Oct 15, 2019 at 08:46:46AM -0600, Simon Glass wrote:

> Hi Tom,
> 
> https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/950
> 
> 
> The following changes since commit 6891152a4596d38ac25d2fe1238e3b6a938554b8:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-socfpga
> (2019-10-14 21:00:10 -0400)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-dm.git tags/dm-pull-15oct19
> 
> for you to fetch changes up to d11ef4d54cab0e740efbceb9c6b5697a41770eea:
> 
>   sandbox: fix build error due to missing struct udevice definition
> (2019-10-15 08:40:03 -0600)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 1/2] spi: cadence_qspi: Move to spi-mem framework

[Simon Goldschmidt]

On Mon, Oct 14, 2019 at 3:27 PM Vignesh Raghavendra  wrote:
>
> Current Cadence QSPI driver has few limitations. It assumes all read
> operations to be in Quad mode and thus does not support SFDP parsing.
> Also, adding support for new mode such as Octal mode would not be
> possible with current configuration. Therefore move the driver over to spi-mem
> framework. This has added advantage that driver can be used to support
> SPI NAND memories too.
> Hence, move driver over to new spi-mem APIs.
>
> Please note that this gets rid of mode bit setting done when
> CONFIG_SPL_SPI_XIP is defined as there does not seem to be any user to
> that config option.

I just have tried this on an socfgpa cylone5 board with an mt25ql256a, but
it does not seem to work: when leaving spi-rx-bus-width and spi-tx-bus-width
at 4 in my devicetree, SFDP parsing works, but reading data afterwards
produces invalid results (I haven't tested what's wrong there).

It works as expected when not parsing SFDP or setting the bus-width to 1.
So the change itself probably works, but SFDP parsing is broken?

I did the tests with this applied first:
https://patchwork.ozlabs.org/project/uboot/list/?series=135505

Regards,
Simon


>
> Signed-off-by: Vignesh Raghavendra 
> ---
>  drivers/spi/cadence_qspi.c | 136 +
>  drivers/spi/cadence_qspi.h |   9 +--
>  drivers/spi/cadence_qspi_apb.c | 124 --
>  3 files changed, 91 insertions(+), 178 deletions(-)
>
> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> index e2e54cd27723..673a2e9a6c4c 100644
> --- a/drivers/spi/cadence_qspi.c
> +++ b/drivers/spi/cadence_qspi.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include "cadence_qspi.h"
>
> @@ -34,12 +35,21 @@ static int cadence_spi_write_speed(struct udevice *bus, 
> uint hz)
> return 0;
>  }
>
> +static int cadence_spi_read_id(void *reg_base, u8 len, u8 *idcode)
> +{
> +   struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(0x9F, 1),
> + SPI_MEM_OP_NO_ADDR,
> + SPI_MEM_OP_NO_DUMMY,
> + SPI_MEM_OP_DATA_IN(len, idcode, 1));
> +
> +   return cadence_qspi_apb_command_read(reg_base, );
> +}
> +
>  /* Calibration sequence to determine the read data capture delay register */
>  static int spi_calibration(struct udevice *bus, uint hz)
>  {
> struct cadence_spi_priv *priv = dev_get_priv(bus);
> void *base = priv->regbase;
> -   u8 opcode_rdid = 0x9F;
> unsigned int idcode = 0, temp = 0;
> int err = 0, i, range_lo = -1, range_hi = -1;
>
> @@ -53,8 +63,7 @@ static int spi_calibration(struct udevice *bus, uint hz)
> cadence_qspi_apb_controller_enable(base);
>
> /* read the ID which will be our golden value */
> -   err = cadence_qspi_apb_command_read(base, 1, _rdid,
> -   3, (u8 *));
> +   err = cadence_spi_read_id(base, 3, (u8 *));
> if (err) {
> puts("SF: Calibration failed (read)\n");
> return err;
> @@ -73,8 +82,7 @@ static int spi_calibration(struct udevice *bus, uint hz)
> cadence_qspi_apb_controller_enable(base);
>
> /* issue a RDID to get the ID value */
> -   err = cadence_qspi_apb_command_read(base, 1, _rdid,
> -   3, (u8 *));
> +   err = cadence_spi_read_id(base, 3, (u8 *));
> if (err) {
> puts("SF: Calibration failed (read)\n");
> return err;
> @@ -195,96 +203,56 @@ static int cadence_spi_set_mode(struct udevice *bus, 
> uint mode)
> return 0;
>  }
>
> -static int cadence_spi_xfer(struct udevice *dev, unsigned int bitlen,
> -   const void *dout, void *din, unsigned long flags)
> +static int cadence_spi_mem_exec_op(struct spi_slave *spi,
> +  const struct spi_mem_op *op)
>  {
> -   struct udevice *bus = dev->parent;
> +   struct udevice *bus = spi->dev->parent;
> struct cadence_spi_platdata *plat = bus->platdata;
> struct cadence_spi_priv *priv = dev_get_priv(bus);
> -   struct dm_spi_slave_platdata *dm_plat = dev_get_parent_platdata(dev);
> void *base = priv->regbase;
> -   u8 *cmd_buf = priv->cmd_buf;
> -   size_t data_bytes;
> int err = 0;
> -   u32 mode = CQSPI_STIG_WRITE;
> -
> -   if (flags & SPI_XFER_BEGIN) {
> -   /* copy command to local buffer */
> -   priv->cmd_len = bitlen / 8;
> -   memcpy(cmd_buf, dout, priv->cmd_len);
> -   }
> -
> -   if (flags == (SPI_XFER_BEGIN | SPI_XFER_END)) {
> -   /* if start and end bit are set, the data bytes is 0. */
> -   data_bytes = 0;
> -   } else {
> -   data_bytes = bitlen / 8;
> -   }
> - 

Re: [U-Boot] [PATCH] nvme: flush dcache on both r/w, and the prp list

[Bin Meng]

On Thu, Oct 17, 2019 at 5:22 AM Patrick Wildt  wrote:
>
> It's possible that the data cache for the buffer still holds data
> to be flushed to memory, since the buffer was probably used as stack
> before.  Thus we need to make sure to flush it also on reads, since
> it's possible that the cache is automatically flused to memory after
> the NVMe DMA transfer happened, thus overwriting the NVMe transfer's
> data.  Also add a missing dcache flush for the prp list.
>
> Signed-off-by: Patrick Wildt 
> ---
>  drivers/nvme/nvme.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>

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

[U-Boot] [PATCH 6/6] armv8: ls1028a: erratum A050382 workaround

[Laurentiu Tudor]

From: Laurentiu Tudor 

Description:
  The eDMA ICID programmed in the eDMA_AMQR register in DCFG is not
  correctly forwarded to the SMMU.
Workaround:
  Program eDMA ICID in the eDMA_AMQR register in DCFG to 0x28.

Signed-off-by: Laurentiu Tudor 
---
 arch/arm/cpu/armv8/fsl-layerscape/Kconfig |  3 +++
 .../asm/arch-fsl-layerscape/stream_id_lsch3.h | 15 +++
 2 files changed, 18 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index 24c606a232..046dcf539e 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -45,6 +45,7 @@ config ARCH_LS1028A
select SYS_FSL_ERRATUM_A008514 if !TFABOOT
select SYS_FSL_ERRATUM_A009663 if !TFABOOT
select SYS_FSL_ERRATUM_A009942 if !TFABOOT
+   select SYS_FSL_ERRATUM_A050382
imply PANIC_HANG
 
 config ARCH_LS1043A
@@ -584,6 +585,8 @@ config SYS_FSL_ERRATUM_A009660
 config SYS_FSL_ERRATUM_A009929
bool
 
+config SYS_FSL_ERRATUM_A050382
+   bool
 
 config SYS_FSL_HAS_RGMII
bool
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch3.h
index 0b36416ad3..4c9e1e72f0 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch3.h
@@ -105,7 +105,22 @@
 #define FSL_SEC_JR4_STREAM_ID  68
 
 #define FSL_SDMMC2_STREAM_ID   69
+
+/*
+ * Erratum A050382 workaround
+ *
+ * Description:
+ *   The eDMA ICID programmed in the eDMA_AMQR register in DCFG is not
+ *   correctly forwarded to the SMMU.
+ * Workaround:
+ *   Program eDMA ICID in the eDMA_AMQR register in DCFG to 0x28.
+ */
+#ifdef CONFIG_SYS_FSL_ERRATUM_A050382
+#define FSL_EDMA_STREAM_ID 40
+#else
 #define FSL_EDMA_STREAM_ID 70
+#endif
+
 #define FSL_GPU_STREAM_ID  71
 #define FSL_DISPLAY_STREAM_ID  72
 #define FSL_SATA3_STREAM_ID73
-- 
2.17.1

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

[U-Boot] [PATCH 5/6] armv8: lx2160a: add icid setup for platform devices

[Laurentiu Tudor]

From: Laurentiu Tudor 

Add ICID setup for the platform devices contained on this chip: usb,
sata, sdhc, sec.

Signed-off-by: Laurentiu Tudor 
---
 arch/arm/cpu/armv8/fsl-layerscape/Makefile|  1 +
 .../arm/cpu/armv8/fsl-layerscape/lx2160_ids.c | 48 +++
 arch/arm/cpu/armv8/fsl-layerscape/soc.c   |  2 +-
 .../asm/arch-fsl-layerscape/immap_lsch3.h |  4 +-
 .../asm/arch-fsl-layerscape/stream_id_lsch3.h |  2 +
 board/freescale/lx2160a/lx2160a.c |  2 +
 include/fsl_sec.h |  3 +-
 7 files changed, 58 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/lx2160_ids.c

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile 
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index f00ef817b1..e398aecd12 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -24,6 +24,7 @@ endif
 
 ifneq ($(CONFIG_ARCH_LX2160A),)
 obj-$(CONFIG_SYS_HAS_SERDES) += lx2160a_serdes.o
+obj-y += icid.o lx2160_ids.o
 endif
 
 ifneq ($(CONFIG_ARCH_LS2080A),)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lx2160_ids.c 
b/arch/arm/cpu/armv8/fsl-layerscape/lx2160_ids.c
new file mode 100644
index 00..3a0ed1fa55
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lx2160_ids.c
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+struct icid_id_table icid_tbl[] = {
+   SET_SDHC_ICID(1, FSL_SDMMC_STREAM_ID),
+   SET_SDHC_ICID(2, FSL_SDMMC2_STREAM_ID),
+   SET_USB_ICID(1, "snps,dwc3", FSL_USB1_STREAM_ID),
+   SET_USB_ICID(2, "snps,dwc3", FSL_USB2_STREAM_ID),
+   SET_SATA_ICID(1, "fsl,lx2160a-ahci", FSL_SATA1_STREAM_ID),
+   SET_SATA_ICID(2, "fsl,lx2160a-ahci", FSL_SATA2_STREAM_ID),
+   SET_SATA_ICID(3, "fsl,lx2160a-ahci", FSL_SATA3_STREAM_ID),
+   SET_SATA_ICID(4, "fsl,lx2160a-ahci", FSL_SATA4_STREAM_ID),
+#ifdef CONFIG_FSL_CAAM
+   SET_SEC_JR_ICID_ENTRY(0, FSL_SEC_JR1_STREAM_ID),
+   SET_SEC_JR_ICID_ENTRY(1, FSL_SEC_JR2_STREAM_ID),
+   SET_SEC_JR_ICID_ENTRY(2, FSL_SEC_JR3_STREAM_ID),
+   SET_SEC_JR_ICID_ENTRY(3, FSL_SEC_JR4_STREAM_ID),
+   SET_SEC_RTIC_ICID_ENTRY(0, FSL_SEC_STREAM_ID),
+   SET_SEC_RTIC_ICID_ENTRY(1, FSL_SEC_STREAM_ID),
+   SET_SEC_RTIC_ICID_ENTRY(2, FSL_SEC_STREAM_ID),
+   SET_SEC_RTIC_ICID_ENTRY(3, FSL_SEC_STREAM_ID),
+   SET_SEC_DECO_ICID_ENTRY(0, FSL_SEC_STREAM_ID),
+   SET_SEC_DECO_ICID_ENTRY(1, FSL_SEC_STREAM_ID),
+   SET_SEC_DECO_ICID_ENTRY(2, FSL_SEC_STREAM_ID),
+   SET_SEC_DECO_ICID_ENTRY(3, FSL_SEC_STREAM_ID),
+   SET_SEC_DECO_ICID_ENTRY(4, FSL_SEC_STREAM_ID),
+   SET_SEC_DECO_ICID_ENTRY(5, FSL_SEC_STREAM_ID),
+   SET_SEC_DECO_ICID_ENTRY(6, FSL_SEC_STREAM_ID),
+   SET_SEC_DECO_ICID_ENTRY(7, FSL_SEC_STREAM_ID),
+   SET_SEC_DECO_ICID_ENTRY(8, FSL_SEC_STREAM_ID),
+   SET_SEC_DECO_ICID_ENTRY(9, FSL_SEC_STREAM_ID),
+   SET_SEC_DECO_ICID_ENTRY(10, FSL_SEC_STREAM_ID),
+   SET_SEC_DECO_ICID_ENTRY(11, FSL_SEC_STREAM_ID),
+   SET_SEC_DECO_ICID_ENTRY(12, FSL_SEC_STREAM_ID),
+   SET_SEC_DECO_ICID_ENTRY(13, FSL_SEC_STREAM_ID),
+   SET_SEC_DECO_ICID_ENTRY(14, FSL_SEC_STREAM_ID),
+   SET_SEC_DECO_ICID_ENTRY(15, FSL_SEC_STREAM_ID),
+#endif
+};
+
+int icid_tbl_sz = ARRAY_SIZE(icid_tbl);
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c 
b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
index 924f5f3fe8..4dea8361fc 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
@@ -342,7 +342,7 @@ void fsl_lsch3_early_init_f(void)
 #endif
 
 #if defined(CONFIG_ARCH_LS1088A) || defined(CONFIG_ARCH_LS1028A) || \
-   defined(CONFIG_ARCH_LS2080A)
+   defined(CONFIG_ARCH_LS2080A) || defined(CONFIG_ARCH_LX2160A)
set_icids();
 #endif
 }
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 0e4bf331fd..f86835a33d 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -447,7 +447,9 @@ struct ccsr_gur {
u8  res_538[0x550 - 0x538]; /* add more registers when needed */
u32 sata1_amqr;
u32 sata2_amqr;
-   u8  res_558[0x570-0x558];   /* add more registers when needed */
+   u32 sata3_amqr;
+   u32 sata4_amqr;
+   u8  res_558[0x570 - 0x560]; /* add more registers when needed */
u32 misc1_amqr;
u8  res_574[0x590-0x574];   /* add more registers when needed */
u32 spare1_amqr;
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch3.h
index 93bdcc4caa..0b36416ad3 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch3.h
@@ -108,5 +108,7 @@
 #define 

[U-Boot] [PATCH 4/6] armv8: fsl-layerscape: add missing SATA3 and SATA4 base addresses

[Laurentiu Tudor]

From: Laurentiu Tudor 

There are chips that have 4 sata controllers. Add missing base
addresses for SATA3 and SATA4.

Signed-off-by: Laurentiu Tudor 
---
 arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 4f050470dd..0e4bf331fd 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -87,6 +87,8 @@
 /* SATA */
 #define AHCI_BASE_ADDR1(CONFIG_SYS_IMMR + 
0x0220)
 #define AHCI_BASE_ADDR2(CONFIG_SYS_IMMR + 
0x0221)
+#define AHCI_BASE_ADDR3(CONFIG_SYS_IMMR + 
0x0222)
+#define AHCI_BASE_ADDR4(CONFIG_SYS_IMMR + 
0x0223)
 
 /* QDMA */
 #define QDMA_BASE_ADDR (CONFIG_SYS_IMMR + 0x0738)
-- 
2.17.1

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

[U-Boot] [PATCH 3/6] armv8: ls2088a: add icid setup for platform devices

[Laurentiu Tudor]

From: Laurentiu Tudor 

Add ICID setup for the platform devices contained on this chip: usb,
sata, sdhc, sec.

Signed-off-by: Laurentiu Tudor 
---
 arch/arm/cpu/armv8/fsl-layerscape/Makefile|  1 +
 .../arm/cpu/armv8/fsl-layerscape/ls2088_ids.c | 33 +++
 arch/arm/cpu/armv8/fsl-layerscape/soc.c   |  3 +-
 board/freescale/ls2080aqds/ls2080aqds.c   |  3 ++
 board/freescale/ls2080ardb/ls2080ardb.c   |  3 ++
 5 files changed, 42 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/ls2088_ids.c

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile 
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index efecbc07e7..f00ef817b1 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -28,6 +28,7 @@ endif
 
 ifneq ($(CONFIG_ARCH_LS2080A),)
 obj-$(CONFIG_SYS_HAS_SERDES) += ls2080a_serdes.o
+obj-y += icid.o ls2088_ids.o
 endif
 
 ifneq ($(CONFIG_ARCH_LS1043A),)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls2088_ids.c 
b/arch/arm/cpu/armv8/fsl-layerscape/ls2088_ids.c
new file mode 100644
index 00..9556e93de9
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ls2088_ids.c
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+struct icid_id_table icid_tbl[] = {
+   SET_SDHC_ICID(1, FSL_SDMMC_STREAM_ID),
+   SET_USB_ICID(1, "snps,dwc3", FSL_USB1_STREAM_ID),
+   SET_USB_ICID(2, "snps,dwc3", FSL_USB2_STREAM_ID),
+   SET_SATA_ICID(1, "fsl,ls2080a-ahci", FSL_SATA1_STREAM_ID),
+   SET_SATA_ICID(2, "fsl,ls2080a-ahci", FSL_SATA2_STREAM_ID),
+#ifdef CONFIG_FSL_CAAM
+   SET_SEC_JR_ICID_ENTRY(0, FSL_SEC_JR1_STREAM_ID),
+   SET_SEC_JR_ICID_ENTRY(1, FSL_SEC_JR2_STREAM_ID),
+   SET_SEC_JR_ICID_ENTRY(2, FSL_SEC_JR3_STREAM_ID),
+   SET_SEC_JR_ICID_ENTRY(3, FSL_SEC_JR4_STREAM_ID),
+   SET_SEC_RTIC_ICID_ENTRY(0, FSL_SEC_STREAM_ID),
+   SET_SEC_RTIC_ICID_ENTRY(1, FSL_SEC_STREAM_ID),
+   SET_SEC_RTIC_ICID_ENTRY(2, FSL_SEC_STREAM_ID),
+   SET_SEC_RTIC_ICID_ENTRY(3, FSL_SEC_STREAM_ID),
+   SET_SEC_DECO_ICID_ENTRY(0, FSL_SEC_STREAM_ID),
+   SET_SEC_DECO_ICID_ENTRY(1, FSL_SEC_STREAM_ID),
+   SET_SEC_DECO_ICID_ENTRY(2, FSL_SEC_STREAM_ID),
+   SET_SEC_DECO_ICID_ENTRY(3, FSL_SEC_STREAM_ID),
+#endif
+};
+
+int icid_tbl_sz = ARRAY_SIZE(icid_tbl);
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c 
b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
index 3fd34e3a43..924f5f3fe8 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
@@ -341,7 +341,8 @@ void fsl_lsch3_early_init_f(void)
bypass_smmu();
 #endif
 
-#if defined(CONFIG_ARCH_LS1088A) || defined(CONFIG_ARCH_LS1028A)
+#if defined(CONFIG_ARCH_LS1088A) || defined(CONFIG_ARCH_LS1028A) || \
+   defined(CONFIG_ARCH_LS2080A)
set_icids();
 #endif
 }
diff --git a/board/freescale/ls2080aqds/ls2080aqds.c 
b/board/freescale/ls2080aqds/ls2080aqds.c
index 91c80353ed..25e80c8ac6 100644
--- a/board/freescale/ls2080aqds/ls2080aqds.c
+++ b/board/freescale/ls2080aqds/ls2080aqds.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 
 #include "../common/qixis.h"
@@ -358,6 +359,8 @@ int ft_board_setup(void *blob, bd_t *bd)
fdt_fixup_board_enet(blob);
 #endif
 
+   fdt_fixup_icid(blob);
+
return 0;
 }
 #endif
diff --git a/board/freescale/ls2080ardb/ls2080ardb.c 
b/board/freescale/ls2080ardb/ls2080ardb.c
index e20267f27c..6a1b8e3f53 100644
--- a/board/freescale/ls2080ardb/ls2080ardb.c
+++ b/board/freescale/ls2080ardb/ls2080ardb.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_FSL_QIXIS
 #include "../common/qixis.h"
@@ -478,6 +479,8 @@ int ft_board_setup(void *blob, bd_t *bd)
fdt_fixup_board_enet(blob);
 #endif
 
+   fdt_fixup_icid(blob);
+
return 0;
 }
 #endif
-- 
2.17.1

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

[U-Boot] [PATCH 2/6] armv8: fsl-layerscape: fix compile error with sec fw disabled

[Laurentiu Tudor]

From: Laurentiu Tudor 

If SEC FW support is not enabled (ARMV8_SEC_FIRMWARE_SUPPORT=n) this
compilation error happens:
arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h:169:4: error:
'CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT' undeclared here (not in a function)

Fix it by adding an intermediate macro to handle the problem.

Signed-off-by: Laurentiu Tudor 
---
 arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h 
b/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
index 37e2fe4e66..398bb4eb86 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
@@ -164,9 +164,15 @@ extern int fman_icid_tbl_sz;
QDMA_BASE_ADDR + QMAN_CQSIDR_REG + 4, \
QDMA_BASE_ADDR, QDMA_IS_LE)
 
+#ifdef CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT
+#define SEC_FW_SUPPORT CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT
+#else
+#define SEC_FW_SUPPORT 0
+#endif
+
 #define SET_SEC_JR_ICID_ENTRY(jr_num, streamid) \
SET_ICID_ENTRY( \
-   (CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT && \
+   (SEC_FW_SUPPORT && \
(FSL_SEC_JR##jr_num##_OFFSET ==  \
SEC_JR3_OFFSET + CONFIG_SYS_FSL_SEC_OFFSET) \
? NULL \
-- 
2.17.1

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

[U-Boot] [PATCH 1/6] armv8: fsl-layerscape: guard caam specific defines

[Laurentiu Tudor]

From: Laurentiu Tudor 

These macros should only be used when CONFIG_FSL_CAAM is present.

Signed-off-by: Laurentiu Tudor 
---
 arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c | 2 ++
 arch/arm/cpu/armv8/fsl-layerscape/ls1088_ids.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c 
b/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c
index d9d125e8ba..9462298fbf 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c
@@ -18,6 +18,7 @@ struct icid_id_table icid_tbl[] = {
SET_QDMA_ICID("fsl,ls1028a-qdma", FSL_DMA_STREAM_ID),
SET_GPU_ICID("fsl,ls1028a-gpu", FSL_GPU_STREAM_ID),
SET_DISPLAY_ICID(FSL_DISPLAY_STREAM_ID),
+#ifdef CONFIG_FSL_CAAM
SET_SEC_JR_ICID_ENTRY(0, FSL_SEC_JR1_STREAM_ID),
SET_SEC_JR_ICID_ENTRY(1, FSL_SEC_JR2_STREAM_ID),
SET_SEC_JR_ICID_ENTRY(2, FSL_SEC_JR3_STREAM_ID),
@@ -28,6 +29,7 @@ struct icid_id_table icid_tbl[] = {
SET_SEC_RTIC_ICID_ENTRY(3, FSL_SEC_STREAM_ID),
SET_SEC_DECO_ICID_ENTRY(0, FSL_SEC_STREAM_ID),
SET_SEC_DECO_ICID_ENTRY(1, FSL_SEC_STREAM_ID),
+#endif
 };
 
 int icid_tbl_sz = ARRAY_SIZE(icid_tbl);
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1088_ids.c 
b/arch/arm/cpu/armv8/fsl-layerscape/ls1088_ids.c
index 49e27553b1..23743ae10c 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/ls1088_ids.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1088_ids.c
@@ -13,6 +13,7 @@ struct icid_id_table icid_tbl[] = {
SET_USB_ICID(1, "snps,dwc3", FSL_USB1_STREAM_ID),
SET_USB_ICID(2, "snps,dwc3", FSL_USB2_STREAM_ID),
SET_SATA_ICID(1, "fsl,ls1088a-ahci", FSL_SATA1_STREAM_ID),
+#ifdef CONFIG_FSL_CAAM
SET_SEC_JR_ICID_ENTRY(0, FSL_SEC_JR1_STREAM_ID),
SET_SEC_JR_ICID_ENTRY(1, FSL_SEC_JR2_STREAM_ID),
SET_SEC_JR_ICID_ENTRY(2, FSL_SEC_JR3_STREAM_ID),
@@ -25,6 +26,7 @@ struct icid_id_table icid_tbl[] = {
SET_SEC_DECO_ICID_ENTRY(1, FSL_SEC_STREAM_ID),
SET_SEC_DECO_ICID_ENTRY(2, FSL_SEC_STREAM_ID),
SET_SEC_DECO_ICID_ENTRY(3, FSL_SEC_STREAM_ID),
+#endif
 };
 
 int icid_tbl_sz = ARRAY_SIZE(icid_tbl);
-- 
2.17.1

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

Re: [U-Boot] [PATCH v0] rockchip: adding the missing "/" in entries of boot_devices

[Philipp Tomsich]

> On 17.10.2019, at 09:22, d...@t-chip.com.cn wrote:
> 
> From: Levin Du 
> 
> Without the prefix, "same-as-spl" in `u-boot,spl-boot-order` will not work
> as expected. When board_boot_order() `spl-boot-order.c` meets
> "same-as-spl", it gets the conf by looking the boot_devices table by boot
> source, and parse the node by the conf with:
> 
>   node = fdt_path_offset(blob, conf);
> 
> which will failed without the "/" indicating the path.
> 
> Currently only entries of boot_devices in rk3399 have the "/" prefix.
> Therefore add the missing ones in other boards.

Good catch. One can thus tell what platform I originally tested this on ;-)

> Signed-off-by: Levin Du 

Reviewed-by: Philipp Tomsich 

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

Re: [U-Boot] [PATCH v0] rockchip: adding the missing "/" in entries of boot_devices

[Mark Kettenis]

> From: d...@t-chip.com.cn
> Date: Thu, 17 Oct 2019 15:22:38 +0800
> 
> From: Levin Du 
> 
> Without the prefix, "same-as-spl" in `u-boot,spl-boot-order` will not work
> as expected. When board_boot_order() `spl-boot-order.c` meets
> "same-as-spl", it gets the conf by looking the boot_devices table by boot
> source, and parse the node by the conf with:
> 
>node = fdt_path_offset(blob, conf);
> 
> which will failed without the "/" indicating the path.
> 
> Currently only entries of boot_devices in rk3399 have the "/" prefix.
> Therefore add the missing ones in other boards.
> 
> Signed-off-by: Levin Du 

I have a very similar diff in my tree that I didn't manage to send out yet.

Reviewed by: Mark Kettenis 

> ---
> 
>  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/rk3328/rk3328.c | 4 ++--
>  arch/arm/mach-rockchip/rk3368/rk3368.c | 4 ++--
>  5 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/mach-rockchip/rk3188/rk3188.c 
> b/arch/arm/mach-rockchip/rk3188/rk3188.c
> index 95f0e3ccbead..1b012f7f67ae 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 cd0bf8a70cc0..562117e6c13a 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 057ce920809e..987b4e0d58c2 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/rk3328/rk3328.c 
> b/arch/arm/mach-rockchip/rk3328/rk3328.c
> index c2448d727302..8c81242e5d4b 100644
> --- a/arch/arm/mach-rockchip/rk3328/rk3328.c
> +++ b/arch/arm/mach-rockchip/rk3328/rk3328.c
> @@ -19,8 +19,8 @@ DECLARE_GLOBAL_DATA_PTR;
>  #define FW_DDR_CON_REG   0xFF7C0040
>  
>  const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
> - [BROM_BOOTSOURCE_EMMC] = "rksdmmc@ff52",
> - [BROM_BOOTSOURCE_SD] = "rksdmmc@ff50",
> + [BROM_BOOTSOURCE_EMMC] = "/rksdmmc@ff52",
> + [BROM_BOOTSOURCE_SD] = "/rksdmmc@ff50",
>  };
>  
>  static struct mm_region rk3328_mem_map[] = {
> diff --git a/arch/arm/mach-rockchip/rk3368/rk3368.c 
> b/arch/arm/mach-rockchip/rk3368/rk3368.c
> index 7ccd417a18ce..20ae79779473 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.23.0.37.g745f6812895b
> 
> 
> 
> ___
> 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] [PATCH] rockchip: firefly-rk3288: Enable TPL support【请注意，邮件由u-boot-boun...@lists.denx.de代发】

[Levin Du]

Hi all, I have difficulties with TPL in the firefly-rk3288 board.

1. Without defining DEBUG in `drivers/mmc/dw_mmc.c`, boot with TF card:

U-Boot TPL 2019.10-00017-g5b02ac7fa5dd-dirty (Oct 17 2019 - 16:36:39)
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2019.10-00017-g5b02ac7fa5dd-dirty (Oct 17 2019 - 16:36:39 +0800)
Trying to boot from MMC1
spl: mmc boot mode: raw
hdr read sector 4000, count=1
TO read 3af sectors to c0

It hangs without further messages.

2. With defining DEBUG in `drivers/mmc/dw_mmc.c`, boot with TF card, emmc
being erased:

U-Boot TPL 2019.10-00017-g5b02ac7fa5dd-dirty (Oct 17 2019 - 16:42:43)
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2019.10-00017-g5b02ac7fa5dd-dirty (Oct 17 2019 - 16:42:43 +0800)
Trying to boot from MMC1
Buswidth = 0, clock: 0
Buswidth = 1, clock: 0
Buswidth = 1, clock: 40
Sending CMD0
Sending CMD8
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD2
Sending CMD3
Sending CMD9
Sending CMD7
Sending CMD55
Sending CMD51
Sending CMD6
Sending CMD55
Sending CMD6
Buswidth = 4, clock: 40
Sending CMD6
Buswidth = 4, clock: 5000
spl: mmc boot mode: raw
Sending CMD16
Sending CMD17
hdr read sector 4000, count=1
TO read 3b1 sectors to c0
Sending CMD16
Sending CMD18
Sending CMD12
read 3b1 sectors to c0


U-Boot 2019.10-00017-g5b02ac7fa5dd-dirty (Oct 17 2019 - 16:42:43 +0800)

Model: Firefly-RK3288
DRAM:  4 GiB
MMC:   dwmmc@ff0c: 1, dwmmc@ff0f: 0
Loading Environment from MMC... Buswidth = 0, clock: 0
Buswidth = 1, clock: 0
Buswidth = 1, clock: 40
Sending CMD0
Sending CMD8
dwmci_send_cmd: Response Timeout.
Sending CMD55
dwmci_send_cmd: Response Timeout.
Sending CMD0
Sending CMD1
Sending CMD1
Sending CMD0
Sending CMD1
Sending CMD1
Sending CMD2
Sending CMD3
Sending CMD9
Sending CMD7
Sending CMD8
Buswidth = 1, clock: 2500
Sending CMD6
Sending CMD13
Buswidth = 8, clock: 2500
Sending CMD6
Sending CMD13
Sending CMD8
Buswidth = 8, clock: 5200
Sending CMD8
Sending CMD16
Sending CMD17
Sending CMD16
Sending CMD18
Sending CMD12
Sending CMD16
Sending CMD18
Sending CMD12
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Model: Firefly-RK3288
rockchip_dnl_key_pressed: adc_channel_single_shot fail!
Net:
Warning: ethernet@ff29 (eth0) using random MAC address - 
f2:26:96:9a:41:83
eth0: ethernet@ff29
Hit any key to stop autoboot:  0
=>

Everything works. It is weird.

Have tried with the eMMC booting, with the same result.


My modification besides Kever's patch is:

diff --git a/arch/arm/mach-rockchip/rk3288/rk3288.c 
b/arch/arm/mach-rockchip/rk3288/rk3288.c
index 057ce920809e..987b4e0d58c2 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/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index b3619889f794..e7432c96752a 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -5,6 +5,7 @@
  *
  * Aneesh V 
  */
+#define DEBUG
 #include 
 #include 
 #include 
@@ -31,6 +32,8 @@ static int mmc_load_legacy(struct spl_image_info *spl_image, 
struct mmc *mmc,
 mmc->read_bl_len;
 
/* Read the header too to avoid extra memcpy */
+   debug("TO read %x sectors to %lx\n", image_size_sectors,
+ spl_image->load_addr);
count = blk_dread(mmc_get_blk_desc(mmc), sector, image_size_sectors,
  (void *)(ulong)spl_image->load_addr);
debug("read %x sectors to %lx\n", image_size_sectors,
diff --git a/configs/firefly-rk3288_defconfig b/configs/firefly-rk3288_defconfig
index 4a43cb5470f1..061005453be4 100644
--- a/configs/firefly-rk3288_defconfig
+++ b/configs/firefly-rk3288_defconfig
@@ -15,6 +15,7 @@ CONFIG_SILENT_CONSOLE=y
 CONFIG_DEFAULT_FDT_FILE="rk3288-firefly.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2000
 CONFIG_CMD_GPIO=y
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index ebe7bcdd9005..2cd4092f0601 100644
--- a/drivers/mmc/dw_mmc.c
+++ 

Re: [U-Boot] [PATCH v1 3/3] lib: rsa: add rsa_verify_with_pkey()

[AKASHI Takahiro]

On Tue, Oct 15, 2019 at 04:17:04PM +0900, AKASHI Takahiro wrote:
> On Sat, Oct 12, 2019 at 02:47:33PM +0200, Heinrich Schuchardt wrote:
> > On 10/10/19 3:04 AM, AKASHI Takahiro wrote:
> > >On Wed, Oct 09, 2019 at 07:56:04PM +0200, Heinrich Schuchardt wrote:
> > >>On 10/9/19 7:30 AM, AKASHI Takahiro wrote:
> > >>>This function, and hence rsa_verify(), will perform RSA verification
> > >>>with two essential parameters for a RSA public key in contract of
> > >>>rsa_verify_with_keynode(), which requires additional three parameters
> > >>>stored in FIT image.
> > >>>
> > >>>It will be used in implementing UEFI secure boot, i.e. image 
> > >>>authentication
> > >>>and variable authentication.
> > >>>
> > >>>Signed-off-by: AKASHI Takahiro 
> > >>
> > >>Is this code tested by test/py/tests/test_vboot.py? Or is there another
> > >>unit test?
> > >
> > >I haven't run vboot test yet.
> > 
> > I would have assumed that you to through Travis CI before submitting.
> > 
> > >For rsa_verify_with_pkey(), as with vtest for FIT signature,
> > >we can test it with my "UEFI secure boot" pytest.
> > 
> > I can't see such a test in this patch series. So how I can test the
> > changes before merging?
> 
> The only solution that I can give you is that I would submit
> rsa patch with my "UEFI secure boot" patch.

I added a very simple function test in "ut" command but will defer
sending a new version until after v2 of "x509 parser" patch
as I found there is some dependency on public key parser in rsa_keyprop.c.

-Takahiro Akashi

> 
> 
> > Best regards
> > 
> > Heinrich
> > 
> > >
> > >>>---
> > >>>  lib/rsa/Kconfig  |  7 -
> > >>>  lib/rsa/Makefile |  1 -
> > >>>  lib/rsa/rsa-verify.c | 63 ++--
> > >>>  3 files changed, 55 insertions(+), 16 deletions(-)
> > >>>
> > >>>diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig
> > >>>index d1743d7a4c47..62b7ab9c5e5c 100644
> > >>>--- a/lib/rsa/Kconfig
> > >>>+++ b/lib/rsa/Kconfig
> > >>>@@ -30,13 +30,6 @@ config RSA_VERIFY
> > >>> help
> > >>>   Add RSA signature verification support.
> > >>>
> > >>>-config RSA_VERIFY_WITH_PKEY
> > >>>-bool "Execute RSA verification without key parameters from FDT"
> > >>>-depends on RSA
> > >>>-help
> > >>>-  This options enables RSA signature verification without
> > >>>-  using public key parameters which is embedded control FDT.
> > >>>-
> > >>>  config RSA_SOFTWARE_EXP
> > >>> bool "Enable driver for RSA Modular Exponentiation in software"
> > >>> depends on DM
> > >>>diff --git a/lib/rsa/Makefile b/lib/rsa/Makefile
> > >>>index 14ed3cb4012b..c07305188e0c 100644
> > >>>--- a/lib/rsa/Makefile
> > >>>+++ b/lib/rsa/Makefile
> > >>>@@ -6,5 +6,4 @@
> > >>>  # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> > >>>
> > >>>  obj-$(CONFIG_$(SPL_)RSA_VERIFY) += rsa-verify.o rsa-checksum.o
> > >>>-obj-$(CONFIG_RSA_VERIFY_WITH_PKEY) += rsa-keyprop.o
> > >>>  obj-$(CONFIG_RSA_SOFTWARE_EXP) += rsa-mod-exp.o
> > >>>diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
> > >>>index 1df42f28c64a..ce79984b30f9 100644
> > >>>--- a/lib/rsa/rsa-verify.c
> > >>>+++ b/lib/rsa/rsa-verify.c
> > >>>@@ -17,9 +17,14 @@
> > >>>  #include "mkimage.h"
> > >>>  #include 
> > >>>  #endif
> > >>>+#include 
> > >>>  #include 
> > >>>  #include 
> > >>>
> > >>>+#ifndef __UBOOT__ /* for host tools */
> > >>>+#undef CONFIG_RSA_VERIFY_WITH_PKEY
> > >>
> > >>Where should it have been defined?
> > >
> > >defined in patch#2
> > >
> > >>>+#endif
> > >>>+
> > >>>  /* Default public exponent for backward compatibility */
> > >>>  #define RSA_DEFAULT_PUBEXP 65537
> > >>>
> > >>>@@ -344,6 +349,34 @@ static int rsa_verify_key(struct image_sign_info 
> > >>>*info,
> > >>>  }
> > >>>  #endif
> > >>>
> > >>>+#ifdef CONFIG_RSA_VERIFY_WITH_PKEY
> > >>
> > >>Where would CONFIG_RSA_VERIFY_WITH_PKEY be defined? You just a removed
> > >>it from Kconfig.
> > >
> > >Because rsa-keyprop.c be compiled only under CONFIG_RSA_VERIFY_WITH_PKEY
> > >per Simon's comment.
> > >
> > >>>+/**
> > >>>+ * rsa_verify_with_pkey()
> > >>
> > >>The short text for the function is missing.
> > >>
> > >>>+ *
> > >>
> > >>Please, describe the parameters.
> > >
> > >Sure.
> > >
> > >-Takahiro Akashi
> > >
> > >>>+ */
> > >>>+static int rsa_verify_with_pkey(struct image_sign_info *info,
> > >>>+const void *hash, uint8_t *sig, uint 
> > >>>sig_len)
> > >>>+{
> > >>>+struct key_prop *prop;
> > >>>+int ret;
> > >>>+
> > >>>+/* Public key is self-described to fill key_prop */
> > >>>+prop = rsa_gen_key_prop(info->key, info->keylen);
> > >>>+if (!prop) {
> > >>>+debug("Generating necessary parameter for decoding 
> > >>>failed\n");
> > >>>+return -EACCES;
> > >>>+}
> > >>>+
> > >>>+ret = rsa_verify_key(info, prop, sig, sig_len, hash,
> > >>>+ 

[U-Boot] [PATCH v0] rockchip: adding the missing "/" in entries of boot_devices

[djw]

From: Levin Du 

Without the prefix, "same-as-spl" in `u-boot,spl-boot-order` will not work
as expected. When board_boot_order() `spl-boot-order.c` meets
"same-as-spl", it gets the conf by looking the boot_devices table by boot
source, and parse the node by the conf with:

   node = fdt_path_offset(blob, conf);

which will failed without the "/" indicating the path.

Currently only entries of boot_devices in rk3399 have the "/" prefix.
Therefore add the missing ones in other boards.

Signed-off-by: Levin Du 

---

 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/rk3328/rk3328.c | 4 ++--
 arch/arm/mach-rockchip/rk3368/rk3368.c | 4 ++--
 5 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-rockchip/rk3188/rk3188.c 
b/arch/arm/mach-rockchip/rk3188/rk3188.c
index 95f0e3ccbead..1b012f7f67ae 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 cd0bf8a70cc0..562117e6c13a 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 057ce920809e..987b4e0d58c2 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/rk3328/rk3328.c 
b/arch/arm/mach-rockchip/rk3328/rk3328.c
index c2448d727302..8c81242e5d4b 100644
--- a/arch/arm/mach-rockchip/rk3328/rk3328.c
+++ b/arch/arm/mach-rockchip/rk3328/rk3328.c
@@ -19,8 +19,8 @@ DECLARE_GLOBAL_DATA_PTR;
 #define FW_DDR_CON_REG 0xFF7C0040
 
 const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
-   [BROM_BOOTSOURCE_EMMC] = "rksdmmc@ff52",
-   [BROM_BOOTSOURCE_SD] = "rksdmmc@ff50",
+   [BROM_BOOTSOURCE_EMMC] = "/rksdmmc@ff52",
+   [BROM_BOOTSOURCE_SD] = "/rksdmmc@ff50",
 };
 
 static struct mm_region rk3328_mem_map[] = {
diff --git a/arch/arm/mach-rockchip/rk3368/rk3368.c 
b/arch/arm/mach-rockchip/rk3368/rk3368.c
index 7ccd417a18ce..20ae79779473 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.23.0.37.g745f6812895b



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

Re: [U-Boot] [PATCH] nvme: add more cache flushes

[Patrick Wildt]

On Thu, Oct 17, 2019 at 03:08:59PM +0800, Bin Meng wrote:
> Hi Patrick,
> 
> On Thu, Oct 17, 2019 at 2:44 PM Patrick Wildt  wrote:
> >
> > On Thu, Oct 17, 2019 at 10:55:11AM +0800, Bin Meng wrote:
> > > Hi Patrick,
> > >
> > > On Wed, Oct 16, 2019 at 11:35 PM Patrick Wildt  wrote:
> > > >
> > > > On Wed, Oct 16, 2019 at 06:11:23PM +0800, Bin Meng wrote:
> > > > > On Mon, Oct 14, 2019 at 7:11 PM Patrick Wildt  
> > > > > wrote:
> > > > > >
> > > > > > On an i.MX8MQ our nvme driver doesn't completely work since we are
> > > > > > missing a few cache flushes.  One is the prp list, which is an extra
> > > > > > buffer that we need to flush before handing it to the hardware.  
> > > > > > Also
> > > > > > the block read/write operations needs more cache flushes on this 
> > > > > > SoC.
> > > > > >
> > > > > > Signed-off-by: Patrick Wildt 
> > > > > > ---
> > > > > >  drivers/nvme/nvme.c | 15 +--
> > > > > >  1 file changed, 9 insertions(+), 6 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
> > > > > > index 2444e0270f..69d5e3eedc 100644
> > > > > > --- a/drivers/nvme/nvme.c
> > > > > > +++ b/drivers/nvme/nvme.c
> > > > > > @@ -123,6 +123,9 @@ static int nvme_setup_prps(struct nvme_dev 
> > > > > > *dev, u64 *prp2,
> > > > > > }
> > > > > > *prp2 = (ulong)dev->prp_pool;
> > > > > >
> > > > > > +   flush_dcache_range((ulong)dev->prp_pool, 
> > > > > > (ulong)dev->prp_pool +
> > > > > > +  dev->prp_entry_num * sizeof(u64));
> > > > > > +
> > > > > > return 0;
> > > > > >  }
> > > > > >
> > > > > > @@ -717,9 +720,10 @@ static ulong nvme_blk_rw(struct udevice *udev, 
> > > > > > lbaint_t blknr,
> > > > > > u16 lbas = 1 << (dev->max_transfer_shift - ns->lba_shift);
> > > > > > u64 total_lbas = blkcnt;
> > > > > >
> > > > > > -   if (!read)
> > > > > > -   flush_dcache_range((unsigned long)buffer,
> > > > > > -  (unsigned long)buffer + 
> > > > > > total_len);
> > > > > > +   flush_dcache_range((unsigned long)buffer,
> > > > > > +  (unsigned long)buffer + total_len);
> > > > >
> > > > > Why we need this for read?
> > > >
> > > > I'm no processor engineer, but I have read (and "seen") the following
> > > > on ARMs.  If I'm wrong. please correct me.
> > > >
> > > > Since the buffer is usually allocated cache-aligned on the stack,
> > > > it is very possible that this buffer was previously still used
> > > > as it's supposed to be used: as stack.  Thus, the caches can still
> > > > be filled, and are not yet evicted/flushed to memory.  Now it is
> > > > possible that between the DMA access from the device and our cache
> > > > invalidation, the CPU cache writes back its contents to memory,
> > > > overwriting whatever the NVMe just gave us.
> > >
> > > OK, this makes sense. So if we allocate the buffer from the heap, we
> > > should only care about flush on write, right? Can you test this?
> >
> > If you're talking about having a bounce buffer:  You'd need to flush
> > it once upon allocation, because that part of the heap could have also
> > be used earlier by someone else.
> >
> 
> I was not talking about bounce buffer. I mean the buffer allocated
> from help and use that directly for DMA.
> 
> Regards,
> Bin

If you allocate a buffer from the heap, you still need to make sure
to flush it once, since there's still the chance that you have used
it shortly earlier.  But it's less of an issue as on the stack.

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

Re: [U-Boot] [PATCH] nvme: add more cache flushes

[Bin Meng]

Hi Patrick,

On Thu, Oct 17, 2019 at 2:44 PM Patrick Wildt  wrote:
>
> On Thu, Oct 17, 2019 at 10:55:11AM +0800, Bin Meng wrote:
> > Hi Patrick,
> >
> > On Wed, Oct 16, 2019 at 11:35 PM Patrick Wildt  wrote:
> > >
> > > On Wed, Oct 16, 2019 at 06:11:23PM +0800, Bin Meng wrote:
> > > > On Mon, Oct 14, 2019 at 7:11 PM Patrick Wildt  wrote:
> > > > >
> > > > > On an i.MX8MQ our nvme driver doesn't completely work since we are
> > > > > missing a few cache flushes.  One is the prp list, which is an extra
> > > > > buffer that we need to flush before handing it to the hardware.  Also
> > > > > the block read/write operations needs more cache flushes on this SoC.
> > > > >
> > > > > Signed-off-by: Patrick Wildt 
> > > > > ---
> > > > >  drivers/nvme/nvme.c | 15 +--
> > > > >  1 file changed, 9 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
> > > > > index 2444e0270f..69d5e3eedc 100644
> > > > > --- a/drivers/nvme/nvme.c
> > > > > +++ b/drivers/nvme/nvme.c
> > > > > @@ -123,6 +123,9 @@ static int nvme_setup_prps(struct nvme_dev *dev, 
> > > > > u64 *prp2,
> > > > > }
> > > > > *prp2 = (ulong)dev->prp_pool;
> > > > >
> > > > > +   flush_dcache_range((ulong)dev->prp_pool, (ulong)dev->prp_pool 
> > > > > +
> > > > > +  dev->prp_entry_num * sizeof(u64));
> > > > > +
> > > > > return 0;
> > > > >  }
> > > > >
> > > > > @@ -717,9 +720,10 @@ static ulong nvme_blk_rw(struct udevice *udev, 
> > > > > lbaint_t blknr,
> > > > > u16 lbas = 1 << (dev->max_transfer_shift - ns->lba_shift);
> > > > > u64 total_lbas = blkcnt;
> > > > >
> > > > > -   if (!read)
> > > > > -   flush_dcache_range((unsigned long)buffer,
> > > > > -  (unsigned long)buffer + total_len);
> > > > > +   flush_dcache_range((unsigned long)buffer,
> > > > > +  (unsigned long)buffer + total_len);
> > > >
> > > > Why we need this for read?
> > >
> > > I'm no processor engineer, but I have read (and "seen") the following
> > > on ARMs.  If I'm wrong. please correct me.
> > >
> > > Since the buffer is usually allocated cache-aligned on the stack,
> > > it is very possible that this buffer was previously still used
> > > as it's supposed to be used: as stack.  Thus, the caches can still
> > > be filled, and are not yet evicted/flushed to memory.  Now it is
> > > possible that between the DMA access from the device and our cache
> > > invalidation, the CPU cache writes back its contents to memory,
> > > overwriting whatever the NVMe just gave us.
> >
> > OK, this makes sense. So if we allocate the buffer from the heap, we
> > should only care about flush on write, right? Can you test this?
>
> If you're talking about having a bounce buffer:  You'd need to flush
> it once upon allocation, because that part of the heap could have also
> be used earlier by someone else.
>

I was not talking about bounce buffer. I mean the buffer allocated
from help and use that directly for DMA.

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

Re: [U-Boot] [PATCH v1 06/11] lib: add asn1 decoder

[AKASHI Takahiro]

On Sat, Oct 12, 2019 at 02:29:49PM +0200, Heinrich Schuchardt wrote:
> On 10/11/19 9:41 AM, AKASHI Takahiro wrote:
> >Imported from linux kernel v5.3.
> >
> >Signed-off-by: AKASHI Takahiro 
> >---
> >  lib/Kconfig|   6 +
> >  lib/Makefile   |   1 +
> >  lib/asn1_decoder.c | 527 +
> 
> Except for adjustments of include files lib/asn1_decoder.c is a
> verbatime copy of the Linux kernel file. OK.
> 
> >  3 files changed, 534 insertions(+)
> >  create mode 100644 lib/asn1_decoder.c
> >
> >diff --git a/lib/Kconfig b/lib/Kconfig
> >index 3da45a5ec322..26c94f49ecd2 100644
> >--- a/lib/Kconfig
> >+++ b/lib/Kconfig
> >@@ -521,6 +521,12 @@ config SMBIOS_PRODUCT_NAME
> >
> >  endmenu
> >
> >+config ASN1
> >+bool
> >+select BUILD_ASN1
> 
> BUILD_ASN1 does not really fit into cmd/Kconfig.

I just follows the way of BUILD_BIN2C, but

> Should we move it here?

yeah, bin2c is only used under cmd and so moving BUILD_ASN1
to lib/ is fine to me.

> Why do we need two separate flags ASN1 and BUILD_ASN1?

My intension here is that CONFIG_ASN1 is for asn1_decoder.o and
CONFIG_BUILD_ASN1 is for asn1 compiler.
(lib/Makefile is wrong in this sense.)
I believe that having different config's here makes sense
as those two targets are closely related but different objects.

So I will change their names to clarify this.

-Takahiro Akashi

> Best regards
> 
> Heinrich
> 
> >+help
> >+  Enable asn1 decoder library.
> >+
> >  source lib/efi/Kconfig
> >  source lib/efi_loader/Kconfig
> >  source lib/optee/Kconfig
> >diff --git a/lib/Makefile b/lib/Makefile
> >index 2fffd68f943c..eb3a675fb8c2 100644
> >--- a/lib/Makefile
> >+++ b/lib/Makefile
> >@@ -17,6 +17,7 @@ obj-$(CONFIG_OF_LIVE) += of_live.o
> >  obj-$(CONFIG_CMD_DHRYSTONE) += dhry/
> >  obj-$(CONFIG_ARCH_AT91) += at91/
> >  obj-$(CONFIG_OPTEE) += optee/
> >+obj-$(CONFIG_BUILD_ASN1) += asn1_decoder.o
> >
> >  obj-$(CONFIG_AES) += aes.o
> >
> >diff --git a/lib/asn1_decoder.c b/lib/asn1_decoder.c
> >new file mode 100644
> >index ..db222625dd0f
> >--- /dev/null
> >+++ b/lib/asn1_decoder.c
> >@@ -0,0 +1,527 @@
> >+// SPDX-License-Identifier: GPL-2.0-or-later
> >+/* Decoder for ASN.1 BER/DER/CER encoded bytestream
> >+ *
> >+ * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
> >+ * Written by David Howells (dhowe...@redhat.com)
> >+ */
> >+
> >+#ifdef __UBOOT__
> >+#include 
> >+#else
> >+#include 
> >+#endif
> >+#include 
> >+#include 
> >+#ifndef __UBOOT__
> >+#include 
> >+#endif
> >+#include 
> >+#include 
> >+
> >+static const unsigned char asn1_op_lengths[ASN1_OP__NR] = {
> >+/*  OPC TAG JMP ACT */
> >+[ASN1_OP_MATCH] = 1 + 1,
> >+[ASN1_OP_MATCH_OR_SKIP] = 1 + 1,
> >+[ASN1_OP_MATCH_ACT] = 1 + 1 + 1,
> >+[ASN1_OP_MATCH_ACT_OR_SKIP] = 1 + 1 + 1,
> >+[ASN1_OP_MATCH_JUMP]= 1 + 1 + 1,
> >+[ASN1_OP_MATCH_JUMP_OR_SKIP]= 1 + 1 + 1,
> >+[ASN1_OP_MATCH_ANY] = 1,
> >+[ASN1_OP_MATCH_ANY_OR_SKIP] = 1,
> >+[ASN1_OP_MATCH_ANY_ACT] = 1 + 1,
> >+[ASN1_OP_MATCH_ANY_ACT_OR_SKIP] = 1 + 1,
> >+[ASN1_OP_COND_MATCH_OR_SKIP]= 1 + 1,
> >+[ASN1_OP_COND_MATCH_ACT_OR_SKIP]= 1 + 1 + 1,
> >+[ASN1_OP_COND_MATCH_JUMP_OR_SKIP]   = 1 + 1 + 1,
> >+[ASN1_OP_COND_MATCH_ANY]= 1,
> >+[ASN1_OP_COND_MATCH_ANY_OR_SKIP]= 1,
> >+[ASN1_OP_COND_MATCH_ANY_ACT]= 1 + 1,
> >+[ASN1_OP_COND_MATCH_ANY_ACT_OR_SKIP]= 1 + 1,
> >+[ASN1_OP_COND_FAIL] = 1,
> >+[ASN1_OP_COMPLETE]  = 1,
> >+[ASN1_OP_ACT]   = 1 + 1,
> >+[ASN1_OP_MAYBE_ACT] = 1 + 1,
> >+[ASN1_OP_RETURN]= 1,
> >+[ASN1_OP_END_SEQ]   = 1,
> >+[ASN1_OP_END_SEQ_OF]= 1 + 1,
> >+[ASN1_OP_END_SET]   = 1,
> >+[ASN1_OP_END_SET_OF]= 1 + 1,
> >+[ASN1_OP_END_SEQ_ACT]   = 1 + 1,
> >+[ASN1_OP_END_SEQ_OF_ACT]= 1 + 1 + 1,
> >+[ASN1_OP_END_SET_ACT]   = 1 + 1,
> >+[ASN1_OP_END_SET_OF_ACT]= 1 + 1 + 1,
> >+};
> >+
> >+/*
> >+ * Find the length of an indefinite length object
> >+ * @data: The data buffer
> >+ * @datalen: The end of the innermost containing element in the buffer
> >+ * @_dp: The data parse cursor (updated before returning)
> >+ * @_len: Where to return the size of the element.
> >+ * @_errmsg: Where to return a pointer to an error message on error
> >+ */
> >+static int asn1_find_indefinite_length(const unsigned char *data, size_t 
> >datalen,
> >+  

Re: [U-Boot] [PATCH] nvme: add more cache flushes

[Simon Goldschmidt]

On Thu, Oct 17, 2019 at 8:44 AM Patrick Wildt  wrote:
>
> On Thu, Oct 17, 2019 at 10:55:11AM +0800, Bin Meng wrote:
> > Hi Patrick,
> >
> > On Wed, Oct 16, 2019 at 11:35 PM Patrick Wildt  wrote:
> > >
> > > On Wed, Oct 16, 2019 at 06:11:23PM +0800, Bin Meng wrote:
> > > > On Mon, Oct 14, 2019 at 7:11 PM Patrick Wildt  wrote:
> > > > >
> > > > > On an i.MX8MQ our nvme driver doesn't completely work since we are
> > > > > missing a few cache flushes.  One is the prp list, which is an extra
> > > > > buffer that we need to flush before handing it to the hardware.  Also
> > > > > the block read/write operations needs more cache flushes on this SoC.
> > > > >
> > > > > Signed-off-by: Patrick Wildt 
> > > > > ---
> > > > >  drivers/nvme/nvme.c | 15 +--
> > > > >  1 file changed, 9 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
> > > > > index 2444e0270f..69d5e3eedc 100644
> > > > > --- a/drivers/nvme/nvme.c
> > > > > +++ b/drivers/nvme/nvme.c
> > > > > @@ -123,6 +123,9 @@ static int nvme_setup_prps(struct nvme_dev *dev, 
> > > > > u64 *prp2,
> > > > > }
> > > > > *prp2 = (ulong)dev->prp_pool;
> > > > >
> > > > > +   flush_dcache_range((ulong)dev->prp_pool, (ulong)dev->prp_pool 
> > > > > +
> > > > > +  dev->prp_entry_num * sizeof(u64));
> > > > > +
> > > > > return 0;
> > > > >  }
> > > > >
> > > > > @@ -717,9 +720,10 @@ static ulong nvme_blk_rw(struct udevice *udev, 
> > > > > lbaint_t blknr,
> > > > > u16 lbas = 1 << (dev->max_transfer_shift - ns->lba_shift);
> > > > > u64 total_lbas = blkcnt;
> > > > >
> > > > > -   if (!read)
> > > > > -   flush_dcache_range((unsigned long)buffer,
> > > > > -  (unsigned long)buffer + total_len);
> > > > > +   flush_dcache_range((unsigned long)buffer,
> > > > > +  (unsigned long)buffer + total_len);
> > > >
> > > > Why we need this for read?
> > >
> > > I'm no processor engineer, but I have read (and "seen") the following
> > > on ARMs.  If I'm wrong. please correct me.
> > >
> > > Since the buffer is usually allocated cache-aligned on the stack,
> > > it is very possible that this buffer was previously still used
> > > as it's supposed to be used: as stack.  Thus, the caches can still
> > > be filled, and are not yet evicted/flushed to memory.  Now it is
> > > possible that between the DMA access from the device and our cache
> > > invalidation, the CPU cache writes back its contents to memory,
> > > overwriting whatever the NVMe just gave us.
> >
> > OK, this makes sense. So if we allocate the buffer from the heap, we
> > should only care about flush on write, right? Can you test this?
>
> If you're talking about having a bounce buffer:  You'd need to flush
> it once upon allocation, because that part of the heap could have also
> be used earlier by someone else.

And this is exactly what common/bouncebuf.c does ;-)

Regards,
Simon

>
> Best regards,
> Patrick
>
> > >
> > > > > +   invalidate_dcache_range((unsigned long)buffer,
> > > > > +   (unsigned long)buffer + total_len);
> > > > >
> > > > > c.rw.opcode = read ? nvme_cmd_read : nvme_cmd_write;
> > > > > c.rw.flags = 0;
> > > > > @@ -755,9 +759,8 @@ static ulong nvme_blk_rw(struct udevice *udev, 
> > > > > lbaint_t blknr,
> > > > > buffer += lbas << ns->lba_shift;
> > > > > }
> > > > >
> > > > > -   if (read)
> > > > > -   invalidate_dcache_range((unsigned long)buffer,
> > > > > -   (unsigned long)buffer + 
> > > > > total_len);
> > > > > +   invalidate_dcache_range((unsigned long)buffer,
> > > > > +   (unsigned long)buffer + total_len);
> > > >
> > > > Why we need this for write?
> > >
> > > That's a good point.  After the transaction, if it was a read then
> > > we need to invalidate it, as we might have speculatively read it.
> > > On a write, we don't care about its contents.  I will test it w/o
> > > this chunk and report back.
> > >
> >
> > Regards,
> > Bin
> ___
> 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] [PATCH] nvme: add more cache flushes

[Patrick Wildt]

On Thu, Oct 17, 2019 at 10:55:11AM +0800, Bin Meng wrote:
> Hi Patrick,
> 
> On Wed, Oct 16, 2019 at 11:35 PM Patrick Wildt  wrote:
> >
> > On Wed, Oct 16, 2019 at 06:11:23PM +0800, Bin Meng wrote:
> > > On Mon, Oct 14, 2019 at 7:11 PM Patrick Wildt  wrote:
> > > >
> > > > On an i.MX8MQ our nvme driver doesn't completely work since we are
> > > > missing a few cache flushes.  One is the prp list, which is an extra
> > > > buffer that we need to flush before handing it to the hardware.  Also
> > > > the block read/write operations needs more cache flushes on this SoC.
> > > >
> > > > Signed-off-by: Patrick Wildt 
> > > > ---
> > > >  drivers/nvme/nvme.c | 15 +--
> > > >  1 file changed, 9 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
> > > > index 2444e0270f..69d5e3eedc 100644
> > > > --- a/drivers/nvme/nvme.c
> > > > +++ b/drivers/nvme/nvme.c
> > > > @@ -123,6 +123,9 @@ static int nvme_setup_prps(struct nvme_dev *dev, 
> > > > u64 *prp2,
> > > > }
> > > > *prp2 = (ulong)dev->prp_pool;
> > > >
> > > > +   flush_dcache_range((ulong)dev->prp_pool, (ulong)dev->prp_pool +
> > > > +  dev->prp_entry_num * sizeof(u64));
> > > > +
> > > > return 0;
> > > >  }
> > > >
> > > > @@ -717,9 +720,10 @@ static ulong nvme_blk_rw(struct udevice *udev, 
> > > > lbaint_t blknr,
> > > > u16 lbas = 1 << (dev->max_transfer_shift - ns->lba_shift);
> > > > u64 total_lbas = blkcnt;
> > > >
> > > > -   if (!read)
> > > > -   flush_dcache_range((unsigned long)buffer,
> > > > -  (unsigned long)buffer + total_len);
> > > > +   flush_dcache_range((unsigned long)buffer,
> > > > +  (unsigned long)buffer + total_len);
> > >
> > > Why we need this for read?
> >
> > I'm no processor engineer, but I have read (and "seen") the following
> > on ARMs.  If I'm wrong. please correct me.
> >
> > Since the buffer is usually allocated cache-aligned on the stack,
> > it is very possible that this buffer was previously still used
> > as it's supposed to be used: as stack.  Thus, the caches can still
> > be filled, and are not yet evicted/flushed to memory.  Now it is
> > possible that between the DMA access from the device and our cache
> > invalidation, the CPU cache writes back its contents to memory,
> > overwriting whatever the NVMe just gave us.
> 
> OK, this makes sense. So if we allocate the buffer from the heap, we
> should only care about flush on write, right? Can you test this?

If you're talking about having a bounce buffer:  You'd need to flush
it once upon allocation, because that part of the heap could have also
be used earlier by someone else.

Best regards,
Patrick

> >
> > > > +   invalidate_dcache_range((unsigned long)buffer,
> > > > +   (unsigned long)buffer + total_len);
> > > >
> > > > c.rw.opcode = read ? nvme_cmd_read : nvme_cmd_write;
> > > > c.rw.flags = 0;
> > > > @@ -755,9 +759,8 @@ static ulong nvme_blk_rw(struct udevice *udev, 
> > > > lbaint_t blknr,
> > > > buffer += lbas << ns->lba_shift;
> > > > }
> > > >
> > > > -   if (read)
> > > > -   invalidate_dcache_range((unsigned long)buffer,
> > > > -   (unsigned long)buffer + 
> > > > total_len);
> > > > +   invalidate_dcache_range((unsigned long)buffer,
> > > > +   (unsigned long)buffer + total_len);
> > >
> > > Why we need this for write?
> >
> > That's a good point.  After the transaction, if it was a read then
> > we need to invalidate it, as we might have speculatively read it.
> > On a write, we don't care about its contents.  I will test it w/o
> > this chunk and report back.
> >
> 
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] stm32mp1: configs: Add CONFIG_SPL_SPI_FLASH_MTD

[Schrempf Frieder]

Hi Jagan,

On 16.10.19 18:34, Jagan Teki wrote:
> On Sat, Sep 14, 2019 at 4:18 AM Schrempf Frieder
>  wrote:
>>
>> From: Frieder Schrempf 
>>
>> As SPI_FLASH_MTD is used in SPL and U-Boot proper, we enable both,
>> now that a separate option for SPL was introduced.
>>
>> Signed-off-by: Frieder Schrempf 
>> ---
>>   configs/stm32mp15_basic_defconfig | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/configs/stm32mp15_basic_defconfig 
>> b/configs/stm32mp15_basic_defconfig
>> index 09785b5dc1..390319657f 100644
>> --- a/configs/stm32mp15_basic_defconfig
>> +++ b/configs/stm32mp15_basic_defconfig
>> @@ -7,10 +7,10 @@ CONFIG_TARGET_STM32MP1=y
>>   CONFIG_SPL_SPI_FLASH_SUPPORT=y
>>   CONFIG_SPL_SPI_SUPPORT=y
>>   # CONFIG_ARMV7_VIRT is not set
>> +CONFIG_SPL_TEXT_BASE=0x2FFC2500
>>   CONFIG_DISTRO_DEFAULTS=y
>>   CONFIG_FIT=y
>>   CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
>> -CONFIG_SPL_TEXT_BASE=0x2FFC2500
> 
> Unrelated change wrt to commit message?

Yes, this is unrelated, but that's what 'menuconfig' and 'savedefconfig' 
gave me as output. So I would think it's ok. If you don't think so, feel 
free to remove this change or let me know if I should remove it.

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

Re: [U-Boot] [PATCH v1 05/11] Makefile: add build script for asn1 parsers

[AKASHI Takahiro]

On Sat, Oct 12, 2019 at 02:36:48PM +0200, Heinrich Schuchardt wrote:
> On 10/11/19 9:41 AM, AKASHI Takahiro wrote:
> >This rule will be used to build x509 and pkcs7 parsers.
> >
> >Signed-off-by: AKASHI Takahiro 
> 
> The ASN1 compiler is generating both *.asn.h and *.asn.c files.
> 
> Then I would expect that these files are deleted by `make mrproper'.
> 
> Please, adjust the clean: target in /Makefile accordingly.

Good catch, thank you.

-Takahiro Akashi

> Best regards
> 
> Heinrich
> 
> >---
> >  scripts/Makefile.build | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> >diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> >index f7a041296d3d..9357d310e50b 100644
> >--- a/scripts/Makefile.build
> >+++ b/scripts/Makefile.build
> >@@ -331,7 +331,7 @@ quiet_cmd_asn1_compiler = ASN.1   $@
> >cmd_asn1_compiler = $(objtree)/scripts/asn1_compiler $< \
> > $(subst .h,.c,$@) $(subst .c,.h,$@)
> >
> >-$(obj)/%-asn1.c $(obj)/%-asn1.h: $(src)/%.asn1 
> >$(objtree)/scripts/asn1_compiler
> >+$(obj)/%.asn1.c $(obj)/%.asn1.h: $(src)/%.asn1 
> >$(objtree)/scripts/asn1_compiler
> > $(call cmd,asn1_compiler)
> >
> >  # Build the compiled-in targets
> >@@ -419,9 +419,11 @@ targets += $(multi-used-y) $(multi-used-m)
> >  intermediate_targets = $(foreach sfx, $(2), \
> > $(patsubst %$(strip $(1)),%$(sfx), \
> > $(filter %$(strip $(1)), $(targets
> >+# %.asn1.o <- %.asn1.[ch] <- %.asn1
> >  # %.lex.o <- %.lex.c <- %.l
> >  # %.tab.o <- %.tab.[ch] <- %.y
> >-targets += $(call intermediate_targets, .lex.o, .lex.c) \
> >+targets += $(call intermediate_targets, .asn1.o, .asn1.c .asn1.h) \
> >+   $(call intermediate_targets, .lex.o, .lex.c) \
> >$(call intermediate_targets, .tab.o, .tab.c .tab.h)
> >
> >  # Descending
> >
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 04/11] cmd: add asn1_compiler

[AKASHI Takahiro]

On Sat, Oct 12, 2019 at 02:22:14PM +0200, Heinrich Schuchardt wrote:
> On 10/11/19 9:41 AM, AKASHI Takahiro wrote:
> >Imported from linux kernel v5.3.
> >
> >This host command will be used to create a ASN1 parser, for example,
> >for pkcs7 or x509.
> >
> >Signed-off-by: AKASHI Takahiro 
> >---
> >  cmd/Kconfig   |3 +
> >  include/linux/asn1.h  |   65 ++
> >  include/linux/asn1_ber_bytecode.h |   89 ++
> >  include/linux/asn1_decoder.h  |   20 +
> >  scripts/Makefile  |3 +
> >  scripts/asn1_compiler.c   | 1611 +
> 
> Except for Makefile and Kconfig these are verbatime copies of the Linux
> files. OK.
> 
> >  6 files changed, 1791 insertions(+)
> >  create mode 100644 include/linux/asn1.h
> >  create mode 100644 include/linux/asn1_ber_bytecode.h
> >  create mode 100644 include/linux/asn1_decoder.h
> >  create mode 100644 scripts/asn1_compiler.c
> >
> >diff --git a/cmd/Kconfig b/cmd/Kconfig
> >index 4e61565aab16..605dcfdf4282 100644
> >--- a/cmd/Kconfig
> >+++ b/cmd/Kconfig
> >@@ -184,6 +184,9 @@ endmenu
> >  config BUILD_BIN2C
> > bool
> >
> >+config BUILD_ASN1
> >+bool
> >+
> >  comment "Commands"
> >
> >  menu "Info commands"
> >diff --git a/include/linux/asn1.h b/include/linux/asn1.h
> >new file mode 100644
> >index ..a4d0bdd10711
> >--- /dev/null
> >+++ b/include/linux/asn1.h
> >@@ -0,0 +1,65 @@
> >+/* SPDX-License-Identifier: GPL-2.0-or-later */
> >+/* ASN.1 BER/DER/CER encoding definitions
> >+ *
> >+ * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
> >+ * Written by David Howells (dhowe...@redhat.com)
> >+ */
> >+
> >+#ifndef _LINUX_ASN1_H
> >+#define _LINUX_ASN1_H
> >+
> >+/* Class */
> >+enum asn1_class {
> >+ASN1_UNIV   = 0,/* Universal */
> >+ASN1_APPL   = 1,/* Application */
> >+ASN1_CONT   = 2,/* Context */
> >+ASN1_PRIV   = 3 /* Private */
> >+};
> >+#define ASN1_CLASS_BITS 0xc0
> >+
> >+
> >+enum asn1_method {
> >+ASN1_PRIM   = 0,/* Primitive */
> >+ASN1_CONS   = 1 /* Constructed */
> >+};
> >+#define ASN1_CONS_BIT   0x20
> >+
> >+/* Tag */
> >+enum asn1_tag {
> >+ASN1_EOC= 0,/* End Of Contents or N/A */
> >+ASN1_BOOL   = 1,/* Boolean */
> >+ASN1_INT= 2,/* Integer */
> >+ASN1_BTS= 3,/* Bit String */
> >+ASN1_OTS= 4,/* Octet String */
> >+ASN1_NULL   = 5,/* Null */
> >+ASN1_OID= 6,/* Object Identifier  */
> >+ASN1_ODE= 7,/* Object Description */
> >+ASN1_EXT= 8,/* External */
> >+ASN1_REAL   = 9,/* Real float */
> >+ASN1_ENUM   = 10,   /* Enumerated */
> >+ASN1_EPDV   = 11,   /* Embedded PDV */
> >+ASN1_UTF8STR= 12,   /* UTF8 String */
> >+ASN1_RELOID = 13,   /* Relative OID */
> >+/* 14 - Reserved */
> >+/* 15 - Reserved */
> >+ASN1_SEQ= 16,   /* Sequence and Sequence of */
> >+ASN1_SET= 17,   /* Set and Set of */
> >+ASN1_NUMSTR = 18,   /* Numerical String */
> >+ASN1_PRNSTR = 19,   /* Printable String */
> >+ASN1_TEXSTR = 20,   /* T61 String / Teletext String */
> >+ASN1_VIDSTR = 21,   /* Videotex String */
> >+ASN1_IA5STR = 22,   /* IA5 String */
> >+ASN1_UNITIM = 23,   /* Universal Time */
> >+ASN1_GENTIM = 24,   /* General Time */
> >+ASN1_GRASTR = 25,   /* Graphic String */
> >+ASN1_VISSTR = 26,   /* Visible String */
> >+ASN1_GENSTR = 27,   /* General String */
> >+ASN1_UNISTR = 28,   /* Universal String */
> >+ASN1_CHRSTR = 29,   /* Character String */
> >+ASN1_BMPSTR = 30,   /* BMP String */
> >+ASN1_LONG_TAG   = 31/* Long form tag */
> >+};
> >+
> >+#define ASN1_INDEFINITE_LENGTH 0x80
> >+
> >+#endif /* _LINUX_ASN1_H */
> >diff --git a/include/linux/asn1_ber_bytecode.h 
> >b/include/linux/asn1_ber_bytecode.h
> >new file mode 100644
> >index ..b38361953a48
> >--- /dev/null
> >+++ b/include/linux/asn1_ber_bytecode.h
> >@@ -0,0 +1,89 @@
> >+/* SPDX-License-Identifier: GPL-2.0-or-later */
> >+/* ASN.1 BER/DER/CER parsing state machine internal definitions
> >+ *
> >+ * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
> >+ * Written by David Howells (dhowe...@redhat.com)
> >+ */
> >+
> >+#ifndef _LINUX_ASN1_BER_BYTECODE_H
> >+#define _LINUX_ASN1_BER_BYTECODE_H
> >+
> >+#ifdef __KERNEL__
> >+#include 
> >+#endif
> >+#include 
> >+
> >+typedef int (*asn1_action_t)(void *context,
> >+ size_t hdrlen, /* In case of ANY type */
> >+ unsigned char tag, /* In case of ANY type */
> >+ const void *value, size_t vlen);
> >+
> >+struct asn1_decoder {
> >+const unsigned char *machine;
> >+size_t machlen;
> >+const asn1_action_t *actions;
> >+};
> >+
> >+enum asn1_opcode {
> >+/* 

Re: [U-Boot] [PATCH v1 03/11] include: kernel.h: include printk.h

[AKASHI Takahiro]

On Thu, Oct 17, 2019 at 02:58:45PM +0900, AKASHI Takahiro wrote:
> On Sat, Oct 12, 2019 at 01:47:06PM +0200, Heinrich Schuchardt wrote:
> > On 10/11/19 9:41 AM, AKASHI Takahiro wrote:
> > >Adding "printk.h" will help improve portability from linux kernel
> > >code (in my case, lib/asn1_decoder.c).
> > >
> > >Signed-off-by: AKASHI Takahiro 
> > >---
> > >  include/linux/kernel.h | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > >diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> > >index a85c15d8dc28..919d12bdf89c 100644
> > >--- a/include/linux/kernel.h
> > >+++ b/include/linux/kernel.h
> > >@@ -2,7 +2,9 @@
> > >  #define _LINUX_KERNEL_H
> > >
> > >
> > >+#include  /* for printf utilities */
> > 
> > Kernel code has no vsprintf.h. Linux's lib/asn1_decoder.c has not a
> > single print statement. So why are you inserting vsprintf.h here?
> 
> I don't remember why I mentioned to asn1_decoder.c here, but

For the record, asn1_parser.c uses pr_debug/pr_devel and others
in many places.

-Takahiro Akashi

> When this statement is removed from kernel.h, some files cannot
> be compiled.
> The fact is that sprintf() is used in time.h without including any
> related headers.
> (There are still bunch of *missing headers* issues in U-Boot.)
> 
> I will add one more patch against time.h here.
> 
> Thanks,
> -Takahiro Akashi
> 
> 
> > >  #include 
> > >+#include 
> > 
> > Linux include/linux/kernel.h also includes printk.h. OK.
> > 
> > Best regards
> > 
> > Heinrich
> > >
> > >  #define USHRT_MAX((u16)(~0U))
> > >  #define SHRT_MAX ((s16)(USHRT_MAX>>1))
> > >
> > 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot