|
© 2002, 2003, 2004 Cadenux, LLC, Inc. Derived from the RidgeRun rrload bootloader manual © 2001 RidgeRun. This manual is part of the rrload GPL software.
ARM is a registered trademark of ARM Limited. Linux is a registered trademark of Linus Torvalds in the United States and other countries and is used by Cadenux under license. Motorola is a registered trademark of Motorola, Inc. Texas Instruments, Code Composer Studio, and TI are registered trademarks of Texas Instruments Incorporated. All other trademarks are the property of their respective owners.
6 Building and Upgrading the Bootloader
The rrload Embedded Bootloader, developed by RidgeRun, Incorporated, is part of the Cadenux BSP. The Bootloader is tailored specifically toward allowing users to manage the loading, storing, and invoking of a Linux kernel and root file system.
In normal operation, the bootloader resides in flash at the reset vector. It is the first program run on power up and, unless intercepted, rrload will typically transfer control to the stored Linux kernel and file system. Additionally, the bootloader will relocate either the kernel and/or the file system to SDRAM, if necessary, prior to transferring control. This behavior happens automatically in response to the user having previously configured rrload with "boot_auto" (the default boot command). This is the typical command stored along with the user's other persistent bootloader settings, which among other things can include additional command line arguments that the user wants passed to the kernel.
If the bootloader is not configured with a default boot command, or if the boot process is intercepted, rrload will simply present its user interface and wait for user input. The bootloader offers both a menu user interface (UI) and a command line UI between which the user may easily toggle. Available through the UI is the ability to download a new kernel and/or file system to either RAM or Flash.
The bootloader supports a variety of download formats and can accept these formats over a variety of board I/O ports such as serial, parallel, and ethernet. The user interface communicates over the board's serial line with a host terminal session such as minicom on Linux, or Procomm on Windows. Do not use HyperTerm since it does not support a 8 bit binary transfer mode. Using HyperTerm will cause the images being downloaded to be corrupted.. Holding the ENTER key down within the host terminal session while simultaneously applying power to the board, will insure that any previously stored default boot command is temporarily intercepted and forces the bootloader to present its UI. This allows user interaction.
When operating in menu mode, rrload displays the following choices:
+-------------------------------------+ | Welcome to the | | rrload bootloader | | | | Version: v5.26 z | | Datecode: 030814a | | Platform: DM270 | | ARM clock: 87750 kHz | +-------------------------------------+ MAIN MENU --------- 1. Load [comp] from I/O port... 2. Store RAM [comp] to Flash... 3. View/Edit Params... 4. Boot Kernel/filesystem (boot_auto) 5. CmdLine Mode 6. Dump memory 7. Print memory map 8. Print network chip memory map f. Print flash chip information m. Modify memory v. Verify SDRAM image r. Run Default Boot Cmd E. Erase [comp] from Flash... Which?Some of the options, choices '6', '7', '8', 'f', 'm', and 'v' are intended as debugging aids and are not normally included in rrload. These features are described in rrload Debugging Aids. The other commonly used features are described below.
This section assumes rrload is already stored in flash on your target hardware. If this is not the case, refer to Installing rrload into a New Flash Chip.
| Target Hardware | Recommended RS-232 Cable |
| TI/Spectrum Digital C5471 EVM |
Male to female, 9-pin, straight through |
| TI DM320/DM342 EVM |
Female to female, 9-pin, "crossover" null modem |
| AmRoad DM310 EVM |
Male to female, 9-pin, straight through |
| TI DM310 EVM |
Male to female, 9-pin, straight through |
| TI DM270 EVM |
Female to female, 9-pin, "crossover" null modem |
| TI DSC25 EVM |
Female to female, 9-pin, straight through |
| AmRoad DSC25 EVM |
Male to female, 9-pin, straight through |
| AmRoad DSC21 EVM |
Male to female, 9-pin, straight through |
| Setting | Value |
| Baud Rate | 115200 |
| Data Bits | 8 |
| Parity | None |
| Stop Bits | 1 |
| Hardware Flow Control | None |
| Software Flow Control | None |
| Target Hardware | Jumper |
| TI/Spectrum Digital C5471 EVM |
|
| TI DM320/DM342 EVM | To be provided. |
| TI DM270 EVM |
|
| TI DSC25 EVM |
|
| AmRoad DSC25 EVM |
|
| AmRoad DSC21 EVM |
|
As the board powers up you should see the rrload UI appear in the host terminal session. The bootloader now has control of your target and is waiting for user input.
Option 3 in the rrload main menu shows a list of current user settings, as shown below.
View/Edit Params
----------------
0. --to MAIN--
1. ui mode [cmd|menu] : menu
2. default boot cmd :
3. I/O load format : rrbin
4. I/O load port : ether
5. console port : serial
Linux Settings
6. Kernel cmdline :
7. Device MAC : 00:e0:81:10:36:df
rrload TFTP Settings
8. Server IP (tftp) : 10.0.0.3
9. Server MAC (tftp) : 00:07:95:D0:56:03
a. Device IP (tftp) : 10.0.0.20
b. Kernel Path (tftp) : linux.rr
c. FileSys Path (tftp) : romdisk.img.rr
Edit Which?
You can view these same settings from the command line mode by issuing the "set" command, also show below.
rrload> set
set
mode : menu
bootcmd :
loadfmt : rrbin
loadport : ether
consoleport : serial
serverip : 10.0.0.3
servermac : 00:07:95:D0:56:03
devip : 10.0.0.20
devmac : 00:e0:81:10:36:df
kpath : linux.rr
fpath : romdisk.img.rr
kcmdline :
rrload>
If you make changes to these settings, it only affects the current session (RAM- based settings). If you want the new settings to survive power cycles, you need to store them in flash by first performing an erase of the params section of flash (the RAM copy is unaltered), followed by a flash store of the new params causing the current RAM settings to be copied to flash. You can perform this from menu mode or command line mode.
Below is an example showing the setting (storing) of a new bootcmd parameter, the default boot command. In this case, as an alternative to using the menu mode UI, we are using the bootloader's command line UI to assign the bootcmd parameter. Here we assign an empty string since no value string was supplied on the first line.
rrload> set bootcmd rrload> eraseflash params rrload> copy -c params -s ram -d flash -f n
Below are the settings that rrload allows the user to customize and store persistently. The default network values used by rrload can be modified using the Cadenux ARM BSPConfiguration Tool.
| Parameter Name | Valid Values | Description |
| mode | cmd, menu | Default UI mode . This allows the user to establish which UI (menu or command line) the bootloader will present by default. |
| bootcmd | Any list of valid bootloader commands | Default boot command. Use ";" to separate your commands. For example you might want to use this to have the bootloader automatically perform:
copy -c k -s f -d r -f n; copy -c f -s f -d r -f n; bootAlthough it should be noted that this particular example could be accomplished even more easily with a single boot_auto command. |
| loadfmt | srec, rrbin | I/O load format |
| loadport | ser, ether | I/O load port. When the load port is set to ether then the network related parameters pertaining to TFTP are enabled. Otherwise they are ignored. |
| consoleport | serial | The port used by the bootloader to interact with the user. Currently only the serial port is supported. |
| serverip | Any IP address in the form XXX.XXX.XXX.XXX | The IP address of the remote server that delivers the TFTP based image. |
| servermac | Any mac address in the form XX:XX:XX:XX:XX:XX | The MAC address of the remote server that delivers the TFTP based image. |
| devip | Any IP address in the form XXX.XXX.XXX.XXX | The IP address to be used by the target hardware. Once the Linux kernel boots, it can override this value. |
| devmac | Any mac address in the form XX:XX:XX:XX:XX:XX | The MAC address to be used by the target hardware. Once the Linux kernel boots, it can override this value. |
| kpath | Any directory/filename | The path name of the kernel file that is to be transferred to the target hardware from the server over the network using TFTP. |
| fpath | Any directory/filename | The path name of the file containing the target hardware file system that is to be transferred to the target hardware from the server over the network using TFTP. |
| kcmdline | Any valid Linux kernel command line parameters | Command line string passed to the kernel as it is being invoked by the bootloader. |
Note: As mentioned earlier, the user can change any of these SDRAM based values, however, the new values will remain in effect ONLY during the current session. If the user wants the new settings to survive power cycles then the user must take steps to erase the params section of flash and store the new value to flash. On boot-up, the bootloader will always insure that the SDRAM based params are initialized to the set stored in flash.
One of the main reasons the bootloader exists is to give the user a means to load images onto the target hardware. Specifically, we are interested in loading a kernel and possibly a file system. Without the bootloader the user is restricted to JTAG based downloads which can be an attractive option. However, not all users have the supporting tools necessary to facilitate JTAG based development. The rrload bootloader gives the user an immediate path to loading and running software components on the board. Additionally, the bootloader allows the user to store the components to flash if desired.
The bootloader supports a variety of download image formats, which can be streamed through the various I/O ports of the EVM. The architecture supports the ease of adding more modules to support additional image formats or I/O ports as necessary. Currently the two image formats and three I/O ports below are supported.
| I/O Load Ports | Image Formats |
|
|
The srec format is a Motorola inspired binary standard format. This ASCII format is used for downloading executable files, not data files. An srec file is typically created prior to download using the following command where myprog is a standard executable file format such as ELF or a.out:
$ arm-uclinux-objcopy -S -O srec myprog myprog.srec
or
$ arm-linux-objcopy -S -O srec myprog myprog.srec
depending upon if you are using the ARM7 uClinux or the ARM9 Linux toolchain.
A RidgeRun inspired format, rrbin is a tagged image binary format used for downloading either executable files or data files such as file systems. This format is very efficient and can be generated using the mkimage utility.
Note: The --LAddr used below is just an example, the actual value you use is dependent on the address where you need load your specific object (which is set using the make xconfig Linux kernel configuration program). For example, in the case of a kernel, you could use a command such as arm-linux-objdump -h linux to find out where the image expects to load. In the case of a file system the --LAddr value should match the address where your kernel expects to find the file system during a kernel boot. Use mkimage to prepare both kernel and file system images for download.
$ mkimage --LAddr 08e00000 linux linux.rror
$ mkimage --LAddr 08c00000 romdisk.img romdisk.img.rr
The resulting *.rr file is a space efficient binary format with an additional header tacked on the front to allow the rrload bootloader to accept the file with a minimum of coupling between the rrload source code and the software components downloaded to it. This special header is what makes it a tagged image format. It contains the following pieces of information used by rrload to process the enclosed pure binary data.Using the head command, you can see the tags by looking at the first three lines.
$ head -3 linux.rr >LoadAddr:0x08e00000 >EntryAddr:0x08e00130 >NumBytes:0x0000a200
Note: In the example above, the LoadAddr was determined by the user options supplied (--LAddr), while the EntryAddr and NumBytes are computed by the mkimage script. In cases where the input image does not represent an executable, but rather represents a file system, then the EntryAddr will not apply and mkimage will simply supply a default filler value. For those that are curious, there is additional usage information contained within the document header of the mkimage script.
When faced with the choice of creating an srec image or rrbin image, rrload users generally opt for the rrbin format for both the kernel and file system components. Once the images are created, they can be downloaded to the target hardware using UI menus in conjunction with the prior settings made to rrload parameters (main menu, option 3). In particular, you will want to adjust the bootloader configuration to indicate the I/O port and image format you will use. However, when using the bootloader's command line mode, the copy command contains all the information needed to direct the download.
Copy kernel from serial port to target hardware RAM.
rrload> copy -c kernel -s serial -d ram -f rrbin
This command copies the kernel from the serial port to a RAM destination using the rrbin input parser. The incoming file contains the information used by rrload to determine where in RAM the kernel is stored. The image was built specifically to load and run at this address.
Note: The command above only loads the kernel, it does NOT cause the kernel to start running. The bootloader's boot and boot_auto commands are the only way to transfer control to a kernel.
The header information is also acquired by rrload when processing incoming srec images. The bootloader keeps this information with the image and uses it to place the downloaded image in the correct memory area.
You can reduce the amount you type. The following example does the same thing as the first example above.
rrload> copy -c k -s s -d r -f r
The command below requests the bootloader to use TFTP to load the file system rrbin image. This works only if the bootloader was previously setup with the correct TFTP related user configuration. For more details, see Ethernet Downloads.
rrload> copy -c filesys -s ether -d ram -f r
The incoming rrbin file system image is copied from the ether port to memory, as specified in the first three lines of the rrbin image file.
rrload> set
Shows the current bootloader user configuration settings as described in Persistent Configuration.
rrload> help
Provides additional information regarding the copy command and others. Also shows how you can change the bootloader user-config settings if necessary.
rrload> copy -c k -s e -d r -f r; copy -c f -s e -d r -f r; boot
A command list requesting a kernel and file system download, followed by a boot of the kernel. The boot command transfers control to the last kernel downloaded, or if there wasn't one, it will attempt to locate one stored in flash and transfer it to the EntryAddr recorded with that kernel image.
rrload> copy -c f -s e -d r -f r; copy -c k -s e -d r -f r; boot
This command is exactly the same as the command above except the order of the loads are reversed. (First the file system, next the kernel, and last boot the kernel.) Either order works.
In the next three commands, we have supplied the -f n option (meaning na for not applicable) because we are moving a memory image from flash to SDRAM and it does not make sense to state the format - this is just a memory copy.
rrload> copy -c kernel-s flash -d ram -f n rrload> copy -c filesys-s flash -d ram -f n rrload> boot
Moves the kernel and file system stored in flash to SDRAM according to the LoadAddr recorded with it. Then boots the kernel by transferring control to the EntryAddr recorded with the kernel image.
rrload> boot_auto
This single command is exactly the same as the 3-command-set shown above. This is typically the command the user assigns to the bootloader's default boot command so that on power-cycle the kernel automatically boots. This is the command mapped to option 4 in the main menu.
rrload> set bootcmd boot_auto
This command sets the bootloader's default boot command to a string that represents the command (or command list) the user wants the bootloader to automatically execute on each power cycle. Using this type of command, a user can set things up so that the kernel boots directly on a power cycle instead of presenting the bootloader's UI. However, holding the ENTER key down within the host terminal session while simultaneously applying power to the board will insure that any previously stored default boot command is temporarily intercepted and instead forces the bootloader to present its user interface.
The rrload bootloader has the ability to pass a user supplied kernel command line string to the Linux (or uClinux) kernel as control is being transferred to it. Once the kernel boot process is under way, special logic in the kernel picks up the command line previously deposited by rrload then replaces the original default kernel command line embedded within the kernel. Linux then parses the command line during the remaining steps of the kernel boot process. The following sets the kernel command line to use NFS to mount the root file system (use network and directory values appropriate for your system).
rrload> set kcmdline root=/dev/nfs nfsroot=10.0.0.3:/home/tfischer/arm7/fs/fs nfsaddrs=10.0.0.20:10.0.0.3
See the BSP User's Guide for other important information about using NFS to mount the root file system.
The examples above where performed using the bootloader's command line UI. However, you can perform all of these operations equally well using the bootloader's menu UI.
As mentioned earlier, one of the main purposes of the bootloader is to facilitate getting software components loaded onto the target hardware (via an I/O port). Another purpose for the bootloader is to facilitate the storing and retrieving of software components within on-board flash. Specifically, the rrload bootloader was designed to manage four such component types:
Each of these components has an area of flash dedicated to holding it (as defined in the rrload source file btldr_pi.c). There can only be one such instance of each component within flash at any one time and, prior to replacing any content, the user must explicitly erase the previous component content. The rrload UI provides the ability to individually erase and store the four components listed above. The bootloader image area of flash is typically not something a person would deal with unless performing the steps associated with installing a copy of rrload on the target hardware. The bootloader's user configuration area of flash holds the various persistent configuration items.
Kernels and file systems can be stored two ways:
RAM-Based Case. The steps below will load a RAM-based image and store it to flash.
rrload> copy -c kernel -s ether -d ram -f rrbin rrload> eraseflash kernel rrload> copy -c kernel -s ram -d flash -f n
If the current SDRAM contents are lost (for instance by a power cycle), the user can retrieve the kernel from flash and boot it with the commands below.
rrload> copy -c kernel -s flash -d ram -f n; boot
Note: At no time must the user be aware of the specific addresses used for storing the component in either flash or SDRAM. This is true of all 4- component types. Of course, there always is an exception and, in this case, it is revealed during the flash-based image case discussed next.
Flash-Based Case. When the Linux kernel is configured for XIP (using the make xconfig kernel configuration tool), the addresses used to build the kernel and file system are set to values located in flash. These value can be found in file linux/arch/armnommu/config.in.
rrload> copy -c k -s f -d r -f n; boot
Note: If you modify the load address (using make xconfig) and cause rrload to store an image to the wrong area of flash, you will most certainly corrupt data reserved for the bootloader's use. This could require reloading rrload using a JTAG emulator.
Erase the component's flash area first before placing new contents there. These are the steps to follow:
rrload> eraseflash -c kernel rrload> copy -c k -s e -d r -f rrbin rrload> eraseflash -c filesys rrload> copy -c f -s e -d r -f rrbin
Note: You might expect the -d field to be -d flash instead of -d ram; it turns out that either one will work.
Recall that the serial port is used by rrload for UI interaction and it serves double duty when it is also used during an image download to the target platform. Take the following command for example:
rrload> copy -c kernel -s serial -d ram -f rrbin
This command is issued to rrload by using a terminal session running on a remote host connected over a serial port. Yet, the command itself is requesting a file transfer over that same serial line. When using the UI to request a file download, rrload drops into a mode where it stops using the serial channel for anything except bringing in the file image. Only when rrload has finished bringing in the image data will rrload again start using the serial line for UI operations.
When rrload drops into image load mode, the user must insure that only file image bytes are transferred over the serial line since any bytes received by the target hardware are interpreted as image data. In the case of using minicom as a terminal emulator, you can issue the rrload copy command and then, without typing anything else in the terminal emulator, go to a Linux shell and type the following:
$ cat linux.rr > /dev/ttyS0
The above command streams the image file to rrload. When rrload completes the file transfer, the user can resume using the terminal emulator and interact with the rrload UI.
If you are planning to use the Ethernet port for your downloads then you must use the rrload UI to establish parameter settings that allow the internal TFTP logic to work with your remote server. Option 3 from the main menu shows a list of current user settings as will the rrload set command.
The network stack implemented within the bootloader does NOT support the Address Resolution Protocol (ARP), therefore it is necessary to manually inform the remote server of the target hardware IP/MAC mapping. The following Linux workstation command run by user root is one way of establishing the mapping on the remote server.
# arp -s <target hardware IP Address> <target hardware MAC address>for example,
# arp -s 192.168.1.29 00:e0:81:10:36:cf
The device IP and MAC addresses you should use are stored in the Cadenux BSP Configuration under Network Settings. To access, in the development directory, type:
$ make bspconfig
and go to Network Settings. These addresses can be changed, but must be consistent between the BSP Configuration, the ARP, and the bootloader params. Changing the network settings using the Cadenux BSP configuration utility then rebuilding the rrload bootloader will cause the default values used by the boot loader to match the values set via the Cadenux BSP configuration utility.
Next, TFTP must be enabled on the remote server. The following steps describe the process.
The following steps are performed by user root:
# mkdir /tftpboot # chmod ugo+rwx /tftpboot edit /etc/xinetd.d/tftp changing the line to "disable = no" # service xinetd restart
$ cd <development directory> $ source setenv $ make $ ls /tftpbootIt can be performed manually by:
$ cd <development directory> $ cp linux.rr /tftpboot/linux.rr.<target processor> $ cp fs.img.rr /tftpboot/fs.img.rr.<target processor>
To configure the ethernet connection, you will need the IP and MAC addresses of your computer and your target hardware. In a terminal window, use
$ /sbin/ifconfig eth0 | head -2
to find the addresses for your computer. The IP and MAC addresses are the inet addr: and HWaddr, respectively.
To verify the addresses of your target hardware are set properly in the remote server, enter
$ cat /proc/net/arp
The following steps are performed using rrload on the target hardware.
From the Main Menu, go to View/Edit Params. Enter the correct addresses for your computer and the target hardware. Set option I/O load port to ether. Make sure to Erase the old params and Store the new ones.
Power cycle into the bootloader. Now, after you select Load from I/O port from the bootloader menu, you should see Load [comp] from -ether- I/O as the heading. Assuming that your files are in the /tftpboot directory, you should be able to load the kernel and the filesystem with the ethernet connection.
If you have problems, run the following in the development directory:
$ make chkconfig
This will verify that the steps taken in this section have been implemented correctly, or tell you what needs to be fixed.
If you are still having problems, consult Appendix A: Common Ethernet Problems.$ cd <development directory> $ source setenv $ make
This operation produces the following components.
| File Name | Format | Usage |
| rrload/rrload | ELF | JTAG emulator downloadable version of rrload. This is the method used the first time rrload is installed on the target hardware. |
| rrload.rr | rrbin | rrload downloadable version of rrload. Used when upgrading rrload. |
| rrload/rrload.map | ASCII | Loader map file used when debugging changes to rrload. |
| rrload.ForUpgrade.rr | rrbin | rrload downloadable version of rrload. Used when upgrading rrload. This version of rrload is linked to reside in the kernel SDRAM memory area. Used when upgrading rrload. |
| rrload/setup | ELF | JTAG emulator downloadable version of the algorithm used to initialize the hardware. Used when the Linux kernel and / or target file system are downloaded using a JTAG emulator instead of using rrload.1 |
| rrload/setup.out | ELF | Code Composer Studio (CCS) compatible vision of setup to download with a JTAG emulator instead of using rrload.1 |
| rrload/rrload.out | ELF | Code Composer Studio (CCS) compatible vision of setup to download with a JTAG emulator instead of using rrload. |
|
NOTES: 1 No setup program is build for the i.MX21 BSP. The i.MX21 contains an ROM-based bootstrap program that performs the initial hardware set. Additional setup can be accomplished with an emulator script. |
||
The rrload Makefile creates two rrload images in rrbin format, which are identical to one another except they are built to run at different locations within the memory map. This allows both instances of rrload to reside in memory simultaneously without conflicting with each other. This is necessary to perform an rrload upgrade using an older (already flash resident) version of rrload.
Assuming the user has built the new version of rrload and has the current (old) running rrload in the command line mode, these steps will accomplish the upgrade.
Before preceding, verify you can download the kernel using Ethernet. The same network setting will be used when upgrading rrload using Ethernet.
$ cd <development directory> $ source setenv $ make $ cp rrload.ForUpgrade.rr /tftpboot
rrload> set kpath rrload.ForUpgrade.rr
rrload> copy -c kernel -s ether -d ram -f rrbin
rrload> eraseflash params
rrload> boot
We used the "load kernel" path to load the second instance of rrload into memory. Then we booted the version of rrload running at the memory region normally used by the Linux kernel. At this point, the second instance of rrload should be running. We use the second instance of rrload to upgrade the normal version. The RAM location used by the normal rrload version is now available so we can now download the new version of rrload to fill that spot.You need to re-establish your desired bootloader parameters before loading the new image of the normal rrload version.
DO NOT store these settings to flash just yet. We still need to get the final bootloader image into memory first, which is the next step.
rrload> set kpath rrload.rr rrload> copy -c kernel -s ether -d ram -f rrbin rrload> boot
We have he new version in memory and we are running it. The only thing left to do is to establish your final bootloader parameter values and then use the normal rrload commands to flash itself persistently as well as flash the params persistently.
rrload> eraseflash bootldr
rrload> copy -c bootldr -s ram -d flash -f n
rrload> set bootcmd boot_auto
rrload> set loadfmt rrbin
rrload> set loadport ether
etc, for other desired settings, then...
rrload> copy -c params -s ram -d flash -f n
All done. The rrload bootloader has been upgraded and is stored persistently with its new bootloader params settings.
The steps to upgrade rrload using serial are similar to the steps used to perform the upgrade using Ethernet, except you replaced "-s ether" with "-s serial" and you have to initiate sending the image files from the Linux workstation.
$ cd <development directory> $ source setenv $ make
rrload> copy -c kernel -s serial -d ram -f rrbin
On the Linux workstation, send the upgrade version of rrload over the serial port:
$ cd <development directory> $ cat rrload.ForUpgrade.rr > /dev/ttyS1Clear out the rrload persistent parameters so they are not incorrectly loaded by the second instance of rrload and then boot the second instance.
rrload> eraseflash params
rrload> boot
rrload> copy -c kernel -s serial -d ram -f rrbin
On the Linux workstation, send the normal rrload version over the serial port:
$ cd <development directory> $ cat rrload.rr > /dev/ttyS1Now boot into the upgraded rrload.
rrload> boot
rrload> eraseflash bootldr
rrload> copy -c bootldr -s ram -d flash -f n
rrload> set bootcmd boot_auto
rrload> set loadfmt rrbin
rrload> set loadport serial
etc, for other desired settings, then...
rrload> copy -c params -s ram -d flash -f n
All done. The rrload bootloader has been upgraded and is stored persistently with its new bootloader params settings.
Getting the first instance of the bootloader onto the target hardware requires the use of a JTAG emulator. This is necessary since there is no code running on the hardware yet to "pull" in that first instance; JTAG allows you to "push" it there.
Detailed steps on loading, configuring, and using Code Composer Studio to load the rrload bootloader are available.
Once rrload is loaded into RAM and is running, we use the rrload UI to request that rrload store itself in the on-board flash. This means you do not need to purchase extra JTAG emulator software to burn flash memory. With rrload present, you can load other software components such as kernel and file system through various target hardware I/O ports (rather than using a JTAG emulator to load those components).
Gaining control of the ARM processor can be difficult because even with a JTAG emulator connected, the ARM processor starts executing what every random data is in the flash part. When executing the random data, the ARM processor may crash in a manner disables the JTAG interface. If this happens, reset the ARM and try again. It may take several retries to gain control. We have found that if you release the EVM reset button at the same time you use JTAG to gain control over the ARM processor, you will successfully be able use your JTAG debugger.
Depending upon which which JTAG emulator you are using, you may perform the initialization of hardware registers using an emulator scriptfile.
For many processors1 a setup program is also provided. The program setup.out, found in the rrload directory, is an ELF format executable that initializes the hardware and the SDRAM controller to allow for proper operation. Before downloading rrload.out, you first need to download and run setup.out. The end of setup.out contains an infinite loop called forever. After letting setup run for a few seconds, use the JTAG emulator to break execution and verify the ARM processor is executing the setup forever infinite loop. If it is not, reload setup.out and try again.
setup.out also contains a memory test routine. If you have changed how the hardware is initialized to accommodate your target hardware design, you may want to enable the memory test routine and verify the memory where rrload will reside is functioning properly.
1The setup program is provided for all platforms except for the i.MX21 ADS
After running setup.out, the SDRAM controller is initialized and the memory can now store rrload.out. Use your JTAG emulator to download the ELF version of rrload.out. Run rrload.out. You should see the rrload main menu on the terminal emulator.
The following rrload commands will store rrload into flash.
rrload> eraseflash bootldr rrload> copy -c bootldr -s ram -d flash -f n
The rrload bootloader is now installed in flash. You can turn off power to the target hardware, remove the JTAG connector, and power it back on. You should see the rrload main menu on the terminal emulator.
When built with gzip decompression support, the rrload menu will contain a "z" after the version number, as shown below:
+-------------------------------------+ | Welcome to the | | rrload bootloader | | | | Version: v5.26 z | ...
When copying either the kernel or file system component from flash to SD RAM as part of the kernel boot process, rrload checks the first few bytes of the image data. If those bytes of data match the gzip compression signature, then rrload will automatically decompress the image data before copying it to SD RAM.
When using either compressed kernel or compressed file system, you must first save the compressed component to flash before attempting to boot the kernel.
Although not normally needed, rrload contains several features to support hardware configuration and debugging. These features are enabled via the BSP Configuration Description menu in the Cadenux BSP Configuration Tool.
Any size memory region can be displayed by selecting the 6. Dump memory rrload menu item. The starting address to dump (in hex), and the number of bytes to dump (also in hex), need to be entered by the user. The following shows the results from dumping memory starting at 100000 (hex) and displaying 16 (hex) bytes of memory.
(Enter values in hex) Address? 100000 addr = 1048576 Length? 16 len = 22 00100000: D3 00 A0 E3 00 F0 29 E1 00100008: 93 0D 00 EB 00 A0 A0 E3 00100010: 02 D9 A0 E3 00 B0 Hit any key to continue
The flash memory map can displayed by selecting the 7. Print memory map rrload menu item. The following is example flash memory map output.
Flash Memory Map
----------------
Flash hardware: 00100000 - 002FFFFF
rrload: 00100000 - 00111F35 (max 0011FFFF)
rrload parameters: 00120000 - 00120964 (max 0012FFFF)
kernel: 00130000 - 0019E8BD (max 001AFFFF)
file system: 001B0000 - not loaded (max 002FFFFF)
Hit any key to continue
To verify rrload has the correct base address for the network chip, you can select the "8. Print network chip memory map" rrload menu item. The following is the output if the network chip is a CS8900A.
CS8900A Memory Dump ------------------- 0000 = 630E 0900 0020 = 0300 5554 5553 0000 0028 = 0000 0000 0000 5500 0030 = 0000 0000 0000 0000 0040 = 0200 FFFF 0050 = 0000 0100 = 0300 0003 0005 0007 0108 = 0009 000B 0300 0300 0110 = 0300 0013 0015 0017 0118 = 0019 0300 0300 0300 0120 = 0000 0300 0004 0300 0128 = 0008 0300 000C 0300 0130 = 0010 0012 1294 0AD6 0138 = 0018 0300 001C 0300 0144 = 0009 0000 0150 = FFFF FFFF FFFF FFFF 0158 = FFFF FFFF FFFF Hit any key to continue
If the chip support the Common Flash Interface (CFI) Specification, command set 2, then information embedded in the flash chip can be displayed. If the flash chip supports primary extended table version 1.1 or greater, then the CFI_CMDSET_2 flash part can be selected via the Cadenux Memory Resource Description menu in the Cadenux ARM BSPConfiguration Tool.
The following is output from displaying flash chip information.
Flash Chip Information ---------------------- Flash manufacturer / device ID: 00980043 Flash size (Mbytes): 2 Command Set: 2 Primary Extended table address: 0040 Primary Extended table version: 1.1 Top / Bottom boot flag: 2 Common Flash Interface data 0010 = 51 52 59 02 00 40 00 00 0018 = 00 00 00 27 36 00 00 04 0020 = 00 0A 00 05 00 04 00 15 0028 = 02 00 00 00 04 00 00 40 0030 = 00 01 00 20 00 00 00 80 0038 = 00 1E 00 00 01 FF FF FF 0040 = 50 52 49 31 31 00 02 01 0048 = 01 04 00 00 00 FF FF 02 Flash Sector Map (35 sectors) 0000 = 00004000 00002000 00002000 00008000 0004 = 00010000 00010000 00010000 00010000 0008 = 00010000 00010000 00010000 00010000 000C = 00010000 00010000 00010000 00010000 0010 = 00010000 00010000 00010000 00010000 0014 = 00010000 00010000 00010000 00010000 0018 = 00010000 00010000 00010000 00010000 001C = 00010000 00010000 00010000 00010000 0020 = 00010000 00010000 00010000 Hit any key to continue
rrload supports writing to arbitrary memory locations using the m. Modify memory menu item. The user interaction is the same as for the rwmem example Linux program included with the BSP. The primary purpose for modifying memory is to change the SoC hardware configuration. The following is the output when the flash idle state clock configuration is changed from 1 idle clock cycle to 3 idle clock cycles on the DM270 SoC.
< Usage:
< {b,w,l} <hex-address>[=<hex-value>][ <decimal-byte-count>]
< to read/write bytes(b), short integers(w), or longs(l)
< {h,?} to print this usage information
< q to quit
> w 030A02=3110
< 0x00030A02 = 0x1110 -> 0x3110
> q
The command line syntax is very simple: A one character command followed by optional arguments. There are not optional arguments for the h (help), ? (help), and q (quit) commands. There are three memory access operations differing only in the width of the memory access: b (byte size), w (16-bit half word size), and l (32-bit long word size). The arguments for these memory access operations are all the same: As shown above, these include, as a minimum, a hexadecimal address identifying the memory location to access. Memory write operations, are specified by appending an equal sign and and value to write. For example:
For both reads and writes, an option byte count (in decimal). This will repeat the memory access for the correct number of times to access that number of bytes.
On the
8.6 Verify SDRAM Image
To verify proper communication and proper flash erase and programing, rrload supports comparing a previously stored flash component (either kernel or file system) with a version downloaded to SD RAM. Follow these steps:
The hexadecimal address for the _text and _etext are required to perform the verification. There values can be found in the file linux/System.map.
The following is example verify SDRAM image output:
Enter value of _text symbol in System.map: 0290c000
Enter value of _etext symbol in System.map: 029f5df0
Starting flash address: 0013C010
Starting SDRAM address: 0290C000
Number of bytes: 000E9DF0
If you are having problems with the ethernet connection, assure that the following settings are correct. If a test fails, try implementing the solution.
| Test | Solution |
Type $ ls /tftpboot and verify that
|
As the root user, type # chmod go+w /tftpboot Run make in the development directory again. |
| In a terminal window, type: $ /sbin/ifconfig eth0 | head -2 $ cat /proc/net/arp Type $ make bspconfig and click Network Settings on the window that pops up. Power cycle the board and bring up the bootloader menu. Go to View/Edit Params. Verify that all four of these locations have consistent IP and MAC addresses for both the device and your computer. |
To change the Server (your computer) IP or MAC, change the bootloader params (remember to Erase the old params and Store the new ones.) To change the Device IP or MAC, type (as the root user): # arp -s <target hardware IP Address> <target hardware MAC address> with the IP and MAC addresses from the BSP Config Network Settings. Also change the Device IP and MAC in the bootloader params. |
| As the root user, use an ethernet analyzer like tcpdump or ethereal to monitor the packets exchanged between the remote server and the target hardware. Attempt to download the kernel or file system over Ethernet using rrload while running the ethernet analyzer. |
|
After changes, make sure to Erase old params, and Store the new ones flash.