[U-Boot] [PATCH v2 3/4] configs: dra71x-evm: Add Support for NAND

[Faiz Abbas]

Add NAND support to dra71x-evm defconfig

Signed-off-by: Faiz Abbas 
---
 configs/dra7xx_evm_defconfig| 3 +++
 configs/dra7xx_hs_evm_defconfig | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/configs/dra7xx_evm_defconfig b/configs/dra7xx_evm_defconfig
index 3f25a2ec28..d71d989c4c 100644
--- a/configs/dra7xx_evm_defconfig
+++ b/configs/dra7xx_evm_defconfig
@@ -28,6 +28,7 @@ CONFIG_SPL_OS_BOOT=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_CMD_SPL=y
 # CONFIG_CMD_FLASH is not set
+CONFIG_CMD_NAND=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
@@ -66,6 +67,8 @@ CONFIG_MMC_UHS_SUPPORT=y
 CONFIG_MMC_HS200_SUPPORT=y
 CONFIG_SPL_MMC_HS200_SUPPORT=y
 CONFIG_MMC_OMAP_HS=y
+CONFIG_NAND=y
+CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_SPANSION=y
diff --git a/configs/dra7xx_hs_evm_defconfig b/configs/dra7xx_hs_evm_defconfig
index ee28e0c6ec..4642da3c01 100644
--- a/configs/dra7xx_hs_evm_defconfig
+++ b/configs/dra7xx_hs_evm_defconfig
@@ -32,6 +32,7 @@ CONFIG_SPL_DMA_SUPPORT=y
 # CONFIG_SPL_NAND_SUPPORT is not set
 CONFIG_SPL_SPI_LOAD=y
 # CONFIG_CMD_FLASH is not set
+CONFIG_CMD_NAND=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
@@ -70,6 +71,8 @@ CONFIG_MMC_UHS_SUPPORT=y
 CONFIG_MMC_HS200_SUPPORT=y
 CONFIG_SPL_MMC_HS200_SUPPORT=y
 CONFIG_MMC_OMAP_HS=y
+CONFIG_NAND=y
+CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_SPANSION=y
-- 
2.19.2

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

[U-Boot] [PATCH v2 4/4] configs: ti_omap5_common: Add NAND environment settings

[Faiz Abbas]

Now that NAND is supported on DRA71x include various NAND environment
settings

Signed-off-by: Faiz Abbas 
---
 configs/dra7xx_evm_defconfig  |  4 +++-
 configs/dra7xx_hs_evm_defconfig   |  4 +++-
 include/configs/dra7xx_evm.h  |  2 +-
 include/configs/ti_omap5_common.h |  3 ++-
 include/environment/ti/nand.h | 26 ++
 5 files changed, 35 insertions(+), 4 deletions(-)
 create mode 100644 include/environment/ti/nand.h

diff --git a/configs/dra7xx_evm_defconfig b/configs/dra7xx_evm_defconfig
index d71d989c4c..68eab7184e 100644
--- a/configs/dra7xx_evm_defconfig
+++ b/configs/dra7xx_evm_defconfig
@@ -23,13 +23,15 @@ CONFIG_BOARD_EARLY_INIT_F=y
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_SEPARATE_BSS=y
 CONFIG_SPL_DMA_SUPPORT=y
-# CONFIG_SPL_NAND_SUPPORT is not set
 CONFIG_SPL_OS_BOOT=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_CMD_SPL=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_NAND=y
 # CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_MTDPARTS=y
+CONFIG_MTDIDS_DEFAULT="nand0=nand.0"
+CONFIG_MTDPARTS_DEFAULT="mtdparts=nand.0:256k(NAND.SPL),256k(NAND.SPL.backup1),256k(NAND.SPL.backup2),256k(NAND.SPL.backup3),256k(NAND.u-boot-spl-os),2m(NAND.u-boot),128k(NAND.u-boot-env),128k(NAND.u-boot-env.backup1),8m(NAND.kernel),-(NAND.file-system)"
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="dra7-evm"
diff --git a/configs/dra7xx_hs_evm_defconfig b/configs/dra7xx_hs_evm_defconfig
index 4642da3c01..076c800332 100644
--- a/configs/dra7xx_hs_evm_defconfig
+++ b/configs/dra7xx_hs_evm_defconfig
@@ -33,7 +33,9 @@ CONFIG_SPL_DMA_SUPPORT=y
 CONFIG_SPL_SPI_LOAD=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_NAND=y
-# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_MTDPARTS=y
+CONFIG_MTDIDS_DEFAULT="nand0=nand.0"
+CONFIG_MTDPARTS_DEFAULT="mtdparts=nand.0:256k(NAND.SPL),256k(NAND.SPL.backup1),256k(NAND.SPL.backup2),256k(NAND.SPL.backup3),256k(NAND.u-boot-spl-os),2m(NAND.u-boot),128k(NAND.u-boot-env),128k(NAND.u-boot-env.backup1),8m(NAND.kernel),-(NAND.file-system)"
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="dra7-evm"
diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index f36a9c3e08..955d315608 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -136,7 +136,7 @@
 50, 51, 52, 53, 54, 55, 56, 57, }
 #define CONFIG_SYS_NAND_ECCSIZE512
 #define CONFIG_SYS_NAND_ECCBYTES   14
-#define CONFIG_SYS_NAND_U_BOOT_OFFS0x000c
+#define CONFIG_SYS_NAND_U_BOOT_OFFS0x0014
 /* NAND: SPL related configs */
 /* NAND: SPL falcon mode configs */
 #ifdef CONFIG_SPL_OS_BOOT
diff --git a/include/configs/ti_omap5_common.h 
b/include/configs/ti_omap5_common.h
index ba57c40182..7c08e47d3d 100644
--- a/include/configs/ti_omap5_common.h
+++ b/include/configs/ti_omap5_common.h
@@ -56,6 +56,7 @@
 
 #include 
 #include 
+#include 
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
DEFAULT_LINUX_BOOT_ENV \
@@ -65,6 +66,7 @@
DEFAULT_FDT_TI_ARGS \
DFUARGS \
NETARGS \
+   NANDARGS \
 
 /*
  * SPL related defines.  The Public RAM memory map the ROM defines the
@@ -100,7 +102,6 @@
 
 #define CONFIG_SYS_SPL_ARGS_ADDR   (CONFIG_SYS_SDRAM_BASE + \
 (128 << 20))
-
 #ifdef CONFIG_SPL_BUILD
 #undef CONFIG_TIMER
 #endif
diff --git a/include/environment/ti/nand.h b/include/environment/ti/nand.h
new file mode 100644
index 00..f838cb3ed1
--- /dev/null
+++ b/include/environment/ti/nand.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Environment variable definitions for NAND on TI boards.
+ */
+
+#ifdef CONFIG_NAND
+#define NANDARGS \
+   "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \
+   "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
+   "nandargs=setenv bootargs console=${console} " \
+   "${optargs} " \
+   "root=${nandroot} " \
+   "rootfstype=${nandrootfstype}\0" \
+   "nandroot=ubi0:rootfs rw ubi.mtd=NAND.file-system,2048\0" \
+   "nandrootfstype=ubifs rootwait=1\0" \
+   "nandboot=echo Booting from nand ...; " \
+   "run nandargs; " \
+   "nand read ${fdtaddr} NAND.u-boot-spl-os; " \
+   "nand read ${loadaddr} NAND.kernel; " \
+   "bootz ${loadaddr} - ${fdtaddr}\0"
+#else
+#define NANDARGS ""
+#endif
+
-- 
2.19.2

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

[U-Boot] [PATCH v2 2/4] arm: dra7: Allow NAND to be enabled on DRA71x EVM.

[Faiz Abbas]

From: Franklin S Cooper Jr 

If SW 8 pins 0 and 1 indicate that NAND should be enabled then
the pins pinmux must be reconfigured for NAND mode.

Therefore, enable NAND by reconfiguring the pinmux.

Signed-off-by: Franklin S Cooper Jr 
Signed-off-by: Faiz Abbas 
---
 board/ti/dra7xx/evm.c | 56 +++
 1 file changed, 56 insertions(+)

diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index d69641e3a0..446ce8399c 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -55,6 +56,10 @@ DECLARE_GLOBAL_DATA_PTR;
 
 #define SYSINFO_BOARD_NAME_MAX_LEN 37
 
+/* I2C I/O Expander */
+#define NAND_PCF8575_ADDR  0x21
+#define NAND_PCF8575_I2C_BUS_NUM   0
+
 const struct omap_sysinfo sysinfo = {
"Board: UNKNOWN(DRA7 EVM) REV UNKNOWN\n"
 };
@@ -777,6 +782,44 @@ void set_muxconf_regs(void)
 early_padconf, ARRAY_SIZE(early_padconf));
 }
 
+#if defined(CONFIG_NAND)
+static int nand_sw_detect(void)
+{
+   int rc;
+   uchar data[2];
+   struct udevice *dev;
+
+   rc = i2c_get_chip_for_busnum(NAND_PCF8575_I2C_BUS_NUM,
+NAND_PCF8575_ADDR, 0, );
+   if (rc)
+   return -1;
+
+   rc = dm_i2c_read(dev, 0, (uint8_t *), sizeof(data));
+   if (rc)
+   return -1;
+
+   /* We are only interested in P10 and P11 on PCF8575 which is equal to
+* bits 8 and 9.
+*/
+   data[1] = data[1] & 0x3;
+
+   /* Ensure only P11 is set and P10 is cleared. This ensures only
+* NAND (P10) is configured and not NOR (P11) which are both low
+* true signals. NAND and NOR settings should not be enabled at
+* the same time.
+*/
+   if (data[1] == 0x2)
+   return 0;
+
+   return -1;
+}
+#else
+int nand_sw_detect(void)
+{
+   return -1;
+}
+#endif
+
 #ifdef CONFIG_IODELAY_RECALIBRATION
 void recalibrate_iodelay(void)
 {
@@ -796,6 +839,19 @@ void recalibrate_iodelay(void)
npads = ARRAY_SIZE(dra71x_core_padconf_array);
iodelay = dra71_iodelay_cfg_array;
niodelays = ARRAY_SIZE(dra71_iodelay_cfg_array);
+   /* If SW8 on the EVM is set to enable NAND then
+* overwrite the pins used by VOUT3 with NAND.
+*/
+   if (!nand_sw_detect()) {
+   delta_pads = dra71x_nand_padconf_array;
+   delta_npads =
+   ARRAY_SIZE(dra71x_nand_padconf_array);
+   } else {
+   delta_pads = dra71x_vout3_padconf_array;
+   delta_npads =
+   ARRAY_SIZE(dra71x_vout3_padconf_array);
+   }
+
} else if (board_is_dra72x_revc_or_later()) {
delta_pads = dra72x_rgmii_padconf_array_revc;
delta_npads =
-- 
2.19.2

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

[U-Boot] [PATCH v2 0/4] Add Support for NAND in dra71x-evm

[Faiz Abbas]

The following patches add support for NAND and booting from
NAND in dra71x-evm.

v2:
Patch4: Moved NANDARGS to its own file in include/environment/ti

Faiz Abbas (2):
  configs: dra71x-evm: Add Support for NAND
  configs: ti_omap5_common: Add NAND environment settings

Franklin S Cooper Jr (2):
  board: ti: dra71: Add pinmux settings for NAND on DRA71x EVM
  arm: dra7: Allow NAND to be enabled on DRA71x EVM.

 board/ti/dra7xx/evm.c | 56 +
 board/ti/dra7xx/mux_data.h| 60 ++-
 configs/dra7xx_evm_defconfig  |  7 +++-
 configs/dra7xx_hs_evm_defconfig   |  7 +++-
 include/configs/dra7xx_evm.h  |  2 +-
 include/configs/ti_omap5_common.h |  3 +-
 include/environment/ti/nand.h | 26 ++
 7 files changed, 141 insertions(+), 20 deletions(-)
 create mode 100644 include/environment/ti/nand.h

-- 
2.19.2

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

[U-Boot] [PATCH v2 1/4] board: ti: dra71: Add pinmux settings for NAND on DRA71x EVM

[Faiz Abbas]

From: Franklin S Cooper Jr 

By default VOUT3 occupies the pins required for NAND. Therefore, create
a seperate entry that can be use to reconfigure these pins to work for
NAND.

On the EVM SWITCH 8 pins 0 and 1 will be used to determine if NAND is
enabled or not. For NAND to be selected pin 0 should be on and pin 1
should be off. Any other combination will assume NAND shouldn't be
enabled.

Signed-off-by: Franklin S Cooper Jr 
Signed-off-by: Faiz Abbas 
---
 board/ti/dra7xx/mux_data.h | 60 --
 1 file changed, 44 insertions(+), 16 deletions(-)

diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
index f1f6bd5316..75da5cb608 100644
--- a/board/ti/dra7xx/mux_data.h
+++ b/board/ti/dra7xx/mux_data.h
@@ -220,22 +220,6 @@ const struct pad_conf_entry 
dra72x_rgmii_padconf_array_revc[] = {
 };
 
 const struct pad_conf_entry dra71x_core_padconf_array[] = {
-   {GPMC_AD0, (M3 | PIN_INPUT)},   /* gpmc_ad0.vout3_d0 */
-   {GPMC_AD1, (M3 | PIN_INPUT)},   /* gpmc_ad1.vout3_d1 */
-   {GPMC_AD2, (M3 | PIN_INPUT)},   /* gpmc_ad2.vout3_d2 */
-   {GPMC_AD3, (M3 | PIN_INPUT)},   /* gpmc_ad3.vout3_d3 */
-   {GPMC_AD4, (M3 | PIN_INPUT)},   /* gpmc_ad4.vout3_d4 */
-   {GPMC_AD5, (M3 | PIN_INPUT)},   /* gpmc_ad5.vout3_d5 */
-   {GPMC_AD6, (M3 | PIN_INPUT)},   /* gpmc_ad6.vout3_d6 */
-   {GPMC_AD7, (M3 | PIN_INPUT)},   /* gpmc_ad7.vout3_d7 */
-   {GPMC_AD8, (M3 | PIN_INPUT)},   /* gpmc_ad8.vout3_d8 */
-   {GPMC_AD9, (M3 | PIN_INPUT)},   /* gpmc_ad9.vout3_d9 */
-   {GPMC_AD10, (M3 | PIN_INPUT)},  /* gpmc_ad10.vout3_d10 */
-   {GPMC_AD11, (M3 | PIN_INPUT)},  /* gpmc_ad11.vout3_d11 */
-   {GPMC_AD12, (M3 | PIN_INPUT)},  /* gpmc_ad12.vout3_d12 */
-   {GPMC_AD13, (M3 | PIN_INPUT)},  /* gpmc_ad13.vout3_d13 */
-   {GPMC_AD14, (M3 | PIN_INPUT)},  /* gpmc_ad14.vout3_d14 */
-   {GPMC_AD15, (M3 | PIN_INPUT)},  /* gpmc_ad15.vout3_d15 */
{GPMC_A0, (M3 | PIN_INPUT_PULLDOWN)},   /* gpmc_a0.vout3_d16 */
{GPMC_A1, (M3 | PIN_INPUT_PULLDOWN)},   /* gpmc_a1.vout3_d17 */
{GPMC_A2, (M3 | PIN_INPUT_PULLDOWN)},   /* gpmc_a2.vout3_d18 */
@@ -370,6 +354,50 @@ const struct pad_conf_entry dra71x_core_padconf_array[] = {
{WAKEUP3, (M1 | PULL_ENA | PULL_UP)},   /* Wakeup3.sys_nirq1 */
 };
 
+const struct pad_conf_entry dra71x_vout3_padconf_array[] = {
+   {GPMC_AD0, (M3 | PIN_INPUT)},   /* gpmc_ad0.vout3_d0 */
+   {GPMC_AD1, (M3 | PIN_INPUT)},   /* gpmc_ad1.vout3_d1 */
+   {GPMC_AD2, (M3 | PIN_INPUT)},   /* gpmc_ad2.vout3_d2 */
+   {GPMC_AD3, (M3 | PIN_INPUT)},   /* gpmc_ad3.vout3_d3 */
+   {GPMC_AD4, (M3 | PIN_INPUT)},   /* gpmc_ad4.vout3_d4 */
+   {GPMC_AD5, (M3 | PIN_INPUT)},   /* gpmc_ad5.vout3_d5 */
+   {GPMC_AD6, (M3 | PIN_INPUT)},   /* gpmc_ad6.vout3_d6 */
+   {GPMC_AD7, (M3 | PIN_INPUT)},   /* gpmc_ad7.vout3_d7 */
+   {GPMC_AD8, (M3 | PIN_INPUT)},   /* gpmc_ad8.vout3_d8 */
+   {GPMC_AD9, (M3 | PIN_INPUT)},   /* gpmc_ad9.vout3_d9 */
+   {GPMC_AD10, (M3 | PIN_INPUT)},  /* gpmc_ad10.vout3_d10 */
+   {GPMC_AD11, (M3 | PIN_INPUT)},  /* gpmc_ad11.vout3_d11 */
+   {GPMC_AD12, (M3 | PIN_INPUT)},  /* gpmc_ad12.vout3_d12 */
+   {GPMC_AD13, (M3 | PIN_INPUT)},  /* gpmc_ad13.vout3_d13 */
+   {GPMC_AD14, (M3 | PIN_INPUT)},  /* gpmc_ad14.vout3_d14 */
+   {GPMC_AD15, (M3 | PIN_INPUT)},  /* gpmc_ad15.vout3_d15 */
+};
+
+const struct pad_conf_entry dra71x_nand_padconf_array[] = {
+   {GPMC_AD0, (M0 | PIN_INPUT)},   /* gpmc_ad0.gpmc_ad0 */
+   {GPMC_AD1, (M0 | PIN_INPUT)},   /* gpmc_ad1.gpmc_ad1 */
+   {GPMC_AD2, (M0 | PIN_INPUT)},   /* gpmc_ad2.gpmc_ad2 */
+   {GPMC_AD3, (M0 | PIN_INPUT)},   /* gpmc_ad3.gpmc_ad3 */
+   {GPMC_AD4, (M0 | PIN_INPUT)},   /* gpmc_ad4.gpmc_ad4 */
+   {GPMC_AD5, (M0 | PIN_INPUT)},   /* gpmc_ad5.gpmc_ad5 */
+   {GPMC_AD6, (M0 | PIN_INPUT)},   /* gpmc_ad6.gpmc_ad6 */
+   {GPMC_AD7, (M0 | PIN_INPUT)},   /* gpmc_ad7.gpmc_ad7 */
+   {GPMC_AD8, (M0 | PIN_INPUT)},   /* gpmc_ad8.gpmc_ad8 */
+   {GPMC_AD9, (M0 | PIN_INPUT)},   /* gpmc_ad9.gpmc_ad9 */
+   {GPMC_AD10, (M0 | PIN_INPUT)},  /* gpmc_ad10.gpmc_ad10 */
+   {GPMC_AD11, (M0 | PIN_INPUT)},  /* gpmc_ad11.gpmc_ad11 */
+   {GPMC_AD12, (M0 | PIN_INPUT)},  /* gpmc_ad12.gpmc_ad12 */
+   {GPMC_AD13, (M0 | PIN_INPUT)},  /* gpmc_ad13.gpmc_ad13 */
+   {GPMC_AD14, (M0 | PIN_INPUT)},  /* gpmc_ad14.gpmc_ad14 */
+   {GPMC_AD15, (M0 | PIN_INPUT)},  /* gpmc_ad15.gpmc_ad15 */
+   {GPMC_CS0, (M0 | PIN_INPUT_PULLUP)},/* gpmc_cs0.gpmc_cs0 */
+   {GPMC_ADVN_ALE, (M0 | PIN_INPUT_PULLDOWN)}, /* 
gpmc_advn_ale.gpmc_advn_ale */
+   {GPMC_OEN_REN, (M0 | PIN_INPUT_PULLUP)},/* 
gpmc_oen_ren.gpmc_oen_ren */
+   {GPMC_WEN, (M0 | PIN_INPUT_PULLUP)},/* gpmc_wen.gpmc_wen */
+   {GPMC_BEN0, (M0 | PIN_INPUT_PULLDOWN)}, /* gpmc_ben0.gpmc_ben0 */
+   {GPMC_WAIT0, (M0 | PIN_INPUT_PULLUP | SLEWCONTROL)},/* 

Re: [U-Boot] [PATCH 4/4] configs: ti_omap5_common: Add NAND environment settings

[Faiz Abbas]

Hi Tom,

On 22/02/19 4:52 AM, Tom Rini wrote:
> On Wed, Feb 20, 2019 at 03:34:53PM +0530, Faiz Abbas wrote:
> 
>> Now that NAND is supported on DRA71x include various NAND environment
>> settings
>>
>> Signed-off-by: Faiz Abbas 
> [snip]
>> +#ifdef CONFIG_NAND
>> +#define NANDARGS \
>> +"mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \
>> +"mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
>> +"nandargs=setenv bootargs console=${console} " \
>> +"${optargs} " \
>> +"root=${nandroot} " \
>> +"rootfstype=${nandrootfstype}\0" \
>> +"nandroot=ubi0:rootfs rw ubi.mtd=NAND.file-system,2048\0" \
>> +"nandrootfstype=ubifs rootwait=1\0" \
>> +"nandboot=echo Booting from nand ...; " \
>> +"run nandargs; " \
>> +"nand read ${fdtaddr} NAND.u-boot-spl-os; " \
>> +"nand read ${loadaddr} NAND.kernel; " \
>> +"bootz ${loadaddr} - ${fdtaddr}\0"
>> +#else
>> +#define NANDARGS ""
>> +#endif
> 
> This kind of stuff needs to fit into include/environment/ti/ somehow,
> not added to, thanks!
> 

Ok. I will create an environment/ti/nand.h

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

Re: [U-Boot] [PATCH v2 5/5] cmd: run: add "-e" option to run an EFI application

[Heinrich Schuchardt]

On 2/27/19 7:37 AM, AKASHI Takahiro wrote:
> On Wed, Feb 27, 2019 at 07:25:52AM +0100, Heinrich Schuchardt wrote:
>> On 2/27/19 7:12 AM, AKASHI Takahiro wrote:
>>> On Tue, Feb 26, 2019 at 08:20:10PM +0100, Heinrich Schuchardt wrote:
 On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> "run -e" allows for executing EFI application with a specific "Boot"
> variable. If no "Boot" is specified or "BootOrder" is specified,
> it tries to run an EFI application specified in the order of "bootOrder."
>

 If we cannot specify the device tree what would be the use of this for
 ARM processors?
>>>
>>> I don't get your point. What's the matter with device tree?
>>
>> To boot an ARM board on Linux or BSD you need a device tree.
> 
> When I discussed with Alex about Boot Manager (and distro_bootcmd?),
> he suggested that we should not allow users to specify fdt at a command line.
> I believe that it would apply to my case above.
> 
> IMO, we should always provide system's fdt to EFI applications.

With current Linux development practice this unfortunately does not
work. Linux device trees sometimes see incompatible changes between
versions. Booting may fail with a device tree that is either too old or
too new for your Linux version.

E.g. for the Odroid C2 some reserved memory regions were removed from
the device tree and replaced by a logic that determines them on the fly
due to changes in ARM trusted firmware location.

The Wandboard rev B1 device tree was moved to a new file when a new
board revision appeared and the new revision changed the old file (sic).

U-Boot is also not perfect at keeping its device tree in sync with the
newest Linux device tree.

> 
>> So run -e Boot0001 will not allow you to boot into Linux because it does
>> not specify a device tree.
>>
>>>
>>>
 Why do you add the option to run and not to bootefi?

 You already introduced the capability to set BootNext. Why isn't that
 enough?
>>>
>>> Simple.
>>>
>>> => run -e Boot00>
>>> versus
>>>
>>> => efidebug boot next 1
>>> => bootefi bootmgr
>>
>> In patch 4/5 you already introduced 'bootefi bootmgr $fdt_addr_r 0001'
>>
>> So there is no need to go through efidebug.
>>
>> I think we should avoid alternative commands.
> 
> As I said, I already removed this feature from bootefi.
> 
>>>
>>> First of all, efidebug is only recognized as a *debugging* tool.
>>> I believe that the former syntax is more intuitive, and it looks
>>> a natural extension to "run" command semantics akin to "env -e".
>>>
>>> As a result, we don't have to know about bootefi for normal operations.
>>
>> But you have to know about 'run' which you might not need otherwise.
> 
> "run" is much better known to U-Boot users than bootefi.

Do you have a statistic ;)

Up to now booting always required a command starting on boot...

Best regards

Heinrich

> 
> Thanks,
> -Takahiro Akashi
> 
>> Best regards
>>
>> Heinrich
>>
>>>
>>> Thanks,
>>> -Takahiro Akashi
>>>
>>>
 Best regards

 Heinrich

> Signed-off-by: AKASHI Takahiro 
> ---
>  cmd/bootefi.c | 31 +++
>  cmd/nvedit.c  |  9 -
>  common/cli.c  | 10 ++
>  include/command.h |  3 +++
>  4 files changed, 52 insertions(+), 1 deletion(-)
>
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 241fd0f987ab..ebe149dffa1f 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -492,6 +492,37 @@ static int do_bootefi_bootmgr_exec(int boot_id)
>   return CMD_RET_SUCCESS;
>  }
>  
> +/* Called by "run" command */
> +int do_bootefi_run(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> argv[])
> +{
> + int boot_id = -1;
> + char *endp;
> +
> + if (argc > 2)
> + return CMD_RET_USAGE;
> +
> + if (argc == 2) {
> + if (!strcmp(argv[1], "BootOrder")) {
> + boot_id = -1;
> + } else if (!strncmp(argv[2], "Boot", 4)) {
> + boot_id = (int)simple_strtoul([2][4], , 0);
> + if ((argv[2] + strlen(argv[2]) != endp) ||
> + boot_id > 0x)
> + return CMD_RET_USAGE;
> + } else {
> + return CMD_RET_USAGE;
> + }
> + }
> +
> + if (efi_init_obj_list())
> + return CMD_RET_FAILURE;
> +
> + if (efi_handle_fdt(NULL))
> + return CMD_RET_FAILURE;
> +
> + return do_bootefi_bootmgr_exec(boot_id);
> +}
> +
>  /* Interpreter command to boot an arbitrary EFI image from memory */
>  static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> argv[])
>  {
> diff --git a/cmd/nvedit.c b/cmd/nvedit.c
> index de16c72c23f2..ce746bbf1b3e 100644
> --- a/cmd/nvedit.c
> +++ b/cmd/nvedit.c
> @@ -1344,7 +1344,14 @@ U_BOOT_CMD_COMPLETE(
>   run,

Re: [U-Boot] [PATCH] drivers: net: ldpaa_eth: check if the dpmac is enabled

[Pankaj Bansal]

Hi Joe,

Can you please check and ACK this patch?
This patch is related to http://patchwork.ozlabs.org/patch/990131/

Regards,
Pankaj Bansal

> -Original Message-
> From: Prabhakar Kushwaha
> Sent: Monday, 11 February, 2019 03:19 PM
> To: Pankaj Bansal ; Joe Hershberger
> 
> Cc: u-boot@lists.denx.de
> Subject: RE: [PATCH] drivers: net: ldpaa_eth: check if the dpmac is enabled
> 
> Dear Joe,
> 
> > -Original Message-
> > From: Pankaj Bansal
> > Sent: Friday, February 8, 2019 2:29 PM
> > To: Prabhakar Kushwaha 
> > Cc: u-boot@lists.denx.de; Pankaj Bansal 
> > Subject: [PATCH] drivers: net: ldpaa_eth: check if the dpmac is
> > enabled
> >
> > some dpmacs in armv8a based freescale layerscape SOCs can be
> > configured via both serdes(sgmii, xfi, xlaui etc) bits and via
> > EC*_PMUX(rgmii) bits in RCW.
> > e.g. dpmac 17 and 18 in LX2160A can be configured as SGMII from serdes
> > bits and as RGMII via EC1_PMUX/EC2_PMUX bits Now if a dpmac is enabled
> > by serdes bits then it takes precedence over EC*_PMUX bits. i.e. in
> > LX2160A if we select serdes protocol that configures dpmac17 as SGMII
> > and set the EC1_PMUX as RGMII, then the dpmac is SGMII and not RGMII.
> >
> > Therefore, in fsl_rgmii_init function of SOC, we will check if the
> > dpmac is enabled or not? if it is (fsl_serdes_init has already enabled
> > the dpmac), then don't enable it.
> >
> > Signed-off-by: Pankaj Bansal 
> > ---
> >
> > Notes:
> > Dependencies:
> > - http://patchwork.ozlabs.org/patch/990131/
> > - http://patchwork.ozlabs.org/patch/990093/
> >
> >  drivers/net/ldpaa_eth/lx2160a.c | 4 ++--
> 
> Please let me know if you have any concern on this patch.
> 
> I would like pull this patch via u-boot-fsl-qoriq repo..
> 
> --pk

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

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

[AKASHI Takahiro]

On Wed, Feb 27, 2019 at 07:39:50AM +0100, Heinrich Schuchardt wrote:
> On 2/27/19 7:27 AM, AKASHI Takahiro wrote:
> > On Wed, Feb 27, 2019 at 07:14:10AM +0100, Heinrich Schuchardt wrote:
> >> On 2/27/19 6:47 AM, AKASHI Takahiro wrote:
> >>> On Tue, Feb 26, 2019 at 07:57:26PM +0100, Heinrich Schuchardt wrote:
>  On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> > See UEFI v2.7, section 3.1.2 for details of the specification.
> >
> > With my efitool command, you can try as the following:
> >   => 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 ...)
> >   => efi dumpvar
> >   
> >   BootCurrent: {boot,run}(blob)
> >   :  02 00..
> >   BootOrder: {boot,run}(blob)
> >   :  01 00 02 00  
> >
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  lib/efi_loader/efi_bootmgr.c | 34 +-
> >  1 file changed, 33 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> > index a095df3f540b..6c5303736dc6 100644
> > --- a/lib/efi_loader/efi_bootmgr.c
> > +++ b/lib/efi_loader/efi_bootmgr.c
> > @@ -145,11 +145,21 @@ 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",
> >   __func__, lo.label, lo.file_path);
> >  
> > +   attributes = EFI_VARIABLE_BOOTSERVICE_ACCESS |
> > +EFI_VARIABLE_RUNTIME_ACCESS;
> > +   size = sizeof(n);
> > +   ret = rs->set_variable(L"BootCurrent",
> > +  (efi_guid_t 
> > *)_global_variable_guid,
> 
>  Use EFI_CALL().
> >>>
> >>> Okay
> >>> But as I said somewhere else, it's quite annoying to me that
> >>> some efi_xxx requires EFI_CALL(), and others not.
> >>> There should have been consistent naming rules.
> >>
> >> We started with having separate functions like efi_allocate_pages_ext()
> >> and efi_allocate_pages(). Then Rob Clark came along and introduced
> >> EFI_CALL() in a095aadffa96 and I stopped creating _ext() functions.
> >>
> >> When running with DEBUG 1 it sometimes is helpful to see which function
> >> is calling which other and where errors are originally reported.
> >>
> >> But I am open to changes in this area.
> >>
> >>>
>  Instead of dereferencing you could directly call
>  efi_set_variable().
> >>>
> >>> Yeah, given that this code is under lib/efi_loader, it may be natural
> >>> to use efi_set_variable(). But existing get_var() uses the same style of 
> >>> coding.
> >>>
> >>> Do you want to change all of the call sites including get_var()?
> >>
> >> Calling efi_set_variable() directly uses less bytes of code than
> >> rs->get_variable() which makes it preferable.
> > 
> > So is your answer yes, or no?
> 
> I would prefer calling efi_get_variable() directly and not to use
> rs->get_variable().

My point is "including get_var()" or not.
I have never touched that function in my patch.

> > 
> >> I have seen that iPXE modifies system->boottime to intercept system
> >> calls. The same could be done by an EFI driver to the runtime vectors.
> >>
> >> In the light of your work on secure boot I think we should not allow an
> >> EFI driver to intercept the reading and changing of variables here.
> >>
> >> We should also rethink it for efidebug.c
> > 
> > I'm not sure about your concern here, but no doubt efidebug should
> > be disabled on production system with secure boot.
> 
> Also in efidebug we are creating more runtime code bytes than needed by
> using system->runtime->efi_something() or system->boottime->efi_something().

I think we discussed in the past.
I prefer to calling boot time/run time services via system table
as this command is expected to be implemented as an (embedded) EFI application
sometime in the future.

Thanks,
-Takahiro Akashi

> Best regards
> 
> Heinrich
> 
> > 
> > Thanks,
> > -Takahiro Akashi
> > 
> >> Best regards
> >>
> >> Heinrich
> >>
> >>>
> > +  attributes, size, );
> > +   if (ret != EFI_SUCCESS)
> > +   goto error;
> > +
> > ret = efi_load_image_from_path(lo.file_path, );
> >  
> > if (ret != EFI_SUCCESS)
> > @@ -173,16 +183,38 @@ error:
> >  void *efi_bootmgr_load(struct efi_device_path **device_path,
> >

Re: [U-Boot] [PATCH v2 4/5] cmd: bootefi: run an EFI application of a specific load option

[AKASHI Takahiro]

On Wed, Feb 27, 2019 at 07:31:06AM +0100, Heinrich Schuchardt wrote:
> On 2/27/19 6:58 AM, AKASHI Takahiro wrote:
> > On Tue, Feb 26, 2019 at 08:30:50PM +0100, Heinrich Schuchardt wrote:
> >> On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> >>> With this patch applied, we will be able to selectively execute
> >>> an EFI application by specifying a load option, say "1" for Boot0001,
> >>> "2" for Boot0002 and so on.
> >>>
> >>>   => bootefi bootmgr  1, or
> >>>  bootefi bootmgr - 1
> >>
> >> You already introduced the support for BootNext. So is there a real 
> >> benefit?
> > 
> > This is a convenient way of running EFI application directly,
> > but I already removed this feature from the next version.
> 
> Please, remove 'run -e' instead because it cannot specify the device
> tree needed for booting ARM boards.

See my comment for patch#5 first.

> > 
> >>>
> >>> Please note that Boot need not be included in "BootOrder".
> >>>
> >>> Signed-off-by: AKASHI Takahiro 
> >>> ---
> >>>  cmd/bootefi.c | 39 ---
> >>>  1 file changed, 28 insertions(+), 11 deletions(-)
> >>>
> >>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> >>> index 3be01b49b589..241fd0f987ab 100644
> >>> --- a/cmd/bootefi.c
> >>> +++ b/cmd/bootefi.c
> >>> @@ -471,16 +471,15 @@ static efi_status_t bootefi_test_prepare
> >>>  
> >>>  #endif /* CONFIG_CMD_BOOTEFI_SELFTEST */
> >>>  
> >>> -static int do_bootefi_bootmgr_exec(void)
> >>> +static int do_bootefi_bootmgr_exec(int boot_id)
> >>>  {
> >>>   struct efi_device_path *device_path, *file_path;
> >>>   void *addr;
> >>>   efi_status_t r;
> >>>  
> >>> - addr = efi_bootmgr_load(EFI_BOOTMGR_DEFAULT_ORDER,
> >>> - _path, _path);
> >>> + addr = efi_bootmgr_load(boot_id, _path, _path);
> >>>   if (!addr)
> >>> - return 1;
> >>> + return CMD_RET_FAILURE;
> >>>  
> >>>   printf("## Starting EFI application at %p ...\n", addr);
> >>>   r = do_bootefi_exec(addr, device_path, file_path);
> >>> @@ -488,9 +487,9 @@ static int do_bootefi_bootmgr_exec(void)
> >>>  r & ~EFI_ERROR_MASK);
> >>>  
> >>>   if (r != EFI_SUCCESS)
> >>> - return 1;
> >>> + return CMD_RET_FAILURE;
> >>>  
> >>> - return 0;
> >>> + return CMD_RET_SUCCESS;
> >>>  }
> >>>  
> >>>  /* Interpreter command to boot an arbitrary EFI image from memory */
> >>> @@ -546,10 +545,28 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, 
> >>> int argc, char * const argv[])
> >>>   } else
> >>>  #endif
> >>>   if (!strcmp(argv[1], "bootmgr")) {
> >>> - if (efi_handle_fdt(argc > 2 ? argv[2] : NULL))
> >>> - return CMD_RET_FAILURE;
> >>> + char *fdtstr, *endp;
> >>> + int boot_id = EFI_BOOTMGR_DEFAULT_ORDER;
> >>> +
> >>> + if (argc > 2) {
> >>> + fdtstr = argv[2];
> >>> +  /* Special address "-" means no device tree */
> >>> + if (fdtstr[0] == '-')
> >>> + fdtstr = NULL;
> >>> +
> >>> + r = efi_handle_fdt(fdtstr);
> >>> + if (r)
> >>> + return CMD_RET_FAILURE;
> >>> + }
> >>> +
> >>> + if (argc > 3) {
> >>> + boot_id = (int)simple_strtoul(argv[3], , 0);
> >>> + if ((argv[3] + strlen(argv[3]) != endp) ||
> >>> + boot_id > 0x)
> >>> + return CMD_RET_USAGE;
> >>> + }
> >>>  
> >>> - return do_bootefi_bootmgr_exec();
> >>> + return do_bootefi_bootmgr_exec(boot_id);
> >>
> >> Why not communicate via the BootNext variable?
> > 
> > I don't get your point.
> > BootNext and BootOrder are both defined by UEFI specification.
> 
> Instead of changing the interface of do_bootefi_bootmgr_exec()

Who care changing an *internal* function?

> you could
> simply set BootNext. Then the boot manager would pick up the option from
> the variable and finally delete the variable. This would result in less
> code.

No. Even with "run -e," BootNext will disappear after execution.
This is a requirement by UEFI spec.

Thanks,
-Takahiro Akashi

> Best regards
> 
> Heinrich
> 
> > 
> >>>   } else {
> >>>   saddr = argv[1];
> >>>  
> >>> @@ -590,7 +607,7 @@ static char bootefi_help_text[] =
> >>>   "Use environment variable efi_selftest to select a single test.\n"
> >>>   "Use 'setenv efi_selftest list' to enumerate all tests.\n"
> >>>  #endif
> >>> - "bootefi bootmgr [fdt addr]\n"
> >>> + "bootefi bootmgr [|'-' []]\n"
> >>>   "  - load and boot EFI payload based on BootOrder/Boot variables.\n"
> >>>   "\n"
> >>>   "If specified, the device tree located at  gets\n"
> >>> @@ -598,7 +615,7 @@ static char bootefi_help_text[] =
> >>>  #endif
> >>>  
> >>>  U_BOOT_CMD(
> >>> - bootefi, 3, 0, do_bootefi,
> >>> + bootefi, 5, 0, do_bootefi,
> >>
> >> Why 5?
> > 
> > For additional/optional '-' and .
> > But I removed this feature from bootefi.
> > 
> > Thanks,
> > 

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

[Heinrich Schuchardt]

On 2/27/19 7:27 AM, AKASHI Takahiro wrote:
> On Wed, Feb 27, 2019 at 07:14:10AM +0100, Heinrich Schuchardt wrote:
>> On 2/27/19 6:47 AM, AKASHI Takahiro wrote:
>>> On Tue, Feb 26, 2019 at 07:57:26PM +0100, Heinrich Schuchardt wrote:
 On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> See UEFI v2.7, section 3.1.2 for details of the specification.
>
> With my efitool command, you can try as the following:
>   => 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 ...)
>   => efi dumpvar
>   
>   BootCurrent: {boot,run}(blob)
>   :  02 00..
>   BootOrder: {boot,run}(blob)
>   :  01 00 02 00  
>
> Signed-off-by: AKASHI Takahiro 
> ---
>  lib/efi_loader/efi_bootmgr.c | 34 +-
>  1 file changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> index a095df3f540b..6c5303736dc6 100644
> --- a/lib/efi_loader/efi_bootmgr.c
> +++ b/lib/efi_loader/efi_bootmgr.c
> @@ -145,11 +145,21 @@ 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",
> __func__, lo.label, lo.file_path);
>  
> + attributes = EFI_VARIABLE_BOOTSERVICE_ACCESS |
> +  EFI_VARIABLE_RUNTIME_ACCESS;
> + size = sizeof(n);
> + ret = rs->set_variable(L"BootCurrent",
> +(efi_guid_t *)_global_variable_guid,

 Use EFI_CALL().
>>>
>>> Okay
>>> But as I said somewhere else, it's quite annoying to me that
>>> some efi_xxx requires EFI_CALL(), and others not.
>>> There should have been consistent naming rules.
>>
>> We started with having separate functions like efi_allocate_pages_ext()
>> and efi_allocate_pages(). Then Rob Clark came along and introduced
>> EFI_CALL() in a095aadffa96 and I stopped creating _ext() functions.
>>
>> When running with DEBUG 1 it sometimes is helpful to see which function
>> is calling which other and where errors are originally reported.
>>
>> But I am open to changes in this area.
>>
>>>
 Instead of dereferencing you could directly call
 efi_set_variable().
>>>
>>> Yeah, given that this code is under lib/efi_loader, it may be natural
>>> to use efi_set_variable(). But existing get_var() uses the same style of 
>>> coding.
>>>
>>> Do you want to change all of the call sites including get_var()?
>>
>> Calling efi_set_variable() directly uses less bytes of code than
>> rs->get_variable() which makes it preferable.
> 
> So is your answer yes, or no?

I would prefer calling efi_get_variable() directly and not to use
rs->get_variable().

> 
>> I have seen that iPXE modifies system->boottime to intercept system
>> calls. The same could be done by an EFI driver to the runtime vectors.
>>
>> In the light of your work on secure boot I think we should not allow an
>> EFI driver to intercept the reading and changing of variables here.
>>
>> We should also rethink it for efidebug.c
> 
> I'm not sure about your concern here, but no doubt efidebug should
> be disabled on production system with secure boot.

Also in efidebug we are creating more runtime code bytes than needed by
using system->runtime->efi_something() or system->boottime->efi_something().

Best regards

Heinrich

> 
> Thanks,
> -Takahiro Akashi
> 
>> Best regards
>>
>> Heinrich
>>
>>>
> +attributes, size, );
> + if (ret != EFI_SUCCESS)
> + goto error;
> +
>   ret = efi_load_image_from_path(lo.file_path, );
>  
>   if (ret != EFI_SUCCESS)
> @@ -173,16 +183,38 @@ error:
>  void *efi_bootmgr_load(struct efi_device_path **device_path,
>  struct efi_device_path **file_path)
>  {
> - uint16_t *bootorder;
> + u16 bootnext, *bootorder;
>   efi_uintn_t size;
>   void *image = NULL;
>   int i, num;
> + efi_status_t ret;
>  
>   __efi_entry_check();
>  
>   bs = systab.boottime;
>   rs = systab.runtime;
>  
> + /* get BootNext */
> + size = sizeof(bootnext);
> + ret = rs->get_variable(L"BootNext",
> +(efi_guid_t *)_global_variable_guid,
> +NULL, , );

 You could call efi_get_variable() directly instead of dereferencing rs.
 But anyway you have to use EFI_CALL().
>>>
>>> Ditto
>>>
> + if (!bootnext)
> + goto run_list;

 

Re: [U-Boot] [PATCH v2 5/5] cmd: run: add "-e" option to run an EFI application

[AKASHI Takahiro]

On Wed, Feb 27, 2019 at 07:25:52AM +0100, Heinrich Schuchardt wrote:
> On 2/27/19 7:12 AM, AKASHI Takahiro wrote:
> > On Tue, Feb 26, 2019 at 08:20:10PM +0100, Heinrich Schuchardt wrote:
> >> On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> >>> "run -e" allows for executing EFI application with a specific "Boot"
> >>> variable. If no "Boot" is specified or "BootOrder" is specified,
> >>> it tries to run an EFI application specified in the order of "bootOrder."
> >>>
> >>
> >> If we cannot specify the device tree what would be the use of this for
> >> ARM processors?
> > 
> > I don't get your point. What's the matter with device tree?
> 
> To boot an ARM board on Linux or BSD you need a device tree.

When I discussed with Alex about Boot Manager (and distro_bootcmd?),
he suggested that we should not allow users to specify fdt at a command line.
I believe that it would apply to my case above.

IMO, we should always provide system's fdt to EFI applications.

> So run -e Boot0001 will not allow you to boot into Linux because it does
> not specify a device tree.
> 
> > 
> > 
> >> Why do you add the option to run and not to bootefi?
> >>
> >> You already introduced the capability to set BootNext. Why isn't that
> >> enough?
> > 
> > Simple.
> > 
> > => run -e Boot00>
> > versus
> > 
> > => efidebug boot next 1
> > => bootefi bootmgr
> 
> In patch 4/5 you already introduced 'bootefi bootmgr $fdt_addr_r 0001'
> 
> So there is no need to go through efidebug.
> 
> I think we should avoid alternative commands.

As I said, I already removed this feature from bootefi.

> > 
> > First of all, efidebug is only recognized as a *debugging* tool.
> > I believe that the former syntax is more intuitive, and it looks
> > a natural extension to "run" command semantics akin to "env -e".
> > 
> > As a result, we don't have to know about bootefi for normal operations.
> 
> But you have to know about 'run' which you might not need otherwise.

"run" is much better known to U-Boot users than bootefi.

Thanks,
-Takahiro Akashi

> Best regards
> 
> Heinrich
> 
> > 
> > Thanks,
> > -Takahiro Akashi
> > 
> > 
> >> Best regards
> >>
> >> Heinrich
> >>
> >>> Signed-off-by: AKASHI Takahiro 
> >>> ---
> >>>  cmd/bootefi.c | 31 +++
> >>>  cmd/nvedit.c  |  9 -
> >>>  common/cli.c  | 10 ++
> >>>  include/command.h |  3 +++
> >>>  4 files changed, 52 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> >>> index 241fd0f987ab..ebe149dffa1f 100644
> >>> --- a/cmd/bootefi.c
> >>> +++ b/cmd/bootefi.c
> >>> @@ -492,6 +492,37 @@ static int do_bootefi_bootmgr_exec(int boot_id)
> >>>   return CMD_RET_SUCCESS;
> >>>  }
> >>>  
> >>> +/* Called by "run" command */
> >>> +int do_bootefi_run(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> >>> argv[])
> >>> +{
> >>> + int boot_id = -1;
> >>> + char *endp;
> >>> +
> >>> + if (argc > 2)
> >>> + return CMD_RET_USAGE;
> >>> +
> >>> + if (argc == 2) {
> >>> + if (!strcmp(argv[1], "BootOrder")) {
> >>> + boot_id = -1;
> >>> + } else if (!strncmp(argv[2], "Boot", 4)) {
> >>> + boot_id = (int)simple_strtoul([2][4], , 0);
> >>> + if ((argv[2] + strlen(argv[2]) != endp) ||
> >>> + boot_id > 0x)
> >>> + return CMD_RET_USAGE;
> >>> + } else {
> >>> + return CMD_RET_USAGE;
> >>> + }
> >>> + }
> >>> +
> >>> + if (efi_init_obj_list())
> >>> + return CMD_RET_FAILURE;
> >>> +
> >>> + if (efi_handle_fdt(NULL))
> >>> + return CMD_RET_FAILURE;
> >>> +
> >>> + return do_bootefi_bootmgr_exec(boot_id);
> >>> +}
> >>> +
> >>>  /* Interpreter command to boot an arbitrary EFI image from memory */
> >>>  static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> >>> argv[])
> >>>  {
> >>> diff --git a/cmd/nvedit.c b/cmd/nvedit.c
> >>> index de16c72c23f2..ce746bbf1b3e 100644
> >>> --- a/cmd/nvedit.c
> >>> +++ b/cmd/nvedit.c
> >>> @@ -1344,7 +1344,14 @@ U_BOOT_CMD_COMPLETE(
> >>>   run,CONFIG_SYS_MAXARGS, 1,  do_run,
> >>>   "run commands in an environment variable",
> >>>   "var [...]\n"
> >>> - "- run the commands in the environment variable(s) 'var'",
> >>> + "- run the commands in the environment variable(s) 'var'"
> >>> +#if defined(CONFIG_CMD_BOOTEFI)
> >>> + "\n"
> >>> + "run -e [Boot]\n"
> >>> + "- load and run UEFI app based on 'Boot' UEFI variable",
> >>> +#else
> >>> + ,
> >>> +#endif
> >>>   var_complete
> >>>  );
> >>>  #endif
> >>> diff --git a/common/cli.c b/common/cli.c
> >>> index 51b8d5f85cbb..fbb09d5049a4 100644
> >>> --- a/common/cli.c
> >>> +++ b/common/cli.c
> >>> @@ -12,6 +12,7 @@
> >>>  #include 
> >>>  #include 
> >>>  #include 
> >>> +#include 
> >>>  #include 
> >>>  #include 
> >>>  
> >>> @@ -125,6 +126,15 @@ int do_run(cmd_tbl_t *cmdtp, int flag, int argc, 
> >>> char * const argv[])
> >>>   if 

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

[Chee, Tien Fong]

On Tue, 2019-02-26 at 07:58 -0800, Dalon L Westergreen wrote:
> On Tue, 2019-02-26 at 16:42 +0100, Michal Simek wrote:
> > 
> > On 26. 02. 19 15:28, Chee, Tien Fong wrote:
> > > 
> > > On Tue, 2019-02-26 at 15:06 +0100, Michal Simek wrote:
> > > > 
> > > > On 19. 02. 19 4:47, 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 
> > > > > 
> > > > > ---
> > > > > 
> > > > > changes for v8
> > > > > - Removed explanation about support for altr,bitstream-core
> > > > > 
> > > > > changes for v7
> > > > > - Provided example of setting FPGA FIT image for both early
> > > > > IO
> > > > > release
> > > > >   and full release FPGA configuration.
> > > > > ---
> > > > >  .../fpga/altera-socfpga-a10-fpga-mgr.txt   | 26
> > > > > +-
> > > > >  1 file changed, 25 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-
> > > > > a10-fpga-
> > > > > mgr.txt b/doc/device-tree-bindings/fpga/altera-socfpga-a10-
> > > > > fpga-
> > > > > mgr.txt
> > > > > index 2fd8e7a..da210bf 100644
> > > > > --- a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-
> > > > > mgr.txt
> > > > > +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-
> > > > > mgr.txt
> > > > > @@ -7,8 +7,31 @@ Required properties:
> > > > > - The second index is for writing FPGA
> > > > > configuration data.
> > > > >  - resets : Phandle and reset specifier for the device's
> > > > > reset.
> > > > >  - clocks : Clocks used by the device.
> > > > > +- altr,bitstream : Fit image file name for both FPGA
> > > > > peripheral
> > > > > bitstream,
> > > > > +    FPGA core bitstream and full bitstream.
> > > > >  
> > > > By adding new required property you are automatically saying
> > > > that you
> > > > want to break all current users.
> > > This is company's product specific property, that's why with
> > > prefix
> > > "altr". DT allows that ,right?
> > no issue with altr prefix. Issue is that you add a required
> > property and
> > breaking all current users.
> > It should be optional.
> This parameter is only for Arria10, which at this point is not fully
> supported
> in mainline uboot.  So this doesnt affect any existing designs, no?

Yeah, how this breaking all current users? This property in only used
for the A10 fpga driver with fit implementation.
> 
> --dalon
> 
> > 
> > 
> > M
> > 
> > 
> > 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v9 3/7] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading

[Chee, Tien Fong]

On Tue, 2019-02-26 at 16:46 +0100, Michal Simek wrote:
> On 26. 02. 19 15:53, Chee, Tien Fong wrote:
> > 
> > On Tue, 2019-02-26 at 15:20 +0100, Michal Simek wrote:
> > > 
> > > On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > Add FPGA driver to support program FPGA with FPGA bitstream
> > > > loading
> > > > from
> > > > filesystem. The driver are designed based on generic firmware
> > > > loader
> > > > framework. The driver can handle FPGA program operation from
> > > > loading FPGA
> > > > bitstream in flash to memory and then to program FPGA.
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > 
> > > > ---
> > > > 
> > > > changes for v9
> > > > - Support data offset
> > > > - Added default DDR load address
> > > > - Squashed the image.h
> > > > - Changed to phandle
> > > > - Ensure the DDR is fully up running by checking the gd->ram
> > > > 
> > > > changes for v8
> > > > - Added codes to discern bitstream type based on fpga node
> > > > name.
> > > > 
> > > > changes for v7
> > > > - Restructure the FPGA driver to support both peripheral
> > > > bitstream
> > > > and core
> > > >   bitstream bundled into FIT image.
> > > > - Support loadable property for core bitstream. User can set
> > > > loadable
> > > >   in DDR for better performance. This loading would be done in
> > > > one
> > > > large
> > > >   chunk instead of chunk by chunk loading with small memory
> > > > buffer.
> > > > ---
> > > >  arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts   |  17 +
> > > >  .../include/mach/fpga_manager_arria10.h|  40 +-
> > > >  drivers/fpga/socfpga_arria10.c | 533
> > > > -
> > > >  include/image.h|   4 +
> > > >  4 files changed, 571 insertions(+), 23 deletions(-)
> > > > 
> > > > diff --git a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > > > b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > > > index 998d811..9d43111 100644
> > > > --- a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > > > +++ b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > > > @@ -18,6 +18,23 @@
> > > >  /dts-v1/;
> > > >  #include "socfpga_arria10_socdk.dtsi"
> > > >  
> > > > +/ {
> > > > +   chosen {
> > > > +   firmware-loader = <_loader0>;
> > > > +   };
> > > > +
> > > > +   fs_loader0: fs-loader@0 {
> > > again @0 without reg properly is wrong.
> > Mind to explain more?
How about fs-loader-0?
> > > 
> > > 
> > > > 
> > > > 
> > > > +   u-boot,dm-pre-reloc;
> > > > +   compatible = "u-boot,fs-loader";
> > > > +   phandlepart = < 1>;
> > > > +   };
> > > I think that this will be nacked by DT guys.
> > > 
> > > > 
> > > > 
> > > > +};
> > > > +
> > > > +_mgr {
> > > > +   u-boot,dm-pre-reloc;
> > > > +   altr,bitstream = "fit_spl_fpga.itb";
> > > > +};
> > > > +
> > > >   {
> > > >     u-boot,dm-pre-reloc;
> > > >     status = "okay";
> > > > diff --git a/arch/arm/mach-
> > > > socfpga/include/mach/fpga_manager_arria10.h b/arch/arm/mach-
> > > > socfpga/include/mach/fpga_manager_arria10.h
> > > > index 09d13f6..7a4f723 100644
> > > > --- a/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
> > > > +++ b/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
> > > > @@ -1,9 +1,13 @@
> > > >  /* SPDX-License-Identifier: GPL-2.0 */
> > > >  /*
> > > > - * Copyright (C) 2017 Intel Corporation 
> > > > + * Copyright (C) 2017-2019 Intel Corporation 
> > > >   * All rights reserved.
> > > >   */
> > > >  
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +
> > > >  #ifndef _FPGA_MANAGER_ARRIA10_H_
> > > >  #define _FPGA_MANAGER_ARRIA10_H_
> > > >  
> > > > @@ -51,6 +55,10 @@
> > > >  #define ALT_FPGAMGR_IMGCFG_CTL_02_CFGWIDTH_SET_MSK 
> > > > BIT(24)
> > > >  #define ALT_FPGAMGR_IMGCFG_CTL_02_CDRATIO_LSB  
> > > > 16
> > > >  
> > > > +#define FPGA_SOCFPGA_A10_RBF_UNENCRYPTED   0xa65c
> > > > +#define FPGA_SOCFPGA_A10_RBF_ENCRYPTED 0xa65d
> > > > +#define FPGA_SOCFPGA_A10_RBF_PERIPH0x0001
> > > > +#define FPGA_SOCFPGA_A10_RBF_CORE  0x8001
> > > >  #ifndef __ASSEMBLY__
> > > >  
> > > >  struct socfpga_fpga_manager {
> > > > @@ -88,12 +96,40 @@ struct socfpga_fpga_manager {
> > > >     u32  imgcfg_fifo_status;
> > > >  };
> > > >  
> > > > +enum rbf_type {
> > > > +   unknown,
> > > > +   periph_section,
> > > > +   core_section
> > > > +};
> > > > +
> > > > +enum rbf_security {
> > > > +   invalid,
> > > > +   unencrypted,
> > > > +   encrypted
> > > > +};
> > > > +
> > > > +struct rbf_info {
> > > > +   enum rbf_type section;
> > > > +   enum rbf_security security;
> > > > +};
> > > > +
> > > > +struct fpga_loadfs_info {
> > > > +   fpga_fs_info *fpga_fsinfo;
> > > > +   u32 remaining;
> > > > +   u32 offset;
> > > > +   struct rbf_info rbfinfo;
> > > > +};

Re: [U-Boot] [PATCH v2 4/5] cmd: bootefi: run an EFI application of a specific load option

[Heinrich Schuchardt]

On 2/27/19 6:58 AM, AKASHI Takahiro wrote:
> On Tue, Feb 26, 2019 at 08:30:50PM +0100, Heinrich Schuchardt wrote:
>> On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
>>> With this patch applied, we will be able to selectively execute
>>> an EFI application by specifying a load option, say "1" for Boot0001,
>>> "2" for Boot0002 and so on.
>>>
>>>   => bootefi bootmgr  1, or
>>>  bootefi bootmgr - 1
>>
>> You already introduced the support for BootNext. So is there a real benefit?
> 
> This is a convenient way of running EFI application directly,
> but I already removed this feature from the next version.

Please, remove 'run -e' instead because it cannot specify the device
tree needed for booting ARM boards.

> 
>>>
>>> Please note that Boot need not be included in "BootOrder".
>>>
>>> Signed-off-by: AKASHI Takahiro 
>>> ---
>>>  cmd/bootefi.c | 39 ---
>>>  1 file changed, 28 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>>> index 3be01b49b589..241fd0f987ab 100644
>>> --- a/cmd/bootefi.c
>>> +++ b/cmd/bootefi.c
>>> @@ -471,16 +471,15 @@ static efi_status_t bootefi_test_prepare
>>>  
>>>  #endif /* CONFIG_CMD_BOOTEFI_SELFTEST */
>>>  
>>> -static int do_bootefi_bootmgr_exec(void)
>>> +static int do_bootefi_bootmgr_exec(int boot_id)
>>>  {
>>> struct efi_device_path *device_path, *file_path;
>>> void *addr;
>>> efi_status_t r;
>>>  
>>> -   addr = efi_bootmgr_load(EFI_BOOTMGR_DEFAULT_ORDER,
>>> -   _path, _path);
>>> +   addr = efi_bootmgr_load(boot_id, _path, _path);
>>> if (!addr)
>>> -   return 1;
>>> +   return CMD_RET_FAILURE;
>>>  
>>> printf("## Starting EFI application at %p ...\n", addr);
>>> r = do_bootefi_exec(addr, device_path, file_path);
>>> @@ -488,9 +487,9 @@ static int do_bootefi_bootmgr_exec(void)
>>>r & ~EFI_ERROR_MASK);
>>>  
>>> if (r != EFI_SUCCESS)
>>> -   return 1;
>>> +   return CMD_RET_FAILURE;
>>>  
>>> -   return 0;
>>> +   return CMD_RET_SUCCESS;
>>>  }
>>>  
>>>  /* Interpreter command to boot an arbitrary EFI image from memory */
>>> @@ -546,10 +545,28 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int 
>>> argc, char * const argv[])
>>> } else
>>>  #endif
>>> if (!strcmp(argv[1], "bootmgr")) {
>>> -   if (efi_handle_fdt(argc > 2 ? argv[2] : NULL))
>>> -   return CMD_RET_FAILURE;
>>> +   char *fdtstr, *endp;
>>> +   int boot_id = EFI_BOOTMGR_DEFAULT_ORDER;
>>> +
>>> +   if (argc > 2) {
>>> +   fdtstr = argv[2];
>>> +/* Special address "-" means no device tree */
>>> +   if (fdtstr[0] == '-')
>>> +   fdtstr = NULL;
>>> +
>>> +   r = efi_handle_fdt(fdtstr);
>>> +   if (r)
>>> +   return CMD_RET_FAILURE;
>>> +   }
>>> +
>>> +   if (argc > 3) {
>>> +   boot_id = (int)simple_strtoul(argv[3], , 0);
>>> +   if ((argv[3] + strlen(argv[3]) != endp) ||
>>> +   boot_id > 0x)
>>> +   return CMD_RET_USAGE;
>>> +   }
>>>  
>>> -   return do_bootefi_bootmgr_exec();
>>> +   return do_bootefi_bootmgr_exec(boot_id);
>>
>> Why not communicate via the BootNext variable?
> 
> I don't get your point.
> BootNext and BootOrder are both defined by UEFI specification.

Instead of changing the interface of do_bootefi_bootmgr_exec() you could
simply set BootNext. Then the boot manager would pick up the option from
the variable and finally delete the variable. This would result in less
code.

Best regards

Heinrich

> 
>>> } else {
>>> saddr = argv[1];
>>>  
>>> @@ -590,7 +607,7 @@ static char bootefi_help_text[] =
>>> "Use environment variable efi_selftest to select a single test.\n"
>>> "Use 'setenv efi_selftest list' to enumerate all tests.\n"
>>>  #endif
>>> -   "bootefi bootmgr [fdt addr]\n"
>>> +   "bootefi bootmgr [|'-' []]\n"
>>> "  - load and boot EFI payload based on BootOrder/Boot variables.\n"
>>> "\n"
>>> "If specified, the device tree located at  gets\n"
>>> @@ -598,7 +615,7 @@ static char bootefi_help_text[] =
>>>  #endif
>>>  
>>>  U_BOOT_CMD(
>>> -   bootefi, 3, 0, do_bootefi,
>>> +   bootefi, 5, 0, do_bootefi,
>>
>> Why 5?
> 
> For additional/optional '-' and .
> But I removed this feature from bootefi.
> 
> Thanks,
> -Takahiro Akashi
> 
> 
>> Best regards
>>
>> Heinrich
>>
>>> "Boots an EFI payload from memory",
>>> bootefi_help_text
>>>  );
>>>
>>
> 

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

Re: [U-Boot] [PATCH v2 5/5] cmd: run: add "-e" option to run an EFI application

[Heinrich Schuchardt]

On 2/27/19 7:12 AM, AKASHI Takahiro wrote:
> On Tue, Feb 26, 2019 at 08:20:10PM +0100, Heinrich Schuchardt wrote:
>> On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
>>> "run -e" allows for executing EFI application with a specific "Boot"
>>> variable. If no "Boot" is specified or "BootOrder" is specified,
>>> it tries to run an EFI application specified in the order of "bootOrder."
>>>
>>
>> If we cannot specify the device tree what would be the use of this for
>> ARM processors?
> 
> I don't get your point. What's the matter with device tree?

To boot an ARM board on Linux or BSD you need a device tree.

So run -e Boot0001 will not allow you to boot into Linux because it does
not specify a device tree.

> 
> 
>> Why do you add the option to run and not to bootefi?
>>
>> You already introduced the capability to set BootNext. Why isn't that
>> enough?
> 
> Simple.
> 
> => run -e Boot00>
> versus
> 
> => efidebug boot next 1
> => bootefi bootmgr

In patch 4/5 you already introduced 'bootefi bootmgr $fdt_addr_r 0001'

So there is no need to go through efidebug.

I think we should avoid alternative commands.

> 
> First of all, efidebug is only recognized as a *debugging* tool.
> I believe that the former syntax is more intuitive, and it looks
> a natural extension to "run" command semantics akin to "env -e".
> 
> As a result, we don't have to know about bootefi for normal operations.

But you have to know about 'run' which you might not need otherwise.

Best regards

Heinrich

> 
> Thanks,
> -Takahiro Akashi
> 
> 
>> Best regards
>>
>> Heinrich
>>
>>> Signed-off-by: AKASHI Takahiro 
>>> ---
>>>  cmd/bootefi.c | 31 +++
>>>  cmd/nvedit.c  |  9 -
>>>  common/cli.c  | 10 ++
>>>  include/command.h |  3 +++
>>>  4 files changed, 52 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>>> index 241fd0f987ab..ebe149dffa1f 100644
>>> --- a/cmd/bootefi.c
>>> +++ b/cmd/bootefi.c
>>> @@ -492,6 +492,37 @@ static int do_bootefi_bootmgr_exec(int boot_id)
>>> return CMD_RET_SUCCESS;
>>>  }
>>>  
>>> +/* Called by "run" command */
>>> +int do_bootefi_run(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
>>> argv[])
>>> +{
>>> +   int boot_id = -1;
>>> +   char *endp;
>>> +
>>> +   if (argc > 2)
>>> +   return CMD_RET_USAGE;
>>> +
>>> +   if (argc == 2) {
>>> +   if (!strcmp(argv[1], "BootOrder")) {
>>> +   boot_id = -1;
>>> +   } else if (!strncmp(argv[2], "Boot", 4)) {
>>> +   boot_id = (int)simple_strtoul([2][4], , 0);
>>> +   if ((argv[2] + strlen(argv[2]) != endp) ||
>>> +   boot_id > 0x)
>>> +   return CMD_RET_USAGE;
>>> +   } else {
>>> +   return CMD_RET_USAGE;
>>> +   }
>>> +   }
>>> +
>>> +   if (efi_init_obj_list())
>>> +   return CMD_RET_FAILURE;
>>> +
>>> +   if (efi_handle_fdt(NULL))
>>> +   return CMD_RET_FAILURE;
>>> +
>>> +   return do_bootefi_bootmgr_exec(boot_id);
>>> +}
>>> +
>>>  /* Interpreter command to boot an arbitrary EFI image from memory */
>>>  static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
>>> argv[])
>>>  {
>>> diff --git a/cmd/nvedit.c b/cmd/nvedit.c
>>> index de16c72c23f2..ce746bbf1b3e 100644
>>> --- a/cmd/nvedit.c
>>> +++ b/cmd/nvedit.c
>>> @@ -1344,7 +1344,14 @@ U_BOOT_CMD_COMPLETE(
>>> run,CONFIG_SYS_MAXARGS, 1,  do_run,
>>> "run commands in an environment variable",
>>> "var [...]\n"
>>> -   "- run the commands in the environment variable(s) 'var'",
>>> +   "- run the commands in the environment variable(s) 'var'"
>>> +#if defined(CONFIG_CMD_BOOTEFI)
>>> +   "\n"
>>> +   "run -e [Boot]\n"
>>> +   "- load and run UEFI app based on 'Boot' UEFI variable",
>>> +#else
>>> +   ,
>>> +#endif
>>> var_complete
>>>  );
>>>  #endif
>>> diff --git a/common/cli.c b/common/cli.c
>>> index 51b8d5f85cbb..fbb09d5049a4 100644
>>> --- a/common/cli.c
>>> +++ b/common/cli.c
>>> @@ -12,6 +12,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  
>>> @@ -125,6 +126,15 @@ int do_run(cmd_tbl_t *cmdtp, int flag, int argc, char 
>>> * const argv[])
>>> if (argc < 2)
>>> return CMD_RET_USAGE;
>>>  
>>> +#ifdef CONFIG_CMD_BOOTEFI
>>> +   if (!strcmp(argv[1], "-e")) {
>>> +   argc--;
>>> +   argv++;
>>> +
>>> +   return do_bootefi_run(cmdtp, flag, argc, argv);
>>> +   }
>>> +#endif
>>> +
>>> for (i = 1; i < argc; ++i) {
>>> char *arg;
>>>  
>>> diff --git a/include/command.h b/include/command.h
>>> index 200c7a5e9f4e..feddef300ccc 100644
>>> --- a/include/command.h
>>> +++ b/include/command.h
>>> @@ -48,6 +48,9 @@ typedef struct cmd_tbl_s  cmd_tbl_t;
>>>  #if defined(CONFIG_CMD_RUN)
>>>  extern int do_run(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
>>> argv[]);
>>>  #endif
>>> +#if 

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

[AKASHI Takahiro]

On Wed, Feb 27, 2019 at 07:14:10AM +0100, Heinrich Schuchardt wrote:
> On 2/27/19 6:47 AM, AKASHI Takahiro wrote:
> > On Tue, Feb 26, 2019 at 07:57:26PM +0100, Heinrich Schuchardt wrote:
> >> On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> >>> See UEFI v2.7, section 3.1.2 for details of the specification.
> >>>
> >>> With my efitool command, you can try as the following:
> >>>   => 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 ...)
> >>>   => efi dumpvar
> >>>   
> >>>   BootCurrent: {boot,run}(blob)
> >>>   :  02 00..
> >>>   BootOrder: {boot,run}(blob)
> >>>   :  01 00 02 00  
> >>>
> >>> Signed-off-by: AKASHI Takahiro 
> >>> ---
> >>>  lib/efi_loader/efi_bootmgr.c | 34 +-
> >>>  1 file changed, 33 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> >>> index a095df3f540b..6c5303736dc6 100644
> >>> --- a/lib/efi_loader/efi_bootmgr.c
> >>> +++ b/lib/efi_loader/efi_bootmgr.c
> >>> @@ -145,11 +145,21 @@ 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",
> >>> __func__, lo.label, lo.file_path);
> >>>  
> >>> + attributes = EFI_VARIABLE_BOOTSERVICE_ACCESS |
> >>> +  EFI_VARIABLE_RUNTIME_ACCESS;
> >>> + size = sizeof(n);
> >>> + ret = rs->set_variable(L"BootCurrent",
> >>> +(efi_guid_t *)_global_variable_guid,
> >>
> >> Use EFI_CALL().
> > 
> > Okay
> > But as I said somewhere else, it's quite annoying to me that
> > some efi_xxx requires EFI_CALL(), and others not.
> > There should have been consistent naming rules.
> 
> We started with having separate functions like efi_allocate_pages_ext()
> and efi_allocate_pages(). Then Rob Clark came along and introduced
> EFI_CALL() in a095aadffa96 and I stopped creating _ext() functions.
> 
> When running with DEBUG 1 it sometimes is helpful to see which function
> is calling which other and where errors are originally reported.
> 
> But I am open to changes in this area.
> 
> > 
> >> Instead of dereferencing you could directly call
> >> efi_set_variable().
> > 
> > Yeah, given that this code is under lib/efi_loader, it may be natural
> > to use efi_set_variable(). But existing get_var() uses the same style of 
> > coding.
> > 
> > Do you want to change all of the call sites including get_var()?
> 
> Calling efi_set_variable() directly uses less bytes of code than
> rs->get_variable() which makes it preferable.

So is your answer yes, or no?

> I have seen that iPXE modifies system->boottime to intercept system
> calls. The same could be done by an EFI driver to the runtime vectors.
> 
> In the light of your work on secure boot I think we should not allow an
> EFI driver to intercept the reading and changing of variables here.
> 
> We should also rethink it for efidebug.c

I'm not sure about your concern here, but no doubt efidebug should
be disabled on production system with secure boot.

Thanks,
-Takahiro Akashi

> Best regards
> 
> Heinrich
> 
> > 
> >>> +attributes, size, );
> >>> + if (ret != EFI_SUCCESS)
> >>> + goto error;
> >>> +
> >>>   ret = efi_load_image_from_path(lo.file_path, );
> >>>  
> >>>   if (ret != EFI_SUCCESS)
> >>> @@ -173,16 +183,38 @@ error:
> >>>  void *efi_bootmgr_load(struct efi_device_path **device_path,
> >>>  struct efi_device_path **file_path)
> >>>  {
> >>> - uint16_t *bootorder;
> >>> + u16 bootnext, *bootorder;
> >>>   efi_uintn_t size;
> >>>   void *image = NULL;
> >>>   int i, num;
> >>> + efi_status_t ret;
> >>>  
> >>>   __efi_entry_check();
> >>>  
> >>>   bs = systab.boottime;
> >>>   rs = systab.runtime;
> >>>  
> >>> + /* get BootNext */
> >>> + size = sizeof(bootnext);
> >>> + ret = rs->get_variable(L"BootNext",
> >>> +(efi_guid_t *)_global_variable_guid,
> >>> +NULL, , );
> >>
> >> You could call efi_get_variable() directly instead of dereferencing rs.
> >> But anyway you have to use EFI_CALL().
> > 
> > Ditto
> > 
> >>> + if (!bootnext)
> >>> + goto run_list;
> >>
> >> Goto is acceptable for error handling. But otherwise I would rather
> >> avoid it.
> > 
> > Okay with another indentation.
> > 
> >>> +
> >>> + /* delete BootNext */
> >>> + ret = rs->set_variable(L"BootNext",
> >>> +(efi_guid_t *)_global_variable_guid,
> >>> +0, 0, );
> >>
> >> 

Re: [U-Boot] [PATCH v9 3/7] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading

[Chee, Tien Fong]

On Tue, 2019-02-26 at 16:46 +0100, Michal Simek wrote:
> On 26. 02. 19 15:53, Chee, Tien Fong wrote:
> > 
> > On Tue, 2019-02-26 at 15:20 +0100, Michal Simek wrote:
> > > 
> > > On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > Add FPGA driver to support program FPGA with FPGA bitstream
> > > > loading
> > > > from
> > > > filesystem. The driver are designed based on generic firmware
> > > > loader
> > > > framework. The driver can handle FPGA program operation from
> > > > loading FPGA
> > > > bitstream in flash to memory and then to program FPGA.
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > 
> > > > ---
> > > > 
> > > > changes for v9
> > > > - Support data offset
> > > > - Added default DDR load address
> > > > - Squashed the image.h
> > > > - Changed to phandle
> > > > - Ensure the DDR is fully up running by checking the gd->ram
> > > > 
> > > > changes for v8
> > > > - Added codes to discern bitstream type based on fpga node
> > > > name.
> > > > 
> > > > changes for v7
> > > > - Restructure the FPGA driver to support both peripheral
> > > > bitstream
> > > > and core
> > > >   bitstream bundled into FIT image.
> > > > - Support loadable property for core bitstream. User can set
> > > > loadable
> > > >   in DDR for better performance. This loading would be done in
> > > > one
> > > > large
> > > >   chunk instead of chunk by chunk loading with small memory
> > > > buffer.
> > > > ---
> > > >  arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts   |  17 +
> > > >  .../include/mach/fpga_manager_arria10.h|  40 +-
> > > >  drivers/fpga/socfpga_arria10.c | 533
> > > > -
> > > >  include/image.h|   4 +
> > > >  4 files changed, 571 insertions(+), 23 deletions(-)
> > > > 
> > > > diff --git a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > > > b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > > > index 998d811..9d43111 100644
> > > > --- a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > > > +++ b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > > > @@ -18,6 +18,23 @@
> > > >  /dts-v1/;
> > > >  #include "socfpga_arria10_socdk.dtsi"
> > > >  
> > > > +/ {
> > > > +   chosen {
> > > > +   firmware-loader = <_loader0>;
> > > > +   };
> > > > +
> > > > +   fs_loader0: fs-loader@0 {
> > > again @0 without reg properly is wrong.
> > Mind to explain more?
> > > 
> > > 
> > > > 
> > > > 
> > > > +   u-boot,dm-pre-reloc;
> > > > +   compatible = "u-boot,fs-loader";
> > > > +   phandlepart = < 1>;
> > > > +   };
> > > I think that this will be nacked by DT guys.
> > > 
> > > > 
> > > > 
> > > > +};
> > > > +
> > > > +_mgr {
> > > > +   u-boot,dm-pre-reloc;
> > > > +   altr,bitstream = "fit_spl_fpga.itb";
> > > > +};
> > > > +
> > > >   {
> > > >     u-boot,dm-pre-reloc;
> > > >     status = "okay";
> > > > diff --git a/arch/arm/mach-
> > > > socfpga/include/mach/fpga_manager_arria10.h b/arch/arm/mach-
> > > > socfpga/include/mach/fpga_manager_arria10.h
> > > > index 09d13f6..7a4f723 100644
> > > > --- a/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
> > > > +++ b/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
> > > > @@ -1,9 +1,13 @@
> > > >  /* SPDX-License-Identifier: GPL-2.0 */
> > > >  /*
> > > > - * Copyright (C) 2017 Intel Corporation 
> > > > + * Copyright (C) 2017-2019 Intel Corporation 
> > > >   * All rights reserved.
> > > >   */
> > > >  
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +
> > > >  #ifndef _FPGA_MANAGER_ARRIA10_H_
> > > >  #define _FPGA_MANAGER_ARRIA10_H_
> > > >  
> > > > @@ -51,6 +55,10 @@
> > > >  #define ALT_FPGAMGR_IMGCFG_CTL_02_CFGWIDTH_SET_MSK 
> > > > BIT(24)
> > > >  #define ALT_FPGAMGR_IMGCFG_CTL_02_CDRATIO_LSB  
> > > > 16
> > > >  
> > > > +#define FPGA_SOCFPGA_A10_RBF_UNENCRYPTED   0xa65c
> > > > +#define FPGA_SOCFPGA_A10_RBF_ENCRYPTED 0xa65d
> > > > +#define FPGA_SOCFPGA_A10_RBF_PERIPH0x0001
> > > > +#define FPGA_SOCFPGA_A10_RBF_CORE  0x8001
> > > >  #ifndef __ASSEMBLY__
> > > >  
> > > >  struct socfpga_fpga_manager {
> > > > @@ -88,12 +96,40 @@ struct socfpga_fpga_manager {
> > > >     u32  imgcfg_fifo_status;
> > > >  };
> > > >  
> > > > +enum rbf_type {
> > > > +   unknown,
> > > > +   periph_section,
> > > > +   core_section
> > > > +};
> > > > +
> > > > +enum rbf_security {
> > > > +   invalid,
> > > > +   unencrypted,
> > > > +   encrypted
> > > > +};
> > > > +
> > > > +struct rbf_info {
> > > > +   enum rbf_type section;
> > > > +   enum rbf_security security;
> > > > +};
> > > > +
> > > > +struct fpga_loadfs_info {
> > > > +   fpga_fs_info *fpga_fsinfo;
> > > > +   u32 remaining;
> > > > +   u32 offset;
> > > > +   struct rbf_info rbfinfo;
> > > > +};
> > > > +
> > > >  /* 

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

[Heinrich Schuchardt]

On 2/27/19 6:47 AM, AKASHI Takahiro wrote:
> On Tue, Feb 26, 2019 at 07:57:26PM +0100, Heinrich Schuchardt wrote:
>> On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
>>> See UEFI v2.7, section 3.1.2 for details of the specification.
>>>
>>> With my efitool command, you can try as the following:
>>>   => 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 ...)
>>>   => efi dumpvar
>>>   
>>>   BootCurrent: {boot,run}(blob)
>>>   :  02 00..
>>>   BootOrder: {boot,run}(blob)
>>>   :  01 00 02 00  
>>>
>>> Signed-off-by: AKASHI Takahiro 
>>> ---
>>>  lib/efi_loader/efi_bootmgr.c | 34 +-
>>>  1 file changed, 33 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
>>> index a095df3f540b..6c5303736dc6 100644
>>> --- a/lib/efi_loader/efi_bootmgr.c
>>> +++ b/lib/efi_loader/efi_bootmgr.c
>>> @@ -145,11 +145,21 @@ 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",
>>>   __func__, lo.label, lo.file_path);
>>>  
>>> +   attributes = EFI_VARIABLE_BOOTSERVICE_ACCESS |
>>> +EFI_VARIABLE_RUNTIME_ACCESS;
>>> +   size = sizeof(n);
>>> +   ret = rs->set_variable(L"BootCurrent",
>>> +  (efi_guid_t *)_global_variable_guid,
>>
>> Use EFI_CALL().
> 
> Okay
> But as I said somewhere else, it's quite annoying to me that
> some efi_xxx requires EFI_CALL(), and others not.
> There should have been consistent naming rules.

We started with having separate functions like efi_allocate_pages_ext()
and efi_allocate_pages(). Then Rob Clark came along and introduced
EFI_CALL() in a095aadffa96 and I stopped creating _ext() functions.

When running with DEBUG 1 it sometimes is helpful to see which function
is calling which other and where errors are originally reported.

But I am open to changes in this area.

> 
>> Instead of dereferencing you could directly call
>> efi_set_variable().
> 
> Yeah, given that this code is under lib/efi_loader, it may be natural
> to use efi_set_variable(). But existing get_var() uses the same style of 
> coding.
> 
> Do you want to change all of the call sites including get_var()?

Calling efi_set_variable() directly uses less bytes of code than
rs->get_variable() which makes it preferable.

I have seen that iPXE modifies system->boottime to intercept system
calls. The same could be done by an EFI driver to the runtime vectors.

In the light of your work on secure boot I think we should not allow an
EFI driver to intercept the reading and changing of variables here.

We should also rethink it for efidebug.c

Best regards

Heinrich

> 
>>> +  attributes, size, );
>>> +   if (ret != EFI_SUCCESS)
>>> +   goto error;
>>> +
>>> ret = efi_load_image_from_path(lo.file_path, );
>>>  
>>> if (ret != EFI_SUCCESS)
>>> @@ -173,16 +183,38 @@ error:
>>>  void *efi_bootmgr_load(struct efi_device_path **device_path,
>>>struct efi_device_path **file_path)
>>>  {
>>> -   uint16_t *bootorder;
>>> +   u16 bootnext, *bootorder;
>>> efi_uintn_t size;
>>> void *image = NULL;
>>> int i, num;
>>> +   efi_status_t ret;
>>>  
>>> __efi_entry_check();
>>>  
>>> bs = systab.boottime;
>>> rs = systab.runtime;
>>>  
>>> +   /* get BootNext */
>>> +   size = sizeof(bootnext);
>>> +   ret = rs->get_variable(L"BootNext",
>>> +  (efi_guid_t *)_global_variable_guid,
>>> +  NULL, , );
>>
>> You could call efi_get_variable() directly instead of dereferencing rs.
>> But anyway you have to use EFI_CALL().
> 
> Ditto
> 
>>> +   if (!bootnext)
>>> +   goto run_list;
>>
>> Goto is acceptable for error handling. But otherwise I would rather
>> avoid it.
> 
> Okay with another indentation.
> 
>>> +
>>> +   /* delete BootNext */
>>> +   ret = rs->set_variable(L"BootNext",
>>> +  (efi_guid_t *)_global_variable_guid,
>>> +  0, 0, );
>>
>> EFI_CALL().
> 
> Thanks,
> -Takahiro Akashi
> 
>> Best regards
>>
>> Heinrich
>>
>>> +   if (ret != EFI_SUCCESS)
>>> +   goto error;
>>> +
>>> +   image = try_load_entry(bootnext, device_path, file_path);
>>> +   if (image)
>>> +   goto error;
>>> +
>>> +run_list:
>>> +   /* BootOrder */
>>> bootorder = get_var(L"BootOrder", _global_variable_guid, );
>>> if (!bootorder)
>>> goto error;
>>>
>>
> 

Re: [U-Boot] [PATCH v2 5/5] cmd: run: add "-e" option to run an EFI application

[AKASHI Takahiro]

On Tue, Feb 26, 2019 at 08:20:10PM +0100, Heinrich Schuchardt wrote:
> On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> > "run -e" allows for executing EFI application with a specific "Boot"
> > variable. If no "Boot" is specified or "BootOrder" is specified,
> > it tries to run an EFI application specified in the order of "bootOrder."
> > 
> 
> If we cannot specify the device tree what would be the use of this for
> ARM processors?

I don't get your point. What's the matter with device tree?


> Why do you add the option to run and not to bootefi?
> 
> You already introduced the capability to set BootNext. Why isn't that
> enough?

Simple.

=> run -e Boot0001

versus

=> efidebug boot next 1
=> bootefi bootmgr

First of all, efidebug is only recognized as a *debugging* tool.
I believe that the former syntax is more intuitive, and it looks
a natural extension to "run" command semantics akin to "env -e".

As a result, we don't have to know about bootefi for normal operations.

Thanks,
-Takahiro Akashi


> Best regards
> 
> Heinrich
> 
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  cmd/bootefi.c | 31 +++
> >  cmd/nvedit.c  |  9 -
> >  common/cli.c  | 10 ++
> >  include/command.h |  3 +++
> >  4 files changed, 52 insertions(+), 1 deletion(-)
> > 
> > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > index 241fd0f987ab..ebe149dffa1f 100644
> > --- a/cmd/bootefi.c
> > +++ b/cmd/bootefi.c
> > @@ -492,6 +492,37 @@ static int do_bootefi_bootmgr_exec(int boot_id)
> > return CMD_RET_SUCCESS;
> >  }
> >  
> > +/* Called by "run" command */
> > +int do_bootefi_run(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> > argv[])
> > +{
> > +   int boot_id = -1;
> > +   char *endp;
> > +
> > +   if (argc > 2)
> > +   return CMD_RET_USAGE;
> > +
> > +   if (argc == 2) {
> > +   if (!strcmp(argv[1], "BootOrder")) {
> > +   boot_id = -1;
> > +   } else if (!strncmp(argv[2], "Boot", 4)) {
> > +   boot_id = (int)simple_strtoul([2][4], , 0);
> > +   if ((argv[2] + strlen(argv[2]) != endp) ||
> > +   boot_id > 0x)
> > +   return CMD_RET_USAGE;
> > +   } else {
> > +   return CMD_RET_USAGE;
> > +   }
> > +   }
> > +
> > +   if (efi_init_obj_list())
> > +   return CMD_RET_FAILURE;
> > +
> > +   if (efi_handle_fdt(NULL))
> > +   return CMD_RET_FAILURE;
> > +
> > +   return do_bootefi_bootmgr_exec(boot_id);
> > +}
> > +
> >  /* Interpreter command to boot an arbitrary EFI image from memory */
> >  static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> > argv[])
> >  {
> > diff --git a/cmd/nvedit.c b/cmd/nvedit.c
> > index de16c72c23f2..ce746bbf1b3e 100644
> > --- a/cmd/nvedit.c
> > +++ b/cmd/nvedit.c
> > @@ -1344,7 +1344,14 @@ U_BOOT_CMD_COMPLETE(
> > run,CONFIG_SYS_MAXARGS, 1,  do_run,
> > "run commands in an environment variable",
> > "var [...]\n"
> > -   "- run the commands in the environment variable(s) 'var'",
> > +   "- run the commands in the environment variable(s) 'var'"
> > +#if defined(CONFIG_CMD_BOOTEFI)
> > +   "\n"
> > +   "run -e [Boot]\n"
> > +   "- load and run UEFI app based on 'Boot' UEFI variable",
> > +#else
> > +   ,
> > +#endif
> > var_complete
> >  );
> >  #endif
> > diff --git a/common/cli.c b/common/cli.c
> > index 51b8d5f85cbb..fbb09d5049a4 100644
> > --- a/common/cli.c
> > +++ b/common/cli.c
> > @@ -12,6 +12,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  
> > @@ -125,6 +126,15 @@ int do_run(cmd_tbl_t *cmdtp, int flag, int argc, char 
> > * const argv[])
> > if (argc < 2)
> > return CMD_RET_USAGE;
> >  
> > +#ifdef CONFIG_CMD_BOOTEFI
> > +   if (!strcmp(argv[1], "-e")) {
> > +   argc--;
> > +   argv++;
> > +
> > +   return do_bootefi_run(cmdtp, flag, argc, argv);
> > +   }
> > +#endif
> > +
> > for (i = 1; i < argc; ++i) {
> > char *arg;
> >  
> > diff --git a/include/command.h b/include/command.h
> > index 200c7a5e9f4e..feddef300ccc 100644
> > --- a/include/command.h
> > +++ b/include/command.h
> > @@ -48,6 +48,9 @@ typedef struct cmd_tbl_s  cmd_tbl_t;
> >  #if defined(CONFIG_CMD_RUN)
> >  extern int do_run(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> > argv[]);
> >  #endif
> > +#if defined(CONFIG_CMD_BOOTEFI)
> > +extern int do_bootefi_run(cmd_tbl_t *cmdtp, int flag, int argc, char * 
> > const argv[]);
> > +#endif
> >  
> >  /* common/command.c */
> >  int _do_help (cmd_tbl_t *cmd_start, int cmd_items, cmd_tbl_t * cmdtp, int
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v9 2/7] ARM: socfpga: Add default FPGA bitstream fitImage for Arria10 SoCDK

[Chee, Tien Fong]

On Tue, 2019-02-26 at 16:43 +0100, Michal Simek wrote:
> On 26. 02. 19 15:30, Chee, Tien Fong wrote:
> > 
> > On Tue, 2019-02-26 at 15:07 +0100, Michal Simek wrote:
> > > 
> > > On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > Add default fitImage file bundling FPGA bitstreams for Arria10.
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > 
> > > > ---
> > > > 
> > > > changes for v8
> > > > - Reordered the images and fpga configurations.
> > > > - Removed the load property at core image.
> > > > 
> > > > changes for v8
> > > > - Changed the FPGA node name to fpga-core and fpga-periph for
> > > > both
> > > > core and
> > > >   periph bitstreams respectively.
> > > > ---
> > > >  board/altera/arria10-socdk/fit_spl_fpga.its | 38
> > > > +
> > > >  1 file changed, 38 insertions(+)
> > > >  create mode 100644 board/altera/arria10-socdk/fit_spl_fpga.its
> > > > 
> > > > diff --git a/board/altera/arria10-socdk/fit_spl_fpga.its
> > > > b/board/altera/arria10-socdk/fit_spl_fpga.its
> > > > new file mode 100644
> > > > index 000..df84562
> > > > --- /dev/null
> > > > +++ b/board/altera/arria10-socdk/fit_spl_fpga.its
> > > > @@ -0,0 +1,38 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > + /*
> > > > + * Copyright (C) 2019 Intel Corporation 
> > > > + *
> > > > + */
> > > > +
> > > > +/dts-v1/;
> > > > +
> > > > +/ {
> > > > +   description = "FIT image with FPGA bistream";
> > > > +   #address-cells = <1>;
> > > > +
> > > > +   images {
> > > > +   fpga-periph@1 {
> > > Still this is DT and using @1 without reg property below is
> > > wrong.
> > Sorry, i'm not getting you.
> > Mind to explain more?
> it should be just fpga-periph {
> because you don't have reg properly below.
So this rule also apply for ITS image node name?
How about fpga-periph-1?
> 
> M
> 
> 
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] net: eth-uclass: call stop only for active devices

[Bin Meng]

On Wed, Feb 27, 2019 at 1:47 PM Keerthy  wrote:
>
>
>
> On 22/02/19 12:08 AM, Joe Hershberger wrote:
> > On Wed, Feb 20, 2019 at 6:33 AM Keerthy  wrote:
> >>
> >> Currently stop is being called unconditionally without even
> >> checking if start is called. In case of multiple instances eth
> >> being present many devices might just be initialized without
> >> a start call in such cases stop might lead unpredictable behaviors
> >> including aborts and crashes. Hence add a check before calling stop.
> >>
> >> Signed-off-by: Keerthy 
> >> ---
> >>   net/eth-uclass.c | 3 ++-
> >>   1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/net/eth-uclass.c b/net/eth-uclass.c
> >> index 2ef20df192..26f7e0b8cd 100644
> >> --- a/net/eth-uclass.c
> >> +++ b/net/eth-uclass.c
> >> @@ -531,7 +531,8 @@ static int eth_pre_remove(struct udevice *dev)
> >>   {
> >>  struct eth_pdata *pdata = dev->platdata;
> >>
> >> -   eth_get_ops(dev)->stop(dev);
> >> +   if (eth_is_active(dev))
> >> +   eth_get_ops(dev)->stop(dev);
> >
> > This seems reasonable... What was the case that provoked an issue?
> > Which driver was having trouble?
>
> I am trying to implement pru based ethernet driver(multiple instances)
> with cpsw driver on top on am654-evm. I observed that even though i had
> not started
> a particular instance of my pru based device stop was getting called and
> it was crashing right at the end.
>

Please add a proper test case in test/dm/eth.c to cover such scenarios. Thanks!

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

Re: [U-Boot] [PATCH v2 4/5] cmd: bootefi: run an EFI application of a specific load option

[AKASHI Takahiro]

On Tue, Feb 26, 2019 at 08:30:50PM +0100, Heinrich Schuchardt wrote:
> On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> > With this patch applied, we will be able to selectively execute
> > an EFI application by specifying a load option, say "1" for Boot0001,
> > "2" for Boot0002 and so on.
> > 
> >   => bootefi bootmgr  1, or
> >  bootefi bootmgr - 1
> 
> You already introduced the support for BootNext. So is there a real benefit?

This is a convenient way of running EFI application directly,
but I already removed this feature from the next version.

> > 
> > Please note that Boot need not be included in "BootOrder".
> > 
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  cmd/bootefi.c | 39 ---
> >  1 file changed, 28 insertions(+), 11 deletions(-)
> > 
> > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > index 3be01b49b589..241fd0f987ab 100644
> > --- a/cmd/bootefi.c
> > +++ b/cmd/bootefi.c
> > @@ -471,16 +471,15 @@ static efi_status_t bootefi_test_prepare
> >  
> >  #endif /* CONFIG_CMD_BOOTEFI_SELFTEST */
> >  
> > -static int do_bootefi_bootmgr_exec(void)
> > +static int do_bootefi_bootmgr_exec(int boot_id)
> >  {
> > struct efi_device_path *device_path, *file_path;
> > void *addr;
> > efi_status_t r;
> >  
> > -   addr = efi_bootmgr_load(EFI_BOOTMGR_DEFAULT_ORDER,
> > -   _path, _path);
> > +   addr = efi_bootmgr_load(boot_id, _path, _path);
> > if (!addr)
> > -   return 1;
> > +   return CMD_RET_FAILURE;
> >  
> > printf("## Starting EFI application at %p ...\n", addr);
> > r = do_bootefi_exec(addr, device_path, file_path);
> > @@ -488,9 +487,9 @@ static int do_bootefi_bootmgr_exec(void)
> >r & ~EFI_ERROR_MASK);
> >  
> > if (r != EFI_SUCCESS)
> > -   return 1;
> > +   return CMD_RET_FAILURE;
> >  
> > -   return 0;
> > +   return CMD_RET_SUCCESS;
> >  }
> >  
> >  /* Interpreter command to boot an arbitrary EFI image from memory */
> > @@ -546,10 +545,28 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int 
> > argc, char * const argv[])
> > } else
> >  #endif
> > if (!strcmp(argv[1], "bootmgr")) {
> > -   if (efi_handle_fdt(argc > 2 ? argv[2] : NULL))
> > -   return CMD_RET_FAILURE;
> > +   char *fdtstr, *endp;
> > +   int boot_id = EFI_BOOTMGR_DEFAULT_ORDER;
> > +
> > +   if (argc > 2) {
> > +   fdtstr = argv[2];
> > +/* Special address "-" means no device tree */
> > +   if (fdtstr[0] == '-')
> > +   fdtstr = NULL;
> > +
> > +   r = efi_handle_fdt(fdtstr);
> > +   if (r)
> > +   return CMD_RET_FAILURE;
> > +   }
> > +
> > +   if (argc > 3) {
> > +   boot_id = (int)simple_strtoul(argv[3], , 0);
> > +   if ((argv[3] + strlen(argv[3]) != endp) ||
> > +   boot_id > 0x)
> > +   return CMD_RET_USAGE;
> > +   }
> >  
> > -   return do_bootefi_bootmgr_exec();
> > +   return do_bootefi_bootmgr_exec(boot_id);
> 
> Why not communicate via the BootNext variable?

I don't get your point.
BootNext and BootOrder are both defined by UEFI specification.

> > } else {
> > saddr = argv[1];
> >  
> > @@ -590,7 +607,7 @@ static char bootefi_help_text[] =
> > "Use environment variable efi_selftest to select a single test.\n"
> > "Use 'setenv efi_selftest list' to enumerate all tests.\n"
> >  #endif
> > -   "bootefi bootmgr [fdt addr]\n"
> > +   "bootefi bootmgr [|'-' []]\n"
> > "  - load and boot EFI payload based on BootOrder/Boot variables.\n"
> > "\n"
> > "If specified, the device tree located at  gets\n"
> > @@ -598,7 +615,7 @@ static char bootefi_help_text[] =
> >  #endif
> >  
> >  U_BOOT_CMD(
> > -   bootefi, 3, 0, do_bootefi,
> > +   bootefi, 5, 0, do_bootefi,
> 
> Why 5?

For additional/optional '-' and .
But I removed this feature from bootefi.

Thanks,
-Takahiro Akashi


> Best regards
> 
> Heinrich
> 
> > "Boots an EFI payload from memory",
> > bootefi_help_text
> >  );
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] net: eth-uclass: call stop only for active devices

[Keerthy]

On 22/02/19 12:08 AM, Joe Hershberger wrote:

On Wed, Feb 20, 2019 at 6:33 AM Keerthy  wrote:


Currently stop is being called unconditionally without even
checking if start is called. In case of multiple instances eth
being present many devices might just be initialized without
a start call in such cases stop might lead unpredictable behaviors
including aborts and crashes. Hence add a check before calling stop.

Signed-off-by: Keerthy 
---
  net/eth-uclass.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/eth-uclass.c b/net/eth-uclass.c
index 2ef20df192..26f7e0b8cd 100644
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -531,7 +531,8 @@ static int eth_pre_remove(struct udevice *dev)
  {
 struct eth_pdata *pdata = dev->platdata;

-   eth_get_ops(dev)->stop(dev);
+   if (eth_is_active(dev))
+   eth_get_ops(dev)->stop(dev);


This seems reasonable... What was the case that provoked an issue?
Which driver was having trouble?


I am trying to implement pru based ethernet driver(multiple instances) 
with cpsw driver on top on am654-evm. I observed that even though i had 
not started
a particular instance of my pru based device stop was getting called and 
it was crashing right at the end.






 /* clear the MAC address */
 memset(pdata->enetaddr, 0, ARP_HLEN);
--
2.17.1

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

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

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

[AKASHI Takahiro]

On Tue, Feb 26, 2019 at 07:57:26PM +0100, Heinrich Schuchardt wrote:
> On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> > See UEFI v2.7, section 3.1.2 for details of the specification.
> > 
> > With my efitool command, you can try as the following:
> >   => 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 ...)
> >   => efi dumpvar
> >   
> >   BootCurrent: {boot,run}(blob)
> >   :  02 00..
> >   BootOrder: {boot,run}(blob)
> >   :  01 00 02 00  
> > 
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  lib/efi_loader/efi_bootmgr.c | 34 +-
> >  1 file changed, 33 insertions(+), 1 deletion(-)
> > 
> > diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> > index a095df3f540b..6c5303736dc6 100644
> > --- a/lib/efi_loader/efi_bootmgr.c
> > +++ b/lib/efi_loader/efi_bootmgr.c
> > @@ -145,11 +145,21 @@ 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",
> >   __func__, lo.label, lo.file_path);
> >  
> > +   attributes = EFI_VARIABLE_BOOTSERVICE_ACCESS |
> > +EFI_VARIABLE_RUNTIME_ACCESS;
> > +   size = sizeof(n);
> > +   ret = rs->set_variable(L"BootCurrent",
> > +  (efi_guid_t *)_global_variable_guid,
> 
> Use EFI_CALL().

Okay
But as I said somewhere else, it's quite annoying to me that
some efi_xxx requires EFI_CALL(), and others not.
There should have been consistent naming rules.

> Instead of dereferencing you could directly call
> efi_set_variable().

Yeah, given that this code is under lib/efi_loader, it may be natural
to use efi_set_variable(). But existing get_var() uses the same style of coding.

Do you want to change all of the call sites including get_var()?

> > +  attributes, size, );
> > +   if (ret != EFI_SUCCESS)
> > +   goto error;
> > +
> > ret = efi_load_image_from_path(lo.file_path, );
> >  
> > if (ret != EFI_SUCCESS)
> > @@ -173,16 +183,38 @@ error:
> >  void *efi_bootmgr_load(struct efi_device_path **device_path,
> >struct efi_device_path **file_path)
> >  {
> > -   uint16_t *bootorder;
> > +   u16 bootnext, *bootorder;
> > efi_uintn_t size;
> > void *image = NULL;
> > int i, num;
> > +   efi_status_t ret;
> >  
> > __efi_entry_check();
> >  
> > bs = systab.boottime;
> > rs = systab.runtime;
> >  
> > +   /* get BootNext */
> > +   size = sizeof(bootnext);
> > +   ret = rs->get_variable(L"BootNext",
> > +  (efi_guid_t *)_global_variable_guid,
> > +  NULL, , );
> 
> You could call efi_get_variable() directly instead of dereferencing rs.
> But anyway you have to use EFI_CALL().

Ditto

> > +   if (!bootnext)
> > +   goto run_list;
> 
> Goto is acceptable for error handling. But otherwise I would rather
> avoid it.

Okay with another indentation.

> > +
> > +   /* delete BootNext */
> > +   ret = rs->set_variable(L"BootNext",
> > +  (efi_guid_t *)_global_variable_guid,
> > +  0, 0, );
> 
> EFI_CALL().

Thanks,
-Takahiro Akashi

> Best regards
> 
> Heinrich
> 
> > +   if (ret != EFI_SUCCESS)
> > +   goto error;
> > +
> > +   image = try_load_entry(bootnext, device_path, file_path);
> > +   if (image)
> > +   goto error;
> > +
> > +run_list:
> > +   /* BootOrder */
> > bootorder = get_var(L"BootOrder", _global_variable_guid, );
> > if (!bootorder)
> > goto error;
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Pull request: u-boot-riscv/master

[uboot]

Hi Tom,

Please pull some riscv updates:

SiFive FU540 Support

https://travis-ci.org/rickchen36/u-boot-riscv/builds/499037971

Thanks
Rick


The following changes since commit b3820ba997f004a376efc5446683101ff42b05af:

  Merge tag 'efi-2019-04-rc3' of https://github.com/xypron2/u-boot (2019-02-26 
08:45:08 -0500)

are available in the Git repository at:

  git://git.denx.de/u-boot-riscv.git

for you to fetch changes up to 98a66ffa3aafd20d38f357d624e470e20fbb1839:

  riscv: Enable CONFIG_SYS_BOOT_RAMDISK_HIGH for using initrd (2019-02-27 
09:12:34 +0800)


Anup Patel (10):
  riscv: Enable create symlink using kconfig
  riscv: Rename cpu/qemu to cpu/generic
  riscv: Add asm/dma-mapping.h for DMA mappings
  riscv: Add place-holder asm/arch/clk.h for driver compilation
  riscv: generic: Ensure that U-Boot runs within 4GB for 64bit systems
  net: macb: Fix clk API usage for RISC-V systems
  clk: Add SiFive FU540 PRCI clock driver
  clk: Add fixed-factor clock driver
  riscv: Add SiFive FU540 board support
  riscv: Enable CONFIG_SYS_BOOT_RAMDISK_HIGH for using initrd

Atish Patra (5):
  net: macb: Fix GEM hardware detection
  drivers: serial_sifive: Fix baud rate calculation
  drivers: serial_sifive: Skip baudrate config if no input clock
  cpu: Bind timer driver for boot hart
  doc: Add a readme guide for SiFive FU540

 arch/Kconfig  |   1 +
 arch/riscv/Kconfig|   6 +-
 arch/riscv/cpu/{qemu => generic}/Kconfig  |   2 +-
 arch/riscv/cpu/{qemu => generic}/Makefile |   0
 arch/riscv/cpu/{qemu => generic}/cpu.c|   0
 arch/riscv/cpu/generic/dram.c |  37 ++
 arch/riscv/cpu/qemu/dram.c|  17 ---
 arch/riscv/include/asm/arch-generic/clk.h |  14 +++
 arch/riscv/include/asm/config.h   |   1 +
 arch/riscv/include/asm/dma-mapping.h  |  38 ++
 arch/sandbox/dts/test.dts |   8 ++
 board/emulation/qemu-riscv/Kconfig|   4 +-
 board/sifive/fu540/Kconfig|  42 +++
 board/sifive/fu540/MAINTAINERS|   9 ++
 board/sifive/fu540/Makefile   |   5 +
 board/sifive/fu540/fu540.c|  17 +++
 configs/sifive_fu540_defconfig|  11 ++
 doc/README.sifive-fu540   | 303 

 doc/device-tree-bindings/clock/fixed-factor-clock.txt |  24 
 drivers/clk/Kconfig   |   1 +
 drivers/clk/Makefile  |   5 +-
 drivers/clk/clk_fixed_factor.c|  74 
 drivers/clk/sifive/Kconfig|  19 +++
 drivers/clk/sifive/Makefile   |   5 +
 drivers/clk/sifive/analogbits-wrpll-cln28hpc.h| 101 
 drivers/clk/sifive/fu540-prci.c   | 604 
+++
 drivers/clk/sifive/wrpll-cln28hpc.c   | 390 
+
 drivers/cpu/riscv_cpu.c   |   7 +-
 drivers/net/macb.c|  11 +-
 drivers/serial/serial_sifive.c|  60 +++---
 include/configs/sifive-fu540.h|  43 +++
 include/dt-bindings/clk/sifive-fu540-prci.h   |  29 +
 test/dm/clk.c |   5 +-
 33 files changed, 1843 insertions(+), 50 deletions(-)
 rename arch/riscv/cpu/{qemu => generic}/Kconfig (91%)
 rename arch/riscv/cpu/{qemu => generic}/Makefile (100%)
 rename arch/riscv/cpu/{qemu => generic}/cpu.c (100%)
 create mode 100644 arch/riscv/cpu/generic/dram.c
 delete mode 100644 arch/riscv/cpu/qemu/dram.c
 create mode 100644 arch/riscv/include/asm/arch-generic/clk.h
 create mode 100644 arch/riscv/include/asm/dma-mapping.h
 create mode 100644 board/sifive/fu540/Kconfig
 create mode 100644 board/sifive/fu540/MAINTAINERS
 create mode 100644 board/sifive/fu540/Makefile
 create mode 100644 board/sifive/fu540/fu540.c
 create mode 100644 configs/sifive_fu540_defconfig
 create mode 100644 doc/README.sifive-fu540
 create mode 100644 doc/device-tree-bindings/clock/fixed-factor-clock.txt
 create mode 100644 drivers/clk/clk_fixed_factor.c
 create mode 100644 drivers/clk/sifive/Kconfig
 create mode 100644 drivers/clk/sifive/Makefile
 create mode 100644 drivers/clk/sifive/analogbits-wrpll-cln28hpc.h
 create mode 100644 drivers/clk/sifive/fu540-prci.c
 create mode 100644 drivers/clk/sifive/wrpll-cln28hpc.c
 create mode 100644 include/configs/sifive-fu540.h
 

[U-Boot] [PATCH v2] spi: cadence_qspi: Add quad write support

[Ley Foon Tan]

Use quad write if SPI_TX_QUAD flag is set.

Tested quad write on Stratix 10 SoC board (Micron
serial NOR flash, mt25qu02g)

Signed-off-by: Ley Foon Tan 

---
v1 -> v2:
- Update commit message
- Restore file permission
---
 drivers/spi/cadence_qspi.c | 2 +-
 drivers/spi/cadence_qspi.h | 2 +-
 drivers/spi/cadence_qspi_apb.c | 7 ++-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 11fce9c4fe..efdb178450 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -256,7 +256,7 @@ static int cadence_spi_xfer(struct udevice *dev, unsigned 
int bitlen,
break;
case CQSPI_INDIRECT_WRITE:
err = cadence_qspi_apb_indirect_write_setup
-   (plat, priv->cmd_len, cmd_buf);
+   (plat, priv->cmd_len, dm_plat->mode, cmd_buf);
if (!err) {
err = cadence_qspi_apb_indirect_write_execute
(plat, data_bytes, dout);
diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h
index 055900def0..b491407130 100644
--- a/drivers/spi/cadence_qspi.h
+++ b/drivers/spi/cadence_qspi.h
@@ -60,7 +60,7 @@ int cadence_qspi_apb_indirect_read_setup(struct 
cadence_spi_platdata *plat,
 int cadence_qspi_apb_indirect_read_execute(struct cadence_spi_platdata *plat,
unsigned int rxlen, u8 *rxbuf);
 int cadence_qspi_apb_indirect_write_setup(struct cadence_spi_platdata *plat,
-   unsigned int cmdlen, const u8 *cmdbuf);
+   unsigned int cmdlen, unsigned int tx_width, const u8 *cmdbuf);
 int cadence_qspi_apb_indirect_write_execute(struct cadence_spi_platdata *plat,
unsigned int txlen, const u8 *txbuf);
 
diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index a8af352030..55a7501913 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -77,6 +77,7 @@
 
 #defineCQSPI_REG_WR_INSTR  0x08
 #defineCQSPI_REG_WR_INSTR_OPCODE_LSB   0
+#defineCQSPI_REG_WR_INSTR_TYPE_DATA_LSB16
 
 #defineCQSPI_REG_DELAY 0x0C
 #defineCQSPI_REG_DELAY_TSLCH_LSB   0
@@ -686,7 +687,7 @@ failrd:
 
 /* Opcode + Address (3/4 bytes) */
 int cadence_qspi_apb_indirect_write_setup(struct cadence_spi_platdata *plat,
-   unsigned int cmdlen, const u8 *cmdbuf)
+   unsigned int cmdlen, unsigned int tx_width, const u8 *cmdbuf)
 {
unsigned int reg;
unsigned int addr_bytes = cmdlen > 4 ? 4 : 3;
@@ -702,6 +703,10 @@ int cadence_qspi_apb_indirect_write_setup(struct 
cadence_spi_platdata *plat,
 
/* Configure the opcode */
reg = cmdbuf[0] << CQSPI_REG_WR_INSTR_OPCODE_LSB;
+
+   if (tx_width & SPI_TX_QUAD)
+   reg |= CQSPI_INST_TYPE_QUAD << CQSPI_REG_WR_INSTR_TYPE_DATA_LSB;
+
writel(reg, plat->regbase + CQSPI_REG_WR_INSTR);
 
/* Setup write address. */
-- 
2.19.0

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

Re: [U-Boot] SiFive FU540 U-Boot patches,

[Rick Chen]

Hi Anup

Anup Patel  於 2019年2月26日 週二 下午7:55寫道：
>
> On Mon, Feb 25, 2019 at 12:50 PM Rick Chen  wrote:
> >
> > Hi Anup
> >
> > Anup Patel  於 2019年2月25日 週一 上午11:28寫道：
> > >
> > > On Mon, Feb 25, 2019 at 7:50 AM Rick Chen  wrote:
> > > >
> > > > Hi Anup
> > > >
> > > > Rick Chen  於 2019年2月22日 週五 下午12:05寫道：
> > > > >
> > > > > Hi Anup
> > > > >
> > > > > Anup Patel  於 2019年2月21日 週四 下午5:57寫道：
> > > > >
> > > > > >
> > > > > > On Thu, Feb 21, 2019 at 11:31 AM Bin Meng  
> > > > > > wrote:
> > > > > > >
> > > > > > > On Thu, Feb 21, 2019 at 12:48 PM Anup Patel  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Rick,
> > > > > > > >
> > > > > > > > On Fri, Feb 15, 2019 at 10:19 AM Rick Chen 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > Hi Anup
> > > > > > > > >
> > > > > > > > > > > Hi All,
> > > > > > > > > > >
> > > > > > > > > > > Thanks for all the review comments so far.
> > > > > > > > > > >
> > > > > > > > > > > Is it possible to accept "[PATCH v7 00/15] SiFive FU540 
> > > > > > > > > > > Support" for
> > > > > > > > > > > U-Boot-2019.04 ??
> > > > > > > > > > >
> > > > > > > > > > > Based on our discussion with various folks at FOSDEM19, 
> > > > > > > > > > > lot of people want to
> > > > > > > > > > > use U-Boot on Unleashed board. In general, it will be 
> > > > > > > > > > > exciting to see U-Boot being
> > > > > > > > > > > adopted as bootloader by various RISC-V HW vendors.
> > > > > > > > >
> > > > > > > > > I am still waiting for Simon's response about the two patchs
> > > > > > > > > that he have comments.
> > > > > > > >
> > > > > > > > I have addressed Simon's patches and got Reviewed-by as well.
> > > > > > > >
> > > > > > > > I have posted "[PATCH v9 00/15] SiFive FU540 Support" which
> > > > > > > > is based on U-Boot-2019.4-rc2.
> > > > > > > >
> > > > > > > > You can also find this patches in riscv_sifive_fu540_v9 branch 
> > > > > > > > of
> > > > > > > > https://github.com/avpatel/u-boot.git
> > > > > > >
> > > > > > > Thanks for the support and hopefully we can get this one plus 
> > > > > > > Lukas's
> > > > > > > SMP series in the v2019.04 release.
> > > > > >
> > > > > > It will be awesome to have Lukas's SMP patches along with
> > > > > > SiFive FU540 patches in v2019.04
> > > > > >
> > > > >
> > > > > OK
> > > > > I will pull into u-boot-riscv and run Travis.
> > > >
> > > > Can you take a look this Travis fail item 12.44 as below
> > > > https://travis-ci.org/rickchen36/u-boot-riscv/jobs/496911491
> > >
> > > Ahh, this issue got introduced when I removed "#if" (Suggested by Alex)
> > > from clk_fixed_factor_ofdata_to_platdata() in v3 of this patchset.
> > >
> > > I suggest we bring back the "#if" by modifying PATCH9 with following
> > > additional change:
> > >
> > > diff --git a/drivers/clk/clk_fixed_factor.c 
> > > b/drivers/clk/clk_fixed_factor.c
> > > index 9e00544889..5fa20a84db 100644
> > > --- a/drivers/clk/clk_fixed_factor.c
> > > +++ b/drivers/clk/clk_fixed_factor.c
> > > @@ -42,6 +42,7 @@ const struct clk_ops clk_fixed_factor_ops = {
> > >
> > >  static int clk_fixed_factor_ofdata_to_platdata(struct udevice *dev)
> > >  {
> > > +#if !CONFIG_IS_ENABLED(OF_PLATDATA)
> > > int err;
> > > struct clk_fixed_factor *ff = to_clk_fixed_factor(dev);
> > >
> > > @@ -51,6 +52,7 @@ static int
> > > clk_fixed_factor_ofdata_to_platdata(struct udevice *dev)
> > >
> > > ff->div = dev_read_u32_default(dev, "clock-div", 1);
> > > ff->mult = dev_read_u32_default(dev, "clock-mult", 1);
> > > +#endif
> > >
> > > return 0;
> > >  }
> > >
> > > The above will resolve Travis build fail.
> > >
> >
> > Will you send another patchset to solve this fail issue ?
>
> Does the v10 patchset work for you?

Yes. It can pass the Travis build.
I will send a PR later.

Thanks
Rick

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

Re: [U-Boot] [PATCH] spi: cadence_qspi: Add quad write support

[Ley Foon Tan]

On Wed, 2019-02-27 at 10:38 +0530, Vignesh R wrote:
> 
> On 26/02/19 1:59 PM, Ley Foon Tan wrote:
> > 
> > Use quad write if SPI_TX_QUAD flag is set.
> > 
> How was the patch tested? Could you add that info to commit msg?
Tested on Stratix 10 SoC board.
Will update commit message.
> 
> > 
> > Signed-off-by: Ley Foon Tan 
> > ---
> >  drivers/spi/cadence_qspi.c | 2 +-
> >  drivers/spi/cadence_qspi.h | 2 +-
> >  drivers/spi/cadence_qspi_apb.c | 7 ++-
> >  3 files changed, 8 insertions(+), 3 deletions(-)
> >  mode change 100644 => 100755 drivers/spi/cadence_qspi.c
> >  mode change 100644 => 100755 drivers/spi/cadence_qspi.h
> >  mode change 100644 => 100755 drivers/spi/cadence_qspi_apb.c
> > 
> Why are the permissions being changed? Please keep it as is
Change it accidentally. Will fix this.
> 
> > 
> > diff --git a/drivers/spi/cadence_qspi.c
> > b/drivers/spi/cadence_qspi.c
> > old mode 100644
> > new mode 100755
> > index 11fce9c4fe..efdb178450
> > --- a/drivers/spi/cadence_qspi.c
> > +++ b/drivers/spi/cadence_qspi.c
> > @@ -256,7 +256,7 @@ static int cadence_spi_xfer(struct udevice
> > *dev, unsigned int bitlen,
> >     break;
> >     case CQSPI_INDIRECT_WRITE:
> >     err =
> > cadence_qspi_apb_indirect_write_setup
> > -   (plat, priv->cmd_len, cmd_buf);
> > +   (plat, priv->cmd_len, dm_plat-
> > >mode, cmd_buf);
> >     if (!err) {
> >     err =
> > cadence_qspi_apb_indirect_write_execute
> >     (plat, data_bytes, dout);
> > diff --git a/drivers/spi/cadence_qspi.h
> > b/drivers/spi/cadence_qspi.h
> > old mode 100644
> > new mode 100755
> > index 055900def0..b491407130
> > --- a/drivers/spi/cadence_qspi.h
> > +++ b/drivers/spi/cadence_qspi.h
> > @@ -60,7 +60,7 @@ int cadence_qspi_apb_indirect_read_setup(struct
> > cadence_spi_platdata *plat,
> >  int cadence_qspi_apb_indirect_read_execute(struct
> > cadence_spi_platdata *plat,
> >     unsigned int rxlen, u8 *rxbuf);
> >  int cadence_qspi_apb_indirect_write_setup(struct
> > cadence_spi_platdata *plat,
> > -   unsigned int cmdlen, const u8 *cmdbuf);
> > +   unsigned int cmdlen, unsigned int tx_width, const u8
> > *cmdbuf);
> >  int cadence_qspi_apb_indirect_write_execute(struct
> > cadence_spi_platdata *plat,
> >     unsigned int txlen, const u8 *txbuf);
> >  
> > diff --git a/drivers/spi/cadence_qspi_apb.c
> > b/drivers/spi/cadence_qspi_apb.c
> > old mode 100644
> > new mode 100755
> > index a8af352030..55a7501913
> > --- a/drivers/spi/cadence_qspi_apb.c
> > +++ b/drivers/spi/cadence_qspi_apb.c
> > @@ -77,6 +77,7 @@
> >  
> >  #defineCQSPI_REG_WR_INSTR  0x08
> >  #defineCQSPI_REG_WR_INSTR_OPCODE_LSB   0
> > +#defineCQSPI_REG_WR_INSTR_TYPE_DATA_LSB16
> >  
> >  #defineCQSPI_REG_DELAY 0x0C
> >  #defineCQSPI_REG_DELAY_TSLCH_LSB   0
> > @@ -686,7 +687,7 @@ failrd:
> >  
> >  /* Opcode + Address (3/4 bytes) */
> >  int cadence_qspi_apb_indirect_write_setup(struct
> > cadence_spi_platdata *plat,
> > -   unsigned int cmdlen, const u8 *cmdbuf)
> > +   unsigned int cmdlen, unsigned int tx_width, const u8
> > *cmdbuf)
> >  {
> >     unsigned int reg;
> >     unsigned int addr_bytes = cmdlen > 4 ? 4 : 3;
> > @@ -702,6 +703,10 @@ int
> > cadence_qspi_apb_indirect_write_setup(struct cadence_spi_platdata
> > *plat,
> >  
> >     /* Configure the opcode */
> >     reg = cmdbuf[0] << CQSPI_REG_WR_INSTR_OPCODE_LSB;
> > +
> > +   if (tx_width & SPI_TX_QUAD)
> > +   reg |= CQSPI_INST_TYPE_QUAD <<
> > CQSPI_REG_WR_INSTR_TYPE_DATA_LSB;
> > +
> >     writel(reg, plat->regbase + CQSPI_REG_WR_INSTR);
> >  
> >     /* Setup write address. */
> > 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] kbuild: make arch-dtbs target PHONY

[Masahiro Yamada]

On Wed, Feb 27, 2019 at 4:21 AM Stephen Warren  wrote:
>
> From: Stephen Warren 
>
> Without this, the arch-dtbs target only gets evaluated when building
> U-Boot the first time, not when re-building (incrementally building)
> U-Boot. Thus incremental builds ignore changes to DTB files.
>
> Signed-off-by: Stephen Warren 


Reviewed-by: Masahiro Yamada 



> ---
>  dts/Makefile | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/dts/Makefile b/dts/Makefile
> index a7a604303cc6..4970223b3d2e 100644
> --- a/dts/Makefile
> +++ b/dts/Makefile
> @@ -40,6 +40,7 @@ endif
> echo >&2;   \
> /bin/false)
>
> +PHONY += arch-dtbs
>  arch-dtbs:
> $(Q)$(MAKE) $(build)=$(ARCH_PATH) dtbs
>
> --
> 2.20.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot



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

Re: [U-Boot] [PATCH] spi: cadence_qspi: Add quad write support

[Vignesh R]

On 26/02/19 1:59 PM, Ley Foon Tan wrote:
> Use quad write if SPI_TX_QUAD flag is set.
> 

How was the patch tested? Could you add that info to commit msg?

> Signed-off-by: Ley Foon Tan 
> ---
>  drivers/spi/cadence_qspi.c | 2 +-
>  drivers/spi/cadence_qspi.h | 2 +-
>  drivers/spi/cadence_qspi_apb.c | 7 ++-
>  3 files changed, 8 insertions(+), 3 deletions(-)
>  mode change 100644 => 100755 drivers/spi/cadence_qspi.c
>  mode change 100644 => 100755 drivers/spi/cadence_qspi.h
>  mode change 100644 => 100755 drivers/spi/cadence_qspi_apb.c
> 

Why are the permissions being changed? Please keep it as is

> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> old mode 100644
> new mode 100755
> index 11fce9c4fe..efdb178450
> --- a/drivers/spi/cadence_qspi.c
> +++ b/drivers/spi/cadence_qspi.c
> @@ -256,7 +256,7 @@ static int cadence_spi_xfer(struct udevice *dev, unsigned 
> int bitlen,
>   break;
>   case CQSPI_INDIRECT_WRITE:
>   err = cadence_qspi_apb_indirect_write_setup
> - (plat, priv->cmd_len, cmd_buf);
> + (plat, priv->cmd_len, dm_plat->mode, cmd_buf);
>   if (!err) {
>   err = cadence_qspi_apb_indirect_write_execute
>   (plat, data_bytes, dout);
> diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h
> old mode 100644
> new mode 100755
> index 055900def0..b491407130
> --- a/drivers/spi/cadence_qspi.h
> +++ b/drivers/spi/cadence_qspi.h
> @@ -60,7 +60,7 @@ int cadence_qspi_apb_indirect_read_setup(struct 
> cadence_spi_platdata *plat,
>  int cadence_qspi_apb_indirect_read_execute(struct cadence_spi_platdata *plat,
>   unsigned int rxlen, u8 *rxbuf);
>  int cadence_qspi_apb_indirect_write_setup(struct cadence_spi_platdata *plat,
> - unsigned int cmdlen, const u8 *cmdbuf);
> + unsigned int cmdlen, unsigned int tx_width, const u8 *cmdbuf);
>  int cadence_qspi_apb_indirect_write_execute(struct cadence_spi_platdata 
> *plat,
>   unsigned int txlen, const u8 *txbuf);
>  
> diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
> old mode 100644
> new mode 100755
> index a8af352030..55a7501913
> --- a/drivers/spi/cadence_qspi_apb.c
> +++ b/drivers/spi/cadence_qspi_apb.c
> @@ -77,6 +77,7 @@
>  
>  #define  CQSPI_REG_WR_INSTR  0x08
>  #define  CQSPI_REG_WR_INSTR_OPCODE_LSB   0
> +#define  CQSPI_REG_WR_INSTR_TYPE_DATA_LSB16
>  
>  #define  CQSPI_REG_DELAY 0x0C
>  #define  CQSPI_REG_DELAY_TSLCH_LSB   0
> @@ -686,7 +687,7 @@ failrd:
>  
>  /* Opcode + Address (3/4 bytes) */
>  int cadence_qspi_apb_indirect_write_setup(struct cadence_spi_platdata *plat,
> - unsigned int cmdlen, const u8 *cmdbuf)
> + unsigned int cmdlen, unsigned int tx_width, const u8 *cmdbuf)
>  {
>   unsigned int reg;
>   unsigned int addr_bytes = cmdlen > 4 ? 4 : 3;
> @@ -702,6 +703,10 @@ int cadence_qspi_apb_indirect_write_setup(struct 
> cadence_spi_platdata *plat,
>  
>   /* Configure the opcode */
>   reg = cmdbuf[0] << CQSPI_REG_WR_INSTR_OPCODE_LSB;
> +
> + if (tx_width & SPI_TX_QUAD)
> + reg |= CQSPI_INST_TYPE_QUAD << CQSPI_REG_WR_INSTR_TYPE_DATA_LSB;
> +
>   writel(reg, plat->regbase + CQSPI_REG_WR_INSTR);
>  
>   /* Setup write address. */
> 

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

Re: [U-Boot] [PATCH 2/2] kbuild: fix DTB .cmd source variable

[Masahiro Yamada]

On Wed, Feb 27, 2019 at 4:20 AM Stephen Warren  wrote:
>
> From: Stephen Warren 
>
> *.dts are processed using a custom command, then the C pre-processor is
> run on them, then they are compiled using dtc. Thus, the dependency
> files generated by both cpp and dtc reference a temporary file name
> rather than the actual source file. While this information isn't used
> for any purpose by the build system,

Right, not used in U-Boot.

The 'source_*' is only used by scripts/mod/sumversion.c in Linux.


Anyway, the .*.cmd files will look better.



Reviewed-by: Masahiro Yamada 



> and hence this causes no functional
> issue, it does cause the dependency files to contain invalid and
> confusing data, which is unhelpful while debugging build problems. Fix
> this using sed.
>
> Signed-off-by: Stephen Warren 
> ---


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

Re: [U-Boot] [PATCH v2] configs: dra7xx_evm: Remove ENV_IS_IN_FAT

[Lokesh Vutla]

On 26/02/19 10:45 PM, Faiz Abbas wrote:
> With U-boot supporting environment in multiple places, enable only
> ENV_IS_IN_EMMC
> 
> Signed-off-by: Faiz Abbas 

Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh

> ---
>  configs/dra7xx_evm_defconfig| 1 +
>  configs/dra7xx_hs_evm_defconfig | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/configs/dra7xx_evm_defconfig b/configs/dra7xx_evm_defconfig
> index ef061501ef..3f25a2ec28 100644
> --- a/configs/dra7xx_evm_defconfig
> +++ b/configs/dra7xx_evm_defconfig
> @@ -36,6 +36,7 @@ CONFIG_OF_LIST="dra7-evm dra72-evm dra72-evm-revc dra71-evm 
> dra76-evm"
>  CONFIG_SPL_MULTI_DTB_FIT=y
>  CONFIG_SPL_MULTI_DTB_FIT_UNCOMPRESS_SZ=0x9000
>  CONFIG_OF_SPL_REMOVE_PROPS="clocks clock-names interrupt-parent"
> +# CONFIG_ENV_IS_IN_FAT is not set
>  CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
>  CONFIG_DM=y
> diff --git a/configs/dra7xx_hs_evm_defconfig b/configs/dra7xx_hs_evm_defconfig
> index 3cf7659496..ee28e0c6ec 100644
> --- a/configs/dra7xx_hs_evm_defconfig
> +++ b/configs/dra7xx_hs_evm_defconfig
> @@ -40,6 +40,7 @@ CONFIG_OF_LIST="dra7-evm dra72-evm dra72-evm-revc dra71-evm 
> dra76-evm"
>  CONFIG_SPL_MULTI_DTB_FIT=y
>  CONFIG_SPL_MULTI_DTB_FIT_UNCOMPRESS_SZ=0x9000
>  CONFIG_OF_SPL_REMOVE_PROPS="clocks clock-names interrupt-parent"
> +# CONFIG_ENV_IS_IN_FAT is not set
>  CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
>  CONFIG_DM=y
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] cmd: efidebug: add memmap command

[Meenakshi Aggarwal]

Please ignore, it is sent by mistake.


> -Original Message-
> From: U-Boot  On Behalf Of Meenakshi
> Aggarwal
> Sent: Wednesday, February 27, 2019 2:41 PM
> To: u-boot@lists.denx.de; Prabhakar Kushwaha
> 
> Subject: [U-Boot] [PATCH 1/2] cmd: efidebug: add memmap command
> 
> From: AKASHI Takahiro 
> 
> "memmap" command prints uefi-specific memory map information.
> => efi memmap
> Type StartEnd  Attributes
>    ==
> CONVENTIONAL 4000-7de27000 WB
> RUNTIME DATA 7de27000-7de28000 WB|RT
> RESERVED 7de28000-7de2a000 WB
> RUNTIME DATA 7de2a000-7de2b000 WB|RT
> RESERVED 7de2b000-7de2c000 WB
> RUNTIME DATA 7de2c000-7de2d000 WB|RT
> LOADER DATA  7de2d000-7ff37000 WB
> RUNTIME CODE 7ff37000-7ff38000 WB|RT
> LOADER DATA  7ff38000-8000 WB
> 
> Signed-off-by: AKASHI Takahiro 
> Reviewed-by: Heinrich Schuchardt 
> ---
>  cmd/efidebug.c | 127
> -
>  1 file changed, 126 insertions(+), 1 deletion(-)
> 
> diff --git a/cmd/efidebug.c b/cmd/efidebug.c index e3a2d09..5072a7b 100644
> --- a/cmd/efidebug.c
> +++ b/cmd/efidebug.c
> @@ -335,6 +335,127 @@ static int do_efi_show_images(cmd_tbl_t *cmdtp, int
> flag,
>   return CMD_RET_SUCCESS;
>  }
> 
> +static const char * const efi_mem_type_string[] = {
> + [EFI_RESERVED_MEMORY_TYPE] = "RESERVED",
> + [EFI_LOADER_CODE] = "LOADER CODE",
> + [EFI_LOADER_DATA] = "LOADER DATA",
> + [EFI_BOOT_SERVICES_CODE] = "BOOT CODE",
> + [EFI_BOOT_SERVICES_DATA] = "BOOT DATA",
> + [EFI_RUNTIME_SERVICES_CODE] = "RUNTIME CODE",
> + [EFI_RUNTIME_SERVICES_DATA] = "RUNTIME DATA",
> + [EFI_CONVENTIONAL_MEMORY] = "CONVENTIONAL",
> + [EFI_UNUSABLE_MEMORY] = "UNUSABLE MEM",
> + [EFI_ACPI_RECLAIM_MEMORY] = "ACPI RECLAIM MEM",
> + [EFI_ACPI_MEMORY_NVS] = "ACPI NVS",
> + [EFI_MMAP_IO] = "IO",
> + [EFI_MMAP_IO_PORT] = "IO PORT",
> + [EFI_PAL_CODE] = "PAL",
> +};
> +
> +static const struct efi_mem_attrs {
> + const u64 bit;
> + const char *text;
> +} efi_mem_attrs[] = {
> + {EFI_MEMORY_UC, "UC"},
> + {EFI_MEMORY_UC, "UC"},
> + {EFI_MEMORY_WC, "WC"},
> + {EFI_MEMORY_WT, "WT"},
> + {EFI_MEMORY_WB, "WB"},
> + {EFI_MEMORY_UCE, "UCE"},
> + {EFI_MEMORY_WP, "WP"},
> + {EFI_MEMORY_RP, "RP"},
> + {EFI_MEMORY_XP, "WP"},
> + {EFI_MEMORY_NV, "NV"},
> + {EFI_MEMORY_MORE_RELIABLE, "REL"},
> + {EFI_MEMORY_RO, "RO"},
> + {EFI_MEMORY_RUNTIME, "RT"},
> +};
> +
> +/**
> + * print_memory_attributes() - print memory map attributes
> + * @attributes:  Attribute value
> + *
> + * Print memory map attributes
> + */
> +static void print_memory_attributes(u64 attributes) {
> + int sep, i;
> +
> + for (sep = 0, i = 0; i < ARRAY_SIZE(efi_mem_attrs); i++)
> + if (attributes & efi_mem_attrs[i].bit) {
> + if (sep) {
> + putc('|');
> + } else {
> + putc(' ');
> + sep = 1;
> + }
> + puts(efi_mem_attrs[i].text);
> + }
> +}
> +
> +#define EFI_PHYS_ADDR_WIDTH (int)(sizeof(efi_physical_addr_t) * 2)
> +
> +/**
> + * do_efi_show_memmap() - show UEFI memory map
> + *
> + * @cmdtp:   Command table
> + * @flag:Command flag
> + * @argc:Number of arguments
> + * @argv:Argument array
> + * Return:   CMD_RET_SUCCESS on success, CMD_RET_RET_FAILURE on
> failure
> + *
> + * Implement efidebug "memmap" sub-command.
> + * Show UEFI memory map.
> + */
> +static int do_efi_show_memmap(cmd_tbl_t *cmdtp, int flag,
> +   int argc, char * const argv[]) {
> + struct efi_mem_desc *memmap = NULL, *map;
> + efi_uintn_t map_size = 0;
> + const char *type;
> + int i;
> + efi_status_t ret;
> +
> + ret = EFI_CALL(BS->get_memory_map(_size, memmap, NULL,
> NULL, NULL));
> + if (ret == EFI_BUFFER_TOO_SMALL) {
> + map_size += sizeof(struct efi_mem_desc); /* for my own */
> + ret = EFI_CALL(BS->allocate_pool(EFI_LOADER_DATA,
> +  map_size, (void
> *)));
> + if (ret != EFI_SUCCESS)
> + return CMD_RET_FAILURE;
> + ret = EFI_CALL(BS->get_memory_map(_size, memmap,
> +   NULL, NULL, NULL));
> + }
> + if (ret != EFI_SUCCESS) {
> + EFI_CALL(BS->free_pool(memmap));
> + return CMD_RET_FAILURE;
> + }
> +
> + printf("Type Start%.*s End%.*s Attributes\n",
> +EFI_PHYS_ADDR_WIDTH - 5, spc, EFI_PHYS_ADDR_WIDTH - 3, spc);
> + printf(" 

[U-Boot] [PATCH 2/2] mc : Reduce MC memory size to 128M

[Meenakshi Aggarwal]

ls2088, ls1088 : minimum MC Memory size is 128 MB
lx2 : minimum MC memory size is 256 MB

Signed-off-by: Meenakshi Aggarwal 
---
 drivers/net/fsl-mc/mc.c  | 23 +++
 include/configs/ls1088a_common.h |  2 +-
 include/configs/ls2080a_common.h |  2 +-
 include/configs/lx2160a_common.h |  2 +-
 4 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
index a51b8a4..a56edc3 100644
--- a/drivers/net/fsl-mc/mc.c
+++ b/drivers/net/fsl-mc/mc.c
@@ -28,6 +28,7 @@
 #define MC_MEM_SIZE_ENV_VAR"mcmemsize"
 #define MC_BOOT_TIMEOUT_ENV_VAR"mcboottimeout"
 #define MC_BOOT_ENV_VAR"mcinitcmd"
+#define MC_DRAM_BLOCK_DEFAULT_SIZE (512UL * 1024 * 1024)
 
 DECLARE_GLOBAL_DATA_PTR;
 static int mc_memset_resv_ram;
@@ -680,7 +681,8 @@ int mc_init(u64 mc_fw_addr, u64 mc_dpc_addr)
size_t mc_ram_size = mc_get_dram_block_size();
 
mc_ram_num_256mb_blocks = mc_ram_size / MC_RAM_SIZE_ALIGNMENT;
-   if (mc_ram_num_256mb_blocks < 1 || mc_ram_num_256mb_blocks > 0xff) {
+
+   if (mc_ram_num_256mb_blocks >= 0xff) {
error = -EINVAL;
printf("fsl-mc: ERROR: invalid MC private RAM size (%lu)\n",
   mc_ram_size);
@@ -688,6 +690,13 @@ int mc_init(u64 mc_fw_addr, u64 mc_dpc_addr)
}
 
/*
+* To support 128 MB DDR Size for MC
+*/
+   if (mc_ram_num_256mb_blocks == 0) {
+   mc_ram_num_256mb_blocks = 0xFF;
+   }
+
+   /*
 * Management Complex cores should be held at reset out of POR.
 * U-Boot should be the first software to touch MC. To be safe,
 * we reset all cores again by setting GCR1 to 0. It doesn't do
@@ -727,8 +736,14 @@ int mc_init(u64 mc_fw_addr, u64 mc_dpc_addr)
/*
 * Tell MC what is the address range of the DRAM block assigned to it:
 */
-   reg_mcfbalr = (u32)mc_ram_addr |
- (mc_ram_num_256mb_blocks - 1);
+   if (mc_ram_num_256mb_blocks < 0xFF) {
+   reg_mcfbalr = (u32)mc_ram_addr |
+   (mc_ram_num_256mb_blocks - 1);
+   } else {
+   reg_mcfbalr = (u32)mc_ram_addr |
+   (mc_ram_num_256mb_blocks);
+   }
+
out_le32(_ccsr_regs->reg_mcfbalr, reg_mcfbalr);
out_le32(_ccsr_regs->reg_mcfbahr,
 (u32)(mc_ram_addr >> 32));
@@ -878,7 +893,7 @@ unsigned long mc_get_dram_block_size(void)
   "\' environment variable: %lu\n",
   dram_block_size);
 
-   dram_block_size = CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE;
+   dram_block_size = MC_DRAM_BLOCK_DEFAULT_SIZE;
}
}
 
diff --git a/include/configs/ls1088a_common.h b/include/configs/ls1088a_common.h
index b663937..fa9c8c8 100644
--- a/include/configs/ls1088a_common.h
+++ b/include/configs/ls1088a_common.h
@@ -151,7 +151,7 @@ unsigned long long get_qixis_addr(void);
  */
 
 #if defined(CONFIG_FSL_MC_ENET)
-#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE   (512UL * 1024 * 1024)
+#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE   (128UL * 1024 * 1024)
 #endif
 /* Command line configuration */
 #define CONFIG_CMD_CACHE
diff --git a/include/configs/ls2080a_common.h b/include/configs/ls2080a_common.h
index 0a6c90d..682f068 100644
--- a/include/configs/ls2080a_common.h
+++ b/include/configs/ls2080a_common.h
@@ -155,7 +155,7 @@ unsigned long long get_qixis_addr(void);
  * 512MB aligned, so the min size to hide is 512MB.
  */
 #ifdef CONFIG_FSL_MC_ENET
-#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE   (512UL * 1024 * 1024)
+#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE   (128UL * 1024 * 1024)
 #endif
 
 /* Command line configuration */
diff --git a/include/configs/lx2160a_common.h b/include/configs/lx2160a_common.h
index 4b5608b..637619c 100644
--- a/include/configs/lx2160a_common.h
+++ b/include/configs/lx2160a_common.h
@@ -100,7 +100,7 @@
  * 512MB aligned, so the min size to hide is 512MB.
  */
 #ifdef CONFIG_FSL_MC_ENET
-#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE   (512UL * 1024 * 1024)
+#define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE   (256UL * 1024 * 1024)
 #endif
 
 /* I2C bus multiplexer */
-- 
1.9.1

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

[U-Boot] [PATCH 1/2] cmd: efidebug: add memmap command

[Meenakshi Aggarwal]

From: AKASHI Takahiro 

"memmap" command prints uefi-specific memory map information.
=> efi memmap
Type StartEnd  Attributes
   ==
CONVENTIONAL 4000-7de27000 WB
RUNTIME DATA 7de27000-7de28000 WB|RT
RESERVED 7de28000-7de2a000 WB
RUNTIME DATA 7de2a000-7de2b000 WB|RT
RESERVED 7de2b000-7de2c000 WB
RUNTIME DATA 7de2c000-7de2d000 WB|RT
LOADER DATA  7de2d000-7ff37000 WB
RUNTIME CODE 7ff37000-7ff38000 WB|RT
LOADER DATA  7ff38000-8000 WB

Signed-off-by: AKASHI Takahiro 
Reviewed-by: Heinrich Schuchardt 
---
 cmd/efidebug.c | 127 -
 1 file changed, 126 insertions(+), 1 deletion(-)

diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index e3a2d09..5072a7b 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -335,6 +335,127 @@ static int do_efi_show_images(cmd_tbl_t *cmdtp, int flag,
return CMD_RET_SUCCESS;
 }
 
+static const char * const efi_mem_type_string[] = {
+   [EFI_RESERVED_MEMORY_TYPE] = "RESERVED",
+   [EFI_LOADER_CODE] = "LOADER CODE",
+   [EFI_LOADER_DATA] = "LOADER DATA",
+   [EFI_BOOT_SERVICES_CODE] = "BOOT CODE",
+   [EFI_BOOT_SERVICES_DATA] = "BOOT DATA",
+   [EFI_RUNTIME_SERVICES_CODE] = "RUNTIME CODE",
+   [EFI_RUNTIME_SERVICES_DATA] = "RUNTIME DATA",
+   [EFI_CONVENTIONAL_MEMORY] = "CONVENTIONAL",
+   [EFI_UNUSABLE_MEMORY] = "UNUSABLE MEM",
+   [EFI_ACPI_RECLAIM_MEMORY] = "ACPI RECLAIM MEM",
+   [EFI_ACPI_MEMORY_NVS] = "ACPI NVS",
+   [EFI_MMAP_IO] = "IO",
+   [EFI_MMAP_IO_PORT] = "IO PORT",
+   [EFI_PAL_CODE] = "PAL",
+};
+
+static const struct efi_mem_attrs {
+   const u64 bit;
+   const char *text;
+} efi_mem_attrs[] = {
+   {EFI_MEMORY_UC, "UC"},
+   {EFI_MEMORY_UC, "UC"},
+   {EFI_MEMORY_WC, "WC"},
+   {EFI_MEMORY_WT, "WT"},
+   {EFI_MEMORY_WB, "WB"},
+   {EFI_MEMORY_UCE, "UCE"},
+   {EFI_MEMORY_WP, "WP"},
+   {EFI_MEMORY_RP, "RP"},
+   {EFI_MEMORY_XP, "WP"},
+   {EFI_MEMORY_NV, "NV"},
+   {EFI_MEMORY_MORE_RELIABLE, "REL"},
+   {EFI_MEMORY_RO, "RO"},
+   {EFI_MEMORY_RUNTIME, "RT"},
+};
+
+/**
+ * print_memory_attributes() - print memory map attributes
+ * @attributes:Attribute value
+ *
+ * Print memory map attributes
+ */
+static void print_memory_attributes(u64 attributes)
+{
+   int sep, i;
+
+   for (sep = 0, i = 0; i < ARRAY_SIZE(efi_mem_attrs); i++)
+   if (attributes & efi_mem_attrs[i].bit) {
+   if (sep) {
+   putc('|');
+   } else {
+   putc(' ');
+   sep = 1;
+   }
+   puts(efi_mem_attrs[i].text);
+   }
+}
+
+#define EFI_PHYS_ADDR_WIDTH (int)(sizeof(efi_physical_addr_t) * 2)
+
+/**
+ * do_efi_show_memmap() - show UEFI memory map
+ *
+ * @cmdtp: Command table
+ * @flag:  Command flag
+ * @argc:  Number of arguments
+ * @argv:  Argument array
+ * Return: CMD_RET_SUCCESS on success, CMD_RET_RET_FAILURE on failure
+ *
+ * Implement efidebug "memmap" sub-command.
+ * Show UEFI memory map.
+ */
+static int do_efi_show_memmap(cmd_tbl_t *cmdtp, int flag,
+ int argc, char * const argv[])
+{
+   struct efi_mem_desc *memmap = NULL, *map;
+   efi_uintn_t map_size = 0;
+   const char *type;
+   int i;
+   efi_status_t ret;
+
+   ret = EFI_CALL(BS->get_memory_map(_size, memmap, NULL, NULL, NULL));
+   if (ret == EFI_BUFFER_TOO_SMALL) {
+   map_size += sizeof(struct efi_mem_desc); /* for my own */
+   ret = EFI_CALL(BS->allocate_pool(EFI_LOADER_DATA,
+map_size, (void *)));
+   if (ret != EFI_SUCCESS)
+   return CMD_RET_FAILURE;
+   ret = EFI_CALL(BS->get_memory_map(_size, memmap,
+ NULL, NULL, NULL));
+   }
+   if (ret != EFI_SUCCESS) {
+   EFI_CALL(BS->free_pool(memmap));
+   return CMD_RET_FAILURE;
+   }
+
+   printf("Type Start%.*s End%.*s Attributes\n",
+  EFI_PHYS_ADDR_WIDTH - 5, spc, EFI_PHYS_ADDR_WIDTH - 3, spc);
+   printf(" %.*s %.*s ==\n",
+  EFI_PHYS_ADDR_WIDTH, sep, EFI_PHYS_ADDR_WIDTH, sep);
+   for (i = 0, map = memmap; i < map_size / sizeof(*map); map++, i++) {
+   if (map->type < EFI_MAX_MEMORY_TYPE)
+   type = efi_mem_type_string[map->type];
+   else
+   type = "(unknown)";
+
+   printf("%-16s %.*llx-%.*llx", 

Re: [U-Boot] [PATCH 1/2] kbuild: make arch-dtbs target PHONY

[Masahiro Yamada]

On Wed, Feb 27, 2019 at 11:17 AM Masahiro Yamada
 wrote:
>
> On Wed, Feb 27, 2019 at 4:21 AM Stephen Warren  wrote:
> >
> > From: Stephen Warren 
> >
> > Without this, the arch-dtbs target only gets evaluated when building
> > U-Boot the first time, not when re-building (incrementally building)
> > U-Boot. Thus incremental builds ignore changes to DTB files.
>
>
> Really?
>
> I tested "touch DT, then incremental build",
> and it correctly re-compiled device tree.
>
>
> I attached the log of the following build sequence:
>
> [1] make jetson-tk1_defconfig
> [2] make CROSS_COMPILE=arm-linux-gnueabihf-
> [3] touch  arch/arm/dts/tegra124-jetson-tk1.dts
> [4] make CROSS_COMPILE=arm-linux-gnueabihf-
>
>

Hmm, OK. Understood.

The jetson DT was recompiled,
but the other tegra DT files were not.


So, I am fine with this patch,
but this Makefile is problematic already.




Looking into dts/Makefile,
I noticed there are two ways to descend into arch/*/dts.


$(DTB): $(dtb_depends)
ifeq ($(EXT_DTB),)
$(Q)$(MAKE) $(build)=$(ARCH_PATH) $@  <- [1]
endif
$(Q)test -e $@ || ( \
echo >&2; \
echo >&2 "Device Tree Source is not correctly specified."; \
echo >&2 "Please define 'CONFIG_DEFAULT_DEVICE_TREE'"; \
echo >&2 "or build with 'DEVICE_TREE=' argument"; \
echo >&2; \
/bin/false)

arch-dtbs:
$(Q)$(MAKE) $(build)=$(ARCH_PATH) dtbs  <- [2]



[1] and [2] would cause a race in parallel building
and might produce an invalid DTB.


I do not understand commit 27cb7300ffda7a3f1581f0f5a2d3bfe59b97ad67




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

Re: [U-Boot] [PATCH 1/2] kbuild: make arch-dtbs target PHONY

[Masahiro Yamada]

On Wed, Feb 27, 2019 at 4:21 AM Stephen Warren  wrote:
>
> From: Stephen Warren 
>
> Without this, the arch-dtbs target only gets evaluated when building
> U-Boot the first time, not when re-building (incrementally building)
> U-Boot. Thus incremental builds ignore changes to DTB files.


Really?

I tested "touch DT, then incremental build",
and it correctly re-compiled device tree.


I attached the log of the following build sequence:

[1] make jetson-tk1_defconfig
[2] make CROSS_COMPILE=arm-linux-gnueabihf-
[3] touch  arch/arm/dts/tegra124-jetson-tk1.dts
[4] make CROSS_COMPILE=arm-linux-gnueabihf-






masahiro@pug:~/ref/u-boot$ git log --oneline  -1
b3820ba Merge tag 'efi-2019-04-rc3' of https://github.com/xypron2/u-boot
masahiro@pug:~/ref/u-boot$ make jetson-tk1_defconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  YACCscripts/kconfig/zconf.tab.c
  LEX scripts/kconfig/zconf.lex.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#
masahiro@pug:~/ref/u-boot$ make CROSS_COMPILE=arm-linux-gnueabihf-
scripts/kconfig/conf  --syncconfig Kconfig
  CHK include/config.h
  UPD include/config.h
  CFG u-boot.cfg
  GEN include/autoconf.mk
  GEN include/autoconf.mk.dep
  CFG spl/u-boot.cfg
  GEN spl/include/autoconf.mk
  CHK include/config/uboot.release
  UPD include/config/uboot.release
  CHK include/generated/version_autogenerated.h
  UPD include/generated/version_autogenerated.h
  CHK include/generated/timestamp_autogenerated.h
  UPD include/generated/timestamp_autogenerated.h
  CC  lib/asm-offsets.s
  CHK include/generated/generic-asm-offsets.h
  UPD include/generated/generic-asm-offsets.h
  CC  arch/arm/lib/asm-offsets.s
  CHK include/generated/asm-offsets.h
  UPD include/generated/asm-offsets.h
  SHIPPED scripts/dtc/pylibfdt/libfdt.i
  PYMOD   scripts/dtc/pylibfdt/_libfdt.so
  HOSTCC  scripts/dtc/dtc.o
  HOSTCC  scripts/dtc/flattree.o
  HOSTCC  scripts/dtc/fstree.o
  HOSTCC  scripts/dtc/data.o
  HOSTCC  scripts/dtc/livetree.o
  HOSTCC  scripts/dtc/treesource.o
  HOSTCC  scripts/dtc/srcpos.o
  HOSTCC  scripts/dtc/checks.o
  HOSTCC  scripts/dtc/util.o
  LEX scripts/dtc/dtc-lexer.lex.c
  YACCscripts/dtc/dtc-parser.tab.h
  HOSTCC  scripts/dtc/dtc-lexer.lex.o
  YACCscripts/dtc/dtc-parser.tab.c
  HOSTCC  scripts/dtc/dtc-parser.tab.o
  HOSTLD  scripts/dtc/dtc
  HOSTCC  tools/gen_eth_addr
  HOSTCC  tools/gen_ethaddr_crc.o
  WRAPtools/lib/crc8.c
  HOSTCC  tools/lib/crc8.o
  HOSTLD  tools/gen_ethaddr_crc
  HOSTCC  tools/img2srec
  HOSTCC  tools/mkenvimage.o
  HOSTCC  tools/os_support.o
  WRAPtools/lib/crc32.c
  HOSTCC  tools/lib/crc32.o
  HOSTLD  tools/mkenvimage
  HOSTCC  tools/aisimage.o
  HOSTCC  tools/atmelimage.o
  WRAPtools/common/bootm.c
  HOSTCC  tools/common/bootm.o
  HOSTCC  tools/default_image.o
  WRAPtools/lib/fdtdec_common.c
  HOSTCC  tools/lib/fdtdec_common.o
  WRAPtools/lib/fdtdec.c
  HOSTCC  tools/lib/fdtdec.o
  HOSTCC  tools/fit_common.o
  HOSTCC  tools/fit_image.o
  WRAPtools/common/image-fit.c
  HOSTCC  tools/common/image-fit.o
  HOSTCC  tools/image-host.o
  WRAPtools/common/image.c
  HOSTCC  tools/common/image.o
  HOSTCC  tools/imagetool.o
  HOSTCC  tools/imximage.o
  HOSTCC  tools/imx8image.o
  HOSTCC  tools/imx8mimage.o
  HOSTCC  tools/kwbimage.o
  WRAPtools/lib/md5.c
  HOSTCC  tools/lib/md5.o
  HOSTCC  tools/lpc32xximage.o
  HOSTCC  tools/mxsimage.o
  HOSTCC  tools/omapimage.o
  HOSTCC  tools/pblimage.o
  HOSTCC  tools/pbl_crc32.o
  HOSTCC  tools/vybridimage.o
  HOSTCC  tools/stm32image.o
  WRAPtools/lib/rc4.c
  HOSTCC  tools/lib/rc4.o
  HOSTCC  tools/rkcommon.o
  HOSTCC  tools/rkimage.o
  HOSTCC  tools/rksd.o
  HOSTCC  tools/rkspi.o
  HOSTCC  tools/socfpgaimage.o
  WRAPtools/lib/crc16.c
  HOSTCC  tools/lib/crc16.o
  WRAPtools/lib/sha1.c
  HOSTCC  tools/lib/sha1.o
  WRAPtools/lib/sha256.c
  HOSTCC  tools/lib/sha256.o
  WRAPtools/common/hash.c
  HOSTCC  tools/common/hash.o
  HOSTCC  tools/ublimage.o
  HOSTCC  tools/zynqimage.o
  HOSTCC  tools/zynqmpimage.o
  HOSTCC  tools/zynqmpbif.o
  HOSTCC  tools/libfdt/fdt.o
  HOSTCC  tools/libfdt/fdt_wip.o
  HOSTCC  tools/libfdt/fdt_sw.o
  HOSTCC  tools/libfdt/fdt_rw.o
  HOSTCC  tools/libfdt/fdt_strerror.o
  HOSTCC  tools/libfdt/fdt_empty_tree.o
  HOSTCC  tools/libfdt/fdt_addresses.o
  HOSTCC  tools/libfdt/fdt_overlay.o
  WRAPtools/lib/libfdt/fdt_ro.c
  HOSTCC  tools/lib/libfdt/fdt_ro.o
  WRAPtools/lib/libfdt/fdt_region.c
  HOSTCC  tools/lib/libfdt/fdt_region.o
  HOSTCC  tools/gpimage.o
  HOSTCC  tools/gpimage-common.o
  HOSTCC  tools/mtk_image.o
  HOSTCC  tools/dumpimage.o
  HOSTLD  tools/dumpimage
  HOSTCC  tools/mkimage.o
  HOSTLD  tools/mkimage
  HOSTCC  tools/proftool
  HOSTCC  tools/fdtgrep.o
  HOSTLD  tools/fdtgrep
  LD  arch/arm/cpu/built-in.o
  CC  arch/arm/cpu/armv7/cache_v7.o
  AS  

Re: [U-Boot] [PATCH 3/3] mips: fix erros on registers macros of pll-ddr-config1-nfrac for QCA956X

[Daniel Schwierzeck]

Am 15.02.19 um 12:56 schrieb Rosy Song:
> Signed-off-by: Rosy Song 

this should have some commit message explaining the error. In fact all
of your commits should have some meaningful commit message.


> ---
>  arch/mips/mach-ath79/include/mach/ar71xx_regs.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/mips/mach-ath79/include/mach/ar71xx_regs.h 
> b/arch/mips/mach-ath79/include/mach/ar71xx_regs.h
> index 380f387a26..016679e0f8 100644
> --- a/arch/mips/mach-ath79/include/mach/ar71xx_regs.h
> +++ b/arch/mips/mach-ath79/include/mach/ar71xx_regs.h
> @@ -551,7 +551,7 @@
>  #define QCA956X_PLL_CPU_CONFIG1_NFRAC_L_SHIFT0
>  #define QCA956X_PLL_CPU_CONFIG1_NFRAC_L_MASK 0x1f
>  #define QCA956X_PLL_CPU_CONFIG1_NFRAC_H_SHIFT5
> -#define QCA956X_PLL_CPU_CONFIG1_NFRAC_H_MASK 0x3fff
> +#define QCA956X_PLL_CPU_CONFIG1_NFRAC_H_MASK 0x1fff
>  #define QCA956X_PLL_CPU_CONFIG1_NINT_SHIFT   18
>  #define QCA956X_PLL_CPU_CONFIG1_NINT_MASK0x1ff
>  
> @@ -563,7 +563,7 @@
>  #define QCA956X_PLL_DDR_CONFIG1_NFRAC_L_SHIFT0
>  #define QCA956X_PLL_DDR_CONFIG1_NFRAC_L_MASK 0x1f
>  #define QCA956X_PLL_DDR_CONFIG1_NFRAC_H_SHIFT5
> -#define QCA956X_PLL_DDR_CONFIG1_NFRAC_H_MASK 0x3fff
> +#define QCA956X_PLL_DDR_CONFIG1_NFRAC_H_MASK 0x1fff
>  #define QCA956X_PLL_DDR_CONFIG1_NINT_SHIFT   18
>  #define QCA956X_PLL_DDR_CONFIG1_NINT_MASK0x1ff
>  
> 

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

Re: [U-Boot] [PATCH 2/3] mips: add initial support for qca956x referenced board

[Daniel Schwierzeck]

Am 15.02.19 um 12:56 schrieb Rosy Song:
> Signed-off-by: Rosy Song 
> ---
>  arch/mips/dts/Makefile|   1 +
>  arch/mips/dts/ap152.dts   |  48 ++
>  arch/mips/dts/qca956x.dtsi|  87 
>  arch/mips/mach-ath79/Kconfig  |  14 +
>  arch/mips/mach-ath79/Makefile |   1 +
>  .../mach-ath79/include/mach/ar71xx_regs.h |  70 +++
>  arch/mips/mach-ath79/include/mach/ath79.h |   3 +
>  arch/mips/mach-ath79/qca956x/Makefile |   5 +
>  arch/mips/mach-ath79/qca956x/clk.c| 419 ++
>  arch/mips/mach-ath79/qca956x/cpu.c|   9 +
>  arch/mips/mach-ath79/qca956x/ddr.c| 308 +
>  arch/mips/mach-ath79/qca956x/lowlevel_init.S  |  79 
>  .../mips/mach-ath79/qca956x/qca956x-ddr-tap.S | 194 
>  arch/mips/mach-ath79/reset.c  | 271 +++
>  board/qca/ap152/Kconfig   |  27 ++
>  board/qca/ap152/MAINTAINERS   |   6 +
>  board/qca/ap152/Makefile  |   3 +
>  board/qca/ap152/ap152.c   |  81 
>  configs/ap152_defconfig   |  55 +++
>  include/configs/ap152.h   |  54 +++
>  20 files changed, 1735 insertions(+)
>  create mode 100644 arch/mips/dts/ap152.dts
>  create mode 100644 arch/mips/dts/qca956x.dtsi
>  create mode 100644 arch/mips/mach-ath79/qca956x/Makefile
>  create mode 100644 arch/mips/mach-ath79/qca956x/clk.c
>  create mode 100644 arch/mips/mach-ath79/qca956x/cpu.c
>  create mode 100644 arch/mips/mach-ath79/qca956x/ddr.c
>  create mode 100644 arch/mips/mach-ath79/qca956x/lowlevel_init.S
>  create mode 100644 arch/mips/mach-ath79/qca956x/qca956x-ddr-tap.S
>  create mode 100644 board/qca/ap152/Kconfig
>  create mode 100644 board/qca/ap152/MAINTAINERS
>  create mode 100644 board/qca/ap152/Makefile
>  create mode 100644 board/qca/ap152/ap152.c
>  create mode 100644 configs/ap152_defconfig
>  create mode 100644 include/configs/ap152.h
> 
> diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
> index b94b582837..621c35f0ef 100644
> --- a/arch/mips/dts/Makefile
> +++ b/arch/mips/dts/Makefile
> @@ -2,6 +2,7 @@
>  
>  dtb-$(CONFIG_TARGET_AP121) += ap121.dtb
>  dtb-$(CONFIG_TARGET_AP143) += ap143.dtb
> +dtb-$(CONFIG_TARGET_AP152) += ap152.dtb
>  dtb-$(CONFIG_TARGET_BOSTON) += img,boston.dtb
>  dtb-$(CONFIG_TARGET_MALTA) += mti,malta.dtb
>  dtb-$(CONFIG_TARGET_PIC32MZDASK) += pic32mzda_sk.dtb
> diff --git a/arch/mips/dts/ap152.dts b/arch/mips/dts/ap152.dts
> new file mode 100644
> index 00..1722290c73
> --- /dev/null
> +++ b/arch/mips/dts/ap152.dts
> @@ -0,0 +1,48 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018 Rosy Song 
> + */
> +
> +/dts-v1/;
> +#include "qca956x.dtsi"
> +
> +/ {
> + model = "AP152 Reference Board";
> + compatible = "qca,ap152", "qca,qca956x";
> +
> + aliases {
> + spi0 = 
> + serial0 = 
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> + {
> + phy-mode = "sgmii";
> + status = "okay";
> +};
> +
> + {
> + clock-frequency = <2500>;
> +};
> +
> + {
> + clock-frequency = <2500>;
> + status = "okay";
> +};
> +
> + {
> + spi-max-frequency = <2500>;
> + status = "okay";
> + spi-flash@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "spi-flash";
> + memory-map = <0x9f00 0x0100>;
> + spi-max-frequency = <2500>;
> + reg = <0>;
> + };
> +};
> diff --git a/arch/mips/dts/qca956x.dtsi b/arch/mips/dts/qca956x.dtsi
> new file mode 100644
> index 00..6cb360b3f8
> --- /dev/null
> +++ b/arch/mips/dts/qca956x.dtsi
> @@ -0,0 +1,87 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018 Rosy Song 
> + */
> +
> +#include "skeleton.dtsi"
> +
> +/ {
> + compatible = "qca,qca956x";
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "mips,mips74Kc";
> + reg = <0>;
> + };
> + };
> +
> + clocks {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + xtal: xtal {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-output-names = "xtal";
> + };
> + };
> +
> + ahb {
> + compatible = "simple-bus";
> + ranges;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + apb {
> + compatible = "simple-bus";
> + ranges;
> +
> 

Re: [U-Boot] Extract RSA Keys from image

[Douglas Zobel]

On Tue, Feb 19, 2019 at 9:31 AM  wrote:

> I am working on an application needing the ability to update to a verified
> image from the running kernel/application.
>
> We can follow the "normal" verified image boot sequence, where the chain
> of trust is verified from U-Boot to image to execution, etc, but unsure how
> to verify a new image after already running.
>
> Is there a way to extract the public key hash from the U-Boot image so
> that we can compute a hash on an upgrade image and verify a match?  Either
> an existing tool, or some means that is accessibly from a Linux kernel that
> we could use to grab this information.
>
> I've done a lot of googling, and I have not seen any means to get to this
> once the image is already booted and running.
>
> Thank you for any guidance you can provide for this.
>
> Jeridiah Welti
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot


I'll take a stab at answering this since I recently went through
implementing verified boot.  The public key data used to verify the boot
images isn't passed on for use inside those images.  However it would be
possible to get them.  The public key is usually stored in the device tree
of the object doing the verification (SPL or u-boot).  This device tree is
stored as an object inside the FIT boot image.  The FIT boot image is
simply another device tree which contains configuration, device trees and
binary executables.

Within a running Linux image, you could read the u-boot FIT image (or SPL
FIT image if CONFIG_SPL_FIT_SIGNATURE is used) from wherever it's stored.
Use dtc tools to find the traverse to the /images/fdt-1/data object.  This
data object is the device tree containing the public key that u-boot used
to verify the kernel (or in case of SPL, this is the public key used to
verify u-boot).  Use dtc tools again to decode the device tree blob and
traverse to /signature/[signature name].  This node will have your public
key in the format:
key-somekeyname {
required = "image";
algo = "sha256,rsa2048";
rsa,r-squared = <0x1874a2f>;
rsa,modulus = <0x4a7b31eb>;
rsa,exponent = <0x0 0x10001>;
rsa,n0-inverse = <0x93a4cd16>;
rsa,num-bits = <0x800>;
key-name-hint = "somekeyname";
};

-Doug

-- 










This email and any attachments are for the exclusive use of the 
intended recipient(s) and may contain confidential and/or privileged 
information.  Inadvertent disclosure of this message does not constitute a 
waiver of any privilege, right or remedy.  If you are not the intended 
recipient, please do not directly or indirectly use, disclose or distribute 
this message, and please contact the sender and delete this email, any 
attachments and all copies.  Climate and its affiliates may use, read or 
archive email communications (including attachments) through its computer 
network, as permitted by applicable law.  Climate and its affiliates (or an 
external service provider) may also scan emails and attachments on its 
computer network to ensure systems operate efficiently and to minimize 
security risks. Thank you.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] spl: add debug print for early malloc usage

[Simon Goldschmidt]

To find out how big the early malloc heap must be in SPL, add a debug
print statement that dumps its usage before switching to relocated heap
in spl_relocate_stack_gd() via CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN.

Signed-off-by: Simon Goldschmidt 
---

 common/spl/spl.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index 2e2af1b28e..88d4b8a9bf 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -728,6 +728,8 @@ ulong spl_relocate_stack_gd(void)
 
 #if defined(CONFIG_SPL_SYS_MALLOC_SIMPLE) && CONFIG_VAL(SYS_MALLOC_F_LEN)
if (CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN) {
+   debug("SPL malloc() before relocation used 0x%lx bytes (%ld 
KB)\n",
+ gd->malloc_ptr, gd->malloc_ptr / 1024);
ptr -= CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN;
gd->malloc_base = ptr;
gd->malloc_limit = CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN;
-- 
2.17.1

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

Re: [U-Boot] ut dm pch sandbox test failures

[Tom Rini]

On Tue, Feb 26, 2019 at 12:21:53PM -0700, Stephen Warren wrote:
> On 2/25/19 4:49 PM, Stephen Warren wrote:
> >On 2/21/19 4:45 PM, Stephen Warren wrote:
> >>With the latest push to u-boot.git master branch, I'm seeing the
> >>following failures running test/py on sandbox:
> >>
> >>=> ut dm pch_base
> >>Test: dm_test_pch_base: pch.c
> >>/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/pch.c:20,
> >>dm_test_pch_base(): 0 == uclass_first_device_err(UCLASS_PCH, ):
> >>Expected 0, got -19
> >>Test: dm_test_pch_base: pch.c (flat tree)
> >>/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/pch.c:20,
> >>dm_test_pch_base(): 0 == uclass_first_device_err(UCLASS_PCH, ):
> >>Expected 0, got -19
> >>Failures: 2
> >>
> >>=> ut dm pch_ioctl
> >>Test: dm_test_pch_ioctl: pch.c
> >>/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/pch.c:44,
> >>dm_test_pch_ioctl(): 0 == uclass_first_device_err(UCLASS_PCH, ):
> >>Expected 0, got -19
> >>Test: dm_test_pch_ioctl: pch.c (flat tree)
> >>/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/pch.c:44,
> >>dm_test_pch_ioctl(): 0 == uclass_first_device_err(UCLASS_PCH, ):
> >>Expected 0, got -19
> >>Failures: 2
> >
> >This is some kind of incremental build problem; I deleted the build
> >results and retriggered Jenkins and everything worked fine. The exact same
> >issue and solution appeared and worked in two separate branches that I
> >test (u-boot.git master, u-boot-video.git master). Subsequently I found
> >that the following works fine:
> >
> >rm -rf build-sandbox/
> >git checkout 888f9aa5cac4
> >./test/py/test.py --bd sandbox --build -k test_ut
> >
> >But the following reproduces the problem:
> >
> >rm -rf build-sandbox/
> >git checkout 97f9830849c6
> >./test/py/test.py --bd sandbox --build -k test_ut
> >git checkout 888f9aa5cac4
> >./test/py/test.py --bd sandbox --build -k test_ut
> 
> I just sent "[PATCH 1/2] kbuild: make arch-dtbs target PHONY" to fix this.

Thanks for figuring this out!

-- 
Tom


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

[U-Boot] [PATCH v3 6/8] mtd: rawnand: denali: add reset handling

[Simon Goldschmidt]

This adds reset handling to the devicetree-enabled Denali NAND driver.

For backwards compatibility, only a warning is printed when failing to
get reset handles.

Signed-off-by: Simon Goldschmidt 
---

Changes in v3:
- add DM_FLAG_OS_PREPARE flag

Changes in v2:
- fix copy/paste issues
- add .remove callback to release the resets

 drivers/mtd/nand/raw/denali.h|  2 ++
 drivers/mtd/nand/raw/denali_dt.c | 15 +++
 2 files changed, 17 insertions(+)

diff --git a/drivers/mtd/nand/raw/denali.h b/drivers/mtd/nand/raw/denali.h
index 019deda094..63ae828768 100644
--- a/drivers/mtd/nand/raw/denali.h
+++ b/drivers/mtd/nand/raw/denali.h
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define DEVICE_RESET   0x0
 #define DEVICE_RESET__BANK(bank)   BIT(bank)
@@ -315,6 +316,7 @@ struct denali_nand_info {
void (*host_write)(struct denali_nand_info *denali, u32 addr, u32 data);
void (*setup_dma)(struct denali_nand_info *denali, dma_addr_t dma_addr,
  int page, int write);
+   struct reset_ctl_bulk resets;
 };
 
 #define DENALI_CAP_HW_ECC_FIXUPBIT(0)
diff --git a/drivers/mtd/nand/raw/denali_dt.c b/drivers/mtd/nand/raw/denali_dt.c
index d384b974df..0ce81324b9 100644
--- a/drivers/mtd/nand/raw/denali_dt.c
+++ b/drivers/mtd/nand/raw/denali_dt.c
@@ -131,15 +131,30 @@ static int denali_dt_probe(struct udevice *dev)
denali->clk_x_rate = 2;
}
 
+   ret = reset_get_bulk(dev, >resets);
+   if (ret)
+   dev_warn(dev, "Can't get reset: %d\n", ret);
+   else
+   reset_deassert_bulk(>resets);
+
return denali_init(denali);
 }
 
+static int denali_dt_remove(struct udevice *dev)
+{
+   struct denali_nand_info *denali = dev_get_priv(dev);
+
+   return reset_release_bulk(>resets);
+}
+
 U_BOOT_DRIVER(denali_nand_dt) = {
.name = "denali-nand-dt",
.id = UCLASS_MISC,
.of_match = denali_nand_dt_ids,
.probe = denali_dt_probe,
.priv_auto_alloc_size = sizeof(struct denali_nand_info),
+   .remove = denali_dt_remove,
+   .flags = DM_FLAG_OS_PREPARE,
 };
 
 void board_nand_init(void)
-- 
2.17.1

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

[U-Boot] [PATCH v3 8/8] arm: socfpga: implement proper peripheral reset

[Simon Goldschmidt]

This commit removes ad-hoc reset handling for peripheral resets from SPL
for socfpga gen5.

This is done because as U-Boot drivers support reset handling by now.

Signed-off-by: Simon Goldschmidt 
---

Changes in v3:
- keep the call to enable fpga bridges in SPL

Changes in v2:
- removed Kconfig option OLD_SOCFPGA_KERNEL_COMPAT since compatibility
  now uses an environment variable

 arch/arm/mach-socfpga/misc_gen5.c | 10 --
 arch/arm/mach-socfpga/spl_gen5.c  |  9 +
 2 files changed, 1 insertion(+), 18 deletions(-)

diff --git a/arch/arm/mach-socfpga/misc_gen5.c 
b/arch/arm/mach-socfpga/misc_gen5.c
index 6e11ba6cb2..9865f5b5b1 100644
--- a/arch/arm/mach-socfpga/misc_gen5.c
+++ b/arch/arm/mach-socfpga/misc_gen5.c
@@ -201,16 +201,6 @@ int arch_early_init_r(void)
/* Add device descriptor to FPGA device table */
socfpga_fpga_add(_fpga[0]);
 
-#ifdef CONFIG_DESIGNWARE_SPI
-   /* Get Designware SPI controller out of reset */
-   socfpga_per_reset(SOCFPGA_RESET(SPIM0), 0);
-   socfpga_per_reset(SOCFPGA_RESET(SPIM1), 0);
-#endif
-
-#ifdef CONFIG_NAND_DENALI
-   socfpga_per_reset(SOCFPGA_RESET(NAND), 0);
-#endif
-
return 0;
 }
 
diff --git a/arch/arm/mach-socfpga/spl_gen5.c b/arch/arm/mach-socfpga/spl_gen5.c
index 1bff8cbfcf..552eaf6864 100644
--- a/arch/arm/mach-socfpga/spl_gen5.c
+++ b/arch/arm/mach-socfpga/spl_gen5.c
@@ -36,16 +36,12 @@ u32 spl_boot_device(void)
return BOOT_DEVICE_RAM;
case 0x2:   /* NAND Flash (1.8V) */
case 0x3:   /* NAND Flash (3.0V) */
-   socfpga_per_reset(SOCFPGA_RESET(NAND), 0);
return BOOT_DEVICE_NAND;
case 0x4:   /* SD/MMC External Transceiver (1.8V) */
case 0x5:   /* SD/MMC Internal Transceiver (3.0V) */
-   socfpga_per_reset(SOCFPGA_RESET(SDMMC), 0);
-   socfpga_per_reset(SOCFPGA_RESET(DMA), 0);
return BOOT_DEVICE_MMC1;
case 0x6:   /* QSPI Flash (1.8V) */
case 0x7:   /* QSPI Flash (3.0V) */
-   socfpga_per_reset(SOCFPGA_RESET(QSPI), 0);
return BOOT_DEVICE_SPI;
default:
printf("Invalid boot device (bsel=%08x)!\n", bsel);
@@ -99,9 +95,7 @@ void board_init_f(ulong dummy)
socfpga_bridges_reset(1);
}
 
-   socfpga_per_reset(SOCFPGA_RESET(UART0), 0);
socfpga_per_reset(SOCFPGA_RESET(OSC1TIMER0), 0);
-
timer_init();
 
debug("Reconfigure Clock Manager\n");
@@ -123,8 +117,7 @@ void board_init_f(ulong dummy)
sysmgr_pinmux_init();
sysmgr_config_warmrstcfgio(0);
 
-   /* De-assert reset for peripherals and bridges based on handoff */
-   reset_deassert_peripherals_handoff();
+   /* De-assert reset for bridges based on handoff */
socfpga_bridges_reset(0);
 
debug("Unfreezing/Thaw all I/O banks\n");
-- 
2.17.1

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

[U-Boot] [PATCH v3 7/8] spi: cadence_qspi: add reset handling

[Simon Goldschmidt]

This adds reset handling to the cadence qspi driver.

For backwards compatibility, only a warning is printed when failing to
get reset handles.

Signed-off-by: Simon Goldschmidt 
---

Changes in v3:
- add DM_FLAG_OS_PREPARE flag

Changes in v2:
- add .remove callback to release the resets

 drivers/spi/cadence_qspi.c | 17 +
 drivers/spi/cadence_qspi.h |  4 
 2 files changed, 21 insertions(+)

diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 11fce9c4fe..c0735d6ef4 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "cadence_qspi.h"
@@ -154,10 +155,17 @@ static int cadence_spi_probe(struct udevice *bus)
 {
struct cadence_spi_platdata *plat = bus->platdata;
struct cadence_spi_priv *priv = dev_get_priv(bus);
+   int ret;
 
priv->regbase = plat->regbase;
priv->ahbbase = plat->ahbbase;
 
+   ret = reset_get_bulk(bus, >resets);
+   if (ret)
+   dev_warn(bus, "Can't get reset: %d\n", ret);
+   else
+   reset_deassert_bulk(>resets);
+
if (!priv->qspi_is_init) {
cadence_qspi_apb_controller_init(plat);
priv->qspi_is_init = 1;
@@ -166,6 +174,13 @@ static int cadence_spi_probe(struct udevice *bus)
return 0;
 }
 
+static int cadence_spi_remove(struct udevice *dev)
+{
+   struct cadence_spi_priv *priv = dev_get_priv(dev);
+
+   return reset_release_bulk(>resets);
+}
+
 static int cadence_spi_set_mode(struct udevice *bus, uint mode)
 {
struct cadence_spi_priv *priv = dev_get_priv(bus);
@@ -342,4 +357,6 @@ U_BOOT_DRIVER(cadence_spi) = {
.platdata_auto_alloc_size = sizeof(struct cadence_spi_platdata),
.priv_auto_alloc_size = sizeof(struct cadence_spi_priv),
.probe = cadence_spi_probe,
+   .remove = cadence_spi_remove,
+   .flags = DM_FLAG_OS_PREPARE,
 };
diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h
index 055900def0..d4ede6e15e 100644
--- a/drivers/spi/cadence_qspi.h
+++ b/drivers/spi/cadence_qspi.h
@@ -7,6 +7,8 @@
 #ifndef __CADENCE_QSPI_H__
 #define __CADENCE_QSPI_H__
 
+#include 
+
 #define CQSPI_IS_ADDR(cmd_len) (cmd_len > 1 ? 1 : 0)
 
 #define CQSPI_NO_DECODER_MAX_CS4
@@ -42,6 +44,8 @@ struct cadence_spi_priv {
unsigned intqspi_calibrated_hz;
unsigned intqspi_calibrated_cs;
unsigned intprevious_hz;
+
+   struct reset_ctl_bulk resets;
 };
 
 /* Functions call declaration */
-- 
2.17.1

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

[U-Boot] [PATCH v3 5/8] arm: socfpga: move gen5 SDR driver to DM

[Simon Goldschmidt]

To clean up reset handling for socfpga gen5, port the DDR driver to DM
using UCLASS_RAM and implement proper reset handling.

This gets us rid of one ad-hoc call to socfpga_per_reset().

The gen5 driver is implemented in 2 distinct files. One of it (containing
the calibration training) is not touched much and is kept at using
hard coded addresses since the code grows even more otherwise.

SPL is changed from calling hard into the DDR driver code to just
probing UCLASS_RESET and UCLASS_RAM. It is happy after finding a RAM
driver after that.

Signed-off-by: Simon Goldschmidt 
---

Changes in v3: None
Changes in v2:
- port DDR driver to DM UCLASS_RAM
- don't change DDR calibration training driver (code got too big)
- use reset.h code instead of socfpga_per_reset()

 arch/arm/Kconfig  |   2 +
 arch/arm/dts/socfpga.dtsi |   4 +-
 .../mach-socfpga/include/mach/sdram_gen5.h|   4 -
 arch/arm/mach-socfpga/spl_gen5.c  |  29 ++--
 drivers/ddr/altera/Kconfig|   1 +
 drivers/ddr/altera/sdram_gen5.c   | 143 --
 drivers/ddr/altera/sequencer.c|   9 +-
 drivers/ddr/altera/sequencer.h|  35 +
 8 files changed, 185 insertions(+), 42 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ded7c11a4c..3b77d731a7 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -821,12 +821,14 @@ config ARCH_SOCFPGA
select DM_SERIAL
select ENABLE_ARM_SOC_BOOT0_HOOK if TARGET_SOCFPGA_GEN5 || 
TARGET_SOCFPGA_ARRIA10
select OF_CONTROL
+   select RAM if TARGET_SOCFPGA_GEN5
select SPL_DM_RESET if DM_RESET
select SPL_DM_SERIAL
select SPL_LIBCOMMON_SUPPORT
select SPL_LIBGENERIC_SUPPORT
select SPL_NAND_SUPPORT if SPL_NAND_DENALI
select SPL_OF_CONTROL
+   select SPL_RAM if TARGET_SOCFPGA_GEN5
select SPL_SEPARATE_BSS if TARGET_SOCFPGA_STRATIX10
select SPL_SERIAL_SUPPORT
select SPL_WATCHDOG_SUPPORT
diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi
index ec1966480f..51a6a51b53 100644
--- a/arch/arm/dts/socfpga.dtsi
+++ b/arch/arm/dts/socfpga.dtsi
@@ -791,9 +791,9 @@
reg = <0xfffec000 0x100>;
};
 
-   sdr: sdr@ffc25000 {
+   sdr: sdr@ffc2 {
compatible = "altr,sdr-ctl", "syscon";
-   reg = <0xffc25000 0x1000>;
+   reg = <0xffc2 0x6000>;
resets = < SDR_RESET>;
};
 
diff --git a/arch/arm/mach-socfpga/include/mach/sdram_gen5.h 
b/arch/arm/mach-socfpga/include/mach/sdram_gen5.h
index a238d5d17f..c41208591a 100644
--- a/arch/arm/mach-socfpga/include/mach/sdram_gen5.h
+++ b/arch/arm/mach-socfpga/include/mach/sdram_gen5.h
@@ -7,10 +7,6 @@
 
 #ifndef __ASSEMBLY__
 
-unsigned long sdram_calculate_size(void);
-int sdram_mmr_init_full(unsigned int sdr_phy_reg);
-int sdram_calibration_full(void);
-
 const struct socfpga_sdram_config *socfpga_get_sdram_config(void);
 
 void socfpga_get_seq_ac_init(const u32 **init, unsigned int *nelem);
diff --git a/arch/arm/mach-socfpga/spl_gen5.c b/arch/arm/mach-socfpga/spl_gen5.c
index 4c9f7997be..1bff8cbfcf 100644
--- a/arch/arm/mach-socfpga/spl_gen5.c
+++ b/arch/arm/mach-socfpga/spl_gen5.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -66,9 +67,9 @@ u32 spl_boot_mode(const u32 boot_device)
 void board_init_f(ulong dummy)
 {
const struct cm_config *cm_default_cfg = cm_get_default_config();
-   unsigned long sdram_size;
unsigned long reg;
int ret;
+   struct udevice *dev;
 
/*
 * First C code to run. Clear fake OCRAM ECC first as SBE
@@ -98,7 +99,6 @@ void board_init_f(ulong dummy)
socfpga_bridges_reset(1);
}
 
-   socfpga_per_reset(SOCFPGA_RESET(SDR), 0);
socfpga_per_reset(SOCFPGA_RESET(UART0), 0);
socfpga_per_reset(SOCFPGA_RESET(OSC1TIMER0), 0);
 
@@ -142,27 +142,16 @@ void board_init_f(ulong dummy)
hang();
}
 
+   ret = uclass_get_device(UCLASS_RESET, 0, );
+   if (ret)
+   debug("Reset init failed: %d\n", ret);
+
/* enable console uart printing */
preloader_console_init();
 
-   if (sdram_mmr_init_full(0x) != 0) {
-   puts("SDRAM init failed.\n");
-   hang();
-   }
-
-   debug("SDRAM: Calibrating PHY\n");
-   /* SDRAM calibration */
-   if (sdram_calibration_full() == 0) {
-   puts("SDRAM calibration failed.\n");
-   hang();
-   }
-
-   sdram_size = sdram_calculate_size();
-   debug("SDRAM: %ld MiB\n", sdram_size >> 20);
-
-   /* Sanity check ensure correct SDRAM size specified */
-   if (get_ram_size(0, sdram_size) != sdram_size) {
-   puts("SDRAM size check failed!\n");

[U-Boot] [PATCH v3 4/8] reset: socfpga: add reset handling for old kernels

[Simon Goldschmidt]

This adds code to take peripherals out of reset based on an environment
variable. This is in preparation for removing the code that does this from
SPL.

However, some drivers even in current Linux cannot handle peripheral reset,
so until this works, we need a compatibility workaround.

This workaround is implemented in the 'assert' and 'remove' callbacks of
this reset driver: the 'assert' callback does not disable peripherals that
were already taken out of reset, while the 'remove' callback, which is
called on OS_PREPARE, deasserts all peripheral resets if the environment
variable "socfpga_legacy_reset_compat" is set to 1, which is what the gen5
SPL did up to now.

This is in preparation to clean up the SPL and implementing proper reset
handling for U-Boot.

Signed-off-by: Simon Goldschmidt 
---

Changes in v3:
- fix falcon mode in SPL should work, too
- change env var name "socfpga_permodrst_ungate" to
  "socfpga_legacy_reset_compat"
- in compat mode, don't reset peripherals once they are enabled

Changes in v2:
- moved from Kernel option "OLD_SOCFPGA_KERNEL_COMPAT" to environment
  variable "socfpga_permodrst_ungate"

 drivers/reset/reset-socfpga.c | 44 +++
 1 file changed, 44 insertions(+)

diff --git a/drivers/reset/reset-socfpga.c b/drivers/reset/reset-socfpga.c
index b2acfcd2ec..39d0b9e8f2 100644
--- a/drivers/reset/reset-socfpga.c
+++ b/drivers/reset/reset-socfpga.c
@@ -27,6 +27,36 @@ struct socfpga_reset_data {
void __iomem *membase;
 };
 
+/*
+ * For compatibility with Kernels that don't support peripheral reset, this
+ * driver can keep the old behaviour of not asserting peripheral reset before
+ * starting the OS and deasserting all peripheral resets (enabling all
+ * peripherals).
+ *
+ * For that, the reset driver checks the environment variable
+ * "socfpga_legacy_reset_compat". If this variable is '1', perihperals are not
+ * reset again once taken out of reset and all peripherals in 'permodrst' are
+ * taken out of reset before booting into the OS.
+ * Note that this should be required for gen5 systems only that are running
+ * Linux kernels without proper peripheral reset support for all drivers used.
+ */
+static bool socfpga_reset_keep_enabled(void)
+{
+#if !defined(CONFIG_SPL_BUILD) || CONFIG_IS_ENABLED(ENV_SUPPORT)
+   const char *env_str;
+   long val;
+
+   env_str = env_get("socfpga_legacy_reset_compat");
+   if (env_str) {
+   val = simple_strtol(env_str, NULL, 0);
+   if (val == 1)
+   return true;
+   }
+#endif
+
+   return false;
+}
+
 static int socfpga_reset_assert(struct reset_ctl *reset_ctl)
 {
struct socfpga_reset_data *data = dev_get_priv(reset_ctl->dev);
@@ -89,6 +119,18 @@ static int socfpga_reset_probe(struct udevice *dev)
return 0;
 }
 
+static int socfpga_reset_remove(struct udevice *dev)
+{
+   struct socfpga_reset_data *data = dev_get_priv(dev);
+
+   if (socfpga_reset_keep_enabled()) {
+   puts("Deasserting all peripheral resets\n");
+   writel(0, data->membase + 4);
+   }
+
+   return 0;
+}
+
 static const struct udevice_id socfpga_reset_match[] = {
{ .compatible = "altr,rst-mgr" },
{ /* sentinel */ },
@@ -101,4 +143,6 @@ U_BOOT_DRIVER(socfpga_reset) = {
.probe = socfpga_reset_probe,
.priv_auto_alloc_size = sizeof(struct socfpga_reset_data),
.ops = _reset_ops,
+   .remove = socfpga_reset_remove,
+   .flags  = DM_FLAG_OS_PREPARE,
 };
-- 
2.17.1

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

[U-Boot] [PATCH v3 3/8] arm: socfpga: gen5: deassert peripheral reset by default

[Simon Goldschmidt]

To keep the current behaviour of taking all peripherals out of reset
before booting the OS before removing that code from socfpga gen5 SPL,
this enables the new behaviour by default for all gen5 boards by adding
the environment variable "socfpga_legacy_reset_compat=1" to the default
environment.

This can be overridden in board config files or by saving an environment
without this variable enabled.

Signed-off-by: Simon Goldschmidt 
---

Changes in v3:
- rename env var to socfpga_legacy_reset_compat
- add env var to CONFIG_EXTRA_ENV_SETTINGS without further ifdefs
- changed the order of patches to keep things bisectable

Changes in v2:
- this patch is new in v2

 include/configs/socfpga_common.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index c9cbf8f5e3..f7e2c6b240 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -330,6 +330,7 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
"scriptaddr=0x0210\0" \
"pxefile_addr_r=0x0220\0" \
"ramdisk_addr_r=0x0230\0" \
+   "socfpga_legacy_reset_compat=1\0" \
BOOTENV
 
 #endif
-- 
2.17.1

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

[U-Boot] [PATCH v3 2/8] arm: socfpga: gen5: add reset & sdr node to SPL devicetrees

[Simon Goldschmidt]

The SPL for socfpga gen5 currently takes all peripherals out of reset
unconditionally. To implement proper reset handling for peripherals,
the reset node has to be provided with the SPL dts.

In preparation to move the DDR driver to DM, the sdr node is required
in SPL, too.

This patch adds "u-boot,dm-pre-reloc" to U-Boot specific dtsi addon
files so that the reset manager and SDR driver correctly probe in SPL.
It centralizes these settings into a common file since in contrast to
boot-type specific nodes, "soc", "rst" and "sdr" are always needed.

Signed-off-by: Simon Goldschmidt 
---

Changes in v3:
- centralize u-boot,dem-pre-reloc for soc, rst and sdr into one common file

Changes in v2: None

 arch/arm/dts/socfpga-common-u-boot.dtsi   | 19 +++
 arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi |  6 ++
 arch/arm/dts/socfpga_cyclone5_dbm_soc1.dts|  5 +
 .../socfpga_cyclone5_de0_nano_soc-u-boot.dtsi |  6 ++
 arch/arm/dts/socfpga_cyclone5_de10_nano.dts   |  5 +
 arch/arm/dts/socfpga_cyclone5_de1_soc.dts |  5 +
 arch/arm/dts/socfpga_cyclone5_is1.dts |  5 +
 .../dts/socfpga_cyclone5_socdk-u-boot.dtsi|  6 ++
 .../dts/socfpga_cyclone5_sockit-u-boot.dtsi   |  6 ++
 .../dts/socfpga_cyclone5_socrates-u-boot.dtsi |  6 ++
 arch/arm/dts/socfpga_cyclone5_sr1500.dts  |  5 +
 .../socfpga_cyclone5_vining_fpga-u-boot.dtsi  |  6 ++
 12 files changed, 36 insertions(+), 44 deletions(-)
 create mode 100644 arch/arm/dts/socfpga-common-u-boot.dtsi

diff --git a/arch/arm/dts/socfpga-common-u-boot.dtsi 
b/arch/arm/dts/socfpga-common-u-boot.dtsi
new file mode 100644
index 00..322c858c4b
--- /dev/null
+++ b/arch/arm/dts/socfpga-common-u-boot.dtsi
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * U-Boot additions
+ *
+ * Copyright (c) 2019 Simon Goldschmidt
+ */
+/{
+   soc {
+   u-boot,dm-pre-reloc;
+   };
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi 
b/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
index c44d1ee2fa..e059831a08 100644
--- a/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
+++ b/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
@@ -6,15 +6,13 @@
  * Copyright (c) 2018 Simon Goldschmidt
  */
 
+#include "socfpga-common-u-boot.dtsi"
+
 /{
aliases {
spi0 = "/soc/spi@ff705000";
udc0 = 
};
-
-   soc {
-   u-boot,dm-pre-reloc;
-   };
 };
 
  {
diff --git a/arch/arm/dts/socfpga_cyclone5_dbm_soc1.dts 
b/arch/arm/dts/socfpga_cyclone5_dbm_soc1.dts
index a387071674..6439daa525 100644
--- a/arch/arm/dts/socfpga_cyclone5_dbm_soc1.dts
+++ b/arch/arm/dts/socfpga_cyclone5_dbm_soc1.dts
@@ -4,6 +4,7 @@
  */
 
 #include "socfpga_cyclone5.dtsi"
+#include "socfpga-common-u-boot.dtsi"
 
 / {
model = "Devboards.de DBM-SoC1";
@@ -24,10 +25,6 @@
device_type = "memory";
reg = <0x0 0x4000>; /* 1GB */
};
-
-   soc {
-   u-boot,dm-pre-reloc;
-   };
 };
 
  {
diff --git a/arch/arm/dts/socfpga_cyclone5_de0_nano_soc-u-boot.dtsi 
b/arch/arm/dts/socfpga_cyclone5_de0_nano_soc-u-boot.dtsi
index 08d81da169..0219c6948d 100644
--- a/arch/arm/dts/socfpga_cyclone5_de0_nano_soc-u-boot.dtsi
+++ b/arch/arm/dts/socfpga_cyclone5_de0_nano_soc-u-boot.dtsi
@@ -6,14 +6,12 @@
  * Copyright (c) 2018 Simon Goldschmidt
  */
 
+#include "socfpga-common-u-boot.dtsi"
+
 /{
aliases {
udc0 = 
};
-
-   soc {
-   u-boot,dm-pre-reloc;
-   };
 };
 
  {
diff --git a/arch/arm/dts/socfpga_cyclone5_de10_nano.dts 
b/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
index e9105743ea..b620dd8dda 100644
--- a/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
+++ b/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
@@ -6,6 +6,7 @@
  */
 
 #include "socfpga_cyclone5.dtsi"
+#include "socfpga-common-u-boot.dtsi"
 
 / {
model = "Terasic DE10-Nano";
@@ -26,10 +27,6 @@
device_type = "memory";
reg = <0x0 0x4000>; /* 1GB */
};
-
-   soc {
-   u-boot,dm-pre-reloc;
-   };
 };
 
  {
diff --git a/arch/arm/dts/socfpga_cyclone5_de1_soc.dts 
b/arch/arm/dts/socfpga_cyclone5_de1_soc.dts
index 4f076bce93..ff1e61e0cb 100644
--- a/arch/arm/dts/socfpga_cyclone5_de1_soc.dts
+++ b/arch/arm/dts/socfpga_cyclone5_de1_soc.dts
@@ -4,6 +4,7 @@
  */
 
 #include "socfpga_cyclone5.dtsi"
+#include "socfpga-common-u-boot.dtsi"
 
 / {
model = "Terasic DE1-SoC";
@@ -24,10 +25,6 @@
device_type = "memory";
reg = <0x0 0x4000>; /* 1GB */
};
-
-   soc {
-   u-boot,dm-pre-reloc;
-   };
 };
 
  {
diff --git a/arch/arm/dts/socfpga_cyclone5_is1.dts 
b/arch/arm/dts/socfpga_cyclone5_is1.dts
index b7054bfd5a..1788e4dfa3 100644
--- a/arch/arm/dts/socfpga_cyclone5_is1.dts
+++ 

[U-Boot] [PATCH v3 1/8] arm: socfpga: gen5: sync devicetrees to Linux

[Simon Goldschmidt]

This is again a sync to linux-next + pending patches in Dinh's tree at
commit 1c909b2dfe6a ("ARM: dts: socfpga: update more missing reset
properties")'

It adds missing peripheral reset properties to socfpga.dtsi and removes
U-Boot specific leftovers from socfpga_cyclone5_socrates.dts.

Signed-off-by: Simon Goldschmidt 
---

Changes in v3: None
Changes in v2:
- cleanly merged Linux dts (moved change of SDR controller base address
  to a separate patch)

 arch/arm/dts/socfpga.dtsi  | 19 +--
 arch/arm/dts/socfpga_cyclone5_socrates.dts |  2 --
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi
index 2458d6707d..ec1966480f 100644
--- a/arch/arm/dts/socfpga.dtsi
+++ b/arch/arm/dts/socfpga.dtsi
@@ -84,6 +84,7 @@
#dma-requests = <32>;
clocks = <_main_clk>;
clock-names = "apb_pclk";
+   resets = < DMA_RESET>;
};
};
 
@@ -100,6 +101,7 @@
reg = <0xffc0 0x1000>;
interrupts = <0 131 4>, <0 132 4>, <0 133 4>, <0 134 4>;
clocks = <_clk>;
+   resets = < CAN0_RESET>;
status = "disabled";
};
 
@@ -108,6 +110,7 @@
reg = <0xffc01000 0x1000>;
interrupts = <0 135 4>, <0 136 4>, <0 137 4>, <0 138 4>;
clocks = <_clk>;
+   resets = < CAN1_RESET>;
status = "disabled";
};
 
@@ -585,6 +588,7 @@
compatible = "snps,dw-apb-gpio";
reg = <0xff708000 0x1000>;
clocks = <_mp_clk>;
+   resets = < GPIO0_RESET>;
status = "disabled";
 
porta: gpio-controller@0 {
@@ -605,6 +609,7 @@
compatible = "snps,dw-apb-gpio";
reg = <0xff709000 0x1000>;
clocks = <_mp_clk>;
+   resets = < GPIO1_RESET>;
status = "disabled";
 
portb: gpio-controller@0 {
@@ -625,6 +630,7 @@
compatible = "snps,dw-apb-gpio";
reg = <0xff70a000 0x1000>;
clocks = <_mp_clk>;
+   resets = < GPIO2_RESET>;
status = "disabled";
 
portc: gpio-controller@0 {
@@ -735,6 +741,7 @@
#size-cells = <0>;
clocks = <_mp_clk>, <_clk_divided>;
clock-names = "biu", "ciu";
+   resets = < SDMMC_RESET>;
status = "disabled";
};
 
@@ -746,9 +753,9 @@
  <0xffb8 0x1>;
reg-names = "nand_data", "denali_reg";
interrupts = <0x0 0x90 0x4>;
-   dma-mask = <0x>;
clocks = <_clk>, <_x_clk>, <_ecc_clk>;
clock-names = "nand", "nand_x", "ecc";
+   resets = < NAND_RESET>;
status = "disabled";
};
 
@@ -759,7 +766,7 @@
 
qspi: spi@ff705000 {
compatible = "cdns,qspi-nor";
-#address-cells = <1>;
+   #address-cells = <1>;
#size-cells = <0>;
reg = <0xff705000 0x1000>,
  <0xffa0 0x1000>;
@@ -768,6 +775,7 @@
cdns,fifo-width = <4>;
cdns,trigger-address = <0x>;
clocks = <_clk>;
+   resets = < QSPI_RESET>;
status = "disabled";
};
 
@@ -786,6 +794,7 @@
sdr: sdr@ffc25000 {
compatible = "altr,sdr-ctl", "syscon";
reg = <0xffc25000 0x1000>;
+   resets = < SDR_RESET>;
};
 
sdramedac {
@@ -802,6 +811,7 @@
interrupts = <0 154 4>;
num-cs = <4>;
clocks = <_m_clk>;
+   resets = < SPIM0_RESET>;
status = "disabled";
};
 
@@ -813,6 +823,7 @@
interrupts = <0 155 4>;
num-cs = <4>;
clocks = <_m_clk>;
+   resets = < SPIM1_RESET>;
status = "disabled";
};
 
@@ -879,6 +890,7 @@
dmas = < 28>,
   < 29>;
dma-names = "tx", "rx";
+   

[U-Boot] [PATCH v3 0/8] arm: socfpga: implement proper peripheral reset handling

[Simon Goldschmidt]

This series implements peripheral reset handling for socfpga gen5.

It moves from enabling all peripherals during SPL startup to using the
socfpga reset driver from all peripherals and enabling peripherals when
they are used.

As Linux cannot even handle this in 4.20, the reset driver implements a
compatibility mode where it takes all peripherals out of reset before
jumpint to the OS if an environment variable "socfpga_permodrst_ungate=1"
is found. This is enabled by default for socfpga gen5 boards, but should
be moved to default off in the near future once a Linux kernel supports
reset handling for all drivers.

Changes in v3:
- centralize u-boot,dem-pre-reloc for soc, rst and sdr into one common file
- rename env var to socfpga_legacy_reset_compat
- add env var to CONFIG_EXTRA_ENV_SETTINGS without further ifdefs
- changed the order of patches to keep things bisectable
- fix falcon mode in SPL should work, too
- change env var name "socfpga_permodrst_ungate" to
  "socfpga_legacy_reset_compat"
- in compat mode, don't reset peripherals once they are enabled
- add DM_FLAG_OS_PREPARE flag
- add DM_FLAG_OS_PREPARE flag
- keep the call to enable fpga bridges in SPL

Changes in v2:
- cleanly merged Linux dts (moved change of SDR controller base address
  to a separate patch)
- this patch is new in v2
- moved from Kernel option "OLD_SOCFPGA_KERNEL_COMPAT" to environment
  variable "socfpga_permodrst_ungate"
- port DDR driver to DM UCLASS_RAM
- don't change DDR calibration training driver (code got too big)
- use reset.h code instead of socfpga_per_reset()
- fix copy/paste issues
- add .remove callback to release the resets
- add .remove callback to release the resets
- removed Kconfig option OLD_SOCFPGA_KERNEL_COMPAT since compatibility
  now uses an environment variable

Simon Goldschmidt (8):
  arm: socfpga: gen5: sync devicetrees to Linux
  arm: socfpga: gen5: add reset & sdr node to SPL devicetrees
  arm: socfpga: gen5: deassert peripheral reset by default
  reset: socfpga: add reset handling for old kernels
  arm: socfpga: move gen5 SDR driver to DM
  mtd: rawnand: denali: add reset handling
  spi: cadence_qspi: add reset handling
  arm: socfpga: implement proper peripheral reset

 arch/arm/Kconfig  |   2 +
 arch/arm/dts/socfpga-common-u-boot.dtsi   |  19 +++
 arch/arm/dts/socfpga.dtsi |  23 ++-
 arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi |   6 +-
 arch/arm/dts/socfpga_cyclone5_dbm_soc1.dts|   5 +-
 .../socfpga_cyclone5_de0_nano_soc-u-boot.dtsi |   6 +-
 arch/arm/dts/socfpga_cyclone5_de10_nano.dts   |   5 +-
 arch/arm/dts/socfpga_cyclone5_de1_soc.dts |   5 +-
 arch/arm/dts/socfpga_cyclone5_is1.dts |   5 +-
 .../dts/socfpga_cyclone5_socdk-u-boot.dtsi|   6 +-
 .../dts/socfpga_cyclone5_sockit-u-boot.dtsi   |   6 +-
 .../dts/socfpga_cyclone5_socrates-u-boot.dtsi |   6 +-
 arch/arm/dts/socfpga_cyclone5_socrates.dts|   2 -
 arch/arm/dts/socfpga_cyclone5_sr1500.dts  |   5 +-
 .../socfpga_cyclone5_vining_fpga-u-boot.dtsi  |   6 +-
 .../mach-socfpga/include/mach/sdram_gen5.h|   4 -
 arch/arm/mach-socfpga/misc_gen5.c |  10 --
 arch/arm/mach-socfpga/spl_gen5.c  |  38 ++---
 drivers/ddr/altera/Kconfig|   1 +
 drivers/ddr/altera/sdram_gen5.c   | 143 --
 drivers/ddr/altera/sequencer.c|   9 +-
 drivers/ddr/altera/sequencer.h|  35 +
 drivers/mtd/nand/raw/denali.h |   2 +
 drivers/mtd/nand/raw/denali_dt.c  |  15 ++
 drivers/reset/reset-socfpga.c |  44 ++
 drivers/spi/cadence_qspi.c|  17 +++
 drivers/spi/cadence_qspi.h|   4 +
 include/configs/socfpga_common.h  |   1 +
 28 files changed, 322 insertions(+), 108 deletions(-)
 create mode 100644 arch/arm/dts/socfpga-common-u-boot.dtsi

-- 
2.17.1

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

Re: [U-Boot] [PATCH v2 8/8] arm: socfpga: implement proper peripheral reset

[Simon Goldschmidt]

On 22.02.2019 22:14, Marek Vasut wrote:

On 2/22/19 8:55 PM, Simon Goldschmidt wrote:


Am Fr., 22. Feb. 2019, 20:47 hat Marek Vasut mailto:ma...@denx.de>> geschrieben:

 On 2/22/19 8:42 PM, Simon Goldschmidt wrote:
 >
 >
 > Am Fr., 22. Feb. 2019, 20:37 hat Marek Vasut mailto:ma...@denx.de>
 > >> geschrieben:
 >
 >     On 2/22/19 8:10 PM, Simon Goldschmidt wrote:
 >     >
 >     >
 >     > Am Fr., 22. Feb. 2019, 18:34 hat Marek Vasut mailto:ma...@denx.de>
 >     >
 >     > 
      >
 >     >     On 2/22/19 7:35 AM, Simon Goldschmidt wrote:
 >     >     > On Thu, Feb 21, 2019 at 10:56 PM Marek Vasut
 mailto:ma...@denx.de>
 >     >
 >     >     
      >     >>
 >     >     >> On 2/21/19 10:43 PM, Simon Goldschmidt wrote:
 >     >     >>> This commit removes ad-hoc reset handling for peripheral
 >     resets
 >     >     from SPL
 >     >     >>> for socfpga gen5.
 >     >     >>>
 >     >     >>> This is done because as U-Boot drivers support reset
 >     handling by
 >     >     now.
 >     >     >>>
 >     >     >>> Signed-off-by: Simon Goldschmidt
 >     >     mailto:simon.k.r.goldschm...@gmail.com>
 >     >
 >     >     
 >          >     >>> ---
 >     >     >>>
 >     >     >>> Changes in v2:
 >     >     >>> - removed Kconfig option OLD_SOCFPGA_KERNEL_COMPAT since
 >     >     compatibility
 >     >     >>>   now uses an environment variable
 >     >     >>>
 >     >     >>>  arch/arm/mach-socfpga/misc_gen5.c | 10 --
 >     >     >>>  arch/arm/mach-socfpga/spl_gen5.c  | 10 --
 >     >     >>>  2 files changed, 20 deletions(-)
 >     >     >>>
 >     >     >>> diff --git a/arch/arm/mach-socfpga/misc_gen5.c
 >     >     b/arch/arm/mach-socfpga/misc_gen5.c
 >     >     >>> index 6e11ba6cb2..9865f5b5b1 100644
 >     >     >>> --- a/arch/arm/mach-socfpga/misc_gen5.c
 >     >     >>> +++ b/arch/arm/mach-socfpga/misc_gen5.c
 >     >     >>> @@ -201,16 +201,6 @@ int arch_early_init_r(void)
 >     >     >>>       /* Add device descriptor to FPGA device table */
 >     >     >>>       socfpga_fpga_add(_fpga[0]);
 >     >     >>>
 >     >     >>> -#ifdef CONFIG_DESIGNWARE_SPI
 >     >     >>> -     /* Get Designware SPI controller out of reset */
 >     >     >>> -     socfpga_per_reset(SOCFPGA_RESET(SPIM0), 0);
 >     >     >>> -     socfpga_per_reset(SOCFPGA_RESET(SPIM1), 0);
 >     >     >>> -#endif
 >     >     >>> -
 >     >     >>> -#ifdef CONFIG_NAND_DENALI
 >     >     >>> -     socfpga_per_reset(SOCFPGA_RESET(NAND), 0);
 >     >     >>> -#endif
 >     >     >>> -
 >     >     >>>       return 0;
 >     >     >>>  }
 >     >     >>>
 >     >     >>> diff --git a/arch/arm/mach-socfpga/spl_gen5.c
 >     >     b/arch/arm/mach-socfpga/spl_gen5.c
 >     >     >>> index 1bff8cbfcf..e1e65261eb 100644
 >     >     >>> --- a/arch/arm/mach-socfpga/spl_gen5.c
 >     >     >>> +++ b/arch/arm/mach-socfpga/spl_gen5.c
 >     >     >>> @@ -36,16 +36,12 @@ u32 spl_boot_device(void)
 >     >     >>>               return BOOT_DEVICE_RAM;
 >     >     >>>       case 0x2:       /* NAND Flash (1.8V) */
 >     >     >>>       case 0x3:       /* NAND Flash (3.0V) */
 >     >     >>> -             socfpga_per_reset(SOCFPGA_RESET(NAND), 0);
 >     >     >>>               return BOOT_DEVICE_NAND;
 >     >     >>>       case 0x4:       /* SD/MMC External Transceiver
 (1.8V) */
 >     >     >>>       case 0x5:       /* SD/MMC Internal Transceiver
 (3.0V) */
 >     >     >>> -
  socfpga_per_reset(SOCFPGA_RESET(SDMMC), 0);
 >     >     >>> -             socfpga_per_reset(SOCFPGA_RESET(DMA), 0);
 >     >     >>>               return BOOT_DEVICE_MMC1;
 >     >     >>>       case 0x6:       /* QSPI Flash (1.8V) */
 >     >     >>>       case 0x7:       /* QSPI Flash (3.0V) */
 >     >     >>> -             socfpga_per_reset(SOCFPGA_RESET(QSPI), 0);
 >     >     >>>               return BOOT_DEVICE_SPI;
 >     >     >>>       default:
 >     >     >>>               printf("Invalid boot device
 (bsel=%08x)!\n",
 >     bsel);
 >     >     >>> @@ -99,9 

Re: [U-Boot] [PATCH 2/3] ARM: rmobile: Add basic PSCI support for r8a7790 SoC

[Oleksandr]

Hi, Marek



+}
+
+/*
+ * Reset vector for secondary CPUs.
+ * This will be mapped at address 0 by SBAR register.
+ * We need _long_ jump to the physical address.
+ */
+asm("    .arm\n"
+    "    .align 12\n"
+    "    .globl shmobile_boot_vector\n"
+    "shmobile_boot_vector:\n"
+    "    ldr r1, 1f\n"
+    "    bx    r1\n"
+    "    .type shmobile_boot_vector, %function\n"
+    "    .size shmobile_boot_vector, .-shmobile_boot_vector\n"
+    "    .align    2\n"
+    "    .globl    shmobile_boot_fn\n"
+    "shmobile_boot_fn:\n"
+    "1:    .space    4\n"
+    "    .globl    shmobile_boot_size\n"
+    "shmobile_boot_size:\n"
+    "    .long    .-shmobile_boot_vector\n");

Why can't this be implemented in C ?

This "reset vector" code was ported from Linux:

https://elixir.bootlin.com/linux/v5.0-rc5/source/arch/arm/mach-shmobile/headsmp.S#L21 





Really don't know whether it can be implemented in C.

I was thinking of moving this code to a separate ASM file in order 
not

to mix C and ASM. What do you think about it?

U-Boot already has a reset vector code, can't that be reused ?
I don't think. Being honest, I couldn't find an obvious way how to 
reuse

(I assume you meant arch/arm/cpu/armv7/start.S).

Maybe it needs some additional work first ?
It seems Altera socfpga somehow uses the U-Boot reset vectors for PSCI,
so it should at least be possible.


Could you, please, point me in code? Unfortunately, I wasn't able to 
find.






The newly turned on secondary CPU entry should be common
"psci_cpu_entry", which does proper things.

And this reset vector is just "a small piece of code" to be located in
on-chip RAM (with limited size) and used for the jump stub...

We already have the SPL reset vectors in SRAM, maybe that can be
recycled somehow ?



The only idea I have, how it may be recycled (not sure whether it will 
work...)



diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 0cb6dd39cc..69acf4677b 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -36,6 +36,12 @@
 #endif

 reset:
+
+#if defined(CONFIG_ARMV7_PSCI) && !defined(CONFIG_SPL_BUILD)
+   b psci_cpu_entry_jump
+   /* return only if this is not "a newly turned on CPU" using 
PSCI) */

+#endif
+
    /* Allow the board to save important registers */
    b   save_boot_params
 save_boot_params_ret:
@@ -128,6 +134,21 @@ ENDPROC(switch_to_hypervisor)
    .weak   switch_to_hypervisor
 #endif

+/*
+ * Each platform which implements psci_cpu_entry_jump function should 
perform

+ * in the following way:
+ *
+ * If the executing this call CPU is exactly that CPU we are 
expecting to be

+ * powered on, then jump to psci_cpu_entry and never return.
+ * Otherwise return to the caller.
+ */
+#if defined(CONFIG_ARMV7_PSCI) && !defined(CONFIG_SPL_BUILD)
+ENTRY(psci_cpu_entry_jump)
+   movs    pc, lr
+ENDPROC(psci_cpu_entry_jump)
+.weak psci_cpu_entry_jump
+#endif
+
 /* 


  *
  * cpu_init_cp15


What do you think?


It would be much appreciated, if you could provide some hints.



Don't want to be annoying, but it would be really nice to get my 
questions answered...



--
Regards,

Oleksandr Tyshchenko

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

Re: [U-Boot] [PATCH v2 4/5] cmd: bootefi: run an EFI application of a specific load option

[Heinrich Schuchardt]

On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> With this patch applied, we will be able to selectively execute
> an EFI application by specifying a load option, say "1" for Boot0001,
> "2" for Boot0002 and so on.
> 
>   => bootefi bootmgr  1, or
>  bootefi bootmgr - 1

You already introduced the support for BootNext. So is there a real benefit?

> 
> Please note that Boot need not be included in "BootOrder".
> 
> Signed-off-by: AKASHI Takahiro 
> ---
>  cmd/bootefi.c | 39 ---
>  1 file changed, 28 insertions(+), 11 deletions(-)
> 
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 3be01b49b589..241fd0f987ab 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -471,16 +471,15 @@ static efi_status_t bootefi_test_prepare
>  
>  #endif /* CONFIG_CMD_BOOTEFI_SELFTEST */
>  
> -static int do_bootefi_bootmgr_exec(void)
> +static int do_bootefi_bootmgr_exec(int boot_id)
>  {
>   struct efi_device_path *device_path, *file_path;
>   void *addr;
>   efi_status_t r;
>  
> - addr = efi_bootmgr_load(EFI_BOOTMGR_DEFAULT_ORDER,
> - _path, _path);
> + addr = efi_bootmgr_load(boot_id, _path, _path);
>   if (!addr)
> - return 1;
> + return CMD_RET_FAILURE;
>  
>   printf("## Starting EFI application at %p ...\n", addr);
>   r = do_bootefi_exec(addr, device_path, file_path);
> @@ -488,9 +487,9 @@ static int do_bootefi_bootmgr_exec(void)
>  r & ~EFI_ERROR_MASK);
>  
>   if (r != EFI_SUCCESS)
> - return 1;
> + return CMD_RET_FAILURE;
>  
> - return 0;
> + return CMD_RET_SUCCESS;
>  }
>  
>  /* Interpreter command to boot an arbitrary EFI image from memory */
> @@ -546,10 +545,28 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int 
> argc, char * const argv[])
>   } else
>  #endif
>   if (!strcmp(argv[1], "bootmgr")) {
> - if (efi_handle_fdt(argc > 2 ? argv[2] : NULL))
> - return CMD_RET_FAILURE;
> + char *fdtstr, *endp;
> + int boot_id = EFI_BOOTMGR_DEFAULT_ORDER;
> +
> + if (argc > 2) {
> + fdtstr = argv[2];
> +  /* Special address "-" means no device tree */
> + if (fdtstr[0] == '-')
> + fdtstr = NULL;
> +
> + r = efi_handle_fdt(fdtstr);
> + if (r)
> + return CMD_RET_FAILURE;
> + }
> +
> + if (argc > 3) {
> + boot_id = (int)simple_strtoul(argv[3], , 0);
> + if ((argv[3] + strlen(argv[3]) != endp) ||
> + boot_id > 0x)
> + return CMD_RET_USAGE;
> + }
>  
> - return do_bootefi_bootmgr_exec();
> + return do_bootefi_bootmgr_exec(boot_id);

Why not communicate via the BootNext variable?

>   } else {
>   saddr = argv[1];
>  
> @@ -590,7 +607,7 @@ static char bootefi_help_text[] =
>   "Use environment variable efi_selftest to select a single test.\n"
>   "Use 'setenv efi_selftest list' to enumerate all tests.\n"
>  #endif
> - "bootefi bootmgr [fdt addr]\n"
> + "bootefi bootmgr [|'-' []]\n"
>   "  - load and boot EFI payload based on BootOrder/Boot variables.\n"
>   "\n"
>   "If specified, the device tree located at  gets\n"
> @@ -598,7 +615,7 @@ static char bootefi_help_text[] =
>  #endif
>  
>  U_BOOT_CMD(
> - bootefi, 3, 0, do_bootefi,
> + bootefi, 5, 0, do_bootefi,

Why 5?

Best regards

Heinrich

>   "Boots an EFI payload from memory",
>   bootefi_help_text
>  );
> 

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

Re: [U-Boot] ut dm pch sandbox test failures

[Stephen Warren]

On 2/25/19 4:49 PM, Stephen Warren wrote:

On 2/21/19 4:45 PM, Stephen Warren wrote:
With the latest push to u-boot.git master branch, I'm seeing the 
following failures running test/py on sandbox:


=> ut dm pch_base
Test: dm_test_pch_base: pch.c
/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/pch.c:20, 
dm_test_pch_base(): 0 == uclass_first_device_err(UCLASS_PCH, ): 
Expected 0, got -19

Test: dm_test_pch_base: pch.c (flat tree)
/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/pch.c:20, 
dm_test_pch_base(): 0 == uclass_first_device_err(UCLASS_PCH, ): 
Expected 0, got -19

Failures: 2

=> ut dm pch_ioctl
Test: dm_test_pch_ioctl: pch.c
/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/pch.c:44, 
dm_test_pch_ioctl(): 0 == uclass_first_device_err(UCLASS_PCH, ): 
Expected 0, got -19

Test: dm_test_pch_ioctl: pch.c (flat tree)
/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/pch.c:44, 
dm_test_pch_ioctl(): 0 == uclass_first_device_err(UCLASS_PCH, ): 
Expected 0, got -19

Failures: 2


This is some kind of incremental build problem; I deleted the build 
results and retriggered Jenkins and everything worked fine. The exact 
same issue and solution appeared and worked in two separate branches 
that I test (u-boot.git master, u-boot-video.git master). Subsequently I 
found that the following works fine:


rm -rf build-sandbox/
git checkout 888f9aa5cac4
./test/py/test.py --bd sandbox --build -k test_ut

But the following reproduces the problem:

rm -rf build-sandbox/
git checkout 97f9830849c6
./test/py/test.py --bd sandbox --build -k test_ut
git checkout 888f9aa5cac4
./test/py/test.py --bd sandbox --build -k test_ut


I just sent "[PATCH 1/2] kbuild: make arch-dtbs target PHONY" to fix this.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/2] kbuild: make arch-dtbs target PHONY

[Stephen Warren]

From: Stephen Warren 

Without this, the arch-dtbs target only gets evaluated when building
U-Boot the first time, not when re-building (incrementally building)
U-Boot. Thus incremental builds ignore changes to DTB files.

Signed-off-by: Stephen Warren 
---
 dts/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/dts/Makefile b/dts/Makefile
index a7a604303cc6..4970223b3d2e 100644
--- a/dts/Makefile
+++ b/dts/Makefile
@@ -40,6 +40,7 @@ endif
echo >&2;   \
/bin/false)
 
+PHONY += arch-dtbs
 arch-dtbs:
$(Q)$(MAKE) $(build)=$(ARCH_PATH) dtbs
 
-- 
2.20.1

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

[U-Boot] [PATCH 2/2] kbuild: fix DTB .cmd source variable

[Stephen Warren]

From: Stephen Warren 

*.dts are processed using a custom command, then the C pre-processor is
run on them, then they are compiled using dtc. Thus, the dependency
files generated by both cpp and dtc reference a temporary file name
rather than the actual source file. While this information isn't used
for any purpose by the build system, and hence this causes no functional
issue, it does cause the dependency files to contain invalid and
confusing data, which is unhelpful while debugging build problems. Fix
this using sed.

Signed-off-by: Stephen Warren 
---
 scripts/Makefile.lib | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 704d644f6faa..ec5c41ec5616 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -301,7 +301,8 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
$(DTC) -O dtb -o $@ -b 0 \
-i $(dir $<) $(DTC_FLAGS) \
-d $(depfile).dtc.tmp $(dtc-tmp) ; \
-   cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile)
+   cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile) ; \
+   sed -i "s:$(pre-tmp):$(<):" $(depfile)
 
 $(obj)/%.dtb: $(src)/%.dts FORCE
$(call if_changed_dep,dtc)
-- 
2.20.1

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

Re: [U-Boot] [PATCH v2 5/5] cmd: run: add "-e" option to run an EFI application

[Heinrich Schuchardt]

On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> "run -e" allows for executing EFI application with a specific "Boot"
> variable. If no "Boot" is specified or "BootOrder" is specified,
> it tries to run an EFI application specified in the order of "bootOrder."
> 

If we cannot specify the device tree what would be the use of this for
ARM processors?

Why do you add the option to run and not to bootefi?

You already introduced the capability to set BootNext. Why isn't that
enough?

Best regards

Heinrich

> Signed-off-by: AKASHI Takahiro 
> ---
>  cmd/bootefi.c | 31 +++
>  cmd/nvedit.c  |  9 -
>  common/cli.c  | 10 ++
>  include/command.h |  3 +++
>  4 files changed, 52 insertions(+), 1 deletion(-)
> 
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 241fd0f987ab..ebe149dffa1f 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -492,6 +492,37 @@ static int do_bootefi_bootmgr_exec(int boot_id)
>   return CMD_RET_SUCCESS;
>  }
>  
> +/* Called by "run" command */
> +int do_bootefi_run(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> +{
> + int boot_id = -1;
> + char *endp;
> +
> + if (argc > 2)
> + return CMD_RET_USAGE;
> +
> + if (argc == 2) {
> + if (!strcmp(argv[1], "BootOrder")) {
> + boot_id = -1;
> + } else if (!strncmp(argv[2], "Boot", 4)) {
> + boot_id = (int)simple_strtoul([2][4], , 0);
> + if ((argv[2] + strlen(argv[2]) != endp) ||
> + boot_id > 0x)
> + return CMD_RET_USAGE;
> + } else {
> + return CMD_RET_USAGE;
> + }
> + }
> +
> + if (efi_init_obj_list())
> + return CMD_RET_FAILURE;
> +
> + if (efi_handle_fdt(NULL))
> + return CMD_RET_FAILURE;
> +
> + return do_bootefi_bootmgr_exec(boot_id);
> +}
> +
>  /* Interpreter command to boot an arbitrary EFI image from memory */
>  static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> argv[])
>  {
> diff --git a/cmd/nvedit.c b/cmd/nvedit.c
> index de16c72c23f2..ce746bbf1b3e 100644
> --- a/cmd/nvedit.c
> +++ b/cmd/nvedit.c
> @@ -1344,7 +1344,14 @@ U_BOOT_CMD_COMPLETE(
>   run,CONFIG_SYS_MAXARGS, 1,  do_run,
>   "run commands in an environment variable",
>   "var [...]\n"
> - "- run the commands in the environment variable(s) 'var'",
> + "- run the commands in the environment variable(s) 'var'"
> +#if defined(CONFIG_CMD_BOOTEFI)
> + "\n"
> + "run -e [Boot]\n"
> + "- load and run UEFI app based on 'Boot' UEFI variable",
> +#else
> + ,
> +#endif
>   var_complete
>  );
>  #endif
> diff --git a/common/cli.c b/common/cli.c
> index 51b8d5f85cbb..fbb09d5049a4 100644
> --- a/common/cli.c
> +++ b/common/cli.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -125,6 +126,15 @@ int do_run(cmd_tbl_t *cmdtp, int flag, int argc, char * 
> const argv[])
>   if (argc < 2)
>   return CMD_RET_USAGE;
>  
> +#ifdef CONFIG_CMD_BOOTEFI
> + if (!strcmp(argv[1], "-e")) {
> + argc--;
> + argv++;
> +
> + return do_bootefi_run(cmdtp, flag, argc, argv);
> + }
> +#endif
> +
>   for (i = 1; i < argc; ++i) {
>   char *arg;
>  
> diff --git a/include/command.h b/include/command.h
> index 200c7a5e9f4e..feddef300ccc 100644
> --- a/include/command.h
> +++ b/include/command.h
> @@ -48,6 +48,9 @@ typedef struct cmd_tbl_scmd_tbl_t;
>  #if defined(CONFIG_CMD_RUN)
>  extern int do_run(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
>  #endif
> +#if defined(CONFIG_CMD_BOOTEFI)
> +extern int do_bootefi_run(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> argv[]);
> +#endif
>  
>  /* common/command.c */
>  int _do_help (cmd_tbl_t *cmd_start, int cmd_items, cmd_tbl_t * cmdtp, int
> 

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

[U-Boot] Dreamplug fails to detect SPI and USB

[Vagrant Cascadian]

On 2019-02-26, Leigh Brown wrote:
> I tested u-boot 2019.01+dfsg-1 on my Globalscale Dreamplug and it 
> doesn't work:
>
> U-Boot 2019.01+dfsg-1 (Jan 15 2019 - 00:36:19 +)
> Marvell-DreamPlug
>
> SoC:   Kirkwood 88F6281_A1
> DRAM:  512 MiB
> Loading Environment from SPI Flash... Invalid bus 0 (err=-19)
> *** Warning - spi_flash_probe_bus_cs() failed, using default environment
>
> In:serial
> Out:   serial
> Err:   serial
> Net:   egiga0
> Error: egiga0 address not set.
> , egiga1
> Error: egiga1 address not set.
>
> 88E1116 Initialized on egiga0
> 88E1116 Initialized on egiga1
> IDE:   ide_preinit failed
> Hit any key to stop autoboot:  0
> => usb start
> starting USB...
> USB0:   USB EHCI 1.00
> scanning bus 0 for devices... EHCI timed out on TD - token=0x80008d80
> EHCI timed out on TD - token=0x80008c80
> EHCI timed out on TD - token=0x80008c80
> EHCI timed out on TD - token=0x80008c80
>   ERROR: NOT USB_CONFIG_DESC a3
> EHCI timed out on TD - token=0x80008d80
> EHCI timed out on TD - token=0x80008c80
> EHCI timed out on TD - token=0x80008c80
> 2 USB Device(s) found
> scanning usb for storage devices... 0 Storage Device(s) found
>
> So it cannot detect USB or SPI Flash.

I don't think Debian carries any particular patches that would affect
the dreamplug target and I'm not seeing any obvious changes in
upstream's master branch since v2019.01.

It would be good to find out the last known working version, if
possible:

  https://snapshot.debian.org/package/u-boot/


Please file a bug in the Debian bug tracker so I can keep track of this
issue in Debian:

  https://www.debian.org/Bugs/Reporting


live well,
  vagrant


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

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

[Heinrich Schuchardt]

On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> See UEFI v2.7, section 3.1.2 for details of the specification.
> 
> With my efitool command, you can try as the following:
>   => 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 ...)
>   => efi dumpvar
>   
>   BootCurrent: {boot,run}(blob)
>   :  02 00..
>   BootOrder: {boot,run}(blob)
>   :  01 00 02 00  
> 
> Signed-off-by: AKASHI Takahiro 
> ---
>  lib/efi_loader/efi_bootmgr.c | 34 +-
>  1 file changed, 33 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> index a095df3f540b..6c5303736dc6 100644
> --- a/lib/efi_loader/efi_bootmgr.c
> +++ b/lib/efi_loader/efi_bootmgr.c
> @@ -145,11 +145,21 @@ 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",
> __func__, lo.label, lo.file_path);
>  
> + attributes = EFI_VARIABLE_BOOTSERVICE_ACCESS |
> +  EFI_VARIABLE_RUNTIME_ACCESS;
> + size = sizeof(n);
> + ret = rs->set_variable(L"BootCurrent",
> +(efi_guid_t *)_global_variable_guid,

Use EFI_CALL(). Instead of dereferencing you could directly call
efi_set_variable().

> +attributes, size, );
> + if (ret != EFI_SUCCESS)
> + goto error;
> +
>   ret = efi_load_image_from_path(lo.file_path, );
>  
>   if (ret != EFI_SUCCESS)
> @@ -173,16 +183,38 @@ error:
>  void *efi_bootmgr_load(struct efi_device_path **device_path,
>  struct efi_device_path **file_path)
>  {
> - uint16_t *bootorder;
> + u16 bootnext, *bootorder;
>   efi_uintn_t size;
>   void *image = NULL;
>   int i, num;
> + efi_status_t ret;
>  
>   __efi_entry_check();
>  
>   bs = systab.boottime;
>   rs = systab.runtime;
>  
> + /* get BootNext */
> + size = sizeof(bootnext);
> + ret = rs->get_variable(L"BootNext",
> +(efi_guid_t *)_global_variable_guid,
> +NULL, , );

You could call efi_get_variable() directly instead of dereferencing rs.
But anyway you have to use EFI_CALL().

> + if (!bootnext)
> + goto run_list;

Goto is acceptable for error handling. But otherwise I would rather
avoid it.

> +
> + /* delete BootNext */
> + ret = rs->set_variable(L"BootNext",
> +(efi_guid_t *)_global_variable_guid,
> +0, 0, );

EFI_CALL().

Best regards

Heinrich

> + if (ret != EFI_SUCCESS)
> + goto error;
> +
> + image = try_load_entry(bootnext, device_path, file_path);
> + if (image)
> + goto error;
> +
> +run_list:
> + /* BootOrder */
>   bootorder = get_var(L"BootOrder", _global_variable_guid, );
>   if (!bootorder)
>   goto error;
> 

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

Re: [U-Boot] U-Boot pull request for EFI subsystem in v2019.04-rc3

[Tom Rini]

On Mon, Feb 25, 2019 at 07:32:35PM +0100, Heinrich Schuchardt wrote:

> The following changes since commit afd46c5f13d0c93c44008bd7040227d0b84e31b9:
> 
>   Merge branch '2019-02-22-master-imports' (2019-02-22 22:40:24 -0500)
> 
> are available in the Git repository at:
> 
>   https://github.com/xypron2/u-boot tag efi-2019-04-rc3
> 
> for you to fetch changes up to 00358bb804e9e8aa754f946954d299ba9e658a84:
> 
>   cmd: efidebug: add memmap command (2019-02-25 12:47:13 +0100)
> 
> GPG primary key fingerprint:
> 6DC4 F9C7 1F29 A6FA 06B7  6D33 C481 DBBC 2C05 1AC4
> 
> Travis results are available at
> https://travis-ci.org/xypron2/u-boot/builds/498121574
> 
> A new option -e is added to the env command which allows to display and
> change UEFI variables in a user friendly way.
> 
> A new command efidebug is introduced to edit the UEFI boot sequence and
> to display different aspects of the state of the UEFI sub-system: memory
> map, loaded images, handles, drivers and devices.
> 
> A bug in the UEFI boot manager is fixed.

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2 6/6] ARM: MediaTek: Add support for MT8516 SoC

[Tom Rini]

On Sat, Feb 23, 2019 at 06:54:03PM +0100, Fabien Parent wrote:

> Add support for MediaTek MT8516 SoC. This include the file
> that will initialize the SoC after boot and its device tree.
> 
> Signed-off-by: Fabien Parent 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 1/3] ARM: rmobile: Switch CPU to non-secure HYP mode for r8a7790 based boards

[Oleksandr]

Hi, Marek




2. It should be new pm-r8a7791.c file which will don't have any CA7
related stuff (CPU cores, SCU, etc).

I'd like to have a generic pm-gen2.c file , which parses the DT and
figures the configuration out that way. We are trying to get rid of all
the ad-hoc hardcoded configuration stuff in favor of DT.


Or it should be the single pm-r8a779x.c which must distinguish what SoC
is being used and do proper things.

Right



I agree to have a single generic pm-gen2.c file which covers all Gen2 
SoCs.


But, unfortunately, I only have Stout boards (H2), and therefore can 
check only on them. This is why the current patch series adds support 
for H2 SoC only.


Theoretically, I could add support for M2 as well, but, I wouldn't 
have possibility to check.



I would focus on the r8a7790 for now, as the Stout board is our 
nearest target which we want to support in Xen and the PSCI feature is 
a mandatory option.


What do you think?


Could you, please, answer that question...







--
Regards,

Oleksandr Tyshchenko

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

[U-Boot] [PATCH v2] configs: dra7xx_evm: Remove ENV_IS_IN_FAT

[Faiz Abbas]

With U-boot supporting environment in multiple places, enable only
ENV_IS_IN_EMMC

Signed-off-by: Faiz Abbas 
---
 configs/dra7xx_evm_defconfig| 1 +
 configs/dra7xx_hs_evm_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/dra7xx_evm_defconfig b/configs/dra7xx_evm_defconfig
index ef061501ef..3f25a2ec28 100644
--- a/configs/dra7xx_evm_defconfig
+++ b/configs/dra7xx_evm_defconfig
@@ -36,6 +36,7 @@ CONFIG_OF_LIST="dra7-evm dra72-evm dra72-evm-revc dra71-evm 
dra76-evm"
 CONFIG_SPL_MULTI_DTB_FIT=y
 CONFIG_SPL_MULTI_DTB_FIT_UNCOMPRESS_SZ=0x9000
 CONFIG_OF_SPL_REMOVE_PROPS="clocks clock-names interrupt-parent"
+# CONFIG_ENV_IS_IN_FAT is not set
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
 CONFIG_DM=y
diff --git a/configs/dra7xx_hs_evm_defconfig b/configs/dra7xx_hs_evm_defconfig
index 3cf7659496..ee28e0c6ec 100644
--- a/configs/dra7xx_hs_evm_defconfig
+++ b/configs/dra7xx_hs_evm_defconfig
@@ -40,6 +40,7 @@ CONFIG_OF_LIST="dra7-evm dra72-evm dra72-evm-revc dra71-evm 
dra76-evm"
 CONFIG_SPL_MULTI_DTB_FIT=y
 CONFIG_SPL_MULTI_DTB_FIT_UNCOMPRESS_SZ=0x9000
 CONFIG_OF_SPL_REMOVE_PROPS="clocks clock-names interrupt-parent"
+# CONFIG_ENV_IS_IN_FAT is not set
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
 CONFIG_DM=y
-- 
2.19.2

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

Re: [U-Boot] [PATCH] efi_loader: Fix serial console size detection

[Heinrich Schuchardt]

On 2/26/19 12:46 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 

Thanks Matthias for the patch.

The general direction is right. Yet I would prefer if you could move the
waiting loop as described below.

> ---
>  lib/efi_loader/efi_console.c | 63 +---
>  1 file changed, 37 insertions(+), 26 deletions(-)
> 
> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
> index 66c33a551d..817220455f 100644
> --- a/lib/efi_loader/efi_console.c
> +++ b/lib/efi_loader/efi_console.c
> @@ -62,6 +62,16 @@ static struct simple_text_output_mode efi_con_mode = {
>   .cursor_visible = 1,
>  };
>  
> +static int term_get_char(char *c)
> +{
> + if (tstc()) {
> + *c = getc();
> + return 0;
> + }
> +
> + return 1;

The function signals an error if the character to read is not yet in the
UART buffer. I think it would be preferable to put the waiting time (100
ms is sufficient at 110 baud and above) into this function instead. This
has the following advantages:

- We would need only one waiting loop.
- We could reuse the function in function efi_cin_read_key() where we
  have another chance to hang waiting for a character.

> +}
> +
>  /*
>   * Receive and parse a reply from the terminal.
>   *
> @@ -74,32 +84,42 @@ static int term_read_reply(int *n, int num, char end_char)
>  {
>   char c;
>   int i = 0;
> + u64 timeout;
>  
> - c = getc();
> - if (c != cESC)
> + /* Allow up to one second for the response */
> + timeout = timer_get_us() + 100;

Even at 110 baud a waiting time of 100 ms is sufficient.

> + while (!tstc())
> + if (timer_get_us() > timeout)
> + return -1;

This loop could be moved to term_get_char().

> +
> + if (term_get_char() || c != cESC)
>   return -1;
> - c = getc();
> - if (c != '[')
> +
> + if (term_get_char() || c != '[')

We should allow time for this character to arrive.

>   return -1;
>  
>   n[0] = 0;
>   while (1) {
> - c = getc();
> - if (c == ';') {
> - i++;
> - if (i >= num)> +if (!term_get_char()) 
> {

On loop entry there is no wait before this term_get_char().

Best regards

Heinrich

> + 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 (timer_get_us() > timeout)
> + return -1;
>   }
>   if (i != num - 1)
>   return -1;
> @@ -196,7 +216,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 +235,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

[U-Boot] [RFC] drivers: serial: Check only input buffers in pending

[matthias . bgg]

From: Matthias Brugger 

Serial device function pending allows to check the state of the input
and output buffers. But in fact only a check for the input buffers
is used in the device model. There are even some driver which discard a
check on the output buffers. So delete the check for the output buffers
to reflect that fact in the function definition.

Signed-off-by: Matthias Brugger 
---
 drivers/serial/altera_jtag_uart.c  |  7 ++-
 drivers/serial/altera_uart.c   |  7 ++-
 drivers/serial/arm_dcc.c   |  8 ++--
 drivers/serial/atmel_usart.c   |  7 ++-
 drivers/serial/lpc32xx_hsuart.c| 11 +++
 drivers/serial/mcfuart.c   |  9 ++---
 drivers/serial/ns16550.c   |  7 ++-
 drivers/serial/sandbox.c   |  7 ++-
 drivers/serial/serial-uclass.c |  2 +-
 drivers/serial/serial_ar933x.c |  8 +++-
 drivers/serial/serial_arc.c|  7 ++-
 drivers/serial/serial_bcm283x_mu.c | 10 +++---
 drivers/serial/serial_bcm6345.c|  7 ++-
 drivers/serial/serial_efi.c|  6 +-
 drivers/serial/serial_linflexuart.c|  7 ++-
 drivers/serial/serial_lpuart.c | 14 +++---
 drivers/serial/serial_meson.c  |  7 ++-
 drivers/serial/serial_mpc8xx.c |  5 +
 drivers/serial/serial_msm.c|  8 +++-
 drivers/serial/serial_mtk.c|  9 +++--
 drivers/serial/serial_mvebu_a3700.c|  2 +-
 drivers/serial/serial_mxc.c|  7 ++-
 drivers/serial/serial_nulldev.c|  2 +-
 drivers/serial/serial_owl.c|  7 ++-
 drivers/serial/serial_pic32.c  |  7 ++-
 drivers/serial/serial_pl01x.c  |  7 ++-
 drivers/serial/serial_pl01x_internal.h |  2 +-
 drivers/serial/serial_pxa.c|  9 ++---
 drivers/serial/serial_s5p.c|  7 ++-
 drivers/serial/serial_sh.c |  2 +-
 drivers/serial/serial_sifive.c | 14 +-
 drivers/serial/serial_sti_asc.c| 11 ---
 drivers/serial/serial_stm32.c  | 10 +++---
 drivers/serial/serial_uniphier.c   |  7 ++-
 drivers/serial/serial_xuartlite.c  |  7 ++-
 drivers/serial/serial_zynq.c   |  7 ++-
 include/serial.h   |  4 ++--
 37 files changed, 83 insertions(+), 182 deletions(-)

diff --git a/drivers/serial/altera_jtag_uart.c 
b/drivers/serial/altera_jtag_uart.c
index 86c3de4e45..7f52399312 100644
--- a/drivers/serial/altera_jtag_uart.c
+++ b/drivers/serial/altera_jtag_uart.c
@@ -53,16 +53,13 @@ static int altera_jtaguart_putc(struct udevice *dev, const 
char ch)
return 0;
 }
 
-static int altera_jtaguart_pending(struct udevice *dev, bool input)
+static int altera_jtaguart_pending(struct udevice *dev)
 {
struct altera_jtaguart_platdata *plat = dev->platdata;
struct altera_jtaguart_regs *const regs = plat->regs;
u32 st = readl(>control);
 
-   if (input)
-   return st & ALTERA_JTAG_RRDY ? 1 : 0;
-   else
-   return !(ALTERA_JTAG_WSPACE(st) == ALTERA_JTAG_WRITE_DEPTH);
+   return st & ALTERA_JTAG_RRDY ? 1 : 0;
 }
 
 static int altera_jtaguart_getc(struct udevice *dev)
diff --git a/drivers/serial/altera_uart.c b/drivers/serial/altera_uart.c
index 67d47199aa..f3f8d908bf 100644
--- a/drivers/serial/altera_uart.c
+++ b/drivers/serial/altera_uart.c
@@ -56,16 +56,13 @@ static int altera_uart_putc(struct udevice *dev, const char 
ch)
return 0;
 }
 
-static int altera_uart_pending(struct udevice *dev, bool input)
+static int altera_uart_pending(struct udevice *dev)
 {
struct altera_uart_platdata *plat = dev->platdata;
struct altera_uart_regs *const regs = plat->regs;
u32 st = readl(>status);
 
-   if (input)
-   return st & ALTERA_UART_RRDY ? 1 : 0;
-   else
-   return !(st & ALTERA_UART_TMT);
+   return st & ALTERA_UART_RRDY ? 1 : 0;
 }
 
 static int altera_uart_getc(struct udevice *dev)
diff --git a/drivers/serial/arm_dcc.c b/drivers/serial/arm_dcc.c
index dfcb6fd698..0771f90e7c 100644
--- a/drivers/serial/arm_dcc.c
+++ b/drivers/serial/arm_dcc.c
@@ -126,15 +126,11 @@ static int arm_dcc_putc(struct udevice *dev, char ch)
return 0;
 }
 
-static int arm_dcc_pending(struct udevice *dev, bool input)
+static int arm_dcc_pending(struct udevice *dev)
 {
register unsigned int reg;
 
-   if (input) {
-   can_read_dcc(reg);
-   } else {
-   can_write_dcc(reg);
-   }
+   can_read_dcc(reg);
 
return reg;
 }
diff --git a/drivers/serial/atmel_usart.c b/drivers/serial/atmel_usart.c
index aa8cdff840..fdde966da2 100644
--- a/drivers/serial/atmel_usart.c
+++ b/drivers/serial/atmel_usart.c
@@ -200,15 +200,12 @@ static int atmel_serial_putc(struct udevice *dev, const 
char ch)
return 0;
 }
 
-static int atmel_serial_pending(struct 

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

[Dalon L Westergreen]

On Tue, 2019-02-26 at 16:42 +0100, Michal Simek wrote:
> On 26. 02. 19 15:28, Chee, Tien Fong wrote:
> > On Tue, 2019-02-26 at 15:06 +0100, Michal Simek wrote:
> > > On 19. 02. 19 4:47, 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 
> > > > 
> > > > ---
> > > > 
> > > > changes for v8
> > > > - Removed explanation about support for altr,bitstream-core
> > > > 
> > > > changes for v7
> > > > - Provided example of setting FPGA FIT image for both early IO
> > > > release
> > > >   and full release FPGA configuration.
> > > > ---
> > > >  .../fpga/altera-socfpga-a10-fpga-mgr.txt   | 26
> > > > +-
> > > >  1 file changed, 25 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-
> > > > mgr.txt b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-
> > > > mgr.txt
> > > > index 2fd8e7a..da210bf 100644
> > > > --- a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt
> > > > +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt
> > > > @@ -7,8 +7,31 @@ Required properties:
> > > > - The second index is for writing FPGA
> > > > configuration data.
> > > >  - resets : Phandle and reset specifier for the device's reset.
> > > >  - clocks : Clocks used by the device.
> > > > +- altr,bitstream : Fit image file name for both FPGA peripheral
> > > > bitstream,
> > > > +  FPGA core bitstream and full bitstream.
> > > >  
> > > By adding new required property you are automatically saying that you
> > > want to break all current users.
> > This is company's product specific property, that's why with prefix
> > "altr". DT allows that ,right?
> 
> no issue with altr prefix. Issue is that you add a required property and
> breaking all current users.
> It should be optional.

This parameter is only for Arria10, which at this point is not fully supported
in mainline uboot.  So this doesnt affect any existing designs, no?

--dalon

> 
> M
> 
> 
> 

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

[U-Boot] [PATCH] driver: net: fsl-mc: Fix DPC MAC address fixup

[Ioana Ciocoi Radulescu]

If node /board_info/ports does not exist in the DPC file,
function mc_fixup_dpc() will skip not only MAC address fixup,
but also the cache flush at the end. This may cause the other
fixup changes (e.g. ICID relatd ones) to be ignored by MC.

Fixes: 1161dbcc0a36 ("drivers: net: fsl-mc: Include MAC addr fixup to DPL")

Signed-off-by: Ioana Radulescu 
---
 drivers/net/fsl-mc/mc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
index a51b8a4..e6cf7f3 100644
--- a/drivers/net/fsl-mc/mc.c
+++ b/drivers/net/fsl-mc/mc.c
@@ -421,9 +421,11 @@ static int mc_fixup_dpc(u64 dpc_addr)
/* fixup MAC addresses for dpmac ports */
nodeoffset = fdt_path_offset(blob, "/board_info/ports");
if (nodeoffset < 0)
-   return 0;
+   goto out;
 
err = mc_fixup_mac_addrs(blob, MC_FIXUP_DPC);
+
+out:
flush_dcache_range(dpc_addr, dpc_addr + fdt_totalsize(blob));
 
return err;
-- 
2.7.4

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

[U-Boot] [U-BOOT] fs: ext4: Problem with ext4load and sparse files

[Gero Schumacher]

Hi,

when I try to load a sparse file via ext4load, I am getting the error message
'invalid extent'

After a deeper look in the code, it seems to be an issue in the function 
ext4fs_get_extent_block in fs/ext4/ext4_common.c:

The file starts with 1k of zeros. The blocksize is 1024. So the first extend 
block contains the following information:

eh_entries: 1
eh_depth: 1
ei_block 1

When the upper layer (ext4fs_read_file) asks for fileblock 0, we are running in 
the 'invalid extent' error message.
For me it seems, that the code is not prepared for handling a sparse block at 
the beginning of the file. The following change, solved my problem:

diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index 67e2471bd3..7c8080d740 100644
--- a/fs/ext4/ext4_common.c
+++ b/fs/ext4/ext4_common.c
@@ -1546,8 +1546,10 @@ static struct ext4_extent_header *ext4fs_get_extent_block
break;
} while (fileblock >= le32_to_cpu(index[i].ei_block));

-   if (--i < 0)
-   return NULL;
+   /* if first logical block number is higher than requested 
fileblock,
+  it is a sparse file. This is handled on upper layer */
+   if (i > 0)
+   i--;

block = le16_to_cpu(index[i].ei_leaf_hi);
block = (block << 32) + le32_to_cpu(index[i].ei_leaf_lo);


I am really not an expert in ext4 filesystems. Can somebody please have a look 
at this issue and give me a feedback, if I am totally wrong or not?

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

Re: [U-Boot] [PATCH v9 3/7] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading

[Michal Simek]

On 26. 02. 19 15:53, Chee, Tien Fong wrote:
> On Tue, 2019-02-26 at 15:20 +0100, Michal Simek wrote:
>> On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
>>>
>>> From: Tien Fong Chee 
>>>
>>> Add FPGA driver to support program FPGA with FPGA bitstream loading
>>> from
>>> filesystem. The driver are designed based on generic firmware
>>> loader
>>> framework. The driver can handle FPGA program operation from
>>> loading FPGA
>>> bitstream in flash to memory and then to program FPGA.
>>>
>>> Signed-off-by: Tien Fong Chee 
>>>
>>> ---
>>>
>>> changes for v9
>>> - Support data offset
>>> - Added default DDR load address
>>> - Squashed the image.h
>>> - Changed to phandle
>>> - Ensure the DDR is fully up running by checking the gd->ram
>>>
>>> changes for v8
>>> - Added codes to discern bitstream type based on fpga node name.
>>>
>>> changes for v7
>>> - Restructure the FPGA driver to support both peripheral bitstream
>>> and core
>>>   bitstream bundled into FIT image.
>>> - Support loadable property for core bitstream. User can set
>>> loadable
>>>   in DDR for better performance. This loading would be done in one
>>> large
>>>   chunk instead of chunk by chunk loading with small memory buffer.
>>> ---
>>>  arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts   |  17 +
>>>  .../include/mach/fpga_manager_arria10.h|  40 +-
>>>  drivers/fpga/socfpga_arria10.c | 533
>>> -
>>>  include/image.h|   4 +
>>>  4 files changed, 571 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
>>> b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
>>> index 998d811..9d43111 100644
>>> --- a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
>>> +++ b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
>>> @@ -18,6 +18,23 @@
>>>  /dts-v1/;
>>>  #include "socfpga_arria10_socdk.dtsi"
>>>  
>>> +/ {
>>> +   chosen {
>>> +   firmware-loader = <_loader0>;
>>> +   };
>>> +
>>> +   fs_loader0: fs-loader@0 {
>> again @0 without reg properly is wrong.
> Mind to explain more?
>>
>>>
>>> +   u-boot,dm-pre-reloc;
>>> +   compatible = "u-boot,fs-loader";
>>> +   phandlepart = < 1>;
>>> +   };
>> I think that this will be nacked by DT guys.
>>
>>>
>>> +};
>>> +
>>> +_mgr {
>>> +   u-boot,dm-pre-reloc;
>>> +   altr,bitstream = "fit_spl_fpga.itb";
>>> +};
>>> +
>>>   {
>>>     u-boot,dm-pre-reloc;
>>>     status = "okay";
>>> diff --git a/arch/arm/mach-
>>> socfpga/include/mach/fpga_manager_arria10.h b/arch/arm/mach-
>>> socfpga/include/mach/fpga_manager_arria10.h
>>> index 09d13f6..7a4f723 100644
>>> --- a/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
>>> +++ b/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
>>> @@ -1,9 +1,13 @@
>>>  /* SPDX-License-Identifier: GPL-2.0 */
>>>  /*
>>> - * Copyright (C) 2017 Intel Corporation 
>>> + * Copyright (C) 2017-2019 Intel Corporation 
>>>   * All rights reserved.
>>>   */
>>>  
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>>  #ifndef _FPGA_MANAGER_ARRIA10_H_
>>>  #define _FPGA_MANAGER_ARRIA10_H_
>>>  
>>> @@ -51,6 +55,10 @@
>>>  #define ALT_FPGAMGR_IMGCFG_CTL_02_CFGWIDTH_SET_MSK 
>>> BIT(24)
>>>  #define ALT_FPGAMGR_IMGCFG_CTL_02_CDRATIO_LSB  
>>> 16
>>>  
>>> +#define FPGA_SOCFPGA_A10_RBF_UNENCRYPTED   0xa65c
>>> +#define FPGA_SOCFPGA_A10_RBF_ENCRYPTED 0xa65d
>>> +#define FPGA_SOCFPGA_A10_RBF_PERIPH0x0001
>>> +#define FPGA_SOCFPGA_A10_RBF_CORE  0x8001
>>>  #ifndef __ASSEMBLY__
>>>  
>>>  struct socfpga_fpga_manager {
>>> @@ -88,12 +96,40 @@ struct socfpga_fpga_manager {
>>>     u32  imgcfg_fifo_status;
>>>  };
>>>  
>>> +enum rbf_type {
>>> +   unknown,
>>> +   periph_section,
>>> +   core_section
>>> +};
>>> +
>>> +enum rbf_security {
>>> +   invalid,
>>> +   unencrypted,
>>> +   encrypted
>>> +};
>>> +
>>> +struct rbf_info {
>>> +   enum rbf_type section;
>>> +   enum rbf_security security;
>>> +};
>>> +
>>> +struct fpga_loadfs_info {
>>> +   fpga_fs_info *fpga_fsinfo;
>>> +   u32 remaining;
>>> +   u32 offset;
>>> +   struct rbf_info rbfinfo;
>>> +};
>>> +
>>>  /* Functions */
>>>  int fpgamgr_program_init(u32 * rbf_data, size_t rbf_size);
>>>  int fpgamgr_program_finish(void);
>>>  int is_fpgamgr_user_mode(void);
>>>  int fpgamgr_wait_early_user_mode(void);
>>> -
>>> +int is_fpgamgr_early_user_mode(void);
>>> +const char *get_fpga_filename(const void *fdt, int *len);
>>> +int socfpga_loadfs(fpga_fs_info *fpga_fsinfo, const void *buf,
>>> size_t bsize,
>>> +     u32 offset);
>>> +void fpgamgr_program(const void *buf, size_t bsize, u32 offset);
>>>  #endif /* __ASSEMBLY__ */
>>>  
>>>  #endif /* _FPGA_MANAGER_ARRIA10_H_ */
>>> diff --git a/drivers/fpga/socfpga_arria10.c
>>> b/drivers/fpga/socfpga_arria10.c
>>> index 114dd91..9936b69 100644
>>> --- a/drivers/fpga/socfpga_arria10.c
>>> +++ b/drivers/fpga/socfpga_arria10.c
>>> @@ -1,8 +1,7 @@
>>>  // 

Re: [U-Boot] [PATCH v9 2/7] ARM: socfpga: Add default FPGA bitstream fitImage for Arria10 SoCDK

[Michal Simek]

On 26. 02. 19 15:30, Chee, Tien Fong wrote:
> On Tue, 2019-02-26 at 15:07 +0100, Michal Simek wrote:
>> On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
>>>
>>> From: Tien Fong Chee 
>>>
>>> Add default fitImage file bundling FPGA bitstreams for Arria10.
>>>
>>> Signed-off-by: Tien Fong Chee 
>>>
>>> ---
>>>
>>> changes for v8
>>> - Reordered the images and fpga configurations.
>>> - Removed the load property at core image.
>>>
>>> changes for v8
>>> - Changed the FPGA node name to fpga-core and fpga-periph for both
>>> core and
>>>   periph bitstreams respectively.
>>> ---
>>>  board/altera/arria10-socdk/fit_spl_fpga.its | 38
>>> +
>>>  1 file changed, 38 insertions(+)
>>>  create mode 100644 board/altera/arria10-socdk/fit_spl_fpga.its
>>>
>>> diff --git a/board/altera/arria10-socdk/fit_spl_fpga.its
>>> b/board/altera/arria10-socdk/fit_spl_fpga.its
>>> new file mode 100644
>>> index 000..df84562
>>> --- /dev/null
>>> +++ b/board/altera/arria10-socdk/fit_spl_fpga.its
>>> @@ -0,0 +1,38 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> + /*
>>> + * Copyright (C) 2019 Intel Corporation 
>>> + *
>>> + */
>>> +
>>> +/dts-v1/;
>>> +
>>> +/ {
>>> +   description = "FIT image with FPGA bistream";
>>> +   #address-cells = <1>;
>>> +
>>> +   images {
>>> +   fpga-periph@1 {
>> Still this is DT and using @1 without reg property below is wrong.
> Sorry, i'm not getting you.
> Mind to explain more?

it should be just fpga-periph {
because you don't have reg properly below.

M




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




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

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

[Michal Simek]

On 26. 02. 19 15:28, Chee, Tien Fong wrote:
> On Tue, 2019-02-26 at 15:06 +0100, Michal Simek wrote:
>> On 19. 02. 19 4:47, 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 
>>>
>>> ---
>>>
>>> changes for v8
>>> - Removed explanation about support for altr,bitstream-core
>>>
>>> changes for v7
>>> - Provided example of setting FPGA FIT image for both early IO
>>> release
>>>   and full release FPGA configuration.
>>> ---
>>>  .../fpga/altera-socfpga-a10-fpga-mgr.txt   | 26
>>> +-
>>>  1 file changed, 25 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-
>>> mgr.txt b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-
>>> mgr.txt
>>> index 2fd8e7a..da210bf 100644
>>> --- a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt
>>> +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt
>>> @@ -7,8 +7,31 @@ Required properties:
>>> - The second index is for writing FPGA
>>> configuration data.
>>>  - resets : Phandle and reset specifier for the device's reset.
>>>  - clocks : Clocks used by the device.
>>> +- altr,bitstream : Fit image file name for both FPGA peripheral
>>> bitstream,
>>> +      FPGA core bitstream and full bitstream.
>>>  
>> By adding new required property you are automatically saying that you
>> want to break all current users.
> This is company's product specific property, that's why with prefix
> "altr". DT allows that ,right?

no issue with altr prefix. Issue is that you add a required property and
breaking all current users.
It should be optional.

M



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




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

Re: [U-Boot] [PATCH v9 3/7] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading

[Chee, Tien Fong]

On Tue, 2019-02-26 at 15:20 +0100, Michal Simek wrote:
> On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Add FPGA driver to support program FPGA with FPGA bitstream loading
> > from
> > filesystem. The driver are designed based on generic firmware
> > loader
> > framework. The driver can handle FPGA program operation from
> > loading FPGA
> > bitstream in flash to memory and then to program FPGA.
> > 
> > Signed-off-by: Tien Fong Chee 
> > 
> > ---
> > 
> > changes for v9
> > - Support data offset
> > - Added default DDR load address
> > - Squashed the image.h
> > - Changed to phandle
> > - Ensure the DDR is fully up running by checking the gd->ram
> > 
> > changes for v8
> > - Added codes to discern bitstream type based on fpga node name.
> > 
> > changes for v7
> > - Restructure the FPGA driver to support both peripheral bitstream
> > and core
> >   bitstream bundled into FIT image.
> > - Support loadable property for core bitstream. User can set
> > loadable
> >   in DDR for better performance. This loading would be done in one
> > large
> >   chunk instead of chunk by chunk loading with small memory buffer.
> > ---
> >  arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts   |  17 +
> >  .../include/mach/fpga_manager_arria10.h|  40 +-
> >  drivers/fpga/socfpga_arria10.c | 533
> > -
> >  include/image.h|   4 +
> >  4 files changed, 571 insertions(+), 23 deletions(-)
> > 
> > diff --git a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > index 998d811..9d43111 100644
> > --- a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > +++ b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > @@ -18,6 +18,23 @@
> >  /dts-v1/;
> >  #include "socfpga_arria10_socdk.dtsi"
> >  
> > +/ {
> > +   chosen {
> > +   firmware-loader = <_loader0>;
> > +   };
> > +
> > +   fs_loader0: fs-loader@0 {
> again @0 without reg properly is wrong.
Mind to explain more?
> 
> > 
> > +   u-boot,dm-pre-reloc;
> > +   compatible = "u-boot,fs-loader";
> > +   phandlepart = < 1>;
> > +   };
> I think that this will be nacked by DT guys.
> 
> > 
> > +};
> > +
> > +_mgr {
> > +   u-boot,dm-pre-reloc;
> > +   altr,bitstream = "fit_spl_fpga.itb";
> > +};
> > +
> >   {
> >     u-boot,dm-pre-reloc;
> >     status = "okay";
> > diff --git a/arch/arm/mach-
> > socfpga/include/mach/fpga_manager_arria10.h b/arch/arm/mach-
> > socfpga/include/mach/fpga_manager_arria10.h
> > index 09d13f6..7a4f723 100644
> > --- a/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
> > +++ b/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
> > @@ -1,9 +1,13 @@
> >  /* SPDX-License-Identifier: GPL-2.0 */
> >  /*
> > - * Copyright (C) 2017 Intel Corporation 
> > + * Copyright (C) 2017-2019 Intel Corporation 
> >   * All rights reserved.
> >   */
> >  
> > +#include 
> > +#include 
> > +#include 
> > +
> >  #ifndef _FPGA_MANAGER_ARRIA10_H_
> >  #define _FPGA_MANAGER_ARRIA10_H_
> >  
> > @@ -51,6 +55,10 @@
> >  #define ALT_FPGAMGR_IMGCFG_CTL_02_CFGWIDTH_SET_MSK 
> > BIT(24)
> >  #define ALT_FPGAMGR_IMGCFG_CTL_02_CDRATIO_LSB  
> > 16
> >  
> > +#define FPGA_SOCFPGA_A10_RBF_UNENCRYPTED   0xa65c
> > +#define FPGA_SOCFPGA_A10_RBF_ENCRYPTED 0xa65d
> > +#define FPGA_SOCFPGA_A10_RBF_PERIPH0x0001
> > +#define FPGA_SOCFPGA_A10_RBF_CORE  0x8001
> >  #ifndef __ASSEMBLY__
> >  
> >  struct socfpga_fpga_manager {
> > @@ -88,12 +96,40 @@ struct socfpga_fpga_manager {
> >     u32  imgcfg_fifo_status;
> >  };
> >  
> > +enum rbf_type {
> > +   unknown,
> > +   periph_section,
> > +   core_section
> > +};
> > +
> > +enum rbf_security {
> > +   invalid,
> > +   unencrypted,
> > +   encrypted
> > +};
> > +
> > +struct rbf_info {
> > +   enum rbf_type section;
> > +   enum rbf_security security;
> > +};
> > +
> > +struct fpga_loadfs_info {
> > +   fpga_fs_info *fpga_fsinfo;
> > +   u32 remaining;
> > +   u32 offset;
> > +   struct rbf_info rbfinfo;
> > +};
> > +
> >  /* Functions */
> >  int fpgamgr_program_init(u32 * rbf_data, size_t rbf_size);
> >  int fpgamgr_program_finish(void);
> >  int is_fpgamgr_user_mode(void);
> >  int fpgamgr_wait_early_user_mode(void);
> > -
> > +int is_fpgamgr_early_user_mode(void);
> > +const char *get_fpga_filename(const void *fdt, int *len);
> > +int socfpga_loadfs(fpga_fs_info *fpga_fsinfo, const void *buf,
> > size_t bsize,
> > +     u32 offset);
> > +void fpgamgr_program(const void *buf, size_t bsize, u32 offset);
> >  #endif /* __ASSEMBLY__ */
> >  
> >  #endif /* _FPGA_MANAGER_ARRIA10_H_ */
> > diff --git a/drivers/fpga/socfpga_arria10.c
> > b/drivers/fpga/socfpga_arria10.c
> > index 114dd91..9936b69 100644
> > --- a/drivers/fpga/socfpga_arria10.c
> > +++ b/drivers/fpga/socfpga_arria10.c
> > @@ -1,8 +1,7 @@
> >  // SPDX-License-Identifier: GPL-2.0
> >  /*
> > - * 

Re: [U-Boot] [PATCH v9 3/7] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading

[Chee, Tien Fong]

On Tue, 2019-02-26 at 15:20 +0100, Michal Simek wrote:
> On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Add FPGA driver to support program FPGA with FPGA bitstream loading
> > from
> > filesystem. The driver are designed based on generic firmware
> > loader
> > framework. The driver can handle FPGA program operation from
> > loading FPGA
> > bitstream in flash to memory and then to program FPGA.
> > 
> > Signed-off-by: Tien Fong Chee 
> > 
> > ---
> > 
> > changes for v9
> > - Support data offset
> > - Added default DDR load address
> > - Squashed the image.h
> > - Changed to phandle
> > - Ensure the DDR is fully up running by checking the gd->ram
> > 
> > changes for v8
> > - Added codes to discern bitstream type based on fpga node name.
> > 
> > changes for v7
> > - Restructure the FPGA driver to support both peripheral bitstream
> > and core
> >   bitstream bundled into FIT image.
> > - Support loadable property for core bitstream. User can set
> > loadable
> >   in DDR for better performance. This loading would be done in one
> > large
> >   chunk instead of chunk by chunk loading with small memory buffer.
> > ---
> >  arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts   |  17 +
> >  .../include/mach/fpga_manager_arria10.h|  40 +-
> >  drivers/fpga/socfpga_arria10.c | 533
> > -
> >  include/image.h|   4 +
> >  4 files changed, 571 insertions(+), 23 deletions(-)
> > 
> > diff --git a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > index 998d811..9d43111 100644
> > --- a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > +++ b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > @@ -18,6 +18,23 @@
> >  /dts-v1/;
> >  #include "socfpga_arria10_socdk.dtsi"
> >  
> > +/ {
> > +   chosen {
> > +   firmware-loader = <_loader0>;
> > +   };
> > +
> > +   fs_loader0: fs-loader@0 {
> again @0 without reg properly is wrong.
> 
> > 
> > +   u-boot,dm-pre-reloc;
> > +   compatible = "u-boot,fs-loader";
> > +   phandlepart = < 1>;
> > +   };
> I think that this will be nacked by DT guys.
We have reached common agrement between Simon and Tom that this would
be the way to implement the software policy.
> 
> > 
> > +};
> > +
> > +_mgr {
> > +   u-boot,dm-pre-reloc;
> > +   altr,bitstream = "fit_spl_fpga.itb";
> > +};
> > +
> >   {
> >     u-boot,dm-pre-reloc;
> >     status = "okay";
> > diff --git a/arch/arm/mach-
> > socfpga/include/mach/fpga_manager_arria10.h b/arch/arm/mach-
> > socfpga/include/mach/fpga_manager_arria10.h
> > index 09d13f6..7a4f723 100644
> > --- a/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
> > +++ b/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
> > @@ -1,9 +1,13 @@
> >  /* SPDX-License-Identifier: GPL-2.0 */
> >  /*
> > - * Copyright (C) 2017 Intel Corporation 
> > + * Copyright (C) 2017-2019 Intel Corporation 
> >   * All rights reserved.
> >   */
> >  
> > +#include 
> > +#include 
> > +#include 
> > +
> >  #ifndef _FPGA_MANAGER_ARRIA10_H_
> >  #define _FPGA_MANAGER_ARRIA10_H_
> >  
> > @@ -51,6 +55,10 @@
> >  #define ALT_FPGAMGR_IMGCFG_CTL_02_CFGWIDTH_SET_MSK 
> > BIT(24)
> >  #define ALT_FPGAMGR_IMGCFG_CTL_02_CDRATIO_LSB  
> > 16
> >  
> > +#define FPGA_SOCFPGA_A10_RBF_UNENCRYPTED   0xa65c
> > +#define FPGA_SOCFPGA_A10_RBF_ENCRYPTED 0xa65d
> > +#define FPGA_SOCFPGA_A10_RBF_PERIPH0x0001
> > +#define FPGA_SOCFPGA_A10_RBF_CORE  0x8001
> >  #ifndef __ASSEMBLY__
> >  
> >  struct socfpga_fpga_manager {
> > @@ -88,12 +96,40 @@ struct socfpga_fpga_manager {
> >     u32  imgcfg_fifo_status;
> >  };
> >  
> > +enum rbf_type {
> > +   unknown,
> > +   periph_section,
> > +   core_section
> > +};
> > +
> > +enum rbf_security {
> > +   invalid,
> > +   unencrypted,
> > +   encrypted
> > +};
> > +
> > +struct rbf_info {
> > +   enum rbf_type section;
> > +   enum rbf_security security;
> > +};
> > +
> > +struct fpga_loadfs_info {
> > +   fpga_fs_info *fpga_fsinfo;
> > +   u32 remaining;
> > +   u32 offset;
> > +   struct rbf_info rbfinfo;
> > +};
> > +
> >  /* Functions */
> >  int fpgamgr_program_init(u32 * rbf_data, size_t rbf_size);
> >  int fpgamgr_program_finish(void);
> >  int is_fpgamgr_user_mode(void);
> >  int fpgamgr_wait_early_user_mode(void);
> > -
> > +int is_fpgamgr_early_user_mode(void);
> > +const char *get_fpga_filename(const void *fdt, int *len);
> > +int socfpga_loadfs(fpga_fs_info *fpga_fsinfo, const void *buf,
> > size_t bsize,
> > +     u32 offset);
> > +void fpgamgr_program(const void *buf, size_t bsize, u32 offset);
> >  #endif /* __ASSEMBLY__ */
> >  
> >  #endif /* _FPGA_MANAGER_ARRIA10_H_ */
> > diff --git a/drivers/fpga/socfpga_arria10.c
> > b/drivers/fpga/socfpga_arria10.c
> > index 114dd91..9936b69 100644
> > --- a/drivers/fpga/socfpga_arria10.c
> > +++ 

Re: [U-Boot] [PATCH v9 2/7] ARM: socfpga: Add default FPGA bitstream fitImage for Arria10 SoCDK

[Chee, Tien Fong]

On Tue, 2019-02-26 at 15:07 +0100, Michal Simek wrote:
> On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Add default fitImage file bundling FPGA bitstreams for Arria10.
> > 
> > Signed-off-by: Tien Fong Chee 
> > 
> > ---
> > 
> > changes for v8
> > - Reordered the images and fpga configurations.
> > - Removed the load property at core image.
> > 
> > changes for v8
> No reason to have separate v8 changes.
Sorry for typo, that's v9.
> 
> > 
> > - Changed the FPGA node name to fpga-core and fpga-periph for both
> > core and
> >   periph bitstreams respectively.
> M
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v9 2/7] ARM: socfpga: Add default FPGA bitstream fitImage for Arria10 SoCDK

[Chee, Tien Fong]

On Tue, 2019-02-26 at 15:07 +0100, Michal Simek wrote:
> On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Add default fitImage file bundling FPGA bitstreams for Arria10.
> > 
> > Signed-off-by: Tien Fong Chee 
> > 
> > ---
> > 
> > changes for v8
> > - Reordered the images and fpga configurations.
> > - Removed the load property at core image.
> > 
> > changes for v8
> > - Changed the FPGA node name to fpga-core and fpga-periph for both
> > core and
> >   periph bitstreams respectively.
> > ---
> >  board/altera/arria10-socdk/fit_spl_fpga.its | 38
> > +
> >  1 file changed, 38 insertions(+)
> >  create mode 100644 board/altera/arria10-socdk/fit_spl_fpga.its
> > 
> > diff --git a/board/altera/arria10-socdk/fit_spl_fpga.its
> > b/board/altera/arria10-socdk/fit_spl_fpga.its
> > new file mode 100644
> > index 000..df84562
> > --- /dev/null
> > +++ b/board/altera/arria10-socdk/fit_spl_fpga.its
> > @@ -0,0 +1,38 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > + /*
> > + * Copyright (C) 2019 Intel Corporation 
> > + *
> > + */
> > +
> > +/dts-v1/;
> > +
> > +/ {
> > +   description = "FIT image with FPGA bistream";
> > +   #address-cells = <1>;
> > +
> > +   images {
> > +   fpga-periph@1 {
> Still this is DT and using @1 without reg property below is wrong.
Sorry, i'm not getting you.
Mind to explain more?
> 
> > 
> > +   description = "FPGA peripheral bitstream";
> > +   data =
> > /incbin/("../../../ghrd_10as066n2.periph.rbf");
> > +   type = "fpga";
> > +   arch = "arm";
> > +   compression = "none";
> > +   };
> > +
> > +   fpga-core@2 {
> ditto.
> 
> > 
> > +   description = "FPGA core bitstream";
> > +   data =
> > /incbin/("../../../ghrd_10as066n2.core.rbf");
> > +   type = "fpga";
> > +   arch = "arm";
> > +   compression = "none";
> > +   };
> > +   };
> > +
> > +   configurations {
> > +   default = "config-1";
> > +   config-1 {
> > +   description = "Boot with FPGA early IO
> > release config";
> > +   fpga = "fpga-periph@1", "fpga-core@2";
> > +   };
> > +   };
> > +};
> > 
> M
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Chee, Tien Fong]

On Tue, 2019-02-26 at 15:06 +0100, Michal Simek wrote:
> On 19. 02. 19 4:47, 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 
> > 
> > ---
> > 
> > changes for v8
> > - Removed explanation about support for altr,bitstream-core
> > 
> > changes for v7
> > - Provided example of setting FPGA FIT image for both early IO
> > release
> >   and full release FPGA configuration.
> > ---
> >  .../fpga/altera-socfpga-a10-fpga-mgr.txt   | 26
> > +-
> >  1 file changed, 25 insertions(+), 1 deletion(-)
> > 
> > diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-
> > mgr.txt b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-
> > mgr.txt
> > index 2fd8e7a..da210bf 100644
> > --- a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt
> > +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt
> > @@ -7,8 +7,31 @@ Required properties:
> > - The second index is for writing FPGA
> > configuration data.
> >  - resets : Phandle and reset specifier for the device's reset.
> >  - clocks : Clocks used by the device.
> > +- altr,bitstream : Fit image file name for both FPGA peripheral
> > bitstream,
> > +      FPGA core bitstream and full bitstream.
> >  
> By adding new required property you are automatically saying that you
> want to break all current users.
This is company's product specific property, that's why with prefix
"altr". DT allows that ,right?
> 
> M
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v9 3/7] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading

[Michal Simek]

On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 
> 
> Add FPGA driver to support program FPGA with FPGA bitstream loading from
> filesystem. The driver are designed based on generic firmware loader
> framework. The driver can handle FPGA program operation from loading FPGA
> bitstream in flash to memory and then to program FPGA.
> 
> Signed-off-by: Tien Fong Chee 
> 
> ---
> 
> changes for v9
> - Support data offset
> - Added default DDR load address
> - Squashed the image.h
> - Changed to phandle
> - Ensure the DDR is fully up running by checking the gd->ram
> 
> changes for v8
> - Added codes to discern bitstream type based on fpga node name.
> 
> changes for v7
> - Restructure the FPGA driver to support both peripheral bitstream and core
>   bitstream bundled into FIT image.
> - Support loadable property for core bitstream. User can set loadable
>   in DDR for better performance. This loading would be done in one large
>   chunk instead of chunk by chunk loading with small memory buffer.
> ---
>  arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts   |  17 +
>  .../include/mach/fpga_manager_arria10.h|  40 +-
>  drivers/fpga/socfpga_arria10.c | 533 
> -
>  include/image.h|   4 +
>  4 files changed, 571 insertions(+), 23 deletions(-)
> 
> diff --git a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts 
> b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> index 998d811..9d43111 100644
> --- a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> +++ b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> @@ -18,6 +18,23 @@
>  /dts-v1/;
>  #include "socfpga_arria10_socdk.dtsi"
>  
> +/ {
> + chosen {
> + firmware-loader = <_loader0>;
> + };
> +
> + fs_loader0: fs-loader@0 {

again @0 without reg properly is wrong.

> + u-boot,dm-pre-reloc;
> + compatible = "u-boot,fs-loader";
> + phandlepart = < 1>;
> + };

I think that this will be nacked by DT guys.

> +};
> +
> +_mgr {
> + u-boot,dm-pre-reloc;
> + altr,bitstream = "fit_spl_fpga.itb";
> +};
> +
>   {
>   u-boot,dm-pre-reloc;
>   status = "okay";
> diff --git a/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h 
> b/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
> index 09d13f6..7a4f723 100644
> --- a/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
> +++ b/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
> @@ -1,9 +1,13 @@
>  /* SPDX-License-Identifier: GPL-2.0 */
>  /*
> - * Copyright (C) 2017 Intel Corporation 
> + * Copyright (C) 2017-2019 Intel Corporation 
>   * All rights reserved.
>   */
>  
> +#include 
> +#include 
> +#include 
> +
>  #ifndef _FPGA_MANAGER_ARRIA10_H_
>  #define _FPGA_MANAGER_ARRIA10_H_
>  
> @@ -51,6 +55,10 @@
>  #define ALT_FPGAMGR_IMGCFG_CTL_02_CFGWIDTH_SET_MSK   BIT(24)
>  #define ALT_FPGAMGR_IMGCFG_CTL_02_CDRATIO_LSB16
>  
> +#define FPGA_SOCFPGA_A10_RBF_UNENCRYPTED 0xa65c
> +#define FPGA_SOCFPGA_A10_RBF_ENCRYPTED   0xa65d
> +#define FPGA_SOCFPGA_A10_RBF_PERIPH  0x0001
> +#define FPGA_SOCFPGA_A10_RBF_CORE0x8001
>  #ifndef __ASSEMBLY__
>  
>  struct socfpga_fpga_manager {
> @@ -88,12 +96,40 @@ struct socfpga_fpga_manager {
>   u32  imgcfg_fifo_status;
>  };
>  
> +enum rbf_type {
> + unknown,
> + periph_section,
> + core_section
> +};
> +
> +enum rbf_security {
> + invalid,
> + unencrypted,
> + encrypted
> +};
> +
> +struct rbf_info {
> + enum rbf_type section;
> + enum rbf_security security;
> +};
> +
> +struct fpga_loadfs_info {
> + fpga_fs_info *fpga_fsinfo;
> + u32 remaining;
> + u32 offset;
> + struct rbf_info rbfinfo;
> +};
> +
>  /* Functions */
>  int fpgamgr_program_init(u32 * rbf_data, size_t rbf_size);
>  int fpgamgr_program_finish(void);
>  int is_fpgamgr_user_mode(void);
>  int fpgamgr_wait_early_user_mode(void);
> -
> +int is_fpgamgr_early_user_mode(void);
> +const char *get_fpga_filename(const void *fdt, int *len);
> +int socfpga_loadfs(fpga_fs_info *fpga_fsinfo, const void *buf, size_t bsize,
> +   u32 offset);
> +void fpgamgr_program(const void *buf, size_t bsize, u32 offset);
>  #endif /* __ASSEMBLY__ */
>  
>  #endif /* _FPGA_MANAGER_ARRIA10_H_ */
> diff --git a/drivers/fpga/socfpga_arria10.c b/drivers/fpga/socfpga_arria10.c
> index 114dd91..9936b69 100644
> --- a/drivers/fpga/socfpga_arria10.c
> +++ b/drivers/fpga/socfpga_arria10.c
> @@ -1,8 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0
>  /*
> - * Copyright (C) 2017 Intel Corporation 
> + * Copyright (C) 2017-2019 Intel Corporation 
>   */
> -
>  #include 
>  #include 
>  #include 
> @@ -10,8 +9,11 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -21,6 +23,9 @@
>  #define COMPRESSION_OFFSET   229
>  #define FPGA_TIMEOUT_MSEC1000 

Re: [U-Boot] [PATCH v9 2/7] ARM: socfpga: Add default FPGA bitstream fitImage for Arria10 SoCDK

[Michal Simek]

On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 
> 
> Add default fitImage file bundling FPGA bitstreams for Arria10.
> 
> Signed-off-by: Tien Fong Chee 
> 
> ---
> 
> changes for v8
> - Reordered the images and fpga configurations.
> - Removed the load property at core image.
> 
> changes for v8

No reason to have separate v8 changes.

> - Changed the FPGA node name to fpga-core and fpga-periph for both core and
>   periph bitstreams respectively.

M

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




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

Re: [U-Boot] [PATCH v9 2/7] ARM: socfpga: Add default FPGA bitstream fitImage for Arria10 SoCDK

[Michal Simek]

On 19. 02. 19 4:47, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 
> 
> Add default fitImage file bundling FPGA bitstreams for Arria10.
> 
> Signed-off-by: Tien Fong Chee 
> 
> ---
> 
> changes for v8
> - Reordered the images and fpga configurations.
> - Removed the load property at core image.
> 
> changes for v8
> - Changed the FPGA node name to fpga-core and fpga-periph for both core and
>   periph bitstreams respectively.
> ---
>  board/altera/arria10-socdk/fit_spl_fpga.its | 38 
> +
>  1 file changed, 38 insertions(+)
>  create mode 100644 board/altera/arria10-socdk/fit_spl_fpga.its
> 
> diff --git a/board/altera/arria10-socdk/fit_spl_fpga.its 
> b/board/altera/arria10-socdk/fit_spl_fpga.its
> new file mode 100644
> index 000..df84562
> --- /dev/null
> +++ b/board/altera/arria10-socdk/fit_spl_fpga.its
> @@ -0,0 +1,38 @@
> +// SPDX-License-Identifier: GPL-2.0
> + /*
> + * Copyright (C) 2019 Intel Corporation 
> + *
> + */
> +
> +/dts-v1/;
> +
> +/ {
> + description = "FIT image with FPGA bistream";
> + #address-cells = <1>;
> +
> + images {
> + fpga-periph@1 {

Still this is DT and using @1 without reg property below is wrong.

> + description = "FPGA peripheral bitstream";
> + data = /incbin/("../../../ghrd_10as066n2.periph.rbf");
> + type = "fpga";
> + arch = "arm";
> + compression = "none";
> + };
> +
> + fpga-core@2 {

ditto.

> + description = "FPGA core bitstream";
> + data = /incbin/("../../../ghrd_10as066n2.core.rbf");
> + type = "fpga";
> + arch = "arm";
> + compression = "none";
> + };
> + };
> +
> + configurations {
> + default = "config-1";
> + config-1 {
> + description = "Boot with FPGA early IO release config";
> + fpga = "fpga-periph@1", "fpga-core@2";
> + };
> + };
> +};
> 

M

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




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

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

[Michal Simek]

On 19. 02. 19 4:47, 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 
> 
> ---
> 
> changes for v8
> - Removed explanation about support for altr,bitstream-core
> 
> changes for v7
> - Provided example of setting FPGA FIT image for both early IO release
>   and full release FPGA configuration.
> ---
>  .../fpga/altera-socfpga-a10-fpga-mgr.txt   | 26 
> +-
>  1 file changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt 
> b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt
> index 2fd8e7a..da210bf 100644
> --- a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt
> +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt
> @@ -7,8 +7,31 @@ Required properties:
> - The second index is for writing FPGA configuration data.
>  - resets : Phandle and reset specifier for the device's reset.
>  - clocks : Clocks used by the device.
> +- altr,bitstream : Fit image file name for both FPGA peripheral bitstream,
> +FPGA core bitstream and full bitstream.
>  

By adding new required property you are automatically saying that you
want to break all current users.

M


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




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

Re: [U-Boot] [PATCH 2/2] mx6sabreauto: README: Adjust the binary name after DM conversion

[Peng Fan]

> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2019年2月26日 20:36
> To: sba...@denx.de
> Cc: dl-uboot-imx ; Peng Fan ;
> Abel Vesa ; u-boot@lists.denx.de; Fabio Estevam
> 
> Subject: [PATCH 2/2] mx6sabreauto: README: Adjust the binary name after
> DM conversion
> 
> After the conversion to DM the U-Boot binary is called u-boot-dtb.imx, so fix
> the README file accordingly.
> 
> Signed-off-by: Fabio Estevam 

Acked-by: Peng Fan 

> ---
>  board/freescale/mx6sabreauto/README | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/board/freescale/mx6sabreauto/README
> b/board/freescale/mx6sabreauto/README
> index e8c589b92a..4c0fda1a2d 100644
> --- a/board/freescale/mx6sabreauto/README
> +++ b/board/freescale/mx6sabreauto/README
> @@ -9,15 +9,15 @@ $ make mx6sabreauto_defconfig
> 
>  $ make
> 
> -This will generate the SPL and u-boot.img binaries.
> +This will generate the SPL and u-boot-dtb.img binaries.
> 
>  - Flash the SPL binary into the SD card:
> 
>  $ sudo dd if=SPL of=/dev/sdX bs=1K seek=1 && sync
> 
> -- Flash the u-boot.img binary into the SD card:
> +- Flash the u-boot-dtb.img binary into the SD card:
> 
> -$ sudo dd if=u-boot.img of=/dev/sdX bs=1K seek=69 && sync
> +$ sudo dd if=u-boot-dtb.img of=/dev/sdX bs=1K seek=69 && sync
> 
>  Booting via Falcon mode
>  ---
> @@ -32,15 +32,15 @@ $ make mx6sabreauto_defconfig
> 
>  $ make
> 
> -This will generate the SPL image called SPL and the u-boot.img.
> +This will generate the SPL image called SPL and the u-boot-dtb.img.
> 
>  - Flash the SPL image into the SD card:
> 
>  $ sudo dd if=SPL of=/dev/sdb bs=1K seek=1 && sync
> 
> -- Flash the u-boot.img image into the SD card:
> +- Flash the u-boot-dtb.img image into the SD card:
> 
> -$ sudo dd if=u-boot.img of=/dev/sdb bs=1K seek=69 && sync
> +$ sudo dd if=u-boot-dtb.img of=/dev/sdb bs=1K seek=69 && sync
> 
>  Create a FAT16 boot partition to store uImage and the dtb file, then copy the
> files there:
> 
> --
> 2.17.1

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

Re: [U-Boot] [PATCH 1/2] mx6sabresd: README: Adjust the binary name after DM conversion

[Peng Fan]

> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2019年2月26日 20:36
> To: sba...@denx.de
> Cc: dl-uboot-imx ; Peng Fan ;
> Abel Vesa ; u-boot@lists.denx.de; Fabio Estevam
> 
> Subject: [PATCH 1/2] mx6sabresd: README: Adjust the binary name after DM
> conversion
> 
> After the conversion to DM the U-Boot binary is called u-boot-dtb.imx, so fix
> the README file accordingly.
> 
> Signed-off-by: Fabio Estevam 

Acked-by: Peng Fan 

> ---
>  board/freescale/mx6sabresd/README | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/board/freescale/mx6sabresd/README
> b/board/freescale/mx6sabresd/README
> index 4b4df06330..4ea4454b9f 100644
> --- a/board/freescale/mx6sabresd/README
> +++ b/board/freescale/mx6sabresd/README
> @@ -21,15 +21,15 @@ $ make mx6sabresd_defconfig
> 
>  $ make
> 
> -This will generate the SPL and u-boot.img binaries.
> +This will generate the SPL and u-boot-dtb.img binaries.
> 
>  - Flash the SPL binary into the SD card:
> 
>  $ sudo dd if=SPL of=/dev/sdX bs=1K seek=1 && sync
> 
> -- Flash the u-boot.img binary into the SD card:
> +- Flash the u-boot-dtb.img binary into the SD card:
> 
> -$ sudo dd if=u-boot.img of=/dev/sdX bs=1K seek=69 && sync
> +$ sudo dd if=u-boot-dtb.img of=/dev/sdX bs=1K seek=69 && sync
> 
> 
>  2. Booting from eMMC
> @@ -39,7 +39,7 @@ $ make mx6sabresd_defconfig
> 
>  $ make
> 
> -This will generate the SPL and u-boot.img binaries.
> +This will generate the SPL and u-boot-dtb.img binaries.
> 
>  - Boot first from SD card as shown in the previous section
> 
> @@ -51,10 +51,10 @@ Mount the eMMC in the host PC:
> 
>  => ums 0 mmc 2
> 
> -- Flash SPL and u-boot.img binaries into the eMMC:
> +- Flash SPL and u-boot-dtb.img binaries into the eMMC:
> 
>  $ sudo dd if=SPL of=/dev/sdX bs=1K seek=1 && sync -$ sudo dd
> if=u-boot.img of=/dev/sdX bs=1K seek=69 && sync
> +$ sudo dd if=u-boot-dtb.img of=/dev/sdX bs=1K seek=69 && sync
> 
>  Set SW6 to eMMC 8-bit boot: 11010110
> 
> @@ -65,15 +65,15 @@ Set SW6 to eMMC 8-bit boot: 11010110  $ make
> mx6sabresd_defconfig  $ make
> 
> -This will generate the SPL image called SPL and the u-boot.img.
> +This will generate the SPL image called SPL and the u-boot-dtb.img.
> 
>  - Flash the SPL image into the SD card:
> 
>  $ sudo dd if=SPL of=/dev/sdX bs=1K seek=1 oflag=sync status=none && sync
> 
> -- Flash the u-boot.img image into the SD card:
> +- Flash the u-boot-dtb.img image into the SD card:
> 
> -$ sudo dd if=u-boot.img of=/dev/sdX bs=1K seek=69 oflag=sync status=none
> && sync
> +$ sudo dd if=u-boot-dtb.img of=/dev/sdX bs=1K seek=69 oflag=sync
> +status=none && sync
> 
>  Create a partition for root file system and extract it there:
> 
> --
> 2.17.1

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

Re: [U-Boot] [PATCH] misc: fs_loader: Replace label with DT phandle

[Chee, Tien Fong]

On Fri, 2019-02-15 at 14:35 +0800, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 
> 
> In previously label which will be expanded to the node's full path
> was
> used, and now replacing label with most commonly used DT phandle. The
> codes were changed accordingly to the use of DT phandle and
> supporting
> multiple instances.
> 
> Signed-off-by: Tien Fong Chee 
> ---
>  doc/driver-model/fs_firmware_loader.txt |   58
> +--
>  drivers/misc/fs_loader.c|   36 ---
>  2 files changed, 62 insertions(+), 32 deletions(-)
> 
> diff --git a/doc/driver-model/fs_firmware_loader.txt b/doc/driver-
> model/fs_firmware_loader.txt
> index b9aee84..d9f966e 100644
> --- a/doc/driver-model/fs_firmware_loader.txt
> +++ b/doc/driver-model/fs_firmware_loader.txt
Any comment?

> @@ -1,4 +1,4 @@
> -# Copyright (C) 2018 Intel Corporation 
> +# Copyright (C) 2018-2019 Intel Corporation 
>  #
>  # SPDX-License-Identifier:GPL-2.0
>  
> @@ -46,15 +46,48 @@ Firmware storage device described in device tree
> source
>   ubivol = "ubi0";
>   };
>  
> - Then, firmware_loader property would be set with the path of
> fs_loader
> - node under /chosen node such as:
> + Then, firmware-loader property can be added with any device
> node, which
> + driver would use the firmware loader for loading.
> +
> + The value of the firmware-loader property should be set with
> phandle
> + of the fs-loader node.
> + For example:
> + firmware-loader = <_loader0>;
> +
> + If there are majority of devices using the same fs-loader
> node, then
> + firmware-loader property can be added under /chosen node
> instead of
> + adding to each of device node.
> +
> + For example:
>   /{
>   chosen {
> - firmware_loader = _loader0;
> + firmware-loader = <_loader0>;
>   };
>   };
>  
> - However, this driver is also designed to support U-boot
> environment
> + In each respective driver of devices using firmware loader,
> the firmware
> + loaded instance should be created by DT phandle.
> +
> + For example of getting DT phandle from /chosen and creating
> instance:
> + chosen_node = ofnode_path("/chosen");
> + if (!ofnode_valid(chosen_node)) {
> + debug("/chosen node was not found.\n");
> + return -ENOENT;
> + }
> +
> + phandle_p = ofnode_get_property(chosen_node, "firmware-
> loader", );
> + if (!phandle_p) {
> + debug("firmware-loader property was not found.\n");
> + return -ENOENT;
> + }
> +
> + phandle = fdt32_to_cpu(*phandle_p);
> + ret =
> uclass_get_device_by_phandle_id(UCLASS_FS_FIRMWARE_LOADER,
> +  phandle, );
> + if (ret)
> + return ret;
> +
> + Firmware loader driver is also designed to support U-boot
> environment
>   variables, so all these data from FDT can be overwritten
>   through the U-boot environment variable during run time.
>   For examples:
> @@ -104,9 +137,12 @@ return:
>  Description:
>   The firmware is loaded directly into the buffer pointed to
> by buf
>  
> -Example of creating firmware loader instance and calling
> -request_firmware_into_buf API:
> - if (uclass_get_device(UCLASS_FS_FIRMWARE_LOADER, 0, )) {
> - request_firmware_into_buf(dev, filename,
> buffer_location,
> -  buffer_size,
> offset_ofreading);
> - }
> +Example of calling request_firmware_into_buf API after creating
> firmware loader
> +instance:
> + ret =
> uclass_get_device_by_phandle_id(UCLASS_FS_FIRMWARE_LOADER,
> +  phandle, );
> + if (ret)
> + return ret;
> +
> + request_firmware_into_buf(dev, filename, buffer_location,
> buffer_size,
> +  offset_ofreading);
> diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
> index a2e3763..f42eeff 100644
> --- a/drivers/misc/fs_loader.c
> +++ b/drivers/misc/fs_loader.c
> @@ -1,6 +1,6 @@
>  // SPDX-License-Identifier: GPL-2.0
>   /*
> - * Copyright (C) 2018 Intel Corporation 
> + * Copyright (C) 2018-2019 Intel Corporation 
>   *
>   */
>  #include 
> @@ -219,32 +219,26 @@ int request_firmware_into_buf(struct udevice
> *dev,
>  
>  static int fs_loader_ofdata_to_platdata(struct udevice *dev)
>  {
> - const char *fs_loader_path;
>   u32 phandlepart[2];
>  
> - fs_loader_path = ofnode_get_chosen_prop("firmware-loader");
> + ofnode fs_loader_node = dev_ofnode(dev);
>  
> - if (fs_loader_path) {
> - ofnode fs_loader_node;
> + if (ofnode_valid(fs_loader_node)) {
> + struct device_platdata *plat;
>  
> - fs_loader_node = ofnode_path(fs_loader_path);
> - if (ofnode_valid(fs_loader_node)) {
> - struct 

[U-Boot] [PATCH 2/2] mx6sabreauto: README: Adjust the binary name after DM conversion

[Fabio Estevam]

After the conversion to DM the U-Boot binary is called u-boot-dtb.imx,
so fix the README file accordingly.

Signed-off-by: Fabio Estevam 
---
 board/freescale/mx6sabreauto/README | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/board/freescale/mx6sabreauto/README 
b/board/freescale/mx6sabreauto/README
index e8c589b92a..4c0fda1a2d 100644
--- a/board/freescale/mx6sabreauto/README
+++ b/board/freescale/mx6sabreauto/README
@@ -9,15 +9,15 @@ $ make mx6sabreauto_defconfig
 
 $ make
 
-This will generate the SPL and u-boot.img binaries.
+This will generate the SPL and u-boot-dtb.img binaries.
 
 - Flash the SPL binary into the SD card:
 
 $ sudo dd if=SPL of=/dev/sdX bs=1K seek=1 && sync
 
-- Flash the u-boot.img binary into the SD card:
+- Flash the u-boot-dtb.img binary into the SD card:
 
-$ sudo dd if=u-boot.img of=/dev/sdX bs=1K seek=69 && sync
+$ sudo dd if=u-boot-dtb.img of=/dev/sdX bs=1K seek=69 && sync
 
 Booting via Falcon mode
 ---
@@ -32,15 +32,15 @@ $ make mx6sabreauto_defconfig
 
 $ make
 
-This will generate the SPL image called SPL and the u-boot.img.
+This will generate the SPL image called SPL and the u-boot-dtb.img.
 
 - Flash the SPL image into the SD card:
 
 $ sudo dd if=SPL of=/dev/sdb bs=1K seek=1 && sync
 
-- Flash the u-boot.img image into the SD card:
+- Flash the u-boot-dtb.img image into the SD card:
 
-$ sudo dd if=u-boot.img of=/dev/sdb bs=1K seek=69 && sync
+$ sudo dd if=u-boot-dtb.img of=/dev/sdb bs=1K seek=69 && sync
 
 Create a FAT16 boot partition to store uImage and the dtb file, then copy the 
files there:
 
-- 
2.17.1

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

[U-Boot] [PATCH 1/2] mx6sabresd: README: Adjust the binary name after DM conversion

[Fabio Estevam]

After the conversion to DM the U-Boot binary is called u-boot-dtb.imx,
so fix the README file accordingly.

Signed-off-by: Fabio Estevam 
---
 board/freescale/mx6sabresd/README | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/board/freescale/mx6sabresd/README 
b/board/freescale/mx6sabresd/README
index 4b4df06330..4ea4454b9f 100644
--- a/board/freescale/mx6sabresd/README
+++ b/board/freescale/mx6sabresd/README
@@ -21,15 +21,15 @@ $ make mx6sabresd_defconfig
 
 $ make
 
-This will generate the SPL and u-boot.img binaries.
+This will generate the SPL and u-boot-dtb.img binaries.
 
 - Flash the SPL binary into the SD card:
 
 $ sudo dd if=SPL of=/dev/sdX bs=1K seek=1 && sync
 
-- Flash the u-boot.img binary into the SD card:
+- Flash the u-boot-dtb.img binary into the SD card:
 
-$ sudo dd if=u-boot.img of=/dev/sdX bs=1K seek=69 && sync
+$ sudo dd if=u-boot-dtb.img of=/dev/sdX bs=1K seek=69 && sync
 
 
 2. Booting from eMMC
@@ -39,7 +39,7 @@ $ make mx6sabresd_defconfig
 
 $ make
 
-This will generate the SPL and u-boot.img binaries.
+This will generate the SPL and u-boot-dtb.img binaries.
 
 - Boot first from SD card as shown in the previous section
 
@@ -51,10 +51,10 @@ Mount the eMMC in the host PC:
 
 => ums 0 mmc 2
 
-- Flash SPL and u-boot.img binaries into the eMMC:
+- Flash SPL and u-boot-dtb.img binaries into the eMMC:
 
 $ sudo dd if=SPL of=/dev/sdX bs=1K seek=1 && sync
-$ sudo dd if=u-boot.img of=/dev/sdX bs=1K seek=69 && sync
+$ sudo dd if=u-boot-dtb.img of=/dev/sdX bs=1K seek=69 && sync
 
 Set SW6 to eMMC 8-bit boot: 11010110
 
@@ -65,15 +65,15 @@ Set SW6 to eMMC 8-bit boot: 11010110
 $ make mx6sabresd_defconfig
 $ make
 
-This will generate the SPL image called SPL and the u-boot.img.
+This will generate the SPL image called SPL and the u-boot-dtb.img.
 
 - Flash the SPL image into the SD card:
 
 $ sudo dd if=SPL of=/dev/sdX bs=1K seek=1 oflag=sync status=none && sync
 
-- Flash the u-boot.img image into the SD card:
+- Flash the u-boot-dtb.img image into the SD card:
 
-$ sudo dd if=u-boot.img of=/dev/sdX bs=1K seek=69 oflag=sync status=none && 
sync
+$ sudo dd if=u-boot-dtb.img of=/dev/sdX bs=1K seek=69 oflag=sync status=none 
&& sync
 
 Create a partition for root file system and extract it there:
 
-- 
2.17.1

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

Re: [U-Boot] [PATCH v9 0/7] Add support for loading FPGA bitstream

[Chee, Tien Fong]

On Tue, 2019-02-19 at 11:47 +0800, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 
> 
> This version mainly resolved comments from Marek in [v8].
> 
> This series is working on top of u-boot.git -  http://git.denx.de/u-b
> oot.git .
> 
> These patches are required before applying this series of patches
> 1. [U-Boot,v4] misc: fs_loader: Add support for initializing block
> device
> https://patchwork.ozlabs.org/project/uboot/list/?series=89282 (done
> review)
> 
> 2 a. [U-Boot,v3,1/2] fs: fat: dynamically allocate memory for
> temporary buffer
>   b. [U-Boot,v3,2/2] fs: fat: Reduce default max clustersize 64KiB
> from malloc
>  pool
> https://patchwork.ozlabs.org/project/uboot/list/?series=91135 (under
> review)
> 
> 3. [U-Boot] misc: fs_loader: Replace label with DT phandle
> https://patchwork.ozlabs.org/project/uboot/list/?series=92167 (under
> review)
> 
> [v8]: https://www.mail-archive.com/u-boot@lists.denx.de/msg316086.htm
> l
> [v7]: https://www.mail-archive.com/u-boot@lists.denx.de/msg314511.htm
> l
> 
> 
> Tien Fong Chee (7):
>   ARM: socfpga: Description on FPGA bitstream type and file name for
> Arria 10
>   ARM: socfpga: Add default FPGA bitstream fitImage for Arria10 SoCDK
>   ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading
>   ARM: socfpga: Add the configuration for FPGA SoCFPGA A10 SoCDK
>   spl : socfpga: Implement fpga bitstream loading with socfpga loadfs
>   ARM: socfpga: Synchronize the configuration for A10 SoCDK
>   ARM: socfpga: Increase Malloc pool size to support FAT filesystem
> in
> SPL
> 
>  arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts   |  17 +
>  .../include/mach/fpga_manager_arria10.h|  40 +-
>  arch/arm/mach-socfpga/spl_a10.c|  31 +-
>  board/altera/arria10-socdk/fit_spl_fpga.its|  38 ++
>  configs/socfpga_arria10_defconfig  |  21 +-
>  .../fpga/altera-socfpga-a10-fpga-mgr.txt   |  26 +-
>  drivers/fpga/socfpga_arria10.c | 533
> -
>  include/configs/socfpga_common.h   |   4 +-
>  include/image.h|   4 +
>  9 files changed, 682 insertions(+), 32 deletions(-)
>  create mode 100644 board/altera/arria10-socdk/fit_spl_fpga.its
> 
Any comment?

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

[U-Boot] [PATCH] net: phy: Reloc next and prev pointers inside phy_drivers

[Michal Simek]

From: Siva Durga Prasad Paladugu 

This patch relocates the pointers inside phy_drivers incase
of manual reloc. Without this reloc, these points to invalid
pre relocation address and hence causes exception or hang.

Signed-off-by: Siva Durga Prasad Paladugu 
Signed-off-by: Michal Simek 
---

 drivers/net/phy/phy.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index ed4000991165..e0a925152e8b 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -462,6 +462,18 @@ static LIST_HEAD(phy_drivers);
 
 int phy_init(void)
 {
+#ifdef CONFIG_NEEDS_MANUAL_RELOC
+   /*
+* The pointers inside phy_drivers also needs to be updated incase of
+* manual reloc, without which these points to some invalid
+* pre reloc address and leads to invalid accesses, hangs.
+*/
+   struct list_head *head = _drivers;
+
+   head->next = (void *)head->next + gd->reloc_off;
+   head->prev = (void *)head->prev + gd->reloc_off;
+#endif
+
 #ifdef CONFIG_B53_SWITCH
phy_b53_init();
 #endif
-- 
1.9.1

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

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

[Michal Simek]

From: Siva Durga Prasad Paladugu 

Don't ignore return value of phy_probe() call as
the probe may fail and it needs to be reported.

Signed-off-by: Siva Durga Prasad Paladugu 
Signed-off-by: Michal Simek 
---

 drivers/net/phy/phy.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 17cfcfe62a78..ed4000991165 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -658,7 +658,10 @@ static struct phy_device *phy_device_create(struct mii_dev 
*bus, int addr,
 
dev->drv = get_phy_driver(dev, interface);
 
-   phy_probe(dev);
+   if (phy_probe(dev)) {
+   printf("%s, PHY probe failed\n", __func__);
+   return NULL;
+   }
 
if (addr >= 0 && addr < PHY_MAX_ADDR)
bus->phymap[addr] = dev;
-- 
1.9.1

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

[U-Boot] [PATCH] efi_loader: Fix serial console size detection

[matthias . bgg]

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 
---
 lib/efi_loader/efi_console.c | 63 +---
 1 file changed, 37 insertions(+), 26 deletions(-)

diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index 66c33a551d..817220455f 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -62,6 +62,16 @@ static struct simple_text_output_mode efi_con_mode = {
.cursor_visible = 1,
 };
 
+static int term_get_char(char *c)
+{
+   if (tstc()) {
+   *c = getc();
+   return 0;
+   }
+
+   return 1;
+}
+
 /*
  * Receive and parse a reply from the terminal.
  *
@@ -74,32 +84,42 @@ static int term_read_reply(int *n, int num, char end_char)
 {
char c;
int i = 0;
+   u64 timeout;
 
-   c = getc();
-   if (c != cESC)
+   /* Allow up to one second for the response */
+   timeout = timer_get_us() + 100;
+   while (!tstc())
+   if (timer_get_us() > timeout)
+   return -1;
+
+   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 (timer_get_us() > timeout)
+   return -1;
}
if (i != num - 1)
return -1;
@@ -196,7 +216,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 +235,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;
-- 
2.20.1

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

[U-Boot] [PATCH] doc: binding: rename directory ram to memory-controller

[Patrick Delaunay]

Alignment with kernel directory name as it have already bindings for
DDR controllers in the directory:
Documentation/devicetree/bindings/memory-controller

PS: the drivers using RAM u-class should be associated with
this binding directory

Signed-off-by: Patrick Delaunay 
---

 doc/device-tree-bindings/{ram => memory-controllers}/k3-am654-ddrss.txt  | 0
 doc/device-tree-bindings/{ram => memory-controllers}/st,stm32-fmc.txt| 0
 doc/device-tree-bindings/{ram => memory-controllers}/st,stm32mp1-ddr.txt | 0
 3 files changed, 0 insertions(+), 0 deletions(-)
 rename doc/device-tree-bindings/{ram => memory-controllers}/k3-am654-ddrss.txt 
(100%)
 rename doc/device-tree-bindings/{ram => memory-controllers}/st,stm32-fmc.txt 
(100%)
 rename doc/device-tree-bindings/{ram => 
memory-controllers}/st,stm32mp1-ddr.txt (100%)

diff --git a/doc/device-tree-bindings/ram/k3-am654-ddrss.txt 
b/doc/device-tree-bindings/memory-controllers/k3-am654-ddrss.txt
similarity index 100%
rename from doc/device-tree-bindings/ram/k3-am654-ddrss.txt
rename to doc/device-tree-bindings/memory-controllers/k3-am654-ddrss.txt
diff --git a/doc/device-tree-bindings/ram/st,stm32-fmc.txt 
b/doc/device-tree-bindings/memory-controllers/st,stm32-fmc.txt
similarity index 100%
rename from doc/device-tree-bindings/ram/st,stm32-fmc.txt
rename to doc/device-tree-bindings/memory-controllers/st,stm32-fmc.txt
diff --git a/doc/device-tree-bindings/ram/st,stm32mp1-ddr.txt 
b/doc/device-tree-bindings/memory-controllers/st,stm32mp1-ddr.txt
similarity index 100%
rename from doc/device-tree-bindings/ram/st,stm32mp1-ddr.txt
rename to doc/device-tree-bindings/memory-controllers/st,stm32mp1-ddr.txt
-- 
2.7.4

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

Re: [U-Boot] SiFive FU540 U-Boot patches,

[Anup Patel]

On Mon, Feb 25, 2019 at 12:50 PM Rick Chen  wrote:
>
> Hi Anup
>
> Anup Patel  於 2019年2月25日 週一 上午11:28寫道：
> >
> > On Mon, Feb 25, 2019 at 7:50 AM Rick Chen  wrote:
> > >
> > > Hi Anup
> > >
> > > Rick Chen  於 2019年2月22日 週五 下午12:05寫道：
> > > >
> > > > Hi Anup
> > > >
> > > > Anup Patel  於 2019年2月21日 週四 下午5:57寫道：
> > > >
> > > > >
> > > > > On Thu, Feb 21, 2019 at 11:31 AM Bin Meng  wrote:
> > > > > >
> > > > > > On Thu, Feb 21, 2019 at 12:48 PM Anup Patel  
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi Rick,
> > > > > > >
> > > > > > > On Fri, Feb 15, 2019 at 10:19 AM Rick Chen  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Anup
> > > > > > > >
> > > > > > > > > > Hi All,
> > > > > > > > > >
> > > > > > > > > > Thanks for all the review comments so far.
> > > > > > > > > >
> > > > > > > > > > Is it possible to accept "[PATCH v7 00/15] SiFive FU540 
> > > > > > > > > > Support" for
> > > > > > > > > > U-Boot-2019.04 ??
> > > > > > > > > >
> > > > > > > > > > Based on our discussion with various folks at FOSDEM19, lot 
> > > > > > > > > > of people want to
> > > > > > > > > > use U-Boot on Unleashed board. In general, it will be 
> > > > > > > > > > exciting to see U-Boot being
> > > > > > > > > > adopted as bootloader by various RISC-V HW vendors.
> > > > > > > >
> > > > > > > > I am still waiting for Simon's response about the two patchs
> > > > > > > > that he have comments.
> > > > > > >
> > > > > > > I have addressed Simon's patches and got Reviewed-by as well.
> > > > > > >
> > > > > > > I have posted "[PATCH v9 00/15] SiFive FU540 Support" which
> > > > > > > is based on U-Boot-2019.4-rc2.
> > > > > > >
> > > > > > > You can also find this patches in riscv_sifive_fu540_v9 branch of
> > > > > > > https://github.com/avpatel/u-boot.git
> > > > > >
> > > > > > Thanks for the support and hopefully we can get this one plus 
> > > > > > Lukas's
> > > > > > SMP series in the v2019.04 release.
> > > > >
> > > > > It will be awesome to have Lukas's SMP patches along with
> > > > > SiFive FU540 patches in v2019.04
> > > > >
> > > >
> > > > OK
> > > > I will pull into u-boot-riscv and run Travis.
> > >
> > > Can you take a look this Travis fail item 12.44 as below
> > > https://travis-ci.org/rickchen36/u-boot-riscv/jobs/496911491
> >
> > Ahh, this issue got introduced when I removed "#if" (Suggested by Alex)
> > from clk_fixed_factor_ofdata_to_platdata() in v3 of this patchset.
> >
> > I suggest we bring back the "#if" by modifying PATCH9 with following
> > additional change:
> >
> > diff --git a/drivers/clk/clk_fixed_factor.c b/drivers/clk/clk_fixed_factor.c
> > index 9e00544889..5fa20a84db 100644
> > --- a/drivers/clk/clk_fixed_factor.c
> > +++ b/drivers/clk/clk_fixed_factor.c
> > @@ -42,6 +42,7 @@ const struct clk_ops clk_fixed_factor_ops = {
> >
> >  static int clk_fixed_factor_ofdata_to_platdata(struct udevice *dev)
> >  {
> > +#if !CONFIG_IS_ENABLED(OF_PLATDATA)
> > int err;
> > struct clk_fixed_factor *ff = to_clk_fixed_factor(dev);
> >
> > @@ -51,6 +52,7 @@ static int
> > clk_fixed_factor_ofdata_to_platdata(struct udevice *dev)
> >
> > ff->div = dev_read_u32_default(dev, "clock-div", 1);
> > ff->mult = dev_read_u32_default(dev, "clock-mult", 1);
> > +#endif
> >
> > return 0;
> >  }
> >
> > The above will resolve Travis build fail.
> >
>
> Will you send another patchset to solve this fail issue ?

Does the v10 patchset work for you?

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

[U-Boot] [PATCH v1 2/2] x86: acpi: Add DMA descriptors for I2C1 on Intel Tangier

[Andy Shevchenko]

Intel Tangier SoC has a general purpose DMA which can serve to speed up
communications on SPI and I2C serial buses.

Provide DMA descriptors to utilize this capability in the future.

Note, I2C6, which is available to user, has no DMA request lines connected.

Signed-off-by: Andy Shevchenko 
---
 .../include/asm/arch-tangier/acpi/southcluster.asl| 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl 
b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
index e4d876ab78..1f940511a1 100644
--- a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
+++ b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
@@ -232,6 +232,17 @@ Device (PCI0)
 {
 Return (STA_VISIBLE)
 }
+
+Name (RBUF, ResourceTemplate()
+{
+FixedDMA(0x0009, 0x, Width32bit, )
+FixedDMA(0x0008, 0x0001, Width32bit, )
+})
+
+Method (_CRS, 0, NotSerialized)
+{
+Return (RBUF)
+}
 }
 
 Device (I2C6)
-- 
2.20.1

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

[U-Boot] [PATCH v1 1/2] x86: acpi: Add DMA descriptors for SPI5 on Intel Tangier

[Andy Shevchenko]

Intel Tangier SoC has a general purpose DMA which can serve to speed up
communications on SPI and I2C serial buses.

Provide DMA descriptors to utilize this capability in the future.

Signed-off-by: Andy Shevchenko 
---
 arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl 
b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
index aad1bf0c87..e4d876ab78 100644
--- a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
+++ b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
@@ -189,6 +189,9 @@ Device (PCI0)
 "\\_SB.PCI0.GPIO", 0, ResourceConsumer, , ) { 112 }
 GpioIo(Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly,
 "\\_SB.PCI0.GPIO", 0, ResourceConsumer, , ) { 113 }
+
+FixedDMA(0x000d, 0x0002, Width32bit, )
+FixedDMA(0x000c, 0x0003, Width32bit, )
 })
 
 Method (_CRS, 0, NotSerialized)
-- 
2.20.1

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

[U-Boot] [PATCH] dm: check OF_LIVE is enabled

[Ibai Erkiaga]

Livetree implemented functions does not have conditional compilation so
check if CONFIG_IS_ENABLED prior using those functions.

The issue does not report any error in a normal build as the toolchain
optimize the code. Using -O0 triggers the error so the patch is intended
to fix issues on a ongoing effor to build U-Boot with -O0.

Signed-off-by: Ibai Erkiaga 
---

 drivers/core/ofnode.c  | 60 +-
 drivers/serial/serial-uclass.c |  2 +-
 2 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index 0e584c1..caa7fa5 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -20,7 +20,7 @@ int ofnode_read_u32(ofnode node, const char *propname, u32 
*outp)
assert(ofnode_valid(node));
debug("%s: %s: ", __func__, propname);
 
-   if (ofnode_is_np(node)) {
+   if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) {
return of_read_u32(ofnode_to_np(node), propname, outp);
} else {
const fdt32_t *cell;
@@ -63,7 +63,7 @@ int ofnode_read_u64(ofnode node, const char *propname, u64 
*outp)
assert(ofnode_valid(node));
debug("%s: %s: ", __func__, propname);
 
-   if (ofnode_is_np(node))
+   if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE))
return of_read_u64(ofnode_to_np(node), propname, outp);
 
cell = fdt_getprop(gd->fdt_blob, ofnode_to_offset(node), propname,
@@ -109,7 +109,7 @@ const char *ofnode_read_string(ofnode node, const char 
*propname)
assert(ofnode_valid(node));
debug("%s: %s: ", __func__, propname);
 
-   if (ofnode_is_np(node)) {
+   if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) {
struct property *prop = of_find_property(
ofnode_to_np(node), propname, NULL);
 
@@ -141,7 +141,7 @@ ofnode ofnode_find_subnode(ofnode node, const char 
*subnode_name)
assert(ofnode_valid(node));
debug("%s: %s: ", __func__, subnode_name);
 
-   if (ofnode_is_np(node)) {
+   if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) {
const struct device_node *np = ofnode_to_np(node);
 
for (np = np->child; np; np = np->sibling) {
@@ -166,7 +166,7 @@ int ofnode_read_u32_array(ofnode node, const char *propname,
assert(ofnode_valid(node));
debug("%s: %s: ", __func__, propname);
 
-   if (ofnode_is_np(node)) {
+   if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) {
return of_read_u32_array(ofnode_to_np(node), propname,
 out_values, sz);
} else {
@@ -179,7 +179,7 @@ int ofnode_read_u32_array(ofnode node, const char *propname,
 ofnode ofnode_first_subnode(ofnode node)
 {
assert(ofnode_valid(node));
-   if (ofnode_is_np(node))
+   if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE))
return np_to_ofnode(node.np->child);
 
return offset_to_ofnode(
@@ -189,7 +189,7 @@ ofnode ofnode_first_subnode(ofnode node)
 ofnode ofnode_next_subnode(ofnode node)
 {
assert(ofnode_valid(node));
-   if (ofnode_is_np(node))
+   if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE))
return np_to_ofnode(node.np->sibling);
 
return offset_to_ofnode(
@@ -201,7 +201,7 @@ ofnode ofnode_get_parent(ofnode node)
ofnode parent;
 
assert(ofnode_valid(node));
-   if (ofnode_is_np(node))
+   if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE))
parent = np_to_ofnode(of_get_parent(ofnode_to_np(node)));
else
parent.of_offset = fdt_parent_offset(gd->fdt_blob,
@@ -213,7 +213,7 @@ ofnode ofnode_get_parent(ofnode node)
 const char *ofnode_get_name(ofnode node)
 {
assert(ofnode_valid(node));
-   if (ofnode_is_np(node))
+   if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE))
return strrchr(node.np->full_name, '/') + 1;
 
return fdt_get_name(gd->fdt_blob, ofnode_to_offset(node), NULL);
@@ -223,7 +223,7 @@ ofnode ofnode_get_by_phandle(uint phandle)
 {
ofnode node;
 
-   if (of_live_active())
+   if (of_live_active() && CONFIG_IS_ENABLED(OF_LIVE))
node = np_to_ofnode(of_find_node_by_phandle(phandle));
else
node.of_offset = fdt_node_offset_by_phandle(gd->fdt_blob,
@@ -236,7 +236,7 @@ int ofnode_read_size(ofnode node, const char *propname)
 {
int len;
 
-   if (ofnode_is_np(node)) {
+   if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) {
struct property *prop = of_find_property(
ofnode_to_np(node), propname, NULL);
 
@@ -256,7 +256,7 @@ fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
int na, ns;
fdt_size_t size;
 
-   if (ofnode_is_np(node)) {
+   if (ofnode_is_np(node) && CONFIG_IS_ENABLED(OF_LIVE)) {
 

[U-Boot] [PATCH v1 2/2] x86: edison: Add the rest of UARTs present on board

[Andy Shevchenko]

Intel Edison has three UART ports, i.e.
 port 0 - Bluetooth
 port 1 - auxiliary, available for general purpose use
 port 2 - debugging, usually console output is here

Enable all of them for future use.

Signed-off-by: Andy Shevchenko 
---
 arch/x86/dts/edison.dts | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/x86/dts/edison.dts b/arch/x86/dts/edison.dts
index b59171cb50..8629f7bcf2 100644
--- a/arch/x86/dts/edison.dts
+++ b/arch/x86/dts/edison.dts
@@ -17,6 +17,8 @@
compatible = "intel,edison";
 
aliases {
+   serial0 = 
+   serial1 = 
serial2 = 
};
 
@@ -53,6 +55,22 @@
  0x0100 0x0 0x2000 0x2000 0 0xe000>;
};
 
+   serial0: serial@ff010180 {
+   compatible = "intel,mid-uart";
+   reg = <0xff010080 0x100>;
+   reg-shift = <0>;
+   clock-frequency = <29491200>;
+   current-speed = <115200>;
+   };
+
+   serial1: serial@ff010180 {
+   compatible = "intel,mid-uart";
+   reg = <0xff010100 0x100>;
+   reg-shift = <0>;
+   clock-frequency = <29491200>;
+   current-speed = <115200>;
+   };
+
serial2: serial@ff010180 {
compatible = "intel,mid-uart";
reg = <0xff010180 0x100>;
-- 
2.20.1

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

[U-Boot] [PATCH v1 1/2] x86: edison: Use proper number of serial interface

[Andy Shevchenko]

The console is actually serial #2. When we would like to enable other ports,
this would be not okay to mess up with the ordering.

Thus, fix the number of default console interface to be 2.

Signed-off-by: Andy Shevchenko 
---
 arch/x86/dts/edison.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/dts/edison.dts b/arch/x86/dts/edison.dts
index 0dd72407ea..b59171cb50 100644
--- a/arch/x86/dts/edison.dts
+++ b/arch/x86/dts/edison.dts
@@ -17,11 +17,11 @@
compatible = "intel,edison";
 
aliases {
-   serial0 = 
+   serial2 = 
};
 
chosen {
-   stdout-path = 
+   stdout-path = 
};
 
cpus {
@@ -53,7 +53,7 @@
  0x0100 0x0 0x2000 0x2000 0 0xe000>;
};
 
-   serial0: serial@ff010180 {
+   serial2: serial@ff010180 {
compatible = "intel,mid-uart";
reg = <0xff010180 0x100>;
reg-shift = <0>;
-- 
2.20.1

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

[U-Boot] [PATCH v2 3/3] armv8: fsl-layerscape: avoid DT fixup warning

[laurentiu . tudor]

From: Laurentiu Tudor 

sec_firmware reserves JR3 for it's own usage and deletes the JR3 node
from the device tree. This causes this warning to be issued when doing
the device tree fixup:

WARNING could not find node fsl,sec-v4.0-job-ring: FDT_ERR_NOTFOUND.

Fix it by excluding the device tree fixup for the JR reserved by
sec_firmware.

Signed-off-by: Laurentiu Tudor 
Reviewed-by: Horia Geanta 
Reviewed-by: Bharat Bhushan 
---
v2:
 - added Reviewed-by tags

 arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h 
b/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
index e7a8801262..f971af8d26 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct icid_id_table {
const char *compat;
@@ -98,7 +99,13 @@ void fdt_fixup_icid(void *blob);
CONFIG_SYS_FSL_SEC_ADDR)
 
 #define SET_SEC_JR_ICID_ENTRY(jr_num, streamid) \
-   SET_ICID_ENTRY("fsl,sec-v4.0-job-ring", streamid, \
+   SET_ICID_ENTRY( \
+   (CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT && \
+   (FSL_SEC_JR##jr_num##_OFFSET ==  \
+   SEC_JR3_OFFSET + CONFIG_SYS_FSL_SEC_OFFSET) \
+   ? NULL \
+   : "fsl,sec-v4.0-job-ring"), \
+   streamid, \
(((streamid) << 16) | (streamid)), \
offsetof(ccsr_sec_t, jrliodnr[jr_num].ls) + \
CONFIG_SYS_FSL_SEC_ADDR, \
-- 
2.17.1

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

[U-Boot] [PATCH v2 2/3] armv8: fsl-layerscape: fix SEC QI ICID setup

[laurentiu . tudor]

From: Laurentiu Tudor 

The SEC QI ICID setup in the QIIC_LS register is actually an offset
that is being added to the ICID coming from the qman portal. Setting
it with a non-zero value breaks SMMU setup as the resulting ICID is
not known. On top of that, the SEC QI ICID must match the qman portal
ICIDs in order to share the isolation context.

Signed-off-by: Laurentiu Tudor 
Reviewed-by: Horia Geanta 
Reviewed-by: Bharat Bhushan 
---
v2:
 - added Reviewed-by tags

 arch/arm/cpu/armv8/fsl-layerscape/ls1043_ids.c  | 2 +-
 arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c  | 2 +-
 arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h | 3 +--
 3 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1043_ids.c 
b/arch/arm/cpu/armv8/fsl-layerscape/ls1043_ids.c
index 0e8649427e..3bd993bebf 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/ls1043_ids.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1043_ids.c
@@ -43,7 +43,7 @@ struct icid_id_table icid_tbl[] = {
SET_DEBUG_ICID(FSL_DEBUG_STREAM_ID),
SET_QE_ICID(FSL_QE_STREAM_ID),
 #ifdef CONFIG_FSL_CAAM
-   SET_SEC_QI_ICID(FSL_DPAA1_STREAM_ID_START + 2),
+   SET_SEC_QI_ICID(FSL_DPAA1_STREAM_ID_END),
SET_SEC_JR_ICID_ENTRY(0, FSL_DPAA1_STREAM_ID_START + 3),
SET_SEC_JR_ICID_ENTRY(1, FSL_DPAA1_STREAM_ID_START + 4),
SET_SEC_JR_ICID_ENTRY(2, FSL_DPAA1_STREAM_ID_START + 5),
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c 
b/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
index 2da9adab5b..abd847b5be 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1046_ids.c
@@ -41,7 +41,7 @@ struct icid_id_table icid_tbl[] = {
SET_ETR_ICID(FSL_ETR_STREAM_ID),
SET_DEBUG_ICID(FSL_DEBUG_STREAM_ID),
 #ifdef CONFIG_FSL_CAAM
-   SET_SEC_QI_ICID(FSL_DPAA1_STREAM_ID_START + 2),
+   SET_SEC_QI_ICID(FSL_DPAA1_STREAM_ID_END),
SET_SEC_JR_ICID_ENTRY(0, FSL_DPAA1_STREAM_ID_START + 3),
SET_SEC_JR_ICID_ENTRY(1, FSL_DPAA1_STREAM_ID_START + 4),
SET_SEC_JR_ICID_ENTRY(2, FSL_DPAA1_STREAM_ID_START + 5),
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h 
b/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
index f375fe7115..e7a8801262 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/fsl_icid.h
@@ -93,8 +93,7 @@ void fdt_fixup_icid(void *blob);
 
 #define SET_SEC_QI_ICID(streamid) \
SET_ICID_ENTRY("fsl,sec-v4.0", streamid, \
-   (((streamid) << 16) | (streamid)), \
-   offsetof(ccsr_sec_t, qilcr_ls) + \
+   0, offsetof(ccsr_sec_t, qilcr_ls) + \
CONFIG_SYS_FSL_SEC_ADDR, \
CONFIG_SYS_FSL_SEC_ADDR)
 
-- 
2.17.1

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