May 2014 - U-Boot

[U-Boot] [PATCH v1 0/4] arm, imx6: add aristainetos board support
by Heiko Schocher 15 Jul '14

15 Jul '14

add support for the imx6 based aristainetos board. Heiko Schocher (4): arm, imx6: add mxc_iomux_set_gpr_register function spi, spi_mxc: do not hang in spi_xchg_single i.MX6: add enable_spi_clk() arm, imx6: add aristainetos board arch/arm/cpu/armv7/mx6/clock.c | 17 + arch/arm/imx-common/iomux-v3.c | 15 + arch/arm/include/asm/arch-mx6/clock.h | 1 + arch/arm/include/asm/imx-common/iomux-v3.h | 2 + board/aristainetos/Makefile | 9 + board/aristainetos/aristainetos.c | 527 +++++++++++++++++++++++++++++ board/aristainetos/aristainetos.cfg | 33 ++ board/aristainetos/clocks.cfg | 24 ++ board/aristainetos/ddr-setup.cfg | 61 ++++ board/aristainetos/mt41j128M.cfg | 70 ++++ boards.cfg | 1 + drivers/spi/mxc_spi.c | 8 +- include/configs/aristainetos.h | 310 +++++++++++++++++ 13 files changed, 1076 insertions(+), 2 deletions(-) create mode 100644 board/aristainetos/Makefile create mode 100644 board/aristainetos/aristainetos.c create mode 100644 board/aristainetos/aristainetos.cfg create mode 100644 board/aristainetos/clocks.cfg create mode 100644 board/aristainetos/ddr-setup.cfg create mode 100644 board/aristainetos/mt41j128M.cfg create mode 100644 include/configs/aristainetos.h -- 1.8.3.1

5 14

[U-Boot] [PATCH v1 0/3] ARM: omap: add support for GPMC and ELM controllers on OMAP4 and OMAP5 platforms
by Pekon Gupta 09 Jul '14

09 Jul '14

This patch series intends to: - Add support for GPMC and ELM controllers for OMAP4 and OMAP5 platform devices by moving all generic arch specific code shared between arch/AM33xx, arch/OMAP4 and arch/OMAP5 into arch/omap-common/ - Separate out arch specific header for future scalability - Remove redundant code Pekon Gupta (3): ARM: omap4: add platform specific info for GPMC and ELM controllers ARM: omap5: add platform specific info for GPMC and ELM controllers ARM: omap: merge GPMC initialization code for all platform arch/arm/cpu/armv7/am33xx/Makefile | 1 - arch/arm/cpu/armv7/omap-common/Makefile | 4 - .../{am33xx/mem.c => omap-common/mem-common.c} | 39 ++++++ arch/arm/cpu/armv7/omap3/Makefile | 1 - arch/arm/cpu/armv7/omap3/mem.c | 139 --------------------- arch/arm/include/asm/arch-omap4/cpu.h | 5 +- arch/arm/include/asm/arch-omap4/hardware.h | 26 ++++ arch/arm/include/asm/arch-omap4/mem.h | 62 +++++++++ arch/arm/include/asm/arch-omap4/omap.h | 3 - arch/arm/include/asm/arch-omap5/cpu.h | 5 +- arch/arm/include/asm/arch-omap5/hardware.h | 26 ++++ arch/arm/include/asm/arch-omap5/mem.h | 62 +++++++++ arch/arm/include/asm/arch-omap5/omap.h | 3 - 13 files changed, 219 insertions(+), 157 deletions(-) rename arch/arm/cpu/armv7/{am33xx/mem.c => omap-common/mem-common.c} (68%) delete mode 100644 arch/arm/cpu/armv7/omap3/mem.c create mode 100644 arch/arm/include/asm/arch-omap4/hardware.h create mode 100644 arch/arm/include/asm/arch-omap4/mem.h create mode 100644 arch/arm/include/asm/arch-omap5/hardware.h create mode 100644 arch/arm/include/asm/arch-omap5/mem.h -- 1.8.5.1.163.gd7aced9

5 15

[U-Boot] [RFC] Extend 'bootm' to support Linux kernel generated images
by Tom Rini 08 Jul '14

08 Jul '14

Hey all, Something that Rob mentioned to me at ELC, and others have mentioned before is that it would be nice if 'bootm' (which says "boot application image stored in memory" in the help, even) would just work with zImage or Image or whatever is spit directly out of the kernel. The following shows roughly what I'm thinking about how we would handle this: diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c index 0706086..14319b2 100644 --- a/arch/arm/lib/bootm.c +++ b/arch/arm/lib/bootm.c @@ -332,6 +332,17 @@ struct zimage_header { #define LINUX_ARM_ZIMAGE_MAGIC 0x016f2818 +int check_image_linux_kernel(ulong image) +{ + struct zimage_header *zi; + + zi = (struct zimage_header *)map_sysmem(image, 0); + if (zi->zi_magic == LINUX_ARM_ZIMAGE_MAGIC) + return 0; + + return 1; +} + int bootz_setup(ulong image, ulong *start, ulong *end) { struct zimage_header *zi; diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index 30fd643..6bed825 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -274,6 +274,11 @@ static int bootm_find_os(cmd_tbl_t *cmdtp, int flag, int argc, } break; #endif +#ifdef CONFIG_BOOTM_LINUX_RAW + case IMAGE_FORMAT_LINUX: + /* Call something to set images.os.things */ + return 0; +#endif default: puts("ERROR: unknown image format type!\n"); return 1; @@ -1002,6 +1007,11 @@ static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int flag, int argc, images->fit_noffset_os = os_noffset; break; #endif +#ifdef CONFIG_BOOTM_LINUX_RAW + case IMAGE_FORMAT_LINUX: + /* Set loadaddr? */ + return 0; +#endif default: printf("Wrong Image Format for %s command\n", cmdtp->name); bootstage_error(BOOTSTAGE_ID_FIT_KERNEL_INFO); diff --git a/common/image.c b/common/image.c index fcc5a9c..32237a3 100644 --- a/common/image.c +++ b/common/image.c @@ -665,6 +665,10 @@ int genimg_get_format(const void *img_addr) format = IMAGE_FORMAT_FIT; } #endif +#ifdef CONFIG_BOOTM_LINUX_RAW + if (check_image_linux_kernel((ulong)img_addr) == 0) + return IMAGE_FORMAT_LINUX; +#endif return format; } diff --git a/include/image.h b/include/image.h index b278778..985c6f0 100644 --- a/include/image.h +++ b/include/image.h @@ -411,6 +411,7 @@ enum fit_load_op { #ifndef USE_HOSTCC /* Image format types, returned by _get_format() routine */ #define IMAGE_FORMAT_INVALID 0x00 +#define IMAGE_FORMAT_LINUX 0xFF /* Linux kernel defined formats */ #define IMAGE_FORMAT_LEGACY 0x01 /* legacy image_header based format */ #define IMAGE_FORMAT_FIT 0x02 /* new, libfdt based format */ @@ -660,6 +661,15 @@ int image_setup_libfdt(bootm_headers_t *images, void *blob, int image_setup_linux(bootm_headers_t *images); /** + * Check if the given location has some form of Linux-kernel generated + * image. + * + * @param image Potential image location + * @return 0 if OK, 1 if not a known Linux-kernel generated image. + */ +int check_image_linux_kernel(ulong image); + +/** * bootz_setup() - Extract stat and size of a Linux xImage * * @image: Address of image It of course doesn't work and just shows where I think we would need to fill things in and probably provide some __weak functions for other arches. Looking over how we do bootz today, and how I wrote booti for arm64, it should be possible to do the correct callouts at the correct places for "oh, we don't have a legacy or FIT header, we have a per Linux architecture defined header". What does everyone think about extending things in this direction? -- Tom

4 9

[U-Boot] [PATCH] arm: fix a build error with CONFIG_USE_IRQ
by Masahiro Yamada 07 Jul '14

07 Jul '14

Commit 41623c91 moved exception handling to arch/arm/lib/vectors.S, breaking CONFIG_USE_IRQ feature. If CONFIG_USE_IRQ is enabled, undefined reference error occurs. arch/arm/lib/built-in.o: In function `interrupt_init': arch/arm/lib/interrupts.c:37: undefined reference to `IRQ_STACK_START' arch/arm/lib/interrupts.c:37: undefined reference to `FIQ_STACK_START' make: *** [u-boot] Error 1 Because arch/arm/lib/vectors.S includes references to CONFIG_SYS_DV_NOR_BOOT_CFG and CONFIG_USE_IRQ, it must include <config.h>. Signed-off-by: Masahiro Yamada <yamada.m(a)jp.panasonic.com> Cc: Albert ARIBAUD <albert.u.boot(a)aribaud.net> --- arch/arm/lib/vectors.S | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/lib/vectors.S b/arch/arm/lib/vectors.S index d68cc47..fad00da 100644 --- a/arch/arm/lib/vectors.S +++ b/arch/arm/lib/vectors.S @@ -13,6 +13,8 @@ * SPDX-License-Identifier: GPL-2.0+ */ +#include <config.h> + /* ************************************************************************* * -- 1.9.1

4 18

[U-Boot] [PATCH v2] gpio: spear_gpio: Fix gpio_set_value() implementation
by Axel Lin 04 Jul '14

04 Jul '14

In current gpio_set_value() implementation, it always sets the gpio control bit no matter the value argument is 0 or 1. Thus the GPIOs never set to low. This patch fixes this bug. The address bus is used as a mask on read/write operations, so that independent software drivers can set their GPIO bits without affecting any other pins in a single write operation. Thus we don't need a read-modify-write to update the register. Signed-off-by: Axel Lin <axel.lin(a)ingics.com> Acked-by: Stefan Roese <sr(a)denx.de> Reviewed-by: Vipin Kumar <vipin.kumar(a)st.com> Reviewed-by: Michael Trimarchi <michael(a)amarulasolutions.com> --- v2: Update commit log to explain why a read-modify-write is not necessary for clearing specific GPIO bit. Also added Michael Trimarchi's reviewed-by tag since he does review the patch and said the patch is fine. drivers/gpio/spear_gpio.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpio/spear_gpio.c b/drivers/gpio/spear_gpio.c index 367b670..6fb4117 100644 --- a/drivers/gpio/spear_gpio.c +++ b/drivers/gpio/spear_gpio.c @@ -36,7 +36,10 @@ int gpio_set_value(unsigned gpio, int value) { struct gpio_regs *regs = (struct gpio_regs *)CONFIG_GPIO_BASE; - writel(1 << gpio, &regs->gpiodata[DATA_REG_ADDR(gpio)]); + if (value) + writel(1 << gpio, &regs->gpiodata[DATA_REG_ADDR(gpio)]); + else + writel(0, &regs->gpiodata[DATA_REG_ADDR(gpio)]); return 0; } -- 1.8.1.2

2 1

[U-Boot] [PATCH 0/5] sunxi: GPIO, AHCI and Cubieboard 2 support.
by Ian Campbell 04 Jul '14

04 Jul '14

The following enables AHCI support for sun7i boards, which in turn requires GPIO support. It also adds support for the Cubieboard2 board. This is based on Hans' "sunxi: Bug fixes, sun4i and sun5i support, pmic support and network improvements" series[0]. (Other than e.g. boards.cfg and Makefile diff context it only actually depends on "sunxi: Add support for using MII phy-s with the GMAC nic"). I've also pushed to my gitorious tree. The following changes since commit b0d49d895cd07ae14e81aa429b570a13ab82bb08: sunxi: Add support for using MII phy-s with the GMAC nic (2014-05-31 10:26:47 +0200) are available in the git repository at: git://gitorious.org/ijc/u-boot.git sunxi-gpio-ahci-and-cubieboard2 for you to fetch changes up to a0fd41759d6ef9313a532c418e518be15ec37fd7: ahci: provide sunxi SATA driver using AHCI platform framework (2014-05-31 17:23:28 +0100) ---------------------------------------------------------------- Ian Campbell (5): AHCI: Increase link timeout to 200ms board_r: run scsi init() on ARM too sunxi: add Cubieboard2 support sunxi: add gpio driver ahci: provide sunxi SATA driver using AHCI platform framework arch/arm/cpu/armv7/sunxi/clock_sun4i.c | 7 +- arch/arm/include/asm/arch-sunxi/clock_sun4i.h | 11 ++- arch/arm/include/asm/arch-sunxi/gpio.h | 2 + board/sunxi/Makefile | 2 + board/sunxi/ahci.c | 84 +++++++++++++++++++++ board/sunxi/dram_cubieboard2.c | 31 ++++++++ boards.cfg | 8 +- common/board_r.c | 6 +- drivers/block/ahci.c | 18 ++++- drivers/gpio/Makefile | 1 + drivers/gpio/sunxi_gpio.c | 102 ++++++++++++++++++++++++++ include/ahci.h | 4 + include/configs/sunxi-common.h | 16 ++++ 13 files changed, 278 insertions(+), 14 deletions(-) create mode 100644 board/sunxi/ahci.c create mode 100644 board/sunxi/dram_cubieboard2.c create mode 100644 drivers/gpio/sunxi_gpio.c Ian. [0] https://github.com/jwrdegoede/u-boot-sunxi/tree/sun4i-upstreaming-v1

4 15

[U-Boot] Return value of run command
by Enric Balletbo Serra 27 Jun '14

27 Jun '14

Hi all, Should the command 'run something"' return the value that returns "something" or just return "true" if can execute something and "false" if it can't ? I'll explain. Imagine you have a variable that loads a file from the mmc but this files doesn't exist. loadfile=load mmc ${mmcdev} ${loadaddr} my-file In the case you do the following script if run loadfile; then echo "true"; else echo "false"; fi the result is always "true", either the file doesn't exist OTOH, if you do : if ${loadfile}; then echo "true"; else echo "false"; fi Then the result is "true" if file exist and "false" if file doesn't exist. For me looks like the "run something" command should return the result of the command but this is not the behaviour. With current behaviour something like CONFIG_EXTRA_ENV_SETTINGS from include/configs/am335x_evm.h file, 129 "echo SD/MMC found on device ${mmcdev};" \ 130 "if run loadbootenv; then " \ 131 "echo Loaded environment from ${bootenv};" \ 132 "run importbootenv;" \ 133 "fi;" \ Either uEnv.txt file exist or not, the "run loadbootenv" always returns true, so always tries to run "run importbootenv". I supose this is not the expected behaviour. The question is. It's a problem with run command or with the definition of CONFIG_EXTRA_ENV_SETTING, that should be something like that: - 130 "if run loadbootenv; then " \ + 130 "if ${loadbootenv}; then " \ Best regards, Enric

2 2

[U-Boot] [PATCH 2/2 v2] usb: r8a66597: Fix initilization size of r8a66597 info structure
by Yasuhisa Umano 25 Jun '14

25 Jun '14

Initialization of r8a66597 info structure is not enough. Because initilization was used size of pointer. This fixes that use size of r8a6659 info structure. Signed-off-by: Yasuhisa Umano <yasuhisa.umano.zc(a)renesas.com> --- v2 : Change from sizeof(struct r8a66597) to sizeof(*r8a66597) drivers/usb/host/r8a66597-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c index c58d2a9..5114544 100644 --- a/drivers/usb/host/r8a66597-hcd.c +++ b/drivers/usb/host/r8a66597-hcd.c @@ -807,7 +807,7 @@ int usb_lowlevel_init(int index, enum usb_init_type init, void **controller) R8A66597_DPRINT("%s\n", __func__); - memset(r8a66597, 0, sizeof(r8a66597)); + memset(r8a66597, 0, sizeof(*r8a66597)); r8a66597->reg = CONFIG_R8A66597_BASE_ADDR; disable_controller(r8a66597); -- 1.7.9.5

2 2

[U-Boot] [PATCH] arm: Allow u-boot to run from offset base address
by Darwin Rambo 25 Jun '14

25 Jun '14

If an earlier loader stage requires an image header and a specific offset, then u-boot's base address (CONFIG_SYS_TEXT_BASE) may be advanced beyond an aligned address. In this case the relocation will not be done correctly for some sections such as vectors and rodata string tables, which will show an incorrect offset after the symbols are fixed up. Advance the relocation address by the image offset so that the gd->reloc_off used will result in relocating these sections to their correct addresses. This change is done under CONFIG_ARM64 conditional compilation because it has only been tested there and may not be appropriate for other architectures. Signed-off-by: Darwin Rambo <drambo(a)broadcom.com> Reviewed-by: Steve Rae <srae(a)broadcom.com> --- arch/arm/lib/board.c | 13 +++++++++++++ common/board_f.c | 10 ++++++++++ 2 files changed, 23 insertions(+) diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index 9b473b5..df520cc 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -449,6 +449,19 @@ void board_init_f(ulong bootflag) dram_init_banksize(); display_dram_config(); /* and display it */ +#ifdef CONFIG_ARM64 + /* + * Fix relocation if u-boot is not on an aligned address. + */ + { + int offset = CONFIG_SYS_TEXT_BASE % 4096; + if (offset) { + addr += offset; + debug("Relocation Addr bumped to 0x%08lx\n", addr); + } + } +#endif + gd->relocaddr = addr; gd->start_addr_sp = addr_sp; gd->reloc_off = addr - (ulong)&_start; diff --git a/common/board_f.c b/common/board_f.c index 4ea4cb2..1035d6f 100644 --- a/common/board_f.c +++ b/common/board_f.c @@ -728,6 +728,16 @@ static int reloc_fdt(void) static int setup_reloc(void) { +#ifdef CONFIG_ARM64 + /* + * Fix relocation if u-boot is not on an aligned address. + */ + int offset = CONFIG_SYS_TEXT_BASE % 4096; + if (offset) { + gd->relocaddr += offset; + debug("Relocation Addr bumped to 0x%08lx\n", gd->relocaddr); + } +#endif gd->reloc_off = gd->relocaddr - CONFIG_SYS_TEXT_BASE; memcpy(gd->new_gd, (char *)gd, sizeof(gd_t)); -- 1.7.9.5

5 30

[U-Boot] [PATCH 0/3] cm_t54: add MAC address and env partiton handling
by Dmitry Lifshitz 25 Jun '14

25 Jun '14

Add Eth MAC address handling, stored in onboard EEPROM. cm-t54 config defines eMMC as env storage device. cm-t54 U-Boot environment is stored in the same partition as boot loader. It can be both - eMMC boot or user data partition. Add support for setting environment partition number in runtime. Dmitry Lifshitz (3): cm-t54: add EEPROM support and MAC address handling env_mmc: support env partition setup in runtime cm-t54: add environment partition runtime detection board/compulab/cm_t54/cm_t54.c | 85 ++++++++++++++++++++++++++++++++++++++++ common/env_mmc.c | 35 ++++++++++++---- include/configs/cm_t54.h | 10 +++++ 3 files changed, 121 insertions(+), 9 deletions(-) -- 1.7.5.4

4 11