mirror of
https://github.com/AsahiLinux/u-boot
synced 2024-11-05 12:45:42 +00:00
00caae6d47
We are now using an env_ prefix for environment functions. Rename these two functions for consistency. Also add function comments in common.h. Quite a few places use getenv() in a condition context, provoking a warning from checkpatch. These are fixed up in this patch also. Suggested-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Simon Glass <sjg@chromium.org> |
||
---|---|---|
.. | ||
ipam390-ais-uart.cfg | ||
ipam390.c | ||
Kconfig | ||
MAINTAINERS | ||
Makefile | ||
README.ipam390 | ||
u-boot-spl-ipam390.lds |
Summary ======= The README is for the boot procedure on the ipam390 board In the context of U-Boot, the board is booted in three stages. The initial bootloader which executes upon reset is the ROM Boot Loader (RBL) and sits in the internal ROM. The RBL initializes the internal memory and then depending on the exact board and pin configurations will initialize another controller (such as NAND) to continue the boot process by loading the secondary program loader (SPL). The SPL will initialize the system further (some clocks, SDRAM). As on this board is used the falcon boot mode, now 2 ways are possible depending on the GPIO 7_14 input pin, connected with the "soft reset switch" If this pin is logical 1 (high level): spl code starts the kernel image without delay If this pin is logical 0 (low level): spl code starts the u-boot image AIS is an image format defined by TI for the images that are to be loaded to memory by the RBL. The image is divided into a series of sections and the image's entry point is specified. Each section comes with meta data like the target address the section is to be copied to and the size of the section, which is used by the RBL to load the image. At the end of the image the RBL jumps to the image entry point. The AIS format allows for other things such as programming the clocks and SDRAM if the header is programmed for it. We do not take advantage of this and instead use SPL as it allows for additional flexibility (run-time detect of board revision, loading the next image from a different media, etc). Compilation =========== run "tools/buildman/buildman -k ipam390" in the u-boot source tree. Once this build completes you will have a ../current/ipam390/u-boot.ais file that needs to be written to the nand flash. Flashing the images to NAND ========================== The AIS image can be written to NAND flash using the following commands. Assuming that the network is configured and enabled and the u-boot.ais file is tftp'able. U-Boot > print upd_uboot upd_uboot=tftp c0000000 ${u-boot};nand erase.part u-boot;nand write c0000000 20000 ${filesize} U-Boot > U-Boot > run upd_uboot Using DaVinci-EMAC device TFTP from server 192.168.1.1; our IP address is 192.168.20.71 Filename '/tftpboot/ipam390/u-boot.ais'. Load address: 0xc0000000 Loading: ################################## 1.5 MiB/s done Bytes transferred = 493716 (78894 hex) NAND erase.part: device 0 offset 0x20000, size 0x160000 Erasing at 0x160000 -- 100% complete. OK NAND write: device 0 offset 0x20000, size 0x78894 493716 bytes written: OK U-Boot > Recovery ======== In the case of a "bricked" board, you need to use the TI tools found here[1] to create an uboot-uart-ais.bin file - cd to the u-boot source tree - compile the u-boot for the ipam390 board: $ tools/buildman/buildman -k ipam390 -> Now we shall have u-boot.bin - Create u-boot-uart-ais.bin $ mono HexAIS_OMAP-L138.exe -entrypoint 0xC1080000 -ini ipam390-ais-uart.cfg \ -o ../current/ipam390/uboot-uart-ais.bin ./u-boot.bin@0xC1080000; Note: The ipam390-ais-uart.cfg is found in the board directory for the ipam390 board, u-boot:/board/Barix/ipam390/ipam390-ais-uart.cfg - We can now run bootloader on IPAM390 via UART using the command below: $ mono ./slh_OMAP-L138.exe -waitForDevice -v -p /dev/tty.UC-232AC uboot-uart-ais.bin NOTE: Do not cancel the command execution! The command takes 20+ seconds to upload u-boot over serial and run it! Outcome: Waiting for the OMAP-L138... (AIS Parse): Read magic word 0x41504954. (AIS Parse): Waiting for BOOTME... (power on or reset target now) (AIS Parse): BOOTME received! (AIS Parse): Performing Start-Word Sync... (AIS Parse): Performing Ping Opcode Sync... (AIS Parse): Processing command 0: 0x5853590D. (AIS Parse): Performing Opcode Sync... (AIS Parse): Executing function... (AIS Parse): Processing command 1: 0x5853590D. (AIS Parse): Performing Opcode Sync... (AIS Parse): Executing function... (AIS Parse): Processing command 2: 0x5853590D. (AIS Parse): Performing Opcode Sync... (AIS Parse): Executing function... (AIS Parse): Processing command 3: 0x5853590D. (AIS Parse): Performing Opcode Sync... (AIS Parse): Executing function... (AIS Parse): Processing command 4: 0x5853590D. (AIS Parse): Performing Opcode Sync... (AIS Parse): Executing function... (AIS Parse): Processing command 5: 0x58535901. (AIS Parse): Performing Opcode Sync... (AIS Parse): Loading section... (AIS Parse): Loaded 326516-Byte section to address 0xC1080000. (AIS Parse): Processing command 6: 0x58535906. (AIS Parse): Performing Opcode Sync... (AIS Parse): Performing jump and close... (AIS Parse): AIS complete. Jump to address 0xC1080000. (AIS Parse): Waiting for DONE... (AIS Parse): Boot completed successfully. Operation completed successfully. Falcon Bootmode (boot linux without booting U-Boot) =================================================== 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. Here the command sequence for the ipam390 board: - load the linux kernel image into ram: U-Boot > nand read c0100000 2 200000 400000 NAND read: device 0 offset 0x200000, size 0x400000 4194304 bytes read: OK - generate the bootparms image: U-Boot > spl export atags c0100000 ## Booting kernel from Legacy Image at c0100000 ... Image Name: Linux-3.5.1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2504280 Bytes = 2.4 MiB Load Address: c0008000 Entry Point: c0008000 Verifying Checksum ... OK Loading Kernel Image ... OK subcommand not supported subcommand not supported Argument image is now in RAM at: 0xc0000100 - copy the bootparms image into nand: U-Boot > mtdparts device nand0 <davinci_nand.0>, # parts = 6 #: name size offset mask_flags 0: u-boot-env 0x00020000 0x00000000 0 1: u-boot 0x00160000 0x00020000 0 2: bootparms 0x00020000 0x00180000 0 3: factory-info 0x00060000 0x001a0000 0 4: kernel 0x00400000 0x00200000 0 5: rootfs 0x07a00000 0x00600000 0 active partition: nand0,0 - (u-boot-env) 0x00020000 @ 0x00000000 defaults: mtdids : nand0=davinci_nand.0 mtdparts: mtdparts=davinci_nand.0:128k(u-boot-env),1408k(u-boot),128k(bootparms),384k(factory-info),4M(kernel),-(rootfs) U-Boot > nand erase.part bootparms NAND erase.part: device 0 offset 0x180000, size 0x20000 Erasing at 0x180000 -- 100% complete. OK U-Boot > nand write c0000100 180000 20000 NAND write: device 0 offset 0x180000, size 0x20000 131072 bytes written: OK U-Boot > You can use also the predefined U-Boot Environment variable "setbootparms", which will do all the above steps in one command: U-Boot > print setbootparms setbootparms=nand read c0100000 200000 400000;spl export atags c0100000;nand erase.part bootparms;nand write c0000100 180000 20000 U-Boot > run setbootparms NAND read: device 0 offset 0x200000, size 0x400000 4194304 bytes read: OK ## Booting kernel from Legacy Image at c0100000 ... Image Name: Linux-3.5.1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2504280 Bytes = 2.4 MiB Load Address: c0008000 Entry Point: c0008000 Verifying Checksum ... OK Loading Kernel Image ... OK subcommand not supported subcommand not supported Argument image is now in RAM at: 0xc0000100 NAND erase.part: device 0 offset 0x180000, size 0x20000 Erasing at 0x180000 -- 100% complete. OK NAND write: device 0 offset 0x180000, size 0x20000 131072 bytes written: OK U-Boot > Links ===== [1] http://sourceforge.net/projects/dvflashutils/files/OMAP-L138/