February 2013 - U-Boot

[U-Boot] Please pull u-boot-x86.git
by Simon Glass 04 Mar '13

04 Mar '13

Hi Tom, This series includes the sandbox map_sysmem() feature, and gets the memory and hashing functions running on sandbox to allow testing/code coverage. I have run it through buildman and it seems clean, with the proviso that I don't have fully-working toolchains for all architectures. The following changes since commit 9f024f62e4604274a23213dcee30016092e32e7b: Merge branch 'fixes' of git://git.denx.de/u-boot-mips (2013-02-15 12:23:42 -0500) are available in the git repository at: git://git.denx.de/u-boot-x86.git master for you to fetch changes up to d76bd1c2d5e75db16b239bd2d4a642673974e250: sandbox: Allow hash functions to work correctly (2013-02-15 16:06:06 -0800) ---------------------------------------------------------------- Allen Martin (1): sandbox: fix compiler warning Simon Glass (19): Tidy up error checking and fix bug in hash command Update print_buffer() to use const sandbox: Add un/map_sysmen() to deal with sandbox's ram_buf sandbox: Change memory commands to use map_physmem Split out the memory tests into separate functions Use common mtest iteration counting Fix mtest indenting Bring mtest putc() into common code Reduce casting in mtest Update set_working_fdt_addr() to use setenv_addr() common: Use new numeric setenv functions drivers: Use new numeric setenv functions net: Use new numeric setenv functions image: Use crc header file instead of C prototypes Roll crc32 into hash infrastructure sandbox: config: Enable hash functions and mtest Move CONFIG_SYS_MEMTEST_SCRATCH #ifdef to top of file sandbox: Update mtest to fix crashes sandbox: Allow hash functions to work correctly Taylor Hutt (1): sandbox: Improve sandbox serial port keyboard interface README | 9 + arch/sandbox/config.mk | 1 + arch/sandbox/cpu/os.c | 8 + arch/sandbox/cpu/start.c | 3 + arch/sandbox/include/asm/io.h | 10 + common/cmd_bootm.c | 11 +- common/cmd_cbfs.c | 4 +- common/cmd_cramfs.c | 4 +- common/cmd_fdos.c | 4 +- common/cmd_fdt.c | 11 +- common/cmd_hash.c | 4 + common/cmd_jffs2.c | 4 +- common/cmd_load.c | 12 +- common/cmd_mem.c | 798 +++++++++++++++++++++--------------------- common/cmd_mtdparts.c | 4 +- common/cmd_nand.c | 12 +- common/cmd_nvedit.c | 11 +- common/cmd_reiser.c | 4 +- common/cmd_setexpr.c | 39 ++- common/cmd_unzip.c | 4 +- common/cmd_ximg.c | 7 +- common/cmd_zfs.c | 3 +- common/cmd_zip.c | 4 +- common/hash.c | 31 +- common/image.c | 4 +- drivers/net/fm/fm.c | 4 +- drivers/serial/sandbox.c | 44 ++- fs/fs.c | 4 +- fs/ubifs/ubifs.c | 4 +- include/common.h | 29 +- include/configs/sandbox.h | 9 +- include/hash.h | 2 +- include/os.h | 10 + include/u-boot/crc.h | 11 + lib/crc32.c | 9 + lib/display_options.c | 3 +- net/net.c | 8 +- 37 files changed, 615 insertions(+), 528 deletions(-) Regards, Simon

4 14

[U-Boot] [PATCH 0/11] sandbox: Add filesystem support
by Simon Glass 04 Mar '13

04 Mar '13

This series adds support for filesystems to sandbox. While we don't yet have access to host machine block devices, we can access files on the host through a new 'host' filesystem type and the new sandbox command 'sb'. For example: sb load host 0 1000 foo.bar will load foo.bar from the host into memory at address 1000. The '0' parameter is the device number, currently unused. While doing this work, I noticed that fs.c had code that probably belongs more in the filesystems themselves. So this series moves fat/ext4 code into those files. This removes most of the #ifdefs from this file, as well as the #defines of functions to 'unsupported'. Now there is a list of filesystems that we support, and if we don't find the one we need, we automatically fall back to the 'unsupported' one. Finally, the ext4 write support is moved into a separate file since ext4fs.c was over 3500 lines and the write support seems entirely separate from the main function in that file. Simon Glass (11): ext4: Split write support into its own file fs: Fully populate the filesystem method struct fs: Use filesystem methods instead of switch() fs: Tell probe functions where to put their results fs: Use map_sysmem() on read fs: Move ls and read methods into ext4, fat sandbox: Add a way of obtaining directory listings sandbox: Add host filesystem sandbox: Add 'sb' command to access filesystem features sandbox: Enable ext4 and fat filesystems sandbox: config: Enable sandbox command Makefile | 1 + README | 1 + arch/sandbox/cpu/os.c | 101 +++++ common/Makefile | 1 + common/cmd_sandbox.c | 63 +++ disk/part.c | 17 + fs/ext4/Makefile | 2 +- fs/ext4/ext4_write.c | 996 +++++++++++++++++++++++++++++++++++++++++++++ fs/ext4/ext4fs.c | 962 +------------------------------------------ fs/fat/fat.c | 17 + fs/fs.c | 237 +++++------- fs/sandbox/Makefile | 47 +++ fs/sandbox/sandboxfs.c | 83 ++++ include/config_cmd_all.h | 1 + include/configs/sandbox.h | 9 + include/ext4fs.h | 3 + include/fat.h | 2 + include/fs.h | 1 + include/os.h | 48 +++ include/sandboxfs.h | 30 ++ 20 files changed, 1533 insertions(+), 1089 deletions(-) create mode 100644 common/cmd_sandbox.c create mode 100644 fs/ext4/ext4_write.c create mode 100644 fs/sandbox/Makefile create mode 100644 fs/sandbox/sandboxfs.c create mode 100644 include/sandboxfs.h -- 1.7.7.3

3 31

[U-Boot] [PATCH v2 1/3] am335x-evm: enable ext4
by Koen Kooi 04 Mar '13

04 Mar '13

The kernel is loaded from an ext4 partition, not ext2 on beaglebone boards. Signed-off-by: Koen Kooi <koen(a)dominion.thruhere.net> --- include/configs/am335x_evm.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index 72459d8..2190a7d 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -144,6 +144,7 @@ #define CONFIG_DOS_PARTITION #define CONFIG_CMD_FAT #define CONFIG_CMD_EXT2 +#define CONFIG_CMD_EXT4 #define CONFIG_SPI #define CONFIG_OMAP3_SPI -- 1.8.1.2

3 9

[U-Boot] [PATCH v3 0/4] Add NAND support to DFU, enable for am335x_evm
by Tom Rini 04 Mar '13

04 Mar '13

This series adds DFU support to NAND and was started by Pantelis. The NAND changes have been compile-tested on all ARM and PowerPC targets and run-time tested on ARM. DFU itself has been tested, for NAND, on am335x_evm. For practical reasons, this series depends on Pantelis' previous series of generic DFU changes. Lukasz and I are discussing how to handle a few changes there since one of them breaks file writing. -- Tom Changes in v3: - Reworked skip_check_len changes to just add accounting for *used to the logic. - Allow for actual to be NULL in nand_(read|write)_skip_bad, only DFU calls this with a non-NULL parameter. Make sure the comments for both functions explain the parameters and their behavior. - Other style changes requested by Scott. - As nand_(write|read)_skip_bad passes back just a used length now. - Rework logic in nand_block_op for nand_(read|write)_skip_bad returning just a size for actual used length. - Remove unused externs from drivers/dfu/dfu_nand.c - Fix checkpatch.pl warnings in include/configs/am335x_evm.h Changes in v2: - NAND skip_check_len changes reworked to allow nand_(read|write)_skip_bad to return this information to the caller. - nand_block_op calls nand_(read|write)_skip_bad directly. - Bugfix in dfu_nand to make sure we set dfu->skip_bad to 0 on each iteration. - Add CONFIG_CMD_MTDPARTS and relevant information to am335x_evm - Enable DFU for NAND and MMC, set dfu_alt_info_(nand|mmc) as examples for both in am335x_evm.h - Increase CONFIG_SYS_MAXARGS due to hush parsing bugs that would otherwise prevent 'setenv dfu_alt_info ${dfu_alt_info_nand}' on am335x_evm Pantelis Antoniou (2): dfu: NAND specific routines for DFU operation am335x_evm: Enable DFU for NAND and MMC, provide example alt_info for both Tom Rini (2): nand: Extend nand_(read|write)_skip_bad with *actual and limit parameters am335x_evm: Add CONFIG_CMD_MTDPARTS and relevant defaults common/cmd_nand.c | 56 ++++++------ common/env_nand.c | 3 +- drivers/dfu/Makefile | 1 + drivers/dfu/dfu.c | 8 ++ drivers/dfu/dfu_nand.c | 195 ++++++++++++++++++++++++++++++++++++++++++ drivers/mtd/nand/nand_util.c | 67 +++++++++++++-- include/configs/am335x_evm.h | 47 +++++++++- include/dfu.h | 23 +++++ include/nand.h | 4 +- 9 files changed, 365 insertions(+), 39 deletions(-) create mode 100644 drivers/dfu/dfu_nand.c -- 1.7.9.5

2 10

[U-Boot] problem with USB storage STALL status
by Anton Vasilyev 04 Mar '13

04 Mar '13

Greetings, I faced with problem: when I read data from USB Storage It unpredictably goes to 'RESET:stall' condition. After this read continuously fall down to usb_stor_BBB_reset() function Comment to this function told about Reset recovery: * For Reset Recovery the host shall issue in the following order: * a) a Bulk-Only Mass Storage Reset * b) a Clear Feature HALT to the Bulk-In endpoint * c) a Clear Feature HALT to the Bulk-Out endpoint * * This is done in 3 steps. * * If the reset doesn't succeed, the device should be port reset. Whereas Universal Serial Bus Specification Revision 2.0 in section 8.5.3 describes that STALL handshake will be returned on all succeeding accesses until a SETUP PID is received. I can't understand how correctly work with STALL status and where is a root of problem. Debug information is following: STATUS phase dev=3f3b03d8, pipe=c8008383, buffer=3f1f7490, length=13, req=(null) TOKEN=0x80008d00 .read10: start 7c70 blocks 28 COMMAND phase dev=3f3b03d8, pipe=c8008303, buffer=3f1f7444, length=31, req=(null) TOKEN=0x80008c00 DATA phase dev=3f3b03d8, pipe=c8008383, buffer=0058e000, length=20480, req=(null) TOKEN=0x8000dd08 usb_bulk_msg error status 32 BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 dev=3f3b03d8, pipe=88000303, buffer=(null), length=0, req=3f1f7430 req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0 TOKEN=0x80248 RESET:stall Read ERROR COMMAND phase dev=3f3b03d8, pipe=c8008303, buffer=3f1f7444, length=31, req=(null) dev=3, usbsts=0x88, p[1]=0x8001205, p[2]=0x0 usb_stor_BBB_comdat:usb_bulk_msg error failed to send CBW status -2147483648 BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 dev=3f3b03d8, pipe=88000303, buffer=(null), length=0, req=3f1f7430 req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0 TOKEN=0x80248 RESET:stall Request Sense returned 00 00 00 .read10: start 7c70 blocks 28 COMMAND phase dev=3f3b03d8, pipe=c8008303, buffer=3f1f7444, length=31, req=(null) dev=3, usbsts=0x88, p[1]=0x8001205, p[2]=0x0 usb_stor_BBB_comdat:usb_bulk_msg error failed to send CBW status -2147483648 BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 dev=3f3b03d8, pipe=88000303, buffer=(null), length=0, req=3f1f7430 req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0 TOKEN=0x80248 RESET:stall Read ERROR COMMAND phase dev=3f3b03d8, pipe=c8008303, buffer=3f1f7444, length=31, req=(null) dev=3, usbsts=0x88, p[1]=0x8001205, p[2]=0x0 usb_stor_BBB_comdat:usb_bulk_msg error failed to send CBW status -2147483648 BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 dev=3f3b03d8, pipe=88000303, buffer=(null), length=0, req=3f1f7430 req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0 TOKEN=0x80248 RESET:stall Request Sense returned 00 00 00 .read10: start 7c70 blocks 28 COMMAND phase dev=3f3b03d8, pipe=c8008303, buffer=3f1f7444, length=31, req=(null) dev=3, usbsts=0x88, p[1]=0x8001205, p[2]=0x0 usb_stor_BBB_comdat:usb_bulk_msg error failed to send CBW status -2147483648 BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 dev=3f3b03d8, pipe=88000303, buffer=(null), length=0, req=3f1f7430 req=255 (0xff), type=33 (0x21), value=0 (0x0), index=0 TOKEN=0x80248 RESET:stall Read ERROR -- Best regards, Anton Vasilyev.

2 2

[U-Boot] Remounting UBI image leads to ECC errors
by Mark Jackson 04 Mar '13

04 Mar '13

We have a custom made AM335x board I'm working on and I have encountered a problem when mounting an ubifs image from nand. If I ... (1) Write an ubifs image to nand (2) Mount the ubifs image (3) Repeat step (2) ... this then corrupts the ubifs image. Below is a full log. Can anyone help ? Regards Mark J. --- U-Boot SPL 2013.01-00336-g044fbc4-dirty (Feb 26 2013 - 14:07:36) U-Boot 2013.01-00336-g044fbc4-dirty (Feb 26 2013 - 14:07:36) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled NAND: 256 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401000 using PIO, IRQ 0 Net: cpsw U-Boot# nandecc hw 2 HW BCH8 selected U-Boot# mw.b 82000000 ff 81f000 U-Boot# dhcp 82000000 10.0.0.100:/nanobone/rootfs.ubifs link up on port 0, speed 100, full duplex BOOTP broadcast 1 *** Unhandled DHCP Option in OFFER/ACK: 46 *** Unhandled DHCP Option in OFFER/ACK: 46 DHCP client bound to address 10.0.0.104 Using cpsw device TFTP from server 10.0.0.100; our IP address is 10.0.0.104 Filename '/nanobone/rootfs.ubifs'. Load address: 0x82000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ##################### 657.2 KiB/s done Bytes transferred = 6029312 (5c0000 hex) U-Boot# nand erase 200000 4000000 NAND erase: device 0 offset 0x200000, size 0x4000000 Erasing at 0x41e0000 -- 100% complete. OK U-Boot# nand write 82000000 200000 81f000 NAND write: device 0 offset 0x200000, size 0x81f000 8515584 bytes written: OK U-Boot# nandecc hw 2 HW BCH8 selected U-Boot# mtdparts default U-Boot# ubi part rootfs Creating 1 MTD partitions on "nand0": 0x000000200000-0x000004200000 : "mtd=6" UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size: 129024 bytes UBI: smallest flash I/O unit: 2048 UBI: sub-page size: 512 UBI: VID header offset: 512 (aligned 512) UBI: data offset: 2048 UBI: volume 0 ("root") re-sized from 44 to 503 LEBs UBI: attached mtd1 to ubi0 UBI: MTD device name: "mtd=6" UBI: MTD device size: 64 MiB UBI: number of good PEBs: 512 UBI: number of bad PEBs: 0 UBI: max. allowed volumes: 128 UBI: wear-leveling threshold: 4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 1 UBI: available PEBs: 0 UBI: total number of reserved PEBs: 512 UBI: number of PEBs reserved for bad PEB handling: 5 UBI: max/mean erase counter: 1/0 U-Boot# nandecc hw 2 HW BCH8 selected U-Boot# mtdparts default U-Boot# ubi part rootfs UBI: mtd1 is detached from ubi0 Creating 1 MTD partitions on "nand0": 0x000000200000-0x000004200000 : "mtd=6" UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size: 129024 bytes UBI: smallest flash I/O unit: 2048 UBI: sub-page size: 512 UBI: VID header offset: 512 (aligned 512) UBI: data offset: 2048 ECC: uncorrectable. ECC: uncorrectable. UBI error: ubi_io_read: error -74 while reading 64 bytes from PEB 510:0, read 64 bytes ECC: uncorrectable. ECC: uncorrectable. UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB 510:512, read 512 bytes ECC: uncorrectable. ECC: uncorrectable. UBI error: ubi_io_read: error -74 while reading 64 bytes from PEB 511:0, read 64 bytes ECC: uncorrectable. ECC: uncorrectable. UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB 511:512, read 512 bytes ECC: uncorrectable. ECC: uncorrectable.

2 2

[U-Boot] [PATCH v5 0/23] Create generic board init for ARM, x86, PPC
by Simon Glass 03 Mar '13

03 Mar '13

This series creates a generic board init implementation which contains the essential functions of the major arch/xxx/lib/board.c files. It is split into two parts: board_f.c for pre-relocation and board_r.c for post-relocation. What is the motivation for this change? 1. There is a lot of repeated code in the board.c files. Any change to things like setting up the baud rate requires a change in 10 separate places. 2. Since there are 14 separate files, adding a new feature which requires initialisation is painful since it must be independently added in 14 places. 3. As time goes by the architectures naturely diverge since there is limited pressure to compare features or even CONFIG options against simiilar things in other board.c files. 4. New architectures must implement all the features all over again, and sometimes in subtley different ways. This places an unfair burden on getting a new architecture fully functional and running with U-Boot. 5. While it is a bit of a tricky change, I believe it is worthwhile and achievable. There is no requirement that all code be common, only that the code that is common should be located in common/board.c rather than arch/xxx/lib/board.c. All the functions of board_init_f() and board_init_r() are broken into separate function calls so that they can easily be included or excluded for a particular architecture. It also makes it easier to adopt Graeme's initcall proposal assuming this comes about. http://lists.denx.de/pipermail/u-boot/2012-January/114499.html This series is not dependent on generic relocation. So relocation happens as one big chunk and is still completely arch-specific. See the relocation series for a proposed solution to this for ARM: http://lists.denx.de/pipermail/u-boot/2011-December/112928.html or x86's implementation which is in mainline. Unifying relocation is probably the next step after this series. Instead of moving over a whole architecture, this series takes the approach of simply enabling generic board support for an architecture. It is then up to each board to opt in by defining CONFIG_SYS_GENERIC_BOARD in the board config file. If this is not done, then the code will be generated as before. This allows both sets of code to co-exist until we are comfortable with the generic approach, and enough boards run. ARM is a relatively large board.c file and one which I can test, therefore I think it is a good target for this series. On the other hand, x86 is relatively small and simple, but different enough that it introduces a few issues to be solved. So I have chosen both ARM and x86 for this series. After a suggestion from Wolfgang I have added PPC also. This is the largest and most feature-full board, so hopefully we have all bases covered in this series. Other archs are mostly a subset of these. A generic global_data structure is now in mainline, and this is required for this series. Similarly we need a generic bd_info structure, since generic code will be accessing it. I have done this with a simple generic file for now. There was dicussion on the list about passing gd_t around as a parameter to pre-relocation init functions. I think this makes sense, but it can be done as a separate change, and this series does not require it. While this series needs to stand on its own, the goal is the unification of the board init code. So I hope we can address issues with this in mind, rather than focusing too narrowly on particular ARM, x86 or PPC issues. I have added TODO markers in places where I think there are opportunities to relationalise the board init now it is all in one place, but these don't need to be addressed for the feature to work, and are best done as smaller patches than can be reviewed by individual arch maintainers, I think. I have run-tested ARM on Tegra Seaboard and x86/coreboot only. To try it out, define CONFIG_SYS_GENERIC_BOARD in your board file and rebuild. Most likely on PPC at least it will hang, but if you are lucky it will print something first :-) I hope to test an SPL board (snow / exynos5250) when I can get that booting from mainline. I have run this though buildman with CONFIG_SYS_GENERIC_BOARD on for all ARM, PPC and x86 boards. The only failure is highbank (an ARM board), which seems to use SCSI but scsi_init() is not available. Code size increases by about 1KB on ARM and about 1.3KB on PPC with generic board enabled. This is mostly due to the move to using separate functions for each part of the init, which will make it easier to move to a pure initcall approach later if we want to. Since this series was first sent there have been additions to the board code for ARM and PPC. I have added in these additions. This is a manual process, and I expect that people will find problems (and send patches) as they try out their boards. Changes in v5: - Use unsigned int for baud_rate - Remove bi_ip_addr field from struct bd_info - Add new patch to replace __bss_end__ with __bss_end - Remove the __bss_end #define now that this is consistent across U-Boot - Remove avr32 changes from what should be an arm patch - Adjust u-boot-nds32.h link symbols to keep U-Boot building - Add debug() code to initcalls - Update copyright on initcalls - Avoid using static declaration for init_func_watchdog_reset() - Add fdtdec header file to board_f.c - Remove setup_global_data_ptr() - Tidy up stack init - Put global data on stack in board_init_f() - Add fdt relocation - Remove fdt relocation field from x86 arch_global_data - Deal with change of board_init_f() semantics on ARM - Save boot_flags in global_data in board_init_f() - Add print_cpuinfo() prototype to include/common.h - Add code from arch/arm/lib/board.c to control loading of environment - Put watchdog init function definitions in watchdog.h - Adjust ppc to work with watchdog.h additions - Add new patch to fix config in keymile boards - Add offsets support for access to fdt that uses CONFIG_OF_SEPARATE - Use watchdog.h for watchdog functions - Add define to work around __bss_end / __bss_end__ confusion - Add prototype for update_flash_size() to include/common.h - Updates in board_r.c to make ppc build correctly - Add prototype for board_start_ide() to include/ide.h - Bring in new ppc features since this patch was first created - Add new patch to adjust board_f.c for x86 - Add new patch to adjust board_r.c for x86 - Include asm/sections.h in x86 sdram code - Define _end instead of __end for x86 - Avoid setting up gd on x86 as it is already done Changes in v4: - Add three more fields required for ARM - Add asm/sections.h for each architecture - Use asm/sections.h instead of asm-generic/sections.h - Use asm/sections.h instead of asm-generic/sections.h - Adjust u-boot-x86.h link symbols to keep U-Boot building - Use asm/sections.h instead of asm-generic/sections.h - Use asm/sections.h instead of asm-generic/sections.h - Updates to sit on top of earlier patches - Updates to sit on top of earlier patches - Use asm/sections.h instead of asm-generic/sections.h - Rebase to master - Drop sc520_timer.c patch (warning already fixed by previous patch) Changes in v3: - Cast away the volatile on gd for memcpy() - Add header to new x86 relocate.c and init_helpers.c - Rebase to master - Rebase on top of x86/master (which has not yet been pulled to master) Changes in v2: - Change generic board to an opt-in system on a per-board basic - Add CONFIG_SYS_GENERIC_BOARD to allow board to select generic board - Add PowerPC support - Rebase to master Simon Glass (23): ppc: Add initial memory barrier macros Introduce generic u-boot.h file Replace __bss_end__ with __bss_end Introduce generic link section.h symbol files arm: Use sections header to obtain link symbols x86: nds32: Change stub example to use asm-generic/sections.h Introduce a basic initcall implementation Define CONFIG_SYS_LEGACY_BOARD everywhere Declare watchdog functions in watchdog.h Introduce generic pre-relocation board_f.c Introduce generic post-relocation board_r.c Add spl load feature arm: Remove use of board_early_init_r/last_stage_init() arm: Enable generic board support Add CONFIG_SYS_SYM_OFFSETS to support offset symbols Adjust board_f.c for ppc Adjust board_r.c for ppc ppc: Enable generic board support x86: Adjust board_f.c for x86 x86: Adjust board_r.c for x86 x86: Use sections header to obtain link symbols x86: Enable generic board support tegra: Enable generic board for Seaboard. README | 17 + arch/arm/cpu/arm1136/start.S | 2 +- arch/arm/cpu/arm1136/u-boot-spl.lds | 2 +- arch/arm/cpu/arm1176/start.S | 2 +- arch/arm/cpu/arm720t/start.S | 2 +- arch/arm/cpu/arm920t/ep93xx/u-boot.lds | 2 +- arch/arm/cpu/arm920t/start.S | 2 +- arch/arm/cpu/arm925t/start.S | 2 +- arch/arm/cpu/arm926ejs/davinci/spl.c | 2 +- arch/arm/cpu/arm926ejs/mxs/start.S | 2 +- arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds | 2 +- arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds | 2 +- arch/arm/cpu/arm926ejs/start.S | 4 +- arch/arm/cpu/arm946es/start.S | 2 +- arch/arm/cpu/arm_intcm/start.S | 2 +- arch/arm/cpu/armv7/omap-common/u-boot-spl.lds | 2 +- arch/arm/cpu/armv7/socfpga/u-boot-spl.lds | 2 +- arch/arm/cpu/armv7/start.S | 2 +- arch/arm/cpu/ixp/start.S | 2 +- arch/arm/cpu/ixp/u-boot.lds | 2 +- arch/arm/cpu/pxa/start.S | 2 +- arch/arm/cpu/s3c44b0/start.S | 2 +- arch/arm/cpu/sa1100/start.S | 2 +- arch/arm/cpu/u-boot.lds | 4 +- arch/arm/include/asm/sections.h | 27 + arch/arm/include/asm/spl.h | 2 +- arch/arm/include/asm/u-boot-arm.h | 4 - arch/arm/include/asm/u-boot.h | 9 + arch/arm/lib/Makefile | 3 + arch/arm/lib/board.c | 1 + arch/arm/lib/crt0.S | 4 +- arch/arm/lib/spl.c | 2 +- arch/avr32/config.mk | 3 + arch/avr32/cpu/start.S | 2 +- arch/avr32/cpu/u-boot.lds | 2 +- arch/avr32/include/asm/sections.h | 6 +- arch/avr32/lib/board.c | 4 +- arch/blackfin/config.mk | 3 + arch/blackfin/include/asm/sections.h | 27 + arch/m68k/config.mk | 3 + arch/m68k/include/asm/sections.h | 27 + arch/m68k/lib/board.c | 4 +- arch/microblaze/config.mk | 3 + arch/microblaze/include/asm/sections.h | 27 + arch/mips/config.mk | 3 + arch/mips/include/asm/sections.h | 27 + arch/nds32/config.mk | 3 + arch/nds32/cpu/n1213/start.S | 2 +- arch/nds32/cpu/n1213/u-boot.lds | 2 +- arch/nds32/include/asm/sections.h | 27 + arch/nds32/include/asm/u-boot-nds32.h | 8 +- arch/nds32/lib/board.c | 2 +- arch/nios2/config.mk | 3 + arch/nios2/cpu/start.S | 6 +- arch/nios2/cpu/u-boot.lds | 2 +- arch/nios2/include/asm/sections.h | 27 + arch/openrisc/include/asm/sections.h | 27 + arch/powerpc/cpu/74xx_7xx/start.S | 4 +- arch/powerpc/cpu/74xx_7xx/u-boot.lds | 2 +- arch/powerpc/cpu/mpc512x/start.S | 4 +- arch/powerpc/cpu/mpc512x/u-boot.lds | 2 +- arch/powerpc/cpu/mpc5xx/start.S | 4 +- arch/powerpc/cpu/mpc5xx/u-boot.lds | 2 +- arch/powerpc/cpu/mpc5xxx/spl_boot.c | 2 +- arch/powerpc/cpu/mpc5xxx/start.S | 4 +- arch/powerpc/cpu/mpc5xxx/u-boot-customlayout.lds | 2 +- arch/powerpc/cpu/mpc5xxx/u-boot-spl.lds | 2 +- arch/powerpc/cpu/mpc5xxx/u-boot.lds | 2 +- arch/powerpc/cpu/mpc8220/start.S | 4 +- arch/powerpc/cpu/mpc8220/u-boot.lds | 2 +- arch/powerpc/cpu/mpc824x/start.S | 4 +- arch/powerpc/cpu/mpc824x/u-boot.lds | 2 +- arch/powerpc/cpu/mpc8260/start.S | 4 +- arch/powerpc/cpu/mpc8260/u-boot.lds | 2 +- arch/powerpc/cpu/mpc83xx/start.S | 4 +- arch/powerpc/cpu/mpc83xx/u-boot-spl.lds | 4 +- arch/powerpc/cpu/mpc83xx/u-boot.lds | 2 +- arch/powerpc/cpu/mpc85xx/start.S | 4 +- arch/powerpc/cpu/mpc85xx/u-boot-nand.lds | 2 +- arch/powerpc/cpu/mpc85xx/u-boot-nand_spl.lds | 2 +- arch/powerpc/cpu/mpc85xx/u-boot-spl.lds | 2 +- arch/powerpc/cpu/mpc85xx/u-boot.lds | 2 +- arch/powerpc/cpu/mpc86xx/start.S | 4 +- arch/powerpc/cpu/mpc86xx/u-boot.lds | 2 +- arch/powerpc/cpu/mpc8xx/start.S | 4 +- arch/powerpc/cpu/ppc4xx/start.S | 4 +- arch/powerpc/cpu/ppc4xx/u-boot.lds | 2 +- arch/powerpc/include/asm/io.h | 8 + arch/powerpc/include/asm/sections.h | 27 + arch/powerpc/include/asm/spl.h | 2 +- arch/powerpc/include/asm/u-boot.h | 7 + arch/powerpc/lib/Makefile | 2 + arch/powerpc/lib/board.c | 18 +- arch/sandbox/config.mk | 3 + arch/sandbox/include/asm/sections.h | 2 + arch/sh/config.mk | 3 + arch/sh/cpu/sh2/u-boot.lds | 2 +- arch/sh/cpu/sh3/u-boot.lds | 2 +- arch/sh/cpu/sh4/u-boot.lds | 2 +- arch/sh/include/asm/sections.h | 27 + arch/sparc/config.mk | 3 + arch/sparc/include/asm/sections.h | 27 + arch/x86/cpu/coreboot/sdram.c | 1 + arch/x86/cpu/u-boot.lds | 4 +- arch/x86/include/asm/global_data.h | 1 - arch/x86/include/asm/sections.h | 27 + arch/x86/include/asm/u-boot-x86.h | 9 - arch/x86/include/asm/u-boot.h | 11 + arch/x86/lib/Makefile | 3 + arch/x86/lib/board.c | 3 +- arch/x86/lib/init_helpers.c | 3 +- arch/x86/lib/relocate.c | 9 +- board/BuS/eb_cpu5282/u-boot.lds | 2 +- board/LEOX/elpt860/u-boot.lds | 2 +- board/RPXClassic/u-boot.lds | 2 +- board/RPXlite/u-boot.lds | 2 +- board/RPXlite_dw/u-boot.lds | 2 +- board/RRvision/u-boot.lds | 2 +- board/actux1/u-boot.lds | 2 +- board/actux2/u-boot.lds | 2 +- board/actux3/u-boot.lds | 2 +- board/adder/u-boot.lds | 2 +- board/ait/cam_enc_4xx/u-boot-spl.lds | 2 +- board/altera/nios2-generic/u-boot.lds | 2 +- board/amcc/acadia/u-boot-nand.lds | 2 +- board/amcc/bamboo/u-boot-nand.lds | 2 +- board/amcc/canyonlands/u-boot-nand.lds | 2 +- board/amcc/kilauea/u-boot-nand.lds | 2 +- board/amcc/sequoia/u-boot-nand.lds | 2 +- board/amcc/sequoia/u-boot-ram.lds | 2 +- board/astro/mcf5373l/u-boot.lds | 2 +- board/cm4008/flash.c | 1 + board/cm41xx/flash.c | 1 + board/cobra5272/u-boot.lds | 2 +- board/cogent/u-boot.lds | 2 +- board/dave/PPChameleonEVB/u-boot.lds | 2 +- board/davinci/da8xxevm/u-boot-spl-da850evm.lds | 2 +- board/davinci/da8xxevm/u-boot-spl-hawk.lds | 2 +- board/dvlhost/u-boot.lds | 2 +- board/eltec/mhpc/u-boot.lds | 2 +- board/emk/top860/u-boot.lds | 2 +- board/ep88x/u-boot.lds | 2 +- board/esd/dasa_sim/u-boot.lds | 2 +- board/esd/pmc440/u-boot-nand.lds | 2 +- board/esd/tasreg/u-boot.lds | 2 +- board/esteem192e/u-boot.lds | 2 +- board/evb64260/u-boot.lds | 2 +- board/fads/u-boot.lds | 2 +- board/flagadm/u-boot.lds | 2 +- board/freescale/m5208evbe/u-boot.lds | 2 +- board/freescale/m52277evb/u-boot.lds | 2 +- board/freescale/m5235evb/u-boot.lds | 2 +- board/freescale/m5249evb/u-boot.lds | 2 +- board/freescale/m5253demo/u-boot.lds | 2 +- board/freescale/m5253evbe/u-boot.lds | 2 +- board/freescale/m5271evb/u-boot.lds | 2 +- board/freescale/m5272c3/u-boot.lds | 2 +- board/freescale/m5275evb/u-boot.lds | 2 +- board/freescale/m5282evb/u-boot.lds | 2 +- board/freescale/m53017evb/u-boot.lds | 2 +- board/freescale/m5329evb/u-boot.lds | 2 +- board/freescale/m5373evb/u-boot.lds | 2 +- board/freescale/m54418twr/u-boot.lds | 2 +- board/freescale/m54451evb/u-boot.lds | 2 +- board/freescale/m54455evb/u-boot.lds | 2 +- board/freescale/m547xevb/u-boot.lds | 2 +- board/freescale/m548xevb/u-boot.lds | 2 +- board/freescale/mx31ads/u-boot.lds | 2 +- board/gaisler/gr_cpci_ax2000/u-boot.lds | 2 +- board/gaisler/gr_ep2s60/u-boot.lds | 2 +- board/gaisler/gr_xc3s_1500/u-boot.lds | 2 +- board/gaisler/grsim/u-boot.lds | 2 +- board/gaisler/grsim_leon2/u-boot.lds | 2 +- board/gen860t/u-boot-flashenv.lds | 2 +- board/gen860t/u-boot.lds | 2 +- board/genietv/u-boot.lds | 2 +- board/hermes/u-boot.lds | 2 +- board/hymod/u-boot.lds | 2 +- board/icu862/u-boot.lds | 2 +- board/idmr/u-boot.lds | 2 +- board/ip860/u-boot.lds | 2 +- board/ivm/u-boot.lds | 2 +- board/korat/u-boot-F7FC.lds | 2 +- board/kup/kup4k/u-boot.lds | 2 +- board/kup/kup4x/u-boot.lds | 2 +- board/lwmon/u-boot.lds | 2 +- board/manroland/uc100/u-boot.lds | 2 +- board/matrix_vision/mvsmr/u-boot.lds | 2 +- board/mbx8xx/u-boot.lds | 2 +- board/mousse/u-boot.lds | 2 +- board/mvblue/u-boot.lds | 2 +- board/netphone/u-boot.lds | 2 +- board/netta/u-boot.lds | 2 +- board/netta2/u-boot.lds | 2 +- board/netvia/u-boot.lds | 2 +- board/nx823/u-boot.lds | 2 +- board/quantum/u-boot.lds | 2 +- board/r360mpi/u-boot.lds | 2 +- board/rbc823/u-boot.lds | 2 +- board/renesas/sh7752evb/u-boot.lds | 2 +- board/renesas/sh7757lcr/u-boot.lds | 2 +- board/rsdproto/u-boot.lds | 2 +- board/samsung/smdk5250/smdk5250-uboot-spl.lds | 2 +- board/samsung/smdk6400/u-boot-nand.lds | 2 +- board/sandpoint/u-boot.lds | 2 +- board/sixnet/u-boot.lds | 2 +- board/snmc/qs850/u-boot.lds | 2 +- board/snmc/qs860t/u-boot.lds | 2 +- board/spc1920/u-boot.lds | 2 +- board/spd8xx/u-boot.lds | 2 +- board/stx/stxxtc/u-boot.lds | 2 +- board/svm_sc8xx/u-boot.lds | 2 +- board/tqc/tqm8xx/u-boot.lds | 2 +- board/v37/u-boot.lds | 2 +- board/vpac270/u-boot-spl.lds | 2 +- board/woodburn/woodburn.c | 2 +- common/Makefile | 4 + common/board_f.c | 1021 ++++++++++++++++++++++ common/board_r.c | 916 +++++++++++++++++++ config.mk | 8 + examples/standalone/stubs.c | 7 +- include/asm-generic/global_data.h | 2 + include/asm-generic/sections.h | 119 +++ include/asm-generic/u-boot.h | 159 ++++ include/common.h | 2 + include/configs/km/keymile-common.h | 4 - include/configs/km/km-powerpc.h | 4 + include/configs/seaboard.h | 2 + include/ide.h | 7 + include/initcall.h | 25 + include/watchdog.h | 18 + lib/Makefile | 1 + lib/initcall.c | 39 + nand_spl/board/amcc/acadia/u-boot.lds | 2 +- nand_spl/board/amcc/bamboo/u-boot.lds | 2 +- nand_spl/board/amcc/canyonlands/u-boot.lds | 2 +- nand_spl/board/amcc/kilauea/u-boot.lds | 2 +- nand_spl/board/amcc/sequoia/u-boot.lds | 2 +- nand_spl/board/freescale/mpc8315erdb/u-boot.lds | 4 +- nand_spl/board/freescale/mx31pdk/u-boot.lds | 2 +- nand_spl/board/karo/tx25/u-boot.lds | 2 +- nand_spl/board/samsung/smdk6400/u-boot.lds | 2 +- nand_spl/board/sheldon/simpc8313/u-boot.lds | 4 +- 243 files changed, 2976 insertions(+), 253 deletions(-) create mode 100644 arch/arm/include/asm/sections.h create mode 100644 arch/blackfin/include/asm/sections.h create mode 100644 arch/m68k/include/asm/sections.h create mode 100644 arch/microblaze/include/asm/sections.h create mode 100644 arch/mips/include/asm/sections.h create mode 100644 arch/nds32/include/asm/sections.h create mode 100644 arch/nios2/include/asm/sections.h create mode 100644 arch/openrisc/include/asm/sections.h create mode 100644 arch/powerpc/include/asm/sections.h create mode 100644 arch/sh/include/asm/sections.h create mode 100644 arch/sparc/include/asm/sections.h create mode 100644 arch/x86/include/asm/sections.h create mode 100644 common/board_f.c create mode 100644 common/board_r.c create mode 100644 include/asm-generic/sections.h create mode 100644 include/asm-generic/u-boot.h create mode 100644 include/initcall.h create mode 100644 lib/initcall.c -- 1.8.1

6 49

[U-Boot] FDT howto
by Jagan Teki 02 Mar '13

02 Mar '13

Hi All, I am planning to use devicetree on u-boot. I have an experience to work with devicetree on Linux. For u-boot, I have read doc from doc/README.fdt-control. I see some dts usages on tegra boards. I have lot of confusions with the concept itself. Is Linux and u-boot devicetree concept and build system are same? Suppose I have 4 boards J1, J2, J3 & J4 on my soc "emb".of vendor "vast" For this requirement I have board/vast/dts/J1.dts board/vast/dts/J2.dts board/vast/dts/J3.dts board/vast/dts/J4.dts include/configs/emb_common.h ==> single configuration of all SOC needed definitions like defconfig in Linux. do I need any more files? In emb_common.h i am defining CONFIG_OF_SEPARATE is it sufficient? My plan is to build u-boot and then build the dtb with specific board and then combine. I saw that all tegra boards config files are defining CONFIG_DEFAULT_DEVICE_TREE if ie. the case dts is a compile time option right. am i correct? Please let me know your inputs. -- Thanks, Jagan.

2 21

[U-Boot] [PATCH v3] btrfs addition to uboot
by Adnan Ali 02 Mar '13

02 Mar '13

Adnan Ali (1): Introduced btrfs file-system with btrload command Makefile | 1 + common/Makefile | 1 + common/cmd_btr.c | 53 +++ fs/btrfs/Makefile | 51 ++ fs/btrfs/btrfs.c | 1131 ++++++++++++++++++++++++++++++++++++++++++++ fs/fs.c | 86 +++- include/btrfs.h | 398 ++++++++++++++++ include/config_fallbacks.h | 4 + include/crc32c.h | 48 ++ include/fs.h | 1 + 10 files changed, 1769 insertions(+), 5 deletions(-) create mode 100644 common/cmd_btr.c create mode 100644 fs/btrfs/Makefile create mode 100644 fs/btrfs/btrfs.c create mode 100644 include/btrfs.h create mode 100644 include/crc32c.h -- 1.7.9.5

4 14

[U-Boot] [PATCH v6 1/3] Add README for the "Falcon" mode
by Stefano Babic 01 Mar '13

01 Mar '13

Simple howto to add support to a board for booting the kernel from SPL ("Falcon" mode). Signed-off-by: Stefano Babic <sbabic(a)denx.de> --- Changes in v6: - rephrasing some parts to make clearer (Otavio Salvador, Andreas Biessmann) - including example with FDT from a3m071 (Stefan Roese) - making clear that using "spl export" with FDT is untested PPC port uses the fdt command to prepare the blob (Andreas Biessmann) Changes in v5: - several fixes for the language, rephrasing some unclear parts (Vikram Narayanan) Changes in v4: - fix capitalization, styling, in spl help (Andreas Biessmann) - move CONFIG_SPL_OS_BOOT before function in doc (Andreas Biessmann) Changes in v3: - parameter initrd_addr was removed in V2 (Andreas Biessmann) - added patch to fix help usage for spl export (Andreas Biessmann) - Added empty lines (Otavio Salvador) - add a more exhaustive description explaining that spl export does not save into media (Lukasz Majewski). Changes in v2: - spelling, language fixes (Andreas Biessman) - rewrite some unclear sentences - drop CONFIG_SPL_OS_BOOT_KEY - make example with twister more exhaustive doc/README.falcon | 209 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 209 insertions(+) create mode 100644 doc/README.falcon diff --git a/doc/README.falcon b/doc/README.falcon new file mode 100644 index 0000000..93e855d --- /dev/null +++ b/doc/README.falcon @@ -0,0 +1,209 @@ +U-Boot Falcon Mode +==================== + +Introduction +------------ + +This document provides an overview of how to add support for Falcon Mode +to a board. + +Falcon Mode is introduced to speed up the booting process, allowing +to boot a Linux kernel (or whatever image) without a full blown U-Boot. + +Falcon Mode relies on the SPL framework. In fact, to make booting faster, +U-Boot is split into two parts: the SPL (Secondary Program Loader) and U-Boot +image. In most implementations, SPL is used to start U-Boot when booting from +a mass storage, such as NAND or SD-Card. SPL has now support for other media, +and can generally be seen as a way to start an image performing the minimum +required initialization. SPL mainly initializes the RAM controller, and then +copies U-Boot image into the memory. + +The Falcon Mode extends this way allowing to start the Linux kernel directly +from SPL. A new command is added to U-Boot to prepare the parameters that SPL +must pass to the kernel, using ATAGS or Device Tree. + +In normal mode, these parameters are generated each time before +loading the kernel, passing to Linux the address in memory where +the parameters can be read. +With Falcon Mode, this snapshot can be saved into persistent storage and SPL is +informed to load it before running the kernel. + +To boot the kernel, these steps under a Falcon-aware U-Boot are required: + +1. Boot the board into U-Boot. +Use the "spl export" command to generate the kernel parameters area or the DT. +U-Boot runs as when it boots the kernel, but stops before passing the control +to the kernel. + +2. Save the prepared snapshot into persistent media. +The address where to save it must be configured into board configuration +file (CONFIG_CMD_SPL_NAND_OFS for NAND). + +3. Boot the board into Falcon Mode. SPL will load the kernel and copy +the parameters which are saved in the persistent area to the required address. + +It is required to implement a custom mechanism to select if SPL loads U-Boot +or another image. + +The value of a GPIO is a simple way to operate the selection, as well as +reading a character from the SPL console if CONFIG_SPL_CONSOLE is set. + +Falcon Mode is generally activated by setting CONFIG_SPL_OS_BOOT. This tells +SPL that U-Boot is not the only available image that SPL is able to start. + +Configuration +---------------------------- +CONFIG_CMD_SPL Enable the "spl export" command. + The command "spl export" is then available in U-Boot + mode +CONFIG_SYS_SPL_ARGS_ADDR Address in RAM where the parameters must be + copied by SPL. + In most cases, it is <start_of_ram> + 0x100 + +CONFIG_SYS_NAND_SPL_KERNEL_OFFS Offset in NAND where the kernel is stored + +CONFIG_CMD_SPL_NAND_OFS Offset in NAND where the parameters area was saved. + +CONFIG_CMD_SPL_WRITE_SIZE Size of the parameters area to be copied + +CONFIG_SPL_OS_BOOT Activate Falcon Mode. + +Function that a board must implement +------------------------------------ + +void spl_board_prepare_for_linux(void) : optional + Called from SPL before starting the kernel + +spl_start_uboot() : required + Returns "0" if SPL should start the kernel, "1" if U-Boot + must be started. + + +Using spl command +----------------- + +spl - SPL configuration + +Usage: + +spl export <img=atags|fdt> [kernel_addr] [initrd_addr] [fdt_addr ] + +img : "atags" or "fdt" +kernel_addr : kernel is loaded as part of the boot process, but it is not started. + This is the address where a kernel image is stored. +initrd_addr : Address of initial ramdisk + can be set to "-" if fdt_addr without initrd_addr is used +fdt_addr : in case of fdt, the address of the device tree. + +The spl export command does not write to a storage media. The user is +responsible to transfer the gathered information (assembled ATAGS list +or prepared FDT) from temporary storage in RAM into persistant storage +after each run of 'spl export'. Unfortunately the position of temporary +storage can not be predicted nor provided at commandline, it depends +highly on your system setup and your provided data (ATAGS or FDT). +However at the end of an succesful 'spl export' run it will print the +RAM address of temporary storage. +Now the user have to save the generated BLOB from that printed address +to the pre-defined address in persistent storage +(CONFIG_CMD_SPL_NAND_OFS in case of NAND). +The following example shows how to prepare the data for Falcon Mode on +twister board with ATAGS BLOB. + +The "spl export" command is prepared to work with ATAGS and FDT. However, +using FDT is at the moment untested. The ppc port (see a3m071 example +later) prepares the fdt blob with the fdt command instead. + + +Usage on the twister board: +-------------------------------- + +Using mtd names with the following (default) configuration +for mtdparts: + +device nand0 <omap2-nand.0>, # parts = 9 + #: name size offset mask_flags + 0: MLO 0x00080000 0x00000000 0 + 1: u-boot 0x00100000 0x00080000 0 + 2: env1 0x00040000 0x00180000 0 + 3: env2 0x00040000 0x001c0000 0 + 4: kernel 0x00600000 0x00200000 0 + 5: bootparms 0x00040000 0x00800000 0 + 6: splashimg 0x00200000 0x00840000 0 + 7: mini 0x02800000 0x00a40000 0 + 8: rootfs 0x1cdc0000 0x03240000 0 + + +twister => nand read 82000000 kernel + +NAND read: device 0 offset 0x200000, size 0x600000 + 6291456 bytes read: OK + +Now the kernel is in RAM at address 0x82000000 + +twister => spl export atags 0x82000000 +## Booting kernel from Legacy Image at 82000000 ... + Image Name: Linux-3.5.0-rc4-14089-gda0b7f4 + Image Type: ARM Linux Kernel Image (uncompressed) + Data Size: 3654808 Bytes = 3.5 MiB + Load Address: 80008000 + Entry Point: 80008000 + Verifying Checksum ... OK + Loading Kernel Image ... OK +OK +cmdline subcommand not supported +bdt subcommand not supported +Argument image is now in RAM at: 0x80000100 + +The result can be checked at address 0x80000100: + +twister => md 0x80000100 +80000100: 00000005 54410001 00000000 00000000 ......AT........ +80000110: 00000000 00000067 54410009 746f6f72 ....g.....ATroot +80000120: 65642f3d 666e2f76 77722073 73666e20 =/dev/nfs rw nfs + +The parameters generated with this step can be saved into NAND at the offset +0x800000 (value for twister for CONFIG_CMD_SPL_NAND_OFS) + +nand erase.part bootparms +nand write 0x80000100 bootparms 0x4000 + +Now the parameters are stored into the NAND flash at the address +CONFIG_CMD_SPL_NAND_OFS (=0x800000). + +Next time, the board can be started into Falcon Mode moving the +setting the gpio (on twister gpio 55 is used) to kernel mode. + +The kernel is loaded directly by the SPL without passing through U-Boot. + +Example with FDT: a3m071 board +------------------------------- + +To boot the Linux kernel from the SPL, the DT blob (fdt) needs to get +prepard/patched first. U-Boot usually inserts some dynamic values into +the DT binary (blob), e.g. autodetected memory size, MAC addresses, +clocks speeds etc. To generate this patched DT blob, you can use +the following command: + +1. Load fdt blob to SDRAM: +=> tftp 1800000 a3m071/a3m071.dtb + +2. Set bootargs as desired for Linux booting (e.g. flash_mtd): +=> run mtdargs addip2 addtty + +3. Use "fdt" commands to patch the DT blob: +=> fdt addr 1800000 +=> fdt boardsetup +=> fdt chosen + +4. Display patched DT blob (optional): +=> fdt print + +5. Save fdt to NOR flash: +=> erase fc060000 fc07ffff +=> cp.b 1800000 fc060000 10000 +... + + +Falcon Mode was presented at the RMLL 2012. Slides are available at: + +http://schedule2012.rmll.info/IMG/pdf/LSM2012_UbootFalconMode_Babic.pdf -- 1.7.9.5

2 6