[U-Boot] [PATCH] ARM: Fix nand boot of imx6q and imx6qdl boards

[Michael Trimarchi]

The nand boot require a little more memory that we had previosly
allocated so it stopped booting.
This patch increase CONFIG_SPL_SYS_MALLOC_F_LEN to 0x2000.

Signed-off-by: Michael Trimarchi 
---
 configs/imx6dl_icore_nand_defconfig | 1 +
 configs/imx6q_icore_nand_defconfig  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/imx6dl_icore_nand_defconfig 
b/configs/imx6dl_icore_nand_defconfig
index c34c515080..69c45b948b 100644
--- a/configs/imx6dl_icore_nand_defconfig
+++ b/configs/imx6dl_icore_nand_defconfig
@@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x1780
 CONFIG_SPL_GPIO_SUPPORT=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_TARGET_MX6Q_ENGICAM=y
 CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_SPL=y
diff --git a/configs/imx6q_icore_nand_defconfig 
b/configs/imx6q_icore_nand_defconfig
index cf149d615b..b53a5010e5 100644
--- a/configs/imx6q_icore_nand_defconfig
+++ b/configs/imx6q_icore_nand_defconfig
@@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x1780
 CONFIG_SPL_GPIO_SUPPORT=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_TARGET_MX6Q_ENGICAM=y
 CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_SPL=y
-- 
2.17.1

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

Re: [U-Boot] [PATCH v4 0/9] arm: exynos: Fix reboot on Odroid HC1

[Krzysztof Kozlowski]

On Wed, 6 Mar 2019 at 08:03, Minkyu Kang  wrote:
>
> Dear Krzysztof Kozlowski,
>
> On 06/03/2019 04:57, Krzysztof Kozlowski wrote:
> > Hi,
> >
> > Changes since v3
> > 
> > 1. Add accumulated review and test tags.
> > 2. Patch 6: Add "ramp" keyword to new function (as discussed with
> >Torsten Duwe).
> > 3. Rebased on v2019.04-rc3.
> >
> >
> > Changes since v2
> > 
> > 1. Add Lukasz review tags.
> > 2. Patch 7: Return on error, as suggested by Simon.
> > 2. Patch 3: Use IS_ENABLED() to run revision detection only
> >once - either during late display board or misc_init_r.
> >
> > Changes since v1
> > 
> > 1. Move fixes to beginning of patchset.
> > 2. Patch 3: Rework the idea - split revision detection to be executed later.
> > 3. Patch 4: New patch.
> > 4. Patch 6: Apply Simon's comments.
> > 5. Patch 6: Do not delay when changing voltage if regulator is disabled.
> > 6. Patch 6: Do not delay when disabling the regulator.
> >
> >
> > Description
> > ===
> > Odroid HC1 does not reboot properly (at least from SD card but
> > I do not expect difference on eMMC), if LDO4/VDD_ADC was turned
> > off by Linux kernel.  This condition happens so far always, because
> > Linux kernel did not enable ADC on Odroid HC1, therefore the
> > VDD_ADC regulator was turned off as unused.
> >
> > The issue is in detection of revision which later is used to load
> > proper DTB.
> >
> > The revision is obtained by ADC read of a voltage depending on VDD_ADC.
> > Therefore:
> > 1. VDD_ADC has to be turned on (but board detection happens before
> >power is initialized),
> > 2. Turning VDD_ADC should wait with ramp delay,
> > 3. Reading the value from ADC should wait for it to stabilize.
> >
> > Tested on Odroid XU3-Lite and Odroid HC1.
> >
> > Comments and testing are welcomed.
> >
> > Best regards,
> > Krzysztof
> >
> > Krzysztof Kozlowski (9):
> >   adc: exynos-adc: Fix wrong bit operation used to stop the ADC
> >   power: regulator: s2mps11: Fix step for LDO27 and LDO35
> >   arm: exynos: Detect revision later, when all resources are ready
> >   arm: exynos: odroid-xu3: Display info late to have proper type
> >   arm: exynos: Wait till ADC stabilizes before checking Odroid HC1
> > revision
> >   regulator: Add support for ramp delay
> >   power: regulator: s2mps11: Add enable delay
> >   arm: dts: exynos: Add supply for ADC block to Odroid XU3 family
> >   arm: dts: exynos: Add ramp delay property to LDO regulators to Odroid
> > XU3 family
> >
> >  arch/arm/dts/exynos5422-odroidxu3.dts | 20 +++
> >  board/samsung/common/board.c  | 24 -
> >  board/samsung/common/exynos5-dt-types.c   | 54 +--
> >  board/samsung/odroid/odroid.c |  8 +++
> >  configs/odroid-xu3_defconfig  |  2 +
> >  .../regulator/regulator.txt   |  2 +
> >  drivers/adc/exynos-adc.c  |  2 +-
> >  drivers/power/regulator/regulator-uclass.c| 47 +++-
> >  drivers/power/regulator/s2mps11_regulator.c   | 15 +-
> >  include/power/regulator.h |  2 +
> >  include/samsung/misc.h|  1 +
> >  11 files changed, 167 insertions(+), 10 deletions(-)
> >
>
> Build was failed after apply your patch on trats, trats2 and 
> s5pc210_universal.
> Please check.
>
> board/samsung/common/built-in.o: In function `misc_init_r':
> /home/share/Work/u-boot-samsung/board/samsung/common/board.c:307: undefined 
> reference to `set_board_revision'

Indeed, I need to update other boards as well.
I'll fix it.

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

Re: [U-Boot] [PATCH v4 0/9] arm: exynos: Fix reboot on Odroid HC1

[Minkyu Kang]

Dear Krzysztof Kozlowski,

On 06/03/2019 04:57, Krzysztof Kozlowski wrote:
> Hi,
> 
> Changes since v3
> 
> 1. Add accumulated review and test tags.
> 2. Patch 6: Add "ramp" keyword to new function (as discussed with
>Torsten Duwe).
> 3. Rebased on v2019.04-rc3.
> 
> 
> Changes since v2
> 
> 1. Add Lukasz review tags.
> 2. Patch 7: Return on error, as suggested by Simon.
> 2. Patch 3: Use IS_ENABLED() to run revision detection only
>once - either during late display board or misc_init_r.
> 
> Changes since v1
> 
> 1. Move fixes to beginning of patchset.
> 2. Patch 3: Rework the idea - split revision detection to be executed later.
> 3. Patch 4: New patch.
> 4. Patch 6: Apply Simon's comments.
> 5. Patch 6: Do not delay when changing voltage if regulator is disabled.
> 6. Patch 6: Do not delay when disabling the regulator.
> 
> 
> Description
> ===
> Odroid HC1 does not reboot properly (at least from SD card but
> I do not expect difference on eMMC), if LDO4/VDD_ADC was turned
> off by Linux kernel.  This condition happens so far always, because
> Linux kernel did not enable ADC on Odroid HC1, therefore the
> VDD_ADC regulator was turned off as unused.
> 
> The issue is in detection of revision which later is used to load
> proper DTB.
> 
> The revision is obtained by ADC read of a voltage depending on VDD_ADC.
> Therefore:
> 1. VDD_ADC has to be turned on (but board detection happens before
>power is initialized),
> 2. Turning VDD_ADC should wait with ramp delay,
> 3. Reading the value from ADC should wait for it to stabilize.
> 
> Tested on Odroid XU3-Lite and Odroid HC1.
> 
> Comments and testing are welcomed.
> 
> Best regards,
> Krzysztof
> 
> Krzysztof Kozlowski (9):
>   adc: exynos-adc: Fix wrong bit operation used to stop the ADC
>   power: regulator: s2mps11: Fix step for LDO27 and LDO35
>   arm: exynos: Detect revision later, when all resources are ready
>   arm: exynos: odroid-xu3: Display info late to have proper type
>   arm: exynos: Wait till ADC stabilizes before checking Odroid HC1
> revision
>   regulator: Add support for ramp delay
>   power: regulator: s2mps11: Add enable delay
>   arm: dts: exynos: Add supply for ADC block to Odroid XU3 family
>   arm: dts: exynos: Add ramp delay property to LDO regulators to Odroid
> XU3 family
> 
>  arch/arm/dts/exynos5422-odroidxu3.dts | 20 +++
>  board/samsung/common/board.c  | 24 -
>  board/samsung/common/exynos5-dt-types.c   | 54 +--
>  board/samsung/odroid/odroid.c |  8 +++
>  configs/odroid-xu3_defconfig  |  2 +
>  .../regulator/regulator.txt   |  2 +
>  drivers/adc/exynos-adc.c  |  2 +-
>  drivers/power/regulator/regulator-uclass.c| 47 +++-
>  drivers/power/regulator/s2mps11_regulator.c   | 15 +-
>  include/power/regulator.h |  2 +
>  include/samsung/misc.h|  1 +
>  11 files changed, 167 insertions(+), 10 deletions(-)
> 

Build was failed after apply your patch on trats, trats2 and s5pc210_universal.
Please check.

board/samsung/common/built-in.o: In function `misc_init_r':
/home/share/Work/u-boot-samsung/board/samsung/common/board.c:307: undefined 
reference to `set_board_revision'

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

[U-Boot] [PATCH] armv7: ls102xa: Add workaround for DDR erratum A-008850

[Alison Wang]

Barrier transactions from CCI400 need to be disabled till
the DDR is configured, otherwise it may lead to system hang.
The patch adds workaround to fix the erratum.

Signed-off-by: Shengzhou Liu 
Signed-off-by: Alison Wang 
---
 arch/arm/cpu/armv7/ls102xa/Kconfig|  6 +++
 arch/arm/cpu/armv7/ls102xa/soc.c  | 44 ---
 .../include/asm/arch-ls102xa/ls102xa_soc.h|  2 +
 board/freescale/ls1021aiot/ls1021aiot.c   |  2 +
 board/freescale/ls1021aqds/ddr.c  |  2 +
 board/freescale/ls1021aqds/ddr.h  |  3 ++
 board/freescale/ls1021aqds/ls1021aqds.c   | 30 -
 board/freescale/ls1021atwr/ls1021atwr.c   |  2 +
 include/configs/ls1021aiot.h  |  2 +
 include/configs/ls1021atwr.h  |  2 +
 10 files changed, 58 insertions(+), 37 deletions(-)

diff --git a/arch/arm/cpu/armv7/ls102xa/Kconfig 
b/arch/arm/cpu/armv7/ls102xa/Kconfig
index 5d6a711c14..94fa68250d 100644
--- a/arch/arm/cpu/armv7/ls102xa/Kconfig
+++ b/arch/arm/cpu/armv7/ls102xa/Kconfig
@@ -4,6 +4,7 @@ config ARCH_LS1021A
select SYS_FSL_DDR_VER_50 if SYS_FSL_DDR
select SYS_FSL_ERRATUM_A008378
select SYS_FSL_ERRATUM_A008407
+   select SYS_FSL_ERRATUM_A008850
select SYS_FSL_ERRATUM_A008997
select SYS_FSL_ERRATUM_A009007
select SYS_FSL_ERRATUM_A009008
@@ -63,6 +64,11 @@ config SYS_CCI400_OFFSET
  Offset for CCI400 base.
  CCI400 base addr = CCSRBAR + CCI400_OFFSET
 
+config SYS_FSL_ERRATUM_A008850
+   bool
+   help
+ Workaround for DDR erratum A008850
+
 config SYS_FSL_ERRATUM_A008997
bool
help
diff --git a/arch/arm/cpu/armv7/ls102xa/soc.c b/arch/arm/cpu/armv7/ls102xa/soc.c
index 448d951c36..a779d33739 100644
--- a/arch/arm/cpu/armv7/ls102xa/soc.c
+++ b/arch/arm/cpu/armv7/ls102xa/soc.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct liodn_id_table sec_liodn_tbl[] = {
SET_SEC_JR_LIODN_ENTRY(0, 0x10, 0x10),
@@ -103,6 +104,41 @@ static void erratum_a009007(void)
 #endif /* CONFIG_SYS_FSL_ERRATUM_A009007 */
 }
 
+static void erratum_a008850_early(void)
+{
+#ifdef CONFIG_SYS_FSL_ERRATUM_A008850
+   /* part 1 of 2 */
+   struct ccsr_cci400 __iomem *cci = (void *)(CONFIG_SYS_IMMR +
+   CONFIG_SYS_CCI400_OFFSET);
+   struct ccsr_ddr __iomem *ddr = (void *)CONFIG_SYS_FSL_DDR_ADDR;
+
+   /* disables propagation of barrier transactions to DDRC from CCI400 */
+   out_le32(>ctrl_ord, CCI400_CTRLORD_TERM_BARRIER);
+
+   /* disable the re-ordering in DDRC */
+   out_be32(>eor, DDR_EOR_RD_REOD_DIS | DDR_EOR_WD_REOD_DIS);
+#endif
+}
+
+void erratum_a008850_post(void)
+{
+#ifdef CONFIG_SYS_FSL_ERRATUM_A008850
+   /* part 2 of 2 */
+   struct ccsr_cci400 __iomem *cci = (void *)(CONFIG_SYS_IMMR +
+   CONFIG_SYS_CCI400_OFFSET);
+   struct ccsr_ddr __iomem *ddr = (void *)CONFIG_SYS_FSL_DDR_ADDR;
+   u32 tmp;
+
+   /* enable propagation of barrier transactions to DDRC from CCI400 */
+   out_le32(>ctrl_ord, CCI400_CTRLORD_EN_BARRIER);
+
+   /* enable the re-ordering in DDRC */
+   tmp = in_be32(>eor);
+   tmp &= ~(DDR_EOR_RD_REOD_DIS | DDR_EOR_WD_REOD_DIS);
+   out_be32(>eor, tmp);
+#endif
+}
+
 void s_init(void)
 {
 }
@@ -163,13 +199,6 @@ int arch_soc_init(void)
 */
out_le32(>slave[1].sha_ord, CCI400_SHAORD_NON_SHAREABLE);
out_le32(>slave[2].sha_ord, CCI400_SHAORD_NON_SHAREABLE);
-
-   /* Workaround for the issue that DDR could not respond to
-* barrier transaction which is generated by executing DSB/ISB
-* instruction. Set CCI-400 control override register to
-* terminate the barrier transaction. After DDR is initialized,
-* allow barrier transaction to DDR again */
-   out_le32(>ctrl_ord, CCI400_CTRLORD_TERM_BARRIER);
}
 
/* Enable all the snoop signal for various masters */
@@ -191,6 +220,7 @@ int arch_soc_init(void)
out_be32(>eddrtqcfg, 0x63b20042);
 
/* Erratum */
+   erratum_a008850_early();
erratum_a009008();
erratum_a009798();
erratum_a008997();
diff --git a/arch/arm/include/asm/arch-ls102xa/ls102xa_soc.h 
b/arch/arm/include/asm/arch-ls102xa/ls102xa_soc.h
index 05e8b49c2d..1fde8bce5d 100644
--- a/arch/arm/include/asm/arch-ls102xa/ls102xa_soc.h
+++ b/arch/arm/include/asm/arch-ls102xa/ls102xa_soc.h
@@ -10,6 +10,8 @@ unsigned int get_soc_major_rev(void);
 int arch_soc_init(void);
 int ls102xa_smmu_stream_id_init(void);
 
+void erratum_a008850_post(void);
+
 #ifdef CONFIG_SYS_FSL_ERRATUM_A010315
 void erratum_a010315(void);
 #endif
diff --git a/board/freescale/ls1021aiot/ls1021aiot.c 
b/board/freescale/ls1021aiot/ls1021aiot.c
index fb05b55b5c..70992a5ce4 100644
--- 

[U-Boot] [PATCH v2] cmd: thordown: Fix spelling of download.

[Vagrant Cascadian]

Signed-off-by: Vagrant Cascadian 
Reviewed-by: Bin Meng 
Reviewed-by: Lukasz Majewski 
---

Changes in v2:
- Add "cmd: thordown:" to define scope of the spelling fix.
- Add Reviewed-by entries.

 cmd/thordown.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmd/thordown.c b/cmd/thordown.c
index ce3660d174..19ae6721d1 100644
--- a/cmd/thordown.c
+++ b/cmd/thordown.c
@@ -65,7 +65,7 @@ done:
 U_BOOT_CMD(thordown, CONFIG_SYS_MAXARGS, 1, do_thor_down,
   "TIZEN \"THOR\" downloader",
   "  \n"
-  "  - device software upgrade via LTHOR TIZEN dowload\n"
+  "  - device software upgrade via LTHOR TIZEN download\n"
   "program via  on device ,\n"
   "attached to interface \n"
 );
-- 
2.20.1

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

Re: [U-Boot] [PATCH] configs: ls1046: Update mtd-id for QSPI nor in mtdparts variable

[Jagdish Gediya]

Hi Kuldeep,

> -Original Message-
> From: Kuldeep Singh
> Sent: Tuesday, March 5, 2019 11:39 AM
> To: u-boot@lists.denx.de
> Cc: Rajesh Bhagat ; Prabhakar Kushwaha
> ; Ashish Kumar
> ; Jagdish Gediya ;
> Mingkai Hu ; Ruchika Gupta
> ; Kuldeep Singh 
> Subject: [PATCH] configs: ls1046: Update mtd-id for QSPI nor in mtdparts
> variable
> 
> Updated mtd-id for QSPI nor due to change introduced in mtd/spi.
'Updated' -> 'Update'
> 
> Commit for reference in linux-5.0
> "spi: Add a driver for the Freescale/NXP QuadSPI controller"
This is not the correct way to refer a commit. Please correct it.
> 
> Signed-off-by: Kuldeep Singh 
> ---
>  configs/ls1046aqds_qspi_defconfig   | 4 ++--
>  configs/ls1046aqds_sdcard_qspi_defconfig| 4 ++--
>  configs/ls1046ardb_emmc_defconfig   | 4 ++--
>  configs/ls1046ardb_qspi_SECURE_BOOT_defconfig   | 4 ++--
>  configs/ls1046ardb_qspi_defconfig   | 4 ++--
>  configs/ls1046ardb_qspi_spl_defconfig   | 4 ++--
>  configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig | 4 ++--
>  configs/ls1046ardb_sdcard_defconfig | 4 ++--
>  configs/ls1046ardb_tfa_SECURE_BOOT_defconfig| 4 ++--
>  configs/ls1046ardb_tfa_defconfig| 4 ++--
>  10 files changed, 20 insertions(+), 20 deletions(-)
> 
> diff --git a/configs/ls1046aqds_qspi_defconfig
> b/configs/ls1046aqds_qspi_defconfig
> index 4cc19fe7ac..b7a6da2128 100644
> --- a/configs/ls1046aqds_qspi_defconfig
> +++ b/configs/ls1046aqds_qspi_defconfig
> @@ -10,7 +10,7 @@ CONFIG_OF_BOARD_SETUP=y  CONFIG_QSPI_BOOT=y
>  CONFIG_BOOTDELAY=10
>  CONFIG_USE_BOOTARGS=y
> -CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0
> earlycon=uart8250,mmio,0x21c0500
> mtdparts=155.quadspi:2m(uboot),14m(free)"
> +CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0
> earlycon=uart8250,mmio,0x21c0500 mtdparts=155.spi-
> 0:2m(uboot),14m(free)"
>  # CONFIG_USE_BOOTCOMMAND is not set
>  CONFIG_MISC_INIT_R=y
>  CONFIG_CMD_BOOTZ=y
> @@ -25,7 +25,7 @@ CONFIG_CMD_SF=y
>  CONFIG_CMD_USB=y
>  CONFIG_CMD_CACHE=y
>  CONFIG_MP=y
> -
> CONFIG_MTDPARTS_DEFAULT="mtdparts=155.quadspi:2m(uboot),14m(
> free)"
> +CONFIG_MTDPARTS_DEFAULT="mtdparts=155.spi-
> 0:2m(uboot),14m(free)"
>  CONFIG_OF_CONTROL=y
>  CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1046a-qds-duart"
>  CONFIG_ENV_IS_IN_SPI_FLASH=y
> diff --git a/configs/ls1046aqds_sdcard_qspi_defconfig
> b/configs/ls1046aqds_sdcard_qspi_defconfig
> index a7620d23ad..3cd7d344c0 100644
> --- a/configs/ls1046aqds_sdcard_qspi_defconfig
> +++ b/configs/ls1046aqds_sdcard_qspi_defconfig
> @@ -17,7 +17,7 @@
> CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL,SD_BOOT_QSPI
> "
>  CONFIG_SD_BOOT=y
>  CONFIG_BOOTDELAY=10
>  CONFIG_USE_BOOTARGS=y
> -CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0
> earlycon=uart8250,mmio,0x21c0500
> mtdparts=155.quadspi:2m(uboot),14m(free)"
> +CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0
> earlycon=uart8250,mmio,0x21c0500 mtdparts=155.spi-
> 0:2m(uboot),14m(free)"
>  # CONFIG_USE_BOOTCOMMAND is not set
>  CONFIG_MISC_INIT_R=y
>  CONFIG_SPL_BOARD_INIT=y
> @@ -39,7 +39,7 @@ CONFIG_CMD_SF=y
>  CONFIG_CMD_USB=y
>  CONFIG_CMD_CACHE=y
>  CONFIG_MP=y
> -
> CONFIG_MTDPARTS_DEFAULT="mtdparts=155.quadspi:2m(uboot),14m(
> free)"
> +CONFIG_MTDPARTS_DEFAULT="mtdparts=155.spi-
> 0:2m(uboot),14m(free)"
>  # CONFIG_SPL_EFI_PARTITION is not set
>  CONFIG_OF_CONTROL=y
>  CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1046a-qds-duart"
> diff --git a/configs/ls1046ardb_emmc_defconfig
> b/configs/ls1046ardb_emmc_defconfig
> index 4b45289869..e8e7e13e61 100644
> --- a/configs/ls1046ardb_emmc_defconfig
> +++ b/configs/ls1046ardb_emmc_defconfig
> @@ -17,7 +17,7 @@
> CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL,EMMC_BOOT"
>  CONFIG_SD_BOOT=y
>  CONFIG_BOOTDELAY=10
>  CONFIG_USE_BOOTARGS=y
> -CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0
> earlycon=uart8250,mmio,0x21c0500
> mtdparts=155.quadspi:1m(rcw),15m(u-
> boot),48m(kernel.itb);7e80.flash:16m(nand_uboot),48m(nand_kernel),
> 448m(nand_free)"
> +CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0
> earlycon=uart8250,mmio,0x21c0500 mtdparts=155.spi-
> 0:1m(rcw),15m(u-
> boot),48m(kernel.itb);7e80.flash:16m(nand_uboot),48m(nand_kernel),
> 448m(nand_free)"
>  # CONFIG_USE_BOOTCOMMAND is not set
>  CONFIG_MISC_INIT_R=y
>  CONFIG_SPL_BOARD_INIT=y
> @@ -36,7 +36,7 @@ CONFIG_CMD_SF=y
>  CONFIG_CMD_USB=y
>  CONFIG_CMD_CACHE=y
>  CONFIG_MP=y
> -
> CONFIG_MTDPARTS_DEFAULT="mtdparts=155.quadspi:1m(rcw),15m(u-
> boot),48m(kernel.itb);7e80.flash:16m(nand_uboot),48m(nand_kernel),
> 448m(nand_free)"
> +CONFIG_MTDPARTS_DEFAULT="mtdparts=155.spi-0:1m(rcw),15m(u-
> boot),48m(kernel.itb);7e80.flash:16m(nand_uboot),48m(nand_kernel),
> 448m(nand_free)"
>  # CONFIG_SPL_EFI_PARTITION is not set
>  CONFIG_OF_CONTROL=y
>  CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1046a-rdb"
> diff --git a/configs/ls1046ardb_qspi_SECURE_BOOT_defconfig
> 

Re: [U-Boot] [RFC 1/8] efi_loader: boottime: don't add device path protocol to image handle

[Heinrich Schuchardt]

On 3/6/19 6:04 AM, Heinrich Schuchardt wrote:
> On 3/6/19 1:27 AM, AKASHI Takahiro wrote:
>> On Tue, Mar 05, 2019 at 08:48:37PM +0100, Heinrich Schuchardt wrote:
>>> On 3/5/19 6:53 AM, AKASHI Takahiro wrote:
 It is just wrong to add devcie path protocol to image handle.

 Signed-off-by: AKASHI Takahiro 
 ---
  lib/efi_loader/efi_boottime.c | 11 +--
  1 file changed, 1 insertion(+), 10 deletions(-)

 diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
 index bd8b8a17ae71..7bd9c0a952d4 100644
 --- a/lib/efi_loader/efi_boottime.c
 +++ b/lib/efi_loader/efi_boottime.c
 @@ -1540,17 +1540,8 @@ efi_status_t efi_setup_loaded_image(struct 
 efi_device_path *device_path,
info->file_path = file_path;
info->system_table = 
  
 -  if (device_path) {
 +  if (device_path)
info->device_handle = efi_dp_find_obj(device_path, NULL);
 -  /*
 -   * When asking for the device path interface, return
 -   * bootefi_device_path
 -   */
 -  ret = efi_add_protocol(>header,
 - _guid_device_path, device_path);
>>>
>>> Installing the device path is not the problem. It is the GUID that is
>>> wrong. Use EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL_GUID here.
>>
>> Okay, but I believe that we need duplicate device_path here
>> before installing it as EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL_GUID.
>>
>> See this line:
>>
info->device_handle = efi_dp_find_obj(device_path, NULL);
>>
>> Normally, device_path is expected to be already associated with
>> another handle. We should not allow two handles to share one protocol(data).
>> That is also why I initially believed that add_protocol() should be removed.
> 
> The spec says we should use a copy of the unchanged DevicePath parameter
> of LoadImage() which may be NULL.
> 
> So we have to rework all callers to get the device_path parameter of
> efi_setup_loaded_image() right.
> 

Why are we constructing a dummy memory device path at all in cmd/bootefi?

The commit message of patch bf19273e81eb "efi_loader: Add mem-mapped for
fallback" that introduced this does not give a valid answer as it is
explicitly allowable to call LoadImage with DevicePath = NULL if
SourceBuffer is provided.

So I suggest we rid ourselves of the dummy device path with this patch
series.

Best regards

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

Re: [U-Boot] [RFC 1/8] efi_loader: boottime: don't add device path protocol to image handle

[Heinrich Schuchardt]

On 3/6/19 1:27 AM, AKASHI Takahiro wrote:
> On Tue, Mar 05, 2019 at 08:48:37PM +0100, Heinrich Schuchardt wrote:
>> On 3/5/19 6:53 AM, AKASHI Takahiro wrote:
>>> It is just wrong to add devcie path protocol to image handle.
>>>
>>> Signed-off-by: AKASHI Takahiro 
>>> ---
>>>  lib/efi_loader/efi_boottime.c | 11 +--
>>>  1 file changed, 1 insertion(+), 10 deletions(-)
>>>
>>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>>> index bd8b8a17ae71..7bd9c0a952d4 100644
>>> --- a/lib/efi_loader/efi_boottime.c
>>> +++ b/lib/efi_loader/efi_boottime.c
>>> @@ -1540,17 +1540,8 @@ efi_status_t efi_setup_loaded_image(struct 
>>> efi_device_path *device_path,
>>> info->file_path = file_path;
>>> info->system_table = 
>>>  
>>> -   if (device_path) {
>>> +   if (device_path)
>>> info->device_handle = efi_dp_find_obj(device_path, NULL);
>>> -   /*
>>> -* When asking for the device path interface, return
>>> -* bootefi_device_path
>>> -*/
>>> -   ret = efi_add_protocol(>header,
>>> -  _guid_device_path, device_path);
>>
>> Installing the device path is not the problem. It is the GUID that is
>> wrong. Use EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL_GUID here.
> 
> Okay, but I believe that we need duplicate device_path here
> before installing it as EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL_GUID.
> 
> See this line:
> 
>>> info->device_handle = efi_dp_find_obj(device_path, NULL);
> 
> Normally, device_path is expected to be already associated with
> another handle. We should not allow two handles to share one protocol(data).
> That is also why I initially believed that add_protocol() should be removed.

The spec says we should use a copy of the unchanged DevicePath parameter
of LoadImage() which may be NULL.

So we have to rework all callers to get the device_path parameter of
efi_setup_loaded_image() right.

Best regards

Heinrich

> 
> Thanks,
> -Takahiro Akashi
> 
> 
>> UEFI Spec 2.7:
>>
>> "The Loaded Image Device Path Protocol must be installed onto the image
>> handle of a PE/COFF image loaded through the EFI Boot Service LoadImage()."
>>
>> Best regards
>>
>> Heinrich
>>
>>> -   if (ret != EFI_SUCCESS)
>>> -   goto failure;
>>> -   }
>>>  
>>> /*
>>>  * When asking for the loaded_image interface, just
>>>
>>
> 

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

Re: [U-Boot] [PATCH v11 8/9] ARM: socfpga: Synchronize the configuration for A10 SoCDK

[Dinh Nguyen]

On 3/5/19 10:23 AM, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 
> 
> Update the default configuration file to enable the necessary functionality
> the get the kit working.
> 
> Signed-off-by: Tien Fong Chee 
> 
> ---
> 
> changes for v8
> - Moved the FIT related configs to the patch of configuration for FPGA
>   SoCFPGA A10 SoCDK.
> 
> changes for v7
> - Keep minimal configs.
> ---
>  configs/socfpga_arria10_defconfig | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)

Why are there 2 patches touching socfpga_arria10_defconfig in this
series? Can you squash them into 1?

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

Re: [U-Boot] [PATCH v11 9/9] ARM: socfpga: Increase Malloc pool size to support FAT filesystem in SPL

[Dinh Nguyen]

On 3/5/19 10:23 AM, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 
> 
> After some series of patches to maximise reusable of memory pool, here come
> to result of reasonable size required for whole SDMMC boot working on A10
> SoCDK. Size required come from default max cluster(0x1) +
> others(0x2000) + additional memory for headroom(0x3000).

This commit log is really confusing. What "series of patches"? I think
you're just needing a bigger malloc pool. Can you just say that and
explain why you need it?

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

Re: [U-Boot] [PATCH 1/1] efi_loader: release file buffer after loading image

[Heinrich Schuchardt]

On 3/6/19 1:41 AM, AKASHI Takahiro wrote:
> On Tue, Mar 05, 2019 at 08:56:12PM +0100, Heinrich Schuchardt wrote:
>> efi_load_pe() copies and rebases the UEFI image.
>> We do not need the buffer with the file contents afterwards.
>>
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>>  lib/efi_loader/efi_boottime.c | 50 +--
>>  1 file changed, 18 insertions(+), 32 deletions(-)
>>
>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>> index bd8b8a17ae..391681260c 100644
>> --- a/lib/efi_loader/efi_boottime.c
>> +++ b/lib/efi_loader/efi_boottime.c
>> @@ -1693,6 +1693,7 @@ static efi_status_t EFIAPI efi_load_image(bool 
>> boot_policy,
>>  struct efi_loaded_image_obj **image_obj =
>>  (struct efi_loaded_image_obj **)image_handle;
>>  efi_status_t ret;
>> +void *dest_buffer;
>>  
>>  EFI_ENTRY("%d, %p, %pD, %p, %zd, %p", boot_policy, parent_image,
>>file_path, source_buffer, source_size, image_handle);
>> @@ -1708,7 +1709,7 @@ static efi_status_t EFIAPI efi_load_image(bool 
>> boot_policy,
>>  }
>>  
>>  if (!source_buffer) {
>> -ret = efi_load_image_from_path(file_path, _buffer,
>> +ret = efi_load_image_from_path(file_path, _buffer,
>> _size);
>>  if (ret != EFI_SUCCESS)
>>  goto error;
>> @@ -1721,41 +1722,26 @@ static efi_status_t EFIAPI efi_load_image(bool 
>> boot_policy,
>>  /* In this case, file_path is the "device" path, i.e.
>>   * something like a HARDWARE_DEVICE:MEMORY_MAPPED
>>   */
>> -u64 addr;
>> -void *dest_buffer;
>> -
>> -ret = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES,
>> - EFI_RUNTIME_SERVICES_CODE,
>> - efi_size_in_pages(source_size), );
>> -if (ret != EFI_SUCCESS)
>> -goto error;
>> -dest_buffer = (void *)(uintptr_t)addr;
>> -memcpy(dest_buffer, source_buffer, source_size);
>> -source_buffer = dest_buffer;
>> -
> 
> Are you sure? This code is what you added in your recent commit
> 0e18f584de59 ("efi_loader: LoadImage: always allocate new pages")
> at v2019.04-rc2.

I had that now rejected patch '[U-Boot,RFC,1/1] efi_loader: in situ
relocation' in mind. Maybe I should add a 'Fixes' tag pointing to
0e18f584de59.

If the caller provides a source buffer, we should not delete it. But we
there is also no need to copy it here because it is duplicated by the
relocation code.

If we read from file we need a receiving buffer, but we can delete it
once we have completed relocation.

> 
> IMO, the comment:
>>  /* In this case, file_path is the "device" path, i.e.
>>   * something like a HARDWARE_DEVICE:MEMORY_MAPPED
> 
> is also not accurate because "file_path" is normally non-NULL,
> indicating where the content of "source_buffer" comes from.
> In other words, "HARDWARE_DEVICE:MEMORY_MAPPED" is a quite irregular case.

Yes, the comment can be updated. "HARDWARE_DEVICE:MEMORY_MAPPED" is only
what we do in do_bootefi as workaround in some cases.

Regards

Heinrich

> 
> -Takahiro Akashi
> 
> 
>> +dest_buffer = source_buffer;
>>  dp = file_path;
>>  fp = NULL;
>>  }
>>  ret = efi_setup_loaded_image(dp, fp, image_obj, );
>> -if (ret != EFI_SUCCESS)
>> -goto error_invalid_image;
>> -ret = efi_load_pe(*image_obj, source_buffer, info);
>> -if (ret != EFI_SUCCESS)
>> -goto error_invalid_image;
>> -/* Update the type of the allocated memory */
>> -efi_add_memory_map((uintptr_t)source_buffer,
>> -   efi_size_in_pages(source_size),
>> -   info->image_code_type, false);
>> -info->system_table = 
>> -info->parent_handle = parent_image;
>> -return EFI_EXIT(EFI_SUCCESS);
>> -error_invalid_image:
>> -/* The image is invalid. Release all associated resources. */
>> -efi_free_pages((uintptr_t)source_buffer,
>> -   efi_size_in_pages(source_size));
>> -efi_delete_handle(*image_handle);
>> -*image_handle = NULL;
>> -free(info);
>> +if (ret == EFI_SUCCESS)
>> +ret = efi_load_pe(*image_obj, dest_buffer, info);
>> +if (!source_buffer)
>> +/* Release buffer to which file was loaded */
>> +efi_free_pages((uintptr_t)dest_buffer,
>> +   efi_size_in_pages(source_size));
>> +if (ret == EFI_SUCCESS) {
>> +info->system_table = 
>> +info->parent_handle = parent_image;
>> +} else {
>> +/* The image is invalid. Release all associated resources. */
>> +efi_delete_handle(*image_handle);
>> +*image_handle = NULL;
>> +free(info);
>> +}
>>  error:
>>  return EFI_EXIT(ret);
>>  }

Re: [U-Boot] [PATCH v11 4/9] ARM: socfpga: Move the watchdog reset to the looping location

[Dinh Nguyen]

It looks like this patch was not in the previous 9 versions of this
series? Please try to not add new functionality to a series that is
already gone through so many reviews. It make reviewing the series
really confusing!

On 3/5/19 10:23 AM, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 
> 
> Ensure the watchdog is reset timely if the looping is long.

How are you ensuring this?

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

Re: [U-Boot] [PATCH v11 3/9] ARM: socfpga: Cleaning up the messages

[Dinh Nguyen]

On 3/5/19 10:23 AM, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 
> 
> Ensure the comment and debug messages are always consistent with the rest.

The rest of what? This patch seems unnecessary to me.

Dinh

> 
> Signed-off-by: Tien Fong Chee 
> ---
>  drivers/fpga/socfpga_arria10.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/fpga/socfpga_arria10.c b/drivers/fpga/socfpga_arria10.c
> index 114dd910ab..b0abe1955c 100644
> --- a/drivers/fpga/socfpga_arria10.c
> +++ b/drivers/fpga/socfpga_arria10.c
> @@ -94,7 +94,7 @@ int fpgamgr_wait_early_user_mode(void)
>   i++;
>   }
>  
> - debug("Additional %i sync word needed\n", i);
> + debug("FPGA: Additional %i sync word needed\n", i);
>  
>   /* restoring original CDRATIO */
>   fpgamgr_set_cd_ratio(cd_ratio);
> @@ -172,9 +172,10 @@ static int fpgamgr_set_cdratio_cdwidth(unsigned int 
> cfg_width, u32 *rbf_data,
>   compress = (rbf_data[COMPRESSION_OFFSET] >> 1) & 1;
>   compress = !compress;
>  
> - debug("header word %d = %08x\n", 69, rbf_data[69]);
> - debug("header word %d = %08x\n", 229, rbf_data[229]);
> - debug("read from rbf header: encrypt=%d compress=%d\n", encrypt, 
> compress);
> + debug("FPGA: Header word %d = %08x.\n", 69, rbf_data[69]);
> + debug("FPGA: Header word %d = %08x.\n", 229, rbf_data[229]);
> + debug("FPGA: Read from rbf header: encrypt=%d compress=%d.\n", encrypt,
> +  compress);
>  
>   /*
>* from the register map description of cdratio in imgcfg_ctrl_02:
> @@ -455,10 +456,10 @@ int socfpga_load(Altera_desc *desc, const void 
> *rbf_data, size_t rbf_size)
>  {
>   int status;
>  
> - /* disable all signals from hps peripheral controller to fpga */
> + /* Disable all signals from hps peripheral controller to fpga */
>   writel(0, _manager_base->fpgaintf_en_global);
>  
> - /* disable all axi bridge (hps2fpga, lwhps2fpga & fpga2hps) */
> + /* Disable all axi bridge (hps2fpga, lwhps2fpga & fpga2hps) */
>   socfpga_bridges_reset();
>  
>   /* Initialize the FPGA Manager */
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/1] efi_loader: bootmgr: support BootNext and BootCurrent variable behavior

[Heinrich Schuchardt]

On 3/6/19 1:17 AM, AKASHI Takahiro wrote:
> On Tue, Mar 05, 2019 at 08:38:40PM +0100, Heinrich Schuchardt wrote:
>> On 3/5/19 2:58 AM, AKASHI Takahiro wrote:
>>> See UEFI v2.7, section 3.1.2 for details of the specification.
>>>
>>> With efidebug command, you can run any EFI boot option as follows:
>>>   => efi boot add 1 SHELL ...
>>>   => efi boot add 2 HELLO ...
>>>   => efi boot order 1 2
>>>   => efi bootmgr
>>>  (starting SHELL ...)
>>>
>>>   => efi boot next 2
>>>   => efi bootmgr
>>>  (starting HELLO ...)
>>>   => env print -e
>>>   
>>>   BootCurrent: {boot,run}(blob)
>>>   :  02 00..
>>>   BootOrder: {boot,run}(blob)
>>>   :  01 00 02 00  
>>>
>>> Signed-off-by: AKASHI Takahiro 
>>
>> Please, use scripts/get_maintainer.pl to determine the correct
>> recipients. You missed Alex's new email address.
> 
> Okay.
> 
>>> ---
>>>  lib/efi_loader/efi_bootmgr.c | 40 
>>>  1 file changed, 36 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
>>> index 417016102b48..1575c5c09e46 100644
>>> --- a/lib/efi_loader/efi_bootmgr.c
>>> +++ b/lib/efi_loader/efi_bootmgr.c
>>> @@ -141,6 +141,7 @@ static void *try_load_entry(uint16_t n, struct 
>>> efi_device_path **device_path,
>>> efi_deserialize_load_option(, load_option);
>>>  
>>> if (lo.attributes & LOAD_OPTION_ACTIVE) {
>>> +   u32 attributes;
>>> efi_status_t ret;
>>>  
>>> debug("%s: trying to load \"%ls\" from %pD\n",
>>> @@ -151,6 +152,16 @@ static void *try_load_entry(uint16_t n, struct 
>>> efi_device_path **device_path,
>>> if (ret != EFI_SUCCESS)
>>> goto error;
>>>  
>>> +   attributes = EFI_VARIABLE_BOOTSERVICE_ACCESS |
>>> +EFI_VARIABLE_RUNTIME_ACCESS;
>>> +   size = sizeof(n);
>>> +   ret = EFI_CALL(efi_set_variable(
>>> +   L"BootCurrent",
>>> +   (efi_guid_t *)_global_variable_guid,
>>> +   attributes, size, ));
>>> +   if (ret != EFI_SUCCESS)
>>> +   goto error;
>>> +
>>> printf("Booting: %ls\n", lo.label);
>>> efi_dp_split_file_path(lo.file_path, device_path, file_path);
>>> }
>>> @@ -162,21 +173,42 @@ error:
>>>  }
>>>  
>>>  /*
>>> - * Attempt to load, in the order specified by BootOrder EFI variable, the
>>> - * available load-options, finding and returning the first one that can
>>> - * be loaded successfully.
>>> + * Attempt to load from BootNext or in the order specified by BootOrder
>>> + * EFI variable, the available load-options, finding and returning
>>> + * the first one that can be loaded successfully.
>>>   */
>>>  void *efi_bootmgr_load(struct efi_device_path **device_path,
>>>struct efi_device_path **file_path)
>>>  {
>>> -   uint16_t *bootorder;
>>> +   u16 bootnext, *bootorder;
>>
>> bootnext has enough space for the terminating \n. That is way too small.
>>
>> You want to call efi_get_variable() twice. Get the buffer size needed in
>> the first round. malloc() a buffer. Then actually read the variable.
>> Finally free() the buffer.
> 
> No.
> "BootNext" is always a 16-bit integer, and "bootnext" is a u16 variable,
> not a pointer.
> So we don't need to call get_variable() twice. That is why I didn't use
> get_var() here. I believe that you seem to like "code efficiency."

I see.

> 
>>> efi_uintn_t size;
>>> void *image = NULL;
>>> int i, num;
>>> +   efi_status_t ret;
>>>  
>>> bs = systab.boottime;
>>> rs = systab.runtime;
>>>  
>>> +   /* BootNext */
>>> +   size = sizeof(bootnext);
>>> +   ret = EFI_CALL(efi_get_variable(L"BootNext",
>>> +   (efi_guid_t *)_global_variable_guid,
>>> +   NULL, , ));
>>> +   if (ret == EFI_SUCCESS) {

As we expect the variable to have size 2, we should check the size field
too.

>>
>> The expected value of ret for an existing variable of size > 0 is
>> EFI_BUFFER_TOO_SMALL.

Now let's assume that the variable has been created with the wrong size
(e.g. using `env set -e`). In that case we should either try to delete
it or write an error message or both.

>>
>>> +   /* delete BootNext */
>>> +   ret = EFI_CALL(efi_set_variable(
>>> +   L"BootNext",
>>> +   (efi_guid_t *)_global_variable_guid,
>>> +   0, 0, ));
>>> +   if (ret == EFI_SUCCESS) {
>>
>> Why would loading the boot entry depend on the return value here?
> 
> Deleting "BootNex" is required by UEFI spec.
> In addition, if we fail to delete it, we will see the same application
> start again when executing boot manager next time.
> 

BootNext is a non-volatile variable. Once we have a non-volatile backend
for variables the 

Re: [U-Boot] [PATCH v11 6/9] ARM: socfpga: Add the configuration for FPGA SoCFPGA A10 SoCDK

[Dinh Nguyen]

On 3/5/19 10:23 AM, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 
> 
> Update the default configuration file to enable the necessary functionality
> to get the SoCFPGA loadfs driver support. This would enable the
> implementation of programming bitstream into FPGA from MMC.
> 
> Signed-off-by: Tien Fong Chee 
> 
> ---
> 
> changes for v8
> - Added FIT related configs
> 
> changes for v7
> - Removed limit set for CONFIG_FS_FAT_MAX_CLUSTSIZE
> ---
>  configs/socfpga_arria10_defconfig | 8 
>  1 file changed, 8 insertions(+)

What changed in v9 - v11?

Also this patch doesn't apply to v2019.04-rc4 at all:

error: patch failed: configs/socfpga_arria10_defconfig:27
error: configs/socfpga_arria10_defconfig: patch does not apply
dinguyen@b13cycling:~/linux_dev/u-boot$ git apply --reject patch1.patch
Checking patch configs/socfpga_arria10_defconfig...
error: while searching for:
# CONFIG_EFI_PARTITION is not set
CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc"
CONFIG_ENV_IS_IN_MMC=y
CONFIG_SPL_DM=y
CONFIG_SPL_DM_SEQ_ALIAS=y
CONFIG_SPL_FS_FAT=y
CONFIG_FPGA_SOCFPGA=y
CONFIG_DM_GPIO=y
CONFIG_DWAPB_GPIO=y
CONFIG_DM_MMC=y

error: patch failed: configs/socfpga_arria10_defconfig:27
Applying patch configs/socfpga_arria10_defconfig with 1 reject...
Rejected hunk #1.

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

Re: [U-Boot] [PATCH v2 0/9] SMP support for RISC-V

[Anup Patel]

> -Original Message-
> From: Lukas Auer 
> Sent: Wednesday, March 6, 2019 4:23 AM
> To: u-boot@lists.denx.de
> Cc: Atish Patra ; Anup Patel
> ; Bin Meng ; Andreas
> Schwab ; Palmer Dabbelt ;
> Alexander Graf ; Lukas Auer
> ; Anup Patel ;
> Anup Patel ; Rick Chen ;
> Baruch Siach ; Atish Patra ;
> Stefan Roese ; Paul Walmsley ;
> Daniel Schwierzeck 
> Subject: [PATCH v2 0/9] SMP support for RISC-V
> 
> This patch series adds SMP support for RISC-V to U-Boot. It allows U-Boot to
> run on multi-hart systems (hart is the RISC-V terminology for hardware
> thread). Images passed to bootm will be started on all harts.
> The bootm command is currently the only one that will boot images on all
> harts, bootefi is not yet supported.
> 
> The patches have been successfully tested on both QEMU (machine and
> supervisor mode) and the HiFive Unleashed board (supervisor mode), using
> BBL and OpenSBI.
> Mainline QEMU requires two patches [1, 2] to run in this configuration.
> 
> [1]: https://patchwork.ozlabs.org/patch/1039493/
> [2]: https://patchwork.ozlabs.org/patch/1039082/
> 
> Changes in v2:
> - Remove unneeded quotes from NR_CPUS Kconfig entry
> - Move memory barrier from send_ipi_many() to handle_ipi()
> - Add check in send_ipi_many so that IPIs are only sent to available harts as
> indicated by the available_harts mask
> - Implement hart lottery to pick main hart to run U-Boot
> - Remove CONFIG_MAIN_HART as it is not required anymore
> - Register available harts in the available_harts mask
> - New patch to populate register a0 with the hart ID from the mhartid CSR in
> machine-mode
> - New patch to enable SMP on the SiFive FU540, which was previously sent
> independently
> 
> Lukas Auer (9):
>   riscv: add infrastructure for calling functions on other harts
>   riscv: import the supervisor binary interface header file
>   riscv: implement IPI platform functions using SBI
>   riscv: delay initialization of caches and debug UART
>   riscv: add support for multi-hart systems
>   riscv: boot images passed to bootm on all harts
>   riscv: do not rely on hart ID passed by previous boot stage
>   riscv: fu540: enable SMP
>   riscv: qemu: enable SMP
> 
>  arch/riscv/Kconfig   |  28 +
>  arch/riscv/cpu/cpu.c |   9 +-
>  arch/riscv/cpu/start.S   | 152 +--
>  arch/riscv/include/asm/csr.h |   1 +
>  arch/riscv/include/asm/global_data.h |   6 ++
>  arch/riscv/include/asm/sbi.h |  94 +
>  arch/riscv/include/asm/smp.h |  53 ++
>  arch/riscv/lib/Makefile  |   2 +
>  arch/riscv/lib/asm-offsets.c |   1 +
>  arch/riscv/lib/bootm.c   |  13 ++-
>  arch/riscv/lib/sbi_ipi.c |  25 +
>  arch/riscv/lib/smp.c | 116 
>  board/emulation/qemu-riscv/Kconfig   |   1 +
>  board/sifive/fu540/Kconfig   |   1 +
>  14 files changed, 492 insertions(+), 10 deletions(-)  create mode 100644
> arch/riscv/include/asm/sbi.h  create mode 100644
> arch/riscv/include/asm/smp.h  create mode 100644 arch/riscv/lib/sbi_ipi.c
> create mode 100644 arch/riscv/lib/smp.c
> 
> --
> 2.20.1

I tried this series on U-Boot-2019.04-rc3 and works fine on
SiFive Unleashed board.

Tested-by: Anup Patel 

I have also pushed these patches to riscv_sifive_fu540_smp_v4
branch of https://github.com/avpatel/u-boot.git

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

Re: [U-Boot] [PATCH v2 7/9] riscv: do not rely on hart ID passed by previous boot stage

[Anup Patel]

> -Original Message-
> From: Lukas Auer 
> Sent: Wednesday, March 6, 2019 4:23 AM
> To: u-boot@lists.denx.de
> Cc: Atish Patra ; Anup Patel
> ; Bin Meng ; Andreas
> Schwab ; Palmer Dabbelt ;
> Alexander Graf ; Lukas Auer
> ; Rick Chen ; Anup
> Patel 
> Subject: [PATCH v2 7/9] riscv: do not rely on hart ID passed by previous boot
> stage
> 
> RISC-V U-Boot expects the hart ID to be passed to it via register a0 by the
> previous boot stage. Machine mode firmware such as BBL and OpenSBI do
> this when starting their payload (U-Boot) in supervisor mode. If U-Boot is
> running in machine mode, this task must be handled by the boot ROM.
> Explicitly populate register a0 with the hart ID from the mhartid CSR to avoid
> possible problems on RISC-V processors with a boot ROM that does not
> handle this task.
> 
> Suggested-by: Rick Chen 
> Signed-off-by: Lukas Auer 
> ---
> 
> Changes in v2:
> - New patch to populate register a0 with the hart ID from the mhartid CSR in
> machine-mode
> 
>  arch/riscv/cpu/start.S | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S index
> 79b753847c..d4daa6e0bf 100644
> --- a/arch/riscv/cpu/start.S
> +++ b/arch/riscv/cpu/start.S
> @@ -36,6 +36,10 @@
>  .section .text
>  .globl _start
>  _start:
> +#ifdef CONFIG_RISCV_MMODE
> + csrra0, mhartid
> +#endif
> +
>   /* save hart id and dtb pointer */
>   mv  s0, a0
>   mv  s1, a1
> --
> 2.20.1

Reviewed-by: Anup Patel 

Regards,
Anup

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

Re: [U-Boot] [PATCH v2 5/9] riscv: add support for multi-hart systems

[Anup Patel]

> -Original Message-
> From: Lukas Auer 
> Sent: Wednesday, March 6, 2019 4:23 AM
> To: u-boot@lists.denx.de
> Cc: Atish Patra ; Anup Patel
> ; Bin Meng ; Andreas
> Schwab ; Palmer Dabbelt ;
> Alexander Graf ; Lukas Auer
> ; Anup Patel ; Rick
> Chen ; Baruch Siach ; Stefan
> Roese ; Daniel Schwierzeck 
> Subject: [PATCH v2 5/9] riscv: add support for multi-hart systems
> 
> On RISC-V, all harts boot independently. To be able to run on a multi-hart
> system, U-Boot must be extended with the functionality to manage all harts
> in the system. All harts entering U-Boot are registered in the available_harts
> mask stored in global data. A hart lottery system as used in the Linux kernel
> selects the hart U-Boot runs on. All other harts are halted. U-Boot can
> delegate functions to them using smp_call_function().
> 
> Every hart has a valid pointer to the global data structure and a 8KiB stack 
> by
> default. The stack size is set with CONFIG_STACK_SIZE_SHIFT.
> 
> Signed-off-by: Lukas Auer 
> ---
> 
> Changes in v2:
> - Implement hart lottery to pick main hart to run U-Boot
> - Remove CONFIG_MAIN_HART as it is not required anymore
> - Register available harts in the available_harts mask
> 
>  arch/riscv/Kconfig   |   4 ++
>  arch/riscv/cpu/cpu.c |   9 ++-
>  arch/riscv/cpu/start.S   | 134 ++-
>  arch/riscv/include/asm/csr.h |   1 +
>  arch/riscv/lib/asm-offsets.c |   1 +
>  5 files changed, 147 insertions(+), 2 deletions(-)

Reviewed-by: Anup Patel 

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

Re: [U-Boot] [PATCH v2 1/9] riscv: add infrastructure for calling functions on other harts

[Anup Patel]

> -Original Message-
> From: Lukas Auer 
> Sent: Wednesday, March 6, 2019 4:23 AM
> To: u-boot@lists.denx.de
> Cc: Atish Patra ; Anup Patel
> ; Bin Meng ; Andreas
> Schwab ; Palmer Dabbelt ;
> Alexander Graf ; Lukas Auer
> ; Anup Patel ; Rick
> Chen 
> Subject: [PATCH v2 1/9] riscv: add infrastructure for calling functions on 
> other
> harts
> 
> Harts on RISC-V boot independently, U-Boot is responsible for managing
> them. Functions are called on other harts with smp_call_function(), which
> sends inter-processor interrupts (IPIs) to all other available harts. 
> Available
> harts are those marked as available in the device tree and present in the
> available_harts mask stored in global data. The available_harts mask is used
> to register all harts that have entered U-Boot. Functions are specified with
> their address and two function arguments (argument 2 and 3). The first
> function argument is always the hart ID of the hart calling the function. On
> the other harts, the IPI interrupt handler handle_ipi() must be called on
> software interrupts to handle the request and call the specified function.
> 
> Functions are stored in the ipi_data data structure. Every hart has its own
> data structure in global data. While this is not required at the moment (all
> harts are expected to boot Linux), this does allow future expansion, where
> other harts may be used for monitoring or other tasks.
> 
> Signed-off-by: Lukas Auer 
> ---
> 
> Changes in v2:
> - Remove unneeded quotes from NR_CPUS Kconfig entry
> - Move memory barrier from send_ipi_many() to handle_ipi()
> - Add check in send_ipi_many so that IPIs are only sent to available harts as
> indicated by the available_harts mask

Reviewed-by: Anup Patel 

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

Re: [U-Boot] [PATCH v11 9/9] ARM: socfpga: Increase Malloc pool size to support FAT filesystem in SPL

[Chee, Tien Fong]

On Tue, 2019-03-05 at 21:05 +0100, Simon Goldschmidt wrote:
> Am 05.03.2019 um 17:23 schrieb tien.fong.c...@intel.com:
> > 
> > From: Tien Fong Chee 
> > 
> > After some series of patches to maximise reusable of memory pool,
> > here come
> > to result of reasonable size required for whole SDMMC boot working
> > on A10
> > SoCDK. Size required come from default max cluster(0x1) +
> > others(0x2000) + additional memory for headroom(0x3000).
> > 
> > Signed-off-by: Tien Fong Chee 
> > 
> > ---
> > 
> > changes for v7
> > - Added 0x3000 for memory headroom.
> > ---
> >   include/configs/socfpga_common.h | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/configs/socfpga_common.h
> > b/include/configs/socfpga_common.h
> > index 4551cb29bc..548b458e78 100644
> > --- a/include/configs/socfpga_common.h
> > +++ b/include/configs/socfpga_common.h
> > @@ -1,6 +1,6 @@
> >   /* SPDX-License-Identifier: GPL-2.0+ */
> >   /*
> > - * Copyright (C) 2012 Altera Corporation 
> > + * Copyright (C) 2012-2019 Altera Corporation 
> >    */
> >   #ifndef __CONFIG_SOCFPGA_COMMON_H__
> >   #define __CONFIG_SOCFPGA_COMMON_H__
> > @@ -258,7 +258,7 @@ unsigned int
> > cm_get_qspi_controller_clk_hz(void);
> >   #if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> >   /* SPL memory allocation configuration, this is for FAT
> > implementation */
> >   #ifndef CONFIG_SYS_SPL_MALLOC_START
> > -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0001
> > +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x00015000
> This will clash with my series here:
> https://patchwork.ozlabs.org/patch/1051451/
> 
> Any chance you could test that on A10? I only have a cyclone 5.
Okay, let me trying to test your series.
> 
Thanks,
TF
> 
> 
> > 
> >   #define CONFIG_SYS_SPL_MALLOC_START   (CONFIG_SYS_INIT_RAM_S
> > IZE - \
> >      CONFIG_SYS_SPL_MALLOC_SI
> > ZE + \
> >      CONFIG_SYS_INIT_RAM_ADDR
> > )
> > 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/3] net: add higmacv300 Ethernet driver for HiSilicon platform

[Shawn Guo]

On Tue, Mar 05, 2019 at 11:58:26PM +, Joe Hershberger wrote:
> > +static int higmac_recv(struct udevice *dev, int flags, uchar **packetp)
> > +{
> > +   struct higmac_priv *priv = dev_get_priv(dev);
> > +   struct higmac_desc *fqd = priv->rxfq;
> > +   struct higmac_desc *bqd = priv->rxbq;
> > +   int fqw_pos, fqr_pos, bqw_pos, bqr_pos;
> > +   int timeout = 10;
> > +   int len = 0;
> > +   int space;
> > +   int i;
> > +
> > +   fqw_pos = DESC_CNT(readl(priv->base + RX_FQ_WR_ADDR));
> > +   fqr_pos = DESC_CNT(readl(priv->base + RX_FQ_RD_ADDR));
> > +
> > +   if (fqw_pos >= fqr_pos)
> > +   space = RX_DESC_NUM - (fqw_pos - fqr_pos);
> > +   else
> > +   space = fqr_pos - fqw_pos;
> > +
> > +   /* Leave one free to distinguish full filled from empty buffer */
> > +   for (i = 0; i < space - 1; i++) {
> > +   fqd = priv->rxfq + fqw_pos;
> > +   invalidate_dcache_range(fqd->buf_addr,
> > +   fqd->buf_addr + MAC_MAX_FRAME_SIZE);
> > +
> > +   if (++fqw_pos >= RX_DESC_NUM)
> > +   fqw_pos = 0;
> > +
> > +   writel(DESC_BYTE(fqw_pos), priv->base + RX_FQ_WR_ADDR);
> > +   }
> > +
> > +   bqr_pos = DESC_CNT(readl(priv->base + RX_BQ_RD_ADDR));
> > +   bqd += bqr_pos;
> > +   /* BQ is only ever written by GMAC */
> > +   invalidate_desc(bqd);
> > +
> > +   do {
> > +   bqw_pos = DESC_CNT(readl(priv->base + RX_BQ_WR_ADDR));
> > +   udelay(1);
> > +   } while (--timeout && bqw_pos == bqr_pos);
> 
> Did you look into using wait bit macros?

I may miss your point, but this is not a loop waiting for some bits set
or clear.  It's waiting for a given number.

> 
> > +
> > +   if (!timeout)
> > +   return -ETIMEDOUT;
> > +
> > +   if (++bqr_pos >= RX_DESC_NUM)
> > +   bqr_pos = 0;
> > +
> > +   len = bqd->data_len;
> > +
> > +   /* CPU should not have touched this buffer since we added it to FQ 
> > */
> > +   invalidate_dcache_range(bqd->buf_addr, bqd->buf_addr + len);
> > +   *packetp = (void *)(unsigned long)bqd->buf_addr;
> > +
> > +   /* Record the RX_BQ descriptor that is holding RX data */
> > +   priv->rxdesc_in_use = bqr_pos;
> > +
> > +   return len;
> > +}



> > +static int higmac_hw_init(struct higmac_priv *priv)
> > +{
> > +   int ret;
> > +
> > +   /* Initialize hardware queues */
> > +   ret = higmac_init_hw_queue(priv, RX_FQ);
> > +   if (ret)
> > +   return ret;
> > +
> > +   ret = higmac_init_hw_queue(priv, RX_BQ);
> > +   if (ret)
> > +   goto free_rx_fq;
> > +
> > +   ret = higmac_init_hw_queue(priv, TX_BQ);
> > +   if (ret)
> > +   goto free_rx_bq;
> > +
> > +   ret = higmac_init_hw_queue(priv, TX_RQ);
> > +   if (ret)
> > +   goto free_tx_bq;
> > +
> > +   /* Reset phy */
> > +   reset_assert(>rst_phy);
> > +   mdelay(10);
> 
> I'm surprised the delay here is not a DT parameter.

We do not see the necessity for now.  We can make it a DT parameter when
we see the real need in the future.

> 
> > +   reset_deassert(>rst_phy);
> > +   mdelay(30);
> 
> I'm surprised the delay here is not a DT parameter.
> 
> > +   reset_assert(>rst_phy);
> > +   mdelay(30);
> 
> Why is this reasserted?

I have to admit this is a bit hackish.  Ideally, the reset sequence
should be: deassert -> assert -> deassert.  But this reset signal gets
an opposite polarity than others that reset driver handles.  I can add a
comment to explain it if you can tolerate this little hack, or I will
add polarity support to reset driver to handle this phy reset quirk.
Please let me know your preference.

> 
> > +
> > +   return 0;
> > +
> > +free_tx_bq:
> > +   free(priv->txbq);
> > +free_rx_bq:
> > +   free(priv->rxbq);
> > +free_rx_fq:
> > +   free(priv->rxfq);
> > +   return ret;
> > +}
> > +
> > +static int higmac_probe(struct udevice *dev)
> > +{
> > +   struct higmac_priv *priv = dev_get_priv(dev);
> > +   struct phy_device *phydev;
> > +   struct mii_dev *bus;
> > +   int ret;
> > +
> > +   ret = higmac_hw_init(priv);
> > +   if (ret)
> > +   return ret;
> > +
> > +   bus = mdio_alloc();
> > +   if (!bus)
> > +   return -ENOMEM;
> > +
> > +   bus->read = higmac_mdio_read;
> > +   bus->write = higmac_mdio_write;
> > +   bus->priv = priv;
> > +   priv->bus = bus;
> > +
> > +   ret = mdio_register_seq(bus, dev->seq);
> > +   if (ret)
> > +   return ret;
> > +
> > +   phydev = phy_connect(bus, priv->phyaddr, dev, priv->phyintf);
> > +   if (!phydev)
> > +   return -ENODEV;
> > +
> > +   phydev->supported &= PHY_GBIT_FEATURES;
> > +   phydev->advertising = phydev->supported;
> > +   

Re: [U-Boot] [PATCH 1/1] efi_loader: release file buffer after loading image

[AKASHI Takahiro]

On Tue, Mar 05, 2019 at 08:56:12PM +0100, Heinrich Schuchardt wrote:
> efi_load_pe() copies and rebases the UEFI image.
> We do not need the buffer with the file contents afterwards.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_boottime.c | 50 +--
>  1 file changed, 18 insertions(+), 32 deletions(-)
> 
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index bd8b8a17ae..391681260c 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -1693,6 +1693,7 @@ static efi_status_t EFIAPI efi_load_image(bool 
> boot_policy,
>   struct efi_loaded_image_obj **image_obj =
>   (struct efi_loaded_image_obj **)image_handle;
>   efi_status_t ret;
> + void *dest_buffer;
>  
>   EFI_ENTRY("%d, %p, %pD, %p, %zd, %p", boot_policy, parent_image,
> file_path, source_buffer, source_size, image_handle);
> @@ -1708,7 +1709,7 @@ static efi_status_t EFIAPI efi_load_image(bool 
> boot_policy,
>   }
>  
>   if (!source_buffer) {
> - ret = efi_load_image_from_path(file_path, _buffer,
> + ret = efi_load_image_from_path(file_path, _buffer,
>  _size);
>   if (ret != EFI_SUCCESS)
>   goto error;
> @@ -1721,41 +1722,26 @@ static efi_status_t EFIAPI efi_load_image(bool 
> boot_policy,
>   /* In this case, file_path is the "device" path, i.e.
>* something like a HARDWARE_DEVICE:MEMORY_MAPPED
>*/
> - u64 addr;
> - void *dest_buffer;
> -
> - ret = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES,
> -  EFI_RUNTIME_SERVICES_CODE,
> -  efi_size_in_pages(source_size), );
> - if (ret != EFI_SUCCESS)
> - goto error;
> - dest_buffer = (void *)(uintptr_t)addr;
> - memcpy(dest_buffer, source_buffer, source_size);
> - source_buffer = dest_buffer;
> -

Are you sure? This code is what you added in your recent commit
0e18f584de59 ("efi_loader: LoadImage: always allocate new pages")
at v2019.04-rc2.

IMO, the comment:
>   /* In this case, file_path is the "device" path, i.e.
>* something like a HARDWARE_DEVICE:MEMORY_MAPPED

is also not accurate because "file_path" is normally non-NULL,
indicating where the content of "source_buffer" comes from.
In other words, "HARDWARE_DEVICE:MEMORY_MAPPED" is a quite irregular case.

-Takahiro Akashi


> + dest_buffer = source_buffer;
>   dp = file_path;
>   fp = NULL;
>   }
>   ret = efi_setup_loaded_image(dp, fp, image_obj, );
> - if (ret != EFI_SUCCESS)
> - goto error_invalid_image;
> - ret = efi_load_pe(*image_obj, source_buffer, info);
> - if (ret != EFI_SUCCESS)
> - goto error_invalid_image;
> - /* Update the type of the allocated memory */
> - efi_add_memory_map((uintptr_t)source_buffer,
> -efi_size_in_pages(source_size),
> -info->image_code_type, false);
> - info->system_table = 
> - info->parent_handle = parent_image;
> - return EFI_EXIT(EFI_SUCCESS);
> -error_invalid_image:
> - /* The image is invalid. Release all associated resources. */
> - efi_free_pages((uintptr_t)source_buffer,
> -efi_size_in_pages(source_size));
> - efi_delete_handle(*image_handle);
> - *image_handle = NULL;
> - free(info);
> + if (ret == EFI_SUCCESS)
> + ret = efi_load_pe(*image_obj, dest_buffer, info);
> + if (!source_buffer)
> + /* Release buffer to which file was loaded */
> + efi_free_pages((uintptr_t)dest_buffer,
> +efi_size_in_pages(source_size));
> + if (ret == EFI_SUCCESS) {
> + info->system_table = 
> + info->parent_handle = parent_image;
> + } else {
> + /* The image is invalid. Release all associated resources. */
> + efi_delete_handle(*image_handle);
> + *image_handle = NULL;
> + free(info);
> + }
>  error:
>   return EFI_EXIT(ret);
>  }
> -- 
> 2.20.1
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC 1/8] efi_loader: boottime: don't add device path protocol to image handle

[AKASHI Takahiro]

On Tue, Mar 05, 2019 at 08:48:37PM +0100, Heinrich Schuchardt wrote:
> On 3/5/19 6:53 AM, AKASHI Takahiro wrote:
> > It is just wrong to add devcie path protocol to image handle.
> > 
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  lib/efi_loader/efi_boottime.c | 11 +--
> >  1 file changed, 1 insertion(+), 10 deletions(-)
> > 
> > diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> > index bd8b8a17ae71..7bd9c0a952d4 100644
> > --- a/lib/efi_loader/efi_boottime.c
> > +++ b/lib/efi_loader/efi_boottime.c
> > @@ -1540,17 +1540,8 @@ efi_status_t efi_setup_loaded_image(struct 
> > efi_device_path *device_path,
> > info->file_path = file_path;
> > info->system_table = 
> >  
> > -   if (device_path) {
> > +   if (device_path)
> > info->device_handle = efi_dp_find_obj(device_path, NULL);
> > -   /*
> > -* When asking for the device path interface, return
> > -* bootefi_device_path
> > -*/
> > -   ret = efi_add_protocol(>header,
> > -  _guid_device_path, device_path);
> 
> Installing the device path is not the problem. It is the GUID that is
> wrong. Use EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL_GUID here.

Okay, but I believe that we need duplicate device_path here
before installing it as EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL_GUID.

See this line:

> > info->device_handle = efi_dp_find_obj(device_path, NULL);

Normally, device_path is expected to be already associated with
another handle. We should not allow two handles to share one protocol(data).
That is also why I initially believed that add_protocol() should be removed.

Thanks,
-Takahiro Akashi


> UEFI Spec 2.7:
> 
> "The Loaded Image Device Path Protocol must be installed onto the image
> handle of a PE/COFF image loaded through the EFI Boot Service LoadImage()."
> 
> Best regards
> 
> Heinrich
> 
> > -   if (ret != EFI_SUCCESS)
> > -   goto failure;
> > -   }
> >  
> > /*
> >  * When asking for the loaded_image interface, just
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/1] efi_loader: bootmgr: support BootNext and BootCurrent variable behavior

[AKASHI Takahiro]

On Tue, Mar 05, 2019 at 08:38:40PM +0100, Heinrich Schuchardt wrote:
> On 3/5/19 2:58 AM, AKASHI Takahiro wrote:
> > See UEFI v2.7, section 3.1.2 for details of the specification.
> > 
> > With efidebug command, you can run any EFI boot option as follows:
> >   => efi boot add 1 SHELL ...
> >   => efi boot add 2 HELLO ...
> >   => efi boot order 1 2
> >   => efi bootmgr
> >  (starting SHELL ...)
> > 
> >   => efi boot next 2
> >   => efi bootmgr
> >  (starting HELLO ...)
> >   => env print -e
> >   
> >   BootCurrent: {boot,run}(blob)
> >   :  02 00..
> >   BootOrder: {boot,run}(blob)
> >   :  01 00 02 00  
> > 
> > Signed-off-by: AKASHI Takahiro 
> 
> Please, use scripts/get_maintainer.pl to determine the correct
> recipients. You missed Alex's new email address.

Okay.

> > ---
> >  lib/efi_loader/efi_bootmgr.c | 40 
> >  1 file changed, 36 insertions(+), 4 deletions(-)
> > 
> > diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> > index 417016102b48..1575c5c09e46 100644
> > --- a/lib/efi_loader/efi_bootmgr.c
> > +++ b/lib/efi_loader/efi_bootmgr.c
> > @@ -141,6 +141,7 @@ static void *try_load_entry(uint16_t n, struct 
> > efi_device_path **device_path,
> > efi_deserialize_load_option(, load_option);
> >  
> > if (lo.attributes & LOAD_OPTION_ACTIVE) {
> > +   u32 attributes;
> > efi_status_t ret;
> >  
> > debug("%s: trying to load \"%ls\" from %pD\n",
> > @@ -151,6 +152,16 @@ static void *try_load_entry(uint16_t n, struct 
> > efi_device_path **device_path,
> > if (ret != EFI_SUCCESS)
> > goto error;
> >  
> > +   attributes = EFI_VARIABLE_BOOTSERVICE_ACCESS |
> > +EFI_VARIABLE_RUNTIME_ACCESS;
> > +   size = sizeof(n);
> > +   ret = EFI_CALL(efi_set_variable(
> > +   L"BootCurrent",
> > +   (efi_guid_t *)_global_variable_guid,
> > +   attributes, size, ));
> > +   if (ret != EFI_SUCCESS)
> > +   goto error;
> > +
> > printf("Booting: %ls\n", lo.label);
> > efi_dp_split_file_path(lo.file_path, device_path, file_path);
> > }
> > @@ -162,21 +173,42 @@ error:
> >  }
> >  
> >  /*
> > - * Attempt to load, in the order specified by BootOrder EFI variable, the
> > - * available load-options, finding and returning the first one that can
> > - * be loaded successfully.
> > + * Attempt to load from BootNext or in the order specified by BootOrder
> > + * EFI variable, the available load-options, finding and returning
> > + * the first one that can be loaded successfully.
> >   */
> >  void *efi_bootmgr_load(struct efi_device_path **device_path,
> >struct efi_device_path **file_path)
> >  {
> > -   uint16_t *bootorder;
> > +   u16 bootnext, *bootorder;
> 
> bootnext has enough space for the terminating \n. That is way too small.
> 
> You want to call efi_get_variable() twice. Get the buffer size needed in
> the first round. malloc() a buffer. Then actually read the variable.
> Finally free() the buffer.

No.
"BootNext" is always a 16-bit integer, and "bootnext" is a u16 variable,
not a pointer.
So we don't need to call get_variable() twice. That is why I didn't use
get_var() here. I believe that you seem to like "code efficiency."

> > efi_uintn_t size;
> > void *image = NULL;
> > int i, num;
> > +   efi_status_t ret;
> >  
> > bs = systab.boottime;
> > rs = systab.runtime;
> >  
> > +   /* BootNext */
> > +   size = sizeof(bootnext);
> > +   ret = EFI_CALL(efi_get_variable(L"BootNext",
> > +   (efi_guid_t *)_global_variable_guid,
> > +   NULL, , ));
> > +   if (ret == EFI_SUCCESS) {
> 
> The expected value of ret for an existing variable of size > 0 is
> EFI_BUFFER_TOO_SMALL.
> 
> > +   /* delete BootNext */
> > +   ret = EFI_CALL(efi_set_variable(
> > +   L"BootNext",
> > +   (efi_guid_t *)_global_variable_guid,
> > +   0, 0, ));
> > +   if (ret == EFI_SUCCESS) {
> 
> Why would loading the boot entry depend on the return value here?

Deleting "BootNex" is required by UEFI spec.
In addition, if we fail to delete it, we will see the same application
start again when executing boot manager next time.

Thanks,
-Takahiro Akashi

> > +   image = try_load_entry(bootnext,
> 
> Best regards
> 
> Heinrich
> 
> > +  device_path, file_path);
> > +   if (image)
> > +   goto error;
> > +   }
> > +   }
> > +
> > +   /* BootOrder */
> > bootorder = get_var(L"BootOrder", _global_variable_guid, );
> > if (!bootorder) {
> > 

Re: [U-Boot] [PATCH v2 2/3] net: add higmacv300 Ethernet driver for HiSilicon platform

[Joe Hershberger]

On Sun, Feb 17, 2019 at 9:39 PM Shawn Guo  wrote:
>
> It adds the driver for HIGMACV300 Ethernet controller found on HiSilicon
> SoCs like Hi3798CV200.  It's based on a downstream U-Boot driver, but
> quite a lot of code gets rewritten and cleaned up to adopt driver model
> and PHY API.
>
> Signed-off-by: Shawn Guo 

Looks pretty good. I have a few  questions / comments below.

> ---
>  drivers/net/Kconfig  |   9 +
>  drivers/net/Makefile |   1 +
>  drivers/net/higmacv300.c | 597 +++
>  3 files changed, 607 insertions(+)
>  create mode 100644 drivers/net/higmacv300.c
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 6a570285aac5..ad1e50c0e8ca 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -525,4 +525,13 @@ config MEDIATEK_ETH
>   This Driver support MediaTek Ethernet GMAC
>   Say Y to enable support for the MediaTek Ethernet GMAC.
>
> +config HIGMACV300_ETH
> +   bool "HiSilicon Gigabit Ethernet Controller"
> +   depends on DM_ETH
> +   select DM_RESET
> +   select PHYLIB
> +   help
> + This driver supports HIGMACV300 Ethernet controller found on
> + HiSilicon SoCs.
> +
>  endif # NETDEVICES
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 51be72b0aa86..8d02a378964b 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -76,3 +76,4 @@ obj-$(CONFIG_SNI_AVE) += sni_ave.o
>  obj-y += ti/
>  obj-$(CONFIG_MEDIATEK_ETH) += mtk_eth.o
>  obj-y += mscc_eswitch/
> +obj-$(CONFIG_HIGMACV300_ETH) += higmacv300.o
> diff --git a/drivers/net/higmacv300.c b/drivers/net/higmacv300.c
> new file mode 100644
> index ..549c26b19b99
> --- /dev/null
> +++ b/drivers/net/higmacv300.c
> @@ -0,0 +1,597 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019, Linaro Limited
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define STATION_ADDR_LOW   0x
> +#define STATION_ADDR_HIGH  0x0004
> +#define MAC_DUPLEX_HALF_CTRL   0x0008
> +#define PORT_MODE  0x0040
> +#define PORT_EN0x0044
> +#define BIT_TX_EN  BIT(2)
> +#define BIT_RX_EN  BIT(1)
> +#define MODE_CHANGE_EN 0x01b4
> +#define BIT_MODE_CHANGE_EN BIT(0)
> +#define MDIO_SINGLE_CMD0x03c0
> +#define BIT_MDIO_BUSY  BIT(20)
> +#define MDIO_READ  (BIT(17) | BIT_MDIO_BUSY)
> +#define MDIO_WRITE (BIT(16) | BIT_MDIO_BUSY)
> +#define MDIO_SINGLE_DATA   0x03c4
> +#define MDIO_RDATA_STATUS  0x03d0
> +#define BIT_MDIO_RDATA_INVALID BIT(0)
> +#define RX_FQ_START_ADDR   0x0500
> +#define RX_FQ_DEPTH0x0504
> +#define RX_FQ_WR_ADDR  0x0508
> +#define RX_FQ_RD_ADDR  0x050c
> +#define RX_FQ_REG_EN   0x0518
> +#define RX_BQ_START_ADDR   0x0520
> +#define RX_BQ_DEPTH0x0524
> +#define RX_BQ_WR_ADDR  0x0528
> +#define RX_BQ_RD_ADDR  0x052c
> +#define RX_BQ_REG_EN   0x0538
> +#define TX_BQ_START_ADDR   0x0580
> +#define TX_BQ_DEPTH0x0584
> +#define TX_BQ_WR_ADDR  0x0588
> +#define TX_BQ_RD_ADDR  0x058c
> +#define TX_BQ_REG_EN   0x0598
> +#define TX_RQ_START_ADDR   0x05a0
> +#define TX_RQ_DEPTH0x05a4
> +#define TX_RQ_WR_ADDR  0x05a8
> +#define TX_RQ_RD_ADDR  0x05ac
> +#define TX_RQ_REG_EN   0x05b8
> +#define BIT_START_ADDR_EN  BIT(2)
> +#define BIT_DEPTH_EN   BIT(1)
> +#define DESC_WR_RD_ENA 0x05cc
> +#define BIT_RX_OUTCFF_WR   BIT(3)
> +#define BIT_RX_CFF_RD  BIT(2)
> +#define BIT_TX_OUTCFF_WR   BIT(1)
> +#define BIT_TX_CFF_RD  BIT(0)
> +#define BITS_DESC_ENA  (BIT_RX_OUTCFF_WR | BIT_RX_CFF_RD | \
> +BIT_TX_OUTCFF_WR | BIT_TX_CFF_RD)
> +
> +/* MACIF_CTRL */
> +#define RGMII_SPEED_1000   0x2c
> +#define RGMII_SPEED_1000x2f
> +#define RGMII_SPEED_10 0x2d
> +#define MII_SPEED_100  0x0f
> +#define MII_SPEED_10   0x0d
> +#define GMAC_SPEED_10000x05
> +#define GMAC_SPEED_100 0x01
> +#define GMAC_SPEED_10  0x00
> +#define GMAC_FULL_DUPLEX   BIT(4)
> +
> +#define RX_DESC_NUM64
> +#define TX_DESC_NUM2
> +#define DESC_SIZE  32
> +#define DESC_WORD_SHIFT3
> +#define 

Re: [U-Boot] [U-Boot, v10, 04/10] fdt: parse "reserved-memory" for memory reservation

[Marek Vasut]

On 3/6/19 12:26 AM, Eugeniu Rosca wrote:
> Simon, Marek, All,

Hi,

> Booting Linux on H3-ES2.0-Salvator-X, this patch contributes with
> below runtime errors:
> 
> ERROR: reserving fdt memory region failed (addr=5400 size=300)
> ERROR: reserving fdt memory region failed (addr=5700 size=100)
> ERROR: reserving fdt memory region failed (addr=5800 size=1800)
> ERROR: reserving fdt memory region failed (addr=7000 size=1000)
> 
> I use rcar-3.9.2 device trees from:
> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts?h=rcar-3.9.2

BSP DTs are not supported, we're moving to Linux 5.0 DTs in the next
release, I'll be posting patches once they receive proper testing. The
patches are here [1], along M3N ULCB support, which I believe is broken
thus far and so none of that is posted to the ML yet. I'll be fixing
that at the end of month, once I have physical access to the board (and
there's more stuff coming :) )

[1] https://github.com/marex/u-boot-sh/tree/m3nulcb-v1

> The mainline v5.0 device trees lack the reserved-memory node, so I
> expect the errors will not show up with vanilla kernel and DTB.
> FTR, the errors appear regardless of the value for U-Boot
> CONFIG_ARCH_FIXUP_FDT_MEMORY (=n is the default).
> I tried to play with different values of bootm_size (including the
> recent https://patchwork.ozlabs.org/patch/1052012/), with no success.

The reserved memory nodes are used for the FCNL, right ?
If so, then we will have to deal with it somehow. Can you debug the
problem and propose a patch ?

> I would appreciate your view on how to tackle this. TIA!
> 
> Best regards,
> Eugeniu.
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v10, 04/10] fdt: parse "reserved-memory" for memory reservation

[Eugeniu Rosca]

Simon, Marek, All,

Booting Linux on H3-ES2.0-Salvator-X, this patch contributes with
below runtime errors:

ERROR: reserving fdt memory region failed (addr=5400 size=300)
ERROR: reserving fdt memory region failed (addr=5700 size=100)
ERROR: reserving fdt memory region failed (addr=5800 size=1800)
ERROR: reserving fdt memory region failed (addr=7000 size=1000)

I use rcar-3.9.2 device trees from:
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts?h=rcar-3.9.2

The mainline v5.0 device trees lack the reserved-memory node, so I
expect the errors will not show up with vanilla kernel and DTB.
FTR, the errors appear regardless of the value for U-Boot
CONFIG_ARCH_FIXUP_FDT_MEMORY (=n is the default).
I tried to play with different values of bootm_size (including the
recent https://patchwork.ozlabs.org/patch/1052012/), with no success.

I would appreciate your view on how to tackle this. TIA!

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

Re: [U-Boot] [PATCH] ARM: rmobile: Convert to bootm_size

[Marek Vasut]

On 3/5/19 11:28 PM, Eugeniu Rosca wrote:
> On Tue, Mar 05, 2019 at 07:56:39PM +0100, Marek Vasut wrote:
>> On 3/5/19 7:42 PM, Eugeniu Rosca wrote:
>>> Hello Marek,
>>
>> Hi,
>>
>>> May I ask for your opinion on Renesas commits [1-2] especially in
>>> light of the `bootm_size` changes done in your patch?
>>> The topics look orthogonal to me, but I kindly ask for your confirmation.
>>
>> What do you want to know ? With that commit, U-Boot is sitting in the
>> middle of your RAM and you're likely to overwrite or corrupt it sooner
>> or later, so that patch is not going upstream.
> 
> That's already very helpful. Thanks.
> 
>>
>>> Also, purely related to the `bootm_size` patch, compiling v2019.04-rc3
>>> U-Boot for H3-Salvator-X with the diff [3] applied, I get:
>>>
>>> common/image.c: In function 'env_get_bootm_mapsize':
>>> common/image.c:520:2: error: #error "Take bootm_size from CONFIG"
>>>  #error "Take bootm_size from CONFIG"
>>>   ^
>>>
>>> Does this mean the "CONFIG_SYS_BOOTMAPSZ" definition has to be removed
>>> from include/configs/rcar-gen3-common.h, to allow the patch to have
>>> the desired effect?
>>
>> Possibly, if you could study it a bit and if that's the case, send a
>> patch, that'd be nice.
> 
> Submitted https://patchwork.ozlabs.org/patch/1052012/

Nice , thanks!

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 6/9] riscv: boot images passed to bootm on all harts

[Lukas Auer]

Signed-off-by: Lukas Auer 
Reviewed-by: Anup Patel 
Reviewed-by: Bin Meng 
---

Changes in v2: None

 arch/riscv/lib/bootm.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c
index f36b8702ef..efbd3e23e7 100644
--- a/arch/riscv/lib/bootm.c
+++ b/arch/riscv/lib/bootm.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -81,6 +82,9 @@ static void boot_jump_linux(bootm_headers_t *images, int flag)
 {
void (*kernel)(ulong hart, void *dtb);
int fake = (flag & BOOTM_STATE_OS_FAKE_GO);
+#ifdef CONFIG_SMP
+   int ret;
+#endif
 
kernel = (void (*)(ulong, void *))images->ep;
 
@@ -92,8 +96,15 @@ static void boot_jump_linux(bootm_headers_t *images, int 
flag)
announce_and_cleanup(fake);
 
if (!fake) {
-   if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len)
+   if (IMAGE_ENABLE_OF_LIBFDT && images->ft_len) {
+#ifdef CONFIG_SMP
+   ret = smp_call_function(images->ep,
+   (ulong)images->ft_addr, 0);
+   if (ret)
+   hang();
+#endif
kernel(gd->arch.boot_hart, images->ft_addr);
+   }
}
 }
 
-- 
2.20.1

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

[U-Boot] [PATCH v2 8/9] riscv: fu540: enable SMP

[Lukas Auer]

Signed-off-by: Lukas Auer 
Reviewed-by: Anup Patel 
---

Changes in v2:
- New patch to enable SMP on the SiFive FU540, which was previously sent
independently

 board/sifive/fu540/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
index 6be3d88144..f46437901d 100644
--- a/board/sifive/fu540/Kconfig
+++ b/board/sifive/fu540/Kconfig
@@ -38,5 +38,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy
imply PHY_LIB
imply PHY_MSCC
imply SIFIVE_SERIAL
+   imply SMP
 
 endif
-- 
2.20.1

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

[U-Boot] [PATCH v2 7/9] riscv: do not rely on hart ID passed by previous boot stage

[Lukas Auer]

RISC-V U-Boot expects the hart ID to be passed to it via register a0 by
the previous boot stage. Machine mode firmware such as BBL and OpenSBI
do this when starting their payload (U-Boot) in supervisor mode. If
U-Boot is running in machine mode, this task must be handled by the boot
ROM. Explicitly populate register a0 with the hart ID from the mhartid
CSR to avoid possible problems on RISC-V processors with a boot ROM that
does not handle this task.

Suggested-by: Rick Chen 
Signed-off-by: Lukas Auer 
---

Changes in v2:
- New patch to populate register a0 with the hart ID from the mhartid
CSR in machine-mode

 arch/riscv/cpu/start.S | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 79b753847c..d4daa6e0bf 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -36,6 +36,10 @@
 .section .text
 .globl _start
 _start:
+#ifdef CONFIG_RISCV_MMODE
+   csrra0, mhartid
+#endif
+
/* save hart id and dtb pointer */
mv  s0, a0
mv  s1, a1
-- 
2.20.1

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

[U-Boot] [PATCH v2 3/9] riscv: implement IPI platform functions using SBI

[Lukas Auer]

The supervisor binary interface (SBI) provides the necessary functions
to implement the platform IPI functions riscv_send_ipi() and
riscv_clear_ipi(). Use it to implement them.

This adds support for inter-processor interrupts (IPIs) on RISC-V CPUs
running in supervisor mode. Support for machine mode is already
available for CPUs that include the SiFive CLINT.

Signed-off-by: Lukas Auer 
Reviewed-by: Anup Patel 
Reviewed-by: Bin Meng 
---

Changes in v2: None

 arch/riscv/Kconfig   |  5 +
 arch/riscv/lib/Makefile  |  1 +
 arch/riscv/lib/sbi_ipi.c | 25 +
 3 files changed, 31 insertions(+)
 create mode 100644 arch/riscv/lib/sbi_ipi.c

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 4d7a115569..9da609b33b 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -139,4 +139,9 @@ config NR_CPUS
  Stack memory is pre-allocated. U-Boot must therefore know the
  maximum number of CPUs that may be present.
 
+config SBI_IPI
+   bool
+   default y if RISCV_SMODE
+   depends on SMP
+
 endmenu
diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index 19370f9749..35dbf643e4 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_RISCV_RDTIME) += rdtime.o
 obj-$(CONFIG_SIFIVE_CLINT) += sifive_clint.o
 obj-y  += interrupts.o
 obj-y  += reset.o
+obj-$(CONFIG_SBI_IPI) += sbi_ipi.o
 obj-y   += setjmp.o
 obj-$(CONFIG_SMP) += smp.o
 
diff --git a/arch/riscv/lib/sbi_ipi.c b/arch/riscv/lib/sbi_ipi.c
new file mode 100644
index 00..170346da68
--- /dev/null
+++ b/arch/riscv/lib/sbi_ipi.c
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Fraunhofer AISEC,
+ * Lukas Auer 
+ */
+
+#include 
+#include 
+
+int riscv_send_ipi(int hart)
+{
+   ulong mask;
+
+   mask = 1UL << hart;
+   sbi_send_ipi();
+
+   return 0;
+}
+
+int riscv_clear_ipi(int hart)
+{
+   sbi_clear_ipi();
+
+   return 0;
+}
-- 
2.20.1

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

[U-Boot] [PATCH v2 9/9] riscv: qemu: enable SMP

[Lukas Auer]

Signed-off-by: Lukas Auer 
Reviewed-by: Anup Patel 
Reviewed-by: Bin Meng 
---

Changes in v2: None

 board/emulation/qemu-riscv/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/emulation/qemu-riscv/Kconfig 
b/board/emulation/qemu-riscv/Kconfig
index 88d07d568e..cf057e7de6 100644
--- a/board/emulation/qemu-riscv/Kconfig
+++ b/board/emulation/qemu-riscv/Kconfig
@@ -34,5 +34,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy
imply BOARD_LATE_INIT
imply OF_BOARD_SETUP
imply SIFIVE_SERIAL
+   imply SMP
 
 endif
-- 
2.20.1

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

[U-Boot] [PATCH v2 5/9] riscv: add support for multi-hart systems

[Lukas Auer]

On RISC-V, all harts boot independently. To be able to run on a
multi-hart system, U-Boot must be extended with the functionality to
manage all harts in the system. All harts entering U-Boot are registered
in the available_harts mask stored in global data. A hart lottery system
as used in the Linux kernel selects the hart U-Boot runs on. All other
harts are halted. U-Boot can delegate functions to them using
smp_call_function().

Every hart has a valid pointer to the global data structure and a 8KiB
stack by default. The stack size is set with CONFIG_STACK_SIZE_SHIFT.

Signed-off-by: Lukas Auer 
---

Changes in v2:
- Implement hart lottery to pick main hart to run U-Boot
- Remove CONFIG_MAIN_HART as it is not required anymore
- Register available harts in the available_harts mask

 arch/riscv/Kconfig   |   4 ++
 arch/riscv/cpu/cpu.c |   9 ++-
 arch/riscv/cpu/start.S   | 134 ++-
 arch/riscv/include/asm/csr.h |   1 +
 arch/riscv/lib/asm-offsets.c |   1 +
 5 files changed, 147 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 9da609b33b..3a4470daf3 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -144,4 +144,8 @@ config SBI_IPI
default y if RISCV_SMODE
depends on SMP
 
+config STACK_SIZE_SHIFT
+   int
+   default 13
+
 endmenu
diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
index e662140427..c32de8a4c3 100644
--- a/arch/riscv/cpu/cpu.c
+++ b/arch/riscv/cpu/cpu.c
@@ -12,10 +12,17 @@
 #include 
 
 /*
- * prior_stage_fdt_address must be stored in the data section since it is used
+ * The variables here must be stored in the data section since they are used
  * before the bss section is available.
  */
 phys_addr_t prior_stage_fdt_address __attribute__((section(".data")));
+u32 hart_lottery __attribute__((section(".data"))) = 0;
+
+/*
+ * The main hart running U-Boot has acquired available_harts_lock until it has
+ * finished initialization of global data.
+ */
+u32 available_harts_lock = 1;
 
 static inline bool supports_extension(char ext)
 {
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index a30f6f7194..79b753847c 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -45,6 +46,23 @@ _start:
/* mask all interrupts */
csrwMODE_PREFIX(ie), zero
 
+#ifdef CONFIG_SMP
+   /* check if hart is within range */
+   /* s0: hart id */
+   li  t0, CONFIG_NR_CPUS
+   bge s0, t0, hart_out_of_bounds_loop
+#endif
+
+#ifdef CONFIG_SMP
+   /* set xSIE bit to receive IPIs */
+#ifdef CONFIG_RISCV_MMODE
+   li  t0, MIE_MSIE
+#else
+   li  t0, SIE_SSIE
+#endif
+   csrsMODE_PREFIX(ie), t0
+#endif
+
 /*
  * Set stackpointer in internal/ex RAM to call board_init_f
  */
@@ -56,7 +74,30 @@ call_board_init_f:
 call_board_init_f_0:
mv  a0, sp
jal board_init_f_alloc_reserve
+
+   /*
+* Set global data pointer here for all harts, uninitialized at this
+* point.
+*/
+   mv  gp, a0
+
+   /* setup stack */
+#ifdef CONFIG_SMP
+   /* s0: hart id */
+   sllit0, s0, CONFIG_STACK_SIZE_SHIFT
+   sub sp, a0, t0
+#else
mv  sp, a0
+#endif
+
+   /*
+* Pick hart to initialize global data and run U-Boot. The other harts
+* wait for initialization to complete.
+*/
+   la  t0, hart_lottery
+   li  s2, 1
+   amoswap.w s2, t1, 0(t0)
+   bnezs2, wait_for_gd_init
 
la  t0, prior_stage_fdt_address
SREGs1, 0(t0)
@@ -66,6 +107,33 @@ call_board_init_f_0:
/* save the boot hart id to global_data */
SREGs0, GD_BOOT_HART(gp)
 
+   la  t0, available_harts_lock
+   fence   rw, w
+   amoswap.w zero, zero, 0(t0)
+
+wait_for_gd_init:
+   la  t0, available_harts_lock
+   li  t1, 1
+1: amoswap.w t1, t1, 0(t0)
+   fence   r, rw
+   bnezt1, 1b
+
+   /* register available harts in the available_harts mask */
+   li  t1, 1
+   sll t1, t1, s0
+   LREGt2, GD_AVAILABLE_HARTS(gp)
+   or  t2, t2, t1
+   SREGt2, GD_AVAILABLE_HARTS(gp)
+
+   fence   rw, w
+   amoswap.w zero, zero, 0(t0)
+
+   /*
+* Continue on hart lottery winner, others branch to
+* secondary_hart_loop.
+*/
+   bnezs2, secondary_hart_loop
+
/* Enable cache */
jal icache_enable
jal dcache_enable
@@ -95,7 +163,14 @@ relocate_code:
  *Set up the stack
  */
 stack_setup:
+#ifdef CONFIG_SMP
+   /* s0: hart id */
+   sllit0, s0, CONFIG_STACK_SIZE_SHIFT
+   sub sp, s2, t0
+#else
mv  sp, s2
+#endif
+
la  t0, _start
sub t6, s4, t0  /* t6 <- relocation offset */
beq t0, s4, 

[U-Boot] [PATCH v2 2/9] riscv: import the supervisor binary interface header file

[Lukas Auer]

Import the supervisor binary interface (SBI) header file from Linux
(arch/riscv/include/asm/sbi.h). The last change to it was in commit
6d60b6ee0c97 ("RISC-V: Device, timer, IRQs, and the SBI").

Signed-off-by: Lukas Auer 
Reviewed-by: Anup Patel 
Reviewed-by: Bin Meng 
---

Changes in v2: None

 arch/riscv/include/asm/sbi.h | 94 
 1 file changed, 94 insertions(+)
 create mode 100644 arch/riscv/include/asm/sbi.h

diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
new file mode 100644
index 00..ced57defdd
--- /dev/null
+++ b/arch/riscv/include/asm/sbi.h
@@ -0,0 +1,94 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2015 Regents of the University of California
+ *
+ * Taken from Linux arch/riscv/include/asm/sbi.h
+ */
+
+#ifndef _ASM_RISCV_SBI_H
+#define _ASM_RISCV_SBI_H
+
+#include 
+
+#define SBI_SET_TIMER 0
+#define SBI_CONSOLE_PUTCHAR 1
+#define SBI_CONSOLE_GETCHAR 2
+#define SBI_CLEAR_IPI 3
+#define SBI_SEND_IPI 4
+#define SBI_REMOTE_FENCE_I 5
+#define SBI_REMOTE_SFENCE_VMA 6
+#define SBI_REMOTE_SFENCE_VMA_ASID 7
+#define SBI_SHUTDOWN 8
+
+#define SBI_CALL(which, arg0, arg1, arg2) ({   \
+   register uintptr_t a0 asm ("a0") = (uintptr_t)(arg0);   \
+   register uintptr_t a1 asm ("a1") = (uintptr_t)(arg1);   \
+   register uintptr_t a2 asm ("a2") = (uintptr_t)(arg2);   \
+   register uintptr_t a7 asm ("a7") = (uintptr_t)(which);  \
+   asm volatile ("ecall"   \
+ : "+r" (a0)   \
+ : "r" (a1), "r" (a2), "r" (a7)\
+ : "memory");  \
+   a0; \
+})
+
+/* Lazy implementations until SBI is finalized */
+#define SBI_CALL_0(which) SBI_CALL(which, 0, 0, 0)
+#define SBI_CALL_1(which, arg0) SBI_CALL(which, arg0, 0, 0)
+#define SBI_CALL_2(which, arg0, arg1) SBI_CALL(which, arg0, arg1, 0)
+
+static inline void sbi_console_putchar(int ch)
+{
+   SBI_CALL_1(SBI_CONSOLE_PUTCHAR, ch);
+}
+
+static inline int sbi_console_getchar(void)
+{
+   return SBI_CALL_0(SBI_CONSOLE_GETCHAR);
+}
+
+static inline void sbi_set_timer(uint64_t stime_value)
+{
+#if __riscv_xlen == 32
+   SBI_CALL_2(SBI_SET_TIMER, stime_value, stime_value >> 32);
+#else
+   SBI_CALL_1(SBI_SET_TIMER, stime_value);
+#endif
+}
+
+static inline void sbi_shutdown(void)
+{
+   SBI_CALL_0(SBI_SHUTDOWN);
+}
+
+static inline void sbi_clear_ipi(void)
+{
+   SBI_CALL_0(SBI_CLEAR_IPI);
+}
+
+static inline void sbi_send_ipi(const unsigned long *hart_mask)
+{
+   SBI_CALL_1(SBI_SEND_IPI, hart_mask);
+}
+
+static inline void sbi_remote_fence_i(const unsigned long *hart_mask)
+{
+   SBI_CALL_1(SBI_REMOTE_FENCE_I, hart_mask);
+}
+
+static inline void sbi_remote_sfence_vma(const unsigned long *hart_mask,
+unsigned long start,
+unsigned long size)
+{
+   SBI_CALL_1(SBI_REMOTE_SFENCE_VMA, hart_mask);
+}
+
+static inline void sbi_remote_sfence_vma_asid(const unsigned long *hart_mask,
+ unsigned long start,
+ unsigned long size,
+ unsigned long asid)
+{
+   SBI_CALL_1(SBI_REMOTE_SFENCE_VMA_ASID, hart_mask);
+}
+
+#endif
-- 
2.20.1

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

[U-Boot] [PATCH v2 4/9] riscv: delay initialization of caches and debug UART

[Lukas Auer]

Move the initialization of the caches and the debug UART until after
board_init_f_init_reserve. This is in preparation for SMP support, where
code prior to this point will be executed by all harts. This ensures
that initialization will only be performed once for the main hart
running U-Boot.

Signed-off-by: Lukas Auer 
Reviewed-by: Anup Patel 
Reviewed-by: Bin Meng 
---

Changes in v2: None

 arch/riscv/cpu/start.S | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 81ea52b170..a30f6f7194 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -45,10 +45,6 @@ _start:
/* mask all interrupts */
csrwMODE_PREFIX(ie), zero
 
-   /* Enable cache */
-   jal icache_enable
-   jal dcache_enable
-
 /*
  * Set stackpointer in internal/ex RAM to call board_init_f
  */
@@ -57,10 +53,6 @@ call_board_init_f:
li  t1, CONFIG_SYS_INIT_SP_ADDR
and sp, t1, t0  /* force 16 byte alignment */
 
-#ifdef CONFIG_DEBUG_UART
-   jal debug_uart_init
-#endif
-
 call_board_init_f_0:
mv  a0, sp
jal board_init_f_alloc_reserve
@@ -74,6 +66,14 @@ call_board_init_f_0:
/* save the boot hart id to global_data */
SREGs0, GD_BOOT_HART(gp)
 
+   /* Enable cache */
+   jal icache_enable
+   jal dcache_enable
+
+#ifdef CONFIG_DEBUG_UART
+   jal debug_uart_init
+#endif
+
mv  a0, zero/* a0 <-- boot_flags = 0 */
la  t5, board_init_f
jr  t5  /* jump to board_init_f() */
-- 
2.20.1

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

[U-Boot] [PATCH v2 1/9] riscv: add infrastructure for calling functions on other harts

[Lukas Auer]

Harts on RISC-V boot independently, U-Boot is responsible for managing
them. Functions are called on other harts with smp_call_function(),
which sends inter-processor interrupts (IPIs) to all other available
harts. Available harts are those marked as available in the device tree
and present in the available_harts mask stored in global data. The
available_harts mask is used to register all harts that have entered
U-Boot. Functions are specified with their address and two function
arguments (argument 2 and 3). The first function argument is always the
hart ID of the hart calling the function. On the other harts, the IPI
interrupt handler handle_ipi() must be called on software interrupts to
handle the request and call the specified function.

Functions are stored in the ipi_data data structure. Every hart has its
own data structure in global data. While this is not required at the
moment (all harts are expected to boot Linux), this does allow future
expansion, where other harts may be used for monitoring or other tasks.

Signed-off-by: Lukas Auer 
---

Changes in v2:
- Remove unneeded quotes from NR_CPUS Kconfig entry
- Move memory barrier from send_ipi_many() to handle_ipi()
- Add check in send_ipi_many so that IPIs are only sent to available
harts as indicated by the available_harts mask

 arch/riscv/Kconfig   |  19 +
 arch/riscv/include/asm/global_data.h |   6 ++
 arch/riscv/include/asm/smp.h |  53 
 arch/riscv/lib/Makefile  |   1 +
 arch/riscv/lib/smp.c | 116 +++
 5 files changed, 195 insertions(+)
 create mode 100644 arch/riscv/include/asm/smp.h
 create mode 100644 arch/riscv/lib/smp.c

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 36512a8995..4d7a115569 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -120,4 +120,23 @@ config RISCV_RDTIME
 config SYS_MALLOC_F_LEN
default 0x1000
 
+config SMP
+   bool "Symmetric Multi-Processing"
+   help
+ This enables support for systems with more than one CPU. If
+ you say N here, U-Boot will run on single and multiprocessor
+ machines, but will use only one CPU of a multiprocessor
+ machine. If you say Y here, U-Boot will run on many, but not
+ all, single processor machines.
+
+config NR_CPUS
+   int "Maximum number of CPUs (2-32)"
+   range 2 32
+   depends on SMP
+   default 8
+   help
+ On multiprocessor machines, U-Boot sets up a stack for each CPU.
+ Stack memory is pre-allocated. U-Boot must therefore know the
+ maximum number of CPUs that may be present.
+
 endmenu
diff --git a/arch/riscv/include/asm/global_data.h 
b/arch/riscv/include/asm/global_data.h
index a3a342c6e1..80e3165e39 100644
--- a/arch/riscv/include/asm/global_data.h
+++ b/arch/riscv/include/asm/global_data.h
@@ -10,12 +10,18 @@
 #ifndef__ASM_GBL_DATA_H
 #define __ASM_GBL_DATA_H
 
+#include 
+
 /* Architecture-specific global data */
 struct arch_global_data {
long boot_hart; /* boot hart id */
 #ifdef CONFIG_SIFIVE_CLINT
void __iomem *clint;/* clint base address */
 #endif
+#ifdef CONFIG_SMP
+   struct ipi_data ipi[CONFIG_NR_CPUS];
+#endif
+   ulong available_harts;
 };
 
 #include 
diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
new file mode 100644
index 00..bc863fdbaf
--- /dev/null
+++ b/arch/riscv/include/asm/smp.h
@@ -0,0 +1,53 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2019 Fraunhofer AISEC,
+ * Lukas Auer 
+ */
+
+#ifndef _ASM_RISCV_SMP_H
+#define _ASM_RISCV_SMP_H
+
+/**
+ * struct ipi_data - Inter-processor interrupt (IPI) data structure
+ *
+ * IPIs are used for SMP support to communicate to other harts what function to
+ * call. Functions are in the form
+ * void (*addr)(ulong hart, ulong arg0, ulong arg1).
+ *
+ * The function address and the two arguments, arg0 and arg1, are stored in the
+ * IPI data structure. The hart ID is inserted by the hart handling the IPI and
+ * calling the function.
+ *
+ * @addr: Address of function
+ * @arg0: First argument of function
+ * @arg1: Second argument of function
+ */
+struct ipi_data {
+   ulong addr;
+   ulong arg0;
+   ulong arg1;
+};
+
+/**
+ * handle_ipi() - interrupt handler for software interrupts
+ *
+ * The IPI interrupt handler must be called to handle software interrupts. It
+ * calls the function specified in the hart's IPI data structure.
+ *
+ * @hart: Hart ID of the current hart
+ */
+void handle_ipi(ulong hart);
+
+/**
+ * smp_call_function() - Call a function on all other harts
+ *
+ * Send IPIs with the specified function call to all harts.
+ *
+ * @addr: Address of function
+ * @arg0: First argument of function
+ * @arg1: Second argument of function
+ * @return 0 if OK, -ve on error
+ */
+int smp_call_function(ulong addr, ulong arg0, ulong arg1);
+
+#endif
diff --git a/arch/riscv/lib/Makefile 

[U-Boot] [PATCH v2 0/9] SMP support for RISC-V

[Lukas Auer]

This patch series adds SMP support for RISC-V to U-Boot. It allows
U-Boot to run on multi-hart systems (hart is the RISC-V terminology for
hardware thread). Images passed to bootm will be started on all harts.
The bootm command is currently the only one that will boot images on all
harts, bootefi is not yet supported.

The patches have been successfully tested on both QEMU (machine and
supervisor mode) and the HiFive Unleashed board (supervisor mode), using
BBL and OpenSBI.
Mainline QEMU requires two patches [1, 2] to run in this configuration.

[1]: https://patchwork.ozlabs.org/patch/1039493/
[2]: https://patchwork.ozlabs.org/patch/1039082/

Changes in v2:
- Remove unneeded quotes from NR_CPUS Kconfig entry
- Move memory barrier from send_ipi_many() to handle_ipi()
- Add check in send_ipi_many so that IPIs are only sent to available
harts as indicated by the available_harts mask
- Implement hart lottery to pick main hart to run U-Boot
- Remove CONFIG_MAIN_HART as it is not required anymore
- Register available harts in the available_harts mask
- New patch to populate register a0 with the hart ID from the mhartid
CSR in machine-mode
- New patch to enable SMP on the SiFive FU540, which was previously sent
independently

Lukas Auer (9):
  riscv: add infrastructure for calling functions on other harts
  riscv: import the supervisor binary interface header file
  riscv: implement IPI platform functions using SBI
  riscv: delay initialization of caches and debug UART
  riscv: add support for multi-hart systems
  riscv: boot images passed to bootm on all harts
  riscv: do not rely on hart ID passed by previous boot stage
  riscv: fu540: enable SMP
  riscv: qemu: enable SMP

 arch/riscv/Kconfig   |  28 +
 arch/riscv/cpu/cpu.c |   9 +-
 arch/riscv/cpu/start.S   | 152 +--
 arch/riscv/include/asm/csr.h |   1 +
 arch/riscv/include/asm/global_data.h |   6 ++
 arch/riscv/include/asm/sbi.h |  94 +
 arch/riscv/include/asm/smp.h |  53 ++
 arch/riscv/lib/Makefile  |   2 +
 arch/riscv/lib/asm-offsets.c |   1 +
 arch/riscv/lib/bootm.c   |  13 ++-
 arch/riscv/lib/sbi_ipi.c |  25 +
 arch/riscv/lib/smp.c | 116 
 board/emulation/qemu-riscv/Kconfig   |   1 +
 board/sifive/fu540/Kconfig   |   1 +
 14 files changed, 492 insertions(+), 10 deletions(-)
 create mode 100644 arch/riscv/include/asm/sbi.h
 create mode 100644 arch/riscv/include/asm/smp.h
 create mode 100644 arch/riscv/lib/sbi_ipi.c
 create mode 100644 arch/riscv/lib/smp.c

-- 
2.20.1

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

[U-Boot] [PATCH v2, RESEND] fdt: Fix FIT header verification in mkimage and conduct same checks as bootm

[Jordan Hand]

Signed-off-by: Jordan Hand 
---
FIT header verification in mkimage was treating a return code as a boolean,
which meant that failures in validating the fit were seen as successes.

Additionally, mkimage was checking all formats to find a header which
passes validation, rather than using the image type specified to
mkimage.

checkpatch.pl checks for lines ending with '(' and alignment matching
open parentheses are ignored to keep with existing coding style.

With regards to Simon's comment about imagetool pytests, I don't
currently have time to spare on this but I will keep it on my backlog
and try to address it in a future patch.

Changes in v2:
- Return EXIT_FAILURE on failure from fit_verify_header and comment that
fact
- Address typos and style errors from comments
- Add docs for parameters to imagetool_verify_print_header_by_type

 tools/fit_common.c |  5 -
 tools/fit_common.h |  8 
 tools/imagetool.c  | 34 +-
 tools/imagetool.h  | 19 +++
 tools/mkimage.c|  2 +-
 5 files changed, 65 insertions(+), 3 deletions(-)

diff --git a/tools/fit_common.c b/tools/fit_common.c
index d96085eaad..9506390214 100644
--- a/tools/fit_common.c
+++ b/tools/fit_common.c
@@ -26,7 +26,10 @@
 int fit_verify_header(unsigned char *ptr, int image_size,
struct image_tool_params *params)
 {
-   return fdt_check_header(ptr);
+   if (fdt_check_header(ptr) != EXIT_SUCCESS || !fit_check_format(ptr))
+   return EXIT_FAILURE;
+
+   return EXIT_SUCCESS;
 }
 
 int fit_check_image_types(uint8_t type)
diff --git a/tools/fit_common.h b/tools/fit_common.h
index 71e792e3c4..9e09624f64 100644
--- a/tools/fit_common.h
+++ b/tools/fit_common.h
@@ -10,6 +10,14 @@
 #include "mkimage.h"
 #include 
 
+/**
+ * Verify the format of FIT header pointed to by ptr
+ *
+ * @ptr: image header to be verified
+ * @image_size: size of while image
+ * @params: mkimage parameters
+ * @return 0 if OK, -1 on error
+ */
 int fit_verify_header(unsigned char *ptr, int image_size,
struct image_tool_params *params);
 
diff --git a/tools/imagetool.c b/tools/imagetool.c
index b3e628f612..ba1f64aa37 100644
--- a/tools/imagetool.c
+++ b/tools/imagetool.c
@@ -46,7 +46,7 @@ int imagetool_verify_print_header(
 
if (retval == 0) {
/*
-* Print the image information  if verify is
+* Print the image information if verify is
 * successful
 */
if ((*curr)->print_header) {
@@ -65,6 +65,38 @@ int imagetool_verify_print_header(
return retval;
 }
 
+int imagetool_verify_print_header_by_type(
+   void *ptr,
+   struct stat *sbuf,
+   struct image_type_params *tparams,
+   struct image_tool_params *params)
+{
+   int retval;
+
+   retval = tparams->verify_header((unsigned char *)ptr, sbuf->st_size,
+   params);
+
+   if (retval == 0) {
+   /*
+* Print the image information if verify is successful
+*/
+   if (tparams->print_header) {
+   if (!params->quiet)
+   tparams->print_header(ptr);
+   } else {
+   fprintf(stderr,
+   "%s: print_header undefined for %s\n",
+   params->cmdname, tparams->name);
+   }
+   } else {
+   fprintf(stderr,
+   "%s: verify_header failed for %s with exit code %d\n",
+   params->cmdname, tparams->name, retval);
+   }
+
+   return retval;
+}
+
 int imagetool_save_subimage(
const char *file_name,
ulong file_data,
diff --git a/tools/imagetool.h b/tools/imagetool.h
index 71471420f9..2689a4004a 100644
--- a/tools/imagetool.h
+++ b/tools/imagetool.h
@@ -179,6 +179,25 @@ int imagetool_verify_print_header(
struct image_type_params *tparams,
struct image_tool_params *params);
 
+/*
+ * imagetool_verify_print_header_by_type() - verifies the image header
+ *
+ * Verify the image_header for the image type given by tparams.
+ * If verification is successful, this prints the respective header.
+ * @ptr: pointer the the image header
+ * @sbuf: stat information about the file pointed to by ptr
+ * @tparams: image type parameters
+ * @params: mkimage parameters
+ *
+ * @return 0 on success, negative if input image format does not match with
+ * the given image type
+ */
+int imagetool_verify_print_header_by_type(
+   void *ptr,
+   struct stat *sbuf,
+   struct image_type_params *tparams,
+   struct image_tool_params *params);
+
 /**
  * imagetool_save_subimage - store data into a file
  * @file_name: name of the destination file
diff --git a/tools/mkimage.c 

Re: [U-Boot] [PATCH] ARM: rmobile: Convert to bootm_size

[Eugeniu Rosca]

On Tue, Mar 05, 2019 at 07:56:39PM +0100, Marek Vasut wrote:
> On 3/5/19 7:42 PM, Eugeniu Rosca wrote:
> > Hello Marek,
> 
> Hi,
> 
> > May I ask for your opinion on Renesas commits [1-2] especially in
> > light of the `bootm_size` changes done in your patch?
> > The topics look orthogonal to me, but I kindly ask for your confirmation.
> 
> What do you want to know ? With that commit, U-Boot is sitting in the
> middle of your RAM and you're likely to overwrite or corrupt it sooner
> or later, so that patch is not going upstream.

That's already very helpful. Thanks.

> 
> > Also, purely related to the `bootm_size` patch, compiling v2019.04-rc3
> > U-Boot for H3-Salvator-X with the diff [3] applied, I get:
> > 
> > common/image.c: In function 'env_get_bootm_mapsize':
> > common/image.c:520:2: error: #error "Take bootm_size from CONFIG"
> >  #error "Take bootm_size from CONFIG"
> >   ^
> > 
> > Does this mean the "CONFIG_SYS_BOOTMAPSZ" definition has to be removed
> > from include/configs/rcar-gen3-common.h, to allow the patch to have
> > the desired effect?
> 
> Possibly, if you could study it a bit and if that's the case, send a
> patch, that'd be nice.

Submitted https://patchwork.ozlabs.org/patch/1052012/

> 
> > [1] https://github.com/renesas-rcar/u-boot/commit/86ad30910df818
> > ("arm: rcar_gen3: Add skip of relocation")
> > [2] https://github.com/renesas-rcar/u-boot/commit/91e27e4cc463e ("arm:
> > rcar_gen3: Add skip of relocation")
> > [3] Brutal way to reveal the active bootm_size:
> > diff --git a/common/image.c b/common/image.c
> > index 4d4248f234fb..d65de506060b 100644
> > --- a/common/image.c
> > +++ b/common/image.c
> > @@ -517,8 +517,10 @@ phys_size_t env_get_bootm_mapsize(void)
> > }
> > 
> >  #if defined(CONFIG_SYS_BOOTMAPSZ)
> > +#error "Take bootm_size from CONFIG"
> > return CONFIG_SYS_BOOTMAPSZ;
> >  #else
> > +#error "Take bootm_size from env"
> > return env_get_bootm_size();
> >  #endif
> >  }
> > 
> > Thanks,
> > Eugeniu.
> > 
> 
> 
> -- 
> Best regards,
> Marek Vasut

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

Re: [U-Boot] [PATCH] ARM: rmobile: ebisu: Remove CONFIG_NET_MULTI

[Marek Vasut]

On 3/5/19 11:16 PM, Eugeniu Rosca wrote:
> CONFIG_NET_MULTI seems to make a comeback each time it is wiped out in:
>  - v2011.12 commit 31a4f1e5b6ee ("board configs: drop NET_MULTI references")
>  - v2017.11 commit 795428fc679f ("net: remove CONFIG_NET_MULTI")
>  - v2018.05 commit ec5c4a8fd64a ("configs: Drop CONFIG_NET_MULTI")
> 
> Remove the dangling reference on E3-Ebisu.
> 
> Fixes: 63e22517a390 ("ARM: renesas: Add R8A77990 E3 Ebisu board")
> Signed-off-by: Eugeniu Rosca 
> ---
>  include/configs/ebisu.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/include/configs/ebisu.h b/include/configs/ebisu.h
> index 2e4974acb2f1..cedc9aff139b 100644
> --- a/include/configs/ebisu.h
> +++ b/include/configs/ebisu.h
> @@ -14,7 +14,6 @@
>  #include "rcar-gen3-common.h"
>  
>  /* Ethernet RAVB */
> -#define CONFIG_NET_MULTI
>  #define CONFIG_BITBANGMII
>  #define CONFIG_BITBANGMII_MULTI
>  
> 
Can you make this into a series and zap NET_MULTI completely,
everywhere, even in config_whitelist.txt ?

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: rmobile: rcar-gen3: Activate bootm_size

[Marek Vasut]

On 3/5/19 11:13 PM, Eugeniu Rosca wrote:
> v2019.01 commit 07a8060a1277 ("ARM: rmobile: Convert to bootm_size")
> attempted converting to bootm_size of 256 MiB below targets:
>  - include/configs/alt.h
>  - include/configs/gose.h
>  - include/configs/koelsch.h
>  - include/configs/lager.h
>  - include/configs/porter.h
>  - include/configs/rcar-gen3-common.h
>  - include/configs/silk.h
>  - include/configs/stout.h
> 
> The update didn't fully work on R-Car3 due to the
> CONFIG_SYS_BOOTMAPSZ=8MiB definition left by v2016.09 commit
> e525d34b476e ("ARM: rmobile: Add support salvator-x board"),
> which is explained in below README excerpt:
> 
> 8<
> CONFIG_SYS_BOOTMAPSZ:
> [..] If CONFIG_SYS_BOOTMAPSZ is undefined,
> then the value in "bootm_size" will be used instead.
> 8<
> 
> Allow the original commit to accomplish its purpose on R-Car3 targets
> by removing the CONFIG_SYS_BOOTMAPSZ definition.
> 
> Fixes: 07a8060a1277 ("ARM: rmobile: Convert to bootm_size")
> Signed-off-by: Eugeniu Rosca 
> ---
>  include/configs/rcar-gen3-common.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/include/configs/rcar-gen3-common.h 
> b/include/configs/rcar-gen3-common.h
> index 06d5d3219ca6..20f982165dd5 100644
> --- a/include/configs/rcar-gen3-common.h
> +++ b/include/configs/rcar-gen3-common.h
> @@ -48,7 +48,6 @@
>  #define CONFIG_SYS_MONITOR_BASE  0x
>  #define CONFIG_SYS_MONITOR_LEN   (256 * 1024)
>  #define CONFIG_SYS_MALLOC_LEN(1 * 1024 * 1024)
> -#define CONFIG_SYS_BOOTMAPSZ (8 * 1024 * 1024)
>  #define CONFIG_SYS_BOOTM_LEN (64 << 20)
>  
>  /* ENV setting */
> 
Applied, thanks.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] ARM: rmobile: ebisu: Remove CONFIG_NET_MULTI

[Eugeniu Rosca]

CONFIG_NET_MULTI seems to make a comeback each time it is wiped out in:
 - v2011.12 commit 31a4f1e5b6ee ("board configs: drop NET_MULTI references")
 - v2017.11 commit 795428fc679f ("net: remove CONFIG_NET_MULTI")
 - v2018.05 commit ec5c4a8fd64a ("configs: Drop CONFIG_NET_MULTI")

Remove the dangling reference on E3-Ebisu.

Fixes: 63e22517a390 ("ARM: renesas: Add R8A77990 E3 Ebisu board")
Signed-off-by: Eugeniu Rosca 
---
 include/configs/ebisu.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/configs/ebisu.h b/include/configs/ebisu.h
index 2e4974acb2f1..cedc9aff139b 100644
--- a/include/configs/ebisu.h
+++ b/include/configs/ebisu.h
@@ -14,7 +14,6 @@
 #include "rcar-gen3-common.h"
 
 /* Ethernet RAVB */
-#define CONFIG_NET_MULTI
 #define CONFIG_BITBANGMII
 #define CONFIG_BITBANGMII_MULTI
 
-- 
2.21.0

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

[U-Boot] [PATCH] ARM: rmobile: rcar-gen3: Activate bootm_size

[Eugeniu Rosca]

v2019.01 commit 07a8060a1277 ("ARM: rmobile: Convert to bootm_size")
attempted converting to bootm_size of 256 MiB below targets:
 - include/configs/alt.h
 - include/configs/gose.h
 - include/configs/koelsch.h
 - include/configs/lager.h
 - include/configs/porter.h
 - include/configs/rcar-gen3-common.h
 - include/configs/silk.h
 - include/configs/stout.h

The update didn't fully work on R-Car3 due to the
CONFIG_SYS_BOOTMAPSZ=8MiB definition left by v2016.09 commit
e525d34b476e ("ARM: rmobile: Add support salvator-x board"),
which is explained in below README excerpt:

8<
CONFIG_SYS_BOOTMAPSZ:
[..] If CONFIG_SYS_BOOTMAPSZ is undefined,
then the value in "bootm_size" will be used instead.
8<

Allow the original commit to accomplish its purpose on R-Car3 targets
by removing the CONFIG_SYS_BOOTMAPSZ definition.

Fixes: 07a8060a1277 ("ARM: rmobile: Convert to bootm_size")
Signed-off-by: Eugeniu Rosca 
---
 include/configs/rcar-gen3-common.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/configs/rcar-gen3-common.h 
b/include/configs/rcar-gen3-common.h
index 06d5d3219ca6..20f982165dd5 100644
--- a/include/configs/rcar-gen3-common.h
+++ b/include/configs/rcar-gen3-common.h
@@ -48,7 +48,6 @@
 #define CONFIG_SYS_MONITOR_BASE0x
 #define CONFIG_SYS_MONITOR_LEN (256 * 1024)
 #define CONFIG_SYS_MALLOC_LEN  (1 * 1024 * 1024)
-#define CONFIG_SYS_BOOTMAPSZ   (8 * 1024 * 1024)
 #define CONFIG_SYS_BOOTM_LEN   (64 << 20)
 
 /* ENV setting */
-- 
2.21.0

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

Re: [U-Boot] [RFC PATCHv1 3/3] ARM: socfpga: let the pl310 driver configure the cache settings

[Marek Vasut]

On 3/5/19 9:13 PM, Dinh Nguyen wrote:
> 
> 
> On 3/5/19 1:20 PM, Marek Vasut wrote:
>> On 3/5/19 8:03 PM, Dinh Nguyen wrote:
>>> Load the PL310 L2 cache driver and allow it to setup the cache settings
>>>
>>> Signed-off-by: Dinh Nguyen 
>>> ---
>>>  arch/arm/mach-socfpga/misc.c | 15 ++-
>>>  1 file changed, 2 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
>>> index fcf211d62b..fb0cfd3c1a 100644
>>> --- a/arch/arm/mach-socfpga/misc.c
>>> +++ b/arch/arm/mach-socfpga/misc.c
>>> @@ -59,20 +59,9 @@ void enable_caches(void)
>>>  #ifdef CONFIG_SYS_L2_PL310
>>>  void v7_outer_cache_enable(void)
>>>  {
>>> -   /* Disable the L2 cache */
>>> -   clrbits_le32(>pl310_ctrl, L2X0_CTRL_EN);
>>> -
>>> -   writel(0x111, >pl310_tag_latency_ctrl);
>>> -   writel(0x121, >pl310_data_latency_ctrl);
>>> -
>>> -   /* enable BRESP, instruction and data prefetch, full line of zeroes */
>>> -   setbits_le32(>pl310_aux_ctrl,
>>> -L310_AUX_CTRL_DATA_PREFETCH_MASK |
>>> -L310_AUX_CTRL_INST_PREFETCH_MASK |
>>> -L310_SHARED_ATT_OVERRIDE_ENABLE);
>>> +   struct udevice *dev;
>>>  
>>> -   /* Enable the L2 cache */
>>> -   setbits_le32(>pl310_ctrl, L2X0_CTRL_EN);
>>> +   uclass_first_device(UCLASS_MISC, );
>>
>> Error handling might help here
>>
> 
> Agreed..Just trying to solicit comments on whether this is the right
> approach? Will add error handling..

I think so.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCHv1 2/3] defconfig: socfpga_sockit_defconfig: enable L2X0_CACHE driver

[Marek Vasut]

On 3/5/19 9:17 PM, Dinh Nguyen wrote:
> 
> 
> On 3/5/19 1:20 PM, Marek Vasut wrote:
>> On 3/5/19 8:03 PM, Dinh Nguyen wrote:
>>> Enable CONFIG_MISC and CONFIG_L2X0_CACHE config options.
>>>
>>> Signed-off-by: Dinh Nguyen 
>>> ---
>>>  configs/socfpga_sockit_defconfig | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/configs/socfpga_sockit_defconfig 
>>> b/configs/socfpga_sockit_defconfig
>>> index 4c17d1a9e4..0009b0ebc3 100644
>>> --- a/configs/socfpga_sockit_defconfig
>>> +++ b/configs/socfpga_sockit_defconfig
>>> @@ -47,6 +47,8 @@ CONFIG_DM_GPIO=y
>>>  CONFIG_DWAPB_GPIO=y
>>>  CONFIG_DM_I2C=y
>>>  CONFIG_SYS_I2C_DW=y
>>> +CONFIG_MISC=y
>>> +CONFIG_L2X0_CACHE=y
>>>  CONFIG_DM_MMC=y
>>>  CONFIG_MMC_DW=y
>>>  CONFIG_MTD_DEVICE=y
>>
>> I think you can just add it as a default into arch/arm/socfpga/Kconfig
>> with 'imply CONFIG_...' instead.
>>
> 
> Ah, yes...thanks. This would prevent the need make the same edits for
> all the other socfpga_*_defconfigs.

Right

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/5] arm: socfpga: imply/default common config options

[Marek Vasut]

On 3/5/19 9:28 PM, Simon Goldschmidt wrote:
> Am 04.03.2019 um 22:34 schrieb Marek Vasut:
>> On 3/4/19 10:23 PM, Simon Goldschmidt wrote:
>>>
>>>
>>> Marek Vasut mailto:ma...@denx.de>> schrieb am Mo., 4.
>>> März 2019, 22:19:
>>>
>>>  On 3/4/19 9:53 PM, Simon Goldschmidt wrote:
>>>  > This commit moves common config options used in all socfpga
>>> boards
>>>  > to select/imply in Kconfig. This both cleans up the defconfig
>>> files
>>>  > as well as makes future changes easier.
>>>  >
>>>  > Options implied/defaulted for all sub-arches:
>>>  > - SPL, SPL_DM, USE_TINY_PRINTF, NR_DRAM_BANKS
>>>  >
>>>  > Options implied/defaulted for implied for A10 & gen5:
>>>  > - FPGA_SOCFPGA, SYS_MALLOC_F_LEN, SYS_TEXT_BASE
>>>  >
>>>  > Options implied/defaulted for A10:
>>>  > - SPL_SYS_MALLOC_F_LEN
>>>  >
>>>  > Options implied/defaulted for gen5:
>>>  > - SPL_STACK_R, SPL_SYS_MALLOC_SIMPLE, SPL_STACK_R_ADDR
>>>  >
>>>  > Signed-off-by: Simon Goldschmidt >>  >
>>>  > ---
>>>  >
>>>  > Changes in v2:
>>>  > - added patch to imply/default common config options
>>>  >
>>>  >  arch/arm/Kconfig                       |  3 +++
>>>  >  arch/arm/mach-socfpga/Kconfig          | 21
>>> +
>>>  >  configs/socfpga_arria10_defconfig      |  8 
>>>  >  configs/socfpga_arria5_defconfig       | 10 --
>>>  >  configs/socfpga_cyclone5_defconfig     | 10 --
>>>  >  configs/socfpga_dbm_soc1_defconfig     | 10 --
>>>  >  configs/socfpga_de0_nano_soc_defconfig | 10 --
>>>  >  configs/socfpga_de10_nano_defconfig    | 10 --
>>>  >  configs/socfpga_de1_soc_defconfig      | 10 --
>>>  >  configs/socfpga_is1_defconfig          |  8 
>>>  >  configs/socfpga_sockit_defconfig       | 10 --
>>>  >  configs/socfpga_socrates_defconfig     | 10 --
>>>  >  configs/socfpga_sr1500_defconfig       | 10 --
>>>  >  configs/socfpga_stratix10_defconfig    |  4 
>>>  >  configs/socfpga_vining_fpga_defconfig  | 10 --
>>>  >  15 files changed, 24 insertions(+), 120 deletions(-)
>>>  >
>>>  > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>>  > index ded7c11a4c..71bb14acce 100644
>>>  > --- a/arch/arm/Kconfig
>>>  > +++ b/arch/arm/Kconfig
>>>  > @@ -839,12 +839,15 @@ config ARCH_SOCFPGA
>>>  >       imply DM_SPI
>>>  >       imply DM_SPI_FLASH
>>>  >       imply FAT_WRITE
>>>  > +     imply SPL
>>>  > +     imply SPL_DM
>>>  >       imply SPL_LIBDISK_SUPPORT
>>>  >       imply SPL_MMC_SUPPORT
>>>  >       imply SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
>>>  >       imply SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
>>>  >       imply SPL_SPI_FLASH_SUPPORT
>>>  >       imply SPL_SPI_SUPPORT
>>>  > +     imply USE_TINY_PRINTF
>>>  >
>>>  >  config ARCH_SUNXI
>>>  >       bool "Support sunxi (Allwinner) SoCs"
>>>  > diff --git a/arch/arm/mach-socfpga/Kconfig
>>>  b/arch/arm/mach-socfpga/Kconfig
>>>  > index 5e87371f8c..da801eb660 100644
>>>  > --- a/arch/arm/mach-socfpga/Kconfig
>>>  > +++ b/arch/arm/mach-socfpga/Kconfig
>>>  > @@ -1,8 +1,25 @@
>>>  >  if ARCH_SOCFPGA
>>>  >
>>>  > +config NR_DRAM_BANKS
>>>  > +     default 1
>>>  > +
>>>  > +config SPL_STACK_R_ADDR
>>>  > +     default 0x0080 if TARGET_SOCFPGA_GEN5
>>>  > +
>>>  > +config SPL_SYS_MALLOC_F_LEN
>>>  > +     default 0x1 if TARGET_SOCFPGA_ARRIA10
>>>  > +
>>>
>>>  This is already defined in /Kconfig, won't you end up with
>>>  duplicate/redefined symbols this way ?
>>>
>>>
>>> I did not get errors. I copied the handling
>>> from SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE in the same file. Plus it
>>> seems like it's done like this in other Kconfig files, too.
>>
>> I know it is done. I am not convinced it's right.
> 
> Would it be better acceptable if I moved the defaults to the Kconfig
> files where these settings are defined? I always thought it to be
> strange to clutter those with arch-specific settings, but I don't really
> have a strong preference...

I agree with you on this. I'd really like some reply from Yamada-san.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCHv1 1/3] misc: pl310: add a misc driver for the pl310 cache controller

[Marek Vasut]

On 3/5/19 9:07 PM, Dinh Nguyen wrote:
> 
> 
> On 3/5/19 1:19 PM, Marek Vasut wrote:
>> On 3/5/19 8:03 PM, Dinh Nguyen wrote:
>>> The driver will read the cache properties from the device tree file and
>>> set it up.
>>>
> 
>>>  
>>> +config L2X0_CACHE
>>> +   bool "L2x0 Cache support"
>>> +   depends on MISC
>>> +   help
>>> + Select this to enable a PL310 L2 Cache driver. The driver will
>>> + configure the L2 Cache settings found in the device tree.
>>
>> I wonder whether we don't need some drivers/plat or drivers/soc for this ?
> 
> You mean for plat specific implementations?

Rather, since this is ARM-specific driver.

>>>  config ALTERA_SYSID
>>> bool "Altera Sysid support"
>>> depends on MISC
>>> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
>>> index 6bdf5054f4..ea726f4668 100644
>>> --- a/drivers/misc/Makefile
>>> +++ b/drivers/misc/Makefile
>>> @@ -23,6 +23,7 @@ obj-$(CONFIG_SANDBOX) += spltest_sandbox.o
>>>  endif
>>>  endif
>>>  obj-$(CONFIG_ALI152X) += ali512x.o
>>> +obj-$(CONFIG_L2X0_CACHE) += cache-l2x0.o
>>>  obj-$(CONFIG_ALTERA_SYSID) += altera_sysid.o
>>>  obj-$(CONFIG_ATSHA204A) += atsha204a-i2c.o
>>>  obj-$(CONFIG_CBMEM_CONSOLE) += cbmem_console.o
>>> diff --git a/drivers/misc/cache-l2x0.c b/drivers/misc/cache-l2x0.c
>>> new file mode 100644
>>> index 00..b31598b1cd
>>> --- /dev/null
>>> +++ b/drivers/misc/cache-l2x0.c
>>> @@ -0,0 +1,84 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Copyright (C) 2007 ARM Limited
>>
>> 2007 ? :)
> 
> I think I can remove this. I started with the Linux's cache-l2x0, but
> removed almost all of the code. Just a left-over artifact.

2007-2019 then ?

>>> +
>>> +   saved_reg |= L310_LATENCY_CTRL_RD(tag[0] - 1) |
>>> +L310_LATENCY_CTRL_WR(tag[1] - 1) |
>>> +L310_LATENCY_CTRL_SETUP(tag[2] - 1);
>>> +
>>> +   writel(saved_reg, >pl310_tag_latency_ctrl);
>>> +
>>> +   saved_reg = readl(>pl310_data_latency_ctrl);
>>> +   dev_read_u32_array(dev, "arm,data-latency", tag, 3);
>>
>> What happens if the array isn't present ?
>> Should we _not_ configure the latencies in such case ?
> 
> Right, I have a to-do list that need to handle error conditions like this.

Please fix.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/5] arm: socfpga: imply/default common config options

[Simon Goldschmidt]

Am 04.03.2019 um 22:34 schrieb Marek Vasut:

On 3/4/19 10:23 PM, Simon Goldschmidt wrote:



Marek Vasut mailto:ma...@denx.de>> schrieb am Mo., 4.
März 2019, 22:19:

 On 3/4/19 9:53 PM, Simon Goldschmidt wrote:
 > This commit moves common config options used in all socfpga boards
 > to select/imply in Kconfig. This both cleans up the defconfig files
 > as well as makes future changes easier.
 >
 > Options implied/defaulted for all sub-arches:
 > - SPL, SPL_DM, USE_TINY_PRINTF, NR_DRAM_BANKS
 >
 > Options implied/defaulted for implied for A10 & gen5:
 > - FPGA_SOCFPGA, SYS_MALLOC_F_LEN, SYS_TEXT_BASE
 >
 > Options implied/defaulted for A10:
 > - SPL_SYS_MALLOC_F_LEN
 >
 > Options implied/defaulted for gen5:
 > - SPL_STACK_R, SPL_SYS_MALLOC_SIMPLE, SPL_STACK_R_ADDR
 >
 > Signed-off-by: Simon Goldschmidt mailto:simon.k.r.goldschm...@gmail.com>>
 > ---
 >
 > Changes in v2:
 > - added patch to imply/default common config options
 >
 >  arch/arm/Kconfig                       |  3 +++
 >  arch/arm/mach-socfpga/Kconfig          | 21 +
 >  configs/socfpga_arria10_defconfig      |  8 
 >  configs/socfpga_arria5_defconfig       | 10 --
 >  configs/socfpga_cyclone5_defconfig     | 10 --
 >  configs/socfpga_dbm_soc1_defconfig     | 10 --
 >  configs/socfpga_de0_nano_soc_defconfig | 10 --
 >  configs/socfpga_de10_nano_defconfig    | 10 --
 >  configs/socfpga_de1_soc_defconfig      | 10 --
 >  configs/socfpga_is1_defconfig          |  8 
 >  configs/socfpga_sockit_defconfig       | 10 --
 >  configs/socfpga_socrates_defconfig     | 10 --
 >  configs/socfpga_sr1500_defconfig       | 10 --
 >  configs/socfpga_stratix10_defconfig    |  4 
 >  configs/socfpga_vining_fpga_defconfig  | 10 --
 >  15 files changed, 24 insertions(+), 120 deletions(-)
 >
 > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
 > index ded7c11a4c..71bb14acce 100644
 > --- a/arch/arm/Kconfig
 > +++ b/arch/arm/Kconfig
 > @@ -839,12 +839,15 @@ config ARCH_SOCFPGA
 >       imply DM_SPI
 >       imply DM_SPI_FLASH
 >       imply FAT_WRITE
 > +     imply SPL
 > +     imply SPL_DM
 >       imply SPL_LIBDISK_SUPPORT
 >       imply SPL_MMC_SUPPORT
 >       imply SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
 >       imply SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
 >       imply SPL_SPI_FLASH_SUPPORT
 >       imply SPL_SPI_SUPPORT
 > +     imply USE_TINY_PRINTF
 >
 >  config ARCH_SUNXI
 >       bool "Support sunxi (Allwinner) SoCs"
 > diff --git a/arch/arm/mach-socfpga/Kconfig
 b/arch/arm/mach-socfpga/Kconfig
 > index 5e87371f8c..da801eb660 100644
 > --- a/arch/arm/mach-socfpga/Kconfig
 > +++ b/arch/arm/mach-socfpga/Kconfig
 > @@ -1,8 +1,25 @@
 >  if ARCH_SOCFPGA
 >
 > +config NR_DRAM_BANKS
 > +     default 1
 > +
 > +config SPL_STACK_R_ADDR
 > +     default 0x0080 if TARGET_SOCFPGA_GEN5
 > +
 > +config SPL_SYS_MALLOC_F_LEN
 > +     default 0x1 if TARGET_SOCFPGA_ARRIA10
 > +

 This is already defined in /Kconfig, won't you end up with
 duplicate/redefined symbols this way ?


I did not get errors. I copied the handling
from SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE in the same file. Plus it
seems like it's done like this in other Kconfig files, too.


I know it is done. I am not convinced it's right.


Would it be better acceptable if I moved the defaults to the Kconfig 
files where these settings are defined? I always thought it to be 
strange to clutter those with arch-specific settings, but I don't really 
have a strong preference...


Regards,
Simon




 CCing Yamada-san, since he's the Kconfig guru.


Right, getting more insight here would be nice.


Yes please.



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

Re: [U-Boot] [RFC PATCHv1 2/3] defconfig: socfpga_sockit_defconfig: enable L2X0_CACHE driver

[Dinh Nguyen]

On 3/5/19 1:20 PM, Marek Vasut wrote:
> On 3/5/19 8:03 PM, Dinh Nguyen wrote:
>> Enable CONFIG_MISC and CONFIG_L2X0_CACHE config options.
>>
>> Signed-off-by: Dinh Nguyen 
>> ---
>>  configs/socfpga_sockit_defconfig | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/configs/socfpga_sockit_defconfig 
>> b/configs/socfpga_sockit_defconfig
>> index 4c17d1a9e4..0009b0ebc3 100644
>> --- a/configs/socfpga_sockit_defconfig
>> +++ b/configs/socfpga_sockit_defconfig
>> @@ -47,6 +47,8 @@ CONFIG_DM_GPIO=y
>>  CONFIG_DWAPB_GPIO=y
>>  CONFIG_DM_I2C=y
>>  CONFIG_SYS_I2C_DW=y
>> +CONFIG_MISC=y
>> +CONFIG_L2X0_CACHE=y
>>  CONFIG_DM_MMC=y
>>  CONFIG_MMC_DW=y
>>  CONFIG_MTD_DEVICE=y
> 
> I think you can just add it as a default into arch/arm/socfpga/Kconfig
> with 'imply CONFIG_...' instead.
> 

Ah, yes...thanks. This would prevent the need make the same edits for
all the other socfpga_*_defconfigs.

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

Re: [U-Boot] [RFC PATCHv1 3/3] ARM: socfpga: let the pl310 driver configure the cache settings

[Dinh Nguyen]

On 3/5/19 1:20 PM, Marek Vasut wrote:
> On 3/5/19 8:03 PM, Dinh Nguyen wrote:
>> Load the PL310 L2 cache driver and allow it to setup the cache settings
>>
>> Signed-off-by: Dinh Nguyen 
>> ---
>>  arch/arm/mach-socfpga/misc.c | 15 ++-
>>  1 file changed, 2 insertions(+), 13 deletions(-)
>>
>> diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
>> index fcf211d62b..fb0cfd3c1a 100644
>> --- a/arch/arm/mach-socfpga/misc.c
>> +++ b/arch/arm/mach-socfpga/misc.c
>> @@ -59,20 +59,9 @@ void enable_caches(void)
>>  #ifdef CONFIG_SYS_L2_PL310
>>  void v7_outer_cache_enable(void)
>>  {
>> -/* Disable the L2 cache */
>> -clrbits_le32(>pl310_ctrl, L2X0_CTRL_EN);
>> -
>> -writel(0x111, >pl310_tag_latency_ctrl);
>> -writel(0x121, >pl310_data_latency_ctrl);
>> -
>> -/* enable BRESP, instruction and data prefetch, full line of zeroes */
>> -setbits_le32(>pl310_aux_ctrl,
>> - L310_AUX_CTRL_DATA_PREFETCH_MASK |
>> - L310_AUX_CTRL_INST_PREFETCH_MASK |
>> - L310_SHARED_ATT_OVERRIDE_ENABLE);
>> +struct udevice *dev;
>>  
>> -/* Enable the L2 cache */
>> -setbits_le32(>pl310_ctrl, L2X0_CTRL_EN);
>> +uclass_first_device(UCLASS_MISC, );
> 
> Error handling might help here
> 

Agreed..Just trying to solicit comments on whether this is the right
approach? Will add error handling..

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

Re: [U-Boot] [RFC PATCHv1 1/3] misc: pl310: add a misc driver for the pl310 cache controller

[Dinh Nguyen]

On 3/5/19 1:19 PM, Marek Vasut wrote:
> On 3/5/19 8:03 PM, Dinh Nguyen wrote:
>> The driver will read the cache properties from the device tree file and
>> set it up.
>>

>>  
>> +config L2X0_CACHE
>> +bool "L2x0 Cache support"
>> +depends on MISC
>> +help
>> +  Select this to enable a PL310 L2 Cache driver. The driver will
>> +  configure the L2 Cache settings found in the device tree.
> 
> I wonder whether we don't need some drivers/plat or drivers/soc for this ?

You mean for plat specific implementations?

> 
>>  config ALTERA_SYSID
>>  bool "Altera Sysid support"
>>  depends on MISC
>> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
>> index 6bdf5054f4..ea726f4668 100644
>> --- a/drivers/misc/Makefile
>> +++ b/drivers/misc/Makefile
>> @@ -23,6 +23,7 @@ obj-$(CONFIG_SANDBOX) += spltest_sandbox.o
>>  endif
>>  endif
>>  obj-$(CONFIG_ALI152X) += ali512x.o
>> +obj-$(CONFIG_L2X0_CACHE) += cache-l2x0.o
>>  obj-$(CONFIG_ALTERA_SYSID) += altera_sysid.o
>>  obj-$(CONFIG_ATSHA204A) += atsha204a-i2c.o
>>  obj-$(CONFIG_CBMEM_CONSOLE) += cbmem_console.o
>> diff --git a/drivers/misc/cache-l2x0.c b/drivers/misc/cache-l2x0.c
>> new file mode 100644
>> index 00..b31598b1cd
>> --- /dev/null
>> +++ b/drivers/misc/cache-l2x0.c
>> @@ -0,0 +1,84 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (C) 2007 ARM Limited
> 
> 2007 ? :)

I think I can remove this. I started with the Linux's cache-l2x0, but
removed almost all of the code. Just a left-over artifact.


>> +
>> +saved_reg |= L310_LATENCY_CTRL_RD(tag[0] - 1) |
>> + L310_LATENCY_CTRL_WR(tag[1] - 1) |
>> + L310_LATENCY_CTRL_SETUP(tag[2] - 1);
>> +
>> +writel(saved_reg, >pl310_tag_latency_ctrl);
>> +
>> +saved_reg = readl(>pl310_data_latency_ctrl);
>> +dev_read_u32_array(dev, "arm,data-latency", tag, 3);
> 
> What happens if the array isn't present ?
> Should we _not_ configure the latencies in such case ?

Right, I have a to-do list that need to handle error conditions like this.

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

Re: [U-Boot] [PATCH v11 9/9] ARM: socfpga: Increase Malloc pool size to support FAT filesystem in SPL

[Simon Goldschmidt]

Am 05.03.2019 um 17:23 schrieb tien.fong.c...@intel.com:

From: Tien Fong Chee 

After some series of patches to maximise reusable of memory pool, here come
to result of reasonable size required for whole SDMMC boot working on A10
SoCDK. Size required come from default max cluster(0x1) +
others(0x2000) + additional memory for headroom(0x3000).

Signed-off-by: Tien Fong Chee 

---

changes for v7
- Added 0x3000 for memory headroom.
---
  include/configs/socfpga_common.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index 4551cb29bc..548b458e78 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -1,6 +1,6 @@
  /* SPDX-License-Identifier: GPL-2.0+ */
  /*
- * Copyright (C) 2012 Altera Corporation 
+ * Copyright (C) 2012-2019 Altera Corporation 
   */
  #ifndef __CONFIG_SOCFPGA_COMMON_H__
  #define __CONFIG_SOCFPGA_COMMON_H__
@@ -258,7 +258,7 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
  #if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
  /* SPL memory allocation configuration, this is for FAT implementation */
  #ifndef CONFIG_SYS_SPL_MALLOC_START
-#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0001
+#define CONFIG_SYS_SPL_MALLOC_SIZE 0x00015000


This will clash with my series here:
https://patchwork.ozlabs.org/patch/1051451/

Any chance you could test that on A10? I only have a cyclone 5.

Regards,
Simon



  #define CONFIG_SYS_SPL_MALLOC_START   (CONFIG_SYS_INIT_RAM_SIZE - \
 CONFIG_SYS_SPL_MALLOC_SIZE + \
 CONFIG_SYS_INIT_RAM_ADDR)



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

Re: [U-Boot] [RFC 2/8] efi_loader: boottime: export efi_[un]load_image()

[Heinrich Schuchardt]

On 3/5/19 6:53 AM, AKASHI Takahiro wrote:
> Those two functions will be used later to re-implement do_bootefi_exec().
> 
> Signed-off-by: AKASHI Takahiro 
Reviewed-by: Heinrich Schuchardt 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 9/9] arm: dts: exynos: Add ramp delay property to LDO regulators to Odroid XU3 family

[Krzysztof Kozlowski]

Add startup time to LDO regulators of S2MPS11 PMIC on Odroid XU3/XU4/HC1
family of boards to be sure the voltage is proper before relying on the
regulator.

The datasheet for all the S2MPS1x family is inconsistent here and does
not specify unambiguously the value of ramp delay for LDO.  It mentions
30 mV/us in one timing diagram but then omits it completely in LDO
regulator characteristics table (it is specified for bucks).

However the vendor kernels for Galaxy S5 and Odroid XU3 use values of 12
mV/us or 24 mV/us.

Without the ramp delay value the consumers do not wait for voltage
settle after changing it.  Although the proper value of ramp delay for
LDOs is unknown, it seems safer to use at least some value from
reference kernel than to leave it unset.

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Lukasz Majewski 
Tested-by: Anand Moon 
---
 arch/arm/dts/exynos5422-odroidxu3.dts | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/dts/exynos5422-odroidxu3.dts 
b/arch/arm/dts/exynos5422-odroidxu3.dts
index 9dfae90667cf..04ecc404f907 100644
--- a/arch/arm/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/dts/exynos5422-odroidxu3.dts
@@ -45,6 +45,7 @@
regulator-name = "vdd_ldo1";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
+   regulator-ramp-delay = <12000>;
regulator-always-on;
};
 
@@ -52,18 +53,21 @@
regulator-name = "vddq_mmc0";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+   regulator-ramp-delay = <12000>;
};
 
ldo4_reg: LDO4 {
regulator-name = "vdd_adc";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+   regulator-ramp-delay = <12000>;
};
 
ldo5_reg: LDO5 {
regulator-name = "vdd_ldo5";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+   regulator-ramp-delay = <12000>;
regulator-always-on;
};
 
@@ -71,6 +75,7 @@
regulator-name = "vdd_ldo6";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
+   regulator-ramp-delay = <12000>;
regulator-always-on;
};
 
@@ -78,6 +83,7 @@
regulator-name = "vdd_ldo7";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+   regulator-ramp-delay = <12000>;
regulator-always-on;
};
 
@@ -85,6 +91,7 @@
regulator-name = "vdd_ldo8";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+   regulator-ramp-delay = <12000>;
regulator-always-on;
};
 
@@ -92,6 +99,7 @@
regulator-name = "vdd_ldo9";
regulator-min-microvolt = <300>;
regulator-max-microvolt = <300>;
+   regulator-ramp-delay = <12000>;
regulator-always-on;
};
 
@@ -99,6 +107,7 @@
regulator-name = "vdd_ldo10";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+   regulator-ramp-delay = <12000>;
regulator-always-on;
};
 
@@ -106,6 +115,7 @@
regulator-name = "vdd_ldo11";
regulator-min-microvolt = <100>;
   

[U-Boot] [PATCH v4 7/9] power: regulator: s2mps11: Add enable delay

[Krzysztof Kozlowski]

According to datasheet, the output on LDO regulators will start
appearing after 10-15 us.

Signed-off-by: Krzysztof Kozlowski 
Tested-by: Anand Moon 
---
 drivers/power/regulator/s2mps11_regulator.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/power/regulator/s2mps11_regulator.c 
b/drivers/power/regulator/s2mps11_regulator.c
index 723d27f67c9a..67d1f9689de3 100644
--- a/drivers/power/regulator/s2mps11_regulator.c
+++ b/drivers/power/regulator/s2mps11_regulator.c
@@ -551,7 +551,16 @@ static int ldo_get_enable(struct udevice *dev)
 
 static int ldo_set_enable(struct udevice *dev, bool enable)
 {
-   return s2mps11_ldo_enable(dev, PMIC_OP_SET, );
+   int ret;
+
+   ret = s2mps11_ldo_enable(dev, PMIC_OP_SET, );
+   if (ret)
+   return ret;
+
+   /* Wait the "enable delay" for voltage to start to rise */
+   udelay(15);
+
+   return 0;
 }
 
 static int ldo_get_mode(struct udevice *dev)
-- 
2.17.1

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

[U-Boot] [PATCH v4 6/9] regulator: Add support for ramp delay

[Krzysztof Kozlowski]

Changing voltage and enabling regulator might require delays so the
regulator stabilizes at expected level.

Add support for "regulator-ramp-delay" binding which can introduce
required time to both enabling the regulator and to changing the
voltage.

Signed-off-by: Krzysztof Kozlowski 
Tested-by: Anand Moon 
---
 .../regulator/regulator.txt   |  2 +
 drivers/power/regulator/regulator-uclass.c| 47 ++-
 include/power/regulator.h |  2 +
 3 files changed, 49 insertions(+), 2 deletions(-)

diff --git a/doc/device-tree-bindings/regulator/regulator.txt 
b/doc/device-tree-bindings/regulator/regulator.txt
index 65b69c427899..4ba642b7c77f 100644
--- a/doc/device-tree-bindings/regulator/regulator.txt
+++ b/doc/device-tree-bindings/regulator/regulator.txt
@@ -35,6 +35,7 @@ Optional properties:
 - regulator-max-microamp: a maximum allowed Current value
 - regulator-always-on: regulator should never be disabled
 - regulator-boot-on: enabled by bootloader/firmware
+- regulator-ramp-delay: ramp delay for regulator (in uV/us)
 
 Note
 The "regulator-name" constraint is used for setting the device's uclass
@@ -60,4 +61,5 @@ ldo0 {
regulator-max-microamp = <10>;
regulator-always-on;
regulator-boot-on;
+   regulator-ramp-delay = <12000>;
 };
diff --git a/drivers/power/regulator/regulator-uclass.c 
b/drivers/power/regulator/regulator-uclass.c
index 6f355b969a6d..9118b8eb39e3 100644
--- a/drivers/power/regulator/regulator-uclass.c
+++ b/drivers/power/regulator/regulator-uclass.c
@@ -35,10 +35,22 @@ int regulator_get_value(struct udevice *dev)
return ops->get_value(dev);
 }
 
+static void regulator_set_value_ramp_delay(struct udevice *dev, int old_uV,
+  int new_uV, unsigned int ramp_delay)
+{
+   int delay = DIV_ROUND_UP(abs(new_uV - old_uV), ramp_delay);
+
+   debug("regulator %s: delay %u us (%d uV -> %d uV)\n", dev->name, delay,
+ old_uV, new_uV);
+
+   udelay(delay);
+}
+
 int regulator_set_value(struct udevice *dev, int uV)
 {
const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
struct dm_regulator_uclass_platdata *uc_pdata;
+   int ret, old_uV = uV, is_enabled = 0;
 
uc_pdata = dev_get_uclass_platdata(dev);
if (uc_pdata->min_uV != -ENODATA && uV < uc_pdata->min_uV)
@@ -49,7 +61,20 @@ int regulator_set_value(struct udevice *dev, int uV)
if (!ops || !ops->set_value)
return -ENOSYS;
 
-   return ops->set_value(dev, uV);
+   if (uc_pdata->ramp_delay) {
+   is_enabled = regulator_get_enable(dev);
+   old_uV = regulator_get_value(dev);
+   }
+
+   ret = ops->set_value(dev, uV);
+
+   if (!ret) {
+   if (uc_pdata->ramp_delay && old_uV > 0 && is_enabled)
+   regulator_set_value_ramp_delay(dev, old_uV, uV,
+  uc_pdata->ramp_delay);
+   }
+
+   return ret;
 }
 
 /*
@@ -107,6 +132,7 @@ int regulator_set_enable(struct udevice *dev, bool enable)
 {
const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
struct dm_regulator_uclass_platdata *uc_pdata;
+   int ret, old_enable = 0;
 
if (!ops || !ops->set_enable)
return -ENOSYS;
@@ -115,7 +141,22 @@ int regulator_set_enable(struct udevice *dev, bool enable)
if (!enable && uc_pdata->always_on)
return -EACCES;
 
-   return ops->set_enable(dev, enable);
+   if (uc_pdata->ramp_delay)
+   old_enable = regulator_get_enable(dev);
+
+   ret = ops->set_enable(dev, enable);
+   if (!ret) {
+   if (uc_pdata->ramp_delay && !old_enable && enable) {
+   int uV = regulator_get_value(dev);
+
+   if (uV > 0) {
+   regulator_set_value_ramp_delay(dev, 0, uV,
+  
uc_pdata->ramp_delay);
+   }
+   }
+   }
+
+   return ret;
 }
 
 int regulator_set_enable_if_allowed(struct udevice *dev, bool enable)
@@ -335,6 +376,8 @@ static int regulator_pre_probe(struct udevice *dev)
-ENODATA);
uc_pdata->always_on = dev_read_bool(dev, "regulator-always-on");
uc_pdata->boot_on = dev_read_bool(dev, "regulator-boot-on");
+   uc_pdata->ramp_delay = dev_read_u32_default(dev, "regulator-ramp-delay",
+   0);
 
/* Those values are optional (-ENODATA if unset) */
if ((uc_pdata->min_uV != -ENODATA) &&
diff --git a/include/power/regulator.h b/include/power/regulator.h
index 314160a894b7..6c6e2cd4f996 100644
--- a/include/power/regulator.h
+++ b/include/power/regulator.h
@@ -150,6 +150,7 @@ enum regulator_flag {
  * @always_on* - bool type, true or false
  * @boot_on*   - 

[U-Boot] [PATCH v4 5/9] arm: exynos: Wait till ADC stabilizes before checking Odroid HC1 revision

[Krzysztof Kozlowski]

Fix detection of Odroid HC1 (Exynos5422) after reboot if kernel disabled
the LDO4/VDD_ADC regulator.

The LDO4 supplies both ADC block and the ADC input AIN9.  Voltage on
AIN9 will rise slowly, so use delay of 5 milliseconds instead of
timers-based loop to wait for voltage stabilization.

First reads on Odroid HC1 return 305, 1207, 1297 and finally 1308
(reference value is 1309).

Signed-off-by: Krzysztof Kozlowski 
Tested-by: Anand Moon 
---
 board/samsung/common/exynos5-dt-types.c | 38 -
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/board/samsung/common/exynos5-dt-types.c 
b/board/samsung/common/exynos5-dt-types.c
index 7c1271d6547a..516c32923e44 100644
--- a/board/samsung/common/exynos5-dt-types.c
+++ b/board/samsung/common/exynos5-dt-types.c
@@ -57,12 +57,48 @@ static unsigned int odroid_get_rev(void)
return 0;
 }
 
+/*
+ * Read ADC at least twice and check the resuls.  If regulator providing 
voltage
+ * on to measured point was just turned on, first reads might require time
+ * to stabilize.
+ */
+static int odroid_get_adc_val(unsigned int *adcval)
+{
+   unsigned int adcval_prev = 0;
+   int ret, retries = 20;
+
+   ret = adc_channel_single_shot("adc", CONFIG_ODROID_REV_AIN,
+ _prev);
+   if (ret)
+   return ret;
+
+   while (retries--) {
+   mdelay(5);
+
+   ret = adc_channel_single_shot("adc", CONFIG_ODROID_REV_AIN,
+ adcval);
+   if (ret)
+   return ret;
+
+   /*
+* If difference between ADC reads is less than 3%,
+* accept the result
+*/
+   if ((100 * abs(*adcval - adcval_prev) / adcval_prev) < 3)
+   return ret;
+
+   adcval_prev = *adcval;
+   }
+
+   return ret;
+}
+
 static int odroid_get_board_type(void)
 {
unsigned int adcval;
int ret, i;
 
-   ret = adc_channel_single_shot("adc", CONFIG_ODROID_REV_AIN, );
+   ret = odroid_get_adc_val();
if (ret)
goto rev_default;
 
-- 
2.17.1

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

[U-Boot] [PATCH v4 8/9] arm: dts: exynos: Add supply for ADC block to Odroid XU3 family

[Krzysztof Kozlowski]

The ADC block requires VDD supply to be on so provide one.

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Lukasz Majewski 
Tested-by: Anand Moon 
---
 arch/arm/dts/exynos5422-odroidxu3.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/exynos5422-odroidxu3.dts 
b/arch/arm/dts/exynos5422-odroidxu3.dts
index e859dd1b981a..9dfae90667cf 100644
--- a/arch/arm/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/dts/exynos5422-odroidxu3.dts
@@ -32,6 +32,7 @@
 
adc@12D1 {
u-boot,dm-pre-reloc;
+   vdd-supply = <_reg>;
status = "okay";
};
 
-- 
2.17.1

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

[U-Boot] [PATCH v4 3/9] arm: exynos: Detect revision later, when all resources are ready

[Krzysztof Kozlowski]

Detection of board revision is done early - before power setup.  In case of
Odroid XU3/XU4/HC1 family, the detection is done using ADC which
is supplied by LDO4/VDD_ADC regulator.  This regulator could be turned
off (e.g. by kernel before reboot).  If ADC is used early, the
regulators are not yet available and the detection won't work.

Split the revision detection out of set_board_type() into separate
function called later - either when displaying board info (in late mode)
or during misc_init_r.  The idea is that set_board_type() will be called
early so its method of detection are limited to flattened device tree
(exynos5-dt-types.c for Exynos5) or GPIO (odroid.c for Exynos4412).  The
newly added set_board_revision() can be called only later, when
resources like regulator are available.

This is necessary to fix the detection of Odroid HC1 after reboot, if
kernel turned off the LDO4 regulator.

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Lukasz Majewski 
Tested-by: Anand Moon 
---
 board/samsung/common/board.c| 22 +-
 board/samsung/common/exynos5-dt-types.c | 16 +---
 board/samsung/odroid/odroid.c   |  8 
 include/samsung/misc.h  |  1 +
 4 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 96228a86a117..ef2204742e1d 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -253,7 +253,18 @@ int board_eth_init(bd_t *bis)
 int checkboard(void)
 {
if (IS_ENABLED(CONFIG_BOARD_TYPES)) {
-   const char *board_info = get_board_type();
+   const char *board_info;
+
+   if (IS_ENABLED(CONFIG_DISPLAY_BOARDINFO_LATE)) {
+   /*
+* Printing type requires having revision, although
+* this will succeed only if done late.
+* Otherwise revision will be set in misc_init_r().
+*/
+   set_board_revision();
+   }
+
+   board_info = get_board_type();
 
if (board_info)
printf("Type:  %s\n", board_info);
@@ -287,6 +298,15 @@ int board_late_init(void)
 #ifdef CONFIG_MISC_INIT_R
 int misc_init_r(void)
 {
+   if (!IS_ENABLED(CONFIG_DISPLAY_BOARDINFO_LATE)) {
+   /*
+* If revision was not set by late display boardinfo,
+* set it here. At this point regulators should be already
+* available.
+*/
+   set_board_revision();
+   }
+
 #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
set_board_info();
 #endif
diff --git a/board/samsung/common/exynos5-dt-types.c 
b/board/samsung/common/exynos5-dt-types.c
index 7a86e9187768..7c1271d6547a 100644
--- a/board/samsung/common/exynos5-dt-types.c
+++ b/board/samsung/common/exynos5-dt-types.c
@@ -192,8 +192,11 @@ const char *get_board_type(void)
 
 /**
  * set_board_type() - set board type in gd->board_type.
- * As default type set EXYNOS5_BOARD_GENERIC, if detect Odroid,
- * then set its proper type.
+ * As default type set EXYNOS5_BOARD_GENERIC. If Odroid is detected,
+ * set its proper type based on device tree.
+ *
+ * This might be called early when some more specific ways to detect revision
+ * are not yet available.
  */
 void set_board_type(void)
 {
@@ -211,8 +214,15 @@ void set_board_type(void)
gd->board_type = of_match->data;
break;
}
+}
 
-   /* If Odroid, then check its revision */
+/**
+ * set_board_revision() - set detailed board type in gd->board_type.
+ * Should be called when resources (e.g. regulators) are available
+ * so ADC can be used to detect the specific revision of a board.
+ */
+void set_board_revision(void)
+{
if (board_is_odroidxu3())
gd->board_type = odroid_get_board_type();
 }
diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
index 552333fe869d..4be8cc9826c3 100644
--- a/board/samsung/odroid/odroid.c
+++ b/board/samsung/odroid/odroid.c
@@ -54,6 +54,14 @@ void set_board_type(void)
gd->board_type = ODROID_TYPE_U3;
 }
 
+void set_board_revision(void)
+{
+   /*
+* Revision already set by set_board_type() because it can be
+* executed early.
+*/
+}
+
 const char *get_board_type(void)
 {
const char *board_type[] = {"u3", "x2"};
diff --git a/include/samsung/misc.h b/include/samsung/misc.h
index 017560c25662..4ff28a1df0e8 100644
--- a/include/samsung/misc.h
+++ b/include/samsung/misc.h
@@ -33,6 +33,7 @@ char *get_dfu_alt_system(char *interface, char *devstr);
 char *get_dfu_alt_boot(char *interface, char *devstr);
 #endif
 void set_board_type(void);
+void set_board_revision(void);
 const char *get_board_type(void);
 
 #endif /* __SAMSUNG_MISC_COMMON_H__ */
-- 
2.17.1

___

[U-Boot] [PATCH v4 4/9] arm: exynos: odroid-xu3: Display info late to have proper type

[Krzysztof Kozlowski]

Printing the "Type" of board requires proper detection of revision which
can happen only late because regulators are needed.

Signed-off-by: Krzysztof Kozlowski 
Tested-by: Anand Moon 
---
 board/samsung/common/board.c | 2 +-
 configs/odroid-xu3_defconfig | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index ef2204742e1d..4ffbd7254205 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -249,7 +249,7 @@ int board_eth_init(bd_t *bis)
return 0;
 }
 
-#ifdef CONFIG_DISPLAY_BOARDINFO
+#if defined(CONFIG_DISPLAY_BOARDINFO) || defined(CONFIG_DISPLAY_BOARDINFO_LATE)
 int checkboard(void)
 {
if (IS_ENABLED(CONFIG_BOARD_TYPES)) {
diff --git a/configs/odroid-xu3_defconfig b/configs/odroid-xu3_defconfig
index e35f8d6dde78..682460a1934e 100644
--- a/configs/odroid-xu3_defconfig
+++ b/configs/odroid-xu3_defconfig
@@ -10,6 +10,8 @@ CONFIG_FIT=y
 CONFIG_FIT_BEST_MATCH=y
 CONFIG_SILENT_CONSOLE=y
 CONFIG_CONSOLE_MUX=y
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_MISC_INIT_R=y
 CONFIG_BOARD_TYPES=y
 CONFIG_SYS_PROMPT="ODROID-XU3 # "
-- 
2.17.1

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

[U-Boot] [PATCH v4 2/9] power: regulator: s2mps11: Fix step for LDO27 and LDO35

[Krzysztof Kozlowski]

LDO27 and LDO35 have 25 mV step, not 50 mV.

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Lukasz Majewski 
Tested-by: Anand Moon 
---
 drivers/power/regulator/s2mps11_regulator.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/power/regulator/s2mps11_regulator.c 
b/drivers/power/regulator/s2mps11_regulator.c
index ced504eb1476..723d27f67c9a 100644
--- a/drivers/power/regulator/s2mps11_regulator.c
+++ b/drivers/power/regulator/s2mps11_regulator.c
@@ -346,6 +346,8 @@ static int s2mps11_ldo_hex2volt(int ldo, int hex)
case 11:
case 22:
case 23:
+   case 27:
+   case 35:
uV = hex * S2MPS11_LDO_STEP + S2MPS11_LDO_UV_MIN;
break;
default:
@@ -366,6 +368,8 @@ static int s2mps11_ldo_volt2hex(int ldo, int uV)
case 11:
case 22:
case 23:
+   case 27:
+   case 35:
hex = (uV - S2MPS11_LDO_UV_MIN) / S2MPS11_LDO_STEP;
break;
default:
-- 
2.17.1

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

[U-Boot] [PATCH v4 1/9] adc: exynos-adc: Fix wrong bit operation used to stop the ADC

[Krzysztof Kozlowski]

When stopping the ADC_V2_CON1_STC_EN should be cleared.

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Lukasz Majewski 
Tested-by: Anand Moon 
---
 drivers/adc/exynos-adc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/adc/exynos-adc.c b/drivers/adc/exynos-adc.c
index d33e3d632afc..12c49fc8cefb 100644
--- a/drivers/adc/exynos-adc.c
+++ b/drivers/adc/exynos-adc.c
@@ -62,7 +62,7 @@ int exynos_adc_stop(struct udevice *dev)
 
/* Stop conversion */
cfg = readl(>con1);
-   cfg |= ~ADC_V2_CON1_STC_EN;
+   cfg &= ~ADC_V2_CON1_STC_EN;
 
writel(cfg, >con1);
 
-- 
2.17.1

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

[U-Boot] [PATCH v4 0/9] arm: exynos: Fix reboot on Odroid HC1

[Krzysztof Kozlowski]

Hi,

Changes since v3

1. Add accumulated review and test tags.
2. Patch 6: Add "ramp" keyword to new function (as discussed with
   Torsten Duwe).
3. Rebased on v2019.04-rc3.


Changes since v2

1. Add Lukasz review tags.
2. Patch 7: Return on error, as suggested by Simon.
2. Patch 3: Use IS_ENABLED() to run revision detection only
   once - either during late display board or misc_init_r.

Changes since v1

1. Move fixes to beginning of patchset.
2. Patch 3: Rework the idea - split revision detection to be executed later.
3. Patch 4: New patch.
4. Patch 6: Apply Simon's comments.
5. Patch 6: Do not delay when changing voltage if regulator is disabled.
6. Patch 6: Do not delay when disabling the regulator.


Description
===
Odroid HC1 does not reboot properly (at least from SD card but
I do not expect difference on eMMC), if LDO4/VDD_ADC was turned
off by Linux kernel.  This condition happens so far always, because
Linux kernel did not enable ADC on Odroid HC1, therefore the
VDD_ADC regulator was turned off as unused.

The issue is in detection of revision which later is used to load
proper DTB.

The revision is obtained by ADC read of a voltage depending on VDD_ADC.
Therefore:
1. VDD_ADC has to be turned on (but board detection happens before
   power is initialized),
2. Turning VDD_ADC should wait with ramp delay,
3. Reading the value from ADC should wait for it to stabilize.

Tested on Odroid XU3-Lite and Odroid HC1.

Comments and testing are welcomed.

Best regards,
Krzysztof

Krzysztof Kozlowski (9):
  adc: exynos-adc: Fix wrong bit operation used to stop the ADC
  power: regulator: s2mps11: Fix step for LDO27 and LDO35
  arm: exynos: Detect revision later, when all resources are ready
  arm: exynos: odroid-xu3: Display info late to have proper type
  arm: exynos: Wait till ADC stabilizes before checking Odroid HC1
revision
  regulator: Add support for ramp delay
  power: regulator: s2mps11: Add enable delay
  arm: dts: exynos: Add supply for ADC block to Odroid XU3 family
  arm: dts: exynos: Add ramp delay property to LDO regulators to Odroid
XU3 family

 arch/arm/dts/exynos5422-odroidxu3.dts | 20 +++
 board/samsung/common/board.c  | 24 -
 board/samsung/common/exynos5-dt-types.c   | 54 +--
 board/samsung/odroid/odroid.c |  8 +++
 configs/odroid-xu3_defconfig  |  2 +
 .../regulator/regulator.txt   |  2 +
 drivers/adc/exynos-adc.c  |  2 +-
 drivers/power/regulator/regulator-uclass.c| 47 +++-
 drivers/power/regulator/s2mps11_regulator.c   | 15 +-
 include/power/regulator.h |  2 +
 include/samsung/misc.h|  1 +
 11 files changed, 167 insertions(+), 10 deletions(-)

-- 
2.17.1

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

[U-Boot] [PATCH 1/1] efi_loader: release file buffer after loading image

[Heinrich Schuchardt]

efi_load_pe() copies and rebases the UEFI image.
We do not need the buffer with the file contents afterwards.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_boottime.c | 50 +--
 1 file changed, 18 insertions(+), 32 deletions(-)

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index bd8b8a17ae..391681260c 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1693,6 +1693,7 @@ static efi_status_t EFIAPI efi_load_image(bool 
boot_policy,
struct efi_loaded_image_obj **image_obj =
(struct efi_loaded_image_obj **)image_handle;
efi_status_t ret;
+   void *dest_buffer;
 
EFI_ENTRY("%d, %p, %pD, %p, %zd, %p", boot_policy, parent_image,
  file_path, source_buffer, source_size, image_handle);
@@ -1708,7 +1709,7 @@ static efi_status_t EFIAPI efi_load_image(bool 
boot_policy,
}
 
if (!source_buffer) {
-   ret = efi_load_image_from_path(file_path, _buffer,
+   ret = efi_load_image_from_path(file_path, _buffer,
   _size);
if (ret != EFI_SUCCESS)
goto error;
@@ -1721,41 +1722,26 @@ static efi_status_t EFIAPI efi_load_image(bool 
boot_policy,
/* In this case, file_path is the "device" path, i.e.
 * something like a HARDWARE_DEVICE:MEMORY_MAPPED
 */
-   u64 addr;
-   void *dest_buffer;
-
-   ret = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES,
-EFI_RUNTIME_SERVICES_CODE,
-efi_size_in_pages(source_size), );
-   if (ret != EFI_SUCCESS)
-   goto error;
-   dest_buffer = (void *)(uintptr_t)addr;
-   memcpy(dest_buffer, source_buffer, source_size);
-   source_buffer = dest_buffer;
-
+   dest_buffer = source_buffer;
dp = file_path;
fp = NULL;
}
ret = efi_setup_loaded_image(dp, fp, image_obj, );
-   if (ret != EFI_SUCCESS)
-   goto error_invalid_image;
-   ret = efi_load_pe(*image_obj, source_buffer, info);
-   if (ret != EFI_SUCCESS)
-   goto error_invalid_image;
-   /* Update the type of the allocated memory */
-   efi_add_memory_map((uintptr_t)source_buffer,
-  efi_size_in_pages(source_size),
-  info->image_code_type, false);
-   info->system_table = 
-   info->parent_handle = parent_image;
-   return EFI_EXIT(EFI_SUCCESS);
-error_invalid_image:
-   /* The image is invalid. Release all associated resources. */
-   efi_free_pages((uintptr_t)source_buffer,
-  efi_size_in_pages(source_size));
-   efi_delete_handle(*image_handle);
-   *image_handle = NULL;
-   free(info);
+   if (ret == EFI_SUCCESS)
+   ret = efi_load_pe(*image_obj, dest_buffer, info);
+   if (!source_buffer)
+   /* Release buffer to which file was loaded */
+   efi_free_pages((uintptr_t)dest_buffer,
+  efi_size_in_pages(source_size));
+   if (ret == EFI_SUCCESS) {
+   info->system_table = 
+   info->parent_handle = parent_image;
+   } else {
+   /* The image is invalid. Release all associated resources. */
+   efi_delete_handle(*image_handle);
+   *image_handle = NULL;
+   free(info);
+   }
 error:
return EFI_EXIT(ret);
 }
-- 
2.20.1

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

Re: [U-Boot] [PATCH v3 0/9] arm: exynos: Fix reboot on Odroid HC1

[Krzysztof Kozlowski]

On Tue, 5 Mar 2019 at 11:16, Minkyu Kang  wrote:
>
> Dear Krzysztof Kozlowski,
>
> On 24/02/2019 21:55, Anand Moon wrote:
> > Hi Krzysztof,
> >
> > Please add my. on Odroid HC1
> >
> > Tested-by: Anand Moon 
> >
> > Best Regards
> > -Anand
> >
> > On Sat, 16 Feb 2019 at 15:16, Krzysztof Kozlowski  wrote:
> >>
> >> Hi,
> >>
> >> Changes since v2
> >> 
> >> 1. Add Lukasz review tags.
> >> 2. Patch 7: Return on error, as suggested by Simon.
> >> 2. Patch 3: Use IS_ENABLED() to run revision detection only
> >>once - either during late display board or misc_init_r.
> >>
> >> Changes since v1
> >> 
> >> 1. Move fixes to beginning of patchset.
> >> 2. Patch 3: Rework the idea - split revision detection to be executed 
> >> later.
> >> 3. Patch 4: New patch.
> >> 4. Patch 6: Apply Simon's comments.
> >> 5. Patch 6: Do not delay when changing voltage if regulator is disabled.
> >> 6. Patch 6: Do not delay when disabling the regulator.
> >>
> >>
> >> Description
> >> ===
> >> Odroid HC1 does not reboot properly (at least from SD card but
> >> I do not expect difference on eMMC), if LDO4/VDD_ADC was turned
> >> off by Linux kernel.  This condition happens so far always, because
> >> Linux kernel did not enable ADC on Odroid HC1, therefore the
> >> VDD_ADC regulator was turned off as unused.
> >>
> >> The issue is in detection of revision which later is used to load
> >> proper DTB.
> >>
> >> The revision is obtained by ADC read of a voltage depending on VDD_ADC.
> >> Therefore:
> >> 1. VDD_ADC has to be turned on (but board detection happens before
> >>power is initialized),
> >> 2. Turning VDD_ADC should wait with ramp delay,
> >> 3. Reading the value from ADC should wait for it to stabilize.
> >>
> >> Tested on Odroid XU3-Lite and Odroid HC1.
> >>
> >> Commends and testing are welcomed.
> >>
> >> Best regards,
> >> Krzysztof
> >>
> >> Krzysztof Kozlowski (9):
> >>   adc: exynos-adc: Fix wrong bit operation used to stop the ADC
> >>   power: regulator: s2mps11: Fix step for LDO27 and LDO35
> >>   arm: exynos: Detect revision later, when all resources are ready
> >>   arm: exynos: odroid-xu3: Display info late to have proper type
> >>   arm: exynos: Wait till ADC stabilizes before checking Odroid HC1
> >> revision
> >>   regulator: Add support for ramp delay
> >>   power: regulator: s2mps11: Add enable delay
> >>   arm: dts: exynos: Add supply for ADC block to Odroid XU3 family
> >>   arm: dts: exynos: Add ramp delay property to LDO regulators to Odroid
> >> XU3 family
> >>
> >>  arch/arm/dts/exynos5422-odroidxu3.dts | 20 +++
> >>  board/samsung/common/board.c  | 24 -
> >>  board/samsung/common/exynos5-dt-types.c   | 54 +--
> >>  board/samsung/odroid/odroid.c |  8 +++
> >>  configs/odroid-xu3_defconfig  |  2 +
> >>  .../regulator/regulator.txt   |  2 +
> >>  drivers/adc/exynos-adc.c  |  2 +-
> >>  drivers/power/regulator/regulator-uclass.c| 47 +++-
> >>  drivers/power/regulator/s2mps11_regulator.c   | 15 +-
> >>  include/power/regulator.h |  2 +
> >>  include/samsung/misc.h|  1 +
> >>  11 files changed, 167 insertions(+), 10 deletions(-)
> >>
> >> --
> >> 2.17.1
> >>
> >> ___
> >> U-Boot mailing list
> >> U-Boot@lists.denx.de
> >> https://lists.denx.de/listinfo/u-boot
> >
> >
>
> Patch looks good but could you please rebase on latest u-boot-samsung tree?
>
> Applying: adc: exynos-adc: Fix wrong bit operation used to stop the ADC
> Applying: power: regulator: s2mps11: Fix step for LDO27 and LDO35
> Applying: arm: exynos: Detect revision later, when all resources are ready
> Applying: arm: exynos: odroid-xu3: Display info late to have proper type
> error: patch failed: configs/odroid-xu3_defconfig:11
> error: configs/odroid-xu3_defconfig: patch does not apply
> Patch failed at 0004 arm: exynos: odroid-xu3: Display info late to have 
> proper type

Sure, let me rebase.

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

Re: [U-Boot] [RFC 1/8] efi_loader: boottime: don't add device path protocol to image handle

[Heinrich Schuchardt]

On 3/5/19 6:53 AM, AKASHI Takahiro wrote:
> It is just wrong to add devcie path protocol to image handle.
> 
> Signed-off-by: AKASHI Takahiro 
> ---
>  lib/efi_loader/efi_boottime.c | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)
> 
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index bd8b8a17ae71..7bd9c0a952d4 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -1540,17 +1540,8 @@ efi_status_t efi_setup_loaded_image(struct 
> efi_device_path *device_path,
>   info->file_path = file_path;
>   info->system_table = 
>  
> - if (device_path) {
> + if (device_path)
>   info->device_handle = efi_dp_find_obj(device_path, NULL);
> - /*
> -  * When asking for the device path interface, return
> -  * bootefi_device_path
> -  */
> - ret = efi_add_protocol(>header,
> -_guid_device_path, device_path);

Installing the device path is not the problem. It is the GUID that is
wrong. Use EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL_GUID here.

UEFI Spec 2.7:

"The Loaded Image Device Path Protocol must be installed onto the image
handle of a PE/COFF image loaded through the EFI Boot Service LoadImage()."

Best regards

Heinrich

> - if (ret != EFI_SUCCESS)
> - goto failure;
> - }
>  
>   /*
>* When asking for the loaded_image interface, just
> 

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

Re: [U-Boot] [PATCH v2 1/1] efi_loader: bootmgr: support BootNext and BootCurrent variable behavior

[Heinrich Schuchardt]

On 3/5/19 2:58 AM, AKASHI Takahiro wrote:
> See UEFI v2.7, section 3.1.2 for details of the specification.
> 
> With efidebug command, you can run any EFI boot option as follows:
>   => efi boot add 1 SHELL ...
>   => efi boot add 2 HELLO ...
>   => efi boot order 1 2
>   => efi bootmgr
>  (starting SHELL ...)
> 
>   => efi boot next 2
>   => efi bootmgr
>  (starting HELLO ...)
>   => env print -e
>   
>   BootCurrent: {boot,run}(blob)
>   :  02 00..
>   BootOrder: {boot,run}(blob)
>   :  01 00 02 00  
> 
> Signed-off-by: AKASHI Takahiro 

Please, use scripts/get_maintainer.pl to determine the correct
recipients. You missed Alex's new email address.

> ---
>  lib/efi_loader/efi_bootmgr.c | 40 
>  1 file changed, 36 insertions(+), 4 deletions(-)
> 
> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> index 417016102b48..1575c5c09e46 100644
> --- a/lib/efi_loader/efi_bootmgr.c
> +++ b/lib/efi_loader/efi_bootmgr.c
> @@ -141,6 +141,7 @@ static void *try_load_entry(uint16_t n, struct 
> efi_device_path **device_path,
>   efi_deserialize_load_option(, load_option);
>  
>   if (lo.attributes & LOAD_OPTION_ACTIVE) {
> + u32 attributes;
>   efi_status_t ret;
>  
>   debug("%s: trying to load \"%ls\" from %pD\n",
> @@ -151,6 +152,16 @@ static void *try_load_entry(uint16_t n, struct 
> efi_device_path **device_path,
>   if (ret != EFI_SUCCESS)
>   goto error;
>  
> + attributes = EFI_VARIABLE_BOOTSERVICE_ACCESS |
> +  EFI_VARIABLE_RUNTIME_ACCESS;
> + size = sizeof(n);
> + ret = EFI_CALL(efi_set_variable(
> + L"BootCurrent",
> + (efi_guid_t *)_global_variable_guid,
> + attributes, size, ));
> + if (ret != EFI_SUCCESS)
> + goto error;
> +
>   printf("Booting: %ls\n", lo.label);
>   efi_dp_split_file_path(lo.file_path, device_path, file_path);
>   }
> @@ -162,21 +173,42 @@ error:
>  }
>  
>  /*
> - * Attempt to load, in the order specified by BootOrder EFI variable, the
> - * available load-options, finding and returning the first one that can
> - * be loaded successfully.
> + * Attempt to load from BootNext or in the order specified by BootOrder
> + * EFI variable, the available load-options, finding and returning
> + * the first one that can be loaded successfully.
>   */
>  void *efi_bootmgr_load(struct efi_device_path **device_path,
>  struct efi_device_path **file_path)
>  {
> - uint16_t *bootorder;
> + u16 bootnext, *bootorder;

bootnext has enough space for the terminating \n. That is way too small.

You want to call efi_get_variable() twice. Get the buffer size needed in
the first round. malloc() a buffer. Then actually read the variable.
Finally free() the buffer.

>   efi_uintn_t size;
>   void *image = NULL;
>   int i, num;
> + efi_status_t ret;
>  
>   bs = systab.boottime;
>   rs = systab.runtime;
>  
> + /* BootNext */
> + size = sizeof(bootnext);
> + ret = EFI_CALL(efi_get_variable(L"BootNext",
> + (efi_guid_t *)_global_variable_guid,
> + NULL, , ));
> + if (ret == EFI_SUCCESS) {

The expected value of ret for an existing variable of size > 0 is
EFI_BUFFER_TOO_SMALL.

> + /* delete BootNext */
> + ret = EFI_CALL(efi_set_variable(
> + L"BootNext",
> + (efi_guid_t *)_global_variable_guid,
> + 0, 0, ));
> + if (ret == EFI_SUCCESS) {

Why would loading the boot entry depend on the return value here?

> + image = try_load_entry(bootnext,

Best regards

Heinrich

> +device_path, file_path);
> + if (image)
> + goto error;
> + }
> + }
> +
> + /* BootOrder */
>   bootorder = get_var(L"BootOrder", _global_variable_guid, );
>   if (!bootorder) {
>   printf("BootOrder not defined\n");
> 

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

Re: [U-Boot] [PATCH v2 6/6] i2c: rcar_i2c: Move FSDA check to rcar_i2c_recover

[Marek Vasut]

On 3/5/19 12:23 PM, Ismael Luceno Cortes wrote:
> Cosmetic change.  Any call to the recover function would need to do the
> same check afterwards, so it's sensible to make it part of the function.
> 
> Signed-off-by: Ismael Luceno 
> ---
> 
> Notes:
> Changes since v1:
> - Rebased on top of patch 1050650 ("i2c: rcar_i2c: Add Gen3 SoC support")
> - Explained the change
> - Replaced C99-style variable declaration
> 
>  drivers/i2c/rcar_i2c.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/i2c/rcar_i2c.c b/drivers/i2c/rcar_i2c.c
> index 4556b115bd..21bcf09101 100644
> --- a/drivers/i2c/rcar_i2c.c
> +++ b/drivers/i2c/rcar_i2c.c
> @@ -77,12 +77,13 @@ static int rcar_i2c_finish(struct udevice *dev)
>   return ret;
>  }
>  
> -static void rcar_i2c_recover(struct udevice *dev)
> +static int rcar_i2c_recover(struct udevice *dev)
>  {
>   struct rcar_i2c_priv *priv = dev_get_priv(dev);
>   u32 mcr = RCAR_I2C_ICMCR_MDBS | RCAR_I2C_ICMCR_OBPC;
>   u32 mcra = mcr | RCAR_I2C_ICMCR_FSDA;
>   int i;
> + u32 ret;

Can you change this to "reg" or something like that ? $ret is usually a
signed int return value, so this could be confusing.

>  
>   /* Send 9 SCL pulses */
>   for (i = 0; i < 9; i++) {
> @@ -102,6 +103,9 @@ static void rcar_i2c_recover(struct udevice *dev)
>   udelay(5);
>   writel(mcra | RCAR_I2C_ICMCR_FSCL, priv->base + RCAR_I2C_ICMCR);
>   udelay(5);
> +
> + ret = readl(priv->base + RCAR_I2C_ICMSR);
> + return ret & RCAR_I2C_ICMCR_FSDA;

What about doing this instead

reg = readl...
if (reg & ...FSDA)
return -EBUSY;

return 0;

That way, the code will use standard errno.h return values.

>  }
>  
>  static int rcar_i2c_set_addr(struct udevice *dev, u8 chip, u8 read)
> @@ -121,9 +125,7 @@ static int rcar_i2c_set_addr(struct udevice *dev, u8 
> chip, u8 read)
>   ret = wait_for_bit_le32(priv->base + RCAR_I2C_ICMCR,
>   RCAR_I2C_ICMCR_FSDA, false, 2, true);
>   if (ret) {
> - rcar_i2c_recover(dev);
> - val = readl(priv->base + RCAR_I2C_ICMSR);
> - if (val & RCAR_I2C_ICMCR_FSDA) {
> + if (rcar_i2c_recover(dev)) {
>   dev_err(dev, "Bus busy, aborting\n");
>   return ret;
>   }
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/6] i2c: rcar_i2c: Don't mask errors with EREMOTEIO at rcar_i2c_xfer

[Marek Vasut]

On 3/5/19 12:16 PM, Ismael Luceno Cortes wrote:

Commit message is missing :-(

> Signed-off-by: Ismael Luceno 
> ---
> 
> Notes:
> Changes since v1:
> - Rebased on top of patch 1050650 ("i2c: rcar_i2c: Add Gen3 SoC support")
> 
>  drivers/i2c/rcar_i2c.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/rcar_i2c.c b/drivers/i2c/rcar_i2c.c
> index 7131f0c994..d6b0418290 100644
> --- a/drivers/i2c/rcar_i2c.c
> +++ b/drivers/i2c/rcar_i2c.c
> @@ -217,7 +217,7 @@ static int rcar_i2c_xfer(struct udevice *dev, struct 
> i2c_msg *msg, int nmsgs)
>   ret = rcar_i2c_write_common(dev, msg);
>  
>   if (ret)
> - return -EREMOTEIO;
> + return ret;
>   }
>  
>   return ret;
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCHv1 2/3] defconfig: socfpga_sockit_defconfig: enable L2X0_CACHE driver

[Marek Vasut]

On 3/5/19 8:03 PM, Dinh Nguyen wrote:
> Enable CONFIG_MISC and CONFIG_L2X0_CACHE config options.
> 
> Signed-off-by: Dinh Nguyen 
> ---
>  configs/socfpga_sockit_defconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/configs/socfpga_sockit_defconfig 
> b/configs/socfpga_sockit_defconfig
> index 4c17d1a9e4..0009b0ebc3 100644
> --- a/configs/socfpga_sockit_defconfig
> +++ b/configs/socfpga_sockit_defconfig
> @@ -47,6 +47,8 @@ CONFIG_DM_GPIO=y
>  CONFIG_DWAPB_GPIO=y
>  CONFIG_DM_I2C=y
>  CONFIG_SYS_I2C_DW=y
> +CONFIG_MISC=y
> +CONFIG_L2X0_CACHE=y
>  CONFIG_DM_MMC=y
>  CONFIG_MMC_DW=y
>  CONFIG_MTD_DEVICE=y

I think you can just add it as a default into arch/arm/socfpga/Kconfig
with 'imply CONFIG_...' instead.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCHv1 1/3] misc: pl310: add a misc driver for the pl310 cache controller

[Marek Vasut]

On 3/5/19 8:03 PM, Dinh Nguyen wrote:
> The driver will read the cache properties from the device tree file and
> set it up.
> 
> Signed-off-by: Dinh Nguyen 
> ---
>  arch/arm/include/asm/pl310.h |  3 ++
>  drivers/misc/Kconfig |  7 +++
>  drivers/misc/Makefile|  1 +
>  drivers/misc/cache-l2x0.c| 84 
>  4 files changed, 95 insertions(+)
>  create mode 100644 drivers/misc/cache-l2x0.c
> 
> diff --git a/arch/arm/include/asm/pl310.h b/arch/arm/include/asm/pl310.h
> index b83978b1cc..f69e9e45f8 100644
> --- a/arch/arm/include/asm/pl310.h
> +++ b/arch/arm/include/asm/pl310.h
> @@ -18,6 +18,9 @@
>  #define L310_SHARED_ATT_OVERRIDE_ENABLE  (1 << 22)
>  #define L310_AUX_CTRL_DATA_PREFETCH_MASK (1 << 28)
>  #define L310_AUX_CTRL_INST_PREFETCH_MASK (1 << 29)
> +#define L310_LATENCY_CTRL_SETUP(n)   ((n) << 0)
> +#define L310_LATENCY_CTRL_RD(n)  ((n) << 4)
> +#define L310_LATENCY_CTRL_WR(n)  ((n) << 8)
>  
>  #define L2X0_CACHE_ID_PART_MASK (0xf << 6)
>  #define L2X0_CACHE_ID_PART_L310 (3 << 6)
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index d6e677fba8..c5c34b4dbb 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -13,6 +13,13 @@ config MISC
> set of generic read, write and ioctl methods may be used to
> access the device.
>  
> +config L2X0_CACHE
> + bool "L2x0 Cache support"
> + depends on MISC
> + help
> +   Select this to enable a PL310 L2 Cache driver. The driver will
> +   configure the L2 Cache settings found in the device tree.

I wonder whether we don't need some drivers/plat or drivers/soc for this ?

>  config ALTERA_SYSID
>   bool "Altera Sysid support"
>   depends on MISC
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 6bdf5054f4..ea726f4668 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_SANDBOX) += spltest_sandbox.o
>  endif
>  endif
>  obj-$(CONFIG_ALI152X) += ali512x.o
> +obj-$(CONFIG_L2X0_CACHE) += cache-l2x0.o
>  obj-$(CONFIG_ALTERA_SYSID) += altera_sysid.o
>  obj-$(CONFIG_ATSHA204A) += atsha204a-i2c.o
>  obj-$(CONFIG_CBMEM_CONSOLE) += cbmem_console.o
> diff --git a/drivers/misc/cache-l2x0.c b/drivers/misc/cache-l2x0.c
> new file mode 100644
> index 00..b31598b1cd
> --- /dev/null
> +++ b/drivers/misc/cache-l2x0.c
> @@ -0,0 +1,84 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2007 ARM Limited

2007 ? :)

> + * copied from Linux(arch/arm/mm/cache-l2x0.c
> + */
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +static void l2c310_of_parse(struct udevice *dev)
> +{
> + u32 tag[3] = { 0, 0, 0 };
> + u32 saved_reg, prefetch_i, prefetch_d;
> + bool shared_override;
> + struct pl310_regs *regs = (struct pl310_regs *)devfdt_get_addr(dev);
> +
> + /*Disable the L2 Cache */

/*D

> + clrbits_le32(>pl310_ctrl, L2X0_CTRL_EN);
> +
> + dev_read_u32(dev, "prefetch-data", _d);
> + dev_read_u32(dev, "prefetch-instr", _i);
> + shared_override = dev_read_bool(dev, "arm,shared-override");
> +
> + saved_reg = readl(>pl310_aux_ctrl);
> + if (prefetch_d)
> + saved_reg |= L310_AUX_CTRL_DATA_PREFETCH_MASK;
> + if (prefetch_i)
> + saved_reg |= L310_AUX_CTRL_INST_PREFETCH_MASK;
> + if (shared_override)
> + saved_reg |= L310_SHARED_ATT_OVERRIDE_ENABLE;
> +
> + writel(saved_reg, >pl310_aux_ctrl);
> +
> + saved_reg = readl(>pl310_tag_latency_ctrl);
> + dev_read_u32_array(dev, "arm,tag-latency", tag, 3);
> +
> + saved_reg |= L310_LATENCY_CTRL_RD(tag[0] - 1) |
> +  L310_LATENCY_CTRL_WR(tag[1] - 1) |
> +  L310_LATENCY_CTRL_SETUP(tag[2] - 1);
> +
> + writel(saved_reg, >pl310_tag_latency_ctrl);
> +
> + saved_reg = readl(>pl310_data_latency_ctrl);
> + dev_read_u32_array(dev, "arm,data-latency", tag, 3);

What happens if the array isn't present ?
Should we _not_ configure the latencies in such case ?

> + saved_reg |= L310_LATENCY_CTRL_RD(tag[0] - 1) |
> +  L310_LATENCY_CTRL_WR(tag[1] - 1) |
> +  L310_LATENCY_CTRL_SETUP(tag[2] - 1);
> +
> + writel(saved_reg, >pl310_data_latency_ctrl);
> +
> + /* Enable the L2 cache */
> + setbits_le32(>pl310_ctrl, L2X0_CTRL_EN);
> +}
> +
> +static int l2x0_ofdata_to_platdata(struct udevice *dev)
> +{
> + return 0;
> +}
> +
> +static int l2x0_probe(struct udevice *dev)
> +{
> + l2c310_of_parse(dev);
> + return 0;
> +}
> +
> +

Two newlines here ^ drop one

> +static const struct udevice_id l2x0_ids[] = {
> + { .compatible = "arm,pl310-cache" },
> + {}
> +};
> +
> +U_BOOT_DRIVER(pl310_cache) = {
> + .name   = "pl310_cache",
> + .id = UCLASS_MISC,
> + .of_match = l2x0_ids,
> + .probe  = l2x0_probe,
> + .ofdata_to_platdata = 

Re: [U-Boot] [RFC PATCHv1 3/3] ARM: socfpga: let the pl310 driver configure the cache settings

[Marek Vasut]

On 3/5/19 8:03 PM, Dinh Nguyen wrote:
> Load the PL310 L2 cache driver and allow it to setup the cache settings
> 
> Signed-off-by: Dinh Nguyen 
> ---
>  arch/arm/mach-socfpga/misc.c | 15 ++-
>  1 file changed, 2 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
> index fcf211d62b..fb0cfd3c1a 100644
> --- a/arch/arm/mach-socfpga/misc.c
> +++ b/arch/arm/mach-socfpga/misc.c
> @@ -59,20 +59,9 @@ void enable_caches(void)
>  #ifdef CONFIG_SYS_L2_PL310
>  void v7_outer_cache_enable(void)
>  {
> - /* Disable the L2 cache */
> - clrbits_le32(>pl310_ctrl, L2X0_CTRL_EN);
> -
> - writel(0x111, >pl310_tag_latency_ctrl);
> - writel(0x121, >pl310_data_latency_ctrl);
> -
> - /* enable BRESP, instruction and data prefetch, full line of zeroes */
> - setbits_le32(>pl310_aux_ctrl,
> -  L310_AUX_CTRL_DATA_PREFETCH_MASK |
> -  L310_AUX_CTRL_INST_PREFETCH_MASK |
> -  L310_SHARED_ATT_OVERRIDE_ENABLE);
> + struct udevice *dev;
>  
> - /* Enable the L2 cache */
> - setbits_le32(>pl310_ctrl, L2X0_CTRL_EN);
> + uclass_first_device(UCLASS_MISC, );

Error handling might help here

>  }
>  
>  void v7_outer_cache_disable(void)
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 5/6] i2c: rcar_i2c: Set the slave address from rcar_i2c_xfer

[Marek Vasut]

On 3/5/19 12:16 PM, Ismael Luceno Cortes wrote:

Commit message is missing :-(

The patch itself is fine though. Can you fill the commit message and do
a V3 of the series ?

> Signed-off-by: Ismael Luceno 
> ---
> 
> Notes:
> Changes since v1:
> - Rebased on top of patch 1050650 ("i2c: rcar_i2c: Add Gen3 SoC support")
> - Fixed masking of return value from rcar_i2c_set_addr
> 
>  drivers/i2c/rcar_i2c.c | 14 +-
>  1 file changed, 5 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/i2c/rcar_i2c.c b/drivers/i2c/rcar_i2c.c
> index d6b0418290..4556b115bd 100644
> --- a/drivers/i2c/rcar_i2c.c
> +++ b/drivers/i2c/rcar_i2c.c
> @@ -154,10 +154,6 @@ static int rcar_i2c_read_common(struct udevice *dev, 
> struct i2c_msg *msg)
>   u32 icmcr = RCAR_I2C_ICMCR_MDBS | RCAR_I2C_ICMCR_MIE;
>   int i, ret = -EREMOTEIO;
>  
> - ret = rcar_i2c_set_addr(dev, msg->addr, 1);
> - if (ret)
> - return ret;
> -
>   for (i = 0; i < msg->len; i++) {
>   if (msg->len - 1 == i)
>   icmcr |= RCAR_I2C_ICMCR_FSB;
> @@ -184,10 +180,6 @@ static int rcar_i2c_write_common(struct udevice *dev, 
> struct i2c_msg *msg)
>   u32 icmcr = RCAR_I2C_ICMCR_MDBS | RCAR_I2C_ICMCR_MIE;
>   int i, ret = -EREMOTEIO;
>  
> - ret = rcar_i2c_set_addr(dev, msg->addr, 0);
> - if (ret)
> - return ret;
> -
>   for (i = 0; i < msg->len; i++) {
>   writel(msg->buf[i], priv->base + RCAR_I2C_ICRXD_ICTXD);
>   writel(icmcr, priv->base + RCAR_I2C_ICMCR);
> @@ -211,6 +203,10 @@ static int rcar_i2c_xfer(struct udevice *dev, struct 
> i2c_msg *msg, int nmsgs)
>   int ret;
>  
>   for (; nmsgs > 0; nmsgs--, msg++) {
> + ret = rcar_i2c_set_addr(dev, msg->addr, 1);
> + if (ret)
> + return ret;
> +
>   if (msg->flags & I2C_M_RD)
>   ret = rcar_i2c_read_common(dev, msg);
>   else
> @@ -220,7 +216,7 @@ static int rcar_i2c_xfer(struct udevice *dev, struct 
> i2c_msg *msg, int nmsgs)
>   return ret;
>   }
>  
> - return ret;
> + return 0;
>  }
>  
>  static int rcar_i2c_probe_chip(struct udevice *dev, uint addr, uint flags)
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/6] i2c: rcar_i2c: Fix sending of slave addresses

[Marek Vasut]

On 3/5/19 12:16 PM, Ismael Luceno Cortes wrote:
> Do the reset before clearing the MSR, otherwise it may result in a read
> or write operation instead if the start condition is repeated.
> 
> Signed-off-by: Ismael Luceno 

Reviewed-by: Marek Vasut 

> ---
> 
> Notes:
> Changes since v1:
> - Rebased on top of patch 1050650 ("i2c: rcar_i2c: Add Gen3 SoC support")
> 
>  drivers/i2c/rcar_i2c.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/rcar_i2c.c b/drivers/i2c/rcar_i2c.c
> index c1a233b6e9..7131f0c994 100644
> --- a/drivers/i2c/rcar_i2c.c
> +++ b/drivers/i2c/rcar_i2c.c
> @@ -130,9 +130,11 @@ static int rcar_i2c_set_addr(struct udevice *dev, u8 
> chip, u8 read)
>   }
>  
>   writel((chip << 1) | read, priv->base + RCAR_I2C_ICMAR);
> - writel(0, priv->base + RCAR_I2C_ICMSR);
> + /* Reset */
>   writel(RCAR_I2C_ICMCR_MDBS | RCAR_I2C_ICMCR_MIE | RCAR_I2C_ICMCR_ESG,
>  priv->base + RCAR_I2C_ICMCR);
> + /* Clear Status */
> + writel(0, priv->base + RCAR_I2C_ICMSR);
>  
>   ret = wait_for_bit_le32(priv->base + RCAR_I2C_ICMSR, mask,
>   true, 100, true);
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/6] i2c: rcar_i2c: Setup SCL/SDA delay at rcar_i2c_set_speed

[Marek Vasut]

On 3/5/19 12:16 PM, Ismael Luceno Cortes wrote:
> It only needs to be done once.

As much as I hate to do it, I need to ask you to reword the commit
message again.

When I look at just the commit message and I read "It only needs to be
done once.", I literally have no clue what the change does. I need to
look into the patch.

> Signed-off-by: Ismael Luceno 
> ---
>  drivers/i2c/rcar_i2c.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/i2c/rcar_i2c.c b/drivers/i2c/rcar_i2c.c
> index 10b0f8bad4..74643b085e 100644
> --- a/drivers/i2c/rcar_i2c.c
> +++ b/drivers/i2c/rcar_i2c.c
> @@ -116,9 +116,7 @@ static int rcar_i2c_set_addr(struct udevice *dev, u8 
> chip, u8 read)
>   writel(0, priv->base + RCAR_I2C_ICMSR);
>   writel(priv->icccr, priv->base + RCAR_I2C_ICCCR);
>  
> - if (priv->type == RCAR_I2C_TYPE_GEN3)
> - writel(RCAR_I2C_ICFBSCR_TCYC17, priv->base + RCAR_I2C_ICFBSCR);
> -
> + /* Wait for the bus */
>   ret = wait_for_bit_le32(priv->base + RCAR_I2C_ICMCR,
>   RCAR_I2C_ICMCR_FSDA, false, 2, true);
>   if (ret) {
> @@ -304,6 +302,10 @@ scgd_find:
>   priv->icccr = (scgd << RCAR_I2C_ICCCR_SCGD_OFF) | cdf;
>   writel(priv->icccr, priv->base + RCAR_I2C_ICCCR);
>  
> + if (priv->type == RCAR_I2C_TYPE_GEN3)
> + /* Set SCL/SDA delay */
> + writel(RCAR_I2C_ICFBSCR_TCYC17, priv->base + RCAR_I2C_ICFBSCR);

Please add brackets around the multi-line code, so it's obvious what is
in the if conditional and what is not.

>   return 0;
>  }
>  
> 
> base-commit: f08023c07d826fbc8e62fdd3367961b2f0b06844
> prerequisite-patch-id: 9e5b0458bc15640eb483ccad91dbe85150f9f7be
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/6] i2c: rcar_i2c: Add comments about registers & values

[Marek Vasut]

On 3/5/19 12:16 PM, Ismael Luceno Cortes wrote:

Commit message is missing :(

> Signed-off-by: Ismael Luceno 
> ---
> 
> Notes:
> Changes since v1:
> - Rebased on top of patch 1050650 ("i2c: rcar_i2c: Add Gen3 SoC support")

Thanks!

>  drivers/i2c/rcar_i2c.c | 45 +-
>  1 file changed, 23 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/i2c/rcar_i2c.c b/drivers/i2c/rcar_i2c.c
> index 74643b085e..c1a233b6e9 100644
> --- a/drivers/i2c/rcar_i2c.c
> +++ b/drivers/i2c/rcar_i2c.c
> @@ -18,35 +18,36 @@
>  #include 
>  #include 
>  
> -#define RCAR_I2C_ICSCR   0x00
> -#define RCAR_I2C_ICMCR   0x04
> -#define RCAR_I2C_ICMCR_MDBS  BIT(7)
> -#define RCAR_I2C_ICMCR_FSCL  BIT(6)
> -#define RCAR_I2C_ICMCR_FSDA  BIT(5)
> -#define RCAR_I2C_ICMCR_OBPC  BIT(4)
> -#define RCAR_I2C_ICMCR_MIE   BIT(3)
> +#define RCAR_I2C_ICSCR   0x00   /* slave ctrl */
> +#define RCAR_I2C_ICMCR   0x04   /* master ctrl */
> +#define RCAR_I2C_ICMCR_MDBS  BIT(7) /* non-fifo mode switch */
> +#define RCAR_I2C_ICMCR_FSCL  BIT(6) /* override SCL pin */
> +#define RCAR_I2C_ICMCR_FSDA  BIT(5) /* override SDA pin */
> +#define RCAR_I2C_ICMCR_OBPC  BIT(4) /* override pins */
> +#define RCAR_I2C_ICMCR_MIE   BIT(3) /* master if enable */
>  #define RCAR_I2C_ICMCR_TSBE  BIT(2)
> -#define RCAR_I2C_ICMCR_FSB   BIT(1)
> -#define RCAR_I2C_ICMCR_ESG   BIT(0)
> -#define RCAR_I2C_ICSSR   0x08
> -#define RCAR_I2C_ICMSR   0x0c
> +#define RCAR_I2C_ICMCR_FSB   BIT(1) /* force stop bit */
> +#define RCAR_I2C_ICMCR_ESG   BIT(0) /* enable start bit gen */
> +#define RCAR_I2C_ICSSR   0x08   /* slave status */
> +#define RCAR_I2C_ICMSR   0x0c   /* master status */
>  #define RCAR_I2C_ICMSR_MASK  0x7f
> -#define RCAR_I2C_ICMSR_MNR   BIT(6)
> -#define RCAR_I2C_ICMSR_MAL   BIT(5)
> -#define RCAR_I2C_ICMSR_MST   BIT(4)
> +#define RCAR_I2C_ICMSR_MNR   BIT(6) /* Nack */
> +#define RCAR_I2C_ICMSR_MAL   BIT(5) /* Arbitration lost */
> +#define RCAR_I2C_ICMSR_MST   BIT(4) /* Stop */
>  #define RCAR_I2C_ICMSR_MDE   BIT(3)
>  #define RCAR_I2C_ICMSR_MDT   BIT(2)
>  #define RCAR_I2C_ICMSR_MDR   BIT(1)
>  #define RCAR_I2C_ICMSR_MAT   BIT(0)
> -#define RCAR_I2C_ICSIER  0x10
> -#define RCAR_I2C_ICMIER  0x14
> -#define RCAR_I2C_ICCCR   0x18
> +#define RCAR_I2C_ICSIER  0x10   /* slave irq enable */
> +#define RCAR_I2C_ICMIER  0x14   /* master irq enable */
> +#define RCAR_I2C_ICCCR   0x18   /* clock dividers */
>  #define RCAR_I2C_ICCCR_SCGD_OFF  3
> -#define RCAR_I2C_ICSAR   0x1c
> -#define RCAR_I2C_ICMAR   0x20
> -#define RCAR_I2C_ICRXD_ICTXD 0x24
> -#define RCAR_I2C_ICFBSCR 0x38
> -#define RCAR_I2C_ICFBSCR_TCYC17  0x0f
> +#define RCAR_I2C_ICSAR   0x1c   /* slave address */
> +#define RCAR_I2C_ICMAR   0x20   /* master address */
> +#define RCAR_I2C_ICRXD_ICTXD 0x24   /* data port */
> +#define RCAR_I2C_ICFBSCR 0x38   /* First Bit Setup Cycle (Gen3) 
> */
> +#define RCAR_I2C_ICFBSCR_TCYC17  0x0f   /* 17*Tcyc delay 1st bit
> +   between SDA and SCL */
>  
>  enum rcar_i2c_type {
>   RCAR_I2C_TYPE_GEN2,

Checkpatch is complaining:

WARNING: line over 80 characters
#137: FILE: drivers/i2c/rcar_i2c.c:47:
+#define RCAR_I2C_ICFBSCR   0x38   /* First Bit Setup Cycle
(Gen3) */

WARNING: Block comments use * on subsequent lines
#139: FILE: drivers/i2c/rcar_i2c.c:49:
+#define RCAR_I2C_ICFBSCR_TCYC170x0f   /* 17*Tcyc delay
1st bit
+ between SDA and SCL */

WARNING: Block comments use a trailing */ on a separate line
#139: FILE: drivers/i2c/rcar_i2c.c:49:
+ between SDA and SCL */

total: 1 errors, 3 warnings, 0 checks, 60 lines checked

Please fix and run scripts/checkpatch.pl on the patches before posting them.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v11 1/9] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10

[Dinh Nguyen]

Curious, you sent out 3 versions(2x v10, and v11) within ~2 hours. What
versions should we be reviewing?

On 3/5/19 10:23 AM, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 
> 
> This patch adds description on properties about file name used for both
> peripheral bitstream and core bitstream.
> 
> Signed-off-by: Tien Fong Chee 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [RFC PATCHv1 3/3] ARM: socfpga: let the pl310 driver configure the cache settings

[Dinh Nguyen]

Load the PL310 L2 cache driver and allow it to setup the cache settings

Signed-off-by: Dinh Nguyen 
---
 arch/arm/mach-socfpga/misc.c | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
index fcf211d62b..fb0cfd3c1a 100644
--- a/arch/arm/mach-socfpga/misc.c
+++ b/arch/arm/mach-socfpga/misc.c
@@ -59,20 +59,9 @@ void enable_caches(void)
 #ifdef CONFIG_SYS_L2_PL310
 void v7_outer_cache_enable(void)
 {
-   /* Disable the L2 cache */
-   clrbits_le32(>pl310_ctrl, L2X0_CTRL_EN);
-
-   writel(0x111, >pl310_tag_latency_ctrl);
-   writel(0x121, >pl310_data_latency_ctrl);
-
-   /* enable BRESP, instruction and data prefetch, full line of zeroes */
-   setbits_le32(>pl310_aux_ctrl,
-L310_AUX_CTRL_DATA_PREFETCH_MASK |
-L310_AUX_CTRL_INST_PREFETCH_MASK |
-L310_SHARED_ATT_OVERRIDE_ENABLE);
+   struct udevice *dev;
 
-   /* Enable the L2 cache */
-   setbits_le32(>pl310_ctrl, L2X0_CTRL_EN);
+   uclass_first_device(UCLASS_MISC, );
 }
 
 void v7_outer_cache_disable(void)
-- 
2.20.0

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

[U-Boot] [RFC PATCHv1 2/3] defconfig: socfpga_sockit_defconfig: enable L2X0_CACHE driver

[Dinh Nguyen]

Enable CONFIG_MISC and CONFIG_L2X0_CACHE config options.

Signed-off-by: Dinh Nguyen 
---
 configs/socfpga_sockit_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/socfpga_sockit_defconfig b/configs/socfpga_sockit_defconfig
index 4c17d1a9e4..0009b0ebc3 100644
--- a/configs/socfpga_sockit_defconfig
+++ b/configs/socfpga_sockit_defconfig
@@ -47,6 +47,8 @@ CONFIG_DM_GPIO=y
 CONFIG_DWAPB_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_DW=y
+CONFIG_MISC=y
+CONFIG_L2X0_CACHE=y
 CONFIG_DM_MMC=y
 CONFIG_MMC_DW=y
 CONFIG_MTD_DEVICE=y
-- 
2.20.0

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

[U-Boot] [RFC PATCHv1 1/3] misc: pl310: add a misc driver for the pl310 cache controller

[Dinh Nguyen]

The driver will read the cache properties from the device tree file and
set it up.

Signed-off-by: Dinh Nguyen 
---
 arch/arm/include/asm/pl310.h |  3 ++
 drivers/misc/Kconfig |  7 +++
 drivers/misc/Makefile|  1 +
 drivers/misc/cache-l2x0.c| 84 
 4 files changed, 95 insertions(+)
 create mode 100644 drivers/misc/cache-l2x0.c

diff --git a/arch/arm/include/asm/pl310.h b/arch/arm/include/asm/pl310.h
index b83978b1cc..f69e9e45f8 100644
--- a/arch/arm/include/asm/pl310.h
+++ b/arch/arm/include/asm/pl310.h
@@ -18,6 +18,9 @@
 #define L310_SHARED_ATT_OVERRIDE_ENABLE(1 << 22)
 #define L310_AUX_CTRL_DATA_PREFETCH_MASK   (1 << 28)
 #define L310_AUX_CTRL_INST_PREFETCH_MASK   (1 << 29)
+#define L310_LATENCY_CTRL_SETUP(n) ((n) << 0)
+#define L310_LATENCY_CTRL_RD(n)((n) << 4)
+#define L310_LATENCY_CTRL_WR(n)((n) << 8)
 
 #define L2X0_CACHE_ID_PART_MASK (0xf << 6)
 #define L2X0_CACHE_ID_PART_L310 (3 << 6)
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index d6e677fba8..c5c34b4dbb 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -13,6 +13,13 @@ config MISC
  set of generic read, write and ioctl methods may be used to
  access the device.
 
+config L2X0_CACHE
+   bool "L2x0 Cache support"
+   depends on MISC
+   help
+ Select this to enable a PL310 L2 Cache driver. The driver will
+ configure the L2 Cache settings found in the device tree.
+
 config ALTERA_SYSID
bool "Altera Sysid support"
depends on MISC
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 6bdf5054f4..ea726f4668 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_SANDBOX) += spltest_sandbox.o
 endif
 endif
 obj-$(CONFIG_ALI152X) += ali512x.o
+obj-$(CONFIG_L2X0_CACHE) += cache-l2x0.o
 obj-$(CONFIG_ALTERA_SYSID) += altera_sysid.o
 obj-$(CONFIG_ATSHA204A) += atsha204a-i2c.o
 obj-$(CONFIG_CBMEM_CONSOLE) += cbmem_console.o
diff --git a/drivers/misc/cache-l2x0.c b/drivers/misc/cache-l2x0.c
new file mode 100644
index 00..b31598b1cd
--- /dev/null
+++ b/drivers/misc/cache-l2x0.c
@@ -0,0 +1,84 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2007 ARM Limited
+ *
+ * copied from Linux(arch/arm/mm/cache-l2x0.c
+ */
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static void l2c310_of_parse(struct udevice *dev)
+{
+   u32 tag[3] = { 0, 0, 0 };
+   u32 saved_reg, prefetch_i, prefetch_d;
+   bool shared_override;
+   struct pl310_regs *regs = (struct pl310_regs *)devfdt_get_addr(dev);
+
+   /*Disable the L2 Cache */
+   clrbits_le32(>pl310_ctrl, L2X0_CTRL_EN);
+
+   dev_read_u32(dev, "prefetch-data", _d);
+   dev_read_u32(dev, "prefetch-instr", _i);
+   shared_override = dev_read_bool(dev, "arm,shared-override");
+
+   saved_reg = readl(>pl310_aux_ctrl);
+   if (prefetch_d)
+   saved_reg |= L310_AUX_CTRL_DATA_PREFETCH_MASK;
+   if (prefetch_i)
+   saved_reg |= L310_AUX_CTRL_INST_PREFETCH_MASK;
+   if (shared_override)
+   saved_reg |= L310_SHARED_ATT_OVERRIDE_ENABLE;
+
+   writel(saved_reg, >pl310_aux_ctrl);
+
+   saved_reg = readl(>pl310_tag_latency_ctrl);
+   dev_read_u32_array(dev, "arm,tag-latency", tag, 3);
+
+   saved_reg |= L310_LATENCY_CTRL_RD(tag[0] - 1) |
+L310_LATENCY_CTRL_WR(tag[1] - 1) |
+L310_LATENCY_CTRL_SETUP(tag[2] - 1);
+
+   writel(saved_reg, >pl310_tag_latency_ctrl);
+
+   saved_reg = readl(>pl310_data_latency_ctrl);
+   dev_read_u32_array(dev, "arm,data-latency", tag, 3);
+
+   saved_reg |= L310_LATENCY_CTRL_RD(tag[0] - 1) |
+L310_LATENCY_CTRL_WR(tag[1] - 1) |
+L310_LATENCY_CTRL_SETUP(tag[2] - 1);
+
+   writel(saved_reg, >pl310_data_latency_ctrl);
+
+   /* Enable the L2 cache */
+   setbits_le32(>pl310_ctrl, L2X0_CTRL_EN);
+}
+
+static int l2x0_ofdata_to_platdata(struct udevice *dev)
+{
+   return 0;
+}
+
+static int l2x0_probe(struct udevice *dev)
+{
+   l2c310_of_parse(dev);
+   return 0;
+}
+
+
+static const struct udevice_id l2x0_ids[] = {
+   { .compatible = "arm,pl310-cache" },
+   {}
+};
+
+U_BOOT_DRIVER(pl310_cache) = {
+   .name   = "pl310_cache",
+   .id = UCLASS_MISC,
+   .of_match = l2x0_ids,
+   .probe  = l2x0_probe,
+   .ofdata_to_platdata = l2x0_ofdata_to_platdata,
+   .flags  = DM_FLAG_PRE_RELOC,
+};
-- 
2.20.0

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

[U-Boot] [RFC PATCHv1 0/3] misc: pl310: add a dm cache driver

[Dinh Nguyen]

Hello,

I'm soliciting comments of this patchset. The patchset adds a driver
for the cache controller(specifically the PL310). This cache controller
can be found on many ARMv7 SoCs. I don't think it's used on ARMv8
platforms.

This driver will retrieve the cache properties from the board DTS files
and set the corresponding bits in cache controller.

I think we can do something similar without make this driver and placing
the file in /arch/arm/cpu/armv7, but wanted to get feedback.

To-dos:
- Add error checking
- Add more cache properties

Thanks,

Dinh Nguyen (3):
  misc: pl310: add a misc driver for the pl310 cache controller
  defconfig: socfpga_sockit_defconfig: enable L2X0_CACHE driver
  ARM: socfpga: let the pl310 driver configure the cache settings

 arch/arm/include/asm/pl310.h |  3 ++
 arch/arm/mach-socfpga/misc.c | 15 +-
 configs/socfpga_sockit_defconfig |  2 +
 drivers/misc/Kconfig |  7 +++
 drivers/misc/Makefile|  1 +
 drivers/misc/cache-l2x0.c| 84 
 6 files changed, 99 insertions(+), 13 deletions(-)
 create mode 100644 drivers/misc/cache-l2x0.c

-- 
2.20.0

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

Re: [U-Boot] [PATCH] ARM: rmobile: Convert to bootm_size

[Marek Vasut]

On 3/5/19 7:42 PM, Eugeniu Rosca wrote:
> Hello Marek,

Hi,

> May I ask for your opinion on Renesas commits [1-2] especially in
> light of the `bootm_size` changes done in your patch?
> The topics look orthogonal to me, but I kindly ask for your confirmation.

What do you want to know ? With that commit, U-Boot is sitting in the
middle of your RAM and you're likely to overwrite or corrupt it sooner
or later, so that patch is not going upstream.

> Also, purely related to the `bootm_size` patch, compiling v2019.04-rc3
> U-Boot for H3-Salvator-X with the diff [3] applied, I get:
> 
> common/image.c: In function 'env_get_bootm_mapsize':
> common/image.c:520:2: error: #error "Take bootm_size from CONFIG"
>  #error "Take bootm_size from CONFIG"
>   ^
> 
> Does this mean the "CONFIG_SYS_BOOTMAPSZ" definition has to be removed
> from include/configs/rcar-gen3-common.h, to allow the patch to have
> the desired effect?

Possibly, if you could study it a bit and if that's the case, send a
patch, that'd be nice.

> [1] https://github.com/renesas-rcar/u-boot/commit/86ad30910df818
> ("arm: rcar_gen3: Add skip of relocation")
> [2] https://github.com/renesas-rcar/u-boot/commit/91e27e4cc463e ("arm:
> rcar_gen3: Add skip of relocation")
> [3] Brutal way to reveal the active bootm_size:
> diff --git a/common/image.c b/common/image.c
> index 4d4248f234fb..d65de506060b 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -517,8 +517,10 @@ phys_size_t env_get_bootm_mapsize(void)
> }
> 
>  #if defined(CONFIG_SYS_BOOTMAPSZ)
> +#error "Take bootm_size from CONFIG"
> return CONFIG_SYS_BOOTMAPSZ;
>  #else
> +#error "Take bootm_size from env"
> return env_get_bootm_size();
>  #endif
>  }
> 
> Thanks,
> Eugeniu.
> 


-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/2] efi_loader: Fix possible starving in efi_cin_read_key

[Heinrich Schuchardt]

On 3/5/19 12:50 PM, matthias@kernel.org wrote:
> From: Matthias Brugger 
> 
> The function efi_cin_read_key can be affected by a loss of
> a character which will make u-boot to wait forever.
> Fix this by calling term_get_char instead.
> 
> Signed-off-by: Matthias Brugger 

You can test EFI keyboard input with:

=> setenv efi_selftest extended text input
=> bootefi selftest

Function keys, arrow keys, PG UP, PG DN, etc. do not work with this
patch in place.

> ---
> 
> Changes in v2: None
> 
>  lib/efi_loader/efi_console.c | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
> index 1133674faf..558aaed109 100644
> --- a/lib/efi_loader/efi_console.c
> +++ b/lib/efi_loader/efi_console.c
> @@ -493,13 +493,14 @@ static int analyze_modifiers(struct efi_key_state 
> *key_state)
>  {
>   int c, mod = 0, ret = 0;
>  
> - c = getc();
> + if (!term_get_char())
> + goto out;
>  
>   if (c != ';') {
>   ret = c;
>   if (c == '~')
>   goto out;
> - c = getc();
> + term_get_char();

lib/efi_loader/efi_console.c:496:21: warning: passing argument 1 of
‘term_get_char’ from incompatible pointer type
[-Wincompatible-pointer-types]
  if (!term_get_char())
 ^~
lib/efi_loader/efi_console.c:65:32: note: expected ‘char *’ but argument
is of type ‘int *’
 static int term_get_char(char *c)

The problem repeats throughout the patch.

Best thing is to define the argument of term_get_char() as s32 in the
first patch of the series.

>   }
>   for (;;) {
>   switch (c) {
> @@ -508,7 +509,7 @@ static int analyze_modifiers(struct efi_key_state 
> *key_state)
>   mod += c - '0';
>   /* fall through */
>   case ';':
> - c = getc();
> + term_get_char();
>   break;
>   default:
>   goto out;
> @@ -551,7 +552,9 @@ static efi_status_t efi_cin_read_key(struct efi_key_data 
> *key)
>* Xterm Control Sequences
>* https://www.xfree86.org/4.8.0/ctlseqs.html
>*/
> - ch = getc();
> + if (!term_get_char())
> + return EFI_NOT_READY;
> +
>   switch (ch) {
>   case cESC: /* ESC */
>   pressed_key.scan_code = 23;
> @@ -561,12 +564,15 @@ static efi_status_t efi_cin_read_key(struct 
> efi_key_data *key)

You missed a getc() in line 560.

Best regards

Heinrich

>   /* consider modifiers */
>   if (ch < 'P') {
>   set_shift_mask(ch - '0', >key_state);
> - ch = getc();
> + if (!term_get_char())
> + return EFI_NOT_READY;
>   }
>   pressed_key.scan_code = ch - 'P' + 11;
>   break;
>   case '[':
> - ch = getc();
> + if (!term_get_char())
> + return EFI_NOT_READY;
> +
>   switch (ch) {
>   case 'A'...'D': /* up, down right, left */
>   pressed_key.scan_code = ch - 'A' + 1;
> 

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

Re: [U-Boot] [PATCH v2 1/2] efi_loader: Fix serial console size detection

[Heinrich Schuchardt]

On 3/5/19 12:50 PM, matthias@kernel.org wrote:
> From: Matthias Brugger 
> 
> Function term_read_reply tries to read from the serial console until
> the end_char was read. This can hang forever if we are, for some reason,
> not be able to read the full response (e.g. serial buffer too small,
> frame error). This patch moves the timeout detection into
> term_read_reply to assure we will make progress.
> 
> Fixes: 6bb591f704 ("efi_loader: query serial console size reliably")
> Signed-off-by: Matthias Brugger 
> 
> ---
> 
> Changes in v2:
> - move timeout into term_get_char
> 
>  lib/efi_loader/efi_console.c | 60 
>  1 file changed, 33 insertions(+), 27 deletions(-)
> 
> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
> index 66c33a551d..1133674faf 100644
> --- a/lib/efi_loader/efi_console.c
> +++ b/lib/efi_loader/efi_console.c
> @@ -62,6 +62,21 @@ static struct simple_text_output_mode efi_con_mode = {
>   .cursor_visible = 1,
>  };
>  
> +static int term_get_char(char *c)
> +{
> + u64 timeout;
> +
> + /* Wait up to 100 ms for a character */
> + timeout = timer_get_us() + 10;
> +
> + while (!tstc())
> + if (timer_get_us() > timeout)
> + return 1;
> +
> + *c = getc();
> + return 0;
> +}
> +
>  /*
>   * Receive and parse a reply from the terminal.
>   *
> @@ -75,31 +90,31 @@ static int term_read_reply(int *n, int num, char end_char)
>   char c;
>   int i = 0;
>  
> - c = getc();
> - if (c != cESC)
> + if (term_get_char() || c != cESC)
>   return -1;
> - c = getc();
> - if (c != '[')
> +
> + if (term_get_char() || c != '[')
>   return -1;
>  
>   n[0] = 0;
>   while (1) {
> - c = getc();
> - if (c == ';') {
> - i++;
> - if (i >= num)
> + if (!term_get_char()) {
> + if (c == ';') {
> + i++;
> + if (i >= num)
> + return -1;
> + n[i] = 0;
> + continue;
> + } else if (c == end_char) {
> + break;
> + } else if (c > '9' || c < '0') {
>   return -1;
> - n[i] = 0;
> - continue;
> - } else if (c == end_char) {
> - break;
> - } else if (c > '9' || c < '0') {
> - return -1;
> - }
> + }
>  
> - /* Read one more decimal position */
> - n[i] *= 10;
> - n[i] += c - '0';
> + /* Read one more decimal position */
> + n[i] *= 10;
> + n[i] += c - '0';
> + }

If no character is received we should throw an error:

} else {
return -1;

Best regards

Heinrich

>   }
>   if (i != num - 1)
>   return -1;
> @@ -196,7 +211,6 @@ static int query_console_serial(int *rows, int *cols)
>  {
>   int ret = 0;
>   int n[2];
> - u64 timeout;
>  
>   /* Empty input buffer */
>   while (tstc())
> @@ -216,14 +230,6 @@ static int query_console_serial(int *rows, int *cols)
>  ESC "[999;999H"  /* Move to bottom right corner */
>  ESC "[6n");  /* Query cursor position */
>  
> - /* Allow up to one second for a response */
> - timeout = timer_get_us() + 100;
> - while (!tstc())
> - if (timer_get_us() > timeout) {
> - ret = -1;
> - goto out;
> - }
> -
>   /* Read {rows,cols} */
>   if (term_read_reply(n, 2, 'R')) {
>   ret = 1;
> 

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

Re: [U-Boot] [PATCH] ARM: rmobile: Convert to bootm_size

[Eugeniu Rosca]

Hello Marek,

May I ask for your opinion on Renesas commits [1-2] especially in
light of the `bootm_size` changes done in your patch?
The topics look orthogonal to me, but I kindly ask for your confirmation.

Also, purely related to the `bootm_size` patch, compiling v2019.04-rc3
U-Boot for H3-Salvator-X with the diff [3] applied, I get:

common/image.c: In function 'env_get_bootm_mapsize':
common/image.c:520:2: error: #error "Take bootm_size from CONFIG"
 #error "Take bootm_size from CONFIG"
  ^

Does this mean the "CONFIG_SYS_BOOTMAPSZ" definition has to be removed
from include/configs/rcar-gen3-common.h, to allow the patch to have
the desired effect?

[1] https://github.com/renesas-rcar/u-boot/commit/86ad30910df818
("arm: rcar_gen3: Add skip of relocation")
[2] https://github.com/renesas-rcar/u-boot/commit/91e27e4cc463e ("arm:
rcar_gen3: Add skip of relocation")
[3] Brutal way to reveal the active bootm_size:
diff --git a/common/image.c b/common/image.c
index 4d4248f234fb..d65de506060b 100644
--- a/common/image.c
+++ b/common/image.c
@@ -517,8 +517,10 @@ phys_size_t env_get_bootm_mapsize(void)
}

 #if defined(CONFIG_SYS_BOOTMAPSZ)
+#error "Take bootm_size from CONFIG"
return CONFIG_SYS_BOOTMAPSZ;
 #else
+#error "Take bootm_size from env"
return env_get_bootm_size();
 #endif
 }

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

Re: [U-Boot] IMX6 NAND boot regression

[Michael Nazzareno Trimarchi]

Hi

On Tue, Mar 5, 2019 at 6:20 PM Tim Harvey  wrote:
>
> On Tue, Mar 5, 2019 at 9:00 AM Michael Nazzareno Trimarchi
>  wrote:
> >
> > Hi Tim
> >
> > On Tue, Mar 5, 2019 at 5:54 PM Tim Harvey  wrote:
> > >
> > > On Tue, Mar 5, 2019 at 8:41 AM Michael Nazzareno Trimarchi
> > >  wrote:
> > > >
> > > > HI all
> > > >
> > > > On Mon, Feb 4, 2019 at 7:14 PM Tim Harvey  wrote:
> > > > >
> > > > > On Sat, Feb 2, 2019 at 5:30 AM Adam Ford  wrote:
> > > > > >
> > > > > > On Sat, Feb 2, 2019 at 12:29 AM Jagan Teki 
> > > > > >  wrote:
> > > > > > >
> > > > > > > +Adam, Shyam
> > > > > > >
> > > > > > > On Sat, 2 Feb, 2019, 8:49 AM Stefan Agner 
> > > > > > >  > > > > > >
> > > > > > > > Hi Tim,
> > > > > > > >
> > > > > > > > On 02.02.19 03:32, Tim Harvey wrote:
> > > > > > > > > Stefan,
> > > > > > > > >
> > > > > > > > > I'm trying to track down an IMX6 SPL NAND boot regression 
> > > > > > > > > that started
> > > > > > > > > in v2018.07 with your patch series to mxs_nand.
> > > > > > > >
> > > > > > > > I am sorry about that. Unfortunately I did not had a design at 
> > > > > > > > hand where
> > > > > > > > I was able to test the NAND driver in SPL...
> > > > > > > >
> > > > > > > > >
> > > > > > > > > I bisected it back to 
> > > > > > > > > '5346c31e305a37d39f535cc0d5ae87d8b7e81230 mtd:
> > > > > > > > > nand: mxs_nand: use self init'. With this particular patch 
> > > > > > > > > nand bbt
> > > > > > > > > scanning would crash the board because of nand_chip.scan_btt 
> > > > > > > > > not being
> > > > > > > > > assigned. This was later fixed in
> > > > > > > > > '96d0be07e7498e7174daa6f3b56fc807b9feb71d MTD: nand: 
> > > > > > > > > mxs_nand_spl: Fix
> > > > > > > > > empty function pointer for BBT' but cherry-picking that on 
> > > > > > > > > top of
> > > > > > > > > 5346c31 fixes the immediate crash while scanning but then I 
> > > > > > > > > find that
> > > > > > > > > mxs_read_page_ecc() hangs on the 4th page of reading 
> > > > > > > > > u-boot.img from
> > > > > > > > > the NAND. This gets worse 2 patches later where in
> > > > > > > > > '28897e8d21f8e197e259a91c693de09cd81f2d5a: mtd: nand: 
> > > > > > > > > mxs_nand: use
> > > > > > > > > structure for BCH geometry' I find that the first byte of 
> > > > > > > > > every page
> > > > > > > > > read is wrong because mxs_nand_swap_block_mark() is getting 
> > > > > > > > > called on
> > > > > > > > > the page which swaps the first bytes with oob.
> > > > > > > > >
> > > > > > > > > There are several IMX6 boards out there using both NAND and 
> > > > > > > > > SPL I
> > > > > > > > > believe that I would assume were broken by this series. Any 
> > > > > > > > > ideas on
> > > > > > > > > the proper resolution?
> > > > > > > >
> > > > > > >
> > > > > > > Look like 2017.03 can be stable boot from nand as for as my test 
> > > > > > > is concern.
> > > > > > >
> > > > > > > We are also trying hard using git bisect, but seems like multiple 
> > > > > > > breakings.
> > > > > > >
> > > > > > > Will keep posted if something move further.
> > > > > >
> > > > > >
> > > > > > From a different thread, someone was able to test these patches and
> > > > > > found they fixed their booting issues:
> > > > > >
> > > > > >  There was a broken function pointer here that was fixed and applied
> > > > > >  the imx-master, but pending merge with master
> > > > > >  http://patchwork.ozlabs.org/patch/1019440/
> > > > >
> > > > > right, this one was the 96d0be07 merged upstream already. I'm not
> > > > > clear how any NAND SPL would have worked after Sefan's series back in
> > > > > June without this one.
> > > > >
> > > >
> > > > >>SPL: board_init_r()
> > > > spl_init
> > > > Trying to boot from NAND
> > > > spl: nand - using hw ecc
> > > > 0x2c:0xdc erasesize=262144 (>>18)
> > > > writesize=4096 (>>12)
> > > > oobsize=224
> > > > chipsize=536870912
> > > > nand_spl_load_image offset:0x0020 len:64 page:512
> > > > SPL: payload image: U-Boot 2019.04-rc3-dirty for imx� load addr:
> > > > 0x177fffc0 size: 635435
> > > > nand_spl_load_image offset:0x0020 len:635435 page:512
> > > > is_badblock offs=0x0024 block:9 page:576
> > > > is_badblock offs=0x0028 block:10 page:640
> > > > Jumping to U-Boot
> > > > loaded - jumping to U-Boot...
> > > > image entry point: 0x1780
> > > >
> > > > I'm stuck here. Booting from mmc is fine
> > > >
> > > > Michael
> > >
> > > Michael,
> > >
> > > What code are you running (git sha) and what board?
> > >
> > > Make sure you have 04568bd0b6 MTD: nand: mxs_nand: Allow driver to
> > > auto setup ECC in SPL
> > >
> >
> > Top of master and I have that commit included. Can I know one imx6 board now
> > that can boot from Nand?
> >
>
> Michael,
>
> I just built v2019.04-rc3 for gwventana_nand_defconfig and booted it
> fine on a board with a 2GiB Cypress NAND flash. This uses NAND and SPL
> (and would not boot before the mentioned patch).
>

diff --git a/configs/imx6dl_icore_nand_defconfig
b/configs/imx6dl_icore_nand_defconfig
index 

Re: [U-Boot] [PATCH v2 1/2] efi_loader: Fix serial console size detection

[Heinrich Schuchardt]

On 3/5/19 12:50 PM, matthias@kernel.org wrote:
> From: Matthias Brugger 
> 
> Function term_read_reply tries to read from the serial console until
> the end_char was read. This can hang forever if we are, for some reason,
> not be able to read the full response (e.g. serial buffer too small,
> frame error). This patch moves the timeout detection into
> term_read_reply to assure we will make progress.
> 
> Fixes: 6bb591f704 ("efi_loader: query serial console size reliably")
> Signed-off-by: Matthias Brugger 
Reviewed-by: Heinrich Schuchardt 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 03/13] net: sun8i_emac: Retrieve GMAC clock via 'syscon' phandle

[Joe Hershberger]

On Tue, Mar 5, 2019 at 10:17 AM Jagan Teki  wrote:
>
> On Sat, Mar 2, 2019 at 12:29 AM Joe Hershberger  
> wrote:
> >
> > On Wed, Feb 27, 2019 at 12:59 PM Jagan Teki  
> > wrote:
> > >
> > > Unlike other Allwinner SoC's R40 GMAC clock control register
> > > is locate in CCU, but rest located via syscon itself. Since
> > > the phandle property for current code look for 'syscon' and
> > > it will grab the respective ccu or syscon base address based
> > > on DT property defined in respective SoC dtsi.
> > >
> > > So, use the existing 'syscon' code even for R40 for retrieving
> > > GMAC clock via CCU and update the register directly in
> > > sun8i_emac_set_syscon instead of writing it separately using
> > > ccm base.
> > >
> > > Cc: Joe Hershberger 
> > > Cc: Lothar Felten 
> > > Signed-off-by: Jagan Teki 
> > > ---
> > >  drivers/net/sun8i_emac.c | 55 
> > >  1 file changed, 27 insertions(+), 28 deletions(-)
> > >
> > > diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
> > > index c9798445c7..a7fb7ac405 100644
> > > --- a/drivers/net/sun8i_emac.c
> > > +++ b/drivers/net/sun8i_emac.c
> > > @@ -285,10 +285,18 @@ static int sun8i_emac_set_syscon(struct 
> > > sun8i_eth_pdata *pdata,
> > > int ret;
> > > u32 reg;
> > >
> > > -   reg = readl(priv->sysctl_reg + 0x30);
> > > +   if (priv->variant == R40_GMAC) {
> > > +   /* Select RGMII for R40 */
> > > +   reg = readl(priv->sysctl_reg + 0x164);
> >
> > Please don't add more magic numbers. #define with register name.
>
> I do prefer the same, but kept it as same as original. and there are
> other place do have similar reg magic numbers.  Will clean it up all
> in separate patch. would that be okay?

OK.  This cam in after the merge window closed, right? If so, please
move the cleanup patch before this one in the next version.

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

Re: [U-Boot] IMX6 NAND boot regression

[Tim Harvey]

On Tue, Mar 5, 2019 at 9:00 AM Michael Nazzareno Trimarchi
 wrote:
>
> Hi Tim
>
> On Tue, Mar 5, 2019 at 5:54 PM Tim Harvey  wrote:
> >
> > On Tue, Mar 5, 2019 at 8:41 AM Michael Nazzareno Trimarchi
> >  wrote:
> > >
> > > HI all
> > >
> > > On Mon, Feb 4, 2019 at 7:14 PM Tim Harvey  wrote:
> > > >
> > > > On Sat, Feb 2, 2019 at 5:30 AM Adam Ford  wrote:
> > > > >
> > > > > On Sat, Feb 2, 2019 at 12:29 AM Jagan Teki 
> > > > >  wrote:
> > > > > >
> > > > > > +Adam, Shyam
> > > > > >
> > > > > > On Sat, 2 Feb, 2019, 8:49 AM Stefan Agner  > > > > > wrote:
> > > > > >
> > > > > > > Hi Tim,
> > > > > > >
> > > > > > > On 02.02.19 03:32, Tim Harvey wrote:
> > > > > > > > Stefan,
> > > > > > > >
> > > > > > > > I'm trying to track down an IMX6 SPL NAND boot regression that 
> > > > > > > > started
> > > > > > > > in v2018.07 with your patch series to mxs_nand.
> > > > > > >
> > > > > > > I am sorry about that. Unfortunately I did not had a design at 
> > > > > > > hand where
> > > > > > > I was able to test the NAND driver in SPL...
> > > > > > >
> > > > > > > >
> > > > > > > > I bisected it back to '5346c31e305a37d39f535cc0d5ae87d8b7e81230 
> > > > > > > > mtd:
> > > > > > > > nand: mxs_nand: use self init'. With this particular patch nand 
> > > > > > > > bbt
> > > > > > > > scanning would crash the board because of nand_chip.scan_btt 
> > > > > > > > not being
> > > > > > > > assigned. This was later fixed in
> > > > > > > > '96d0be07e7498e7174daa6f3b56fc807b9feb71d MTD: nand: 
> > > > > > > > mxs_nand_spl: Fix
> > > > > > > > empty function pointer for BBT' but cherry-picking that on top 
> > > > > > > > of
> > > > > > > > 5346c31 fixes the immediate crash while scanning but then I 
> > > > > > > > find that
> > > > > > > > mxs_read_page_ecc() hangs on the 4th page of reading u-boot.img 
> > > > > > > > from
> > > > > > > > the NAND. This gets worse 2 patches later where in
> > > > > > > > '28897e8d21f8e197e259a91c693de09cd81f2d5a: mtd: nand: mxs_nand: 
> > > > > > > > use
> > > > > > > > structure for BCH geometry' I find that the first byte of every 
> > > > > > > > page
> > > > > > > > read is wrong because mxs_nand_swap_block_mark() is getting 
> > > > > > > > called on
> > > > > > > > the page which swaps the first bytes with oob.
> > > > > > > >
> > > > > > > > There are several IMX6 boards out there using both NAND and SPL 
> > > > > > > > I
> > > > > > > > believe that I would assume were broken by this series. Any 
> > > > > > > > ideas on
> > > > > > > > the proper resolution?
> > > > > > >
> > > > > >
> > > > > > Look like 2017.03 can be stable boot from nand as for as my test is 
> > > > > > concern.
> > > > > >
> > > > > > We are also trying hard using git bisect, but seems like multiple 
> > > > > > breakings.
> > > > > >
> > > > > > Will keep posted if something move further.
> > > > >
> > > > >
> > > > > From a different thread, someone was able to test these patches and
> > > > > found they fixed their booting issues:
> > > > >
> > > > >  There was a broken function pointer here that was fixed and applied
> > > > >  the imx-master, but pending merge with master
> > > > >  http://patchwork.ozlabs.org/patch/1019440/
> > > >
> > > > right, this one was the 96d0be07 merged upstream already. I'm not
> > > > clear how any NAND SPL would have worked after Sefan's series back in
> > > > June without this one.
> > > >
> > >
> > > >>SPL: board_init_r()
> > > spl_init
> > > Trying to boot from NAND
> > > spl: nand - using hw ecc
> > > 0x2c:0xdc erasesize=262144 (>>18)
> > > writesize=4096 (>>12)
> > > oobsize=224
> > > chipsize=536870912
> > > nand_spl_load_image offset:0x0020 len:64 page:512
> > > SPL: payload image: U-Boot 2019.04-rc3-dirty for imx� load addr:
> > > 0x177fffc0 size: 635435
> > > nand_spl_load_image offset:0x0020 len:635435 page:512
> > > is_badblock offs=0x0024 block:9 page:576
> > > is_badblock offs=0x0028 block:10 page:640
> > > Jumping to U-Boot
> > > loaded - jumping to U-Boot...
> > > image entry point: 0x1780
> > >
> > > I'm stuck here. Booting from mmc is fine
> > >
> > > Michael
> >
> > Michael,
> >
> > What code are you running (git sha) and what board?
> >
> > Make sure you have 04568bd0b6 MTD: nand: mxs_nand: Allow driver to
> > auto setup ECC in SPL
> >
>
> Top of master and I have that commit included. Can I know one imx6 board now
> that can boot from Nand?
>

Michael,

I just built v2019.04-rc3 for gwventana_nand_defconfig and booted it
fine on a board with a 2GiB Cypress NAND flash. This uses NAND and SPL
(and would not boot before the mentioned patch).

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

Re: [U-Boot] IMX6 NAND boot regression

[Michael Nazzareno Trimarchi]

Hi Tim

On Tue, Mar 5, 2019 at 5:59 PM Michael Nazzareno Trimarchi
 wrote:
>
> Hi Tim
>
> On Tue, Mar 5, 2019 at 5:54 PM Tim Harvey  wrote:
> >
> > On Tue, Mar 5, 2019 at 8:41 AM Michael Nazzareno Trimarchi
> >  wrote:
> > >
> > > HI all
> > >
> > > On Mon, Feb 4, 2019 at 7:14 PM Tim Harvey  wrote:
> > > >
> > > > On Sat, Feb 2, 2019 at 5:30 AM Adam Ford  wrote:
> > > > >
> > > > > On Sat, Feb 2, 2019 at 12:29 AM Jagan Teki 
> > > > >  wrote:
> > > > > >
> > > > > > +Adam, Shyam
> > > > > >
> > > > > > On Sat, 2 Feb, 2019, 8:49 AM Stefan Agner  > > > > > wrote:
> > > > > >
> > > > > > > Hi Tim,
> > > > > > >
> > > > > > > On 02.02.19 03:32, Tim Harvey wrote:
> > > > > > > > Stefan,
> > > > > > > >
> > > > > > > > I'm trying to track down an IMX6 SPL NAND boot regression that 
> > > > > > > > started
> > > > > > > > in v2018.07 with your patch series to mxs_nand.
> > > > > > >
> > > > > > > I am sorry about that. Unfortunately I did not had a design at 
> > > > > > > hand where
> > > > > > > I was able to test the NAND driver in SPL...
> > > > > > >
> > > > > > > >
> > > > > > > > I bisected it back to '5346c31e305a37d39f535cc0d5ae87d8b7e81230 
> > > > > > > > mtd:
> > > > > > > > nand: mxs_nand: use self init'. With this particular patch nand 
> > > > > > > > bbt
> > > > > > > > scanning would crash the board because of nand_chip.scan_btt 
> > > > > > > > not being
> > > > > > > > assigned. This was later fixed in
> > > > > > > > '96d0be07e7498e7174daa6f3b56fc807b9feb71d MTD: nand: 
> > > > > > > > mxs_nand_spl: Fix
> > > > > > > > empty function pointer for BBT' but cherry-picking that on top 
> > > > > > > > of
> > > > > > > > 5346c31 fixes the immediate crash while scanning but then I 
> > > > > > > > find that
> > > > > > > > mxs_read_page_ecc() hangs on the 4th page of reading u-boot.img 
> > > > > > > > from
> > > > > > > > the NAND. This gets worse 2 patches later where in
> > > > > > > > '28897e8d21f8e197e259a91c693de09cd81f2d5a: mtd: nand: mxs_nand: 
> > > > > > > > use
> > > > > > > > structure for BCH geometry' I find that the first byte of every 
> > > > > > > > page
> > > > > > > > read is wrong because mxs_nand_swap_block_mark() is getting 
> > > > > > > > called on
> > > > > > > > the page which swaps the first bytes with oob.
> > > > > > > >
> > > > > > > > There are several IMX6 boards out there using both NAND and SPL 
> > > > > > > > I
> > > > > > > > believe that I would assume were broken by this series. Any 
> > > > > > > > ideas on
> > > > > > > > the proper resolution?
> > > > > > >
> > > > > >
> > > > > > Look like 2017.03 can be stable boot from nand as for as my test is 
> > > > > > concern.
> > > > > >
> > > > > > We are also trying hard using git bisect, but seems like multiple 
> > > > > > breakings.
> > > > > >
> > > > > > Will keep posted if something move further.
> > > > >
> > > > >
> > > > > From a different thread, someone was able to test these patches and
> > > > > found they fixed their booting issues:
> > > > >
> > > > >  There was a broken function pointer here that was fixed and applied
> > > > >  the imx-master, but pending merge with master
> > > > >  http://patchwork.ozlabs.org/patch/1019440/
> > > >
> > > > right, this one was the 96d0be07 merged upstream already. I'm not
> > > > clear how any NAND SPL would have worked after Sefan's series back in
> > > > June without this one.
> > > >
> > >
> > > >>SPL: board_init_r()
> > > spl_init
> > > Trying to boot from NAND
> > > spl: nand - using hw ecc
> > > 0x2c:0xdc erasesize=262144 (>>18)
> > > writesize=4096 (>>12)
> > > oobsize=224
> > > chipsize=536870912
> > > nand_spl_load_image offset:0x0020 len:64 page:512
> > > SPL: payload image: U-Boot 2019.04-rc3-dirty for imx� load addr:
> > > 0x177fffc0 size: 635435
> > > nand_spl_load_image offset:0x0020 len:635435 page:512
> > > is_badblock offs=0x0024 block:9 page:576
> > > is_badblock offs=0x0028 block:10 page:640
> > > Jumping to U-Boot
> > > loaded - jumping to U-Boot...
> > > image entry point: 0x1780
> > >
> > > I'm stuck here. Booting from mmc is fine
> > >
> > > Michael
> >
> > Michael,
> >
> > What code are you running (git sha) and what board?
> >
> > Make sure you have 04568bd0b6 MTD: nand: mxs_nand: Allow driver to
> > auto setup ECC in SPL
> >
>
> Top of master and I have that commit included. Can I know one imx6 board now
> that can boot from Nand?
One valid is here

U-Boot SPL 2017.03 (Mar 05 2019 - 18:15:17)
Trying to boot from NAND
: 512 MiB


U-Boot 2017.03 (Mar 05 2019 - 18:15:17 +0100)

CPU:   Freescale i.MX6SOLO rev1.3 996 MHz (running at 792 MHz)
CPU:   Extended Commercial temperature grade (-20C to 105C) at 54C
Reset cause: WDOG
Model: Engicam i.CoreM6 DualLite/Solo Starter Kit
DRAM:  256 MiB
NAND:  512 MiB
MMC:   FSL_SDHC: 0
*** Warning - bad CRC, using default environment

No panel detected: default to Amp-WD
Display: Amp-WD (800x480)
In:serial
Out:   serial
Err:   serial
Net:
Error: ethernet@02188000 address not set.

Re: [U-Boot] net: dm: fec: Support phy-reset-post-delay property

[Joe Hershberger]

Hi Andrejs,

https://patchwork.ozlabs.org/patch/1050177/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] ARM: k2g-ice: Add pinmux support for rgmii interface

[Joe Hershberger]

Hi Murali,

https://patchwork.ozlabs.org/patch/1047978/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] net: phy: ti: use generic helpers to access MMD registers

[Joe Hershberger]

Hi Carlo,

https://patchwork.ozlabs.org/patch/1038820/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] mc : Reduce MC memory size to 128M

[Joe Hershberger]

Hi Meenakshi,

https://patchwork.ozlabs.org/patch/1048656/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] net: phy: micrel: Find Micrel PHY node correctly

[Joe Hershberger]

Hi James,

https://patchwork.ozlabs.org/patch/1051237/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] ARM: dts: k2g-ice: add dt node for netcp

[Joe Hershberger]

Hi Murali,

https://patchwork.ozlabs.org/patch/1047980/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] net: phy: Fix return value check phy_probe

[Joe Hershberger]

Hi Michal,

https://patchwork.ozlabs.org/patch/1051139/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] k2g: config enable ti phy dp83867 for k2g

[Joe Hershberger]

Hi Murali,

https://patchwork.ozlabs.org/patch/1047983/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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

Re: [U-Boot] dts: imx8qxp-mek: Add PHY post reset delay

[Joe Hershberger]

Hi Andrejs,

https://patchwork.ozlabs.org/patch/1050178/ was applied to 
http://git.denx.de/?p=u-boot/u-boot-net.git

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