March 2013 - U-Boot

[U-Boot] [PATCH] omap5: Allow use of a plain text env file
by Nishanth Menon 25 Mar '13

25 Mar '13

For production systems it is better to use script images since they are protected by checksums and carry valuable information like name and timestamp. Also, you can't validate the content passed to env import. But for development, it is easier to use the env import command and plain text files instead of script-images. Since both OMAP5evm/uevm boards are used primarily for development, we allow U-Boot to load env var from a text file in case that an boot.scr script-image is not present. The variable uenvcmd (if existent) will be executed (using run) after uEnv.txt was loaded. If uenvcmd doesn't exist the default boot sequence will be started. Inspired by commit: d70f54808dfa83b574e1239c3eccbcf3317343e1 (omap4: allow the use of a plain text env file instead boot scripts) Signed-off-by: Nishanth Menon <nm(a)ti.com> --- include/configs/omap5_common.h | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h index af97564..3174423 100644 --- a/include/configs/omap5_common.h +++ b/include/configs/omap5_common.h @@ -155,6 +155,9 @@ "loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0" \ "bootscript=echo Running bootscript from mmc${mmcdev} ...; " \ "source ${loadaddr}\0" \ + "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0" \ + "importbootenv=echo Importing environment from mmc${mmcdev} ...; " \ + "env import -t ${loadaddr} ${filesize}\0" \ "loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0" \ "mmcboot=echo Booting from mmc${mmcdev} ...; " \ "run mmcargs; " \ @@ -165,9 +168,16 @@ "if run loadbootscript; then " \ "run bootscript; " \ "else " \ - "if run loaduimage; then " \ - "run mmcboot; " \ - "fi; " \ + "if run loadbootenv; then " \ + "run importbootenv; " \ + "fi;" \ + "if test -n ${uenvcmd}; then " \ + "echo Running uenvcmd ...;" \ + "run uenvcmd;" \ + "fi;" \ + "fi;" \ + "if run loaduimage; then " \ + "run mmcboot; " \ "fi; " \ "fi" -- 1.7.9.5

5 7

[U-Boot] [PATCH 0/6] Falcon boot mode for spl_mmc
by Peter Korsgaard 24 Mar '13

24 Mar '13

Ehh, seems I fat fingered the subject :/ On Sun, Mar 24, 2013 at 10:51 PM, Peter Korsgaard <peter.korsgaard(a)barco.com> wrote: > Hi, > > This patch series adds falcon boot mode for MMC (raw and FAT), similar to > the existing nand support. > > This series applies on top of the recent spl_mmc variable cleanup: > http://lists.denx.de/pipermail/u-boot/2013-March/149674.html > > As an example, it includes a RFC patch adding falcon boot support for > the am335x evm board, which has been used to test the series. > That patch should not be committed as is. > > -- > Bye, Peter Korsgaard -- Bye, Peter Korsgaard

2 1

[U-Boot] Please pull u-boot-ti/master
by Tom Rini 24 Mar '13

24 Mar '13

Hello, The following changes since commit 131a1e603b3a8438b84b41940bc6a2051a36e087: ARM: rpi_b: enable SD controller, add related env/cmds (2013-03-20 15:32:16 +0100) are available in the git repository at: git://git.denx.de/u-boot-ti.git master for you to fetch changes up to e0c60ef48bc600bcd06c08a436abfca1a963a1e7: mmc: omap_hsmmc.c: only register getcd/getwp callbacks if gpio could be used (2013-03-22 12:01:15 -0400) ---------------------------------------------------------------- Enric Balletbo i Serra (2): ARM: AM33XX: Fix typo that causes an AM duplication in CPU name. igep00x0: Enable CONFIG_CMD_BOOTZ Koen Kooi (3): am335x_evm: add support for BeagleBone Black DT name am335x_evm: Enable CMD_EXT4 and CMD_FS_GENERIC, add bootpart to env am335x_evm: Add more variables and switch to DT booting. Mark Jackson (2): Allow AM335x MPU core clock speed to be specified in the board config file Initialise correct GPMC WAITx irq for AM33xx Matt Porter (9): am33xx: convert defines from am33xx-specific to generic names am33xx: refactor emif4/ddr to support multiple EMIF instances am33xx: refactor am33xx clocks and add ti814x support am33xx: refactor am33xx mux support and add ti814x support am33xx: add ti814x specific register definitions am33xx: add dmm support to emif4 library am33xx: support ti814x mmc reference clock ns16550: enable quirks for ti814x ti814x_evm: add ti814x evm board support Nikita Kiryanov (1): cm-t35: add support for loading splash image from NAND Peter Korsgaard (2): mmc: mmc_getcd/getwp: use sensible defaults mmc: omap_hsmmc.c: only register getcd/getwp callbacks if gpio could be used Steve Kipisz (1): am33xx:ddr:Fix config_sdram to work for all DDR Tom Rini (3): am33xx: Add required includes to some omap/am33xx code am335x_evm: Add better timings for the new BeagleBoard DDR3 part arm: Correct CONFIG_STANDALONE_LOAD_ADDR for AM33XX/OMAP* platforms hvaibhav(a)ti.com (1): am335x: Enable DDR PHY dynamic power down bit for DDR3 boards MAINTAINERS | 4 + Makefile | 2 +- README | 4 + arch/arm/config.mk | 2 +- arch/arm/cpu/armv7/Makefile | 2 +- arch/arm/cpu/armv7/am33xx/Makefile | 3 +- arch/arm/cpu/armv7/am33xx/board.c | 4 +- .../cpu/armv7/am33xx/{clock.c => clock_am33xx.c} | 33 +- arch/arm/cpu/armv7/am33xx/clock_ti814x.c | 406 ++++++++++++++++++++ arch/arm/cpu/armv7/am33xx/ddr.c | 104 +++-- arch/arm/cpu/armv7/am33xx/emif4.c | 57 ++- arch/arm/cpu/armv7/am33xx/mem.c | 2 +- arch/arm/cpu/armv7/am33xx/sys_info.c | 5 +- arch/arm/cpu/armv7/omap-common/Makefile | 2 +- arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 1 + arch/arm/cpu/armv7/omap-common/timer.c | 1 + arch/arm/include/asm/arch-am33xx/clock.h | 2 +- arch/arm/include/asm/arch-am33xx/clocks_am33xx.h | 36 +- arch/arm/include/asm/arch-am33xx/cpu.h | 11 +- arch/arm/include/asm/arch-am33xx/ddr_defs.h | 75 +++- arch/arm/include/asm/arch-am33xx/hardware.h | 40 +- arch/arm/include/asm/arch-am33xx/hardware_am33xx.h | 54 +++ arch/arm/include/asm/arch-am33xx/hardware_ti814x.h | 53 +++ arch/arm/include/asm/arch-am33xx/mmc_host_def.h | 5 + arch/arm/include/asm/arch-am33xx/mux.h | 235 +---------- arch/arm/include/asm/arch-am33xx/mux_am33xx.h | 247 ++++++++++++ arch/arm/include/asm/arch-am33xx/mux_ti814x.h | 311 +++++++++++++++ arch/arm/include/asm/arch-am33xx/omap.h | 5 + arch/arm/include/asm/arch-am33xx/spl.h | 5 + arch/arm/include/asm/arch-am33xx/sys_proto.h | 2 + board/cm_t35/cm_t35.c | 61 +++ board/phytec/pcm051/board.c | 8 +- board/ti/am335x/board.c | 57 ++- board/ti/ti814x/Makefile | 46 +++ board/ti/ti814x/evm.c | 198 ++++++++++ board/ti/ti814x/evm.h | 7 + board/ti/ti814x/mux.c | 51 +++ boards.cfg | 1 + drivers/mmc/mmc.c | 16 +- drivers/mmc/omap_hsmmc.c | 8 +- drivers/mtd/nand/omap_gpmc.c | 1 + drivers/net/cpsw.c | 1 + drivers/serial/ns16550.c | 5 +- include/configs/am335x_evm.h | 28 +- include/configs/cm_t35.h | 4 + include/configs/igep00x0.h | 3 +- include/configs/pcm051.h | 3 +- include/configs/ti814x_evm.h | 221 +++++++++++ spl/Makefile | 2 +- 49 files changed, 2037 insertions(+), 397 deletions(-) rename arch/arm/cpu/armv7/am33xx/{clock.c => clock_am33xx.c} (91%) create mode 100644 arch/arm/cpu/armv7/am33xx/clock_ti814x.c create mode 100644 arch/arm/include/asm/arch-am33xx/hardware_am33xx.h create mode 100644 arch/arm/include/asm/arch-am33xx/hardware_ti814x.h create mode 100644 arch/arm/include/asm/arch-am33xx/mux_am33xx.h create mode 100644 arch/arm/include/asm/arch-am33xx/mux_ti814x.h create mode 100644 board/ti/ti814x/Makefile create mode 100644 board/ti/ti814x/evm.c create mode 100644 board/ti/ti814x/evm.h create mode 100644 board/ti/ti814x/mux.c create mode 100644 include/configs/ti814x_evm.h And a full set of applied replies to the various patches coming soon, just want this out the door. Thanks! -- Tom

2 3

[U-Boot] [PATCH v0 0/4] env: reworking + default/import individual vars
by Gerlando Falauto 24 Mar '13

24 Mar '13

This is a resubmission (after removing remove checkpatch errors) of http://lists.denx.de/pipermail/u-boot/2011-September/102875.html Here I am proposing a set of changes in the behaviour of the environment import/set_to_default functions. PATCH 1: Add a "new" himport_ex() function (reworking of himport_r which is now a wrapper around it), which has 3 new arguments: "nvars", "vars":, number and list of variables to take into account (0 means ALL) "apply" callback function which is in charge of checking whether a variable can be overwritten, and possibly immediately apply the changes. This parameter would be either set to NULL (in which case nothing should change wrt to the past -- i.e. environment is blindly imported) or to "env_check_apply()" function, whose code was taken away from _do_env_set(). This would be useful, for instance, for "baudrate" or "stdin,stderr,stdout", whose changes would not otherwise be effective until the next reboot. The idea is that there should be a single place where all the checks are to be performed. So the same function env_check_apply() is called from _do_env_set() as well (thus keeping the previous behavior). PATCH 2: Add the same behaviour when deleting variables. Not quite sure whether this makes sense or not. PATCH 3: Add the code for setting individual variables to default PATCH 4: Impolement importing of individual variables (also taking into account "-f" for forcing). Gerlando Falauto (4): Groundwork for generalization of env interface env: check and apply changes on delete/destroy env: implement selective "env default" env: implement "env import -n var[,var...]" README | 2 + common/cmd_nvedit.c | 231 ++++++++++++++++++++++++++++++++-------------- common/env_common.c | 29 ++++++- include/config_cmd_all.h | 1 + include/environment.h | 12 +++ include/search.h | 19 ++++- lib/hashtable.c | 68 ++++++++++++- 7 files changed, 284 insertions(+), 78 deletions(-)

7 44

[U-Boot] [PATCH v2] mxs: spl_mem_init: Align DDR2 init with FSL bootlets source
by Fabio Estevam 23 Mar '13

23 Mar '13

From: Fabio Estevam <fabio.estevam(a)freescale.com> Currently the following kernel hang happens when loading a 2.6.35 kernel from Freeescale on a mx28evk board: RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Bus freq driver module loaded IMX usb wakeup probe usb h1 wakeup device is registered mxs_cpu_init: cpufreq init finished ... Loading the same kernel using the bootlets from the imx-bootlets-src-10.12.01 package, the hang does not occur. Comparing the DDR2 initialization from the bootlets code against the U-boot one, we can notice some mismatches, and after applying the same initialization into U-boot the 2.6.35 kernel can boot normally. Also tested with 'mtest' command, which runs succesfully. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- Changes since v1: - Fix tabs/space confusion and only show the real context changes arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c index f8392f6..2195dce 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c @@ -45,17 +45,17 @@ static uint32_t dram_vals[] = { 0x00000000, 0x00000000, 0x00010101, 0x01010101, 0x000f0f01, 0x0f02020a, 0x00000000, 0x00010101, 0x00000100, 0x00000100, 0x00000000, 0x00000002, - 0x01010000, 0x05060302, 0x06005003, 0x0a0000c8, - 0x02009c40, 0x0000030c, 0x0036a609, 0x031a0612, + 0x01010000, 0x07080403, 0x06005003, 0x0a0000c8, + 0x02009c40, 0x0002030c, 0x0036a609, 0x031a0612, 0x02030202, 0x00c8001c, 0x00000000, 0x00000000, 0x00012100, 0xffff0303, 0x00012100, 0xffff0303, 0x00012100, 0xffff0303, 0x00012100, 0xffff0303, 0x00000003, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000612, 0x01000F02, - 0x06120612, 0x00000200, 0x00020007, 0xf5014b27, - 0xf5014b27, 0xf5014b27, 0xf5014b27, 0x07000300, - 0x07000300, 0x07000300, 0x07000300, 0x00000006, + 0x06120612, 0x00000200, 0x00020007, 0xf4004a27, + 0xf4004a27, 0xf4004a27, 0xf4004a27, 0x07000300, + 0x07000300, 0x07400300, 0x07400300, 0x00000005, 0x00000000, 0x00000000, 0x01000000, 0x01020408, 0x08040201, 0x000f1133, 0x00000000, 0x00001f04, 0x00001f04, 0x00001f04, 0x00001f04, 0x00001f04, @@ -76,14 +76,14 @@ static uint32_t dram_vals[] = { 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, - 0x00000000, 0x00000000, 0x00010000, 0x00020304, - 0x00000004, 0x00000000, 0x00000000, 0x00000000, + 0x00000000, 0x00000000, 0x00010000, 0x00030404, + 0x00000003, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x01010000, 0x01000000, 0x03030000, 0x00010303, 0x01020202, 0x00000000, 0x02040303, 0x21002103, 0x00061200, - 0x06120612, 0x04320432, 0x04320432, 0x00040004, + 0x06120612, 0x04420442, 0x04420442, 0x00040004, 0x00040004, 0x00000000, 0x00000000, 0x00000000, - 0x00000000, 0x00010001 + 0x00000000, 0xffffffff /* * i.MX23 DDR at 133MHz -- 1.7.9.5

5 23

[U-Boot] u-boot-imx: tags
by Ruud Commandeur 23 Mar '13

23 Mar '13

Hi everyone, A few weeks ago I cloned the u-boot-imx git and was able to build u-boot for the mx28evk without problems. Just great, but I was wondering how to tell which u-boot version would be the best to pick. Is it just "the latest and greatest", or is there also some release-scheme like for the kernel, with mainline or stable versions that will be maintained? Now I have "U-Boot 2013.01-10534-gbec0160-dirty". I did take a look at the tags, but the latest one is for 2009.08. For the regular u-boot, tags seem to be more recent. Thanks, Ruud

3 2

[U-Boot] Patch sets coming
by York Sun 23 Mar '13

23 Mar '13

Andy, I am sending out several sets of backlog patches. Some of them may have been sent before. To make them easier to apply, here they come in sets. In case my git send-email fails to add the author(s) to the CC list, please add them when you reply (it happened before). York

3 19

[U-Boot] [PATCH v2 0/7] Add cros-ec protocol driver and enable it in smdk5250
by Hung-ying Tyan 23 Mar '13

23 Mar '13

This patch series adds the drivers for the cros-ec protocol that is used to communicate with the ChromeOS Embedded Controller (EC). The series also enables its use in Google Snow based on smdk5250. The series depends on the following patches: 1) http://patchwork.ozlabs.org/patch/217347 add dts file for Snow 2) mmc series: http://patchwork.ozlabs.org/patch/225008 3) power patches needed by one of the mmc patches http://patchwork.ozlabs.org/patch/220060 EXYNOS5: Add function to setup set ps hold http://patchwork.ozlabs.org/patch/220061 SMDK5250: Add PMIC voltage settings (needed by one of the mmc patches) ----- Changes in v2: - Moved code from smdk5250.c (non-FDT) to exynos5-dt.c (FDT). - Moved code from smdk5250.h to exynos5250-dt.h. - Add gpio node to exynos5250.dtsi. - Fixed warnings of exceeding 80 chars in a line. - Added commit messages to each patch. - Dropped the period from commit subjects. Hung-ying Tyan (7): cros: add cros_ec driver cros: add I2C support for cros_ec cros: add SPI support for cros_ec cros: add LPC support for cros_ec cros: adds cros_ec keyboard driver cros: exynos: add cros-ec device nodes to exynos5250-snow.dts cros: enable cros-ec for smdk5250 README | 5 + arch/arm/dts/exynos5250.dtsi | 3 + board/samsung/dts/exynos5250-snow.dts | 82 ++ board/samsung/smdk5250/exynos5-dt.c | 45 + doc/device-tree-bindings/input/cros-ec-keyb.txt | 79 ++ doc/device-tree-bindings/misc/cros-ec.txt | 38 + doc/device-tree-bindings/spi/exynos-spi.txt | 55 + drivers/input/Makefile | 1 + drivers/input/cros_ec_keyb.c | 264 +++++ drivers/misc/Makefile | 4 + drivers/misc/cros_ec.c | 1304 ++++++++++++++++++++ drivers/misc/cros_ec_i2c.c | 199 ++++ drivers/misc/cros_ec_lpc.c | 283 +++++ drivers/misc/cros_ec_spi.c | 166 +++ drivers/spi/exynos_spi.c | 22 + include/configs/exynos5250-dt.h | 10 +- include/cros_ec.h | 449 +++++++ include/cros_ec_message.h | 44 + include/ec_commands.h | 1440 +++++++++++++++++++++++ include/fdtdec.h | 2 + include/spi.h | 16 + lib/fdtdec.c | 2 + 22 files changed, 4512 insertions(+), 1 deletion(-) create mode 100644 doc/device-tree-bindings/input/cros-ec-keyb.txt create mode 100644 doc/device-tree-bindings/misc/cros-ec.txt create mode 100644 doc/device-tree-bindings/spi/exynos-spi.txt create mode 100644 drivers/input/cros_ec_keyb.c create mode 100644 drivers/misc/cros_ec.c create mode 100644 drivers/misc/cros_ec_i2c.c create mode 100644 drivers/misc/cros_ec_lpc.c create mode 100644 drivers/misc/cros_ec_spi.c create mode 100644 include/cros_ec.h create mode 100644 include/cros_ec_message.h create mode 100644 include/ec_commands.h -- 1.8.1.3

2 14

Re: [U-Boot] Integrator PCI base dilemma
by Linus Walleij 23 Mar '13

23 Mar '13

On Fri, Mar 22, 2013 at 11:37 AM, Russell King - ARM Linux <linux(a)arm.linux.org.uk> wrote: > On Fri, Mar 22, 2013 at 09:48:27AM +0000, Arnd Bergmann wrote: >> Yes, I was assuming that Linus would keep Integrator/AP working since that is >> what he uses. > > It's entirely possible that Linus doesn't use a VGA card with Integrator/AP > if Linus is not using MILO - because MILO was the only boot loader for > that platform which had an x86 emulator built in to run the VGA BIOS to > initialize the VGA card. You are right, or, well, I have had an S3 VGA card plugged in and been scratching my head wondering how I should get the damned thing to work. Now I *know* there is not really a way for me to make this work with the kernel only. > There are two boot loaders I'm aware of which are capable of doing this, > and those are MILO and my boot loader for Footbridge platforms (which, > incidentally, now runs ATA card BIOSes too complete with input support > and can push out the VGA output via serial and accept keypresses via > serial) - and that doesn't work on Integrator/AP. I'm on U-boot for this thing, I wonder if that can do x86 emulation to initialize VGA card. I guess I'm about to learn. Yours, Linus Walleij

4 5

[U-Boot] Issues developing standalone applications
by Lucas Endres 23 Mar '13

23 Mar '13

Hi, I am new to U-Boot and I am trying to develop a standalone application that accesses my board peripherals. I couldn't find any examples on how to access my NAND device, for example, and when trying to run the same sequence that is made in the board's initialization, I get an ** Illegal Instruction ** error, causing the board to reboot. I know it's an issue on the NAND initialization, but I am neither very familiar to the U-Boot code nor to debugging errors. What follows is the console output I get when trying to run nand_init_chip() from my standalone application: NIP: 3FFDB098 XER: 20000000 LR: 00046170 REGS: 3bf4f528 TRAP: 0700 DAR: 00000000 MSR: 00029200 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 00 ** Illegal Instruction ** Call backtrace: 65782035 000465EC 00046668 00046764 3FF6F548 3FF6F5C8 3FF7FE44 3FF8001C 3FF62A74 3FF61630 Program Check Exception I need to run a badblocks test on the NAND device, and I successfully do it in the board initialization from within the U-Boot environment, but not from the standalone environment. I could really use some examples, but I couldn't find any online. Thank you so much for your attention, Lucas Pereira Endres.

2 1