April 2019 - U-Boot

[U-Boot] [PATCH V3 1/2] davinci: da850evm/omapl138-lcdk: Move BSS to SDRAM because SRAM is full
by Adam Ford 12 Apr '19

12 Apr '19

In order to fully support SPL_OF_CONTROL, we need BSS to be a bit larger. This patch relocates BSS to SDRAM instead of SRAM which is similar to how ARMv7 boards (like OMAP2+) do it. This means two new variables are required: CONFIG_SPL_BSS_START_ADDR set to DAVINCI_DDR_EMIF_DATA_BASE CONFIG_SPL_BSS_MAX_SIZE is set to 0x1080000 which is 1 byte before the location where U-Boot will load. Signed-off-by: Adam Ford <aford173(a)gmail.com> --- V2: No Change V3: Fix omapl138-lcdk so it builds. diff --git a/board/davinci/da8xxevm/u-boot-spl-da850evm.lds b/board/davinci/da8xxevm/u-boot-spl-da850evm.lds index 7b5fab7756..8f04911306 100644 --- a/board/davinci/da8xxevm/u-boot-spl-da850evm.lds +++ b/board/davinci/da8xxevm/u-boot-spl-da850evm.lds @@ -10,6 +10,9 @@ MEMORY { .sram : ORIGIN = IMAGE_TEXT_BASE,\ LENGTH = CONFIG_SPL_MAX_FOOTPRINT } +MEMORY { .sdram : ORIGIN = CONFIG_SPL_BSS_START_ADDR, \ + LENGTH = CONFIG_SPL_BSS_MAX_SIZE } + OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") OUTPUT_ARCH(arm) ENTRY(_start) @@ -42,6 +45,15 @@ SECTIONS __rel_dyn_end = .; } >.sram + __image_copy_end = .; + + .end : + { + *(.__end) + } + + _image_binary_end = .; + .bss : { . = ALIGN(4); @@ -49,12 +61,5 @@ SECTIONS *(.bss*) . = ALIGN(4); __bss_end = .; - } >.sram - - __image_copy_end = .; - - .end : - { - *(.__end) - } + } >.sdram } diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h index 14a3046f19..bb549e363a 100644 --- a/include/configs/da850evm.h +++ b/include/configs/da850evm.h @@ -48,7 +48,8 @@ #define PHYS_SDRAM_1 DAVINCI_DDR_EMIF_DATA_BASE /* DDR Start */ #define PHYS_SDRAM_1_SIZE (64 << 20) /* SDRAM size 64MB */ #define CONFIG_MAX_RAM_BANK_SIZE (512 << 20) /* max size from SPRS586*/ - +#define CONFIG_SPL_BSS_START_ADDR DAVINCI_DDR_EMIF_DATA_BASE +#define CONFIG_SPL_BSS_MAX_SIZE 0x1080000 /* memtest start addr */ #define CONFIG_SYS_MEMTEST_START (PHYS_SDRAM_1 + 0x2000000) diff --git a/include/configs/omapl138_lcdk.h b/include/configs/omapl138_lcdk.h index 2002444e42..e592df1aea 100644 --- a/include/configs/omapl138_lcdk.h +++ b/include/configs/omapl138_lcdk.h @@ -43,6 +43,9 @@ #define PHYS_SDRAM_1_SIZE (128 << 20) /* SDRAM size 128MB */ #define CONFIG_MAX_RAM_BANK_SIZE (512 << 20) /* max size from SPRS586*/ +#define CONFIG_SPL_BSS_START_ADDR DAVINCI_DDR_EMIF_DATA_BASE +#define CONFIG_SPL_BSS_MAX_SIZE 0x1080000 + /* memtest start addr */ #define CONFIG_SYS_MEMTEST_START (PHYS_SDRAM_1 + 0x2000000) -- 2.17.1

2 4

[U-Boot] [PATCH v3 1/3] Add support for the MT41K128M16JT125K memory modules
by Martyn Welch 12 Apr '19

12 Apr '19

From: Sjoerd Simons <sjoerd.simons(a)collabora.co.uk> Add configuration for the MT41K128M16JT125K memory modules as used on the Bosch Guardian device. Based on a patch by: Govindaraji Sivanantham <Govindaraji.Sivanantham(a)in.bosch.com> Signed-off-by: Sjoerd Simons <sjoerd.simons(a)collabora.co.uk> [checkpatch.pl cleanup by Martyn Welch] Signed-off-by: Martyn Welch <martyn.welch(a)collabora.com> --- Changes in v3: None Changes in v2: None arch/arm/include/asm/arch-am33xx/ddr_defs.h | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/arch/arm/include/asm/arch-am33xx/ddr_defs.h b/arch/arm/include/asm/arch-am33xx/ddr_defs.h index d8ddecc0bd..15a5b641ff 100644 --- a/arch/arm/include/asm/arch-am33xx/ddr_defs.h +++ b/arch/arm/include/asm/arch-am33xx/ddr_defs.h @@ -84,6 +84,22 @@ #define MT41K128MJT187E_PHY_FIFO_WE 0x100 #define MT41K128MJT187E_IOCTRL_VALUE 0x18B +/* Micron MT41K128M16JT-125 IT:K (256 MB) at 400MHz */ +#define MT41K128M16JT125K_EMIF_READ_LATENCY 0x07 +#define MT41K128M16JT125K_EMIF_TIM1 0x0AAAD4DB +#define MT41K128M16JT125K_EMIF_TIM2 0x2A437FDA +#define MT41K128M16JT125K_EMIF_TIM3 0x501F83FF +#define MT41K128M16JT125K_EMIF_SDCFG 0x61A052B2 +#define MT41K128M16JT125K_EMIF_SDREF 0x00000C30 +#define MT41K128M16JT125K_ZQ_CFG 0x50074BE4 +#define MT41K128M16JT125K_RATIO 0x80 +#define MT41K128M16JT125K_INVERT_CLKOUT 0x0 +#define MT41K128M16JT125K_RD_DQS 0x38 +#define MT41K128M16JT125K_WR_DQS 0x46 +#define MT41K128M16JT125K_PHY_WR_DATA 0x7D +#define MT41K128M16JT125K_PHY_FIFO_WE 0x9B +#define MT41K128M16JT125K_IOCTRL_VALUE 0x18B + /* Micron MT41J64M16JT-125 */ #define MT41J64MJT125_EMIF_SDCFG 0x61C04A32 -- 2.20.1

3 6

[U-Boot] [PATCH] am57xx_evm_defconfig: Enable configs to support QSPI boot
by Vignesh R 12 Apr '19

12 Apr '19

AM57xx IDK EVMs can boot out of QSPI. Enable configs to support QSPI boot. Also enable configs for updating QSPI boot images over DFU. Tested on AM572x IDK EVM. Signed-off-by: Vignesh R <vigneshr(a)ti.com> --- configs/am57xx_evm_defconfig | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/configs/am57xx_evm_defconfig b/configs/am57xx_evm_defconfig index 748682036e17..3f73f259751c 100644 --- a/configs/am57xx_evm_defconfig +++ b/configs/am57xx_evm_defconfig @@ -40,9 +40,13 @@ CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y CONFIG_DM=y CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y +CONFIG_SPL_REGMAP=y +CONFIG_SPL_SYSCON=y +CONFIG_SPL_OF_TRANSLATE=y CONFIG_DWC_AHCI=y CONFIG_DFU_MMC=y CONFIG_DFU_RAM=y +CONFIG_DFU_SF=y CONFIG_USB_FUNCTION_FASTBOOT=y CONFIG_FASTBOOT_BUF_ADDR=0x82000000 CONFIG_FASTBOOT_BUF_SIZE=0x2F000000 -- 2.20.1

2 2

[U-Boot] [PATCH v3 0/7] Add netcp networking support on K2G ICE EVM
by Murali Karicheri 12 Apr '19

12 Apr '19

This patch series add networking capability to K2G ICE EVM based on netcp driver. Networking function has been tested using the latest master branch from u-boot repo. Following boot mode has been tested for networking. Net boot (tftp images over ethernet interface and boot kernel) log at https://pastebin.ubuntu.com/p/b3nyCXPhWc/ MMC boot: (load images from boot folder of rootfs and boot kernel) log at https://pastebin.ubuntu.com/p/FWycmKd9KB/ Used Linux upstream linux kernel version 4.19.9 for the tests. Please review and apply if this looks good. Thanks Revision history: v3: Addressed comment to use KConfig for enable TI PHY driver and also netcp driver comment to use proper function as in cpsw driver. Rebased to latest on master branch. v2: Collected Reviewed-by for patch 1 and 2. Rebased to latest on master Murali Karicheri (7): ARM: k2g-ice: Add pinmux support for rgmii interface ARM: k2g-gp-evm: update to rgmii pinmux configuration net: netcp: add support for phy with rgmii ids ARM: k2g: add a workaround to reset the phy ARM: dts: k2g-evm: remove unused phy-mode property from phy node k2g: config enable ti phy dp83867 for k2g ARM: dts: k2g-ice: add dt node for netcp arch/arm/dts/keystone-k2g-evm.dts | 1 - arch/arm/dts/keystone-k2g-ice.dts | 35 +++++++++++++ .../mach-keystone/include/mach/hardware-k2g.h | 3 ++ arch/arm/mach-keystone/include/mach/mux-k2g.h | 5 ++ board/ti/ks2_evm/board_k2g.c | 15 ++++++ board/ti/ks2_evm/mux-k2g.h | 51 +++++++++++++------ configs/k2g_evm_defconfig | 1 + drivers/net/ti/keystone_net.c | 22 +++++++- 8 files changed, 116 insertions(+), 17 deletions(-) -- 2.17.0

3 24

[U-Boot] [PATCH v4 0/7] AM65x: Add DMA support
by Vignesh R 12 Apr '19

12 Apr '19

This series adds DMA support for TI's AM654 SoC. v4: Convert debug prints to pr_debug()s Collect R-bs v3: Minor comment/whitespace cleanups as pointed out by Tom Rini v2: Align DT bindings with latest proposed bindings as pointed out by Peter. Merge drivers/soc/keystone into drivers/soc/ti Background: The AM65x TRM (http://www.ti.com/lit/pdf/spruid7b) describes the Data Movement Architecture which is implmented by the k3-udma driver. This DMA architecture is a big departure from 'traditional' architecture where we had either EDMA or sDMA as system DMA. Packet DMAs were used as dedicated DMAs to service only networking (K2) or USB (am335x) while other peripherals were serviced by EDMA. In AM65x the UDMA (Unified DMA) is used for all data movment within the SoC, tasked to service all peripherals (UART, McSPI, McASP, networking, etc). The NAVSS/UDMA is built around CPPI5 (Communications Port Programming Interface) and it supports Packet mode (similar to CPPI4.1 in K2 for networking) and TR mode (similar to EDMA descriptor). The data movement is done within a PSI-L fabric, all peripherals (including the UDMA-P). peripherals are not addressed by their I/O register as with traditional DMAs but with their PSI-L thread ID. To be able to use the DMA the following generic steps need to be taken: - configure a DMA channel (tchan for TX, rchan for RX) - channel mode: Packet or TR mode - for memcpy a tchan and rchan pair is used. - for packet mode RX we also need to configure a receive flow to configure the packet receiption - the source and destination threads must be paired - at minimum one pair of rings need to be configured: - tx: transfer ring and transfer completion ring - rx: free descriptor ring and receive ring When the channel setup is completed we only interract with the rings: - TX: push a descriptor to t_ring and wait for it to be pushed to the tc_ring by the UDMA-P - RX: push a descriptor to the fd_ring and wait for UDMA-P to push it back to the r_ring. Resources Management and configuration of channel and ring is handled by sending TI-SCI msgs to remote core. Patches are based on kernel patches here: https://patchwork.kernel.org/cover/10612465/ Grygorii Strashko (5): firmware: ti_sci: Add support for NAVSS resource management soc: ti: k3: add navss ringacc driver soc: ti: k3: add CPPI5 description and helpers arm64: dts: ti: k3-am65: add mcu navss nodes configs: am65x_evm_a53: Enable DMA related configs Vignesh R (2): dma: ti: add driver to K3 UDMA soc: keystone: Merge into ti specific directory arch/arm/dts/k3-am65-wakeup.dtsi | 2 +- arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 47 + arch/arm/mach-keystone/Kconfig | 8 + configs/am65x_evm_a53_defconfig | 4 +- drivers/Kconfig | 2 + drivers/dma/Kconfig | 2 + drivers/dma/Makefile | 2 + drivers/dma/ti/Kconfig | 14 + drivers/dma/ti/Makefile | 3 + drivers/dma/ti/k3-udma-hwdef.h | 184 ++ drivers/dma/ti/k3-udma.c | 1730 +++++++++++++++++ drivers/firmware/ti_sci.c | 760 +++++++- drivers/firmware/ti_sci.h | 642 ++++++ drivers/soc/Kconfig | 5 + drivers/soc/Makefile | 2 +- drivers/soc/keystone/Makefile | 3 - drivers/soc/ti/Kconfig | 26 + drivers/soc/ti/Makefile | 4 + drivers/soc/ti/k3-navss-ringacc.c | 1057 ++++++++++ .../soc/{keystone => ti}/keystone_serdes.c | 0 include/configs/ti_armv7_keystone2.h | 3 - include/dt-bindings/dma/k3-udma.h | 31 + include/linux/soc/ti/cppi5.h | 995 ++++++++++ include/linux/soc/ti/k3-navss-ringacc.h | 236 +++ include/linux/soc/ti/ti-udma.h | 24 + include/linux/soc/ti/ti_sci_protocol.h | 300 +++ scripts/config_whitelist.txt | 1 - 27 files changed, 6066 insertions(+), 21 deletions(-) create mode 100644 drivers/dma/ti/Kconfig create mode 100644 drivers/dma/ti/Makefile create mode 100644 drivers/dma/ti/k3-udma-hwdef.h create mode 100644 drivers/dma/ti/k3-udma.c create mode 100644 drivers/soc/Kconfig delete mode 100644 drivers/soc/keystone/Makefile create mode 100644 drivers/soc/ti/Kconfig create mode 100644 drivers/soc/ti/Makefile create mode 100644 drivers/soc/ti/k3-navss-ringacc.c rename drivers/soc/{keystone => ti}/keystone_serdes.c (100%) create mode 100644 include/dt-bindings/dma/k3-udma.h create mode 100644 include/linux/soc/ti/cppi5.h create mode 100644 include/linux/soc/ti/k3-navss-ringacc.h create mode 100644 include/linux/soc/ti/ti-udma.h -- 2.20.1

2 15

[U-Boot] [PATCH] regmap: fix regmap_read_poll_timeout warning about sandbox_timer_add_offset
by Neil Armstrong 12 Apr '19

12 Apr '19

When fixing sandbox test for regmap_read_poll_timeout(), the sandbox_timer_add_offset was introduced but only defined in sandbox code thus generating warnings when used out of sandbox : include/regmap.h:289:2: note: in expansion of macro 'regmap_read_poll_timeout_test' regmap_read_poll_timeout_test(map, addr, val, cond, sleep_us, \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/spi/meson_spifc.c:169:8: note: in expansion of macro 'regmap_read_poll_timeout' ret = regmap_read_poll_timeout(spifc->regmap, REG_SLAVE, data, ^~~~~~~~~~~~~~~~~~~~~~~~ drivers/spi/meson_spifc.c: In function 'meson_spifc_txrx': include/regmap.h:277:4: warning: implicit declaration of function 'sandbox_timer_add_offset' [-Wimplicit-function-declaration] This simply adds an empty static inline sandbox_timer_add_offset() implementation that will be dropped by the compiler optimization routines. Cc: Simon Glass <sjg(a)chromium.org> Reported-by: Tom Rini <trini(a)konsulko.com> Fixes: df9cf1cc08 ("test: dm: regmap: Fix the long test delay") Signed-off-by: Neil Armstrong <narmstrong(a)baylibre.com> --- include/regmap.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/include/regmap.h b/include/regmap.h index 8359c511d2..144cffbcc0 100644 --- a/include/regmap.h +++ b/include/regmap.h @@ -239,6 +239,10 @@ int regmap_raw_read_range(struct regmap *map, uint range_num, uint offset, #define regmap_get(map, type, member, valp) \ regmap_range_get(map, 0, type, member, valp) +#ifndef CONFIG_SANDBOX +static inline void sandbox_timer_add_offset(unsigned long offset) { } +#endif + /** * regmap_read_poll_timeout - Poll until a condition is met or a timeout occurs * -- 2.21.0

2 3

[U-Boot] [PATCH 0/2] Fix minor issues with Serval SoC.
by Horatiu Vultur 12 Apr '19

12 Apr '19

This patch series fix different issues with Serval. - first patch fix resets when DDR training fails. - second patch fix the detection of the board. This patch series is based on u-boot-mips/next. Horatiu Vultur (2): mips: mscc: serval: Fix reset board: mscc: serval: Fix board detect arch/mips/mach-mscc/include/mach/ddr.h | 14 ++++++++++++++ arch/mips/mach-mscc/reset.c | 5 +---- board/mscc/serval/serval.c | 2 +- 3 files changed, 16 insertions(+), 5 deletions(-) -- 2.7.4

2 3

[U-Boot] in drivers/mtd/nand/spi/core.c, what means "#ifdef CONFIG_OF"?
by Robert P. J. Day 12 Apr '19

12 Apr '19

prettu sure there is no Kbuild "config OF" setting, should that be #ifdef CONFIG_OF_CONTROL or something related? i checked for the maintainer of that file, but it listed enough alleged maintainers that i thought i would just ask the list. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

1 0

[U-Boot] [PATCH 0/4] Add Beelink GS1
by Clément Péron 12 Apr '19

12 Apr '19

This serie introduce the Beelink GS1 board with a patch for the reset on Allwinner H6. Thanks to Jagan Teki most of the Beelink GS1 device-tree is taken from the Orange Pi boards. Clément Péron (4): arm: dts: h6: move MMC pinctrl to soc arm: dts: h6: Add Beelink GS1 initial support arm: sunxi: h6: fix reset using r_wdog arm: dts: h6: minor sync with linux arch/arm/dts/Makefile | 1 + arch/arm/dts/sun50i-h6-beelink-gs1.dts | 183 ++++++++++++++++++ arch/arm/dts/sun50i-h6-orangepi.dtsi | 2 - arch/arm/dts/sun50i-h6-pine-h64.dts | 4 - arch/arm/dts/sun50i-h6.dtsi | 16 +- .../include/asm/arch-sunxi/cpu_sun50i_h6.h | 1 + arch/arm/mach-sunxi/board.c | 9 +- configs/beelink_gs1_defconfig | 15 ++ 8 files changed, 217 insertions(+), 14 deletions(-) create mode 100644 arch/arm/dts/sun50i-h6-beelink-gs1.dts create mode 100644 configs/beelink_gs1_defconfig -- 2.17.1

2 9

[U-Boot] why does "board_init_r()" accept a second arg of "ulong dest_addr"?
by Robert P. J. Day 12 Apr '19

12 Apr '19

was tracing the ARM-based boot sequence and ended up at the call to board_init_r(): void board_init_r(gd_t *new_gd, ulong dest_addr) { /* * Set up the new global data pointer. So far only x86 does this * here. * TODO(sjg(a)chromium.org): Consider doing this for all archs, or * dropping the new_gd parameter. */ ... snip ... but as i read board_init_r(), it's not clear what that routine is doing with that second argument, "dest_addr". there is no explicit reference to that argument in that routine that i can see. i backtracked to arch/arm/lib/crt0.S to see the setup for the call: /* call board_init_r(gd_t *id, ulong dest_addr) */ mov r0, r9 /* gd_t */ ldr r1, [r9, #GD_RELOCADDR] /* dest_addr */ /* call board_init_r */ #if CONFIG_IS_ENABLED(SYS_THUMB_BUILD) ldr lr, =board_init_r /* this is auto-relocated! */ bx lr #else ldr pc, =board_init_r /* this is auto-relocated! */ #endif /* we should not return here. */ #endif so i can see the assignment to registers r0 and r1, and thought maybe there's something down the road that expects that argument explicitly in r1 but i can't tell. i'm currently reading doc/README.arm-relocation to see if i've overlooked something trivially obvious, but is there a simple explanation as to the purpose of that second argument being passed to board_init_r()? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

2 3