April 2013 - U-Boot

[U-Boot] [PATCH] am335x: Enable MMC1 clock
by Tom Rini 08 Apr '13

08 Apr '13

We must not assume ROM has enabled the clock for MMC1. Reported-by: Koen Kooi <koen(a)dominion.thruhere.net> Signed-off-by: Tom Rini <trini(a)ti.com> --- arch/arm/cpu/armv7/am33xx/clock_am33xx.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/arch/arm/cpu/armv7/am33xx/clock_am33xx.c b/arch/arm/cpu/armv7/am33xx/clock_am33xx.c index afc0d92..a1efc75 100644 --- a/arch/arm/cpu/armv7/am33xx/clock_am33xx.c +++ b/arch/arm/cpu/armv7/am33xx/clock_am33xx.c @@ -195,6 +195,11 @@ static void enable_per_clocks(void) while (readl(&cmper->mmc0clkctrl) != PRCM_MOD_EN) ; + /* MMC1 */ + writel(PRCM_MOD_EN, &cmper->mmc1clkctrl); + while (readl(&cmper->mmc1clkctrl) != PRCM_MOD_EN) + ; + /* i2c0 */ writel(PRCM_MOD_EN, &cmwkup->wkup_i2c0ctrl); while (readl(&cmwkup->wkup_i2c0ctrl) != PRCM_MOD_EN) -- 1.7.9.5

2 2

[U-Boot] [PATCH] pcm051: Enable DDR PHY dynamic power down bit
by Lars Poeschel 08 Apr '13

08 Apr '13

From: Lars Poeschel <poeschel(a)lemonage.de> This is done already for am335x in 59dcf970d11ebff5d9f4bbbde79fda584e9e7ad4 and also applies for pcm051. It powers down the IO receiver when not performing read which helps reducing the overall power consuption in low power states (suspend/standby). Signed-off-by: Lars Poeschel <poeschel(a)lemonage.de> --- board/phytec/pcm051/board.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/board/phytec/pcm051/board.c b/board/phytec/pcm051/board.c index 1708ac2..43d7b6e 100644 --- a/board/phytec/pcm051/board.c +++ b/board/phytec/pcm051/board.c @@ -104,7 +104,8 @@ static struct emif_regs ddr3_emif_reg_data = { .sdram_tim2 = MT41J256M8HX15E_EMIF_TIM2, .sdram_tim3 = MT41J256M8HX15E_EMIF_TIM3, .zq_config = MT41J256M8HX15E_ZQ_CFG, - .emif_ddr_phy_ctlr_1 = MT41J256M8HX15E_EMIF_READ_LATENCY, + .emif_ddr_phy_ctlr_1 = MT41J256M8HX15E_EMIF_READ_LATENCY | + PHY_EN_DYN_PWRDN, }; #endif -- 1.7.10.4

2 1

[U-Boot] [PATCH] musb: am335x: disable bulk split-combine feature
by Bin Liu 08 Apr '13

08 Apr '13

On TI AM335x devices, MUSB has bulk split/combine feature enabled in the ConfigData register, but the current MUSB driver does not support it yet. Therefore, disable the feature for now, until the driver adds the support. One usecase which is broken because of this feature is that Ether gadget stops working in Fullspeed mode (by un-defining CONFIG_USB_GADGET_DUALSPEED) After desabled this feature, MUSB driver send packets in proper size (no more than 64 bytes) in Fullspeed mode. This has been validated with Ether gadget in Fullspeed mode on AM335x EVM. Signed-off-by: Bin Liu <b-liu(a)ti.com> --- drivers/usb/musb-new/musb_core.c | 5 +++++ include/configs/am335x_evm.h | 1 + 2 files changed, 6 insertions(+) diff --git a/drivers/usb/musb-new/musb_core.c b/drivers/usb/musb-new/musb_core.c index 040a5c0..aa647e6 100644 --- a/drivers/usb/musb-new/musb_core.c +++ b/drivers/usb/musb-new/musb_core.c @@ -1421,6 +1421,7 @@ static int __devinit musb_core_init(u16 musb_type, struct musb *musb) strcat(aInfo, ", dyn FIFOs"); musb->dyn_fifo = true; } +#ifndef CONFIG_MUSB_DISABLE_BULK_COMBINE_SPLIT if (reg & MUSB_CONFIGDATA_MPRXE) { strcat(aInfo, ", bulk combine"); musb->bulk_combine = true; @@ -1429,6 +1430,10 @@ static int __devinit musb_core_init(u16 musb_type, struct musb *musb) strcat(aInfo, ", bulk split"); musb->bulk_split = true; } +#else + musb->bulk_combine = false; + musb->bulk_split = false; +#endif if (reg & MUSB_CONFIGDATA_HBRXE) { strcat(aInfo, ", HB-ISO Rx"); musb->hb_iso_rx = true; diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index 74a70ee..faf9581 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -450,6 +450,7 @@ #define CONFIG_ARCH_MISC_INIT #define CONFIG_MUSB_GADGET #define CONFIG_MUSB_PIO_ONLY +#define CONFIG_MUSB_DISABLE_BULK_COMBINE_SPLIT #define CONFIG_USB_GADGET_DUALSPEED #define CONFIG_USB_GADGET_VBUS_DRAW 2 #define CONFIG_MUSB_HOST -- 1.7.9.5

2 3

[U-Boot] [PATCH 1/2] dfu:ext4:fix: Change ext4write command order of parameters
by Lukasz Majewski 08 Apr '13

08 Apr '13

Following commit: "cmd_ext4: BREAK and correct ext4write parameter order" SHA1:0171d52c410cbaa9290b1b214e695697c835bfe5 introduced cleanup of ext4write semantics to be consistent with other filesystem's writing commands (e.g. fatwrite). This commit provides correct ext4write command generation at DFU eMMC code. Signed-off-by: Lukasz Majewski <l.majewski(a)samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park(a)samsung.com> --- drivers/dfu/dfu_mmc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c index 083d745..afd3506 100644 --- a/drivers/dfu/dfu_mmc.c +++ b/drivers/dfu/dfu_mmc.c @@ -72,10 +72,10 @@ static int mmc_file_op(enum dfu_mmc_op op, struct dfu_entity *dfu, (unsigned int) buf, dfu->name, *len); break; case DFU_FS_EXT4: - sprintf(cmd_buf, "ext4%s mmc %d:%d /%s 0x%x %ld", + sprintf(cmd_buf, "ext4%s mmc %d:%d 0x%x /%s %ld", op == DFU_OP_READ ? "load" : "write", dfu->data.mmc.dev, dfu->data.mmc.part, - dfu->name, (unsigned int) buf, *len); + (unsigned int) buf, dfu->name, *len); break; default: printf("%s: Layout (%s) not (yet) supported!\n", __func__, -- 1.7.10.4

2 2

[U-Boot] [PATCH][Upstream] cmd_sf: include header file common.h before div64.h
by Mingkai Hu 08 Apr '13

08 Apr '13

The header file div64.h includes <asm/types.h> which defines the phys_addr_t according to the macro CONFIG_PHYS_64BIT, while the macro CONFIG_PHYS_64BIT is included in common.h which comes after div64.h, so in order to get consistent type definition for phys_addr_t, common.h should be included before div64.h, Or else, the parameters of phys_addr_t type will be passed wrongly when CONFIG_PHYS_64BIT is defined. Signed-off-by: Mingkai Hu <Mingkai.Hu(a)freescale.com> --- Based on master branch of git://git.denx.de/u-boot.git Also can apply direcly to git://www.denx.de/git/u-boot-mpc85xx.git Tested on P2041RDB board. common/cmd_sf.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/common/cmd_sf.c b/common/cmd_sf.c index b175358..bd3c508 100644 --- a/common/cmd_sf.c +++ b/common/cmd_sf.c @@ -5,8 +5,8 @@ * Licensed under the GPL-2 or later. */ -#include <div64.h> #include <common.h> +#include <div64.h> #include <malloc.h> #include <spi_flash.h> -- 1.7.5.1

2 1

[U-Boot] [Patch v2] common/cmd_test: Avoid macro expansion
by York Sun 08 Apr '13

08 Apr '13

cmd_test.c adds "true" and "false" as new commands. We need to avoid macro expansion for U_BOOT_CMD. Signed-off-by: York Sun <yorksun(a)freescale.com> --- change since v1: fix typo in comment common/cmd_test.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/common/cmd_test.c b/common/cmd_test.c index d4ec186..acc0ecf 100644 --- a/common/cmd_test.c +++ b/common/cmd_test.c @@ -21,6 +21,15 @@ * MA 02111-1307 USA */ +/* + * Define _STDBOOL_H here to avoid macro expansion of true and false. + * If the future code requires macro true or false, remove this define + * and undef true and false before U_BOOT_CMD. This define and comment + * shall be removed if change to U_BOOT_CMD is made to take string + * instead of stringifying it. + */ +#define _STDBOOL_H + #include <common.h> #include <command.h> -- 1.7.9.5

2 1

[U-Boot] [PATCH] powerpc/lib: fix unsafe register handling in wait_ticks
by Mats Kärrman 08 Apr '13

08 Apr '13

If watchdog is enabled, the arch/powerpc/lib/ticks.S::wait_ticks() function calls the function specified by the WATCHDOG_RESET macro. The wait_ticks function depends on the registers r0, r6 and r7 being preserved however that is not guaranteed, e.g. if the reset function is a C function this will probably overwrite r0 and cause an endless loop. The following patch changes to using r14+r15 instead of r6+r7 (to resemble what would have been generated by a C compiler) and saves all necessary registers on the stack. The patch has been tested on a custom MPC5125 based machine using the 512x powerpc architecture. Signed-off-by: Mats Karrman <mats.karrman(a)tritech.se> Cc: Wolfgang Denk <wd(a)denx.de> Acked-by: Joakim Tjernlund <joakim.tjernlund(a)transmode.se> --- arch/powerpc/lib/ticks.S | 17 +++++++++++------ 1 files changed, 11 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/lib/ticks.S b/arch/powerpc/lib/ticks.S index 1781039..63114bb 100644 --- a/arch/powerpc/lib/ticks.S +++ b/arch/powerpc/lib/ticks.S @@ -50,19 +50,24 @@ wait_ticks: stwu r1, -16(r1) mflr r0 /* save link register */ stw r0, 20(r1) /* Use r0 or GDB will be unhappy */ - mr r7, r3 /* save tick count */ + stw r14, 12(r1) /* save used registers */ + stw r15, 8(r1) + mr r14, r3 /* save tick count */ bl get_ticks /* Get start time */ /* Calculate end time */ - addc r7, r4, r7 /* Compute end time lower */ - addze r6, r3 /* and end time upper */ + addc r14, r4, r14 /* Compute end time lower */ + addze r15, r3 /* and end time upper */ WATCHDOG_RESET /* Trigger watchdog, if needed */ 1: bl get_ticks /* Get current time */ - subfc r4, r4, r7 /* Subtract current time from end time */ - subfe. r3, r3, r6 + subfc r4, r4, r14 /* Subtract current time from end time */ + subfe. r3, r3, r15 bge 1b /* Loop until time expired */ - mtlr r0 /* restore link register */ + lwz r15, 8(r1) /* restore saved registers */ + lwz r14, 12(r1) + lwz r0, 20(r1) addi r1,r1,16 + mtlr r0 blr -- 1.7.1

4 3

[U-Boot] [PATCH 0/4 v2]: ARM: vexpress: add support for more core tiles
by Andre Przywara 08 Apr '13

08 Apr '13

This series adds support for the Cortex-A5 and Cortex-A15 core tiles for the ARM Versatile Express boards. The first two patches have been around for about one and a half years in the Linaro tree now, they refactor the A9 support and add support for A5. I kept the original commits and authors, just resolved some trivial merge conflicts and checkpatch complaints. As per request, I merged the first two original patches into one for better readability. Patch 3/4 adds support for the A15 core tile, this is actually the same as the A5 for now, but will be extended later. Patch 4/4 enables bootz and hush parser for all boards, just for convenience. Changes: v2: - merge patch 1/5 and 2/5 as per Albert's request - add support for raw initrd for full bootz experience Regards, Andre. -- Andre Przywara Linaro Virtualization Team

2 5

[U-Boot] [PATCH] mx28evk: add NAND commands
by Eric Bénard 08 Apr '13

08 Apr '13

the mx28evk has a socket which can contains a TSOP48 NAND flash. So enable the nand command and it's trimffs option. Tested on MX28EVK with NAND : NAND: 128 MiB MX28EVK U-Boot > nand info Device 0: nand0, sector size 16 KiB Page size 2048 b OOB size 64 b Erase size 16384 b and without NAND : NAND: No NAND device found!!! 0 MiB MX28EVK U-Boot > nand info MX28EVK U-Boot > Signed-off-by: Eric Bénard <eric(a)eukrea.com> --- include/configs/mx28evk.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h index 0d918a1..789d980 100644 --- a/include/configs/mx28evk.h +++ b/include/configs/mx28evk.h @@ -69,6 +69,8 @@ #define CONFIG_CMD_USB #define CONFIG_CMD_BOOTZ #define CONFIG_CMD_I2C +#define CONFIG_CMD_NAND +#define CONFIG_CMD_NAND_TRIMFFS /* * Memory configurations -- 1.7.11.7

3 4

[U-Boot] OMAP (4) boot_params
by Michael Cashwell 08 Apr '13

08 Apr '13

Greetings, I've been fighting with SPL passing not boot_params properly to u-boot on OMAP4. There are many layers to this onion but I've tracked the bulk of the problem down to the following issues. --- SPL --- arch/arm/cpu/armv7/omap-common/hwinit-common.c sets a pointer to the SPL's &boot_params correctly (cpu_init_crit->lowlevel_init->s_init) but the definition of that pointer in common/spl/spl.c: u32 *boot_params_ptr = NULL; puts it into the spl bss section (in SDRAM) which is cleared long after cpu_init_crit(). Making that: u32 *boot_params_ptr __attribute__ ((section(".data"))); allows the pointer to be in SPL data section (SRAM) and still have its value by the time image_entry() is called. But common/spl/spl.c is not omap-specific so changes there are a concern. Next, image_entry() is called with the argument being indirected an extra time: u32 boot_params_ptr_addr = (u32)&boot_params_ptr; image_entry((u32 *)boot_params_ptr_addr); That extra level of indirection is never dealt with (on ARM anyway) and it ends up passing junk to u-boot. I've tested replacing those lines with: image_entry((u32 *)boot_params_ptr); and that passes a correct address in r0 to lowlevel_init.S in u-boot. --- u-boot --- lowlevel_init.S only deals with pointers for boot_params. It does not *copy* the content of the boot_params struct. With the fixes above we get to u-boot with *the address in SRAM* of the SPL's boot_params struct stored in the first word of u-boot's boot_params struct. Here's logging showing what I have working to this point: U-Boot SPL 2013.04-rc1-00386-g1d3dea1-dirty (Apr 02 2013 - 17:21:36) OMAP4460 ES1.1 boot_params_ptr @40309a5c = 40309918 OMAP SD/MMC: 0 image entry point: 0xBF800000 U-Boot 2013.04-rc1-00386-g1d3dea1-dirty (Apr 02 2013 - 17:21:36) <<< a debug %p print of & boot_params in board_mmc_init said bffdbf10 >>> # md 0xbffdbf10 4 bffdbf10: 40309918 00000000 00000000 bffd297c <<< 40309918 is the expected SPL &boot_params in SRAM as noted above >>> # md 40309918 5 40309918: 4030d204 00000000 00000005 00000001 40309928: 00000001 That maps to the expected (omap_bootdevice == 5 being salient for me): struct omap_boot_parameters { char *boot_message; unsigned int mem_boot_descriptor; unsigned char omap_bootdevice; unsigned char reset_reason; unsigned char ch_flags; }; That leaves me at an impasse. If we expect to have a struct in both contexts then something must copy its contents. That's not currently done. Or we could have a struct in SPL but a *struct in u-boot. But that mixes the . and -> access syntax and there may be source that's agnostic to being in the SPL or u-boot. The last idea I had was to make the SPL struct hidden and only use a pointer for access. That means both SPL and u-boot source could use the -> syntax. The only places where I see this are: ./arch/arm/cpu/armv7/omap-common/boot-common.c: return (u32) (boot_params.omap_bootdevice); ./arch/arm/include/asm/arch-omap4/sys_proto.h:extern struct omap_boot_parameters boot_params; ./arch/arm/include/asm/arch-omap4/sys_proto.h: if ((boot_params.ch_flags) & (CH_FLAGS_CHSETTINGS)) ./arch/arm/include/asm/arch-omap5/sys_proto.h:extern struct omap_boot_parameters boot_params; ./arch/arm/include/asm/arch-omap5/sys_proto.h: if ((boot_params.ch_flags) & (CH_FLAGS_CHSETTINGS)) but I have no OMAP5 to test against. And I'm a little surprised that OMAP3 isn't in evidence here. This has me wrapped around the axle so many times I need guidance regarding what's "the right way" to fix this. Pointers welcome. (pun intended.) -Mike Cashwell

5 11