[U-Boot] [PATCH 3/5] ARM: legoev3: disable networking

[David Lechner]

This disables networking related items in the config. The EV3 does not have
any networking hardware, so this is wasted space.

Signed-off-by: David Lechner 
---
 board/lego/ev3/legoev3.c  | 4 +---
 configs/legoev3_defconfig | 4 +---
 include/configs/legoev3.h | 2 --
 3 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/board/lego/ev3/legoev3.c b/board/lego/ev3/legoev3.c
index 69010055d3..423c2fa44b 100644
--- a/board/lego/ev3/legoev3.c
+++ b/board/lego/ev3/legoev3.c
@@ -14,8 +14,6 @@
 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -162,7 +160,7 @@ int board_init(void)
 
/* setup the SUSPSRC for ARM to control emulation suspend */
writel(readl(_syscfg_regs->suspsrc) &
-  ~(DAVINCI_SYSCFG_SUSPSRC_EMAC | DAVINCI_SYSCFG_SUSPSRC_I2C |
+  ~(DAVINCI_SYSCFG_SUSPSRC_I2C |
 DAVINCI_SYSCFG_SUSPSRC_SPI0 | DAVINCI_SYSCFG_SUSPSRC_TIMER0 |
 DAVINCI_SYSCFG_SUSPSRC_UART1),
   _syscfg_regs->suspsrc);
diff --git a/configs/legoev3_defconfig b/configs/legoev3_defconfig
index c5f54a98d3..8ee2d223fd 100644
--- a/configs/legoev3_defconfig
+++ b/configs/legoev3_defconfig
@@ -18,9 +18,7 @@ CONFIG_CMD_MMC=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_SPI=y
 # CONFIG_CMD_SETEXPR is not set
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
+# CONFIG_CMD_NET is not set
 CONFIG_CMD_EXT4=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_DIAG=y
diff --git a/include/configs/legoev3.h b/include/configs/legoev3.h
index 812fd0c14a..6972cedabf 100644
--- a/include/configs/legoev3.h
+++ b/include/configs/legoev3.h
@@ -43,7 +43,6 @@
DAVINCI_SYSCFG_SUSPSRC_TIMER0 | \
DAVINCI_SYSCFG_SUSPSRC_SPI0 |   \
DAVINCI_SYSCFG_SUSPSRC_UART1 |  \
-   DAVINCI_SYSCFG_SUSPSRC_EMAC |   \
DAVINCI_SYSCFG_SUSPSRC_I2C)
 
 /*
@@ -152,7 +151,6 @@
"run flashboot; " \
"fi"
 #define CONFIG_EXTRA_ENV_SETTINGS \
-   "hostname=EV3\0" \
"memsize=64M\0" \
"filesyssize=10M\0" \
"verify=n\0" \
-- 
2.17.0

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

[U-Boot] [PATCH 5/5] ARM: legoev3: update boot script to load uEnv.txt and .dtb

[David Lechner]

This updates the LEGO MINDSTORMS EV3 boot script to try loading a
uEnv.txt file and a da850-lego-ev3.dtb device tree during boot.

Signed-off-by: David Lechner 
---
 board/lego/ev3/README | 36 ++---
 include/configs/legoev3.h | 48 ++-
 2 files changed, 65 insertions(+), 19 deletions(-)

diff --git a/board/lego/ev3/README b/board/lego/ev3/README
index a356373249..da62a649ba 100644
--- a/board/lego/ev3/README
+++ b/board/lego/ev3/README
@@ -9,14 +9,34 @@ Booting
 ===
 
 The EV3 contains a bootloader in EEPROM that loads u-boot.bin from address 0x0
-of the spi flash memory. Using the default configuration, u-boot will check to
-see if there is a boot.scr file on the first FAT partition of the mmc. If there
-is, it will run the script and boot the kernel from the uImage file also in
-the FAT partition. Otherwise, it will load a kernel and rootfs from the flash.
-The kernel must be stored at address 0x5 on the flash and have a maximum
-size of 4MiB. The rootfs must be a squasfs image and stored at 0x45 in the
-flash and have a maximum size of 10MiB. The flash starting at 0xE5 is
-reserved for user data.
+of the SPI flash memory (with a size of 256KiB!). Because the EEPROM is read-
+only and it takes care of low level configuration (PLL and DDR), we don't use
+U-Boot to produce an SPL image.
+
+Using the default configuration, U-Boot had a boot scrips that works as 
follows:
+
+* Check to see if microSD card is present
+* If it is, try to load boot.scr from the first FAT partition
+* If loading boot.scr was successful, run it
+* Otherwise, try loading uEnv.txt
+* If loading uEnv.txt was successful, import it
+* If there is a uenvcmd variable (from uEnv.txt), run it
+* Try to load uImage from the first FAT partition
+* If it was successful, try to load da850-lego-ev3.dtb
+* If loading uImage was successful, boot it (DT is optional)
+* If none of the above was successful, try booting from flash
+
+Suggested Flash Memory Layout
+=
+
+The following is based on the default U-Boot configuration:
+
+| Image (file)   | Start Addr. | Max. Size |
+++-+---+
+| u-boot.bin | 0x0 |  0x4 (256KiB) |
+| da850-lego-ev3.dtb | 0x4 |  0x1 (64KiB)  |
+| uImage | 0x5 | 0x40 (4MiB)   |
+| rootfs (squashfs)  |0x45 | 0xa0 (10MiB)  |
 
 Writing image to flash
 ==
diff --git a/include/configs/legoev3.h b/include/configs/legoev3.h
index 9eb95bc030..7a0511f88e 100644
--- a/include/configs/legoev3.h
+++ b/include/configs/legoev3.h
@@ -84,34 +84,60 @@
"if run loadbootscr; then " \
"run bootscript; " \
"else " \
+   "if run loadbootenv; then " \
+   "echo Loaded env from ${bootenvfile};" \
+   "run importbootenv;" \
+   "fi;" \
+   "if test -n $uenvcmd; then " \
+   "echo Running uenvcmd...;" \
+   "run uenvcmd;" \
+   "fi;" \
"if run loadimage; then " \
"run mmcargs; " \
+   "if run loadfdt; then " \
+   "echo Using ${fdtfile}...;" \
+   "run fdtfixup; " \
+   "run fdtboot; "\
+   "fi; " \
"run mmcboot; " \
-   "else " \
-   "run flashargs; " \
-   "run flashboot; " \
"fi; " \
"fi; " \
-   "else " \
-   "run flashargs; " \
-   "run flashboot; " \
-   "fi"
+   "fi; "\
+   "run flashargs; " \
+   "run flashboot"
 #define CONFIG_EXTRA_ENV_SETTINGS \
+   "bootenvfile=uEnv.txt\0" \
+   "fdtfile=da850-lego-ev3.dtb\0" \
"memsize=64M\0" \
"filesyssize=10M\0" \
"verify=n\0" \
"console=ttyS1,115200n8\0" \
"bootscraddr=0xC060\0" \
+   "fdtaddr=0xC060\0" \
"loadaddr=0xC0007FC0\0" \
"filesysaddr=0xC118\0" \
"fwupdateboot=mw 0x1FFC 0x; reset\0" \
-   "mmcargs=setenv bootargs mem=${memsize} console=${console} 
root=/dev/mmcblk0p2 rw rootwait lpj=747520\0" \
+   "importbootenv=echo Importing environment...; " \
+   "env import -t ${loadaddr} ${filesize}\0" \
+   "loadbootenv=fatload mmc 0 ${loadaddr} ${bootenvfile}\0" \
+   "mmcargs=setenv bootargs console=${console} root=/dev/mmcblk0p2 rw " \
+   "rootwait ${optargs}\0" \
"mmcboot=bootm ${loadaddr}\0" \
-   "flashargs=setenv bootargs 

[U-Boot] [PATCH 4/5] ARM: legoev3: remove unused configuration options

[David Lechner]

This removes the unused clock and RAM config options that were cargo-
culted when this board was copied from the DA850 EVM.

Signed-off-by: David Lechner 
---
 include/configs/legoev3.h | 54 ---
 1 file changed, 54 deletions(-)

diff --git a/include/configs/legoev3.h b/include/configs/legoev3.h
index 6972cedabf..9eb95bc030 100644
--- a/include/configs/legoev3.h
+++ b/include/configs/legoev3.h
@@ -39,60 +39,6 @@
 
 #define CONFIG_NR_DRAM_BANKS   1 /* we have 1 bank of DRAM */
 
-#define CONFIG_SYS_DA850_SYSCFG_SUSPSRC (  \
-   DAVINCI_SYSCFG_SUSPSRC_TIMER0 | \
-   DAVINCI_SYSCFG_SUSPSRC_SPI0 |   \
-   DAVINCI_SYSCFG_SUSPSRC_UART1 |  \
-   DAVINCI_SYSCFG_SUSPSRC_I2C)
-
-/*
- * PLL configuration
- */
-
-#define CONFIG_SYS_DA850_PLL0_PLLM 24
-#define CONFIG_SYS_DA850_PLL1_PLLM 21
-
-/*
- * DDR2 memory configuration
- */
-#define CONFIG_SYS_DA850_DDR2_DDRPHYCR (DV_DDR_PHY_PWRDNEN | \
-   DV_DDR_PHY_EXT_STRBEN | \
-   (0x4 << DV_DDR_PHY_RD_LATENCY_SHIFT))
-
-#define CONFIG_SYS_DA850_DDR2_SDBCR (  \
-   (1 << DV_DDR_SDCR_MSDRAMEN_SHIFT) | \
-   (1 << DV_DDR_SDCR_DDREN_SHIFT) |\
-   (1 << DV_DDR_SDCR_SDRAMEN_SHIFT) |  \
-   (1 << DV_DDR_SDCR_BUS_WIDTH_SHIFT) |\
-   (0x3 << DV_DDR_SDCR_CL_SHIFT) | \
-   (0x2 << DV_DDR_SDCR_IBANK_SHIFT) |  \
-   (0x2 << DV_DDR_SDCR_PAGESIZE_SHIFT))
-
-/* SDBCR2 is only used if IBANK_POS bit in SDBCR is set */
-#define CONFIG_SYS_DA850_DDR2_SDBCR2 0
-
-#define CONFIG_SYS_DA850_DDR2_SDTIMR ( \
-   (14 << DV_DDR_SDTMR1_RFC_SHIFT) |   \
-   (2 << DV_DDR_SDTMR1_RP_SHIFT) | \
-   (2 << DV_DDR_SDTMR1_RCD_SHIFT) |\
-   (1 << DV_DDR_SDTMR1_WR_SHIFT) | \
-   (5 << DV_DDR_SDTMR1_RAS_SHIFT) |\
-   (8 << DV_DDR_SDTMR1_RC_SHIFT) | \
-   (1 << DV_DDR_SDTMR1_RRD_SHIFT) |\
-   (0 << DV_DDR_SDTMR1_WTR_SHIFT))
-
-#define CONFIG_SYS_DA850_DDR2_SDTIMR2 (\
-   (7 << DV_DDR_SDTMR2_RASMAX_SHIFT) | \
-   (0 << DV_DDR_SDTMR2_XP_SHIFT) | \
-   (0 << DV_DDR_SDTMR2_ODT_SHIFT) |\
-   (17 << DV_DDR_SDTMR2_XSNR_SHIFT) |  \
-   (199 << DV_DDR_SDTMR2_XSRD_SHIFT) | \
-   (0 << DV_DDR_SDTMR2_RTP_SHIFT) |\
-   (0 << DV_DDR_SDTMR2_CKE_SHIFT))
-
-#define CONFIG_SYS_DA850_DDR2_SDRCR0x0494
-#define CONFIG_SYS_DA850_DDR2_PBBPR0x30
-
 /*
  * Serial Driver info
  */
-- 
2.17.0

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

[U-Boot] [PATCH 2/5] ARM: legoev3: Move UART enable to early init

[David Lechner]

This moves the UART init for LEGO MINDSTORMS EV3 to board_early_init_f().
Some console messages were not being printed because the UART was not
enabled until later in the init process.

Signed-off-by: David Lechner 
---
 board/lego/ev3/legoev3.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/board/lego/ev3/legoev3.c b/board/lego/ev3/legoev3.c
index 5e70363588..69010055d3 100644
--- a/board/lego/ev3/legoev3.c
+++ b/board/lego/ev3/legoev3.c
@@ -132,6 +132,11 @@ void get_board_serial(struct tag_serialnr *serialnr)
 
 int board_early_init_f(void)
 {
+   /* enable the console UART */
+   writel((DAVINCI_UART_PWREMU_MGMT_FREE | DAVINCI_UART_PWREMU_MGMT_URRST |
+   DAVINCI_UART_PWREMU_MGMT_UTRST),
+  _uart1_ctrl_regs->pwremu_mgmt);
+
/*
 * Power on required peripherals
 * ARM does not have access by default to PSC0 and PSC1
@@ -166,10 +171,5 @@ int board_init(void)
if (davinci_configure_pin_mux_items(pinmuxes, ARRAY_SIZE(pinmuxes)))
return 1;
 
-   /* enable the console UART */
-   writel((DAVINCI_UART_PWREMU_MGMT_FREE | DAVINCI_UART_PWREMU_MGMT_URRST |
-   DAVINCI_UART_PWREMU_MGMT_UTRST),
-  _uart1_ctrl_regs->pwremu_mgmt);
-
return 0;
 }
-- 
2.17.0

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

[U-Boot] [PATCH 1/5] ARM: legoev3: increase flash image sizes

[David Lechner]

This increases the kernel image to 4M and the rootfs image to 10M.

It is getting hard to get a kernel image to fit in 3M.

Signed-off-by: David Lechner 
---
 board/lego/ev3/README | 4 ++--
 include/configs/legoev3.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/board/lego/ev3/README b/board/lego/ev3/README
index 1a50ca9d03..a356373249 100644
--- a/board/lego/ev3/README
+++ b/board/lego/ev3/README
@@ -14,8 +14,8 @@ see if there is a boot.scr file on the first FAT partition of 
the mmc. If there
 is, it will run the script and boot the kernel from the uImage file also in
 the FAT partition. Otherwise, it will load a kernel and rootfs from the flash.
 The kernel must be stored at address 0x5 on the flash and have a maximum
-size of 3MiB. The rootfs must be a squasfs image and stored at 0x35 in the
-flash and have a maximum size of 9.3MiB. The flash starting at 0xCB is
+size of 4MiB. The rootfs must be a squasfs image and stored at 0x45 in the
+flash and have a maximum size of 10MiB. The flash starting at 0xE5 is
 reserved for user data.
 
 Writing image to flash
diff --git a/include/configs/legoev3.h b/include/configs/legoev3.h
index 542b8f072c..812fd0c14a 100644
--- a/include/configs/legoev3.h
+++ b/include/configs/legoev3.h
@@ -164,7 +164,7 @@
"mmcargs=setenv bootargs mem=${memsize} console=${console} 
root=/dev/mmcblk0p2 rw rootwait lpj=747520\0" \
"mmcboot=bootm ${loadaddr}\0" \
"flashargs=setenv bootargs mem=${memsize} 
initrd=${filesysaddr},${filesyssize} root=/dev/ram0 rw rootfstype=squashfs 
console=${console} lpj=747520\0" \
-   "flashboot=sf probe 0; sf read ${loadaddr} 0x5 0x30; sf read 
${filesysaddr} 0x35 0x96; bootm ${loadaddr}\0" \
+   "flashboot=sf probe 0; sf read ${loadaddr} 0x5 0x40; sf read 
${filesysaddr} 0x45 0xA0; bootm ${loadaddr}\0" \
"loadimage=fatload mmc 0 ${loadaddr} uImage\0" \
"loadbootscr=fatload mmc 0 ${bootscraddr} boot.scr\0" \
"bootscript=source ${bootscraddr}\0" \
-- 
2.17.0

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

[U-Boot] [PATCH 0/5] ARM: legoev3: updates

[David Lechner]

This series contains some updates for LEGO MINDSTORMS EV3. There are a couple
of cleanups, a fix for some console messages not printing and device tree
support.

David Lechner (5):
  ARM: legoev3: increase flash image sizes
  ARM: legoev3: Move UART enable to early init
  ARM: legoev3: disable networking
  ARM: legoev3: remove unused configuration options
  ARM: legoev3: update boot script to load uEnv.txt and .dtb

 board/lego/ev3/README |  36 ++---
 board/lego/ev3/legoev3.c  |  14 +++--
 configs/legoev3_defconfig |   4 +-
 include/configs/legoev3.h | 104 ++
 4 files changed, 72 insertions(+), 86 deletions(-)

-- 
2.17.0

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

[U-Boot] Exception Level switching seems broken on RK3399

[Vicente Bergas]

Hello,
I am writing this from a standalone Sapphire board [1],
 that is, without the Excavator base board.
The CPU is the Rockchip RK3399, which implements ARMv8.0-A.

Currently the boot process is:
 1.- Boot ROM
 2.- SPL, provided as closed source binary blob [2]
 3.- ATF, closed source binary blob [3]
 (not using the one from [2] because of stability issues)
 4.- Mainline u-boot, master branch
 5.- Mainline linux, master branch

I would like to use an opensource boot process.
As a first approach I try to completely remove the ATF and
replace the SPL with the one from u-boot.
The modified boot process looks like:
 1.- Boot ROM
 2.- SPL, from mainline u-boot, master branch
 3.- Mainline u-boot, master branch
 4.- Mainline linux, master branch
But it is not working.

The replaced SPL works fine and loads u-boot.
U-boot also works fine, loads linux and jumps into it.
But then, linux never gets executed.

I have traced the issue to: arch/arm/include/asm/macro.h
 202: msr  spsr_el3, \tmp
 203: msr  elr_el3, \ep
 204: eret // This is the last instruction executed

For testing, I have also set CONFIG_ARMV8_SWITCH_TO_EL1 and
checked that switch_to_el1 from arch/arm/lib/bootm.c is not reached.

At this point I have a few questions:
 1.- Is my first approach feasible? That is, is it possible to boot
 this CPU without ATF?
 2.- If so, what should I do to make it work? Probably it is just
 a configuration issue, but I do not know what to check. [4]
 3.- Else, why do I need ATF?

Regards,
  Vicenç.

[1] http://opensource.rock-chips.com/wiki_Excavator_sapphire_board
[2] https://github.com/rockchip-linux/rkbin/tree/29mirror
[3] 
https://raw.githubusercontent.com/nightseas/armbian-build/master/packages/blobs/rockchip64/trust.img
[4]
CONFIG_ARM=y
CONFIG_ARCH_ROCKCHIP=y
CONFIG_SYS_TEXT_BASE=0x0020
CONFIG_SPL_LIBCOMMON_SUPPORT=y
CONFIG_SPL_LIBGENERIC_SUPPORT=y
CONFIG_SYS_MALLOC_F_LEN=0x4000
CONFIG_ROCKCHIP_RK3399=y
CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
CONFIG_SPL_STACK_R_ADDR=0x8
# CONFIG_PSCI_RESET is not set
CONFIG_CMD_HDMIDETECT=y
CONFIG_DEFAULT_DEVICE_TREE="rk3399-evb"
CONFIG_DEBUG_UART=y
CONFIG_BOOTDELAY=1
# CONFIG_DISPLAY_CPUINFO is not set
# CONFIG_DISPLAY_BOARDINFO is not set
CONFIG_SPL_STACK_R=y
CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
# CONFIG_CMD_IMI is not set
# CONFIG_CMD_XIMG is not set
# CONFIG_CMD_SAVEENV is not set
# CONFIG_CMD_FLASH is not set
# CONFIG_CMD_LOADB is not set
# CONFIG_CMD_LOADS is not set
CONFIG_CMD_MMC=y
CONFIG_CMD_USB=y
# CONFIG_CMD_SETEXPR is not set
# CONFIG_CMD_NET is not set
# CONFIG_DOS_PARTITION is not set
# CONFIG_ISO_PARTITION is not set
CONFIG_SPL_OF_CONTROL=y
CONFIG_REGMAP=y
CONFIG_SPL_REGMAP=y
CONFIG_SYSCON=y
CONFIG_SPL_SYSCON=y
CONFIG_CLK=y
CONFIG_SPL_CLK=y
CONFIG_ROCKCHIP_GPIO=y
CONFIG_SYS_I2C_ROCKCHIP=y
# CONFIG_MMC_WRITE is not set
# CONFIG_MMC_HW_PARTITIONING is not set
CONFIG_MMC_DW=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_ROCKCHIP=y
CONFIG_DM_ETH=y
# CONFIG_NETDEVICES is not set
CONFIG_PINCTRL=y
CONFIG_SPL_PINCTRL=y
CONFIG_PINCTRL_ROCKCHIP_RK3399=y
CONFIG_DM_PMIC=y
CONFIG_PMIC_RK8XX=y
CONFIG_REGULATOR_PWM=y
CONFIG_DM_REGULATOR_FIXED=y
CONFIG_REGULATOR_RK8XX=y
CONFIG_PWM_ROCKCHIP=y
CONFIG_RAM=y
CONFIG_SPL_RAM=y
CONFIG_BAUDRATE=150
CONFIG_DEBUG_UART_BASE=0xFF1A
CONFIG_DEBUG_UART_CLOCK=2400
CONFIG_DEBUG_UART_SHIFT=2
CONFIG_SYSRESET=y
CONFIG_USB=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_DWC3=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_GENERIC=y
CONFIG_USB_STORAGE=y
CONFIG_USB_KEYBOARD=y
CONFIG_USB_HOST_ETHER=y
CONFIG_USB_ETHER_ASIX=y
CONFIG_USB_ETHER_ASIX88179=y
CONFIG_USB_ETHER_MCS7830=y
CONFIG_USB_ETHER_RTL8152=y
CONFIG_USB_ETHER_SMSC95XX=y
CONFIG_DM_VIDEO=y
# CONFIG_BACKLIGHT_PWM is not set
# CONFIG_VIDEO_BPP8 is not set
# CONFIG_VIDEO_BPP16 is not set
# CONFIG_VIDEO_BPP32 is not set
# CONFIG_VIDEO_ANSI is not set
# CONFIG_SYS_WHITE_ON_BLACK is not set
CONFIG_DISPLAY=y
CONFIG_VIDEO_ROCKCHIP=y
CONFIG_DISPLAY_ROCKCHIP_HDMI=y
# CONFIG_FAT_WRITE is not set
CONFIG_USE_TINY_PRINTF=y
CONFIG_ERRNO_STR=y
# CONFIG_EFI_LOADER is not set
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: uniphier: rename environment variable fdt_name to fdtname

[Masahiro Yamada]

2018-05-17 19:55 GMT+09:00 Masahiro Yamada :
> For booting Linux in the generic distro mechanism, cmd/pxe.c
> retrieves the FDT file name from "fdtname" environment variable.
>
> Rename "fdt_name" to "fdtname" for easier migration to distro boot.
>
> Signed-off-by: Masahiro Yamada 
> ---

Fixup "fdtname" -> "fdtfile" in the log,
and applied to u-boot-uniphier.




>
>  arch/arm/mach-uniphier/board_late_init.c | 4 ++--
>  include/configs/uniphier.h   | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-uniphier/board_late_init.c 
> b/arch/arm/mach-uniphier/board_late_init.c
> index 9dff3f1..6a99572 100644
> --- a/arch/arm/mach-uniphier/board_late_init.c
> +++ b/arch/arm/mach-uniphier/board_late_init.c
> @@ -38,7 +38,7 @@ static int uniphier_set_fdt_file(void)
> char dtb_name[256];
> int buf_len = sizeof(dtb_name);
>
> -   if (env_get("fdt_file"))
> +   if (env_get("fdtfile"))
> return 0;   /* do nothing if it is already set */
>
> compat = fdt_stringlist_get(gd->fdt_blob, 0, "compatible", 0, NULL);
> @@ -56,7 +56,7 @@ static int uniphier_set_fdt_file(void)
>
> strncat(dtb_name, ".dtb", buf_len);
>
> -   return env_set("fdt_file", dtb_name);
> +   return env_set("fdtfile", dtb_name);
>  }
>
>  int board_late_init(void)
> diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h
> index f710c8f..b631f79 100644
> --- a/include/configs/uniphier.h
> +++ b/include/configs/uniphier.h
> @@ -168,10 +168,10 @@
> "run boot_common\0" \
> "tftpboot=tftpboot $kernel_addr_load $bootfile && " \
> "tftpboot $ramdisk_addr_r $ramdisk_file &&" \
> -   "tftpboot $fdt_addr_r $fdt_file &&" \
> +   "tftpboot $fdt_addr_r $fdtfile &&" \
> "run boot_common\0" \
> "__nfsboot=tftpboot $kernel_addr_load $bootfile && " \
> -   "tftpboot $fdt_addr_r $fdt_file &&" \
> +   "tftpboot $fdt_addr_r $fdtfile &&" \
> "setenv ramdisk_addr_r - &&" \
> "run boot_common\0"
>  #endif
> --
> 2.7.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot



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

Re: [U-Boot] [PATCH 0/4] ARM: dts: uniphier: add additional required properties for ethernet nodes

[Masahiro Yamada]

2018-05-11 18:49 GMT+09:00 Kunihiko Hayashi :
> According to the modification of linux-next,
> add required clocks and their names, resets and their names, and system
> controller properties to fix the activation issues for the ethernet
> controllers implemented on some UniPhier SoCs.
>
> Kunihiko Hayashi (4):
>   ARM: dts: uniphier: add syscon-phy-mode property to each ethernet node
>   ARM: dts: uniphier: add required clocks and resets to Pro4 ethernet
> node
>   ARM: dts: uniphier: add clock-names and reset-names to ethernet node
>   ARM: dts: uniphier: change phy-mode to 'internal' for LD11


Applied to u-boot-uniphier. Thanks.


>  arch/arm/dts/uniphier-ld11.dtsi |  5 -
>  arch/arm/dts/uniphier-ld20.dtsi |  3 +++
>  arch/arm/dts/uniphier-pro4.dtsi | 10 +++---
>  arch/arm/dts/uniphier-pxs2.dtsi |  3 +++
>  arch/arm/dts/uniphier-pxs3.dtsi |  6 ++
>  5 files changed, 23 insertions(+), 4 deletions(-)
>
> --
> 2.7.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot



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

[U-Boot] [PATCH] ARM: dts: uniphier: sync with Linux 4.17-rc6

[Masahiro Yamada]

Signed-off-by: Masahiro Yamada 
---

 arch/arm/dts/uniphier-ld11.dtsi| 2 +-
 arch/arm/dts/uniphier-ld20-ref.dts | 8 
 arch/arm/dts/uniphier-ld20.dtsi| 2 +-
 arch/arm/dts/uniphier-pxs3.dtsi| 2 +-
 4 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/uniphier-ld11.dtsi b/arch/arm/dts/uniphier-ld11.dtsi
index bf3118e..ebc68c9 100644
--- a/arch/arm/dts/uniphier-ld11.dtsi
+++ b/arch/arm/dts/uniphier-ld11.dtsi
@@ -418,7 +418,7 @@
mmc-ddr-1_8v;
mmc-hs200-1_8v;
mmc-pwrseq = <_pwrseq>;
-   cdns,phy-input-delay-legacy = <4>;
+   cdns,phy-input-delay-legacy = <9>;
cdns,phy-input-delay-mmc-highspeed = <2>;
cdns,phy-input-delay-mmc-ddr = <3>;
cdns,phy-dll-delay-sdclk = <21>;
diff --git a/arch/arm/dts/uniphier-ld20-ref.dts 
b/arch/arm/dts/uniphier-ld20-ref.dts
index 2c1a92f..440c2e6 100644
--- a/arch/arm/dts/uniphier-ld20-ref.dts
+++ b/arch/arm/dts/uniphier-ld20-ref.dts
@@ -67,3 +67,11 @@
reg = <0>;
};
 };
+
+_ether_rgmii {
+   tx {
+   pins = "RGMII_TXCLK", "RGMII_TXD0", "RGMII_TXD1",
+  "RGMII_TXD2", "RGMII_TXD3", "RGMII_TXCTL";
+   drive-strength = <9>;
+   };
+};
diff --git a/arch/arm/dts/uniphier-ld20.dtsi b/arch/arm/dts/uniphier-ld20.dtsi
index b993df8..08dab16 100644
--- a/arch/arm/dts/uniphier-ld20.dtsi
+++ b/arch/arm/dts/uniphier-ld20.dtsi
@@ -523,7 +523,7 @@
mmc-ddr-1_8v;
mmc-hs200-1_8v;
mmc-pwrseq = <_pwrseq>;
-   cdns,phy-input-delay-legacy = <4>;
+   cdns,phy-input-delay-legacy = <9>;
cdns,phy-input-delay-mmc-highspeed = <2>;
cdns,phy-input-delay-mmc-ddr = <3>;
cdns,phy-dll-delay-sdclk = <21>;
diff --git a/arch/arm/dts/uniphier-pxs3.dtsi b/arch/arm/dts/uniphier-pxs3.dtsi
index d4c458a..dc9ec62 100644
--- a/arch/arm/dts/uniphier-pxs3.dtsi
+++ b/arch/arm/dts/uniphier-pxs3.dtsi
@@ -338,7 +338,7 @@
mmc-ddr-1_8v;
mmc-hs200-1_8v;
mmc-pwrseq = <_pwrseq>;
-   cdns,phy-input-delay-legacy = <4>;
+   cdns,phy-input-delay-legacy = <9>;
cdns,phy-input-delay-mmc-highspeed = <2>;
cdns,phy-input-delay-mmc-ddr = <3>;
cdns,phy-dll-delay-sdclk = <21>;
-- 
2.7.4

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

Re: [U-Boot] [RFC][PATCH] block: Enable block cache by default

[Marek Vasut]

On 05/20/2018 12:29 AM, Tom Rini wrote:
> On Sat, May 19, 2018 at 11:39:38PM +0200, Marek Vasut wrote:
>> On 05/19/2018 10:50 PM, Tom Rini wrote:
>>> On Sat, May 19, 2018 at 08:20:30PM +0200, Marek Vasut wrote:
 On 05/19/2018 04:36 PM, Simon Glass wrote:
> On 18 May 2018 at 03:22, Marek Vasut  wrote:
>>
>> The recent ext4 cache discussion would indicate that the block cache
>> is a desired feature, yet hidden and not enabled most of the time.
>> Enable the block cache by default since it provides significant block
>> device access performance improvement and if there are some users who
>> cannot enable it ie. due to size limitations, those should disable it
>> explicitly in their board config.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Simon Glass 
>> Cc: Michal Simek 
>> Cc: Tom Rini 
>> ---
>>  drivers/block/Kconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Reviewed-by: Simon Glass 

 I was hoping to get some feedback ?
>>>
>>> So, as I was asking on IRC, can you show the code paths where this gets
>>> used outside of CONFIG_BLK and then really ext4/fat/btrfs as I do in my
>>> patch?
>>
>> Can you summarize that discussion for everyone who was not on IRC at
>> that point ?
> 
> So I posted https://patchwork.ozlabs.org/patch/913266/ and it depends on
> BLK, as without BLK it does compile but isn't useful, but also isn't
> wholly discarded (due to the invalidate call in disk/part.c).

Maybe that is what needs fixing and then this patch can be applied ?

> AFIACT
> from a quick read of the code, block cache is only useful on filesystems
> that reside on block devices.  It won't help with "just" MMC reads for
> example.  So we should only enable it by default in the case of
> filesystems that are usually on block devices being enabled.

I wonder if this not helping with raw block reads is fine or not.
Thoughts ?

> But I didn't dig through the code hard enough to see if it would be
> useful on say UBIFS or if I'm wrong about it not being in the code path
> of things like say NAND.

I don't see why this won't be useful on UBI/UBIFS . It is probably just
not implemented yet.

> But I also don't think just default y in all cases is right as that's
> adding non-trivial mounts of code on all of the platforms that don't /
> won't make use of it.

So it should be discarded if there are no users ?

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

Re: [U-Boot] [RFC][PATCH] block: Enable block cache by default

[Tom Rini]

On Sat, May 19, 2018 at 11:39:38PM +0200, Marek Vasut wrote:
> On 05/19/2018 10:50 PM, Tom Rini wrote:
> > On Sat, May 19, 2018 at 08:20:30PM +0200, Marek Vasut wrote:
> >> On 05/19/2018 04:36 PM, Simon Glass wrote:
> >>> On 18 May 2018 at 03:22, Marek Vasut  wrote:
> 
>  The recent ext4 cache discussion would indicate that the block cache
>  is a desired feature, yet hidden and not enabled most of the time.
>  Enable the block cache by default since it provides significant block
>  device access performance improvement and if there are some users who
>  cannot enable it ie. due to size limitations, those should disable it
>  explicitly in their board config.
> 
>  Signed-off-by: Marek Vasut 
>  Cc: Simon Glass 
>  Cc: Michal Simek 
>  Cc: Tom Rini 
>  ---
>   drivers/block/Kconfig | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> Reviewed-by: Simon Glass 
> >>
> >> I was hoping to get some feedback ?
> > 
> > So, as I was asking on IRC, can you show the code paths where this gets
> > used outside of CONFIG_BLK and then really ext4/fat/btrfs as I do in my
> > patch?
> 
> Can you summarize that discussion for everyone who was not on IRC at
> that point ?

So I posted https://patchwork.ozlabs.org/patch/913266/ and it depends on
BLK, as without BLK it does compile but isn't useful, but also isn't
wholly discarded (due to the invalidate call in disk/part.c).  AFIACT
from a quick read of the code, block cache is only useful on filesystems
that reside on block devices.  It won't help with "just" MMC reads for
example.  So we should only enable it by default in the case of
filesystems that are usually on block devices being enabled.

But I didn't dig through the code hard enough to see if it would be
useful on say UBIFS or if I'm wrong about it not being in the code path
of things like say NAND.

But I also don't think just default y in all cases is right as that's
adding non-trivial mounts of code on all of the platforms that don't /
won't make use of it.

-- 
Tom


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

Re: [U-Boot] [RFC][PATCH] block: Enable block cache by default

[Marek Vasut]

On 05/19/2018 10:50 PM, Tom Rini wrote:
> On Sat, May 19, 2018 at 08:20:30PM +0200, Marek Vasut wrote:
>> On 05/19/2018 04:36 PM, Simon Glass wrote:
>>> On 18 May 2018 at 03:22, Marek Vasut  wrote:

 The recent ext4 cache discussion would indicate that the block cache
 is a desired feature, yet hidden and not enabled most of the time.
 Enable the block cache by default since it provides significant block
 device access performance improvement and if there are some users who
 cannot enable it ie. due to size limitations, those should disable it
 explicitly in their board config.

 Signed-off-by: Marek Vasut 
 Cc: Simon Glass 
 Cc: Michal Simek 
 Cc: Tom Rini 
 ---
  drivers/block/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> Reviewed-by: Simon Glass 
>>
>> I was hoping to get some feedback ?
> 
> So, as I was asking on IRC, can you show the code paths where this gets
> used outside of CONFIG_BLK and then really ext4/fat/btrfs as I do in my
> patch?

Can you summarize that discussion for everyone who was not on IRC at
that point ?

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

Re: [U-Boot] [RFC][PATCH] block: Enable block cache by default

[Tom Rini]

On Sat, May 19, 2018 at 08:20:30PM +0200, Marek Vasut wrote:
> On 05/19/2018 04:36 PM, Simon Glass wrote:
> > On 18 May 2018 at 03:22, Marek Vasut  wrote:
> >>
> >> The recent ext4 cache discussion would indicate that the block cache
> >> is a desired feature, yet hidden and not enabled most of the time.
> >> Enable the block cache by default since it provides significant block
> >> device access performance improvement and if there are some users who
> >> cannot enable it ie. due to size limitations, those should disable it
> >> explicitly in their board config.
> >>
> >> Signed-off-by: Marek Vasut 
> >> Cc: Simon Glass 
> >> Cc: Michal Simek 
> >> Cc: Tom Rini 
> >> ---
> >>  drivers/block/Kconfig | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > Reviewed-by: Simon Glass 
> 
> I was hoping to get some feedback ?

So, as I was asking on IRC, can you show the code paths where this gets
used outside of CONFIG_BLK and then really ext4/fat/btrfs as I do in my
patch?

-- 
Tom


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

Re: [U-Boot] [RFC][PATCH] block: Enable block cache by default

[Marek Vasut]

On 05/19/2018 04:36 PM, Simon Glass wrote:
> On 18 May 2018 at 03:22, Marek Vasut  wrote:
>>
>> The recent ext4 cache discussion would indicate that the block cache
>> is a desired feature, yet hidden and not enabled most of the time.
>> Enable the block cache by default since it provides significant block
>> device access performance improvement and if there are some users who
>> cannot enable it ie. due to size limitations, those should disable it
>> explicitly in their board config.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Simon Glass 
>> Cc: Michal Simek 
>> Cc: Tom Rini 
>> ---
>>  drivers/block/Kconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Reviewed-by: Simon Glass 
> 
I was hoping to get some feedback ?

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

Re: [U-Boot] [PATCH V3 1/2] mmc: add HS400 support

[Fabio Estevam]

On Sat, May 19, 2018 at 9:54 AM, Peng Fan  wrote:
> Add HS400 support.
> Selecting HS400 needs first select HS199 according to spec, so use

I think you meant HS200 instead?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] malloc: Use malloc simple before malloc is fully initialized in memalign()

[Simon Glass]

Hi Ley,

On 18 May 2018 at 04:03, Ley Foon Tan  wrote:
> Follow implementation in mALLOc(). Check GD_FLG_FULL_MALLOC_INIT flag and use
> malloc_simple if GD_FLG_FULL_MALLOC_INIT is unset. Adjust the malloc bytes
> to align with the requested alignment.
>
> The original memalign() function will access mchunkptr struct to adjust the
> alignment if there is misalignment happen, but mchunkptr struct is not being
> initialized before full malloc is initialized. This cause the system crash.
>
> Signed-off-by: Ley Foon Tan 
> ---
>  common/dlmalloc.c |7 +++
>  1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/common/dlmalloc.c b/common/dlmalloc.c
> index b395eef..edaad29 100644
> --- a/common/dlmalloc.c
> +++ b/common/dlmalloc.c
> @@ -1891,6 +1891,13 @@ Void_t* mEMALIGn(alignment, bytes) size_t alignment; 
> size_t bytes;
>
>if ((long)bytes < 0) return NULL;
>
> +#if CONFIG_VAL(SYS_MALLOC_F_LEN)

How about:

if (IS_ENABLED(CONFIG_SYS_MALLOC_F))

?

> +   if (!(gd->flags & GD_FLG_FULL_MALLOC_INIT)) {
> +   nb = roundup(bytes, alignment);
> +   return malloc_simple(nb);
> +   }
> +#endif
> +
>/* If need less alignment than we give anyway, just relay to malloc */
>
>if (alignment <= MALLOC_ALIGNMENT) return mALLOc(bytes);
> --
> 1.7.1
>

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

Re: [U-Boot] [RFC][PATCH] block: Enable block cache by default

[Simon Glass]

On 18 May 2018 at 03:22, Marek Vasut  wrote:
>
> The recent ext4 cache discussion would indicate that the block cache
> is a desired feature, yet hidden and not enabled most of the time.
> Enable the block cache by default since it provides significant block
> device access performance improvement and if there are some users who
> cannot enable it ie. due to size limitations, those should disable it
> explicitly in their board config.
>
> Signed-off-by: Marek Vasut 
> Cc: Simon Glass 
> Cc: Michal Simek 
> Cc: Tom Rini 
> ---
>  drivers/block/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [U-Boot] [RFC PATCH v2 1/2] usb: fastboot: Convert USB f_fastboot to shared fastboot

[Alex Kiernan]

On Fri, May 18, 2018 at 10:42 PM Alex Kiernan 
wrote:

> Hi Sam
> On Fri, May 18, 2018 at 7:32 PM Sam Protsenko 
> wrote:

> > On 17 May 2018 at 19:13, Alex Kiernan  wrote:
> > > Convert USB fastboot code to use shared fastboot protocol.
> > >
> > > Signed-off-by: Alex Kiernan 
> > > ---
> > >
> > > Changes in v2:
> > > - remove redundant version.h
> > > - use new fastboot_get_bytes_remaining() function
> > >
> > >  drivers/fastboot/Makefile   |   4 +-
> > >  drivers/usb/gadget/f_fastboot.c | 318
> +---
> > >  2 files changed, 37 insertions(+), 285 deletions(-)
> > >

> > Hi Alex,

> > Unfortunately this patch breaks regular fastboot (over USB). At least
> > on TI BeagleBoard X15. I tested your patch series using
> > https://github.com/akiernan/u-boot.git, on branch us-fastboot-udp-v6
> > (hope it contains v2 of this patch). I'm unable to do "fastboot flash"
> > or "fastboot oem format" commands after this patch. Below some debug
> > output that can help you debug this issue.


> Do you remember if you did the 'oem format' after the 'flash' command? If
> so, likely it's got out of sync and the 'oem format' was an innocent
victim
> after the 'flash' failed...

> There's definitely a change in the data transfer which looks like it
should
> be fine, but I can imagine I've not got quite right.


I can see what I've done wrong... the transition into the USB download
phase will never actually execute as I've put it inside an impossible
conditional :(

I've pushed us-fastboot-udp-v6 which is everything apart from the USB
migration, the USB migration (including this fix) is on us-fastboot-usb-v3

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

[U-Boot] [PATCH V3 2/2] mmc: fsl_esdhc: enable HS400 feature

[Peng Fan]

The strobe dll code is ported from Linux Kernel:
drivers/mmc/host/sdhci-esdhc-imx.c
The comments are from the above file,
"For HS400 eMMC, there is a data_strobe line. This signal is generated
by the device and used for data output and CRC status response output
in HS400 mode. The frequency of this signal follows the frequency of
CLK generated by host. The host receives the data which is aligned to the
edge of data_strobe line. Due to the time delay between CLK line and
data_strobe line, if the delay time is larger than one clock cycle,
then CLK and data_strobe line will be misaligned, read error shows up.
So when the CLK is higher than 100MHz, each clock cycle is short enough,
host should configure the delay target. "

Signed-off-by: Peng Fan 
Cc: Jaehoon Chung 
Cc: Stefano Babic 
---

V3:
 remove DDR and HS400 when SD/MMC Legacy mode. 
V2:
 None

 drivers/mmc/fsl_esdhc.c | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 4528345c67..4423d526c3 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -662,6 +662,7 @@ static int esdhc_change_pinstate(struct udevice *dev)
break;
case UHS_SDR104:
case MMC_HS_200:
+   case MMC_HS_400:
ret = pinctrl_select_state(dev, "state_200mhz");
break;
default:
@@ -689,6 +690,33 @@ static void esdhc_reset_tuning(struct mmc *mmc)
}
 }
 
+static void esdhc_set_strobe_dll(struct mmc *mmc)
+{
+   struct fsl_esdhc_priv *priv = dev_get_priv(mmc->dev);
+   struct fsl_esdhc *regs = priv->esdhc_regs;
+   u32 val;
+
+   if (priv->clock > ESDHC_STROBE_DLL_CLK_FREQ) {
+   writel(ESDHC_STROBE_DLL_CTRL_RESET, >strobe_dllctrl);
+
+   /*
+* enable strobe dll ctrl and adjust the delay target
+* for the uSDHC loopback read clock
+*/
+   val = ESDHC_STROBE_DLL_CTRL_ENABLE |
+   (priv->strobe_dll_delay_target <<
+ESDHC_STROBE_DLL_CTRL_SLV_DLY_TARGET_SHIFT);
+   writel(val, >strobe_dllctrl);
+   /* wait 1us to make sure strobe dll status register stable */
+   mdelay(1);
+   val = readl(>strobe_dllstat);
+   if (!(val & ESDHC_STROBE_DLL_STS_REF_LOCK))
+   pr_warn("HS400 strobe DLL status REF not lock!\n");
+   if (!(val & ESDHC_STROBE_DLL_STS_SLV_LOCK))
+   pr_warn("HS400 strobe DLL status SLV not lock!\n");
+   }
+}
+
 static int esdhc_set_timing(struct mmc *mmc)
 {
struct fsl_esdhc_priv *priv = dev_get_priv(mmc->dev);
@@ -702,6 +730,12 @@ static int esdhc_set_timing(struct mmc *mmc)
case MMC_LEGACY:
case SD_LEGACY:
esdhc_reset_tuning(mmc);
+   writel(mixctrl, >mixctrl);
+   break;
+   case MMC_HS_400:
+   mixctrl |= MIX_CTRL_DDREN | MIX_CTRL_HS400_EN;
+   writel(mixctrl, >mixctrl);
+   esdhc_set_strobe_dll(mmc);
break;
case MMC_HS:
case MMC_HS_52:
@@ -1438,7 +1472,7 @@ static int fsl_esdhc_probe(struct udevice *dev)
 #endif
 
if (fdt_get_property(fdt, node, "no-1-8-v", NULL))
-   priv->caps &= ~(UHS_CAPS | MMC_MODE_HS200);
+   priv->caps &= ~(UHS_CAPS | MMC_MODE_HS200 | MMC_MODE_HS400);
 
/*
 * TODO:
-- 
2.14.1

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

[U-Boot] [PATCH V3 1/2] mmc: add HS400 support

[Peng Fan]

Add HS400 support.
Selecting HS400 needs first select HS199 according to spec, so use
a dedicated function for HS400.
Add HS400 related macros.
Remove the restriction of only using the low 6 bits of
EXT_CSD_CARD_TYPE, using all the 8 bits.

Signed-off-by: Peng Fan 
Cc: Jaehoon Chung 
Cc: Jean-Jacques Hiblot 
Cc: Stefano Babic 
Cc: Simon Glass 
Cc: Kishon Vijay Abraham I 
Cc: Bin Meng 
---

V3:
 Simplify code
 add error msg

V2:
 remove 4bits support from HS400, as HS400 does not support 4bits per spec.

 drivers/mmc/Kconfig |   7 +++
 drivers/mmc/mmc.c   | 137 +---
 include/mmc.h   |  11 +
 3 files changed, 128 insertions(+), 27 deletions(-)

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 3f15f85efd..a535a87a8e 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -104,6 +104,13 @@ config SPL_MMC_UHS_SUPPORT
  cards. The IO voltage must be switchable from 3.3v to 1.8v. The bus
  frequency can go up to 208MHz (SDR104)
 
+config MMC_HS400_SUPPORT
+   bool "enable HS400 support"
+   select MMC_HS200_SUPPORT
+   help
+ The HS400 mode is support by some eMMC. The bus frequency is up to
+ 200MHz. This mode requires tuning the IO.
+
 config MMC_HS200_SUPPORT
bool "enable HS200 support"
help
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index f7827f527a..3bb6a68513 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -147,6 +147,7 @@ const char *mmc_mode_name(enum bus_mode mode)
  [MMC_HS_52]   = "MMC High Speed (52MHz)",
  [MMC_DDR_52]  = "MMC DDR52 (52MHz)",
  [MMC_HS_200]  = "HS200 (200MHz)",
+ [MMC_HS_400]  = "HS400 (200MHz)",
};
 
if (mode >= MMC_MODES_END)
@@ -171,6 +172,7 @@ static uint mmc_mode2freq(struct mmc *mmc, enum bus_mode 
mode)
  [UHS_DDR50]   = 5000,
  [UHS_SDR104]  = 20800,
  [MMC_HS_200]  = 2,
+ [MMC_HS_400]  = 2,
};
 
if (mode == MMC_LEGACY)
@@ -769,6 +771,11 @@ static int mmc_set_card_speed(struct mmc *mmc, enum 
bus_mode mode)
case MMC_HS_200:
speed_bits = EXT_CSD_TIMING_HS200;
break;
+#endif
+#if CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
+   case MMC_HS_400:
+   speed_bits = EXT_CSD_TIMING_HS400;
+   break;
 #endif
case MMC_LEGACY:
speed_bits = EXT_CSD_TIMING_LEGACY;
@@ -816,7 +823,7 @@ static int mmc_get_capabilities(struct mmc *mmc)
 
mmc->card_caps |= MMC_MODE_4BIT | MMC_MODE_8BIT;
 
-   cardtype = ext_csd[EXT_CSD_CARD_TYPE] & 0x3f;
+   cardtype = ext_csd[EXT_CSD_CARD_TYPE];
mmc->cardtype = cardtype;
 
 #if CONFIG_IS_ENABLED(MMC_HS200_SUPPORT)
@@ -824,6 +831,12 @@ static int mmc_get_capabilities(struct mmc *mmc)
EXT_CSD_CARD_TYPE_HS200_1_8V)) {
mmc->card_caps |= MMC_MODE_HS200;
}
+#endif
+#if CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
+   if (cardtype & (EXT_CSD_CARD_TYPE_HS400_1_2V |
+   EXT_CSD_CARD_TYPE_HS400_1_8V)) {
+   mmc->card_caps |= MMC_MODE_HS400;
+   }
 #endif
if (cardtype & EXT_CSD_CARD_TYPE_52) {
if (cardtype & EXT_CSD_CARD_TYPE_DDR_52)
@@ -1734,10 +1747,13 @@ static int mmc_set_lowest_voltage(struct mmc *mmc, enum 
bus_mode mode,
u32 card_mask = 0;
 
switch (mode) {
+   case MMC_HS_400:
case MMC_HS_200:
-   if (mmc->cardtype & EXT_CSD_CARD_TYPE_HS200_1_8V)
+   if (mmc->cardtype & (EXT_CSD_CARD_TYPE_HS200_1_8V |
+   EXT_CSD_CARD_TYPE_HS400_1_8V))
card_mask |= MMC_SIGNAL_VOLTAGE_180;
-   if (mmc->cardtype & EXT_CSD_CARD_TYPE_HS200_1_2V)
+   if (mmc->cardtype & (EXT_CSD_CARD_TYPE_HS200_1_2V |
+   EXT_CSD_CARD_TYPE_HS400_1_2V))
card_mask |= MMC_SIGNAL_VOLTAGE_120;
break;
case MMC_DDR_52:
@@ -1773,6 +1789,13 @@ static inline int mmc_set_lowest_voltage(struct mmc 
*mmc, enum bus_mode mode,
 #endif
 
 static const struct mode_width_tuning mmc_modes_by_pref[] = {
+#if CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
+   {
+   .mode = MMC_HS_400,
+   .widths = MMC_MODE_8BIT,
+   .tuning = MMC_CMD_SEND_TUNING_BLOCK_HS200
+   },
+#endif
 #if CONFIG_IS_ENABLED(MMC_HS200_SUPPORT)
{
.mode = MMC_HS_200,
@@ -1816,6 +1839,54 @@ static const struct ext_csd_bus_width {
{MMC_MODE_1BIT, false, EXT_CSD_BUS_WIDTH_1},
 };
 
+#if CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
+static int mmc_select_hs400(struct mmc *mmc)
+{
+   int err;
+
+   /* Set timing to HS200 for tuning */
+   err = 

[U-Boot] [PATCH v3] add FIT data-position & data-offset property support

[Kelvin Cheung]

Add FIT data-position & data-offset property support for bootm,
which were already supported in SPL.

Signed-off-by: Kelvin Cheung 
---

Changes for v2:
   create fit_image_get_data_and_size() to remove duplicated code

Changes for v3:
   correct the comment

---
 common/image-fit.c | 54 +++---
 include/image.h|  2 ++
 2 files changed, 53 insertions(+), 3 deletions(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index 5b93dce..5bce02f 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -391,7 +391,7 @@ void fit_image_print(const void *fit, int image_noffset, 
const char *p)
fit_image_get_comp(fit, image_noffset, );
printf("%s  Compression:  %s\n", p, genimg_get_comp_name(comp));
 
-   ret = fit_image_get_data(fit, image_noffset, , );
+   ret = fit_image_get_data_and_size(fit, image_noffset, , );
 
 #ifndef USE_HOSTCC
printf("%s  Data Start:   ", p);
@@ -856,6 +856,54 @@ int fit_image_get_data_size(const void *fit, int noffset, 
int *data_size)
 }
 
 /**
+ * fit_image_get_data_and_size - get data and its size including
+ *  both embedded and external data
+ * @fit: pointer to the FIT format image header
+ * @noffset: component image node offset
+ * @data: double pointer to void, will hold data property's data address
+ * @size: pointer to size_t, will hold data property's data size
+ *
+ * fit_image_get_data_and_size() finds data and its size including
+ * both embedded and external data. If the property is found
+ * its data start address and size are returned to the caller.
+ *
+ * returns:
+ * 0, on success
+ * otherwise, on failure
+ */
+int fit_image_get_data_and_size(const void *fit, int noffset,
+   const void **data, size_t *size)
+{
+   bool external_data = false;
+   int offset;
+   int len;
+   int ret;
+
+   if (!fit_image_get_data_position(fit, noffset, )) {
+   external_data = true;
+   } else if (!fit_image_get_data_offset(fit, noffset, )) {
+   external_data = true;
+   /*
+* For FIT with external data, figure out where
+* the external images start. This is the base
+* for the data-offset properties in each image.
+*/
+   offset += ((fdt_totalsize(fit) + 3) & ~3);
+   }
+
+   if (external_data) {
+   debug("External Data\n");
+   ret = fit_image_get_data_size(fit, noffset, );
+   *data = fit + offset;
+   *size = len;
+   } else {
+   ret = fit_image_get_data(fit, noffset, data, size);
+   }
+
+   return ret;
+}
+
+/**
  * fit_image_hash_get_algo - get hash algorithm name
  * @fit: pointer to the FIT format image header
  * @noffset: hash node offset
@@ -1153,7 +1201,7 @@ int fit_image_verify(const void *fit, int image_noffset)
char*err_msg = "";
 
/* Get image data and data length */
-   if (fit_image_get_data(fit, image_noffset, , )) {
+   if (fit_image_get_data_and_size(fit, image_noffset, , )) {
err_msg = "Can't get image data/size";
printf("error!\n%s for '%s' hash node in '%s' image node\n",
   err_msg, fit_get_name(fit, noffset, NULL),
@@ -1875,7 +1923,7 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
bootstage_mark(bootstage_id + BOOTSTAGE_SUB_CHECK_ALL_OK);
 
/* get image data address and length */
-   if (fit_image_get_data(fit, noffset, , )) {
+   if (fit_image_get_data_and_size(fit, noffset, , )) {
printf("Could not find %s subimage data!\n", prop_name);
bootstage_error(bootstage_id + BOOTSTAGE_SUB_GET_DATA);
return -ENOENT;
diff --git a/include/image.h b/include/image.h
index df701e3..1aed910 100644
--- a/include/image.h
+++ b/include/image.h
@@ -987,6 +987,8 @@ int fit_image_get_data_offset(const void *fit, int noffset, 
int *data_offset);
 int fit_image_get_data_position(const void *fit, int noffset,
int *data_position);
 int fit_image_get_data_size(const void *fit, int noffset, int *data_size);
+int fit_image_get_data_and_size(const void *fit, int noffset,
+   const void **data, size_t *size);
 
 int fit_image_hash_get_algo(const void *fit, int noffset, char **algo);
 int fit_image_hash_get_value(const void *fit, int noffset, uint8_t **value,
-- 
1.9.1

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

Re: [U-Boot] UBIFS Problems with U-boot 2018.1 & 4.14 Linux

[Richard Weinberger]

Am Samstag, 19. Mai 2018, 01:56:33 CEST schrieb Otto Blom:
> UBIFS error (ubi0:0 pid 0): crypto_comp_decompress: cannot decompress
> 2801 bytes, compressor lzo, error -6

LZO_E_LOOKBEHIND_OVERRUN...

> UBIFS error (ubi0:0 pid 0): ubifs_decompress: cannot decompress 2801
> bytes, compressor lzo, error -6
> ubifs_decompress RC: -6 len: 4096  out_len: 3377
> UBIFS error (ubi0:0 pid 0): read_block: bad data node (block 3, inode 68)
> magic  0x6101831
> crc0xf15144c6
> node_type  1 (data node)
> group_type 0 (no node group)
> sqnum  3276
> len2849
> key(68, data, 3)
> size   4096
> compr_typ  1
> data size  2801
> data:
> UBIFS error (ubi0:0 pid 0): do_readpage: cannot read page 3 of inode
> 68, error -22
> Error reading file '/boot/Image'

So, LZO *does* return an error.
Did you edit the logs in your last mails? Or was some U-Boot silencing option
enabled?

Please double-check whether your setup is correct.
Does it work if you disable compression?

Your UBIFS image looks good.
I checked the data node by hand and was able to read that file on 4.9.100 and 
linus
as of today.

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

Re: [U-Boot] UBIFS Problems with U-boot 2018.1 & 4.14 Linux

[Richard Weinberger]

Otto,

Am Freitag, 18. Mai 2018, 23:02:17 CEST schrieb Otto Blom:
> Hallo Heiko & Richard !
> 
> Turns out the len and out_len do not match, much like you suspected.
> Out_len is 2 bytes short (4094 vs 4096) See log below
> 
> UBIFS DBG tnc: search key (5725, data, 124)
> UBIFS DBG tnc: found 1, lvl 0, n 2
> UBIFS DBG tnc: LEB 566:61864, key (5725, data, 124)
> UBIFS DBG io: LEB 566:61864, data node, length 3635
> UBIFS DBG tnc: search key (5725, data, 125)
> UBIFS DBG tnc: found 1, lvl 0, n 3
> UBIFS DBG tnc: LEB 566:65504, key (5725, data, 125)
> UBIFS DBG io: LEB 566:65504, data node, length 3411
> UBIFS DBG tnc: search key (5725, data, 126)
> UBIFS DBG tnc: found 1, lvl 0, n 4
> UBIFS DBG tnc: LEB 566:68920, key (5725, data, 126)
> UBIFS DBG io: LEB 566:68920, data node, length 3041
> UBIFS DBG tnc: search key (5725, data, 127)
> UBIFS DBG tnc: found 1, lvl 0, n 5
> UBIFS DBG tnc: LEB 566:71968, key (5725, data, 127)
> UBIFS DBG io: LEB 566:71968, data node, length 4144
> UBIFS DBG tnc: search key (5725, data, 128)
> UBIFS DBG tnc: found 1, lvl 0, n 6
> UBIFS DBG tnc: LEB 566:76112, key (5725, data, 128)
> UBIFS DBG io: LEB 566:76112, data node, length 3818
> UBIFS DBG tnc: search key (5725, data, 129)
> UBIFS DBG tnc: found 1, lvl 0, n 7
> UBIFS DBG tnc: LEB 566:79936, key (5725, data, 129)
> UBIFS DBG io: LEB 566:79936, data node, length 4061
> UBIFS DBG tnc: search key (5725, data, 130)
> UBIFS DBG io: LEB 560:17120, indexing node, length 188
> UBIFS DBG tnc: LEB 560:17120, level 0, 8 branch
> UBIFS DBG tnc: found 1, lvl 0, n 0
> UBIFS DBG tnc: LEB 566:84000, key (5725, data, 130)
> UBIFS DBG io: LEB 566:84000, data node, length 3212
> UBIFS DBG tnc: search key (5725, data, 131)
> UBIFS DBG tnc: found 1, lvl 0, n 1
> UBIFS DBG tnc: LEB 566:87216, key (5725, data, 131)
> UBIFS DBG io: LEB 566:87216, data node, length 3121
> ubifs_decompress RC: 0 len: 4096  out_len: 4094
> UBIFS error (ubi0:0 pid 0): read_block: bad data node (block 131, inode 5725)
> magic  0x6101831
> crc0x2503e06e
> node_type  1 (data node)
> group_type 0 (no node group)
> sqnum  59095
> len3121
> key(5725, data, 131)
> size   4096
> compr_typ  1
> data size  3073
> data:
> UBIFS error (ubi0:0 pid 0): do_readpage: cannot read page 131 of inode
> 5725, error -22
> Error reading file '/boot/Image'

This is U-Boot, right?
 
> 
> If I write the file system in 4.14 and attempt to mount it on 4.9 I get
> 
> root@bronte2:~# ubiattach /dev/ubi_ctrl -p /dev/mtd0 -d 0  #Create /dev/ubi8
> [   39.212876] ubi0 error: ubi_attach: PEB 51 contains corrupted VID
> header, and the data does not contain all 0xFF
> [   39.222999] ubi0 error: ubi_attach: this may be a non-UBI PEB or a
> severe VID header corruption which requires manual inspection
> [   39.234526] Volume identifier header dump:
> [   39.238601]  magic 55424921
> [   39.241725]  version   1
> [   39.244232]  vol_type  1
> [   39.246758]  copy_flag 0
> [   39.249278]  compat0
> [   39.251783]  vol_id0
> [   39.254311]  lnum  49
> [   39.256914]  data_size 0
> [   39.259429]  used_ebs  0
> [   39.261954]  data_pad  0
> [   39.264464]  sqnum 0
> [   39.266986]  hdr_crc   9a7266c9
> [   39.270108] Volume identifier header hexdump:
> [   39.274470] hexdump of PEB 51 offset 4096, length 126976[
> 39.871671] ubi0 error: ubi_attach: 1 PEBs are corrupted and preserved
> [   39.878132] Corrupted PEBs are: 51
> [   39.889469] UBI assert failed in ubi_wl_init at 1666 (pid 2455)

This makes no sense at all since the failure happens on a layer below, UBI.
attach is also not mount.

> 
> Which is the same error I get if I try to mount the file system in u-boot 
> 2018.1
> 
> Also, If I attempt to read a file that was written using 4.14 running
> 4.9 Linux I get the same error that 2018.1 U-boot reported, except I
> also get the hexdump. See below
> 
> root@bronte2:~# cp /mnt/ubifs2/boot/Image /dev/null
> [  871.157694] UBIFS error (ubi1:0 pid 2566): do_readpage: bad data
> node (block 131, inode 5725)
> [  871.166166]  magic  0x6101831
> [  871.169812]  crc0x2503e06e
> [  871.173527]  node_type  1 (data node)
> [  871.177527]  group_type 0 (no node group)
> [  871.181870]  sqnum  59095
> [  871.185157]  len3121
> [  871.188362]  key(5725, data, 131)
> [  871.192709]  size   4096
> [  871.195909]  compr_typ  1
> [  871.198876]  data size  3073
> [  871.202080]  data:

Hmmm, how and where did you create that filesystem?
Can you share it?
This should definitely work.

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

Re: [U-Boot] [PATCH v2 1/6] kconfig: re-sync with Linux 4.17-rc4

[Eugeniu Rosca]

Dear reviewers,

Please, have a look at v3 series. TIA!

Best regards,
Eugeniu.

On Wed, May 16, 2018 at 01:27:02PM +0200, Eugeniu Rosca wrote:
> Hi Petr, Masahiro, Simon,
> 
> On Wed, May 16, 2018 at 10:24:41AM +0200, Eugeniu Rosca wrote:
> > Hi Petr,
> > 
> > On Wed, May 16, 2018 at 07:09:05AM +0200, Petr Vorel wrote:
> > > Hi Eugeniu,
> > > 
> > > > 2018-05-13 2:13 GMT+09:00 Eugeniu Rosca :
> > > > > Align Kconfig to Linux 4.17-rc4 with minimal impact on non-kconfig 
> > > > > files.
> > > 
> > > > > Previous Kconfig sync was done by commit bf7ab1e70fd762 ("kconfig:
> > > > > re-sync with Linux 4.10") and it achieved almost perfect alignment 
> > > > > with
> > > > > a few (intended) exceptions, caused by below U-boot commits:
> > > 
> > > Maybe it's again something wrong with my patch, but it broke 2 builds in 
> > > travis:
> > > https://travis-ci.org/pevik/u-boot/builds/379302139
> > > 
> > > It's this branch (make testconfig works on it):
> > > https://github.com/pevik/u-boot/commits/eugeniu/kconfig.v2.test
> > 
> > Our branches match, so it's not the root cause this time.
> > I will start looking into this. Thanks for reporting.
> > I hope we provide a flawless Kconfig update to the users.
> 
> What I see both in [1] and [2] is failure of `ut dm fdt_translation`
> unit test in sandbox/sandbox_flattree environments. I can reproduce
> it myself with the delivered patch-set (see [3]), but cannot reproduce
> it on u-boot/master.
> 
> Doing basic bisecting, I can easily figure out that the issue is
> introduced by the last patch in the series, specifically commit
> ("sandbox: dts: test: Fix wrong aliases property names"). The patch
> fixing the issue is shown in [4]. The problem is no more reproduced
> afterwards, as seen in [5].
> 
> Please, feedback if you are fine with this level of analysis and the
> fix itself or maybe I should go deeper with investigation.
> 
> Anyway, based on above, the problem seems to be unrelated to the
> Kconfig/DTC update. Special thanks to Petr for reporting it.
> 
> Best regards,
> Eugeniu.
> 
> [1] https://travis-ci.org/pevik/u-boot/jobs/379302204
> [2] https://travis-ci.org/pevik/u-boot/jobs/379302206
> 
> [3] Reproducing the issue seen in [1] and [2] in sandbox:
> $ ./u-boot -d arch/sandbox/dts/test.dtb
> 
> U-Boot 2018.05-00230-ge8e03803af5b (May 16 2018 - 13:09:51 +0200)
> 
> Model: sandbox
> DRAM:  128 MiB
> MMC:   mmc2: 2 (SD), mmc1: 1 (SD), mmc0: 0 (SD)
> In:serial
> Out:   vidconsole
> Err:   vidconsole
> Model: sandbox
> SCSI:  Net:   eth0: eth@10002000, eth5: eth@10003000, eth3: sbe5, eth1: 
> eth@10004000
> IDE:   Bus 0: not available  
> Hit any key to stop autoboot:  0 
> => ut dm fdt_translation
> Test: dm_test_fdt_translation: test-fdt.c
> test/dm/test-fdt.c:444, dm_test_fdt_translation(): 0 == 
> uclass_find_device_by_seq(UCLASS_TEST_DUMMY, 0, 1, ): Expected 0, got -19
> Test: dm_test_fdt_translation: test-fdt.c (flat tree)
> test/dm/test-fdt.c:444, dm_test_fdt_translation(): 0 == 
> uclass_find_device_by_seq(UCLASS_TEST_DUMMY, 0, 1, ): Expected 0, got -19
> Failures: 2
> => 
> 
> [4] Patch fixing [3].
> diff --git a/test/dm/test-fdt.c b/test/dm/test-fdt.c
> index 8196844e89a7..66d0df5629a2 100644
> --- a/test/dm/test-fdt.c
> +++ b/test/dm/test-fdt.c
> @@ -425,7 +425,7 @@ static const struct udevice_id fdt_dummy_ids[] = {
>  };
>  
>  UCLASS_DRIVER(fdt_dummy) = {
> - .name   = "fdt_dummy",
> + .name   = "fdt-dummy",
>   .id = UCLASS_TEST_DUMMY,
>   .flags  = DM_UC_FLAG_SEQ_ALIAS,
>  };
> 
> [5] The issue is healed after applying [4]:
> $ ./u-boot -d arch/sandbox/dts/test.dtb
> 
> U-Boot 2018.05-00230-ge8e03803af5b-dirty (May 16 2018 - 13:15:13 +0200)
> 
> Model: sandbox
> DRAM:  128 MiB
> MMC:   mmc2: 2 (SD), mmc1: 1 (SD), mmc0: 0 (SD)
> In:serial
> Out:   vidconsole
> Err:   vidconsole
> Model: sandbox
> SCSI:  Net:   eth0: eth@10002000, eth5: eth@10003000, eth3: sbe5, eth1: 
> eth@10004000
> IDE:   Bus 0: not available  
> Hit any key to stop autoboot:  0 
> => ut dm fdt_translation
> Test: dm_test_fdt_translation: test-fdt.c
> Test: dm_test_fdt_translation: test-fdt.c (flat tree)
> Failures: 0
> =>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 6/6] test: dm: Fix wrong aliases property names

[Eugeniu Rosca]

After importing v4.17-rc1 Linux commit 9130ba884640 ("scripts/dtc:
Update to upstream version v1.4.6-9-gaadd0b65c987"), sandbox build
reports below warnings:

arch/sandbox/dts/test.dtb: Warning (alias_paths): /aliases: aliases property 
name must include only lowercase and '-'
arch/sandbox/dts/test.dtb: Warning (alias_paths): /aliases: aliases property 
name must include only lowercase and '-'
arch/sandbox/dts/test.dtb: Warning (alias_paths): /aliases: aliases property 
name must include only lowercase and '-'
arch/sandbox/dts/test.dtb: Warning (alias_paths): /aliases: aliases property 
name must include only lowercase and '-'

Silent them by applying the 's/_/-/' substitution in the names of the
'fdt_dummy0', 'fdt_dummy1', 'fdt_dummy2', 'fdt_dummy3' properties.

Similar DTC warnings have been recently fixed in Linux kernel, e.g. via
v4.17-rc1 commit d366c30d19f4 ("ARM: dts: STi: Fix aliases property name
for STi boards").

If done alone, the DTS update generates a failure of the
`ut dm fdt_translation` unit test in sandbox environment as seen below:

$ ./u-boot -d arch/sandbox/dts/test.dtb
---<-snip->---
=> ut dm fdt_translation
Test: dm_test_fdt_translation: test-fdt.c
test/dm/test-fdt.c:444, dm_test_fdt_translation(): 0 == 
uclass_find_device_by_seq(UCLASS_TEST_DUMMY, 0, 1, ): Expected 0, got -19
Test: dm_test_fdt_translation: test-fdt.c (flat tree)
test/dm/test-fdt.c:444, dm_test_fdt_translation(): 0 == 
uclass_find_device_by_seq(UCLASS_TEST_DUMMY, 0, 1, ): Expected 0, got -19
Failures: 2
---<-snip->---

Fix this issue in place, by updating the "name" string in the
UCLASS_DRIVER(fdt_dummy) definition, so that it matches the newly
updated aliases properties. After that, the test passes:

$ ./u-boot -d arch/sandbox/dts/test.dtb
---<-snip->---
=> ut dm fdt_translation
Test: dm_test_fdt_translation: test-fdt.c
Test: dm_test_fdt_translation: test-fdt.c (flat tree)
Failures: 0
---<-snip->---

Fixes: e8d5291824e2 ("core: ofnode: Fix translation for #size-cells == 0")
Reported-by: Petr Vorel 
Signed-off-by: Eugeniu Rosca 
---

v2->v3:
* Fixed an issue in the test code (test/dm/test-fdt.c) generated by the
  DTS update (arch/sandbox/dts/test.dts) in [PATCH v2].
* Changed commit summary line, to cover test/dm/test-fdt.c.
* Added: Reported-by: Petr Vorel 
* [Due to update] Dropped: Reviewed-by: Simon Glass 

v1->v2:
* Newly pushed

 arch/sandbox/dts/test.dts | 8 
 test/dm/test-fdt.c| 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 683b1970e0af..3e87c5c0f3fd 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -27,10 +27,10 @@
testfdt3 = "/b-test";
testfdt5 = "/some-bus/c-test@5";
testfdt8 = "/a-test";
-   fdt_dummy0 = "/translation-test@8000/dev@0,0";
-   fdt_dummy1 = "/translation-test@8000/dev@1,100";
-   fdt_dummy2 = "/translation-test@8000/dev@2,200";
-   fdt_dummy3 = "/translation-test@8000/noxlatebus@3,300/dev@42";
+   fdt-dummy0 = "/translation-test@8000/dev@0,0";
+   fdt-dummy1 = "/translation-test@8000/dev@1,100";
+   fdt-dummy2 = "/translation-test@8000/dev@2,200";
+   fdt-dummy3 = "/translation-test@8000/noxlatebus@3,300/dev@42";
usb0 = _0;
usb1 = _1;
usb2 = _2;
diff --git a/test/dm/test-fdt.c b/test/dm/test-fdt.c
index 8196844e89a7..66d0df5629a2 100644
--- a/test/dm/test-fdt.c
+++ b/test/dm/test-fdt.c
@@ -425,7 +425,7 @@ static const struct udevice_id fdt_dummy_ids[] = {
 };
 
 UCLASS_DRIVER(fdt_dummy) = {
-   .name   = "fdt_dummy",
+   .name   = "fdt-dummy",
.id = UCLASS_TEST_DUMMY,
.flags  = DM_UC_FLAG_SEQ_ALIAS,
 };
-- 
2.17.0

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

[U-Boot] [PATCH v3 4/6] scripts/dtc: Update to upstream version v1.4.6-9-gaadd0b65c987

[Eugeniu Rosca]

From: Rob Herring 

This adds the following commits from upstream:

aadd0b65c987 checks: centralize printing of property names in failure messages
88960e398907 checks: centralize printing of node path in check_msg
f1879e1a50eb Add limited read-only support for older (V2 and V3) device tree to 
libfdt.
37dea76e9700 srcpos: drop special handling of tab
65893da4aee0 libfdt: overlay: Add missing license
962a45ca034d Avoid installing pylibfdt when dependencies are missing
cd6ea1b2bea6 Makefile: Split INSTALL out into INSTALL_{PROGRAM,LIB,DATA,SCRIPT}
51b3a16338df Makefile.tests: Add LIBDL make(1) variable for portability sake
333d533a8f4d Attempt to auto-detect stat(1) being used if not given proper 
invocation
e54388015af1 dtc: Bump version to v1.4.6
a1fe86f380cb fdtoverlay: Switch from using alloca to malloc
c8d5472de3ff tests: Improve compatibility with other platforms
c81d389a10cc checks: add chosen node checks
e671852042a7 checks: add aliases node checks
d0c44ebe3f42 checks: check for #{size,address}-cells without child nodes
18a3d84bb802 checks: add string list check for *-names properties
8fe94fd6f19f checks: add string list check
6c5730819604 checks: add a string check for 'label' property
a384191eba09 checks: fix sound-dai phandle with arg property check
b260c4f610c0 Fix ambiguous grammar for devicetree rule
fe667e382bac tests: Add some basic tests for the pci_bridge checks
7975f6422260 Fix widespread incorrect use of strneq(), replace with new 
strprefixeq()
fca296445eab Add strstarts() helper function
cc392f089007 tests: Check non-matching cases for fdt_node_check_compatible()
bba26a5291c8 livetree: avoid assertion of orphan phandles with overlays
c8f8194d76cc implement strnlen for systems that need it
c8b38f65fdec libfdt: Remove leading underscores from identifiers
3b62fdaebfe5 Remove leading underscores from identifiers
2d45d1c5c65e Replace FDT_VERSION() with stringify()
2e6fe5a107b5 Fix some errors in comments
b0ae9e4b0ceb tests: Correct warning in sw_tree1.c

Commit c8b38f65fdec upstream ("libfdt: Remove leading underscores from
identifiers") changed the multiple inclusion define protection, so the
kernel's libfdt_env.h needs the corresponding update.

Signed-off-by: Rob Herring 
[ Linux commit: 9130ba884640328bb78aaa4840e5ddf06ccafb1c ]
[erosca: - Fixup conflicts in include/linux/libfdt_env.h caused by v2018.03-rc4
   commit b08c8c487083 ("libfdt: move headers to 
   and ")
 - Fix build errors in lib/libfdt/fdt_ro.c, tools/libfdt/fdt_rw.c by:
   - s/_fdt_mem_rsv/fdt_mem_rsv_/
   - s/_fdt_offset_ptr/fdt_offset_ptr_/
   - s/_fdt_check_node_offset/fdt_check_node_offset_/
   - s/_fdt_check_prop_offset/fdt_check_prop_offset_/
   - s/_fdt_find_add_string/fdt_find_add_string_/]
Signed-off-by: Eugeniu Rosca 
Reviewed-by: Simon Glass 
Reviewed-by: Masahiro Yamada 
---

v2->v3:
* Added: Reviewed-by: Simon Glass 
* Added: Reviewed-by: Masahiro Yamada 

v1-v2:
* Newly pushed

 include/linux/libfdt_env.h   |   6 +-
 lib/libfdt/fdt_ro.c  |  18 +-
 scripts/dtc/checks.c | 439 ++-
 scripts/dtc/dtc-parser.y |  17 +-
 scripts/dtc/dtc.c|   7 +-
 scripts/dtc/dtc.h|  11 +-
 scripts/dtc/flattree.c   |   2 +-
 scripts/dtc/libfdt/fdt.c |  13 +-
 scripts/dtc/libfdt/fdt.h |   6 +-
 scripts/dtc/libfdt/fdt_overlay.c |  51 
 scripts/dtc/libfdt/fdt_ro.c  | 132 ++--
 scripts/dtc/libfdt/fdt_rw.c  |  90 +++---
 scripts/dtc/libfdt/fdt_sw.c  |  24 +-
 scripts/dtc/libfdt/fdt_wip.c |  10 +-
 scripts/dtc/libfdt/libfdt.h  |  37 +--
 scripts/dtc/libfdt/libfdt_env.h  |  33 +-
 scripts/dtc/libfdt/libfdt_internal.h |  32 +-
 scripts/dtc/livetree.c   |  10 +-
 scripts/dtc/srcpos.c |   5 -
 scripts/dtc/srcpos.h |   6 +-
 scripts/dtc/util.h   |   9 +-
 scripts/dtc/version_gen.h|   2 +-
 tools/libfdt/fdt_rw.c|   2 +-
 23 files changed, 632 insertions(+), 330 deletions(-)

diff --git a/include/linux/libfdt_env.h b/include/linux/libfdt_env.h
index 0d209a649286..e2bf79c7ee8d 100644
--- a/include/linux/libfdt_env.h
+++ b/include/linux/libfdt_env.h
@@ -6,8 +6,8 @@
  * Using the same guard name as that of scripts/dtc/libfdt/libfdt_env.h
  * prevents it from being included.
  */
-#ifndef _LIBFDT_ENV_H
-#define _LIBFDT_ENV_H
+#ifndef LIBFDT_ENV_H
+#define LIBFDT_ENV_H
 
 #include 
 
@@ -27,5 +27,5 @@ typedef __be64 fdt64_t;
 
 #define strtoul(cp, endp, base)simple_strtoul(cp, endp, base)
 
-#endif /* _LIBFDT_ENV_H */
+#endif /* LIBFDT_ENV_H */
 #endif
diff --git a/lib/libfdt/fdt_ro.c b/lib/libfdt/fdt_ro.c
index 

[U-Boot] [PATCH v3 3/6] scripts/dtc: Update to upstream version v1.4.5-6-gc1e55a5513e9

[Eugeniu Rosca]

From: Rob Herring 

Pickup the fix for handling unresolved phandles in overlays.

This adds the following commits from upstream:

c1e55a5513e9 checks: fix handling of unresolved phandles for dts plugins
f8872e29ce06 tests: Avoid 64-bit arithmetic in assembler
48c91c08bcfa libfdt: add stringlist functions to linker script

Signed-off-by: Rob Herring 
[ Linux commit: e45fe7f788dd1395befe5639149ad8dacfbd94ab ]
Signed-off-by: Eugeniu Rosca 
Reviewed-by: Simon Glass 
Reviewed-by: Masahiro Yamada 
---

v2->v3:
* Added: Reviewed-by: Simon Glass 
* Added: Reviewed-by: Masahiro Yamada 

v1->v2:
* Newly pushed

 scripts/dtc/checks.c  | 9 +
 scripts/dtc/version_gen.h | 2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/scripts/dtc/checks.c b/scripts/dtc/checks.c
index 08a3a29edae3..e66138449886 100644
--- a/scripts/dtc/checks.c
+++ b/scripts/dtc/checks.c
@@ -988,6 +988,10 @@ static void check_property_phandle_args(struct check *c,
 * entries when each index position has a specific definition.
 */
if (phandle == 0 || phandle == -1) {
+   /* Give up if this is an overlay with external 
references */
+   if (dti->dtsflags & DTSF_PLUGIN)
+   break;
+
cellsize = 0;
continue;
}
@@ -1176,6 +1180,11 @@ static void check_interrupts_property(struct check *c,
prop = get_property(parent, "interrupt-parent");
if (prop) {
phandle = propval_cell(prop);
+   /* Give up if this is an overlay with external 
references */
+   if ((phandle == 0 || phandle == -1) &&
+   (dti->dtsflags & DTSF_PLUGIN))
+   return;
+
irq_node = get_node_by_phandle(root, phandle);
if (!irq_node) {
FAIL(c, dti, "Bad interrupt-parent phandle for 
%s",
diff --git a/scripts/dtc/version_gen.h b/scripts/dtc/version_gen.h
index d88393cab14a..6a4e84798966 100644
--- a/scripts/dtc/version_gen.h
+++ b/scripts/dtc/version_gen.h
@@ -1 +1 @@
-#define DTC_VERSION "DTC 1.4.5-gb1a60033"
+#define DTC_VERSION "DTC 1.4.5-gc1e55a55"
-- 
2.17.0

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

[U-Boot] [PATCH v3 2/6] board: eets: pdu001: Fix wrong default value in Kconfig

[Eugeniu Rosca]

After importing linux v4.16-rc1 commit 2c37e08464a8 ("kconfig: Warn if
choice default is not in choice"), Kconfig complains:

scripts/kconfig/conf  --syncconfig Kconfig
board/eets/pdu001/Kconfig:22:warning:\
  choice default symbol 'PDU001_RUN_LED_RED' \
  is not contained in the choice

This looks to be caused by a typo. Fix it.

Fixes: 85ab0452fefc ("arm: add support for PDU001")
Signed-off-by: Eugeniu Rosca 
Reviewed-by: Masahiro Yamada 
---

v2->v3:
* No changes.

v1->v2:
* Added: Reviewed-by: Masahiro Yamada 

 board/eets/pdu001/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/eets/pdu001/Kconfig b/board/eets/pdu001/Kconfig
index f28ba6e7bff2..e64ae28875b1 100644
--- a/board/eets/pdu001/Kconfig
+++ b/board/eets/pdu001/Kconfig
@@ -19,7 +19,7 @@ config SYS_CONFIG_NAME
 
 choice
prompt "State of Run LED"
-   default PDU001_RUN_LED_RED
+   default RUN_LED_RED
help
  The PDU001 has a bi-color (red/green) LED labeled 'Run' which
  can be used to indicate the operating state of the board. By
-- 
2.17.0

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

Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size

[Dr. Philipp Tomsich]

Marty,

> On 19 May 2018, at 12:40, Marty E. Plummer  wrote:
> 
> On Mon, May 14, 2018 at 05:56:27PM +0200, Dr. Philipp Tomsich wrote:
>> I had a bit more time to look into this and it looks as if we have two 
>> problem-spots...
>> 
>> First, there's a type-mismatch between ram_info.size (a size_t) and 
>> gd.ram_size (phys_size_t).
>> While we can increase the size of a phys_size_t to 64bit (by defining 
>> CONFIG_PHYS_64BIT),
>> the size_t will always be an unsigned int on a 32bit arm architecture.  So 
>> here's one possible
>> pitfall that should be resolved.
>> 
>> Once this is adjusted, we might just increase the width of ram_info.size to 
>> 64bit by enabling
>> CONFIG_PHYS_64BIT ... however, this comes with a caveat: the default cell 
>> sizes for the
>> FDT (via fdtdec) also increases.  I.e. if any come in our arch or the 
>> drivers still goes through
>> the fdtdec-functions, we'll end up with a problem.
>> 
>> As my test coverage is limited to 64bit targets, I can't tell whether 
>> defining the PHYS_64BIT
>> configuration would be possible for the RK3288 -- if it is, we'd have a 
>> rather easy way forward
>> and could reuse the phys_size_t for ram_info.size.
>> 
>> I'd appreciate if you could take a look at whether CONFIG_PHYS_64BIT gets us 
>> into a lot
>> of trouble on the RK3288 or whether this will trigger just a few minor 
>> adjustments...
>> 
>> Thanks,
>> Philipp.
> 
> So explain to me what you'd like me to do here, if you would. What I
> gather from this is you want me to flip CONFIG_PHYS_64BIT and see if it
> works or what? I can flash/reflash u-boot and coreboot pretty easily on
> the device, so I'm down for any sort of hardware testing needed to get
> this into a usable state.

Yes, just enable PHYS_64BIT and report on how far it goes (activating some
debug may be helpful to understand what goes wrong, if it fails).

My gut feeling is that it could work, but there’s a number of pitfalls and we 
may
not be lucky.

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

Re: [U-Boot] [xHCI] Controller failure with USB 3.0 hub

[Bin Meng]

Hi Marek,

On Sat, May 19, 2018 at 7:30 PM, Marek Vasut  wrote:
> On 05/19/2018 01:09 PM, Bin Meng wrote:
>> Hi Marek,
>
> Hi,
>
>> On Sat, May 19, 2018 at 9:03 AM, Marek Vasut  wrote:
>>> Hello Bin,
>>>
>>> I noticed a potential bug in the U-Boot xHCI implementation. I observe
>>> this one Renesas RCar Gen3 platform.
>>>
>>> If I plug a USB 3.0 hub into the root port, I see the following error:
>>>   ERROR: Configure Endpoint command returned completion code 5.
>>> If I plug a USB 3.0 stick into the root port, I do not get the error and
>>> the stick is correctly detected.
>>>
>>> Example with the USB 3.0 hub:
>>>
>>> => usb reset
>>> resetting USB...
>>> USB0:   Register 2000120 NbrPorts 2
>>> Starting the controller
>>> USB XHCI 1.00
>>> USB1:   USB EHCI 1.10
>>> USB2:   USB EHCI 1.10
>>> USB3:   USB EHCI 1.10
>>>  HERE 
>>> scanning bus 0 for devices... ERROR: Configure Endpoint command returned
>>> completion code 5.
>>
>> Completion code 5 means TRB parameter error, guess the Renesas xHC has
>> some checks on the TRB.
>
> Do you have xhci spec chapter reference/number for me too ? :)
>

I was looking at xhci spec 1.1 chapter 6.4.5 TRB Completion Codes. I
don't have Renesas xHC manual to cross check.

>> Can you try the following patch to see if it makes any difference?
>>
>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
>> index 3adb002..eec3f64 100644
>> --- a/drivers/usb/host/xhci.c
>> +++ b/drivers/usb/host/xhci.c
>> @@ -1453,6 +1453,8 @@ static int xhci_update_hub_device(struct udevice
>> *dev, struct usb_device *udev)
>> if (udev->speed == USB_SPEED_HIGH)
>> slot_ctx->tt_info |= cpu_to_le32(TT_THINK_TIME(think_time));
>>
>> +   slot_ctx->dev_state = 0;
>> +
>> return xhci_configure_endpoints(udev, false);
>>  }
>
> Doesn't make any difference, sorry.
>

Too bad. Then I don't have any obvious clue so far. The completion
code 5 is a helpful sign from xHC to the software that something was
wrong in the TRB. Per the xHCI spec, dev_state needs to be cleared. It
was working with the x86 xHC though. Changing
xhci_configure_endpoints(udev, false) to
xhci_configure_endpoints(udev, true) is not correct as the Evaluate
Context command is not used with configure the hub attributes.

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

Re: [U-Boot] [xHCI] Controller failure with USB 3.0 hub

[Marek Vasut]

On 05/19/2018 01:09 PM, Bin Meng wrote:
> Hi Marek,

Hi,

> On Sat, May 19, 2018 at 9:03 AM, Marek Vasut  wrote:
>> Hello Bin,
>>
>> I noticed a potential bug in the U-Boot xHCI implementation. I observe
>> this one Renesas RCar Gen3 platform.
>>
>> If I plug a USB 3.0 hub into the root port, I see the following error:
>>   ERROR: Configure Endpoint command returned completion code 5.
>> If I plug a USB 3.0 stick into the root port, I do not get the error and
>> the stick is correctly detected.
>>
>> Example with the USB 3.0 hub:
>>
>> => usb reset
>> resetting USB...
>> USB0:   Register 2000120 NbrPorts 2
>> Starting the controller
>> USB XHCI 1.00
>> USB1:   USB EHCI 1.10
>> USB2:   USB EHCI 1.10
>> USB3:   USB EHCI 1.10
>>  HERE 
>> scanning bus 0 for devices... ERROR: Configure Endpoint command returned
>> completion code 5.
> 
> Completion code 5 means TRB parameter error, guess the Renesas xHC has
> some checks on the TRB.

Do you have xhci spec chapter reference/number for me too ? :)

> Can you try the following patch to see if it makes any difference?
> 
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 3adb002..eec3f64 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -1453,6 +1453,8 @@ static int xhci_update_hub_device(struct udevice
> *dev, struct usb_device *udev)
> if (udev->speed == USB_SPEED_HIGH)
> slot_ctx->tt_info |= cpu_to_le32(TT_THINK_TIME(think_time));
> 
> +   slot_ctx->dev_state = 0;
> +
> return xhci_configure_endpoints(udev, false);
>  }

Doesn't make any difference, sorry.

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

Re: [U-Boot] [xHCI] Controller failure with USB 3.0 hub

[Bin Meng]

Hi Marek,

On Sat, May 19, 2018 at 9:03 AM, Marek Vasut  wrote:
> Hello Bin,
>
> I noticed a potential bug in the U-Boot xHCI implementation. I observe
> this one Renesas RCar Gen3 platform.
>
> If I plug a USB 3.0 hub into the root port, I see the following error:
>   ERROR: Configure Endpoint command returned completion code 5.
> If I plug a USB 3.0 stick into the root port, I do not get the error and
> the stick is correctly detected.
>
> Example with the USB 3.0 hub:
>
> => usb reset
> resetting USB...
> USB0:   Register 2000120 NbrPorts 2
> Starting the controller
> USB XHCI 1.00
> USB1:   USB EHCI 1.10
> USB2:   USB EHCI 1.10
> USB3:   USB EHCI 1.10
>  HERE 
> scanning bus 0 for devices... ERROR: Configure Endpoint command returned
> completion code 5.

Completion code 5 means TRB parameter error, guess the Renesas xHC has
some checks on the TRB.

Can you try the following patch to see if it makes any difference?

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 3adb002..eec3f64 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1453,6 +1453,8 @@ static int xhci_update_hub_device(struct udevice
*dev, struct usb_device *udev)
if (udev->speed == USB_SPEED_HIGH)
slot_ctx->tt_info |= cpu_to_le32(TT_THINK_TIME(think_time));

+   slot_ctx->dev_state = 0;
+
return xhci_configure_endpoints(udev, false);
 }

>  HERE 
> 1 USB Device(s) found
> scanning bus 1 for devices... 1 USB Device(s) found
> scanning bus 2 for devices... 1 USB Device(s) found
> scanning bus 3 for devices... 1 USB Device(s) found
>scanning usb for storage devices... 0 Storage Device(s) found
> => usb tree
> USB device tree:
>   1  Hub (5 Gb/s, 0mA)
>  U-Boot XHCI Host Controller
>
>   1  Hub (480 Mb/s, 0mA)
>  u-boot EHCI Host Controller
>
>   1  Hub (480 Mb/s, 0mA)
>  u-boot EHCI Host Controller
>
>   1  Hub (480 Mb/s, 0mA)
>  u-boot EHCI Host Controller
>
> If I revert d228ca362b though, the setup starts working fine. In fact,
> if I just commend out xhci_update_hub_device() in xhci_usb_ops , it
> works fine as well.
>
> Moreover, if I use the following patch, it works fine too:
>
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 3adb0028f2..bd393d92bb 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -1453,7 +1453,7 @@ static int xhci_update_hub_device(struct udevice
> *dev, struct usb_device *udev)
> if (udev->speed == USB_SPEED_HIGH)
> slot_ctx->tt_info |= cpu_to_le32(TT_THINK_TIME(think_time));
>
> -   return xhci_configure_endpoints(udev, false);
> +   return xhci_configure_endpoints(udev, true);
>  }
>
>  static int xhci_get_max_xfer_size(struct udevice *dev, size_t *size)
>
> That is:
>
> => usb reset
> resetting USB...
> USB0:   Register 2000120 NbrPorts 2
> Starting the controller
> USB XHCI 1.00
> USB1:   USB EHCI 1.10
> USB2:   USB EHCI 1.10
> USB3:   USB EHCI 1.10
> scanning bus 0 for devices... 5 USB Device(s) found
> scanning bus 1 for devices... 1 USB Device(s) found
> scanning bus 2 for devices... 1 USB Device(s) found
> scanning bus 3 for devices... 1 USB Device(s) found
>scanning usb for storage devices... 2 Storage Device(s) found
> => usb tree
> USB device tree:
>   1  Hub (5 Gb/s, 0mA)
>   |  U-Boot XHCI Host Controller
>   |
>   +-2  Hub (5 Gb/s, 2mA)
>   | |  VIA Labs, Inc. 4-Port USB 3.0 Hub
>   | |
>   | +-4  Mass Storage (5 Gb/s, 224mA)
>   |  SanDisk Ultra 4C530001110620109113
>   |
>   +-3  Hub (480 Mb/s, 100mA)
> |   USB2.0 Hub
> |
> +-5  Mass Storage (480 Mb/s, 200mA)
>   USB FLASH DRIVE  195A06010623
>
>   1  Hub (480 Mb/s, 0mA)
>  u-boot EHCI Host Controller
>
>   1  Hub (480 Mb/s, 0mA)
>  u-boot EHCI Host Controller
>
>   1  Hub (480 Mb/s, 0mA)
>  u-boot EHCI Host Controller
>
> Do you have an explanation for me ?
> --

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

Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size

[Marty E. Plummer]

On Mon, May 14, 2018 at 05:56:27PM +0200, Dr. Philipp Tomsich wrote:
> I had a bit more time to look into this and it looks as if we have two 
> problem-spots...
> 
> First, there's a type-mismatch between ram_info.size (a size_t) and 
> gd.ram_size (phys_size_t).
> While we can increase the size of a phys_size_t to 64bit (by defining 
> CONFIG_PHYS_64BIT),
> the size_t will always be an unsigned int on a 32bit arm architecture.  So 
> here's one possible
> pitfall that should be resolved.
> 
> Once this is adjusted, we might just increase the width of ram_info.size to 
> 64bit by enabling
> CONFIG_PHYS_64BIT ... however, this comes with a caveat: the default cell 
> sizes for the
> FDT (via fdtdec) also increases.  I.e. if any come in our arch or the drivers 
> still goes through
> the fdtdec-functions, we'll end up with a problem.
> 
> As my test coverage is limited to 64bit targets, I can't tell whether 
> defining the PHYS_64BIT
> configuration would be possible for the RK3288 -- if it is, we'd have a 
> rather easy way forward
> and could reuse the phys_size_t for ram_info.size.
> 
> I'd appreciate if you could take a look at whether CONFIG_PHYS_64BIT gets us 
> into a lot
> of trouble on the RK3288 or whether this will trigger just a few minor 
> adjustments...
> 
> Thanks,
> Philipp.

So explain to me what you'd like me to do here, if you would. What I
gather from this is you want me to flip CONFIG_PHYS_64BIT and see if it
works or what? I can flash/reflash u-boot and coreboot pretty easily on
the device, so I'm down for any sort of hardware testing needed to get
this into a usable state.

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

[U-Boot] [BUG] efi_loader: LUV test and SCT test fail on minnowboard

[Heinrich Schuchardt]

Hello Shubha,

On 05/17/2018 09:40 PM, Macheeri Ramaswamy, ShubhashreeX wrote:
> I could successfully install build and flash the uboot with uefi over
> minnowboard (from Intel) and could use a serial console to see
> the prints.

On 05/18/2018 12:39 AM, Macheeri Ramaswamy, ShubhashreeX wrote:
> We tried running LUV test and SCT test, but both failed.

In qemu-system-x86 I am able to load 32 bit GRUB via EFI but never
succeeded to boot Linux. Linux used the video memory. And of cause video
memory is overwritten by console output.

Part of a solution might be unmerged patch
https://patchwork.ozlabs.org/patch/860400/
efi_loader: memory reservations according to e820 table
but this patch needs rework as indicated by Alex.

On x86_64 an implementation of setjmp() and longjmp() is missing. These
are necessary to use the Exit() boot service or to directly return from
an EFI binary.

On Debian building for x86_64 fails without this rejected patch:
https://patchwork.ozlabs.org/patch/812655/
spl: u-boot-spl-nodtb.bin: remove .got and .got.plt sections

Best regards

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