[U-Boot] [Patch V3] Convert CONFIG_NAND_OMAP_GPMC et al to Kconfig

[Adam Ford]

This converts the following to Kconfig:
   CONFIG_NAND_OMAP_GPMC
   CONFIG_NAND_OMAP_GPMC_PREFETCH
   CONFIG_NAND_OMAP_ELM
   CONFIG_SYS_NAND_BUSWIDTH_16BIT
   CONFIG_SPL_NAND_AM33XX_BCH
   CONFIG_SPL_NAND_SIMPLE (ARCH_OMAP2PLUS only)

Signed-off-by: Adam Ford 

V3:
Remove selection from CMD_NAND

Changes since V1:
  Rebased on latest Master
  Fixed a few missing entries where some features lacked dependancies
---
 configs/am3517_crane_defconfig| 6 --
 configs/cm_t3517_defconfig| 1 +
 configs/cm_t35_defconfig  | 1 +
 configs/omap3_evm_defconfig   | 1 +
 configs/omap3_ha_defconfig| 6 --
 configs/tao3530_defconfig | 6 --
 configs/tricorder_defconfig   | 1 +
 include/configs/ti_omap3_common.h | 1 -
 8 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/configs/am3517_crane_defconfig b/configs/am3517_crane_defconfig
index 396aadd..e7d92b6 100644
--- a/configs/am3517_crane_defconfig
+++ b/configs/am3517_crane_defconfig
@@ -13,11 +13,11 @@ CONFIG_SYS_PROMPT="AM3517_CRANE # "
 # CONFIG_CMD_IMI is not set
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_NAND=y
-CONFIG_CMD_I2C=y
 CONFIG_CMD_USB=y
-# CONFIG_CMD_FPGA is not set
 # CONFIG_CMD_SETEXPR is not set
 # CONFIG_CMD_NET is not set
 CONFIG_CMD_DHCP=y
@@ -26,6 +26,8 @@ CONFIG_CMD_EXT2=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_JFFS2=y
 CONFIG_MMC_OMAP_HS=y
+CONFIG_NAND=y
+CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
 CONFIG_USB_STORAGE=y
diff --git a/configs/cm_t3517_defconfig b/configs/cm_t3517_defconfig
index d5550fe..66cdc19 100644
--- a/configs/cm_t3517_defconfig
+++ b/configs/cm_t3517_defconfig
@@ -37,6 +37,7 @@ CONFIG_LED_STATUS_STATE=2
 CONFIG_LED_STATUS_BOOT_ENABLE=y
 CONFIG_LED_STATUS_BOOT=0
 CONFIG_MMC_OMAP_HS=y
+CONFIG_NAND=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
 CONFIG_USB_MUSB_HOST=y
diff --git a/configs/cm_t35_defconfig b/configs/cm_t35_defconfig
index 16f1eab..21bf5c3 100644
--- a/configs/cm_t35_defconfig
+++ b/configs/cm_t35_defconfig
@@ -39,6 +39,7 @@ CONFIG_LED_STATUS_STATE=2
 CONFIG_LED_STATUS_BOOT_ENABLE=y
 CONFIG_LED_STATUS_BOOT=0
 CONFIG_MMC_OMAP_HS=y
+CONFIG_NAND=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/omap3_evm_defconfig b/configs/omap3_evm_defconfig
index 9bbc980..40a91dd 100644
--- a/configs/omap3_evm_defconfig
+++ b/configs/omap3_evm_defconfig
@@ -45,6 +45,7 @@ CONFIG_SPL_DM=y
 CONFIG_DM_GPIO=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_MTD=y
+CONFIG_NAND=y
 CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
diff --git a/configs/omap3_ha_defconfig b/configs/omap3_ha_defconfig
index f88c2e1..2884d5a 100644
--- a/configs/omap3_ha_defconfig
+++ b/configs/omap3_ha_defconfig
@@ -12,11 +12,11 @@ CONFIG_HUSH_PARSER=y
 # CONFIG_CMD_IMI is not set
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_NAND=y
-CONFIG_CMD_I2C=y
 CONFIG_CMD_USB=y
-# CONFIG_CMD_FPGA is not set
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_PING=y
@@ -25,6 +25,8 @@ CONFIG_CMD_EXT2=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_MTDPARTS=y
 CONFIG_MMC_OMAP_HS=y
+CONFIG_NAND=y
+CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/tao3530_defconfig b/configs/tao3530_defconfig
index e6c7e60..f8c9596 100644
--- a/configs/tao3530_defconfig
+++ b/configs/tao3530_defconfig
@@ -12,11 +12,11 @@ CONFIG_SYS_PROMPT="TAO-3530 # "
 # CONFIG_CMD_IMI is not set
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_NAND=y
-CONFIG_CMD_I2C=y
 CONFIG_CMD_USB=y
-# CONFIG_CMD_FPGA is not set
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_PING=y
@@ -25,6 +25,8 @@ CONFIG_CMD_EXT2=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_MTDPARTS=y
 CONFIG_MMC_OMAP_HS=y
+CONFIG_NAND=y
+CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/tricorder_defconfig b/configs/tricorder_defconfig
index de42b4d..ad07dbc 100644
--- a/configs/tricorder_defconfig
+++ b/configs/tricorder_defconfig
@@ -35,5 +35,6 @@ CONFIG_LED_STATUS_BIT2=4
 CONFIG_LED_STATUS_STATE2=2
 CONFIG_LED_STATUS_CMD=y
 CONFIG_MMC_OMAP_HS=y
+CONFIG_NAND=y
 CONFIG_SYS_NS16550=y
 CONFIG_OF_LIBFDT=y
diff --git a/include/configs/ti_omap3_common.h 
b/include/configs/ti_omap3_common.h
index 393d867..2373727 100644
--- a/include/configs/ti_omap3_common.h
+++ b/include/configs/ti_omap3_common.h
@@ -65,7 +65,6 @@
 (64 << 20))
 
 #ifdef CONFIG_NAND
-#define CONFIG_SPL_NAND_SIMPLE
 #define CONFIG_SYS_NAND_BASE   0x3000
 #endif
 
-- 
2.7.4

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

[U-Boot] [Patch V2] Convert CONFIG_NAND_OMAP_GPMC et al to Kconfig

[Adam Ford]

This converts the following to Kconfig:
   CONFIG_NAND_OMAP_GPMC
   CONFIG_NAND_OMAP_GPMC_PREFETCH
   CONFIG_NAND_OMAP_ELM
   CONFIG_SYS_NAND_BUSWIDTH_16BIT
   CONFIG_SPL_NAND_AM33XX_BCH
   CONFIG_SPL_NAND_SIMPLE (ARCH_OMAP2PLUS only)

Signed-off-by: Adam Ford 

Changes since V1:
  Rebased on latest Master
  Fixed a few missing entries where some features lacked dependancies
---
 cmd/Kconfig   | 1 +
 configs/am3517_crane_defconfig| 6 --
 configs/cm_t3517_defconfig| 1 +
 configs/cm_t35_defconfig  | 1 +
 configs/omap3_evm_defconfig   | 1 +
 configs/omap3_ha_defconfig| 6 --
 configs/tao3530_defconfig | 6 --
 configs/tricorder_defconfig   | 1 +
 include/configs/ti_omap3_common.h | 1 -
 9 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 183f932..1e218ed 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -751,6 +751,7 @@ config CMD_MMC
 config CMD_NAND
bool "nand"
default y if NAND_SUNXI
+   select NAND
help
  NAND support.
 
diff --git a/configs/am3517_crane_defconfig b/configs/am3517_crane_defconfig
index 396aadd..e7d92b6 100644
--- a/configs/am3517_crane_defconfig
+++ b/configs/am3517_crane_defconfig
@@ -13,11 +13,11 @@ CONFIG_SYS_PROMPT="AM3517_CRANE # "
 # CONFIG_CMD_IMI is not set
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_NAND=y
-CONFIG_CMD_I2C=y
 CONFIG_CMD_USB=y
-# CONFIG_CMD_FPGA is not set
 # CONFIG_CMD_SETEXPR is not set
 # CONFIG_CMD_NET is not set
 CONFIG_CMD_DHCP=y
@@ -26,6 +26,8 @@ CONFIG_CMD_EXT2=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_JFFS2=y
 CONFIG_MMC_OMAP_HS=y
+CONFIG_NAND=y
+CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
 CONFIG_USB_STORAGE=y
diff --git a/configs/cm_t3517_defconfig b/configs/cm_t3517_defconfig
index d5550fe..66cdc19 100644
--- a/configs/cm_t3517_defconfig
+++ b/configs/cm_t3517_defconfig
@@ -37,6 +37,7 @@ CONFIG_LED_STATUS_STATE=2
 CONFIG_LED_STATUS_BOOT_ENABLE=y
 CONFIG_LED_STATUS_BOOT=0
 CONFIG_MMC_OMAP_HS=y
+CONFIG_NAND=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
 CONFIG_USB_MUSB_HOST=y
diff --git a/configs/cm_t35_defconfig b/configs/cm_t35_defconfig
index 16f1eab..21bf5c3 100644
--- a/configs/cm_t35_defconfig
+++ b/configs/cm_t35_defconfig
@@ -39,6 +39,7 @@ CONFIG_LED_STATUS_STATE=2
 CONFIG_LED_STATUS_BOOT_ENABLE=y
 CONFIG_LED_STATUS_BOOT=0
 CONFIG_MMC_OMAP_HS=y
+CONFIG_NAND=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/omap3_evm_defconfig b/configs/omap3_evm_defconfig
index 9bbc980..40a91dd 100644
--- a/configs/omap3_evm_defconfig
+++ b/configs/omap3_evm_defconfig
@@ -45,6 +45,7 @@ CONFIG_SPL_DM=y
 CONFIG_DM_GPIO=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_MTD=y
+CONFIG_NAND=y
 CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
diff --git a/configs/omap3_ha_defconfig b/configs/omap3_ha_defconfig
index f88c2e1..2884d5a 100644
--- a/configs/omap3_ha_defconfig
+++ b/configs/omap3_ha_defconfig
@@ -12,11 +12,11 @@ CONFIG_HUSH_PARSER=y
 # CONFIG_CMD_IMI is not set
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_NAND=y
-CONFIG_CMD_I2C=y
 CONFIG_CMD_USB=y
-# CONFIG_CMD_FPGA is not set
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_PING=y
@@ -25,6 +25,8 @@ CONFIG_CMD_EXT2=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_MTDPARTS=y
 CONFIG_MMC_OMAP_HS=y
+CONFIG_NAND=y
+CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/tao3530_defconfig b/configs/tao3530_defconfig
index e6c7e60..f8c9596 100644
--- a/configs/tao3530_defconfig
+++ b/configs/tao3530_defconfig
@@ -12,11 +12,11 @@ CONFIG_SYS_PROMPT="TAO-3530 # "
 # CONFIG_CMD_IMI is not set
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_NAND=y
-CONFIG_CMD_I2C=y
 CONFIG_CMD_USB=y
-# CONFIG_CMD_FPGA is not set
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_PING=y
@@ -25,6 +25,8 @@ CONFIG_CMD_EXT2=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_MTDPARTS=y
 CONFIG_MMC_OMAP_HS=y
+CONFIG_NAND=y
+CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/tricorder_defconfig b/configs/tricorder_defconfig
index de42b4d..ad07dbc 100644
--- a/configs/tricorder_defconfig
+++ b/configs/tricorder_defconfig
@@ -35,5 +35,6 @@ CONFIG_LED_STATUS_BIT2=4
 CONFIG_LED_STATUS_STATE2=2
 CONFIG_LED_STATUS_CMD=y
 CONFIG_MMC_OMAP_HS=y
+CONFIG_NAND=y
 CONFIG_SYS_NS16550=y
 CONFIG_OF_LIBFDT=y
diff --git a/include/configs/ti_omap3_common.h 
b/include/configs/ti_omap3_common.h
index 393d867..2373727 100644
--- a/include/configs/ti_omap3_common.h
+++ b/include/configs/ti_omap3_common.h
@@ -65,7 +65,6 @@
 (64 << 20))
 
 #ifdef 

[U-Boot] [PATCH 2/2] arm: Exercise v7_arch_cp15_set_acr even without errata fixups

[Siarhei Siamashka]

By applying this patch, we are ensuring that the code paths
responsible for applying errata workarounds are also exercised
on CPU revisions, which actually don't need these workarounds.

Only CONFIG_ARM_ERRATA_621766, CONFIG_ARM_ERRATA_454179,
CONFIG_ARM_ERRATA_725233 and CONFIG_ARM_ERRATA_430973 are
covered by this patch (Cortex-A8).

This improves code coverage when testing U-Boot builds
on newer hardware. In particular, the problematic commit
00bbe96ebabb ("arm: omap: Unify get_device_type() function")
would break both BeageBoard and BeagleBoard XM rather than
just older BeagleBoard.

As an additional bonus, we need fewer instructins and the SPL
size is reduced.

Signed-off-by: Siarhei Siamashka 
---
 arch/arm/cpu/armv7/start.S | 32 
 1 file changed, 12 insertions(+), 20 deletions(-)

diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index f06fd28..1442675 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -232,55 +232,47 @@ skip_errata_801819:
 #endif
 
 #ifdef CONFIG_ARM_ERRATA_454179
+   mrc p15, 0, r0, c1, c0, 1   @ Read ACR
+
cmp r2, #0x21   @ Only on < r2p1
-   bge skip_errata_454179
+   orrlt   r0, r0, #(0x3 << 6) @ Set DBSM(BIT7) and IBE(BIT6) bits
 
-   mrc p15, 0, r0, c1, c0, 1   @ Read ACR
-   orr r0, r0, #(0x3 << 6) @ Set DBSM(BIT7) and IBE(BIT6) bits
push{r1-r5} @ Save the cpu info registers
bl  v7_arch_cp15_set_acr
pop {r1-r5} @ Restore the cpu info - fall through
-
-skip_errata_454179:
 #endif
 
 #ifdef CONFIG_ARM_ERRATA_430973
+   mrc p15, 0, r0, c1, c0, 1   @ Read ACR
+
cmp r2, #0x21   @ Only on < r2p1
-   bge skip_errata_430973
+   orrlt   r0, r0, #(0x1 << 6) @ Set IBE bit
 
-   mrc p15, 0, r0, c1, c0, 1   @ Read ACR
-   orr r0, r0, #(0x1 << 6) @ Set IBE bit
push{r1-r5} @ Save the cpu info registers
bl  v7_arch_cp15_set_acr
pop {r1-r5} @ Restore the cpu info - fall through
-
-skip_errata_430973:
 #endif
 
 #ifdef CONFIG_ARM_ERRATA_621766
+   mrc p15, 0, r0, c1, c0, 1   @ Read ACR
+
cmp r2, #0x21   @ Only on < r2p1
-   bge skip_errata_621766
+   orrlt   r0, r0, #(0x1 << 5) @ Set L1NEON bit
 
-   mrc p15, 0, r0, c1, c0, 1   @ Read ACR
-   orr r0, r0, #(0x1 << 5) @ Set L1NEON bit
push{r1-r5} @ Save the cpu info registers
bl  v7_arch_cp15_set_acr
pop {r1-r5} @ Restore the cpu info - fall through
-
-skip_errata_621766:
 #endif
 
 #ifdef CONFIG_ARM_ERRATA_725233
+   mrc p15, 1, r0, c9, c0, 2   @ Read L2ACR
+
cmp r2, #0x21   @ Only on < r2p1 (Cortex A8)
-   bge skip_errata_725233
+   orrlt   r0, r0, #(0x1 << 27)@ L2 PLD data forwarding disable
 
-   mrc p15, 1, r0, c9, c0, 2   @ Read L2ACR
-   orr r0, r0, #(0x1 << 27)@ L2 PLD data forwarding disable
push{r1-r5} @ Save the cpu info registers
bl  v7_arch_cp15_set_l2aux_ctrl
pop {r1-r5} @ Restore the cpu info - fall through
-
-skip_errata_725233:
 #endif
 
 #ifdef CONFIG_ARM_ERRATA_852421
-- 
2.7.3

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

[U-Boot] [PATCH 0/2] Fix get_device_type() problems

[Siarhei Siamashka]

The comit 00bbe96ebabb ("arm: omap: Unify get_device_type()
function") does not play nice with early errata workarounds
and needs some fixes. And because it does not bring any
practical improvements anyway (other than increasing the SPL
size and introducing more lines of code), it's best to revert
it for now.

The second patch in this series improves testing coverage
and should prevent similar regressions in the future.

Siarhei Siamashka (2):
  Revert "arm: omap: Unify get_device_type() function"
  arm: Exercise v7_arch_cp15_set_acr even without errata fixups

 arch/arm/cpu/armv7/start.S  | 32 
 arch/arm/include/asm/arch-am33xx/cpu.h  |  6 ++
 arch/arm/include/asm/arch-am33xx/omap.h |  3 ---
 arch/arm/include/asm/arch-omap3/omap.h  |  3 ---
 arch/arm/include/asm/arch-omap4/omap.h  |  1 +
 arch/arm/include/asm/arch-omap5/omap.h  |  1 +
 arch/arm/include/asm/omap_common.h  | 11 +--
 arch/arm/mach-omap2/Makefile|  1 -
 arch/arm/mach-omap2/am33xx/Makefile |  2 --
 arch/arm/mach-omap2/am33xx/board.c  |  3 ---
 arch/arm/mach-omap2/am33xx/hw_data.c| 19 ---
 arch/arm/mach-omap2/am33xx/prcm-regs.c  | 15 ---
 arch/arm/mach-omap2/am33xx/sys_info.c   | 10 ++
 arch/arm/mach-omap2/hwinit-common.c |  9 +
 arch/arm/mach-omap2/omap3/Makefile  |  2 --
 arch/arm/mach-omap2/omap3/board.c   |  7 ---
 arch/arm/mach-omap2/omap3/hw_data.c | 19 ---
 arch/arm/mach-omap2/omap3/prcm-regs.c   | 15 ---
 arch/arm/mach-omap2/omap3/sys_info.c|  9 -
 arch/arm/mach-omap2/sysinfo-common.c| 21 -
 board/ti/am335x/board.c |  1 -
 board/ti/am43xx/board.c |  1 -
 22 files changed, 48 insertions(+), 143 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/am33xx/hw_data.c
 delete mode 100644 arch/arm/mach-omap2/am33xx/prcm-regs.c
 delete mode 100644 arch/arm/mach-omap2/omap3/hw_data.c
 delete mode 100644 arch/arm/mach-omap2/omap3/prcm-regs.c
 delete mode 100644 arch/arm/mach-omap2/sysinfo-common.c

-- 
2.7.3

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

[U-Boot] [PATCH 1/2] Revert "arm: omap: Unify get_device_type() function"

[Siarhei Siamashka]

This reverts commit 00bbe96ebabbc83777cd8d6c6fd2791c5c8cf619.

There were two major problems with this patch:
 1. It made OMAP3530 devices non-bootable, as reported
and investigated by Derald D. Woods in
https://lists.denx.de/pipermail/u-boot/2017-August/302192.html
 2. The SPL code size increased really a lot.

SPL size for omap3_beagle_defconfig build with GCC 6:

== before reverting ==
   textdata bss dec hex filename
  497211505  203200  254426   3e1da spl/u-boot-spl

== after reverting ==
   textdata bss dec hex filename
  492331501  203200  253934   3dfee spl/u-boot-spl

Signed-off-by: Siarhei Siamashka 
Reported-by: Derald D. Woods 
---
 arch/arm/include/asm/arch-am33xx/cpu.h  |  6 ++
 arch/arm/include/asm/arch-am33xx/omap.h |  3 ---
 arch/arm/include/asm/arch-omap3/omap.h  |  3 ---
 arch/arm/include/asm/arch-omap4/omap.h  |  1 +
 arch/arm/include/asm/arch-omap5/omap.h  |  1 +
 arch/arm/include/asm/omap_common.h  | 11 +--
 arch/arm/mach-omap2/Makefile|  1 -
 arch/arm/mach-omap2/am33xx/Makefile |  2 --
 arch/arm/mach-omap2/am33xx/board.c  |  3 ---
 arch/arm/mach-omap2/am33xx/hw_data.c| 19 ---
 arch/arm/mach-omap2/am33xx/prcm-regs.c  | 15 ---
 arch/arm/mach-omap2/am33xx/sys_info.c   | 10 ++
 arch/arm/mach-omap2/hwinit-common.c |  9 +
 arch/arm/mach-omap2/omap3/Makefile  |  2 --
 arch/arm/mach-omap2/omap3/board.c   |  7 ---
 arch/arm/mach-omap2/omap3/hw_data.c | 19 ---
 arch/arm/mach-omap2/omap3/prcm-regs.c   | 15 ---
 arch/arm/mach-omap2/omap3/sys_info.c|  9 -
 arch/arm/mach-omap2/sysinfo-common.c| 21 -
 board/ti/am335x/board.c |  1 -
 board/ti/am43xx/board.c |  1 -
 21 files changed, 36 insertions(+), 123 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/am33xx/hw_data.c
 delete mode 100644 arch/arm/mach-omap2/am33xx/prcm-regs.c
 delete mode 100644 arch/arm/mach-omap2/omap3/hw_data.c
 delete mode 100644 arch/arm/mach-omap2/omap3/prcm-regs.c
 delete mode 100644 arch/arm/mach-omap2/sysinfo-common.c

diff --git a/arch/arm/include/asm/arch-am33xx/cpu.h 
b/arch/arm/include/asm/arch-am33xx/cpu.h
index e8d7d54..8cae291 100644
--- a/arch/arm/include/asm/arch-am33xx/cpu.h
+++ b/arch/arm/include/asm/arch-am33xx/cpu.h
@@ -36,6 +36,12 @@
 #define TCFG_RESET BIT(0)  /* software reset */
 #define TCFG_EMUFREE   BIT(1)  /* behaviour of tmr on debug */
 #define TCFG_IDLEMOD_SHIFT (2) /* power management */
+/* device type */
+#define DEVICE_MASK(BIT(8) | BIT(9) | BIT(10))
+#define TST_DEVICE 0x0
+#define EMU_DEVICE 0x1
+#define HS_DEVICE  0x2
+#define GP_DEVICE  0x3
 
 /* cpu-id for AM43XX AM33XX and TI81XX family */
 #define AM437X 0xB98C
diff --git a/arch/arm/include/asm/arch-am33xx/omap.h 
b/arch/arm/include/asm/arch-am33xx/omap.h
index d2c5df8..0dafb9e 100644
--- a/arch/arm/include/asm/arch-am33xx/omap.h
+++ b/arch/arm/include/asm/arch-am33xx/omap.h
@@ -41,9 +41,6 @@ struct omap_boot_parameters {
unsigned char boot_device;
unsigned char reset_reason;
 };
-
-#define DEVICE_TYPE_SHIFT  0x8
-#define DEVICE_TYPE_MASK   (0x7 << DEVICE_TYPE_SHIFT)
 #endif
 
 #endif
diff --git a/arch/arm/include/asm/arch-omap3/omap.h 
b/arch/arm/include/asm/arch-omap3/omap.h
index 8933f54..db763e4 100644
--- a/arch/arm/include/asm/arch-omap3/omap.h
+++ b/arch/arm/include/asm/arch-omap3/omap.h
@@ -91,9 +91,6 @@ struct s32ktimer {
unsigned int s32k_cr;   /* 0x10 */
 };
 
-#define DEVICE_TYPE_SHIFT  0x8
-#define DEVICE_TYPE_MASK   (0x7 << DEVICE_TYPE_SHIFT)
-
 #endif /* __ASSEMBLY__ */
 
 #ifndef __ASSEMBLY__
diff --git a/arch/arm/include/asm/arch-omap4/omap.h 
b/arch/arm/include/asm/arch-omap4/omap.h
index 1a3ff7d..b86a776 100644
--- a/arch/arm/include/asm/arch-omap4/omap.h
+++ b/arch/arm/include/asm/arch-omap4/omap.h
@@ -100,6 +100,7 @@ struct s32ktimer {
 
 #define DEVICE_TYPE_SHIFT (0x8)
 #define DEVICE_TYPE_MASK (0x7 << DEVICE_TYPE_SHIFT)
+#define DEVICE_GP 0x3
 
 #endif /* __ASSEMBLY__ */
 
diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
b/arch/arm/include/asm/arch-omap5/omap.h
index 2f005dd..8f31da1 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -127,6 +127,7 @@ struct s32ktimer {
 
 #define DEVICE_TYPE_SHIFT 0x6
 #define DEVICE_TYPE_MASK (0x7 << DEVICE_TYPE_SHIFT)
+#define DEVICE_GP 0x3
 
 /* Output impedance control */
 #define ds_120_ohm 0x0
diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index ef5c481..6aaa1ba 100644
--- a/arch/arm/include/asm/omap_common.h
+++ 

Re: [U-Boot] [PATCH v3 2/3] armv8: ls1088ardb: Add support for LS1088ARDB platform

[Prabhakar Kushwaha]

Hi Ashish,

> -Original Message-
> From: Ashish Kumar [mailto:ashish.ku...@nxp.com]
> Sent: Friday, August 11, 2017 12:54 PM
> To: u-boot@lists.denx.de
> Cc: York Sun ; Ashish Kumar ;
> Alison Wang ; Prabhakar Kushwaha
> ; Raghav Dogra ;
> Shaohui Xie 
> Subject: [PATCH v3 2/3] armv8: ls1088ardb: Add support for LS1088ARDB
> platform
> 
> LS1088A is an ARMv8 implementation. The LS1088ARDB is an evaluatoin
> platform that supports the LS1088A family SoCs. This patch add basic
> support of the platform.
> 
> Signed-off-by: Alison Wang 
> Signed-off-by: Prabhakar Kushwaha 
> Signed-off-by: Ashish Kumar 
> Signed-off-by: Raghav Dogra 
> Signed-off-by: Shaohui Xie 
> ---
> v2:
> Fix indentaion in commit msg
> Separate RDB and Si specific file
> 
> v3:
> 1.Re-based on top of
>   commit d529124fdcf941c34074fd1ce600f4b1b4a7dd07
>   Merge: f0ca30f 6a5691e
>   Author: Tom Rini 
>   Date:   Tue Aug 8 17:06:19 2017 -0400
> 
> Merge git://git.denx.de/u-boot-x86
> 
> 2.Incorporate review comments on v2
>   Remove EMU support
>   Remove RAW timings
>   Disable default enabled CONFIG_DISPLAY_BOARDINFO and enable
> LATE_CONFIG_DISPLAY_BOARDINFO
> 
> 3.Include PPA support
> 
>  arch/arm/Kconfig  |  12 ++
>  arch/arm/cpu/armv8/Kconfig|   1 +
>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig |   1 +
>  arch/arm/dts/Makefile |   3 +-
>  arch/arm/dts/fsl-ls1088a-rdb.dts  |  40 
>  board/freescale/ls1088a/Kconfig   |  15 ++
>  board/freescale/ls1088a/MAINTAINERS   |   9 +


Please add REAdME file in ls1088a providing details of board (default switch 
settings, boot method + xqsgmii riser card (its port vs DPMAC mapping)

--prabhakar

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

[U-Boot] [PATCH 1/5] ARM: uniphier: remove sLD3 SoC support

[Masahiro Yamada]

This SoC is too old.  It is difficult to maintain any longer.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/dts/Makefile  |   2 -
 arch/arm/dts/uniphier-sld3-ref.dts | 100 -
 arch/arm/dts/uniphier-sld3.dtsi| 458 -
 arch/arm/mach-uniphier/Kconfig |   4 -
 arch/arm/mach-uniphier/arm32/cache-uniphier.c  |   3 -
 arch/arm/mach-uniphier/arm32/debug_ll.S|  21 -
 arch/arm/mach-uniphier/arm32/lowlevel_init.S   |   5 +-
 arch/arm/mach-uniphier/arm32/psci.c|   1 -
 arch/arm/mach-uniphier/bcu/Makefile|   1 -
 arch/arm/mach-uniphier/bcu/bcu-sld3.c  |  39 --
 arch/arm/mach-uniphier/board_init.c|   9 -
 arch/arm/mach-uniphier/boards.c|  22 -
 arch/arm/mach-uniphier/boot-device/Makefile|   1 -
 .../mach-uniphier/boot-device/boot-device-sld3.c   |  84 
 arch/arm/mach-uniphier/boot-device/boot-device.c   |   9 -
 arch/arm/mach-uniphier/boot-device/boot-device.h   |   2 -
 arch/arm/mach-uniphier/clk/Makefile|  14 +-
 .../clk/{clk-dram-sld3.c => clk-dram-ld4.c}|   2 +-
 .../clk/{clk-early-sld3.c => clk-early-ld4.c}  |   2 +-
 arch/arm/mach-uniphier/clk/dpll-sld3.c |  13 -
 arch/arm/mach-uniphier/clk/pll-sld3.c  |  14 -
 arch/arm/mach-uniphier/cpu-info.c  |   4 -
 arch/arm/mach-uniphier/debug-uart/Makefile |   1 -
 .../arm/mach-uniphier/debug-uart/debug-uart-sld3.c |  31 --
 arch/arm/mach-uniphier/debug-uart/debug-uart.c |   5 -
 arch/arm/mach-uniphier/debug-uart/debug-uart.h |   1 -
 arch/arm/mach-uniphier/dram/Makefile   |   1 -
 arch/arm/mach-uniphier/dram/umc-sld3.c |   6 -
 arch/arm/mach-uniphier/dram_init.c |   9 -
 arch/arm/mach-uniphier/init.h  |  10 +-
 arch/arm/mach-uniphier/memconf.c   |  14 +-
 arch/arm/mach-uniphier/mmc-boot-mode.c |   2 +-
 arch/arm/mach-uniphier/sc-regs.h   |   4 -
 arch/arm/mach-uniphier/soc-info.h  |   1 -
 arch/arm/mach-uniphier/spl_board_init.c|  29 +-
 configs/uniphier_sld3_defconfig|  46 ---
 doc/README.uniphier|   1 -
 drivers/clk/uniphier/clk-uniphier-core.c   |   4 -
 drivers/clk/uniphier/clk-uniphier-mio.c|   2 -
 drivers/pinctrl/uniphier/Kconfig   |   6 -
 drivers/pinctrl/uniphier/Makefile  |   1 -
 drivers/pinctrl/uniphier/pinctrl-uniphier-sld3.c   | 129 --
 drivers/reset/reset-uniphier.c |  14 +-
 include/configs/uniphier.h |   8 +-
 44 files changed, 30 insertions(+), 1105 deletions(-)
 delete mode 100644 arch/arm/dts/uniphier-sld3-ref.dts
 delete mode 100644 arch/arm/dts/uniphier-sld3.dtsi
 delete mode 100644 arch/arm/mach-uniphier/bcu/bcu-sld3.c
 delete mode 100644 arch/arm/mach-uniphier/boot-device/boot-device-sld3.c
 rename arch/arm/mach-uniphier/clk/{clk-dram-sld3.c => clk-dram-ld4.c} (93%)
 rename arch/arm/mach-uniphier/clk/{clk-early-sld3.c => clk-early-ld4.c} (93%)
 delete mode 100644 arch/arm/mach-uniphier/clk/dpll-sld3.c
 delete mode 100644 arch/arm/mach-uniphier/clk/pll-sld3.c
 delete mode 100644 arch/arm/mach-uniphier/debug-uart/debug-uart-sld3.c
 delete mode 100644 arch/arm/mach-uniphier/dram/umc-sld3.c
 delete mode 100644 configs/uniphier_sld3_defconfig
 delete mode 100644 drivers/pinctrl/uniphier/pinctrl-uniphier-sld3.c

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index c2dc240edf68..8f6b186df828 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -118,8 +118,6 @@ dtb-$(CONFIG_ARCH_UNIPHIER_PXS2) += \
uniphier-pxs2-vodka.dtb
 dtb-$(CONFIG_ARCH_UNIPHIER_PXS3) += \
uniphier-pxs3-ref.dtb
-dtb-$(CONFIG_ARCH_UNIPHIER_SLD3) += \
-   uniphier-sld3-ref.dtb
 dtb-$(CONFIG_ARCH_UNIPHIER_SLD8) += \
uniphier-sld8-ref.dtb
 
diff --git a/arch/arm/dts/uniphier-sld3-ref.dts 
b/arch/arm/dts/uniphier-sld3-ref.dts
deleted file mode 100644
index baf706976aca..
--- a/arch/arm/dts/uniphier-sld3-ref.dts
+++ /dev/null
@@ -1,100 +0,0 @@
-/*
- * Device Tree Source for UniPhier sLD3 Reference Board
- *
- * Copyright (C) 2015-2016 Socionext Inc.
- *   Author: Masahiro Yamada 
- *
- * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
- */
-
-/dts-v1/;
-/include/ "uniphier-sld3.dtsi"
-/include/ "uniphier-ref-daughter.dtsi"
-/include/ "uniphier-support-card.dtsi"
-
-/ {
-   model = "UniPhier sLD3 Reference Board";
-   compatible = "socionext,uniphier-sld3-ref", "socionext,uniphier-sld3";
-
-   chosen {
-   stdout-path = "serial0:115200n8";
-   };
-
-   aliases {
-   serial0 = 
-   serial1 = 
-   serial2 = 
-   i2c0 = 

[U-Boot] [PATCH 3/5] Revert "ARM: uniphier: fix ROM boot mode for PH1-sLD3"

[Masahiro Yamada]

This reverts commit 82d075e79fa509ffb8ecd8dd2dc216929d6e8289.

Commit 82d075e79fa5 ("ARM: uniphier: fix ROM boot mode for PH1-sLD3")
was a workaround for sLD3.  Now the sLD3 SoC support has been removed.

Revert it to allow to simplify the init code.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/arm32/lowlevel_init.S | 5 -
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/mach-uniphier/arm32/lowlevel_init.S 
b/arch/arm/mach-uniphier/arm32/lowlevel_init.S
index 3c7c6502793c..a399a169a9da 100644
--- a/arch/arm/mach-uniphier/arm32/lowlevel_init.S
+++ b/arch/arm/mach-uniphier/arm32/lowlevel_init.S
@@ -98,11 +98,6 @@ ENDPROC(enable_mmu)
 
 ENTRY(setup_init_ram)
ldr r1, = SSCO_BASE
-   mrc p15, 0, r0, c2, c0, 0   @ TTBR0
-   ldr r0, [r0, #0x400]@ entry for virtual address 0x100*
-   bfc r0, #0, #20
-   cmp r0, #0x5000 @ is sLD3 page table?
-   biceq   r1, r1, #0xc000 @ sLD3 ROM maps 0x5*** to 0x1***
 
/* Touch to zero for the boot way */
 0: ldr r0, = 0x00408006@ touch to zero with address range
-- 
2.7.4

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

[U-Boot] [PATCH 2/5] Revert "ARM: uniphier: move lowlevel debug init code after page table switch"

[Masahiro Yamada]

This reverts commit bcc51c1512a3deb6a9fdd37362c6dde32ad3da23.

Commit bcc51c1512a3 ("ARM: uniphier: move lowlevel debug init code
after page table switch") was intended to support lowlevel debug for
sLD3.  Now the sLD3 SoC support has been removed.

Revert it to allow to enable lowlevel debug earlier.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/arm32/lowlevel_init.S | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-uniphier/arm32/lowlevel_init.S 
b/arch/arm/mach-uniphier/arm32/lowlevel_init.S
index 89bb5a6355fd..3c7c6502793c 100644
--- a/arch/arm/mach-uniphier/arm32/lowlevel_init.S
+++ b/arch/arm/mach-uniphier/arm32/lowlevel_init.S
@@ -25,6 +25,10 @@ ENTRY(lowlevel_init)
orr r0, r0, #(CR_C | CR_M)  @ enable MMU and Dcache
mcr p15, 0, r0, c1, c0, 0
 
+#ifdef CONFIG_DEBUG_LL
+   bl  debug_ll_init
+#endif
+
bl  setup_init_ram  @ RAM area for stack and page table
 
/*
@@ -42,10 +46,6 @@ ENTRY(lowlevel_init)
 
bl  enable_mmu
 
-#ifdef CONFIG_DEBUG_LL
-   bl  debug_ll_init
-#endif
-
mov lr, r8  @ restore link
mov pc, lr  @ back to my caller
 ENDPROC(lowlevel_init)
-- 
2.7.4

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

[U-Boot] [PATCH 4/5] reset: uniphier: refactor reset data and add NAND/eMMC reset lines

[Masahiro Yamada]

  - Merge sys_reset data of LD4, Pro4, sLD8 and Pro5

  - Merge sys_reset data of LD11 and LD20

  - Use primitive UNIPHIER_RESETX() macro because bit assignments for
system reset will be changed for every SoC in the future

  - Add NAND and eMMC resets

Signed-off-by: Masahiro Yamada 
---

 drivers/reset/reset-uniphier.c | 63 --
 1 file changed, 17 insertions(+), 46 deletions(-)

diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
index df7fa267d13c..ebb2cae5eb33 100644
--- a/drivers/reset/reset-uniphier.c
+++ b/drivers/reset/reset-uniphier.c
@@ -41,46 +41,20 @@ struct uniphier_reset_data {
}
 
 /* System reset data */
-#define UNIPHIER_SLD3_SYS_RESET_STDMAC(id) \
-   UNIPHIER_RESETX((id), 0x2000, 10)
-
-#define UNIPHIER_LD11_SYS_RESET_STDMAC(id) \
-   UNIPHIER_RESETX((id), 0x200c, 8)
-
-#define UNIPHIER_PRO4_SYS_RESET_GIO(id)\
-   UNIPHIER_RESETX((id), 0x2000, 6)
-
-#define UNIPHIER_LD20_SYS_RESET_GIO(id)\
-   UNIPHIER_RESETX((id), 0x200c, 5)
-
-#define UNIPHIER_PRO4_SYS_RESET_USB3(id, ch)   \
-   UNIPHIER_RESETX((id), 0x2000 + 0x4 * (ch), 17)
-
-static const struct uniphier_reset_data uniphier_ld4_sys_reset_data[] = {
-   UNIPHIER_SLD3_SYS_RESET_STDMAC(8),  /* Ether, HSC, MIO */
-   UNIPHIER_RESET_END,
-};
-
 static const struct uniphier_reset_data uniphier_pro4_sys_reset_data[] = {
-   UNIPHIER_SLD3_SYS_RESET_STDMAC(8),  /* HSC, MIO, RLE */
-   UNIPHIER_PRO4_SYS_RESET_GIO(12),/* Ether, SATA, USB3 */
-   UNIPHIER_PRO4_SYS_RESET_USB3(14, 0),
-   UNIPHIER_PRO4_SYS_RESET_USB3(15, 1),
-   UNIPHIER_RESET_END,
-};
-
-static const struct uniphier_reset_data uniphier_pro5_sys_reset_data[] = {
-   UNIPHIER_SLD3_SYS_RESET_STDMAC(8),  /* HSC */
-   UNIPHIER_PRO4_SYS_RESET_GIO(12),/* PCIe, USB3 */
-   UNIPHIER_PRO4_SYS_RESET_USB3(14, 0),
-   UNIPHIER_PRO4_SYS_RESET_USB3(15, 1),
+   UNIPHIER_RESETX(2, 0x2000, 2),  /* NAND */
+   UNIPHIER_RESETX(8, 0x2000, 10), /* STDMAC */
+   UNIPHIER_RESETX(12, 0x2000, 6), /* GIO */
+   UNIPHIER_RESETX(14, 0x2000, 17),/* USB30 */
+   UNIPHIER_RESETX(15, 0x2004, 17),/* USB31 */
UNIPHIER_RESET_END,
 };
 
 static const struct uniphier_reset_data uniphier_pxs2_sys_reset_data[] = {
-   UNIPHIER_SLD3_SYS_RESET_STDMAC(8),  /* HSC, RLE */
-   UNIPHIER_PRO4_SYS_RESET_USB3(14, 0),
-   UNIPHIER_PRO4_SYS_RESET_USB3(15, 1),
+   UNIPHIER_RESETX(2, 0x2000, 2),  /* NAND */
+   UNIPHIER_RESETX(8, 0x2000, 10), /* STDMAC */
+   UNIPHIER_RESETX(14, 0x2000, 17),/* USB30 */
+   UNIPHIER_RESETX(15, 0x2004, 17),/* USB31 */
UNIPHIER_RESETX(16, 0x2014, 4), /* USB30-PHY0 */
UNIPHIER_RESETX(17, 0x2014, 0), /* USB30-PHY1 */
UNIPHIER_RESETX(18, 0x2014, 2), /* USB30-PHY2 */
@@ -91,14 +65,11 @@ static const struct uniphier_reset_data 
uniphier_pxs2_sys_reset_data[] = {
UNIPHIER_RESET_END,
 };
 
-static const struct uniphier_reset_data uniphier_ld11_sys_reset_data[] = {
-   UNIPHIER_LD11_SYS_RESET_STDMAC(8),  /* HSC, MIO */
-   UNIPHIER_RESET_END,
-};
-
 static const struct uniphier_reset_data uniphier_ld20_sys_reset_data[] = {
-   UNIPHIER_LD11_SYS_RESET_STDMAC(8),  /* HSC */
-   UNIPHIER_LD20_SYS_RESET_GIO(12),/* PCIe, USB3 */
+   UNIPHIER_RESETX(2, 0x200c, 0),  /* NAND */
+   UNIPHIER_RESETX(4, 0x200c, 2),  /* eMMC */
+   UNIPHIER_RESETX(8, 0x200c, 8),  /* STDMAC */
+   UNIPHIER_RESETX(12, 0x200c, 5), /* GIO */
UNIPHIER_RESETX(16, 0x200c, 12),/* USB30-PHY0 */
UNIPHIER_RESETX(17, 0x200c, 13),/* USB30-PHY1 */
UNIPHIER_RESETX(18, 0x200c, 14),/* USB30-PHY2 */
@@ -271,7 +242,7 @@ static const struct udevice_id uniphier_reset_match[] = {
/* System reset */
{
.compatible = "socionext,uniphier-ld4-reset",
-   .data = (ulong)uniphier_ld4_sys_reset_data,
+   .data = (ulong)uniphier_pro4_sys_reset_data,
},
{
.compatible = "socionext,uniphier-pro4-reset",
@@ -279,11 +250,11 @@ static const struct udevice_id uniphier_reset_match[] = {
},
{
.compatible = "socionext,uniphier-sld8-reset",
-   .data = (ulong)uniphier_ld4_sys_reset_data,
+   .data = (ulong)uniphier_pro4_sys_reset_data,
},
{
.compatible = "socionext,uniphier-pro5-reset",
-   .data = (ulong)uniphier_pro5_sys_reset_data,
+   .data = (ulong)uniphier_pro4_sys_reset_data,
},
{
.compatible = "socionext,uniphier-pxs2-reset",
@@ -291,7 +262,7 @@ static 

[U-Boot] [PATCH 5/5] ARM: dts: uniphier: add dr_mode property to dwc3 node

[Masahiro Yamada]

Since commit 576e3cc700c5 ("usb: host: xhci-dwc3: Add dual role mode
support from DT"), warning is displayed.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/dts/uniphier-ld20.dtsi | 1 +
 arch/arm/dts/uniphier-pro4.dtsi | 2 ++
 arch/arm/dts/uniphier-pro5.dtsi | 2 ++
 arch/arm/dts/uniphier-pxs2.dtsi | 2 ++
 4 files changed, 7 insertions(+)

diff --git a/arch/arm/dts/uniphier-ld20.dtsi b/arch/arm/dts/uniphier-ld20.dtsi
index 927340fa48d2..44257aff35b9 100644
--- a/arch/arm/dts/uniphier-ld20.dtsi
+++ b/arch/arm/dts/uniphier-ld20.dtsi
@@ -426,6 +426,7 @@
compatible = "snps,dwc3";
reg = <0x65a0 0x1>;
interrupts = <0 134 4>;
+   dr_mode = "host";
tx-fifo-resize;
};
};
diff --git a/arch/arm/dts/uniphier-pro4.dtsi b/arch/arm/dts/uniphier-pro4.dtsi
index 60287c478f25..cbb848207cc1 100644
--- a/arch/arm/dts/uniphier-pro4.dtsi
+++ b/arch/arm/dts/uniphier-pro4.dtsi
@@ -587,6 +587,7 @@
compatible = "snps,dwc3";
reg = <0x65a0 0x1>;
interrupts = <0 134 4>;
+   dr_mode = "host";
tx-fifo-resize;
};
};
@@ -604,6 +605,7 @@
compatible = "snps,dwc3";
reg = <0x65c0 0x1>;
interrupts = <0 137 4>;
+   dr_mode = "host";
tx-fifo-resize;
};
};
diff --git a/arch/arm/dts/uniphier-pro5.dtsi b/arch/arm/dts/uniphier-pro5.dtsi
index a29597ae88e0..498354c45f90 100644
--- a/arch/arm/dts/uniphier-pro5.dtsi
+++ b/arch/arm/dts/uniphier-pro5.dtsi
@@ -598,6 +598,7 @@
compatible = "snps,dwc3";
reg = <0x65a0 0x1>;
interrupts = <0 134 4>;
+   dr_mode = "host";
tx-fifo-resize;
};
};
@@ -615,6 +616,7 @@
compatible = "snps,dwc3";
reg = <0x65c0 0x1>;
interrupts = <0 137 4>;
+   dr_mode = "host";
tx-fifo-resize;
};
};
diff --git a/arch/arm/dts/uniphier-pxs2.dtsi b/arch/arm/dts/uniphier-pxs2.dtsi
index 2962cb5ae7be..32844f781f5a 100644
--- a/arch/arm/dts/uniphier-pxs2.dtsi
+++ b/arch/arm/dts/uniphier-pxs2.dtsi
@@ -610,6 +610,7 @@
compatible = "snps,dwc3";
reg = <0x65a0 0x1>;
interrupts = <0 134 4>;
+   dr_mode = "host";
tx-fifo-resize;
};
};
@@ -627,6 +628,7 @@
compatible = "snps,dwc3";
reg = <0x65c0 0x1>;
interrupts = <0 137 4>;
+   dr_mode = "host";
tx-fifo-resize;
};
};
-- 
2.7.4

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

Re: [U-Boot] [U-Boot, v2] arm: omap: Fix 'get_device_type()' for OMAP34XX

[Tom Rini]

On Mon, Jul 31, 2017 at 07:41:40AM -0500, Derald D. Woods wrote:

> Fixes: 00bbe96ebabb ("arm: omap: Unify get_device_type() function")
> 
> The control status register value is embedded in a structure somewhere
> in SRAM, with the last refactoring effort. This patch allows OMAP3 EVM
> (TMDSEVM3530) to boot again using the known control register base and
> offset for 'readl', for the OMAP34XX case.
> 
> Signed-off-by: Derald D. Woods 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2] arm: omap: Fix 'get_device_type()' for OMAP34XX

[Tom Rini]

On Thu, Aug 10, 2017 at 07:25:29AM -0500, Derald Woods wrote:

> On Mon, Aug 7, 2017 at 5:19 PM, Derald Woods 
> wrote:
> 
> > On Mon, Aug 7, 2017 at 7:41 AM, Tom Rini  wrote:
> >
> >> On Mon, Aug 07, 2017 at 07:35:30AM -0500, Derald Woods wrote:
> >> > On Mon, Jul 31, 2017 at 7:41 AM, Derald D. Woods <
> >> woods.techni...@gmail.com>
> >> > wrote:
> >> >
> >> > > Fixes: 00bbe96ebabb ("arm: omap: Unify get_device_type() function")
> >> > >
> >> > > The control status register value is embedded in a structure somewhere
> >> > > in SRAM, with the last refactoring effort. This patch allows OMAP3 EVM
> >> > > (TMDSEVM3530) to boot again using the known control register base and
> >> > > offset for 'readl', for the OMAP34XX case.
> >> > >
> >> > > Signed-off-by: Derald D. Woods 
> >> > >
> >> > > ---
> >> > > Changes in v2:
> >> > > - Added 'signed-off-by'
> >> > > - Updated description
> >> > >
> >> > > ---
> >> > >  arch/arm/mach-omap2/sysinfo-common.c | 4 
> >> > >  1 file changed, 4 insertions(+)
> >> > >
> >> > > diff --git a/arch/arm/mach-omap2/sysinfo-common.c
> >> > > b/arch/arm/mach-omap2/sysinfo-common.c
> >> > > index 1dc7051ab3..3955e803ad 100644
> >> > > --- a/arch/arm/mach-omap2/sysinfo-common.c
> >> > > +++ b/arch/arm/mach-omap2/sysinfo-common.c
> >> > > @@ -16,6 +16,10 @@
> >> > >   */
> >> > >  u32 get_device_type(void)
> >> > >  {
> >> > > +#if defined(CONFIG_OMAP34XX)
> >> > > +   return (readl(OMAP34XX_CTRL_BASE + 0x2f0) & DEVICE_TYPE_MASK)
> >> >>
> >> > > +   DEVICE_TYPE_SHIFT;
> >> > > +#endif
> >> > > return (readl((*ctrl)->control_status) & DEVICE_TYPE_MASK) >>
> >> > > DEVICE_TYPE_SHIFT;
> >> > >  }
> >> >
> >> > ​Is there any​ comment or concern with this patch? It was the simplest
> >> > means to get OMAP35XX booting again and still keep the original patch.
> >> > Basically it avoids the pointer to the OMAP_SRAM_SCRATCH_SYS_CTRL
> >> located
> >> > structure as now defined in "arch/arm/mach-omap2/omap3/hw_data.c".
> >> OMAP3
> >> > has a larger active SOC base than just OMAP36XX and greater. Was there
> >> > anything really broken with 'get_device_type()' previously?
> >>
> >> Is the pointer value wrong for 35xx?  The problem, such as it was, was
> >> having the same function duplicated in a number of places, and needing
> >> to make it more easily / readily available (rather than duplicated
> >> again) for some additional patches.  I'd really rather not introduce
> >> an #if here unless we really have no other choice.  Thanks!
> >>
> >> --
> >> Tom
> >>
> >
> > ​I will examine/debug the new 'get_device_type()' source code again
> > tonight. ‎Without the patch, I have two OMAP3530 boards that do not boot at
> > all.
> >
> ​​
> 
> Derald​
> ​
> 
> In "arch/arm/mach-omap2/omap3/board.c", the following routines call
> 'get_device_type':
> - v7_arch_cp15_set_l2aux_ctrl  (called from
> "arch/arm/cpu/armv7/start.S")
> - v7_arch_cp15_set_acr (called from
> "arch/arm/cpu/armv7/start.S")
> - omap3_invalidate_l2_cache_secure (called from "board.c" 's_init')
> - try_unlock_memory(called from "board.c" 's_init')
> 
> Each one of these calls to 'get_device_type' seems to have a purpose (i.e.
> ERRATA or setup). What it highlights is the difference in usage from
> OMAP36XX, AM33XX, and newer. The SRAM usage, L2 cache and call ordering are
> likely factors here. ​Figuring out the implications for OMAP34XX will take
> time. But you need to have boards that boot to address those issues. So
> 'get_device_type' usage, for OMAP34XX, is not strictly a "Apples to Apples"
> type comparison. For now I can proceed with an "out-of-tree" patch, since
> it is small. Let me know if there is something that I am missing here.

OK, thanks for the analysis.  It is indeed a bit too much overhead atm
to see if we can further reconcile all of the code and should grab your
patch, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 2/2] hello_world.c: fix entry point in case of arm thumb binary

[Max Krummenacher]

Dear Wolfgang

Am Samstag, den 12.08.2017, 20:39 +0200 schrieb Wolfgang Denk:
> Dear Max,
> 
> In message <20170812090346.7887-3-max.krummenac...@toradex.com> you wrote:
> > 
> > If compiling for thumb the U-Boot 'go' command can not jump to the entry
> > point, as the jump will be done in the assumption that the code jumped to
> > is using the arm instruction set.
> > 
> > So add add a simple forwarder in arm instruction set which then jumps
> > to the 'real' entry.
> 
> This description makes no sense to me.  Whatever you do, the address
> where the image starts executuin is what is called the entry point.
> Whether this is needs special code to swutch to thumb mode or not
> does not make any difference.  Whichever address you use with the
> "go" command is the "entry point".
> 
> Also, can the mode switching not be done inside the body of the
> regular hello_world() function?  This would be much better as it
> wuld allow to always use the same method to determine the entry
> point address (line running "nm" on the binary and grepping for the
> name "hello_world").  With your code, you would have to fix all
> documentation and explain that the entry pooint name is suddenly
> domething totally different (and an unexpected, unusal name like
> "dummy2" as well) for thumb images.

This again stems from my assumption that one has to write the
standalone application in a way that the entry point is actually
linked to the beginning of the binary.

One cannot put the mode switching from thumb to arm instruction set
inside the body of a C function, as the entry code prepended by
the compiler would be in thumb and thus an exception would occur
before the mode switching code gets executed.

Probably one can add a pragma conditionally so that the entry
function gets compiled in arm instruction set. I investigate
further and send a v2.

Max
> 
> Sorry, but this does not seem a good idea to me.
> 
> Naked-by: Wolfgang Denk 
> 
> Best regards,
> 
> Wolfgang Denk
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] improve hello_world standalone application for arm

[Max Krummenacher]

Dear Wolfgang

Am Samstag, den 12.08.2017, 20:32 +0200 schrieb Wolfgang Denk:
> Dear Max,
> 
> In message <20170812090346.7887-1-max.krummenac...@toradex.com> you wrote:
> > 
> > 
> > This series addresses
> > - hardcoded entry address, use LOADADDR if available as the entry point 
> > instead
> 
> I'm not sure which sort of problem you are trying to fix, but what
> you describe here is inherently broken.
> 
> The entry point of an image is almost never ever at the beginning of
> an image.

I was mislead by the table in point 6. of doc/README.standalone that it
is a design decision that the entry point is whatever is linked to the
beginning of the text segment. Thus the sloppy use of entry point and
load address.

Max
> 
> Naked-by: Wolfgang Denk 
> 
> Sorry!
> 
> 
> Best regards,
> 
> Wolfgang Denk
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] arm: use $loadaddr as the standalone entry point

[Max Krummenacher]

Dear Wolfgang

Am Samstag, den 12.08.2017, 20:29 +0200 schrieb Wolfgang Denk:
> Dear Max,
> 
> In message <20170812090346.7887-2-max.krummenac...@toradex.com> you wrote:
> > 
> > Different SoCs have different RAM layouts, so providing
> > $(CONFIG_LOADADDR) instead of the constant 0xc10 for
> > CONFIG_STANDALONE_LOAD_ADDR is probably more appropriate.
> 
> At least the wording of the Subject should be fixed.

Ok, will do. The issue is that linking the standalone application
to have its text segment at a hardcoded address is less
likely to work than using an address provided by the board
configuration as a possible load address.

Will reword the commit message in a v2 series accordingly.

Max

> 
> It is fundamentaaly broken to associate the names "loadaddr" and
> "entry point" with each other.  Both are completely independent
> entities which mean totally different things. It is pure chance if
> the entry point of some loaded image should be at the very beginning
> of this image, but this is almost never the case.
> 
> Best regards,
> 
> Wolfgang Denk
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Convert CONFIG_NAND to Kconfig

[Tom Rini]

On Mon, Aug 07, 2017 at 05:37:18PM -0400, Tom Rini wrote:

> From: Adam Ford 
> 
> This converts the following to Kconfig:
>CONFIG_NAND
> 
> Signed-off-by: Adam Ford 
> [trini: Sync up a few more, add imply's]
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 2/2] hello_world.c: fix entry point in case of arm thumb binary

[Wolfgang Denk]

Dear Max,

In message <20170812090346.7887-3-max.krummenac...@toradex.com> you wrote:
> If compiling for thumb the U-Boot 'go' command can not jump to the entry
> point, as the jump will be done in the assumption that the code jumped to
> is using the arm instruction set.
> 
> So add add a simple forwarder in arm instruction set which then jumps
> to the 'real' entry.

This description makes no sense to me.  Whatever you do, the address
where the image starts executuin is what is called the entry point.
Whether this is needs special code to swutch to thumb mode or not
does not make any difference.  Whichever address you use with the
"go" command is the "entry point".

Also, can the mode switching not be done inside the body of the
regular hello_world() function?  This would be much better as it
wuld allow to always use the same method to determine the entry
point address (line running "nm" on the binary and grepping for the
name "hello_world").  With your code, you would have to fix all
documentation and explain that the entry pooint name is suddenly
domething totally different (and an unexpected, unusal name like
"dummy2" as well) for thumb images.

Sorry, but this does not seem a good idea to me.

Naked-by: Wolfgang Denk 

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The use of anthropomorphic terminology when  dealing  with  computing
systems is a symptom of professional immaturity.   -- Edsger Dijkstra
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] improve hello_world standalone application for arm

[Wolfgang Denk]

Dear Max,

In message <20170812090346.7887-1-max.krummenac...@toradex.com> you wrote:
> 
> This series addresses
> - hardcoded entry address, use LOADADDR if available as the entry point 
> instead

I'm not sure which sort of problem you are trying to fix, but what
you describe here is inherently broken.

The entry point of an image is almost never ever at the beginning of
an image.

Naked-by: Wolfgang Denk 

Sorry!


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
What is wanted is not the will to believe,  but the will to find out,
which is the exact opposite.
-- Bertrand Russell, "Skeptical Essays", 1928
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] arm: use $loadaddr as the standalone entry point

[Wolfgang Denk]

Dear Max,

In message <20170812090346.7887-2-max.krummenac...@toradex.com> you wrote:
> Different SoCs have different RAM layouts, so providing
> $(CONFIG_LOADADDR) instead of the constant 0xc10 for
> CONFIG_STANDALONE_LOAD_ADDR is probably more appropriate.

At least the wording of the Subject should be fixed.

It is fundamentaaly broken to associate the names "loadaddr" and
"entry point" with each other.  Both are completely independent
entities which mean totally different things. It is pure chance if
the entry point of some loaded image should be at the very beginning
of this image, but this is almost never the case.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"The bad reputation UNIX has gotten is totally undeserved, laid on by
people who don't understand, who have not gotten in there  and  tried
anything."  -- Jim Joyce, owner of Jim Joyce's UNIX Bookstore
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 14/15] efi_loader: efi variable support

[Rob Clark]

On Sat, Aug 12, 2017 at 1:28 PM, Alexander Graf  wrote:
>
>
>> Am 12.08.2017 um 16:39 schrieb Rob Clark :
>>
>>> On Sat, Aug 12, 2017 at 9:01 AM, Alexander Graf  wrote:
>>>
>>>
 On 10.08.17 20:29, Rob Clark wrote:

 Add EFI variable support, mapping to u-boot environment variables.
 Variables are pretty important for setting up boot order, among other
 things.  If the board supports saveenv, then it will be called in
 ExitBootServices() to persist variables set by the efi payload.  (For
 example, fallback.efi configuring BootOrder and Boot load-option
 variables.)

 Variables are *not* currently exposed at runtime, post ExitBootServices.
 On boards without a dedicated device for storage, which the loaded OS
 is not trying to also use, this is rather tricky.  One idea, at least
 for boards that can persist RAM across reboot, is to keep a "journal"
 of modified variables in RAM, and then turn halt into a reboot into
 u-boot, plus store variables, plus halt.  Whatever the solution, it
 likely involves some per-board support.

 Mapping between EFI variables and u-boot variables:

   efi_$guid_$varname = {attributes}(type)value

 For example:

   efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported=
  "{ro,boot,run}(blob)"
   efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder=
  "(blob)0001"

 The attributes are a comma separated list of these possible
 attributes:

   + ro   - read-only
   + boot - boot-services access
   + run  - runtime access

 NOTE: with current implementation, no variables are available after
 ExitBootServices, and all are persisted (if possible).

 If not specified, the attributes default to "{boot}".

 The required type is one of:

   + utf8 - raw utf8 string
   + blob - arbitrary length hex string

 Signed-off-by: Rob Clark 
 ---
  cmd/bootefi.c |   4 +
  include/efi.h |  19 +++
  include/efi_loader.h  |  10 ++
  lib/efi_loader/Makefile   |   2 +-
  lib/efi_loader/efi_boottime.c |   5 +
  lib/efi_loader/efi_runtime.c  |  17 ++-
  lib/efi_loader/efi_variable.c | 342
 ++
  7 files changed, 394 insertions(+), 5 deletions(-)
  create mode 100644 lib/efi_loader/efi_variable.c

 diff --git a/cmd/bootefi.c b/cmd/bootefi.c
 index b9e1e5e131..80f52e9e35 100644
 --- a/cmd/bootefi.c
 +++ b/cmd/bootefi.c
 @@ -181,6 +181,10 @@ static unsigned long do_bootefi_exec(void *efi, void
 *fdt,
goto exit;
}
  + /* we don't support much: */
 +
 setenv("efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported",
 +   "{ro,boot}(blob)");
 +
/* Call our payload! */
debug("%s:%d Jumping to 0x%lx\n", __func__, __LINE__,
 (long)entry);
  diff --git a/include/efi.h b/include/efi.h
 index ddd2b96417..dbd482a5db 100644
 --- a/include/efi.h
 +++ b/include/efi.h
 @@ -324,6 +324,25 @@ extern char image_base[];
  /* Start and end of U-Boot image (for payload) */
  extern char _binary_u_boot_bin_start[], _binary_u_boot_bin_end[];
  +/*
 + * Variable Attributes
 + */
 +#define EFI_VARIABLE_NON_VOLATILE   0x0001
>>>
>>>
>>> Shouldn't we honor this one too? A UEFI application may set runtime
>>> variables that should not get persisted across boots (think the UEFI shell
>>> setting some internal state thing, then booting Linux).
>>
>> So the thing is, we honor non-volatile (at least to the extent the
>> board can do saveenv()).  What we don't do is make volatile vars
>> disappear on reboot... which isn't terribly easy to do since we don't
>> have any way to mark u-boot env vars as volatile.
>>
>> But my reading of the spec doesn't preclude volatile variables from
>> being persisted.  It only says that non-volatile variables should be
>> persisted.
>
> The spec actually says in the non_volatile definition that volatile vars get 
> stored in ram and will disappear after reboot.
>
> Volatile could just be an attribute like all the others and before saveenv we 
> just search for volatile and remove them?
>

I could add it as an attribute.  Although I'm not sure there is any
easy way to iterate env vars without digging into internals of nvedit
(otherwise I probably would have already added GetNextVariable())

Possibly I should add an nv attribute anyways, for future-compat
(which was the only reason I bothered adding boot and run attributes)

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

Re: [U-Boot] [PATCH v1 14/15] efi_loader: efi variable support

[Alexander Graf]

> Am 12.08.2017 um 16:39 schrieb Rob Clark :
> 
>> On Sat, Aug 12, 2017 at 9:01 AM, Alexander Graf  wrote:
>> 
>> 
>>> On 10.08.17 20:29, Rob Clark wrote:
>>> 
>>> Add EFI variable support, mapping to u-boot environment variables.
>>> Variables are pretty important for setting up boot order, among other
>>> things.  If the board supports saveenv, then it will be called in
>>> ExitBootServices() to persist variables set by the efi payload.  (For
>>> example, fallback.efi configuring BootOrder and Boot load-option
>>> variables.)
>>> 
>>> Variables are *not* currently exposed at runtime, post ExitBootServices.
>>> On boards without a dedicated device for storage, which the loaded OS
>>> is not trying to also use, this is rather tricky.  One idea, at least
>>> for boards that can persist RAM across reboot, is to keep a "journal"
>>> of modified variables in RAM, and then turn halt into a reboot into
>>> u-boot, plus store variables, plus halt.  Whatever the solution, it
>>> likely involves some per-board support.
>>> 
>>> Mapping between EFI variables and u-boot variables:
>>> 
>>>   efi_$guid_$varname = {attributes}(type)value
>>> 
>>> For example:
>>> 
>>>   efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported=
>>>  "{ro,boot,run}(blob)"
>>>   efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder=
>>>  "(blob)0001"
>>> 
>>> The attributes are a comma separated list of these possible
>>> attributes:
>>> 
>>>   + ro   - read-only
>>>   + boot - boot-services access
>>>   + run  - runtime access
>>> 
>>> NOTE: with current implementation, no variables are available after
>>> ExitBootServices, and all are persisted (if possible).
>>> 
>>> If not specified, the attributes default to "{boot}".
>>> 
>>> The required type is one of:
>>> 
>>>   + utf8 - raw utf8 string
>>>   + blob - arbitrary length hex string
>>> 
>>> Signed-off-by: Rob Clark 
>>> ---
>>>  cmd/bootefi.c |   4 +
>>>  include/efi.h |  19 +++
>>>  include/efi_loader.h  |  10 ++
>>>  lib/efi_loader/Makefile   |   2 +-
>>>  lib/efi_loader/efi_boottime.c |   5 +
>>>  lib/efi_loader/efi_runtime.c  |  17 ++-
>>>  lib/efi_loader/efi_variable.c | 342
>>> ++
>>>  7 files changed, 394 insertions(+), 5 deletions(-)
>>>  create mode 100644 lib/efi_loader/efi_variable.c
>>> 
>>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>>> index b9e1e5e131..80f52e9e35 100644
>>> --- a/cmd/bootefi.c
>>> +++ b/cmd/bootefi.c
>>> @@ -181,6 +181,10 @@ static unsigned long do_bootefi_exec(void *efi, void
>>> *fdt,
>>>goto exit;
>>>}
>>>  + /* we don't support much: */
>>> +
>>> setenv("efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported",
>>> +   "{ro,boot}(blob)");
>>> +
>>>/* Call our payload! */
>>>debug("%s:%d Jumping to 0x%lx\n", __func__, __LINE__,
>>> (long)entry);
>>>  diff --git a/include/efi.h b/include/efi.h
>>> index ddd2b96417..dbd482a5db 100644
>>> --- a/include/efi.h
>>> +++ b/include/efi.h
>>> @@ -324,6 +324,25 @@ extern char image_base[];
>>>  /* Start and end of U-Boot image (for payload) */
>>>  extern char _binary_u_boot_bin_start[], _binary_u_boot_bin_end[];
>>>  +/*
>>> + * Variable Attributes
>>> + */
>>> +#define EFI_VARIABLE_NON_VOLATILE   0x0001
>> 
>> 
>> Shouldn't we honor this one too? A UEFI application may set runtime
>> variables that should not get persisted across boots (think the UEFI shell
>> setting some internal state thing, then booting Linux).
> 
> So the thing is, we honor non-volatile (at least to the extent the
> board can do saveenv()).  What we don't do is make volatile vars
> disappear on reboot... which isn't terribly easy to do since we don't
> have any way to mark u-boot env vars as volatile.
> 
> But my reading of the spec doesn't preclude volatile variables from
> being persisted.  It only says that non-volatile variables should be
> persisted.

The spec actually says in the non_volatile definition that volatile vars get 
stored in ram and will disappear after reboot.

Volatile could just be an attribute like all the others and before saveenv we 
just search for volatile and remove them?



> 
>> 
>>> +#define EFI_VARIABLE_BOOTSERVICE_ACCESS 0x0002
>>> +#define EFI_VARIABLE_RUNTIME_ACCESS 0x0004
>>> +#define EFI_VARIABLE_HARDWARE_ERROR_RECORD 0x0008
>>> +#define EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS 0x0010
>>> +#define EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS
>>> 0x0020
>>> +#define EFI_VARIABLE_APPEND_WRITE  0x0040
>>> +
>>> +#define EFI_VARIABLE_MASK  (EFI_VARIABLE_NON_VOLATILE | \
>>> +   EFI_VARIABLE_BOOTSERVICE_ACCESS | \
>>> +   EFI_VARIABLE_RUNTIME_ACCESS | \
>>> +   

Re: [U-Boot] [PATCH v1 08/15] efi_loader: use proper device-paths for partitions

[Alexander Graf]

> Am 12.08.2017 um 16:31 schrieb Rob Clark :
> 
>> On Sat, Aug 12, 2017 at 8:36 AM, Alexander Graf  wrote:
>> 
>> 
>>> On 10.08.17 20:29, Rob Clark wrote:
>>> 
>>> Also, create disk objects for the disk itself, in addition to the
>>> partitions.  (UEFI terminology is a bit confusing, a "disk" object is
>>> really a partition.)  This helps grub properly identify the boot device
>>> since it is trying to match up partition "disk" object with it's parent
>>> device.
>>> 
>>> Now instead of seeing devices like:
>>> 
>>>   /File(sd...@07864000.blk)/EndEntire
>>>   /File(usb_mass_storage.lun0)/EndEntire
>>> 
>>> You see:
>>> 
>>>   /ACPI(133741d0,0)/UnknownMessaging(1d)/EndEntire
>>> 
>>> /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(0,800,64000,dd904a8c,1,1)/EndEntire
>>> 
>>> /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(1,64800,20,dd904a8c,1,1)/EndEntire
>>> 
>>> /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(2,264800,19a000,dd904a8c,1,1)/EndEntire
>>>   /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/EndEntire
>>> 
>>> /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(0,800,6,38ca6802,1,1)/EndEntire
>>> 
>>> /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(1,61000,155000,38ca6802,1,1)/EndEntire
>>> 
>>> /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(2,20fa800,1bbf8800,38ca6802,1,1)/EndEntire
>>> 
>>> /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(3,1b6800,1f44000,38ca6802,1,1)/EndEntire
>>> 
>>> This is on a board with single USB disk and single sd-card.  The
>>> UnknownMessaging(1d) node in the device-path is the MMC device,
>>> but grub_efi_print_device_path() hasn't been updated yet for some
>>> of the newer device-path sub-types.
>>> 
>>> This patch is inspired by a patch originally from Peter Jones, but
>>> re-worked to use efi_device_path, so it doesn't much resemble the
>>> original.
>>> 
>>> Signed-off-by: Rob Clark 
>>> ---
>>>  lib/efi_loader/efi_disk.c | 54
>>> +++
>>>  1 file changed, 31 insertions(+), 23 deletions(-)
>>> 
>>> diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
>>> index ed06485e33..eea65a402a 100644
>>> --- a/lib/efi_loader/efi_disk.c
>>> +++ b/lib/efi_loader/efi_disk.c
>>> @@ -28,11 +28,13 @@ struct efi_disk_obj {
>>>/* EFI Interface Media descriptor struct, referenced by ops */
>>>struct efi_block_io_media media;
>>>/* EFI device path to this block device */
>>> -   struct efi_device_path_file_path *dp;
>>> +   struct efi_device_path *dp;
>>> +   /* partition # */
>>> +   unsigned part;
>>>/* Offset into disk for simple partitions */
>>>lbaint_t offset;
>>>/* Internal block device */
>>> -   const struct blk_desc *desc;
>>> +   struct blk_desc *desc;
>>>  };
>>>static efi_status_t EFIAPI efi_disk_reset(struct efi_block_io *this,
>>> @@ -172,26 +174,26 @@ static const struct efi_block_io
>>> block_io_disk_template = {
>>>static void efi_disk_add_dev(const char *name,
>>> const char *if_typename,
>>> -const struct blk_desc *desc,
>>> +struct blk_desc *desc,
>>> int dev_index,
>>> -lbaint_t offset)
>>> +lbaint_t offset,
>>> +unsigned part)
>>>  {
>>>struct efi_disk_obj *diskobj;
>>> -   struct efi_device_path_file_path *dp;
>>> -   int objlen = sizeof(*diskobj) + (sizeof(*dp) * 2);
>>>/* Don't add empty devices */
>>>if (!desc->lba)
>>>return;
>>>  - diskobj = calloc(1, objlen);
>>> +   diskobj = calloc(1, sizeof(*diskobj));
>>>/* Fill in object data */
>>> -   dp = (void *)[1];
>>> +   diskobj->dp = efi_dp_from_part(desc, part);
>>> +   diskobj->part = part;
>>>diskobj->parent.protocols[0].guid = _block_io_guid;
>>>diskobj->parent.protocols[0].protocol_interface = >ops;
>>>diskobj->parent.protocols[1].guid = _guid_device_path;
>>> -   diskobj->parent.protocols[1].protocol_interface = dp;
>>> +   diskobj->parent.protocols[1].protocol_interface = diskobj->dp;
>>>diskobj->parent.handle = diskobj;
>>>diskobj->ops = block_io_disk_template;
>>>diskobj->ifname = if_typename;
>>> @@ -207,17 +209,6 @@ static void efi_disk_add_dev(const char *name,
>>>diskobj->media.last_block = desc->lba - offset;
>>>diskobj->ops.media = >media;
>>>  - /* Fill in device path */
>>> -   diskobj->dp = dp;
>>> -   dp[0].dp.type = DEVICE_PATH_TYPE_MEDIA_DEVICE;
>>> -   dp[0].dp.sub_type = DEVICE_PATH_SUB_TYPE_FILE_PATH;
>>> -   dp[0].dp.length = sizeof(*dp);
>>> -   ascii2unicode(dp[0].str, name);
>>> -
>>> -   dp[1].dp.type = DEVICE_PATH_TYPE_END;
>>> -   dp[1].dp.sub_type = 

Re: [U-Boot] [PATCH v1 02/15] fs/fat: implement readdir

[Alexander Graf]

> Am 12.08.2017 um 16:04 schrieb Rob Clark :
> 
>> On Sat, Aug 12, 2017 at 8:17 AM, Alexander Graf  wrote:
>> 
>> 
>>> On 10.08.17 20:29, Rob Clark wrote:
>>> 
>>> Yes, this is super-hacky.  The FAT code is quite ugly, and this doesn't
>>> improve things.  But it doesn't make it significantly worse either.  The
>>> better option would be a massive FAT re-write to get rid of the hacky
>>> way that fat_file_ls() works.  Volunteers welcome.
>>> 
>>> Signed-off-by: Rob Clark 
>> 
>> 
>> What concerns me the most in patch 1/15 and this patch is the limited scope.
>> Yes, you make readdir work for FAT, but all other file systems are still
>> unimplemented. In fact, they're even all still implementing their own
>> hand-written ls logic.
>> 
>> One of the goals of the efi_loader code is to integrate with U-Boot as much
>> as possible, to reuse code where we can. And if current interfaces are
>> terrible, I think it's ok to just replace them for something that fits
>> everyone's needs better.
>> 
>> How feasible do you think it would be to implement an ls function based on
>> readdir and just convert all file systems to it, completely replacing the
>> current (quite crude) ls logic?
> 
> So I went ahead and re-wrote the fat directory traversal[1].  I should
> be posting to list in the next day or two but still want to make a few
> small cleanups.  (And to get rid of some hacks in efi_file, I think I
> need to add an fs_isdir() too :-/)
> 
> As far as the various other filesys's, I agree that a generic ls would
> be a nice goal.  But the scope of the efi_loader patchset has already
> expanded way too much, and at this point I'm pretty much limited by
> what I can finish this weekend.  At the end of the day, FAT is all
> that UEFI expects, so I think it is fine to let the other filesystems
> catch up on their own schedule.
> 
> I could write a generic ls helper, and just plug it in for FAT, which
> could be re-used later when other filesys's gain readdir support.

That at least sounds much nicer than duplicating ls functionality and moves us 
into the right direction.


Thanks!

Alex


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

Re: [U-Boot] [PATCH v2 4/5] arm: socfpga: Add intermediate driver between flash and FPGA manager

[Marek Vasut]

On 08/12/2017 10:03 AM, Chee, Tien Fong wrote:
[...]
>>> 1: It having ability to the right memory(OCRAM or SDRAM) to achieve
>>> the
>>> best FPGA programing performance.
>> Did you find significant throughput difference ?
>>
> 80% performance improvement with SDRAM.

This looks more like caches are not enabled ... sort of problem ?

>>> 2: It can determine the right size buffer for the fpga rbf without
>>> info
>>> of buffer size defined by user.
>> You mean like $filesize variable in the command prompt ?
>>
> Yeah. No filesize is required.

You can use $filesize instead of reimplementing this functionality
yourself though ?

>>> 3: It has ability to know what kind of fpga rbf type, and security
>>> type, such as peripheral, core, combined rbf, encryption and
>>> unencryption based on any fpga file user pass in .
>> Is this information used for anything ? I was under the impression
>> that
>> the user just needs to load in the correct RBF file into the FPGA.
>>
> Yeah, the driver would decode the RBF image to know what type of RBF
> user loading, and applying correct method(buffer allocation, which
> memory to use and configuration on FPGA manager) to program FPGA.

If the code needs to extract some information from the RBF to correctly
configure something in the FPGA manager, then that's where this should
go then.

>>> 4: It supports the checksum.
>> What checksum ? Can we have a generic hook into the FPGA framework ?
>>
> This checksum is to ensure integrity of RBF file after loading from
> flash into SDRAM. This can help to prevent possibility system
> instability caused by programming corrupt rbf into FPGA. So, this
> should be implemented in cff.c .

Or the FPGA manager driver .

>>> 5: support raw flash without fs.
>> This should go into common code.
>>
> raw flash is part of common codes in cff.c because it is part of
> mechanism like fs to determine how loading rbf from flash and program
> into fpga.

By common code I mean the stuff around FPGA LOADFS , so other FPGAs can
also benefit from that.

>>> 6: support the file name defined in DTS and U-boot environment
>>> variable.
>> I think you should extend the FPGA LOADFS here instead.
>>
> The peripheral rbf filename and DTS are generated from our bsp tool.
> But user can run fpga loadfs to reconfigure FPGA in U-boot console
> after i have supported it.

And why don't you rather apply some FPGA LOADFS if this property is
detected in the DT instead of reimplementing it ?

>>>

  Also, the ifdeffery is awful and the explicit
 depedence on VFAT when loading from FS is real bad.

>>> It is because a lot functions is common to sdmmc, nand and qspi in
>>> different fs such as vfat, ubi and raw. It is unavoidable to have
>>> some
>>> ifdeffery if we want to keep the function common to all flashes and
>>> fs. 
>> Can the FPGA LOADFS be extended generically ?
>>
> Yeah, FPGA loadfs is considered when design cff.c. But, i plan to to
> support FPGA loadfs after having complete boot to U-boot console.

Does that mean the Arria10 is still not even capable of booting into
U-Boot console ?

cff.c is unlikely to hit mainline unless there's compelling argument
that it is needed . Thus far, I see most of the functionality should be
added elsewhere or is already there (fpga loadfs).

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

Re: [U-Boot] [PATCH 1/5] mmc: uniphier-sd: Factor out register IO

[Marek Vasut]

On 08/10/2017 09:49 AM, Masahiro Yamada wrote:
> Hi.
> 
> 
> 2017-08-07 17:30 GMT+09:00 Marek Vasut :
>> On 08/07/2017 04:30 AM, Masahiro Yamada wrote:
>>> Hi Marek,
>>
>> Hi Masahiro,
>>
>> This is gonna be a great discussion, let's wrestle about consts and ints :-)
>>
>>> 2017-08-06 4:23 GMT+09:00 Marek Vasut :
 On 08/03/2017 02:36 PM, Masahiro Yamada wrote:
> Hi Marek,

 Hi,

 [...]

>> +static u32 uniphier_sd_readl(struct uniphier_sd_priv *priv, const u32 
>> reg)
>
> "const" is unneeded here.

 Why? The function should not modify reg , so it is const.
>>>
>>>
>>> Because "const" is useless here.
>>>
>>> The "reg" is not a pointer, so it is obvious
>>> that there is no impact to the callers.
>>>
>>>
>>>
>>> Moreover, whether "reg" is constant or not
>>> depends on how you implement the function.
>>>
>>>
>>> If you force "const" to the argument, the only choice for the implementation
>>> will be as follows:
>>>
>>>
>>>
>>> static u32 uniphier_sd_readl(struct uniphier_sd_priv *priv, const u32 reg)
>>> {
>>>   if (priv->caps & UNIPHIER_SD_CAP_64BIT)
>>>  return readl(priv->regbase + (reg << 1));
>>>   else
>>>  return readl(priv->regbase + reg);
>>> }
>>>
>>>
>>>
>>> If you want to implement the function as follows, you need to drop "const".
>>>
>>> static u32 uniphier_sd_readl(struct uniphier_sd_priv *priv, u32 reg)
>>> {
>>>   if (priv->caps & UNIPHIER_SD_CAP_64BIT)
>>>   reg <<= 1;
>>>
>>>   return readl(priv->regbase + reg);
>>> }
>>
>> My argument would be that the const prevents you from accidentally
>> modifying the $reg inside the function.
> 
> 
> No.
> The arguments of a functions are local variables.
> No impact on the outside of the scope of the function.

I'm not arguing about that.

> If you accidentally modify a variable where it should not,
> it is a bug.  Just fix it.

If it's const, compiler will warn the user he's doing something stupid.

> If you want to wrestle more, please do it in LKML
> by adding around "const".
> 
> For example,
> 
> drivers/base/regmap/regmap.c:
> int regmap_write(struct regmap *map, unsigned int reg, unsigned int val)
> 
> arch/arm/include/asm/io.h:
> static inline void __raw_writel(u32 val, volatile void __iomem *addr)

Well, there were some cocci patches adding const recently :)

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

Re: [U-Boot] [PATCH v2 2/5] arm: socfpga: Add checking function on FPGA setting in FDT

[Marek Vasut]

On 08/12/2017 10:05 AM, Chee, Tien Fong wrote:
> On Jum, 2017-08-11 at 17:01 +0200, Marek Vasut wrote:
>> On 08/10/2017 06:51 AM, Chee, Tien Fong wrote:
>>>
>>> On Rab, 2017-08-09 at 10:20 +0200, Marek Vasut wrote:

 On 08/09/2017 07:07 AM, Chee, Tien Fong wrote:
>
>
> On Sel, 2017-08-08 at 11:29 +0200, Marek Vasut wrote:
>>
>>
>> On 08/08/2017 11:12 AM, tien.fong.c...@intel.com wrote:
>>>
>>>
>>>
>>> From: Tien Fong Chee 
>>>
>>> Function for checking FPGA early release setting which is
>>> defined
>>> by user in FDT chosen section. This function would be used
>>> by
>>> later driver in decision applying appropriate FPGA
>>> configuration in
>>> early release or full FPGA booting mode.
>> Isn't this a property of the FPGA driver ?
>>> This is not property of fpga driver. It acts like passing data flag
>>> to
>>> u-boot, so u-boot knows how to boot in the mode defined by user.
>> So it's a configuration option ? Doing what ... since there's no
>> binding
>> document, it's not clear.
>>
> Okay, i can add decription into / doc / device-tree-bindings /
> chosen.txt.
>>>

>
>>
>> Shouldn't this have altr, prefix ?
>>> This node doesn't represet a real device, it acts like a place for
>>> passing data to U-boot. So, this flag name doesn't matter with
>>> prefix,
>>> right?
>> But it's altera-specific, so it should have one ?
>>
> Yeah, i can add it.
OK

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

Re: [U-Boot] [PATCH v1 14/15] efi_loader: efi variable support

[Rob Clark]

On Sat, Aug 12, 2017 at 9:01 AM, Alexander Graf  wrote:
>
>
> On 10.08.17 20:29, Rob Clark wrote:
>>
>> Add EFI variable support, mapping to u-boot environment variables.
>> Variables are pretty important for setting up boot order, among other
>> things.  If the board supports saveenv, then it will be called in
>> ExitBootServices() to persist variables set by the efi payload.  (For
>> example, fallback.efi configuring BootOrder and Boot load-option
>> variables.)
>>
>> Variables are *not* currently exposed at runtime, post ExitBootServices.
>> On boards without a dedicated device for storage, which the loaded OS
>> is not trying to also use, this is rather tricky.  One idea, at least
>> for boards that can persist RAM across reboot, is to keep a "journal"
>> of modified variables in RAM, and then turn halt into a reboot into
>> u-boot, plus store variables, plus halt.  Whatever the solution, it
>> likely involves some per-board support.
>>
>> Mapping between EFI variables and u-boot variables:
>>
>>efi_$guid_$varname = {attributes}(type)value
>>
>> For example:
>>
>>efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported=
>>   "{ro,boot,run}(blob)"
>>efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder=
>>   "(blob)0001"
>>
>> The attributes are a comma separated list of these possible
>> attributes:
>>
>>+ ro   - read-only
>>+ boot - boot-services access
>>+ run  - runtime access
>>
>> NOTE: with current implementation, no variables are available after
>> ExitBootServices, and all are persisted (if possible).
>>
>> If not specified, the attributes default to "{boot}".
>>
>> The required type is one of:
>>
>>+ utf8 - raw utf8 string
>>+ blob - arbitrary length hex string
>>
>> Signed-off-by: Rob Clark 
>> ---
>>   cmd/bootefi.c |   4 +
>>   include/efi.h |  19 +++
>>   include/efi_loader.h  |  10 ++
>>   lib/efi_loader/Makefile   |   2 +-
>>   lib/efi_loader/efi_boottime.c |   5 +
>>   lib/efi_loader/efi_runtime.c  |  17 ++-
>>   lib/efi_loader/efi_variable.c | 342
>> ++
>>   7 files changed, 394 insertions(+), 5 deletions(-)
>>   create mode 100644 lib/efi_loader/efi_variable.c
>>
>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>> index b9e1e5e131..80f52e9e35 100644
>> --- a/cmd/bootefi.c
>> +++ b/cmd/bootefi.c
>> @@ -181,6 +181,10 @@ static unsigned long do_bootefi_exec(void *efi, void
>> *fdt,
>> goto exit;
>> }
>>   + /* we don't support much: */
>> +
>> setenv("efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported",
>> +   "{ro,boot}(blob)");
>> +
>> /* Call our payload! */
>> debug("%s:%d Jumping to 0x%lx\n", __func__, __LINE__,
>> (long)entry);
>>   diff --git a/include/efi.h b/include/efi.h
>> index ddd2b96417..dbd482a5db 100644
>> --- a/include/efi.h
>> +++ b/include/efi.h
>> @@ -324,6 +324,25 @@ extern char image_base[];
>>   /* Start and end of U-Boot image (for payload) */
>>   extern char _binary_u_boot_bin_start[], _binary_u_boot_bin_end[];
>>   +/*
>> + * Variable Attributes
>> + */
>> +#define EFI_VARIABLE_NON_VOLATILE   0x0001
>
>
> Shouldn't we honor this one too? A UEFI application may set runtime
> variables that should not get persisted across boots (think the UEFI shell
> setting some internal state thing, then booting Linux).

So the thing is, we honor non-volatile (at least to the extent the
board can do saveenv()).  What we don't do is make volatile vars
disappear on reboot... which isn't terribly easy to do since we don't
have any way to mark u-boot env vars as volatile.

But my reading of the spec doesn't preclude volatile variables from
being persisted.  It only says that non-volatile variables should be
persisted.

>
>> +#define EFI_VARIABLE_BOOTSERVICE_ACCESS 0x0002
>> +#define EFI_VARIABLE_RUNTIME_ACCESS 0x0004
>> +#define EFI_VARIABLE_HARDWARE_ERROR_RECORD 0x0008
>> +#define EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS 0x0010
>> +#define EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS
>> 0x0020
>> +#define EFI_VARIABLE_APPEND_WRITE  0x0040
>> +
>> +#define EFI_VARIABLE_MASK  (EFI_VARIABLE_NON_VOLATILE | \
>> +   EFI_VARIABLE_BOOTSERVICE_ACCESS | \
>> +   EFI_VARIABLE_RUNTIME_ACCESS | \
>> +   EFI_VARIABLE_HARDWARE_ERROR_RECORD | \
>> +   EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS |
>> \
>> +
>> EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS | \
>> +   EFI_VARIABLE_APPEND_WRITE)
>> +
>>   /**
>>* efi_get_sys_table() - Get access to the main EFI system table
>>*
>> diff --git a/include/efi_loader.h b/include/efi_loader.h
>> index efb93f31f7..9cb568e615 100644

Re: [U-Boot] [PATCH v1 08/15] efi_loader: use proper device-paths for partitions

[Rob Clark]

On Sat, Aug 12, 2017 at 8:36 AM, Alexander Graf  wrote:
>
>
> On 10.08.17 20:29, Rob Clark wrote:
>>
>> Also, create disk objects for the disk itself, in addition to the
>> partitions.  (UEFI terminology is a bit confusing, a "disk" object is
>> really a partition.)  This helps grub properly identify the boot device
>> since it is trying to match up partition "disk" object with it's parent
>> device.
>>
>> Now instead of seeing devices like:
>>
>>/File(sd...@07864000.blk)/EndEntire
>>/File(usb_mass_storage.lun0)/EndEntire
>>
>> You see:
>>
>>/ACPI(133741d0,0)/UnknownMessaging(1d)/EndEntire
>>
>> /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(0,800,64000,dd904a8c,1,1)/EndEntire
>>
>> /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(1,64800,20,dd904a8c,1,1)/EndEntire
>>
>> /ACPI(133741d0,0)/UnknownMessaging(1d)/HD(2,264800,19a000,dd904a8c,1,1)/EndEntire
>>/ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/EndEntire
>>
>> /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(0,800,6,38ca6802,1,1)/EndEntire
>>
>> /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(1,61000,155000,38ca6802,1,1)/EndEntire
>>
>> /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(2,20fa800,1bbf8800,38ca6802,1,1)/EndEntire
>>
>> /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(3,1b6800,1f44000,38ca6802,1,1)/EndEntire
>>
>> This is on a board with single USB disk and single sd-card.  The
>> UnknownMessaging(1d) node in the device-path is the MMC device,
>> but grub_efi_print_device_path() hasn't been updated yet for some
>> of the newer device-path sub-types.
>>
>> This patch is inspired by a patch originally from Peter Jones, but
>> re-worked to use efi_device_path, so it doesn't much resemble the
>> original.
>>
>> Signed-off-by: Rob Clark 
>> ---
>>   lib/efi_loader/efi_disk.c | 54
>> +++
>>   1 file changed, 31 insertions(+), 23 deletions(-)
>>
>> diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
>> index ed06485e33..eea65a402a 100644
>> --- a/lib/efi_loader/efi_disk.c
>> +++ b/lib/efi_loader/efi_disk.c
>> @@ -28,11 +28,13 @@ struct efi_disk_obj {
>> /* EFI Interface Media descriptor struct, referenced by ops */
>> struct efi_block_io_media media;
>> /* EFI device path to this block device */
>> -   struct efi_device_path_file_path *dp;
>> +   struct efi_device_path *dp;
>> +   /* partition # */
>> +   unsigned part;
>> /* Offset into disk for simple partitions */
>> lbaint_t offset;
>> /* Internal block device */
>> -   const struct blk_desc *desc;
>> +   struct blk_desc *desc;
>>   };
>> static efi_status_t EFIAPI efi_disk_reset(struct efi_block_io *this,
>> @@ -172,26 +174,26 @@ static const struct efi_block_io
>> block_io_disk_template = {
>> static void efi_disk_add_dev(const char *name,
>>  const char *if_typename,
>> -const struct blk_desc *desc,
>> +struct blk_desc *desc,
>>  int dev_index,
>> -lbaint_t offset)
>> +lbaint_t offset,
>> +unsigned part)
>>   {
>> struct efi_disk_obj *diskobj;
>> -   struct efi_device_path_file_path *dp;
>> -   int objlen = sizeof(*diskobj) + (sizeof(*dp) * 2);
>> /* Don't add empty devices */
>> if (!desc->lba)
>> return;
>>   - diskobj = calloc(1, objlen);
>> +   diskobj = calloc(1, sizeof(*diskobj));
>> /* Fill in object data */
>> -   dp = (void *)[1];
>> +   diskobj->dp = efi_dp_from_part(desc, part);
>> +   diskobj->part = part;
>> diskobj->parent.protocols[0].guid = _block_io_guid;
>> diskobj->parent.protocols[0].protocol_interface = >ops;
>> diskobj->parent.protocols[1].guid = _guid_device_path;
>> -   diskobj->parent.protocols[1].protocol_interface = dp;
>> +   diskobj->parent.protocols[1].protocol_interface = diskobj->dp;
>> diskobj->parent.handle = diskobj;
>> diskobj->ops = block_io_disk_template;
>> diskobj->ifname = if_typename;
>> @@ -207,17 +209,6 @@ static void efi_disk_add_dev(const char *name,
>> diskobj->media.last_block = desc->lba - offset;
>> diskobj->ops.media = >media;
>>   - /* Fill in device path */
>> -   diskobj->dp = dp;
>> -   dp[0].dp.type = DEVICE_PATH_TYPE_MEDIA_DEVICE;
>> -   dp[0].dp.sub_type = DEVICE_PATH_SUB_TYPE_FILE_PATH;
>> -   dp[0].dp.length = sizeof(*dp);
>> -   ascii2unicode(dp[0].str, name);
>> -
>> -   dp[1].dp.type = DEVICE_PATH_TYPE_END;
>> -   dp[1].dp.sub_type = DEVICE_PATH_SUB_TYPE_END;
>> -   dp[1].dp.length = sizeof(*dp);
>> -
>> /* Hook up to the device list */
>> list_add_tail(>parent.link, _obj_list);
>>   }
>> @@ -236,14 

Re: [U-Boot] [PATCH v2] arm: omap: Fix 'get_device_type()' for OMAP34XX

[Derald Woods]

On Thu, Aug 10, 2017 at 7:50 AM, Derald Woods 
wrote:

> On Thu, Aug 10, 2017 at 7:25 AM, Derald Woods 
> wrote:
>
>> On Mon, Aug 7, 2017 at 5:19 PM, Derald Woods 
>> wrote:
>>
>>> On Mon, Aug 7, 2017 at 7:41 AM, Tom Rini  wrote:
>>>
 On Mon, Aug 07, 2017 at 07:35:30AM -0500, Derald Woods wrote:
 > On Mon, Jul 31, 2017 at 7:41 AM, Derald D. Woods <
 woods.techni...@gmail.com>
 > wrote:
 >
 > > Fixes: 00bbe96ebabb ("arm: omap: Unify get_device_type() function")
 > >
 > > The control status register value is embedded in a structure
 somewhere
 > > in SRAM, with the last refactoring effort. This patch allows OMAP3
 EVM
 > > (TMDSEVM3530) to boot again using the known control register base
 and
 > > offset for 'readl', for the OMAP34XX case.
 > >
 > > Signed-off-by: Derald D. Woods 
 > >
 > > ---
 > > Changes in v2:
 > > - Added 'signed-off-by'
 > > - Updated description
 > >
 > > ---
 > >  arch/arm/mach-omap2/sysinfo-common.c | 4 
 > >  1 file changed, 4 insertions(+)
 > >
 > > diff --git a/arch/arm/mach-omap2/sysinfo-common.c
 > > b/arch/arm/mach-omap2/sysinfo-common.c
 > > index 1dc7051ab3..3955e803ad 100644
 > > --- a/arch/arm/mach-omap2/sysinfo-common.c
 > > +++ b/arch/arm/mach-omap2/sysinfo-common.c
 > > @@ -16,6 +16,10 @@
 > >   */
 > >  u32 get_device_type(void)
 > >  {
 > > +#if defined(CONFIG_OMAP34XX)
 > > +   return (readl(OMAP34XX_CTRL_BASE + 0x2f0) &
 DEVICE_TYPE_MASK) >>
 > > +   DEVICE_TYPE_SHIFT;
 > > +#endif
 > > return (readl((*ctrl)->control_status) & DEVICE_TYPE_MASK)
 >>
 > > DEVICE_TYPE_SHIFT;
 > >  }
 >
 > ​Is there any​ comment or concern with this patch? It was the simplest
 > means to get OMAP35XX booting again and still keep the original patch.
 > Basically it avoids the pointer to the OMAP_SRAM_SCRATCH_SYS_CTRL
 located
 > structure as now defined in "arch/arm/mach-omap2/omap3/hw_data.c".
 OMAP3
 > has a larger active SOC base than just OMAP36XX and greater. Was there
 > anything really broken with 'get_device_type()' previously?

 Is the pointer value wrong for 35xx?  The problem, such as it was, was
 having the same function duplicated in a number of places, and needing
 to make it more easily / readily available (rather than duplicated
 again) for some additional patches.  I'd really rather not introduce
 an #if here unless we really have no other choice.  Thanks!

 --
 Tom

>>>
>>> ​I will examine/debug the new 'get_device_type()' source code again
>>> tonight. ‎Without the patch, I have two OMAP3530 boards that do not boot at
>>> all.
>>>
>> ​​
>>
>> Derald​
>> ​
>>
>> In "arch/arm/mach-omap2/omap3/board.c", the following routines call
>> 'get_device_type':
>> - v7_arch_cp15_set_l2aux_ctrl  (called from
>> "arch/arm/cpu/armv7/start.S")
>> - v7_arch_cp15_set_acr (called from
>> "arch/arm/cpu/armv7/start.S")
>> - omap3_invalidate_l2_cache_secure (called from "board.c" 's_init')
>> - try_unlock_memory(called from "board.c" 's_init')
>>
>> Each one of these calls to 'get_device_type' seems to have a purpose
>> (i.e. ERRATA or setup). What it highlights is the difference in usage from
>> OMAP36XX, AM33XX, and newer. The SRAM usage, L2 cache and call ordering are
>> likely factors here. ​Figuring out the implications for OMAP34XX will take
>> time. But you need to have boards that boot to address those issues. So
>> 'get_device_type' usage, for OMAP34XX, is not strictly a "Apples to Apples"
>> type comparison. For now I can proceed with an "out-of-tree" patch, since
>> it is small. Let me know if there is something that I am missing here.
>>
>> Derald
>>
>
> ​
> Based on all of the above, I think the "#if" is still the simplest path to
> booting.
>
> Derald
>
>
>
​Are there any further thoughts about OMAP34XX calling 'get_device_type()'
from "start.S"?

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

Re: [U-Boot] [PATCH v3 1/3] armv8: ls1088a: Add NXP LS1088A SoC support

[Prabhakar Kushwaha]

> -Original Message-
> From: Ashish Kumar [mailto:ashish.ku...@nxp.com]
> Sent: Friday, August 11, 2017 12:54 PM
> To: u-boot@lists.denx.de
> Cc: York Sun ; Ashish Kumar ;
> Alison Wang ; Prabhakar Kushwaha
> ; Raghav Dogra ;
> Shaohui Xie 
> Subject: [PATCH v3 1/3] armv8: ls1088a: Add NXP LS1088A SoC support
> 
> The QorIQ LS1088A processor is built on the Layerscape
> architecture combining eight ARM A53 processor cores
> with advanced, high-performance datapath acceleration
> and networks, peripheral interfaces required for
> networking, wireless infrastructure, and general-purpose
> embedded applications.
> 
> LS1088A is compliant to the Layerscape Chassis Generation 3.
> 
> Features summary:
>  - Eight 32-bit / 64-bit ARM v8 Cortex-A53 CPUs
>  - Cores are in 2 cluster of 4-cores each
>  - Cache coherent interconnect (CCI-400)
>  - One 64-bit DDR4 SDRAM memory controller with ECC
>  - Data path acceleration architecture 2.0 (DPAA2)
>  - Ethernet interfaces: SGMIIs, RGMIIs, QSGMIIs, XFIs
>  - QSPI, IFC, 3 PCIe, 1 SATA, 2 USB, 1 SDXC, 2 DUARTs etc
> 
> Signed-off-by: Alison Wang 
> Signed-off-by: Prabhakar Kushwaha 
> Signed-off-by: Ashish Kumar 
> Signed-off-by: Raghav Dogra 
> Signed-off-by: Shaohui Xie 
> ---
> 
> v2:
>  Fix indentaion in commit msg
>  Separate RDB and Si specific file
>  Move Macros to Kconfig
> 
> v3:
> 1.Re-based on top of
>   commit d529124fdcf941c34074fd1ce600f4b1b4a7dd07
>   Merge: f0ca30f 6a5691e
>   Author: Tom Rini 
>   Date:   Tue Aug 8 17:06:19 2017 -0400
> 
> Merge git://git.denx.de/u-boot-x86
> 
> 2.Incorporate review comments on v2
>   Clean up done
> 
> 3.Migrate changes from ls1088ardb_stream_id.h to stream_id_lsch3.h
> 
>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig  |  39 ++-
>  arch/arm/cpu/armv8/fsl-layerscape/Makefile |   4 +
>  .../cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c|  10 ++
>  arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S   |   6 +-
>  arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c | 126
> +
>  arch/arm/cpu/armv8/fsl-layerscape/soc.c|   5 +
>  arch/arm/dts/fsl-ls1088a.dtsi  |  78 +
>  arch/arm/include/asm/arch-fsl-layerscape/config.h  |  62 +-
>  arch/arm/include/asm/arch-fsl-layerscape/cpu.h |   4 +
>  .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |   3 +-
>  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  11 ++
>  arch/arm/include/asm/arch-fsl-layerscape/soc.h |   4 +
>  .../asm/arch-fsl-layerscape/stream_id_lsch3.h  |  14 +++
>  drivers/ddr/fsl/util.c |   2 +-
>  drivers/net/ldpaa_eth/Makefile |   1 +
>  drivers/net/ldpaa_eth/ls1088a.c|  87 ++


Add SoC details in arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc

>  16 files changed, 447 insertions(+), 9 deletions(-)
>  create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c
>  create mode 100644 arch/arm/dts/fsl-ls1088a.dtsi
>  create mode 100644 drivers/net/ldpaa_eth/ls1088a.c
> 

> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> index 1132969..a3c7490 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> @@ -49,6 +49,29 @@ config ARCH_LS1046A
>   select BOARD_EARLY_INIT_F
>   imply SCSI
> 
> +config ARCH_LS1088A
> + bool
> + select ARMV8_SET_SMPEN
> + select FSL_LSCH3
> + select SYS_FSL_DDR
> + select SYS_FSL_DDR_LE
> + select SYS_FSL_DDR_VER_50
> + select SYS_FSL_ERRATUM_A009803
> + select SYS_FSL_ERRATUM_A009942
> + select SYS_FSL_ERRATUM_A010165
> + select SYS_FSL_ERRATUM_A008511
> + select SYS_FSL_ERRATUM_A008850
> + select SYS_FSL_HAS_CCI400
> + select SYS_FSL_HAS_DDR4
> + select SYS_FSL_HAS_SEC
> + select SYS_FSL_SEC_COMPAT_5
> + select SYS_FSL_SEC_LE
> + select SYS_FSL_SRDS_1
> + select SYS_FSL_SRDS_2
> + select FSL_TZASC_1
> + select ARCH_EARLY_INIT_R
> + select BOARD_EARLY_INIT_F
> +
>  config ARCH_LS2080A
>   bool
>   select ARMV8_SET_SMPEN
> @@ -60,6 +83,7 @@ config ARCH_LS2080A
>   select SYS_FSL_DDR
>   select SYS_FSL_DDR_LE
>   select SYS_FSL_DDR_VER_50
> + select SYS_FSL_HAS_CCN504
>   select SYS_FSL_HAS_DP_DDR
>   select SYS_FSL_HAS_SEC
>   select SYS_FSL_HAS_DDR4
> @@ -98,7 +122,7 @@ config FSL_LSCH3
> 
>  config FSL_MC_ENET
>   bool "Management Complex network"
> - depends on ARCH_LS2080A
> + depends on ARCH_LS2080A || ARCH_LS1088A
>   default y
>   select RESV_RAM
>   help
> @@ -114,6 +138,7 @@ config FSL_PCIE_COMPAT
>   default 

[U-Boot] [PATCH 2/3] imx: Enable ACTLR.SMP bit for Cortex-A7 platforms

[Peng Fan]

According to the Cortex-A7 TRM, for ACTLR.SMP bit "You must ensure this bit
is set to 1 before the caches and MMU are enabled, or any cache and TLB
maintenance operations are performed".
ROM sets this bit in normal boot flow, but when in serial download mode,
it is not set. Here we set it for mx6/7/7ulp. The code will check whether
the PE is A7 or not.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
Cc: Fabio Estevam 
---
 arch/arm/include/asm/mach-imx/sys_proto.h |  1 +
 arch/arm/mach-imx/cache.c | 28 
 arch/arm/mach-imx/mx6/soc.c   |  2 ++
 arch/arm/mach-imx/mx7/soc.c   |  9 ++---
 arch/arm/mach-imx/mx7ulp/soc.c|  2 ++
 5 files changed, 35 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h 
b/arch/arm/include/asm/mach-imx/sys_proto.h
index 046df62..26db1cc 100644
--- a/arch/arm/include/asm/mach-imx/sys_proto.h
+++ b/arch/arm/include/asm/mach-imx/sys_proto.h
@@ -87,6 +87,7 @@ static inline u8 imx6_is_bmode_from_gpr9(void)
 u32 imx6_src_get_boot_mode(void);
 #endif /* CONFIG_MX6 */
 
+void enable_actlr_smp(void);
 u32 get_nr_cpus(void);
 u32 get_cpu_rev(void);
 u32 get_cpu_speed_grade_hz(void);
diff --git a/arch/arm/mach-imx/cache.c b/arch/arm/mach-imx/cache.c
index c5279a7..e02f1a5 100644
--- a/arch/arm/mach-imx/cache.c
+++ b/arch/arm/mach-imx/cache.c
@@ -10,6 +10,34 @@
 #include 
 #include 
 
+void enable_actlr_smp(void)
+{
+   uint32_t val;
+
+   /* Read MIDR */
+   asm volatile ("mrc p15, 0, %0, c0, c0, 0\n\t" : "=r"(val));
+   val = (val >> 4);
+   val &= 0xf;
+
+   /* Only set the SMP for Cortex A7 */
+   if (val == 0x7) {
+   /* Read auxiliary control register */
+   asm volatile ("mrc p15, 0, %0, c1, c0, 1\n\t" : "=r"(val));
+
+   if (val & (1 << 6))
+   return;
+
+   /* Enable SMP */
+   val |= (1 << 6);
+
+   /* Write auxiliary control register */
+   asm volatile ("mcr p15, 0, %0, c1, c0, 1\n\t" : : "r"(val));
+
+   DSB;
+   ISB;
+   }
+}
+
 #ifndef CONFIG_SYS_DCACHE_OFF
 void enable_caches(void)
 {
diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
index af31673..0ef4b29 100644
--- a/arch/arm/mach-imx/mx6/soc.c
+++ b/arch/arm/mach-imx/mx6/soc.c
@@ -576,6 +576,8 @@ void s_init(void)
u32 mask528;
u32 reg, periph1, periph2;
 
+   enable_actlr_smp();
+
if (is_mx6sx() || is_mx6ul() || is_mx6ull())
return;
 
diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index ec74b4c..4307ae0 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -447,13 +447,8 @@ int mmc_get_env_dev(void)
 
 void s_init(void)
 {
-#if !defined CONFIG_SPL_BUILD
-   /* Enable SMP mode for CPU0, by setting bit 6 of Auxiliary Ctl reg */
-   asm volatile(
-   "mrc p15, 0, r0, c1, c0, 1\n"
-   "orr r0, r0, #1 << 6\n"
-   "mcr p15, 0, r0, c1, c0, 1\n");
-#endif
+   enable_actlr_smp();
+
/* clock configuration. */
clock_init();
 
diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
index 454665a..71bfe36 100644
--- a/arch/arm/mach-imx/mx7ulp/soc.c
+++ b/arch/arm/mach-imx/mx7ulp/soc.c
@@ -100,6 +100,8 @@ void init_wdog(void)
 
 void s_init(void)
 {
+   enable_actlr_smp();
+
/* Disable wdog */
init_wdog();
 
-- 
2.6.2

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

[U-Boot] [PATCH 1/3] imx: mx7: fix build warning when CONFIG_IMX_RDC not enabled

[Peng Fan]

Fix build warning when CONFIG_IMX_RDC not defined in defconfig.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
Cc: Fabio Estevam 
---
 arch/arm/mach-imx/mx7/soc.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 4cf977e..ec74b4c 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -31,7 +31,7 @@ U_BOOT_DEVICE(imx7_thermal) = {
 };
 #endif
 
-#ifdef CONFIG_IMX_RDC
+#if CONFIG_IS_ENABLED(IMX_RDC)
 /*
  * In current design, if any peripheral was assigned to both A7 and M4,
  * it will receive ipg_stop or ipg_wait when any of the 2 platforms enter
@@ -245,8 +245,9 @@ int arch_cpu_init(void)
mxs_dma_init();
 #endif
 
-   if (IS_ENABLED(CONFIG_IMX_RDC))
-   isolate_resource();
+#if CONFIG_IS_ENABLED(IMX_RDC)
+   isolate_resource();
+#endif
 
return 0;
 }
-- 
2.6.2

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

[U-Boot] [PATCH 3/3] mx7: add epdc qos settings

[Peng Fan]

This EPDC/EPXP QoS setting is needed for EPDC stress test to pass.

Signed-off-by: Peng Fan 
Cc: Stefano Babic 
Cc: Fabio Estevam 
---
 arch/arm/include/asm/arch-mx7/imx-regs.h |  5 +
 arch/arm/mach-imx/mx7/soc.c  | 38 
 2 files changed, 43 insertions(+)

diff --git a/arch/arm/include/asm/arch-mx7/imx-regs.h 
b/arch/arm/include/asm/arch-mx7/imx-regs.h
index aab3a9a..a6b2091 100644
--- a/arch/arm/include/asm/arch-mx7/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx7/imx-regs.h
@@ -152,6 +152,11 @@
 #define IP2APB_AXIMON_IPS_BASE_ADDR (AIPS2_OFF_BASE_ADDR+0x1E)
 #define QOSC_IPS_BASE_ADDR  (AIPS2_OFF_BASE_ADDR+0x1F)
 
+#define REGS_QOS_BASE  QOSC_IPS_BASE_ADDR
+#define REGS_QOS_EPDC  (QOSC_IPS_BASE_ADDR + 0x3400)
+#define REGS_QOS_PXP0  (QOSC_IPS_BASE_ADDR + 0x2C00)
+#define REGS_QOS_PXP1  (QOSC_IPS_BASE_ADDR + 0x3C00)
+
 /* AIPS_TZ#3  - Global enable (0) */
 #define ECSPI1_BASE_ADDR(AIPS_TZ3_BASE_ADDR+0x2)
 #define ECSPI2_BASE_ADDR(AIPS_TZ3_BASE_ADDR+0x3)
diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 4307ae0..6b37848 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -230,6 +230,42 @@ static void imx_enet_mdio_fixup(void)
}
 }
 
+static void set_epdc_qos(void)
+{
+   /* Disable clkgate & soft_reset */
+   writel(0, REGS_QOS_BASE);
+   /* Enable all masters */
+   writel(0, REGS_QOS_BASE + 0x60);
+   /* Disable clkgate & soft_reset */
+   writel(0, REGS_QOS_EPDC);
+   /* Disable clkgate & soft_reset */
+   writel(0, REGS_QOS_PXP0);
+   /* Disable clkgate & soft_reset */
+   writel(0, REGS_QOS_PXP1);
+   /* WR, init = 7 with red flag */
+   writel(0x0f020722, REGS_QOS_EPDC + 0xd0);
+   /* RD,  init = 7 with red flag */
+   writel(0x0f020722, REGS_QOS_EPDC + 0xe0);
+   /* OT_CTRL_EN =1 */
+   writel(1, REGS_QOS_PXP0);
+   /* OT_CTRL_EN =1 */
+   writel(1, REGS_QOS_PXP1);
+   /* WR,  init = 2 with red flag */
+   writel(0x0f020222, REGS_QOS_PXP0 + 0x50);
+   /* WR,  init = 2 with red flag */
+   writel(0x0f020222, REGS_QOS_PXP1 + 0x50);
+   /* rD,  init = 2 with red flag */
+   writel(0x0f020222, REGS_QOS_PXP0 + 0x60);
+   /* rD,  init = 2 with red flag */
+   writel(0x0f020222, REGS_QOS_PXP1 + 0x60);
+   /* tOTAL,  init = 4 with red flag */
+   writel(0x0f020422, REGS_QOS_PXP0 + 0x70);
+   /* TOTAL,  init = 4 with red flag */
+   writel(0x0f020422, REGS_QOS_PXP1 + 0x70);
+   /* EPDC AW/AR CACHE ENABLE */
+   writel(0xe080, IOMUXC_GPR_BASE_ADDR + 0x0034);
+}
+
 int arch_cpu_init(void)
 {
init_aips();
@@ -240,6 +276,8 @@ int arch_cpu_init(void)
 
imx_enet_mdio_fixup();
 
+   set_epdc_qos();
+
 #ifdef CONFIG_APBH_DMA
/* Start APBH DMA */
mxs_dma_init();
-- 
2.6.2

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

Re: [U-Boot] [PATCH v1 15/15] efi_loader: add bootmgr

[Rob Clark]

On Sat, Aug 12, 2017 at 9:10 AM, Alexander Graf  wrote:
>
>
> On 10.08.17 20:29, Rob Clark wrote:
>>
>> Similar to a "real" UEFI implementation, the bootmgr looks at the
>> BootOrder and Boot variables to try to find an EFI payload to load
>> and boot.  This is added as a sub-command of bootefi.
>>
>> The idea is that the distro bootcmd would first try loading a payload
>> via the bootmgr, and then if that fails (ie. first boot or corrupted
>> EFI variables) it would fallback to loading bootaa64.efi.  (Which
>> would then load fallback.efi which would look for \EFI\*\boot.csv and
>> populate BootOrder and Boot based on what it found.)
>>
>> Signed-off-by: Rob Clark 
>> ---
>>   cmd/bootefi.c |  48 ++-
>>   include/config_distro_bootcmd.h   |   5 ++
>>   include/efi_api.h |   4 +
>>   include/efi_loader.h  |   6 ++
>>   lib/efi_loader/Makefile   |   2 +-
>>   lib/efi_loader/efi_bootmgr.c  | 169
>> ++
>>   lib/efi_loader/efi_boottime.c |   6 +-
>>   lib/efi_loader/efi_image_loader.c |   1 +
>>   8 files changed, 235 insertions(+), 6 deletions(-)
>>   create mode 100644 lib/efi_loader/efi_bootmgr.c
>>
>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>> index 80f52e9e35..02a0dd159b 100644
>> --- a/cmd/bootefi.c
>> +++ b/cmd/bootefi.c
>> @@ -219,6 +219,36 @@ exit:
>> return ret;
>>   }
>>   +static int do_bootefi_bootmgr_exec(unsigned long fdt_addr)
>> +{
>> +   struct efi_device_path *device_path, *file_path;
>> +   void *addr;
>> +   efi_status_t r;
>> +
>> +   /* Initialize and populate EFI object list */
>> +   if (!efi_obj_list_initalized)
>> +   efi_init_obj_list();
>> +
>> +   /*
>> +* gd lives in a fixed register which may get clobbered while we
>> execute
>> +* the payload. So save it here and restore it on every callback
>> entry
>> +*/
>> +   efi_save_gd();
>> +
>> +   addr = efi_bootmgr_load(_path, _path);
>> +   if (!addr)
>> +   return 1;
>> +
>> +   printf("## Starting EFI application at %p ...\n", addr);
>> +   r = do_bootefi_exec(addr, (void*)fdt_addr, device_path,
>> file_path);
>> +   printf("## Application terminated, r = %lu\n",
>> +  r & ~EFI_ERROR_MASK);
>> +
>> +   if (r != EFI_SUCCESS)
>> +   return 1;
>> +
>> +   return 0;
>> +}
>> /* 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[])
>> @@ -237,7 +267,14 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int
>> argc, char * const argv[])
>> memcpy((char *)addr, __efi_hello_world_begin, size);
>> } else
>>   #endif
>> -   {
>> +   if (!strcmp(argv[1], "bootmgr")) {
>> +   unsigned long fdt_addr = 0;
>> +
>> +   if (argc > 2)
>> +   fdt_addr = simple_strtoul(argv[2], NULL, 16);
>> +
>> +   return do_bootefi_bootmgr_exec(fdt_addr);
>> +   } else {
>> saddr = argv[1];
>> addr = simple_strtoul(saddr, NULL, 16);
>> @@ -270,7 +307,11 @@ static char bootefi_help_text[] =
>> "hello\n"
>> "  - boot a sample Hello World application stored within U-Boot"
>>   #endif
>> -   ;
>> +   "bootmgr [fdt addr]\n"
>> +   "  - load and boot EFI payload based on BootOrder/Boot
>> variables.\n"
>> +   "\n"
>> +   "If specified, the device tree located at 
>> gets\n"
>> +   "exposed as EFI configuration table.\n";
>>   #endif
>> U_BOOT_CMD(
>> @@ -308,6 +349,9 @@ void efi_set_bootdev(const char *dev, const char
>> *devnr, const char *path)
>>   #endif
>> }
>>   + if (!path)
>> +   return;
>> +
>> if (strcmp(dev, "Net")) {
>> /* Add leading / to fs paths, because they're absolute */
>> snprintf(filename, sizeof(filename), "/%s", path);
>> diff --git a/include/config_distro_bootcmd.h
>> b/include/config_distro_bootcmd.h
>> index d8dab8e46a..94ccab02d2 100644
>> --- a/include/config_distro_bootcmd.h
>> +++ b/include/config_distro_bootcmd.h
>> @@ -112,6 +112,11 @@
>> #define BOOTENV_SHARED_EFI
>> \
>> "boot_efi_binary="
>> \
>> +   "if fdt addr ${fdt_addr_r}; then "
>> \
>> +   "bootefi bootmgr ${fdt_addr_r};"
>> \
>
>
> This is too late. At this point you already checked that there indeed is a
> fallback binary. Since the bootmgr target actually knows which device it
> loads itself from, it can occur way before in the boot chain.
>
> Maybe we should just add a new boot_target for bootmgr. That way it
> naturally fits into the distro boot flow. You could then add a
> BOOTENV_DEV_BOOTMGR and simply run it from there.
>
> The only thing missing in that case is the device tree override - hmm...
>

Re: [U-Boot] [PATCH v1 02/15] fs/fat: implement readdir

[Rob Clark]

On Sat, Aug 12, 2017 at 8:17 AM, Alexander Graf  wrote:
>
>
> On 10.08.17 20:29, Rob Clark wrote:
>>
>> Yes, this is super-hacky.  The FAT code is quite ugly, and this doesn't
>> improve things.  But it doesn't make it significantly worse either.  The
>> better option would be a massive FAT re-write to get rid of the hacky
>> way that fat_file_ls() works.  Volunteers welcome.
>>
>> Signed-off-by: Rob Clark 
>
>
> What concerns me the most in patch 1/15 and this patch is the limited scope.
> Yes, you make readdir work for FAT, but all other file systems are still
> unimplemented. In fact, they're even all still implementing their own
> hand-written ls logic.
>
> One of the goals of the efi_loader code is to integrate with U-Boot as much
> as possible, to reuse code where we can. And if current interfaces are
> terrible, I think it's ok to just replace them for something that fits
> everyone's needs better.
>
> How feasible do you think it would be to implement an ls function based on
> readdir and just convert all file systems to it, completely replacing the
> current (quite crude) ls logic?

So I went ahead and re-wrote the fat directory traversal[1].  I should
be posting to list in the next day or two but still want to make a few
small cleanups.  (And to get rid of some hacks in efi_file, I think I
need to add an fs_isdir() too :-/)

As far as the various other filesys's, I agree that a generic ls would
be a nice goal.  But the scope of the efi_loader patchset has already
expanded way too much, and at this point I'm pretty much limited by
what I can finish this weekend.  At the end of the day, FAT is all
that UEFI expects, so I think it is fine to let the other filesystems
catch up on their own schedule.

I could write a generic ls helper, and just plug it in for FAT, which
could be re-used later when other filesys's gain readdir support.

BR,
-R

[1] https://github.com/robclark/u-boot/commits/readdir
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 3/3] efi_loader: implement OpenProtocolInformation

[Alexander Graf]

On 05.08.17 22:32, Heinrich Schuchardt wrote:

efi_open_protocol_information provides the agent and controller
handles as well as the attributes and open count of an protocol
on a handle.

Cc: Rob Clark 
Signed-off-by: Heinrich Schuchardt 


Do you have an application that leverages these interfaces? Would it be 
possible to add that application to our travis tests?



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

Re: [U-Boot] [PATCH v3 1/3] efi_loader: write protocol GUID in OpenProtocol

[Alexander Graf]

On 11.08.17 18:00, Heinrich Schuchardt wrote:

On 08/11/2017 12:11 PM, Alexander Graf wrote:



On 05.08.17 21:32, Heinrich Schuchardt wrote:

To understand what happens in OpenProtocol it is necessary to know
the protocol interface GUID. Let's write a debug message.

Using uuid_guid_get_str would be quite clumsy for this purpose.
This would involve evaluating _DEBUG which probably should not be used
outside common.h.

Cc: Rob Clark 
Signed-off-by: Heinrich Schuchardt 


I agree with Rob that a printf extension would be the nicest way to go
here. We could then just use that instead of the %p in EFI_ENTRY() that
we have today.


Alex



Hello Alex,

I am aware of
[PATCH 4/5] vsprintf.c: add GUID printing,

I just wonder if you wnat to take this patch series as is and we modify
EFI_PRINT_GUID afterwards

or

we I shall remove GUID printing and resend the patch series without it.


I think it's best to keep changes isolated to not stall anyone. Since 
this is really just a debug enhancement, I think we're best off to drop 
the GUID printing in this patch set.



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

Re: [U-Boot] [PATCH v3 2/3] efi_loader: open_info in OpenProtocol, CloseProtocol

[Alexander Graf]

On 05.08.17 22:32, Heinrich Schuchardt wrote:

efi_open_protocol and close_protocol have to keep track of
opened protocols.

So we add an array open_info to each protocol of each handle.

Cc: Rob Clark 
Signed-off-by: Heinrich Schuchardt 
---
v3:
use EFI_CALL to avoid wrapper for efi_disconnect_controller
use list_for_each_entry
move variable declarations out of loops
v2:
new patch
---
  include/efi_loader.h  |   1 +
  lib/efi_loader/efi_boottime.c | 164 +++---
  2 files changed, 155 insertions(+), 10 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 553c615f11..222b251a38 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -88,6 +88,7 @@ extern unsigned int __efi_runtime_rel_start, 
__efi_runtime_rel_stop;
  struct efi_handler {
const efi_guid_t *guid;
void *protocol_interface;
+   struct efi_open_protocol_info_entry open_info[4];
  };
  
  /*

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index ebb557abb2..e969814476 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -898,23 +898,78 @@ static efi_status_t EFIAPI efi_connect_controller(
return EFI_EXIT(EFI_NOT_FOUND);
  }
  
-static efi_status_t EFIAPI efi_disconnect_controller(void *controller_handle,

-void *driver_image_handle,
-void *child_handle)
+static efi_status_t EFIAPI efi_disconnect_controller(
+   void *controller_handle,
+   void *driver_image_handle,
+   void *child_handle)
  {
EFI_ENTRY("%p, %p, %p", controller_handle, driver_image_handle,
  child_handle);
return EFI_EXIT(EFI_INVALID_PARAMETER);
  }
  
+static efi_status_t efi_close_protocol_int(struct efi_handler *protocol,


Please either wrap _ext or use EFI_CALL :).


+  void *agent_handle,
+  void *controller_handle)
+{
+   size_t i;
+   struct efi_open_protocol_info_entry *open_info;
+
+   for (i = 0; i < ARRAY_SIZE(protocol->open_info); ++i) {
+   open_info = >open_info[i];
+
+   if (!open_info->open_count)
+   continue;
+
+   if (open_info->agent_handle == agent_handle &&
+   open_info->controller_handle ==
+   controller_handle) {
+   open_info->open_count--;
+   return EFI_SUCCESS;
+   }
+   }
+   return EFI_NOT_FOUND;
+}
+
  static efi_status_t EFIAPI efi_close_protocol(void *handle,
  efi_guid_t *protocol,
  void *agent_handle,
  void *controller_handle)
  {
+   struct efi_object *efiobj;
+   size_t i;
+   efi_status_t r = EFI_NOT_FOUND;
+
EFI_ENTRY("%p, %p, %p, %p", handle, protocol, agent_handle,
  controller_handle);
-   return EFI_EXIT(EFI_NOT_FOUND);
+
+   if (!handle || !protocol || !agent_handle) {
+   r = EFI_INVALID_PARAMETER;
+   goto out;
+   }
+
+   EFI_PRINT_GUID("protocol:", protocol);
+
+   list_for_each_entry(efiobj, _obj_list, link) {
+   if (efiobj->handle != handle)
+   continue;
+
+   for (i = 0; i < ARRAY_SIZE(efiobj->protocols); i++) {
+   struct efi_handler *handler = >protocols[i];
+   const efi_guid_t *hprotocol = handler->guid;
+   if (!hprotocol)
+   continue;
+   if (!guidcmp(hprotocol, protocol)) {
+   r = efi_close_protocol_int(handler,
+  agent_handle,
+  controller_handle);
+   goto out;
+   }
+   }
+   goto out;
+   }
+out:
+   return EFI_EXIT(r);
  }
  
  static efi_status_t EFIAPI efi_open_protocol_information(efi_handle_t handle,

@@ -1119,6 +1174,96 @@ static void EFIAPI efi_set_mem(void *buffer, unsigned 
long size, uint8_t value)
memset(buffer, value, size);
  }
  
+static efi_status_t efi_open_protocol_int(


Same here.


Alex


+   struct efi_handler *protocol,
+   void **protocol_interface, void *agent_handle,
+   void *controller_handle, uint32_t attributes)
+{
+   bool opened_exclusive = false;
+   bool opened_by_driver = false;
+   int i;
+   

Re: [U-Boot] [U-Boot, v3] omap3: evm: Update board, defconfig, and maintainer file

[Tom Rini]

On Sun, Aug 06, 2017 at 12:00:21AM -0500, Derald D. Woods wrote:

> This patch brings the OMAP3 EVM to a bootable state, on master, as of
> v2017.09-rc1.
> 
> Signed-off-by: Derald D. Woods 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2,38/42] Convert CONFIG_CMD_UUID to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:35:02PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_UUID
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 33/42] Convert CONFIG_CMD_THOR_DOWNLOAD to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:57PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_THOR_DOWNLOAD
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 13/42] Convert CONFIG_CMD_PCMCIA to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:37PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_PCMCIA
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2,12/42] Kconfig; Drop CONFIG_IDE_TI_CARDBUS and associated driver

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:36PM -0600, Simon Glass wrote:

> This driver is not used by any board. Drop it.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 26/42] Convert CONFIG_CMD_SPL_WRITE_SIZE to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:50PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_SPL_WRITE_SIZE
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 30/42] Convert CONFIG_CMD_TCA642X to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:54PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_TCA642X
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 15/42] Kconfig: Convert CMD_READ to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:39PM -0600, Simon Glass wrote:

> Convert this option and enable it in sandbox. Also correct a bug which
> was introduced with the block-device driver model conversion.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 42/42] README: Drop information about commands

[Tom Rini]

On Fri, Aug 04, 2017 at 04:35:06PM -0600, Simon Glass wrote:

> Most of this is duplicated in Kconfig help. Add some of that which is not,
> and remove the help from the README.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 31/42] Convert CONFIG_CMD_TERMINAL to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:55PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_TERMINAL
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 37/42] Convert CONFIG_CMD_UNIVERSE to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:35:01PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_UNIVERSE
> 
> Since no board uses this, perhaps we should drop this command?
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] OMAP3: omap3logic: Fix DDR Pin Mux

[Tom Rini]

On Tue, Aug 08, 2017 at 09:00:27AM -0500, Adam Ford wrote:

> The 512 MB DDR version of SOM's use CS0 and CS1.  CS1 is not correctly
> setup in the pin muxing.  This causes erratic behavior on suspend/resume
> 
> This fix has been tested on both 256 and 512 MB DDR versions.
> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/board/logicpd/omap3som/omap3logic.c 
> b/board/logicpd/omap3som/omap3logic.c
> index de6a060..af20339 100644

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] travis-ci: Emulate 'make tests'

[Tom Rini]

On Mon, Aug 07, 2017 at 03:24:50PM -0400, Tom Rini wrote:

> The 'tests' target will run sandbox, sandbox_spl and sandbox_flattree in
> test.py and in the case of sandbox_spl ensure that we just run the
> specific tests for that build.  Update our matrix to perform similar
> test.py runs.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 36/42] Convert CONFIG_CMD_TSI148 to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:35:00PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_TSI148
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2,32/42] Kconfig: Drop CONFIG_CMD_TFTP

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:56PM -0600, Simon Glass wrote:

> This is not a valid CONFIG option. Drop it.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 16/42] Convert CONFIG_CMD_REGINFO to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:40PM -0600, Simon Glass wrote:

> From: Christophe Leroy 
> 
> This patch converts CONFIG_CMD_REGINFO to Kconfig
> 
> Signed-off-by: Christophe Leroy 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

With a few more changes to the imply logic to not add this on boards
that didn't have it before, applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2,24/42] Convert CONFIG_CMD_SPL to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:48PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_SPL
> 
> Note that trats does not actually use SPL, so this option can no-longer be
> set.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] board: ks2: README: Update NAND wording

[Tom Rini]

On Wed, Aug 09, 2017 at 09:29:22PM -0500, Cooper Jr., Franklin wrote:

> Traditional KS2 devices supported NAND via the AEMIF peripheral. However,
> 66AK2G doesn't use the AEMIF but rather the GPMC for NAND. Therefore,
> clarify some statements to indicate only certain devices have AEMIF and
> in other places just say NAND instead of AEMIF NAND
> 
> Signed-off-by: Franklin S Cooper Jr 
> Acked-by: Roger Quadros 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2,27/42] Kconfig: Sort the memory commands

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:51PM -0600, Simon Glass wrote:

> These are currently not quite in alphabetical order. Before adding more,
> sort them. Not all options have a CMD_ prefix, so ignore that when
> sorting.
> 
> Signed-off-by: Simon Glass 
> Suggested-by: Bin Meng 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 18/42] Kconfig: sandbox: Drop CONFIG_CMD_SANDBOX option

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:42PM -0600, Simon Glass wrote:

> This is no-longer used. Drop it.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 14/42] Kconfig: Drop CONFIG_CMD_PORTIO and associated command

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:38PM -0600, Simon Glass wrote:

> This command is not used by any board. It also looks quite similar to the
> 'iod' and 'iow' commands which use the correct I/O macros.
> 
> Drop it.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2,19/42] Convert CONFIG_CMD_SAVES to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:43PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_SAVES
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v1] at91, smartweb: use SPL_SYS_MALLOC_F_LEN

[Tom Rini]

On Tue, Aug 08, 2017 at 03:10:24PM +0200, Heiko Schocher wrote:

> commit f1896c45cb2f: spl: make SPL and normal u-boot stage use independent 
> SYS_MALLOC_F_LEN
> introduced independent SYS_MALLOC_F_LEN for SPL and U-Boot.
> 
> Use it on the smartweb board, as above commit broke
> the smartweb board.
> 
> Signed-off-by: Heiko Schocher 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2,40/42] Convert CONFIG_CMD_ZFS to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:35:04PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_ZFS
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 37/42] Convert CONFIG_CMD_UNIVERSE to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:35:01PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_UNIVERSE
> 
> Since no board uses this, perhaps we should drop this command?
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 08/42] Convert CONFIG_CMD_PCA953X to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:32PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_PCA953X
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2,21/42] Convert CONFIG_CMD_SDRAM to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:45PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_SDRAM
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 05/42] Convert CONFIG_CMD_MMC_SPI to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:29PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_MMC_SPI
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2,29/42] gpio: Drop sx151x driver

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:53PM -0600, Simon Glass wrote:

> This driver is not used in U-Boot. Drop it and its associated CONFIG
> options.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2,10/42] Convert CONFIG_CMD_PCI to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:34PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_PCI
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 07/42] Convert CONFIG_CMD_ONENAND to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:31PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_ONENAND
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 04/42] Kconfig: Sort the device-access commands

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:28PM -0600, Simon Glass wrote:

> These are currently not quite in alphabetical order. Before adding more,
> sort them.
> 
> Signed-off-by: Simon Glass 
> Suggested-by: Bin Meng 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2,35/42] Convert CONFIG_CMD_TRACE to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:59PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_TRACE
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 17/42] Convert CONFIG_CMD_REISER to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:41PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_REISER
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2,39/42] Convert CONFIG_CMD_ZBOOT to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:35:03PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_ZBOOT
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 22/42] Convert CONFIG_CMD_SF_TEST to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:46PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_SF_TEST
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 34/42] Convert CONFIG_CMD_YAFFS2 to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:58PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_YAFFS2
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 06/42] Convert CONFIG_CMD_MTDPARTS_SPREAD to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:30PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_MTDPARTS_SPREAD
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 28/42] Convert CONFIG_CMD_STRINGS to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:52PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_STRINGS
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2,41/42] Drop config_cmd_all.h

[Tom Rini]

On Fri, Aug 04, 2017 at 04:35:05PM -0600, Simon Glass wrote:

> This file does not include all commands and has not for a while. Let's
> drop it.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2,11/42] Kconfig: Drop CONFIG_CMD_PCI_ENUM

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:35PM -0600, Simon Glass wrote:

> This option enables the 'pci enum' command. It is only enabled by a few
> board and these have not yet been converted to driver model, which always
> enables this command. It seems easiest to just remove this option.
> 
> The affected boards can be converted to use driver model for PCI if
> needed.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 25/42] Convert CONFIG_CMD_SPL_NAND_OFS to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:49PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_SPL_NAND_OFS
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 23/42] Convert CONFIG_CMD_SH_ZIMAGEBOOT to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:47PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_SH_ZIMAGEBOOT
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2,20/42] Convert CONFIG_CMD_SCSI to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:44PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_SCSI
> 
> Also update the Makefile to use CONFIG_CMD_SCSI instead of CONFIG_SCSI to
> enable the command, fixing an earlier error.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

After making this default y if SCSI, and drop from cl-som-am57x as it
wasn't using really, applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 09/42] Kconfig: Drop CONFIG_CMD_PCA953X_INFO

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:33PM -0600, Simon Glass wrote:

> It does not seem worth having an option to enable another sub-command in
> this legacy driver. Drop this option so that the sub-command is always
> available.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v1 15/15] efi_loader: add bootmgr

[Alexander Graf]

On 10.08.17 20:29, Rob Clark wrote:

Similar to a "real" UEFI implementation, the bootmgr looks at the
BootOrder and Boot variables to try to find an EFI payload to load
and boot.  This is added as a sub-command of bootefi.

The idea is that the distro bootcmd would first try loading a payload
via the bootmgr, and then if that fails (ie. first boot or corrupted
EFI variables) it would fallback to loading bootaa64.efi.  (Which
would then load fallback.efi which would look for \EFI\*\boot.csv and
populate BootOrder and Boot based on what it found.)

Signed-off-by: Rob Clark 
---
  cmd/bootefi.c |  48 ++-
  include/config_distro_bootcmd.h   |   5 ++
  include/efi_api.h |   4 +
  include/efi_loader.h  |   6 ++
  lib/efi_loader/Makefile   |   2 +-
  lib/efi_loader/efi_bootmgr.c  | 169 ++
  lib/efi_loader/efi_boottime.c |   6 +-
  lib/efi_loader/efi_image_loader.c |   1 +
  8 files changed, 235 insertions(+), 6 deletions(-)
  create mode 100644 lib/efi_loader/efi_bootmgr.c

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 80f52e9e35..02a0dd159b 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -219,6 +219,36 @@ exit:
return ret;
  }
  
+static int do_bootefi_bootmgr_exec(unsigned long fdt_addr)

+{
+   struct efi_device_path *device_path, *file_path;
+   void *addr;
+   efi_status_t r;
+
+   /* Initialize and populate EFI object list */
+   if (!efi_obj_list_initalized)
+   efi_init_obj_list();
+
+   /*
+* gd lives in a fixed register which may get clobbered while we execute
+* the payload. So save it here and restore it on every callback entry
+*/
+   efi_save_gd();
+
+   addr = efi_bootmgr_load(_path, _path);
+   if (!addr)
+   return 1;
+
+   printf("## Starting EFI application at %p ...\n", addr);
+   r = do_bootefi_exec(addr, (void*)fdt_addr, device_path, file_path);
+   printf("## Application terminated, r = %lu\n",
+  r & ~EFI_ERROR_MASK);
+
+   if (r != EFI_SUCCESS)
+   return 1;
+
+   return 0;
+}
  
  /* 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[])
@@ -237,7 +267,14 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv[])
memcpy((char *)addr, __efi_hello_world_begin, size);
} else
  #endif
-   {
+   if (!strcmp(argv[1], "bootmgr")) {
+   unsigned long fdt_addr = 0;
+
+   if (argc > 2)
+   fdt_addr = simple_strtoul(argv[2], NULL, 16);
+
+   return do_bootefi_bootmgr_exec(fdt_addr);
+   } else {
saddr = argv[1];
  
  		addr = simple_strtoul(saddr, NULL, 16);

@@ -270,7 +307,11 @@ static char bootefi_help_text[] =
"hello\n"
"  - boot a sample Hello World application stored within U-Boot"
  #endif
-   ;
+   "bootmgr [fdt addr]\n"
+   "  - load and boot EFI payload based on BootOrder/Boot variables.\n"
+   "\n"
+   "If specified, the device tree located at  gets\n"
+   "exposed as EFI configuration table.\n";
  #endif
  
  U_BOOT_CMD(

@@ -308,6 +349,9 @@ void efi_set_bootdev(const char *dev, const char *devnr, 
const char *path)
  #endif
}
  
+	if (!path)

+   return;
+
if (strcmp(dev, "Net")) {
/* Add leading / to fs paths, because they're absolute */
snprintf(filename, sizeof(filename), "/%s", path);
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index d8dab8e46a..94ccab02d2 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -112,6 +112,11 @@
  
  #define BOOTENV_SHARED_EFI\

"boot_efi_binary="\
+   "if fdt addr ${fdt_addr_r}; then "\
+   "bootefi bootmgr ${fdt_addr_r};"  \


This is too late. At this point you already checked that there indeed is 
a fallback binary. Since the bootmgr target actually knows which device 
it loads itself from, it can occur way before in the boot chain.


Maybe we should just add a new boot_target for bootmgr. That way it 
naturally fits into the distro boot flow. You could then add a 
BOOTENV_DEV_BOOTMGR and simply run it from there.


The only thing missing in that case is the device tree override - hmm...

Oh well, if you need that I'm fine to leave it as hacky as it is here, 
but this boot protocol is definitely not what the UEFI guys had 
envisioned ;).



Alex

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

Re: [U-Boot] [U-Boot,v2,03/42] Kconfig: Drop CONFIG_CMD_MEM

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:27PM -0600, Simon Glass wrote:

> This is not actually used in U-Boot. Most likely it means
> CONFIG_CMD_MEMORY so change all occurences to that.
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, v2, 02/42] Convert CONFIG_CMD_MAX6957 to Kconfig

[Tom Rini]

On Fri, Aug 04, 2017 at 04:34:26PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CMD_MAX6957
> 
> Signed-off-by: Simon Glass 
> Reviewed-by: Bin Meng 
> Reviewed-by: Philipp Tomsich 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v1 14/15] efi_loader: efi variable support

[Alexander Graf]

On 10.08.17 20:29, Rob Clark wrote:

Add EFI variable support, mapping to u-boot environment variables.
Variables are pretty important for setting up boot order, among other
things.  If the board supports saveenv, then it will be called in
ExitBootServices() to persist variables set by the efi payload.  (For
example, fallback.efi configuring BootOrder and Boot load-option
variables.)

Variables are *not* currently exposed at runtime, post ExitBootServices.
On boards without a dedicated device for storage, which the loaded OS
is not trying to also use, this is rather tricky.  One idea, at least
for boards that can persist RAM across reboot, is to keep a "journal"
of modified variables in RAM, and then turn halt into a reboot into
u-boot, plus store variables, plus halt.  Whatever the solution, it
likely involves some per-board support.

Mapping between EFI variables and u-boot variables:

   efi_$guid_$varname = {attributes}(type)value

For example:

   efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported=
  "{ro,boot,run}(blob)"
   efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder=
  "(blob)0001"

The attributes are a comma separated list of these possible
attributes:

   + ro   - read-only
   + boot - boot-services access
   + run  - runtime access

NOTE: with current implementation, no variables are available after
ExitBootServices, and all are persisted (if possible).

If not specified, the attributes default to "{boot}".

The required type is one of:

   + utf8 - raw utf8 string
   + blob - arbitrary length hex string

Signed-off-by: Rob Clark 
---
  cmd/bootefi.c |   4 +
  include/efi.h |  19 +++
  include/efi_loader.h  |  10 ++
  lib/efi_loader/Makefile   |   2 +-
  lib/efi_loader/efi_boottime.c |   5 +
  lib/efi_loader/efi_runtime.c  |  17 ++-
  lib/efi_loader/efi_variable.c | 342 ++
  7 files changed, 394 insertions(+), 5 deletions(-)
  create mode 100644 lib/efi_loader/efi_variable.c

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index b9e1e5e131..80f52e9e35 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -181,6 +181,10 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt,
goto exit;
}
  
+	/* we don't support much: */

+   
setenv("efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported",
+   "{ro,boot}(blob)");
+
/* Call our payload! */
debug("%s:%d Jumping to 0x%lx\n", __func__, __LINE__, (long)entry);
  
diff --git a/include/efi.h b/include/efi.h

index ddd2b96417..dbd482a5db 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -324,6 +324,25 @@ extern char image_base[];
  /* Start and end of U-Boot image (for payload) */
  extern char _binary_u_boot_bin_start[], _binary_u_boot_bin_end[];
  
+/*

+ * Variable Attributes
+ */
+#define EFI_VARIABLE_NON_VOLATILE   0x0001


Shouldn't we honor this one too? A UEFI application may set runtime 
variables that should not get persisted across boots (think the UEFI 
shell setting some internal state thing, then booting Linux).



+#define EFI_VARIABLE_BOOTSERVICE_ACCESS 0x0002
+#define EFI_VARIABLE_RUNTIME_ACCESS 0x0004
+#define EFI_VARIABLE_HARDWARE_ERROR_RECORD 0x0008
+#define EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS 0x0010
+#define EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS 0x0020
+#define EFI_VARIABLE_APPEND_WRITE  0x0040
+
+#define EFI_VARIABLE_MASK  (EFI_VARIABLE_NON_VOLATILE | \
+   EFI_VARIABLE_BOOTSERVICE_ACCESS | \
+   EFI_VARIABLE_RUNTIME_ACCESS | \
+   EFI_VARIABLE_HARDWARE_ERROR_RECORD | \
+   EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS | \
+   
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS | \
+   EFI_VARIABLE_APPEND_WRITE)
+
  /**
   * efi_get_sys_table() - Get access to the main EFI system table
   *
diff --git a/include/efi_loader.h b/include/efi_loader.h
index efb93f31f7..9cb568e615 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -271,6 +271,16 @@ efi_status_t __efi_runtime EFIAPI efi_get_time(
struct efi_time_cap *capabilities);
  void efi_get_time_init(void);
  
+efi_status_t EFIAPI efi_get_variable(s16 *variable_name,

+   efi_guid_t *vendor, u32 *attributes,
+   unsigned long *data_size, void *data);
+efi_status_t EFIAPI efi_get_next_variable(
+   unsigned long *variable_name_size,
+   s16 *variable_name, efi_guid_t *vendor);
+efi_status_t EFIAPI efi_set_variable(s16 *variable_name,
+   efi_guid_t *vendor, u32 attributes,
+   unsigned long data_size, void *data);
+
  #else /* defined(EFI_LOADER) && 

Re: [U-Boot] [PATCH v1 08/15] efi_loader: use proper device-paths for partitions

[Alexander Graf]

On 10.08.17 20:29, Rob Clark wrote:

Also, create disk objects for the disk itself, in addition to the
partitions.  (UEFI terminology is a bit confusing, a "disk" object is
really a partition.)  This helps grub properly identify the boot device
since it is trying to match up partition "disk" object with it's parent
device.

Now instead of seeing devices like:

   /File(sd...@07864000.blk)/EndEntire
   /File(usb_mass_storage.lun0)/EndEntire

You see:

   /ACPI(133741d0,0)/UnknownMessaging(1d)/EndEntire
   
/ACPI(133741d0,0)/UnknownMessaging(1d)/HD(0,800,64000,dd904a8c,1,1)/EndEntire
   
/ACPI(133741d0,0)/UnknownMessaging(1d)/HD(1,64800,20,dd904a8c,1,1)/EndEntire
   
/ACPI(133741d0,0)/UnknownMessaging(1d)/HD(2,264800,19a000,dd904a8c,1,1)/EndEntire
   /ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/EndEntire
   
/ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(0,800,6,38ca6802,1,1)/EndEntire
   
/ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(1,61000,155000,38ca6802,1,1)/EndEntire
   
/ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(2,20fa800,1bbf8800,38ca6802,1,1)/EndEntire
   
/ACPI(133741d0,0)/USB(0,0)/USB(0,0)/USB(0,0)/HD(3,1b6800,1f44000,38ca6802,1,1)/EndEntire

This is on a board with single USB disk and single sd-card.  The
UnknownMessaging(1d) node in the device-path is the MMC device,
but grub_efi_print_device_path() hasn't been updated yet for some
of the newer device-path sub-types.

This patch is inspired by a patch originally from Peter Jones, but
re-worked to use efi_device_path, so it doesn't much resemble the
original.

Signed-off-by: Rob Clark 
---
  lib/efi_loader/efi_disk.c | 54 +++
  1 file changed, 31 insertions(+), 23 deletions(-)

diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index ed06485e33..eea65a402a 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -28,11 +28,13 @@ struct efi_disk_obj {
/* EFI Interface Media descriptor struct, referenced by ops */
struct efi_block_io_media media;
/* EFI device path to this block device */
-   struct efi_device_path_file_path *dp;
+   struct efi_device_path *dp;
+   /* partition # */
+   unsigned part;
/* Offset into disk for simple partitions */
lbaint_t offset;
/* Internal block device */
-   const struct blk_desc *desc;
+   struct blk_desc *desc;
  };
  
  static efi_status_t EFIAPI efi_disk_reset(struct efi_block_io *this,

@@ -172,26 +174,26 @@ static const struct efi_block_io block_io_disk_template = 
{
  
  static void efi_disk_add_dev(const char *name,

 const char *if_typename,
-const struct blk_desc *desc,
+struct blk_desc *desc,
 int dev_index,
-lbaint_t offset)
+lbaint_t offset,
+unsigned part)
  {
struct efi_disk_obj *diskobj;
-   struct efi_device_path_file_path *dp;
-   int objlen = sizeof(*diskobj) + (sizeof(*dp) * 2);
  
  	/* Don't add empty devices */

if (!desc->lba)
return;
  
-	diskobj = calloc(1, objlen);

+   diskobj = calloc(1, sizeof(*diskobj));
  
  	/* Fill in object data */

-   dp = (void *)[1];
+   diskobj->dp = efi_dp_from_part(desc, part);
+   diskobj->part = part;
diskobj->parent.protocols[0].guid = _block_io_guid;
diskobj->parent.protocols[0].protocol_interface = >ops;
diskobj->parent.protocols[1].guid = _guid_device_path;
-   diskobj->parent.protocols[1].protocol_interface = dp;
+   diskobj->parent.protocols[1].protocol_interface = diskobj->dp;
diskobj->parent.handle = diskobj;
diskobj->ops = block_io_disk_template;
diskobj->ifname = if_typename;
@@ -207,17 +209,6 @@ static void efi_disk_add_dev(const char *name,
diskobj->media.last_block = desc->lba - offset;
diskobj->ops.media = >media;
  
-	/* Fill in device path */

-   diskobj->dp = dp;
-   dp[0].dp.type = DEVICE_PATH_TYPE_MEDIA_DEVICE;
-   dp[0].dp.sub_type = DEVICE_PATH_SUB_TYPE_FILE_PATH;
-   dp[0].dp.length = sizeof(*dp);
-   ascii2unicode(dp[0].str, name);
-
-   dp[1].dp.type = DEVICE_PATH_TYPE_END;
-   dp[1].dp.sub_type = DEVICE_PATH_SUB_TYPE_END;
-   dp[1].dp.length = sizeof(*dp);
-
/* Hook up to the device list */
list_add_tail(>parent.link, _obj_list);
  }
@@ -236,14 +227,18 @@ static int efi_disk_create_eltorito(struct blk_desc *desc,
if (desc->part_type != PART_TYPE_ISO)
return 0;
  
+	/* and devices for each partition: */

while (!part_get_info(desc, part, )) {
snprintf(devname, sizeof(devname), "%s:%d", pdevname,
 part);
efi_disk_add_dev(devname, 

Re: [U-Boot] [PATCH v1 04/15] efi: add some more device path structures

[Alexander Graf]

On 10.08.17 20:29, Rob Clark wrote:

From: Peter Jones 

Signed-off-by: Peter Jones 
Signed-off-by: Rob Clark 
---
  include/efi_api.h | 62 +++
  1 file changed, 58 insertions(+), 4 deletions(-)

diff --git a/include/efi_api.h b/include/efi_api.h
index ec1b321e8e..b761cf4822 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -284,28 +284,82 @@ struct efi_device_path {
u8 type;
u8 sub_type;
u16 length;
-};
+} __packed;


This does not match the patch description. Please have additions in one 
and packed fixups in a different patch.


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

Re: [U-Boot] [PATCH v1 03/15] part: extract MBR signature from partitions

[Alexander Graf]

On 10.08.17 20:29, Rob Clark wrote:

From: Peter Jones 

EFI client programs need the signature information from the partition
table to determine the disk a partition is on, so we need to fill that
in here.

Signed-off-by: Peter Jones 
[separated from efi_loader part, and fixed build-errors for non-
  CONFIG_EFI_PARTITION case]
Signed-off-by: Rob Clark 
---
  disk/part_dos.c| 12 +---
  disk/part_efi.c| 20 
  include/blk.h  | 15 +++
  include/efi.h  |  4 
  include/part.h |  3 ++-
  include/part_efi.h |  4 
  6 files changed, 50 insertions(+), 8 deletions(-)

diff --git a/disk/part_dos.c b/disk/part_dos.c
index 7ede15ec26..850a538e83 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -89,14 +89,20 @@ static int test_block_type(unsigned char *buffer)
  
  static int part_test_dos(struct blk_desc *dev_desc)

  {
-   ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc->blksz);
+   ALLOC_CACHE_ALIGN_BUFFER(legacy_mbr, mbr, dev_desc->blksz);
  
-	if (blk_dread(dev_desc, 0, 1, (ulong *)buffer) != 1)

+   if (blk_dread(dev_desc, 0, 1, (ulong *)mbr) != 1)
return -1;
  
-	if (test_block_type(buffer) != DOS_MBR)

+   if (test_block_type((unsigned char *)mbr) != DOS_MBR)
return -1;
  
+	if (dev_desc->sig_type == SIG_TYPE_NONE &&

+   mbr->unique_mbr_signature != 0) {
+   dev_desc->sig_type = SIG_TYPE_MBR;
+   dev_desc->mbr_sig = mbr->unique_mbr_signature;
+   }
+
return 0;
  }
  
diff --git a/disk/part_efi.c b/disk/part_efi.c

index 1b7ba27947..71e4188455 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -871,11 +871,19 @@ static int is_pmbr_valid(legacy_mbr * mbr)
  static int is_gpt_valid(struct blk_desc *dev_desc, u64 lba,
gpt_header *pgpt_head, gpt_entry **pgpt_pte)
  {
+   ALLOC_CACHE_ALIGN_BUFFER(legacy_mbr, mbr, dev_desc->blksz);
+
if (!dev_desc || !pgpt_head) {
printf("%s: Invalid Argument(s)\n", __func__);
return 0;
}
  
+	/* Read MBR Header from device */

+   if (blk_dread(dev_desc, 0, 1, (ulong *)mbr) != 1) {
+   printf("*** ERROR: Can't read MBR header ***\n");
+   return 0;
+   }
+
/* Read GPT Header from device */
if (blk_dread(dev_desc, (lbaint_t)lba, 1, pgpt_head) != 1) {
printf("*** ERROR: Can't read GPT header ***\n");
@@ -885,6 +893,18 @@ static int is_gpt_valid(struct blk_desc *dev_desc, u64 lba,
if (validate_gpt_header(pgpt_head, (lbaint_t)lba, dev_desc->lba))
return 0;
  
+	if (dev_desc->sig_type == SIG_TYPE_NONE) {

+   efi_guid_t empty = {};
+   if (memcmp(_head->disk_guid, , sizeof(empty))) {
+   dev_desc->sig_type = SIG_TYPE_GUID;
+   memcpy(_desc->guid_sig, _head->disk_guid,
+ sizeof(empty));
+   } else if (mbr->unique_mbr_signature != 0) {
+   dev_desc->sig_type = SIG_TYPE_MBR;
+   dev_desc->mbr_sig = mbr->unique_mbr_signature;
+   }
+   }
+
/* Read and allocate Partition Table Entries */
*pgpt_pte = alloc_read_gpt_entries(dev_desc, pgpt_head);
if (*pgpt_pte == NULL) {
diff --git a/include/blk.h b/include/blk.h
index ef29a07ee2..3a5e04c00d 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -8,6 +8,8 @@
  #ifndef BLK_H
  #define BLK_H
  
+#include 

+
  #ifdef CONFIG_SYS_64BIT_LBA
  typedef uint64_t lbaint_t;
  #define LBAFlength "ll"
@@ -35,6 +37,14 @@ enum if_type {
IF_TYPE_COUNT,  /* Number of interface types */
  };
  
+enum sig_type {

+   SIG_TYPE_NONE,
+   SIG_TYPE_MBR,
+   SIG_TYPE_GUID,
+
+   SIG_TYPE_COUNT  /* Number of signature types */
+};
+
  /*
   * With driver model (CONFIG_BLK) this is uclass platform data, accessible
   * with dev_get_uclass_platdata(dev)
@@ -62,6 +72,11 @@ struct blk_desc {
charvendor[40+1];   /* IDE model, SCSI Vendor */
charproduct[20+1];  /* IDE Serial no, SCSI product */
charrevision[8+1];  /* firmware revision */
+   enum sig_type   sig_type;   /* Partition table signature type */
+   union {
+   uint32_t mbr_sig;   /* MBR integer signature */
+   efi_guid_t guid_sig;/* GPT GUID Signature */
+   };
  #ifdef CONFIG_BLK
/*
 * For now we have a few functions which take struct blk_desc as a
diff --git a/include/efi.h b/include/efi.h
index 02b78b31b1..87b0b43f20 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -28,6 +28,10 @@
  
  struct efi_device_path;
  
+typedef struct {

+   u8 b[16];
+} efi_guid_t;
+
  #define EFI_BITS_PER_LONG BITS_PER_LONG
  
  /*

diff --git a/include/part.h 

Re: [U-Boot] [PATCH v1 02/15] fs/fat: implement readdir

[Alexander Graf]

On 10.08.17 20:29, Rob Clark wrote:

Yes, this is super-hacky.  The FAT code is quite ugly, and this doesn't
improve things.  But it doesn't make it significantly worse either.  The
better option would be a massive FAT re-write to get rid of the hacky
way that fat_file_ls() works.  Volunteers welcome.

Signed-off-by: Rob Clark 


What concerns me the most in patch 1/15 and this patch is the limited 
scope. Yes, you make readdir work for FAT, but all other file systems 
are still unimplemented. In fact, they're even all still implementing 
their own hand-written ls logic.


One of the goals of the efi_loader code is to integrate with U-Boot as 
much as possible, to reuse code where we can. And if current interfaces 
are terrible, I think it's ok to just replace them for something that 
fits everyone's needs better.


How feasible do you think it would be to implement an ls function based 
on readdir and just convert all file systems to it, completely replacing 
the current (quite crude) ls logic?



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

[U-Boot] [PATCH] Convert CONFIG_BCH to Kconfig

[Adam Ford]

This converts the following to Kconfig:
   CONFIG_BCH

Signed-off-by: Adam Ford 
---
 configs/am3517_evm_defconfig | 1 +
 configs/igep0020_defconfig   | 1 +
 configs/igep0030_defconfig   | 1 +
 configs/igep0032_defconfig   | 1 +
 configs/km_kirkwood_128m16_defconfig | 1 +
 configs/km_kirkwood_defconfig| 1 +
 configs/km_kirkwood_pci_defconfig| 1 +
 configs/kmcoge4_defconfig| 1 +
 configs/kmcoge5ne_defconfig  | 1 +
 configs/kmcoge5un_defconfig  | 1 +
 configs/kmlion1_defconfig| 1 +
 configs/kmnusa_defconfig | 1 +
 configs/kmsugp1_defconfig| 1 +
 configs/kmsuv31_defconfig| 1 +
 configs/kmtegr1_defconfig| 1 +
 configs/mgcoge3un_defconfig  | 1 +
 configs/omap3_logic_defconfig| 1 +
 configs/omap3_overo_defconfig| 1 +
 configs/portl2_defconfig | 1 +
 configs/tricorder_defconfig  | 1 +
 configs/tricorder_flash_defconfig| 1 +
 configs/x600_defconfig   | 1 +
 doc/README.nand  | 6 --
 include/configs/am3517_evm.h | 1 -
 include/configs/km/km_arm.h  | 1 -
 include/configs/km/kmp204x-common.h  | 2 --
 include/configs/km8360.h | 1 -
 include/configs/omap3_igep00x0.h | 1 -
 include/configs/omap3_logic.h| 1 -
 include/configs/omap3_overo.h| 2 --
 include/configs/suvd3.h  | 1 -
 include/configs/tricorder.h  | 1 -
 include/configs/x600.h   | 1 -
 lib/Kconfig  | 7 +++
 scripts/config_whitelist.txt | 1 -
 35 files changed, 29 insertions(+), 19 deletions(-)

diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig
index 4e4aadb..c7e7dc4 100644
--- a/configs/am3517_evm_defconfig
+++ b/configs/am3517_evm_defconfig
@@ -43,4 +43,5 @@ CONFIG_SYS_NS16550=y
 CONFIG_USB=y
 CONFIG_USB_MUSB_HOST=y
 CONFIG_USB_STORAGE=y
+CONFIG_BCH=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/igep0020_defconfig b/configs/igep0020_defconfig
index 745d6f6..41ac579 100644
--- a/configs/igep0020_defconfig
+++ b/configs/igep0020_defconfig
@@ -41,5 +41,6 @@ CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
 CONFIG_MTD_UBI_FASTMAP=y
 CONFIG_SYS_NS16550=y
 CONFIG_FAT_WRITE=y
+CONFIG_BCH=y
 CONFIG_OF_LIBFDT=y
 CONFIG_FDT_FIXUP_PARTITIONS=y
diff --git a/configs/igep0030_defconfig b/configs/igep0030_defconfig
index 48b80ae..14397c5 100644
--- a/configs/igep0030_defconfig
+++ b/configs/igep0030_defconfig
@@ -40,5 +40,6 @@ CONFIG_MMC_OMAP_HS=y
 CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
 CONFIG_SYS_NS16550=y
 CONFIG_FAT_WRITE=y
+CONFIG_BCH=y
 CONFIG_OF_LIBFDT=y
 CONFIG_FDT_FIXUP_PARTITIONS=y
diff --git a/configs/igep0032_defconfig b/configs/igep0032_defconfig
index 8ecd6a5..c44cb15 100644
--- a/configs/igep0032_defconfig
+++ b/configs/igep0032_defconfig
@@ -32,5 +32,6 @@ CONFIG_MMC_OMAP_HS=y
 CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
 CONFIG_SYS_NS16550=y
 CONFIG_FAT_WRITE=y
+CONFIG_BCH=y
 CONFIG_OF_LIBFDT=y
 CONFIG_FDT_FIXUP_PARTITIONS=y
diff --git a/configs/km_kirkwood_128m16_defconfig 
b/configs/km_kirkwood_128m16_defconfig
index bbc43c0..100c337 100644
--- a/configs/km_kirkwood_128m16_defconfig
+++ b/configs/km_kirkwood_128m16_defconfig
@@ -28,4 +28,5 @@ CONFIG_CMD_UBI=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SYS_NS16550=y
+CONFIG_BCH=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/km_kirkwood_defconfig b/configs/km_kirkwood_defconfig
index 5a0bafe..330805a 100644
--- a/configs/km_kirkwood_defconfig
+++ b/configs/km_kirkwood_defconfig
@@ -28,4 +28,5 @@ CONFIG_CMD_UBI=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SYS_NS16550=y
+CONFIG_BCH=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/km_kirkwood_pci_defconfig 
b/configs/km_kirkwood_pci_defconfig
index 5c58244..85588ae 100644
--- a/configs/km_kirkwood_pci_defconfig
+++ b/configs/km_kirkwood_pci_defconfig
@@ -28,4 +28,5 @@ CONFIG_CMD_UBI=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SYS_NS16550=y
+CONFIG_BCH=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/kmcoge4_defconfig b/configs/kmcoge4_defconfig
index 854b4d2..437990f 100644
--- a/configs/kmcoge4_defconfig
+++ b/configs/kmcoge4_defconfig
@@ -39,4 +39,5 @@ CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
 CONFIG_SYS_NS16550=y
 CONFIG_FSL_ESPI=y
+CONFIG_BCH=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/kmcoge5ne_defconfig b/configs/kmcoge5ne_defconfig
index 16f51da..a49e9ae 100644
--- a/configs/kmcoge5ne_defconfig
+++ b/configs/kmcoge5ne_defconfig
@@ -25,4 +25,5 @@ CONFIG_CMD_UBI=y
 CONFIG_MTD_NOR_FLASH=y
 # CONFIG_PCI is not set
 CONFIG_SYS_NS16550=y
+CONFIG_BCH=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/kmcoge5un_defconfig b/configs/kmcoge5un_defconfig
index 333130e..044c06a 100644
--- a/configs/kmcoge5un_defconfig
+++ b/configs/kmcoge5un_defconfig
@@ -28,4 +28,5 @@ CONFIG_CMD_UBI=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SYS_NS16550=y
+CONFIG_BCH=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/kmlion1_defconfig 

[U-Boot] [PATCH 1/2] arm: use $loadaddr as the standalone entry point

[Max Krummenacher]

Different SoCs have different RAM layouts, so providing
$(CONFIG_LOADADDR) instead of the constant 0xc10 for
CONFIG_STANDALONE_LOAD_ADDR is probably more appropriate.

Signed-off-by: Max Krummenacher 
---

 arch/arm/config.mk| 4 
 doc/README.standalone | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 1a9db4..8f56c7433f 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -9,7 +9,11 @@ ifndef CONFIG_STANDALONE_LOAD_ADDR
 ifneq ($(CONFIG_ARCH_OMAP2PLUS),)
 CONFIG_STANDALONE_LOAD_ADDR = 0x8030
 else
+ifndef CONFIG_LOADADDR
 CONFIG_STANDALONE_LOAD_ADDR = 0xc10
+else
+CONFIG_STANDALONE_LOAD_ADDR = $(CONFIG_LOADADDR)
+endif
 endif
 endif
 
diff --git a/doc/README.standalone b/doc/README.standalone
index 659a12f6cb..17d740c44b 100644
--- a/doc/README.standalone
+++ b/doc/README.standalone
@@ -53,7 +53,7 @@ Design Notes on Exporting U-Boot Functions to Standalone 
Applications:
Load addressStart address
x86 0x0004  0x0004
PowerPC 0x0004  0x00040004
-   ARM 0x0c10  0x0c10
+   ARM CONFIG_LOADADDR CONFIG_LOADADDR
MIPS0x8020  0x8020
Blackfin0x1000  0x1000
NDS32   0x0030  0x0030
-- 
2.13.1

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

[U-Boot] [PATCH 2/2] hello_world.c: fix entry point in case of arm thumb binary

[Max Krummenacher]

If compiling for thumb the U-Boot 'go' command can not jump to the entry
point, as the jump will be done in the assumption that the code jumped to
is using the arm instruction set.

So add add a simple forwarder in arm instruction set which then jumps
to the 'real' entry.

Signed-off-by: Max Krummenacher 

---

 examples/standalone/hello_world.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/examples/standalone/hello_world.c 
b/examples/standalone/hello_world.c
index bd8b392315..0b859ca4bd 100644
--- a/examples/standalone/hello_world.c
+++ b/examples/standalone/hello_world.c
@@ -8,6 +8,21 @@
 #include 
 #include 
 
+/*
+ * Make thumb work by providing a forwarder to the (thumb) entry point
+ * compiled for arm instruction set.
+ * Don't compile this for thumb only CPUs.
+ */
+#if defined(__thumb__) && defined(__ARM_ARCH_ISA_ARM)
+void __attribute__((unused)) __attribute__ ((naked)) dummy2(void)
+{
+asm volatile( \
+"  .code 32\n" \
+"  .arm\n" \
+"  ldr pc,=hello_world\n");
+}
+#endif
+
 int hello_world (int argc, char * const argv[])
 {
int i;
-- 
2.13.1

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

[U-Boot] [PATCH 0/2] improve hello_world standalone application for arm

[Max Krummenacher]

This series addresses
- hardcoded entry address, use LOADADDR if available as the entry point instead
- fix thumb build, jumping with 'go' to the entry point expects arm code

Note that in addition to the two fixes I've seen random freezes
or 'random' printed stuff when using an early linaro gcc 6 compiler.
Adding an initialized variable helped in that case
static int dummy_var_in_text = 1;
I assume that this forces alignment of some linker sections.
(e.g. I see that __bss_start points to 0x1201027e, with the variable
this moves to 0x12010280)

However with the current linaro compilers this does not happen so I
don't propose a patch for this issue.
Linaro GCC 5.4-2017.05 5.4.1 20170404
Linaro GCC 6.3-2017.05 6.3.1 20170404
Linaro GCC 7.1-2017.05 7.1.1 20170510

This series is available at 
http://git.toradex.com/cgit/u-boot-toradex.git/log/?h=for-next


Max Krummenacher (2):
  arm: use $loadaddr as the standalone entry point
  hello_world.c: fix entry point in case of arm thumb binary

 arch/arm/config.mk|  4 
 doc/README.standalone |  2 +-
 examples/standalone/hello_world.c | 15 +++
 3 files changed, 20 insertions(+), 1 deletion(-)

-- 
2.13.1

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

Re: [U-Boot] [PATCH v2 2/5] arm: socfpga: Add checking function on FPGA setting in FDT

[Chee, Tien Fong]

On Jum, 2017-08-11 at 17:01 +0200, Marek Vasut wrote:
> On 08/10/2017 06:51 AM, Chee, Tien Fong wrote:
> > 
> > On Rab, 2017-08-09 at 10:20 +0200, Marek Vasut wrote:
> > > 
> > > On 08/09/2017 07:07 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Sel, 2017-08-08 at 11:29 +0200, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 08/08/2017 11:12 AM, tien.fong.c...@intel.com wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > From: Tien Fong Chee 
> > > > > > 
> > > > > > Function for checking FPGA early release setting which is
> > > > > > defined
> > > > > > by user in FDT chosen section. This function would be used
> > > > > > by
> > > > > > later driver in decision applying appropriate FPGA
> > > > > > configuration in
> > > > > > early release or full FPGA booting mode.
> > > > > Isn't this a property of the FPGA driver ?
> > This is not property of fpga driver. It acts like passing data flag
> > to
> > u-boot, so u-boot knows how to boot in the mode defined by user.
> So it's a configuration option ? Doing what ... since there's no
> binding
> document, it's not clear.
> 
Okay, i can add decription into / doc / device-tree-bindings /
chosen.txt.
> > 
> > > 
> > > > 
> > > > > 
> > > > > Shouldn't this have altr, prefix ?
> > This node doesn't represet a real device, it acts like a place for
> > passing data to U-boot. So, this flag name doesn't matter with
> > prefix,
> > right?
> But it's altera-specific, so it should have one ?
> 
Yeah, i can add it.
> > 
> > > 
> > > > 
> > > > > 
> > > > > Did this go through DT binding review?
> > No, refer my explanation above.
> > > 
> > > > 
> > > > > 
> > > > > 
> > > > This is our own define under chosen section. This is flag to
> > > > tell
> > > > U-
> > > > boot what kind of boot and what kind of fpga configuration we
> > > > want
> > > > during boot.
> > > And you didn't answer any of the aforementioned questions :(
> > > 
> > Sorry, it could be i misunderstand your question. please refer my
> > asnwer in above.
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Signed-off-by: Tien Fong Chee 
> > > > > > ---
> > > > > >  arch/arm/mach-socfpga/include/mach/misc.h |  1 +
> > > > > >  arch/arm/mach-socfpga/misc_arria10.c  | 20
> > > > > > 
> > > > > >  2 files changed, 21 insertions(+)
> > > > > > 
> > > > > > diff --git a/arch/arm/mach-socfpga/include/mach/misc.h
> > > > > > b/arch/arm/mach-socfpga/include/mach/misc.h
> > > > > > index 0b65783..e003f8a 100644
> > > > > > --- a/arch/arm/mach-socfpga/include/mach/misc.h
> > > > > > +++ b/arch/arm/mach-socfpga/include/mach/misc.h
> > > > > > @@ -26,6 +26,7 @@ static inline void socfpga_fpga_add(void)
> > > > > > {}
> > > > > >  unsigned int dedicated_uart_com_port(const void *blob);
> > > > > >  unsigned int shared_uart_com_port(const void *blob);
> > > > > >  unsigned int uart_com_port(const void *blob);
> > > > > > +int is_early_release_fpga_config(const void *blob);
> > > > > >  #endif
> > > > > >  
> > > > > >  #endif /* _MISC_H_ */
> > > > > > diff --git a/arch/arm/mach-socfpga/misc_arria10.c
> > > > > > b/arch/arm/mach-
> > > > > > socfpga/misc_arria10.c
> > > > > > index 9d751f6..2d6e977 100644
> > > > > > --- a/arch/arm/mach-socfpga/misc_arria10.c
> > > > > > +++ b/arch/arm/mach-socfpga/misc_arria10.c
> > > > > > @@ -235,6 +235,26 @@ unsigned int uart_com_port(const void
> > > > > > *blob)
> > > > > >     return shared_uart_com_port(blob);
> > > > > >  }
> > > > > >  
> > > > > > +int is_chosen_boolean_true(const void *blob, const char
> > > > > > *name)
> > > > > > +{
> > > > > > +   int node;
> > > > > > +   int rval = 0;
> > > > > > +
> > > > > > +   node = fdt_subnode_offset(blob, 0, "chosen");
> > > > > > +
> > > > > > +   if (node >= 0)
> > > > > > +   rval = fdtdec_get_bool(blob, node, name);
> > > > > > +
> > > > > > +   return rval;
> > > > > > +}
> > > > > > +
> > > > > > +int is_early_release_fpga_config(const void *blob)
> > > > > > +{
> > > > > > +   static const char *name = "early-release-fpga-
> > > > > > config";
> > > > > > +
> > > > > > +   return is_chosen_boolean_true(blob, name);
> > > > > > +}
> > > > > > +
> > > > > >  /*
> > > > > >   * Print CPU information
> > > > > >   */
> > > > > > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/5] arm: socfpga: Add intermediate driver between flash and FPGA manager

[Chee, Tien Fong]

On Jum, 2017-08-11 at 17:09 +0200, Marek Vasut wrote:
> On 08/10/2017 06:43 AM, Chee, Tien Fong wrote:
> > 
> > On Rab, 2017-08-09 at 10:29 +0200, Marek Vasut wrote:
> > > 
> > > On 08/09/2017 06:50 AM, Chee, Tien Fong wrote:
> > > [...]
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > If this is for some FPGA loading, can this functionality
> > > > > > > be
> > > > > > > scripted
> > > > > > > instead?
> > > > > > > 
> > > > > > Sorry, i'm not getting you. How functionality be scripted?
> > > > > > Could
> > > > > > you
> > > > > > provide some example or details explanation?
> > > > > ie. "load" (from fs) + "fpga load" (program FPGA) commands ?
> > > > > I think the fpga command already has some support for loading
> > > > > from FS
> > > > > too.
> > > > > 
> > > > Currently, we already have fpga load commands in fpga driver,
> > > > fpga
> > > > rbf
> > > > is loaded to memory, and programmed to fpga from memory, where
> > > > memory
> > > > location would be decided by user, it could be OCRAM or SDRAM.
> > > > 
> > > > for fpga loadfs command, i plan to implement it after having
> > > > complete
> > > > boot to U-boot console, since this is quite complex and
> > > > involving
> > > > some
> > > > hardware workaround issue, and some use case scenarios need to
> > > > be
> > > > considerd.
> > > So the arria10 u-boot port is still unable to boot to console ?
> > > 
> > Still need 2 to 3 more patchsets to get it boot to console.
> > > 
> > > > 
> > > > 
> > > > For example reconfiguring fpga with periperal rbf can
> > > > corrupt the sdram since sdram IOs is part of the fpga periph
> > > > rbf. I
> > > > need console to run a lot different scenarios testing.
> > > OK
> > > 
> > > > 
> > > > 
> > > > We still need cff.c, because most functionality in cff.c are
> > > > required
> > > > by fpga loadfs command.
> > > It seems a lot of stuff from this is common code, so why does it
> > > have
> > > to
> > > be in this driver again ?
> > This driver contains a lot "smart" functionality such as:
> I start to cringe when I read "smart functionality".
> 
> > 
> > 1: It having ability to the right memory(OCRAM or SDRAM) to achieve
> > the
> > best FPGA programing performance.
> Did you find significant throughput difference ?
> 
80% performance improvement with SDRAM.
> > 
> > 2: It can determine the right size buffer for the fpga rbf without
> > info
> > of buffer size defined by user.
> You mean like $filesize variable in the command prompt ?
> 
Yeah. No filesize is required.
> > 
> > 3: It has ability to know what kind of fpga rbf type, and security
> > type, such as peripheral, core, combined rbf, encryption and
> > unencryption based on any fpga file user pass in .
> Is this information used for anything ? I was under the impression
> that
> the user just needs to load in the correct RBF file into the FPGA.
> 
Yeah, the driver would decode the RBF image to know what type of RBF
user loading, and applying correct method(buffer allocation, which
memory to use and configuration on FPGA manager) to program FPGA.
> > 
> > 4: It supports the checksum.
> What checksum ? Can we have a generic hook into the FPGA framework ?
> 
This checksum is to ensure integrity of RBF file after loading from
flash into SDRAM. This can help to prevent possibility system
instability caused by programming corrupt rbf into FPGA. So, this
should be implemented in cff.c .
> > 
> > 5: support raw flash without fs.
> This should go into common code.
> 
raw flash is part of common codes in cff.c because it is part of
mechanism like fs to determine how loading rbf from flash and program
into fpga.
> > 
> > 6: support the file name defined in DTS and U-boot environment
> > variable.
> I think you should extend the FPGA LOADFS here instead.
> 
The peripheral rbf filename and DTS are generated from our bsp tool.
But user can run fpga loadfs to reconfigure FPGA in U-boot console
after i have supported it.
> > 
> > > 
> > >  Also, the ifdeffery is awful and the explicit
> > > depedence on VFAT when loading from FS is real bad.
> > > 
> > It is because a lot functions is common to sdmmc, nand and qspi in
> > different fs such as vfat, ubi and raw. It is unavoidable to have
> > some
> > ifdeffery if we want to keep the function common to all flashes and
> > fs. 
> Can the FPGA LOADFS be extended generically ?
> 
Yeah, FPGA loadfs is considered when design cff.c. But, i plan to to
support FPGA loadfs after having complete boot to U-boot console.
> > 
> > > 
> > > [...]
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2] arm: dts: am33xx: sync DTS with Linux 4.13-rc4

[sunil . m]

From: Suniel Mahesh 

This re-syncs AM33xx DTS file with current file from
Linux v4.13-rc4 to ensure a consistent configuration. Upstream
Linux removed the redundant Interrupt-parent property from mmc,
mac, lcdc and tscadc sub nodes.

Signed-off-by: Suniel Mahesh 
---
Changes for v2:
- Made corrections as suggested by Tom Rini
- Rebased and compile tested on latest u-boot mainline tree no build issues.

Note:
- commit information upstream Linux:
  arm: dts: am33xx: Remove redundant interrupt-parent property
  sha1: de09eb52a1cceb6f80464a008c67c7bebb242314
---
 arch/arm/dts/am33xx.dtsi | 6 --
 1 file changed, 6 deletions(-)

diff --git a/arch/arm/dts/am33xx.dtsi b/arch/arm/dts/am33xx.dtsi
index b26e21b..14caee7 100644
--- a/arch/arm/dts/am33xx.dtsi
+++ b/arch/arm/dts/am33xx.dtsi
@@ -315,7 +315,6 @@
 25>;
dma-names = "tx", "rx";
interrupts = <64>;
-   interrupt-parent = <>;
reg = <0x4806 0x1000>;
status = "disabled";
};
@@ -328,7 +327,6 @@
 3>;
dma-names = "tx", "rx";
interrupts = <28>;
-   interrupt-parent = <>;
reg = <0x481d8000 0x1000>;
status = "disabled";
};
@@ -338,7 +336,6 @@
ti,hwmods = "mmc3";
ti,needs-special-reset;
interrupts = <29>;
-   interrupt-parent = <>;
reg = <0x4781 0x1000>;
status = "disabled";
};
@@ -724,7 +721,6 @@
   0x4a101200 0x100>;
#address-cells = <1>;
#size-cells = <1>;
-   interrupt-parent = <>;
/*
 * c0_rx_thresh_pend
 * c0_rx_pend
@@ -787,7 +783,6 @@
lcdc: lcdc@4830e000 {
compatible = "ti,am33xx-tilcdc";
reg = <0x4830e000 0x1000>;
-   interrupt-parent = <>;
interrupts = <36>;
ti,hwmods = "lcdc";
status = "disabled";
@@ -796,7 +791,6 @@
tscadc: tscadc@44e0d000 {
compatible = "ti,am3359-tscadc";
reg = <0x44e0d000 0x1000>;
-   interrupt-parent = <>;
interrupts = <16>;
ti,hwmods = "adc_tsc";
status = "disabled";
-- 
1.9.1

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

[U-Boot] [PATCH 04/12] arm: dra76: Add support for ES1.0 detection

[Lokesh Vutla]

From: Praneeth Bajjuri 

dra76 family is a high-performance, infotainment application
device, based on OMAP architecture on a 28-nm technology.
This contains most of the subsystems, peripherals that are
available on dra74, dra72 family. This SoC mainly features
Subsystems:
- 2 x Cortex-A15 with max speed of 1.8GHz
- 2 X DSP
- 2 X Cortex-M4 IPU
- ISS
- CAL
- DSS
- VPE
- VIP
Connectivity peripherals:
- 1 USB3.0 and 3 USB2.0 subsystems
- 2 x SATA
- 2 x PCI Express Gen2
- 3-port Gigabit ethernet switch
- 2 x CAN
- MCAN

Adding CPU detection support for the dra76 ES1.0 soc
and update prcm, control module, dplls data.

Signed-off-by: Praneeth Bajjuri 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/include/asm/arch-omap5/omap.h |  1 +
 arch/arm/include/asm/omap_common.h |  8 
 arch/arm/mach-omap2/omap5/hw_data.c| 27 +++
 arch/arm/mach-omap2/omap5/hwinit.c |  3 +++
 4 files changed, 39 insertions(+)

diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
b/arch/arm/include/asm/arch-omap5/omap.h
index 2f005dd3ad..3e15839858 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -58,6 +58,7 @@
 #define OMAP5430_CONTROL_ID_CODE_ES2_0  0x1B94202F
 #define OMAP5432_CONTROL_ID_CODE_ES1_0 0x0B99802F
 #define OMAP5432_CONTROL_ID_CODE_ES2_0  0x1B99802F
+#define DRA762_CONTROL_ID_CODE_ES1_0   0x0BB5002F
 #define DRA752_CONTROL_ID_CODE_ES1_0   0x0B99002F
 #define DRA752_CONTROL_ID_CODE_ES1_1   0x1B99002F
 #define DRA752_CONTROL_ID_CODE_ES2_0   0x2B99002F
diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index ef5c481349..e951b232d6 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -722,6 +722,7 @@ static inline u8 is_omap54xx(void)
 
 #define DRA7XX 0x0700
 #define DRA72X 0x0720
+#define DRA76X 0x0760
 
 static inline u8 is_dra7xx(void)
 {
@@ -734,6 +735,12 @@ static inline u8 is_dra72x(void)
extern u32 *const omap_si_rev;
return (*omap_si_rev & 0xFFF0) == DRA72X;
 }
+
+static inline u8 is_dra76x(void)
+{
+   extern u32 *const omap_si_rev;
+   return ((*omap_si_rev & 0xFFF0) == DRA76X);
+}
 #endif
 
 /*
@@ -761,6 +768,7 @@ static inline u8 is_dra72x(void)
 #define OMAP5432_ES2_0  0x54320200
 
 /* DRA7XX */
+#define DRA762_ES1_0   0x07620100
 #define DRA752_ES1_0   0x07520100
 #define DRA752_ES1_1   0x07520110
 #define DRA752_ES2_0   0x07520200
diff --git a/arch/arm/mach-omap2/omap5/hw_data.c 
b/arch/arm/mach-omap2/omap5/hw_data.c
index a8a6b8a869..4c4e245a6e 100644
--- a/arch/arm/mach-omap2/omap5/hw_data.c
+++ b/arch/arm/mach-omap2/omap5/hw_data.c
@@ -113,6 +113,16 @@ static const struct dpll_params 
per_dpll_params_768mhz_dra7xx[NUM_SYS_CLKS] = {
{10, 0, 4, 1, 3, 4, 4, 2, -1, -1, -1, -1},  /* 38.4 MHz */
 };
 
+static const struct dpll_params per_dpll_params_768mhz_dra76x[NUM_SYS_CLKS] = {
+   {32, 0, 4, 1, 3, 4, 8, 2, -1, -1, -1, -1},  /* 12 MHz   */
+   {96, 4, 4, 1, 3, 4, 8, 2, -1, -1, -1, -1},  /* 20 MHz   */
+   {160, 6, 4, 1, 3, 4, 8, 2, -1, -1, -1, -1}, /* 16.8 MHz */
+   {20, 0, 4, 1, 3, 4, 8, 2, -1, -1, -1, -1},  /* 19.2 MHz */
+   {192, 12, 4, 1, 3, 4, 8, 2, -1, -1, -1, -1},/* 26 MHz   */
+   {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 27 MHz   */
+   {10, 0, 4, 1, 3, 4, 8, 2, -1, -1, -1, -1},  /* 38.4 MHz */
+};
+
 static const struct dpll_params iva_dpll_params_2330mhz[NUM_SYS_CLKS] = {
{1165, 11, -1, -1, 5, 6, -1, -1, -1, -1, -1, -1},   /* 12 MHz   */
{-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 13 MHz   */
@@ -234,6 +244,17 @@ struct dplls omap5_dplls_es2 = {
.ddr = NULL
 };
 
+struct dplls dra76x_dplls = {
+   .mpu = mpu_dpll_params_1ghz,
+   .core = core_dpll_params_2128mhz_dra7xx,
+   .per = per_dpll_params_768mhz_dra76x,
+   .abe = abe_dpll_params_sysclk2_361267khz,
+   .iva = iva_dpll_params_2330mhz_dra7xx,
+   .usb = usb_dpll_params_1920mhz,
+   .ddr =  ddr_dpll_params_2664mhz,
+   .gmac = gmac_dpll_params_2000mhz,
+};
+
 struct dplls dra7xx_dplls = {
.mpu = mpu_dpll_params_1ghz,
.core = core_dpll_params_2128mhz_dra7xx,
@@ -700,6 +721,12 @@ void __weak hw_data_init(void)
*ctrl = _ctrl;
break;
 
+   case DRA762_ES1_0:
+   *prcm = _prcm;
+   *dplls_data = _dplls;
+   *ctrl = _ctrl;
+   break;
+
case DRA752_ES1_0:
case DRA752_ES1_1:
case DRA752_ES2_0:
diff --git a/arch/arm/mach-omap2/omap5/hwinit.c 
b/arch/arm/mach-omap2/omap5/hwinit.c
index 2050560a37..e54547b5d9 100644
--- a/arch/arm/mach-omap2/omap5/hwinit.c
+++ b/arch/arm/mach-omap2/omap5/hwinit.c
@@ -362,6 +362,9 @@ void