upstream u-boot with additional patches for our devices/boards:
https://lists.denx.de/pipermail/u-boot/2017-March/282789.html (AXP crashes) ;
Gbit ethernet patch for some LIME2 revisions ;
with SPI flash support
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Simon Glass
6de80f2196
|
8 years ago | |
---|---|---|
.. | ||
Kconfig | ||
MAINTAINERS | ||
Makefile | ||
README.ipam390 | 8 years ago | |
ipam390-ais-uart.cfg | ||
ipam390.c | ||
u-boot-spl-ipam390.lds |
README.ipam390
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/