July 2016 - U-Boot

[U-Boot] [PATCH v5] rockchip: add option to change method of loading u-boot
by Ziyuan Xu 15 Jul '16

15 Jul '16

From: Xu Ziyuan <xzy.xu(a)rock-chips.com> If we would like to boot from SD card, we have to implement mmc driver in SPL stage, and get a slightly large SPL binary. Rockchip SoC's bootrom code has the ability to load spl and u-boot, then boot. If CONFIG_ROCKCHIP_SPL_BACK_TO_BROM is enabled, the spl will return to bootrom in board_init_f(), then bootrom loads u-boot binary. Loading sequence after rework: bootrom ==> spl ==> bootrom ==> u-boot Signed-off-by: Ziyuan Xu <xzy.xu(a)rock-chips.com> Acked-by: Simon Glass <sjg(a)chromium.org> --- Changes in v5: - Revise some typos Changes in v4: - Add acked flag from Simon - Rename to CONFIG_ROCKCHIP_SPL_BACK_TO_BROM - Add Kconfig option for this feature support - Revise some nits - Update comments a little - Update commit message Changes in v3: - Add CONFIG_ROCKCHIP_RK3288_SPL_BACKTO_BROM for enabling this feature - Update doc/README.rockchip to instruct how to use it - Detailed commit message Changes in v2: - Add sdcard iomux initlization in board_init() to fix sdmmc command sending timeout issue when booting from eMMC arch/arm/mach-rockchip/Kconfig | 8 ++++++ arch/arm/mach-rockchip/Makefile | 1 + arch/arm/mach-rockchip/board.c | 33 ++++++++++++++++++++++ arch/arm/mach-rockchip/rk3036/Makefile | 1 - arch/arm/mach-rockchip/rk3288-board-spl.c | 5 +++- .../mach-rockchip/{rk3036 => }/save_boot_param.S | 2 +- doc/README.rockchip | 14 +++++++++ include/configs/rk3288_common.h | 5 ++++ 8 files changed, 66 insertions(+), 3 deletions(-) rename arch/arm/mach-rockchip/{rk3036 => }/save_boot_param.S (90%) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index 2a8afac..6ecf9ca 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip/Kconfig @@ -17,6 +17,14 @@ config ROCKCHIP_RK3036 and video codec support. Peripherals include Gigabit Ethernet, USB2 host and OTG, SDIO, I2S, UART, SPI, I2C and PWMs. +config ROCKCHIP_SPL_BACK_TO_BROM + bool "SPL returns to bootrom" + default y if ROCKCHIP_RK3036 + help + Rochchip SoCs have ability to load SPL & U-BOOT binary. This opinion, + if enabled, SPL will return to boorom, then load U-BOOT binary to keep + going on. + config SYS_MALLOC_F default y diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile index 55567cb..c08d61b 100644 --- a/arch/arm/mach-rockchip/Makefile +++ b/arch/arm/mach-rockchip/Makefile @@ -7,6 +7,7 @@ ifdef CONFIG_SPL_BUILD obj-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board-spl.o obj-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o +obj-$(CONFIG_ROCKCHIP_SPL_BACK_TO_BROM) += save_boot_param.o else obj-$(CONFIG_ROCKCHIP_RK3288) += board.o endif diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c index 816540e..b07e073 100644 --- a/arch/arm/mach-rockchip/board.c +++ b/arch/arm/mach-rockchip/board.c @@ -10,12 +10,45 @@ #include <ram.h> #include <asm/io.h> #include <asm/arch/clock.h> +#include <asm/arch/periph.h> +#include <asm/gpio.h> +#include <dm/pinctrl.h> DECLARE_GLOBAL_DATA_PTR; int board_init(void) { +#ifdef CONFIG_ROCKCHIP_SPL_BACK_TO_BROM + struct udevice *pinctrl; + int ret; + + /* + * We need to implement sdcard iomux here for the further + * initlization, otherwise, it'll hit sdcard command sending + * timeout exception. + */ + ret = uclass_get_device(UCLASS_PINCTRL, 0, &pinctrl); + if (ret) { + debug("%s: Cannot find pinctrl device\n", __func__); + goto err; + } + ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_SDCARD); + if (ret) { + debug("%s: Failed to set up SD card\n", __func__); + goto err; + } + + return 0; +err: + printf("board_init: Error %d\n", ret); + + /* No way to report error here */ + hang(); + + return -1; +#else return 0; +#endif } int dram_init(void) diff --git a/arch/arm/mach-rockchip/rk3036/Makefile b/arch/arm/mach-rockchip/rk3036/Makefile index 97d299d..6095777 100644 --- a/arch/arm/mach-rockchip/rk3036/Makefile +++ b/arch/arm/mach-rockchip/rk3036/Makefile @@ -10,4 +10,3 @@ obj-y += syscon_rk3036.o endif obj-y += sdram_rk3036.o -obj-y += save_boot_param.o diff --git a/arch/arm/mach-rockchip/rk3288-board-spl.c b/arch/arm/mach-rockchip/rk3288-board-spl.c index 773ea42..0728e64 100644 --- a/arch/arm/mach-rockchip/rk3288-board-spl.c +++ b/arch/arm/mach-rockchip/rk3288-board-spl.c @@ -151,7 +151,7 @@ static int configure_emmc(struct udevice *pinctrl) return 0; } #endif - +extern void back_to_bootrom(void); void board_init_f(ulong dummy) { struct udevice *pinctrl; @@ -206,6 +206,9 @@ void board_init_f(ulong dummy) debug("DRAM init failed: %d\n", ret); return; } +#ifdef CONFIG_ROCKCHIP_SPL_BACK_TO_BROM + back_to_bootrom(); +#endif } static int setup_led(void) diff --git a/arch/arm/mach-rockchip/rk3036/save_boot_param.S b/arch/arm/mach-rockchip/save_boot_param.S similarity index 90% rename from arch/arm/mach-rockchip/rk3036/save_boot_param.S rename to arch/arm/mach-rockchip/save_boot_param.S index 778ec83..85b407b 100644 --- a/arch/arm/mach-rockchip/rk3036/save_boot_param.S +++ b/arch/arm/mach-rockchip/save_boot_param.S @@ -1,5 +1,5 @@ /* - * (C) Copyright 2015 Google, Inc + * (C) Copyright 2016 Rockchip Electronics Co., Ltd * * SPDX-License-Identifier: GPL-2.0+ */ diff --git a/doc/README.rockchip b/doc/README.rockchip index f4e8348..3fc2582 100644 --- a/doc/README.rockchip +++ b/doc/README.rockchip @@ -120,6 +120,20 @@ something like: Hit any key to stop autoboot: 0 => +The rockchip bootrom can load and boot an initial spl, then continue to +load a second-level bootloader(ie. U-BOOT) as soon as it returns to bootrom. +Therefore RK3288 has another loading sequence like RK3036. The option of +U-Boot is controlled with this setting in U-Boot: + + #define CONFIG_ROCKCHIP_SPL_BACK_TO_BROM + +You can create the image via the following operations: + + ./firefly-rk3288/tools/mkimage -n rk3288 -T rksd -d \ + firefly-rk3288/spl/u-boot-spl-dtb.bin out && \ + cat firefly-rk3288/u-boot-dtb.bin >> out && \ + sudo dd if=out of=/dev/sdc seek=64 + If you have an HDMI cable attached you should see a video console. For evb_rk3036 board: diff --git a/include/configs/rk3288_common.h b/include/configs/rk3288_common.h index 9d50d83..35584ac 100644 --- a/include/configs/rk3288_common.h +++ b/include/configs/rk3288_common.h @@ -33,7 +33,12 @@ #define CONFIG_SYS_NS16550_MEM32 #define CONFIG_SPL_BOARD_INIT +#ifdef CONFIG_ROCKCHIP_SPL_BACK_TO_BROM +/* Bootrom will load u-boot binary to 0x0 once return from SPL */ +#define CONFIG_SYS_TEXT_BASE 0x00000000 +#else #define CONFIG_SYS_TEXT_BASE 0x00100000 +#endif #define CONFIG_SYS_INIT_SP_ADDR 0x00100000 #define CONFIG_SYS_LOAD_ADDR 0x00800800 #define CONFIG_SPL_STACK 0xff718000 -- 1.9.1

2 3

[U-Boot] [PATCH] armv8: spl: Call board_init_r from crt0_64 in SPL
by Jeremy Hunt 15 Jul '16

15 Jul '16

As part of the startup process for boards using the SPL, the meaning of board_init_f changed such that it should return normally rather than calling board_init_r directly. (see db910353a126d84fe8dff7a694ea792f50fcfb6a) This was fixed in 32-bit arm, but broke when SPL was added to 64 bit arm. This fixes crt0_64 so that it calls board_init_r durring the SPL and removes the direct call from board_init_f from the arm SPL example. Signed-off-by: Jeremy Hunt <Jeremy.Hunt(a)DEShawResearch.com> --- arch/arm/lib/crt0_64.S | 3 +-- arch/arm/lib/spl.c | 18 +++++++++--------- 2 files changed, 10 insertions(+), 11 deletions(-) diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S index cad22c7..91b19e0 100644 --- a/arch/arm/lib/crt0_64.S +++ b/arch/arm/lib/crt0_64.S @@ -108,6 +108,7 @@ relocation_return: * Set up final (full) environment */ bl c_runtime_cpu_setup /* still call old routine */ +#endif /* !CONFIG_SPL_BUILD */ /* TODO: For SPL, call spl_relocate_stack_gd() to alloc stack relocation */ @@ -130,6 +131,4 @@ clear_loop: /* NOTREACHED - board_init_r() does not return */ -#endif /* !CONFIG_SPL_BUILD */ - ENDPROC(_main) diff --git a/arch/arm/lib/spl.c b/arch/arm/lib/spl.c index e428868..b188834 100644 --- a/arch/arm/lib/spl.c +++ b/arch/arm/lib/spl.c @@ -25,22 +25,22 @@ gd_t gdata __attribute__ ((section(".data"))); #endif /* - * In the context of SPL, board_init_f must ensure that any clocks/etc for - * DDR are enabled, ensure that the stack pointer is valid, clear the BSS - * and call board_init_r. We provide this version by default but mark it - * as __weak to allow for platforms to do this in their own way if needed. + * In the context of SPL, board_init_f() prepares the hardware for execution + * from system RAM (DRAM, DDR...). As system RAM may not be available yet, + * board_init_f() must use the current GD to store any data which must be + * passed on to later stages. These data include the relocation destination, + * the future stack, and the future GD location. BSS is cleared after this + * function (and therefore must be accessible). + * + * We provide this version by default but mark it as __weak to allow for + * platforms to do this in their own way if needed. */ void __weak board_init_f(ulong dummy) { - /* Clear the BSS. */ - memset(__bss_start, 0, __bss_end - __bss_start); - #ifndef CONFIG_SPL_DM /* TODO: Remove settings of the global data pointer here */ gd = &gdata; #endif - - board_init_r(NULL, 0); } /* -- 2.4.4

2 1

[U-Boot] Please investigate T2080QDS U-Boot
by york sun 15 Jul '16

15 Jul '16

Shengzhou, Can you investigate this message on T2080QDS (see log below)? Looks like some issue with NAND flash. It doesn't happen on T4240QDS. York U-Boot 2016.07-00067-gb8e5997 (Jul 14 2016 - 09:58:11 -0700) CPU0: T2080E, Version: 1.1, (0x85380011) Core: e6500, Version: 2.0, (0x80400120) Clock Configuration: CPU0:1800 MHz, CPU1:1800 MHz, CPU2:1800 MHz, CPU3:1800 MHz, CCB:600 MHz, DDR:933.333 MHz (1866.667 MT/s data rate) (Asynchronous), IFC:150 MHz FMAN1: 700 MHz QMAN: 300 MHz PME: 600 MHz L1: D-cache 32 KiB enabled I-cache 32 KiB enabled Reset Configuration Word (RCW): 00000000: 0c070012 0e000000 00000000 00000000 00000010: 6c2d0002 00000000 ec027000 c1000000 00000020: 00000000 00000000 00000000 000307fc 00000030: 00000000 00000000 00000000 00000004 Board: T2080QDS, Sys ID: 0x28, Board Arch: V1, Board Version: A, boot from vBank4 FPGA: v11 (T1040QDS_2014_0318_1724), build 317 on Tue Mar 18 21:24:26 2014 SERDES Reference Clocks: SD1_CLK1=156.25MHZ, SD1_CLK2=100.00MHz SD2_CLK1=100.00MHz, SD2_CLK2=100.00MHz I2C: ready SPI: ready DRAM: Initializing....using SPD Detected UDIMM 6 GiB left unmapped 8 GiB (DDR3, 64-bit, CL=13, ECC on) DDR Chip-Select Interleaving Mode: CS0+CS1 Flash: 128 MiB L2: 2 MiB enabled Corenet Platform Cache: 512 KiB enabled Using SERDES1 Protocol: 108 (0x6c) Using SERDES2 Protocol: 45 (0x2d) SRIO1: enabled SRIO2: enabled SEC0: RNG instantiated NAND: fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer fsl_ifc_read_byte beyond end of buffer

2 2

[U-Boot] [PATCH] dm: mmc: Add the function for getting current device number
by Jaehoon Chung 15 Jul '16

15 Jul '16

get_mmc_num can be returned 0. Then if you use the "mmcinfo" command, it can't print the mmc information. If get_mmc_num is 0, it means that there is not mmc device. So it added the get_mmc_curr_num() function for getting current device number(index). And get_mmc_num() is returned the number of device. This patch is only tested with mmc block..so i didn't touch the blk-uclass.c. Signed-off-by: Jaehoon Chung <jh80.chung(a)samsung.com> --- drivers/mmc/mmc-uclass.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c index 38ced41..a3f2463 100644 --- a/drivers/mmc/mmc-uclass.c +++ b/drivers/mmc/mmc-uclass.c @@ -111,6 +111,16 @@ struct mmc *find_mmc_device(int dev_num) int get_mmc_num(void) { + int devnum = blk_find_max_devnum(IF_TYPE_MMC); + + if (devnum < 0) + return devnum; + + return devnum + 1; +} + +static int get_mmc_curr_num(void) +{ return max(blk_find_max_devnum(IF_TYPE_MMC), 0); } @@ -118,7 +128,7 @@ int mmc_get_next_devnum(void) { int ret; - ret = get_mmc_num(); + ret = get_mmc_curr_num(); if (ret < 0) return ret; -- 1.9.1

2 2

[U-Boot] [PATCH v2 0/8] U-Boot port to Xtensa architecture
by Max Filippov 15 Jul '16

15 Jul '16

Hi Tom, this series adds U-Boot port to Xtensa, configurable processor architecture from Tensilica, Inc., now Cadence Design Systems Inc. Two patches add proper xtensa bits: changes to shares files and contents of arch/xtensa. Next three patches add three sample xtensa CPU configurations: one without MMU, with MMUv2 and with MMUv3. Two more patches clean up OpenCores 10/100 MBit driver, enable it to be used with dedicated packet memory and with gigabit PHY. One more patch adds xtfpga board family that consists of Avnet LX60, LX110 and LX200 and Xilinx ML605 and KC705 FPGA boards configured with xtensa bitstream. The whole series is also available in the following git tree: git://github.com/jcmvbkbc/u-boot-xtensa.git tags/xtensa-2016.07-rc3 The port has been done mainly by Chris Zankel. I've been maintaining it internally for some time now and I'll maintain it upstream. This is my second attempt to submit it, the first one: http://lists.denx.de/pipermail/u-boot/2014-August/186771.html Changes since v1: - code rebased to v2016.07-rc3; - the port now uses generic board; - timer_get_us is implemented for CPU cores that have CCOUNT option; - functional atomic.h is provided; - both windowed and call0 ABIs are supported; - noMMU, MMUv2 and MMUv3 cores are supported; - CONFIG_OF_CONTROL is supported and DTS for the latest XTFPGA boards are provided. Please review. Chris Zankel (5): xtensa: add support for the xtensa processor architecture [1/2] xtensa: add support for the xtensa processor architecture [2/2] xtensa: add core information for the dc232b processor net/ethoc: support private memory configurations xtensa: add support for the 'xtfpga' evaluation board Max Filippov (3): xtensa: add core information for the dc233c processor xtensa: add core information for the de212 processor net/ethoc: don't advertise gigabit on the connected PHY MAINTAINERS | 5 + MAKEALL | 6 + Makefile | 10 +- arch/Kconfig | 8 + arch/xtensa/Kconfig | 29 + arch/xtensa/Makefile | 8 + arch/xtensa/config.mk | 12 + arch/xtensa/cpu/Makefile | 9 + arch/xtensa/cpu/cpu.c | 92 ++++ arch/xtensa/cpu/exceptions.c | 64 +++ arch/xtensa/cpu/start.S | 737 ++++++++++++++++++++++++++ arch/xtensa/cpu/u-boot.lds | 116 ++++ arch/xtensa/dts/Makefile | 15 + arch/xtensa/dts/include/dt-bindings | 1 + arch/xtensa/dts/kc705.dts | 15 + arch/xtensa/dts/kc705_nommu.dts | 17 + arch/xtensa/dts/ml605.dts | 15 + arch/xtensa/dts/ml605_nommu.dts | 18 + arch/xtensa/dts/xtfpga-flash-128m.dtsi | 28 + arch/xtensa/dts/xtfpga-flash-16m.dtsi | 28 + arch/xtensa/dts/xtfpga.dtsi | 137 +++++ arch/xtensa/include/asm/addrspace.h | 31 ++ arch/xtensa/include/asm/arch-dc232b/core.h | 422 +++++++++++++++ arch/xtensa/include/asm/arch-dc232b/tie-asm.h | 120 +++++ arch/xtensa/include/asm/arch-dc232b/tie.h | 129 +++++ arch/xtensa/include/asm/arch-dc233c/core.h | 475 +++++++++++++++++ arch/xtensa/include/asm/arch-dc233c/tie-asm.h | 193 +++++++ arch/xtensa/include/asm/arch-dc233c/tie.h | 150 ++++++ arch/xtensa/include/asm/arch-de212/core.h | 594 +++++++++++++++++++++ arch/xtensa/include/asm/arch-de212/tie-asm.h | 170 ++++++ arch/xtensa/include/asm/arch-de212/tie.h | 136 +++++ arch/xtensa/include/asm/asmmacro.h | 152 ++++++ arch/xtensa/include/asm/atomic.h | 55 ++ arch/xtensa/include/asm/bitops.h | 36 ++ arch/xtensa/include/asm/bootparam.h | 54 ++ arch/xtensa/include/asm/byteorder.h | 81 +++ arch/xtensa/include/asm/cache.h | 20 + arch/xtensa/include/asm/cacheasm.h | 211 ++++++++ arch/xtensa/include/asm/config.h | 24 + arch/xtensa/include/asm/errno.h | 1 + arch/xtensa/include/asm/global_data.h | 20 + arch/xtensa/include/asm/io.h | 149 ++++++ arch/xtensa/include/asm/ldscript.h | 222 ++++++++ arch/xtensa/include/asm/linkage.h | 4 + arch/xtensa/include/asm/misc.h | 20 + arch/xtensa/include/asm/posix_types.h | 74 +++ arch/xtensa/include/asm/processor.h | 11 + arch/xtensa/include/asm/ptrace.h | 133 +++++ arch/xtensa/include/asm/regs.h | 95 ++++ arch/xtensa/include/asm/sections.h | 12 + arch/xtensa/include/asm/string.h | 10 + arch/xtensa/include/asm/system.h | 27 + arch/xtensa/include/asm/types.h | 60 +++ arch/xtensa/include/asm/u-boot.h | 41 ++ arch/xtensa/include/asm/unaligned.h | 6 + arch/xtensa/include/asm/xtensa.h | 29 + arch/xtensa/lib/Makefile | 10 + arch/xtensa/lib/bootm.c | 197 +++++++ arch/xtensa/lib/misc.S | 179 +++++++ arch/xtensa/lib/time.c | 121 +++++ board/cadence/xtfpga/Kconfig | 43 ++ board/cadence/xtfpga/MAINTAINERS | 6 + board/cadence/xtfpga/Makefile | 8 + board/cadence/xtfpga/README | 125 +++++ board/cadence/xtfpga/lcd.c | 88 +++ board/cadence/xtfpga/lcd.h | 12 + board/cadence/xtfpga/xtfpga.c | 173 ++++++ cmd/bdinfo.c | 22 + common/board_f.c | 7 +- common/image.c | 1 + configs/xtfpga_defconfig | 13 + doc/README.xtensa | 100 ++++ drivers/net/ethoc.c | 97 ++++ examples/standalone/stubs.c | 47 ++ include/configs/xtfpga.h | 286 ++++++++++ include/image.h | 1 + include/linux/stat.h | 4 +- 77 files changed, 6871 insertions(+), 6 deletions(-) create mode 100644 arch/xtensa/Kconfig create mode 100644 arch/xtensa/Makefile create mode 100644 arch/xtensa/config.mk create mode 100644 arch/xtensa/cpu/Makefile create mode 100644 arch/xtensa/cpu/cpu.c create mode 100644 arch/xtensa/cpu/exceptions.c create mode 100644 arch/xtensa/cpu/start.S create mode 100644 arch/xtensa/cpu/u-boot.lds create mode 100644 arch/xtensa/dts/Makefile create mode 120000 arch/xtensa/dts/include/dt-bindings create mode 100644 arch/xtensa/dts/kc705.dts create mode 100644 arch/xtensa/dts/kc705_nommu.dts create mode 100644 arch/xtensa/dts/ml605.dts create mode 100644 arch/xtensa/dts/ml605_nommu.dts create mode 100644 arch/xtensa/dts/xtfpga-flash-128m.dtsi create mode 100644 arch/xtensa/dts/xtfpga-flash-16m.dtsi create mode 100644 arch/xtensa/dts/xtfpga.dtsi create mode 100644 arch/xtensa/include/asm/addrspace.h create mode 100644 arch/xtensa/include/asm/arch-dc232b/core.h create mode 100644 arch/xtensa/include/asm/arch-dc232b/tie-asm.h create mode 100644 arch/xtensa/include/asm/arch-dc232b/tie.h create mode 100644 arch/xtensa/include/asm/arch-dc233c/core.h create mode 100644 arch/xtensa/include/asm/arch-dc233c/tie-asm.h create mode 100644 arch/xtensa/include/asm/arch-dc233c/tie.h create mode 100644 arch/xtensa/include/asm/arch-de212/core.h create mode 100644 arch/xtensa/include/asm/arch-de212/tie-asm.h create mode 100644 arch/xtensa/include/asm/arch-de212/tie.h create mode 100644 arch/xtensa/include/asm/asmmacro.h create mode 100644 arch/xtensa/include/asm/atomic.h create mode 100644 arch/xtensa/include/asm/bitops.h create mode 100644 arch/xtensa/include/asm/bootparam.h create mode 100644 arch/xtensa/include/asm/byteorder.h create mode 100644 arch/xtensa/include/asm/cache.h create mode 100644 arch/xtensa/include/asm/cacheasm.h create mode 100644 arch/xtensa/include/asm/config.h create mode 100644 arch/xtensa/include/asm/errno.h create mode 100644 arch/xtensa/include/asm/global_data.h create mode 100644 arch/xtensa/include/asm/io.h create mode 100644 arch/xtensa/include/asm/ldscript.h create mode 100644 arch/xtensa/include/asm/linkage.h create mode 100644 arch/xtensa/include/asm/misc.h create mode 100644 arch/xtensa/include/asm/posix_types.h create mode 100644 arch/xtensa/include/asm/processor.h create mode 100644 arch/xtensa/include/asm/ptrace.h create mode 100644 arch/xtensa/include/asm/regs.h create mode 100644 arch/xtensa/include/asm/sections.h create mode 100644 arch/xtensa/include/asm/string.h create mode 100644 arch/xtensa/include/asm/system.h create mode 100644 arch/xtensa/include/asm/types.h create mode 100644 arch/xtensa/include/asm/u-boot.h create mode 100644 arch/xtensa/include/asm/unaligned.h create mode 100644 arch/xtensa/include/asm/xtensa.h create mode 100644 arch/xtensa/lib/Makefile create mode 100644 arch/xtensa/lib/bootm.c create mode 100644 arch/xtensa/lib/misc.S create mode 100644 arch/xtensa/lib/time.c create mode 100644 board/cadence/xtfpga/Kconfig create mode 100644 board/cadence/xtfpga/MAINTAINERS create mode 100644 board/cadence/xtfpga/Makefile create mode 100644 board/cadence/xtfpga/README create mode 100644 board/cadence/xtfpga/lcd.c create mode 100644 board/cadence/xtfpga/lcd.h create mode 100644 board/cadence/xtfpga/xtfpga.c create mode 100644 configs/xtfpga_defconfig create mode 100644 doc/README.xtensa create mode 100644 include/configs/xtfpga.h -- 2.1.4

3 31

[U-Boot] [PATCHv2][RESEND] spi: Add support for N25Q016A
by Moritz Fischer 15 Jul '16

15 Jul '16

Signed-off-by: Moritz Fischer <moritz.fischer(a)ettus.com> --- drivers/mtd/spi/sf_params.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c index 4f37e33..8ae4eea 100644 --- a/drivers/mtd/spi/sf_params.c +++ b/drivers/mtd/spi/sf_params.c @@ -83,6 +83,7 @@ const struct spi_flash_params spi_flash_params_table[] = { {"M25P64", 0x202017, 0x0, 64 * 1024, 128, RD_NORM, 0}, {"M25P128", 0x202018, 0x0, 256 * 1024, 64, RD_NORM, 0}, {"M25PX64", 0x207117, 0x0, 64 * 1024, 128, RD_NORM, SECT_4K}, + {"N25Q016A", 0x20bb15, 0x1000, 64 * 1024, 32, RD_NORM, SECT_4K}, {"N25Q32", 0x20ba16, 0x0, 64 * 1024, 64, RD_FULL, WR_QPP | SECT_4K}, {"N25Q32A", 0x20bb16, 0x0, 64 * 1024, 64, RD_FULL, WR_QPP | SECT_4K}, {"N25Q64", 0x20ba17, 0x0, 64 * 1024, 128, RD_FULL, WR_QPP | SECT_4K}, -- 2.5.5

2 2

[U-Boot] [PATCH] arm: start.S: Fix startup of dragonboard410c
by Mateusz Kulikowski 14 Jul '16

14 Jul '16

Commit d73718f3 breaks devices where: - There is EL2/EL3 firmware and - U-Boot starts in NS EL1 and - EL2/EL3 firmware didn't unlocked write-access to CPUECTLR_EL1. This patch makes that change opt-out configuration option, and disables it for dragonboard410c. Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski(a)gmail.com> --- I make it opt-out so nobody will complain that I broke someones board. If you prefer opt-in - just let me know, I'll flip the switch in Kconfig. BTW. I wonder if this register should be written at all on devices that implement ARMv8 but are *not* ARM Cortex. Mateusz arch/arm/cpu/armv8/Kconfig | 13 +++++++++++++ arch/arm/cpu/armv8/start.S | 7 +++++-- configs/dragonboard410c_defconfig | 1 + 3 files changed, 19 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig index 3d19bbf..33af0a2 100644 --- a/arch/arm/cpu/armv8/Kconfig +++ b/arch/arm/cpu/armv8/Kconfig @@ -3,4 +3,17 @@ if ARM64 config ARMV8_MULTIENTRY boolean "Enable multiple CPUs to enter into U-Boot" +config ARMV8_SET_SMPEN + boolean "Enable data coherency with other cores in cluster" + default y if ARM64 + help + Cortex A53/57/72 cores require CPUECTLR_EL1.SMPEN set even + for single core systems. Unfortunately write access to this + register may be controlled by EL3/EL2 firmware. To be more + precise, by default (if there is EL2/EL3 firmware running) + this register is RO for NS EL1. + This switch can be used to avoid writing to CPUECTLR_EL1, + it can be safely enabled when El2/EL3 initialized SMPEN bit + or when CPU implementation doesn't include that register. + endif diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index dfce469..777cad3 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -81,13 +81,16 @@ reset: msr cpacr_el1, x0 /* Enable FP/SIMD */ 0: - /* Enalbe SMPEN bit for coherency. + /* Enable SMPEN bit for coherency. * This register is not architectural but at the moment * this bit should be set for A53/A57/A72. + * */ - mrs x0, S3_1_c15_c2_1 /* cpuactlr_el1 */ +#ifdef CONFIG_ARMV8_SET_SMPEN + mrs x0, S3_1_c15_c2_1 /* cpuectlr_el1 */ orr x0, x0, #0x40 msr S3_1_c15_c2_1, x0 +#endif /* Apply ARM core specific erratas */ bl apply_core_errata diff --git a/configs/dragonboard410c_defconfig b/configs/dragonboard410c_defconfig index ad2e8b8..d3cfa69 100644 --- a/configs/dragonboard410c_defconfig +++ b/configs/dragonboard410c_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_SNAPDRAGON=y +CONFIG_ARMV8_SET_SMPEN=n CONFIG_DEFAULT_DEVICE_TREE="dragonboard410c" CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="dragonboard410c => " -- 2.7.4

3 2

[U-Boot] does u-boot automatically determine valid command abbreviations?
by Robert P. J. Day 14 Jul '16

14 Jul '16

i just want to confirm that u-boot *automatically* determines the valid prefix abbreviations for u-boot commands, correct? as in, there is no registration or configuration to do that, it's done automatically based on the commands that have been configured into u-boot and whether a command abbreviation represents a unique prefix for all configured commands, yes? i'm making that assumption based on this routine from common/command.c: /* find command table entry for a command */ cmd_tbl_t *find_cmd_tbl(const char *cmd, cmd_tbl_t *table, int table_len) { #ifdef CONFIG_CMDLINE cmd_tbl_t *cmdtp; cmd_tbl_t *cmdtp_temp = table; /* Init value */ const char *p; int len; int n_found = 0; if (!cmd) return NULL; /* * Some commands allow length modifiers (like "cp.b"); * compare command name only until first dot. */ len = ((p = strchr(cmd, '.')) == NULL) ? strlen (cmd) : (p - cmd); for (cmdtp = table; cmdtp != table + table_len; cmdtp++) { if (strncmp(cmd, cmdtp->name, len) == 0) { if (len == strlen(cmdtp->name)) return cmdtp; /* full match */ cmdtp_temp = cmdtp; /* abbreviated command ? */ n_found++; } } if (n_found == 1) { /* exactly one match */ return cmdtp_temp; } #endif /* CONFIG_CMDLINE */ return NULL; /* not found or ambiguous command */ } so am i reading that correctly that any unique prefix for configured commands will work? i ask only because, recently, someone made the claim in some u-boot instructions i'm reading: * Use “setenv” command instead of “set” for target boards. u-boot source is not yet modified to alias “setenv” to “set”. Other commands like “printenv” and “saveenv” can still be called as “print” and “save”. huh? why would someone have to "modify" the source to allow "set" to be a valid abbreviation for "setenv"? (aside: these instructions mix advice for both current and very old versions of u-boot, so maybe that claim is only for very old versions.) anyway, clarifiation would be appreciated. thank you kindly. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

2 2

[U-Boot] [PATCH v2 0/4] ARM: imx: enhance support for the cm-fx6 module
by christopher.spinrath＠rwth-aachen.de 14 Jul '16

14 Jul '16

Hi, this is v2 of the series. To address the review comments of v1, v2 has an addtional patch (2/4) touching include/fdt_support.h (thus, I added Simon to the recipients). The original cover letter was (for a discussion cf. [2]): this series aims at enhancing support for the cm-fx6 module. In particular, with respect to the upstream linux kernel. The first patch improves the default environment. It is non-functional but makes it more convenient to adapt certain settings. The later two patches add mtd partition support for the on-board spi flash chip. They pick up the discussion about specifying a default partitioning in the device tree from here [1]. In short: adding the default partitioning to the device tree was rejected by the linux/ device tree community during mainlining large parts of the device tree. It was proposed to implement the partition/mtd handling in u-boot. On the other hand, it was argued that the flash chip becomes some kind of "black-box" since there will be no partition labeling (in particular, with old u-boot versions). IMHO defining the mtd partitioning has the following (dis-)advantages: Advantages: - It is easier for the user to change the partitioning (e.g. to use the unsued 1MB free space). - The flash ship is used entirely for u-boot. So it is quite natural that u-boot manages it. Also, moving the partition table to it allows us to change the layout in future versions of u-boot (almost independently of the kernel - there are still non-device tree kernels). - U-Boot becomes the single point of definition for all device tree kernels. Otherwise, each kernel (vendor vs. upstream + version) would ship its own partitioning. Moreover, u-boot has to know something about the partitioning, too, because it has to know where the environment is saved. Disadvantages: - Users of the upstream linux kernel have to use a recent u-boot version to avoid the "black box" effect. A concrete impact is that the update routine (described/proposed by CompuLab) does not work out of the box with older u-boot versions. - Updating u-boot is something users might not want or miss to do. However, I think nowadays it is ok to demand a recent u-boot in combination with the upstream kernel. The cm-fx6 wouldn't be the first board doing so. Hence, I propose these patches here. Cheers, Christopher [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/434562.html [2] http://lists.denx.de/pipermail/u-boot/2016-June/258546.html

2 1

[U-Boot] best way to submit a patch for numerous, tree-wide typoz?
by Robert P. J. Day 14 Jul '16

14 Jul '16

what is the best way to send in a patch for quite a number of tree-wide (ie., unrelated) typos throughout the source? almost all of them are innocuous -- either comments or in printed strings, so they *shouldn't* break anything. these days, i have a separate "typos" git branch where i just collect typos i run across, and keep rebasing it against "master" to stay up to date. and since this appears to be the u-boot merge window, i figure now is a good time to send it in. but, as i said, it's spread all over the tree, so is a single patch even a good idea, or should i try to break it into smaller, bite-size pieces? 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