index.html

针对德州仪器DM270开发板的bootloader,其实现了内核的下载以及文件系统的下载

<LI><b>Default UI mode</b><br>
      "mode"
      Valid settings are: cmd,  menu.
      This allows the user to establish which UI the bootloader
      will present by default.
<LI><b>Default boot command</b><br>
      "bootcmd"
      This can be any list of bootloader commands. Separate your
      commands with a ';'. For example you might want to use this
      to have the bootloader automatically perform a kernel xfer to
      ram, a filesystem xfer from flash to ram, and then boot the
      kernel. This example could be accomplished with the following
      default boot command:<br>
      <code> copy -c k -s f -d r -f na; copy -c f -s f -d r -f na; boot </code>
      (Although it should be noted that this particular example could be
      accomplished even more easily with single command "boot_auto".)
<LI><b>I/O load format</b><br>
      "loadfmt"
      Valid settings are: srec, rrbin
<LI><b>I/O load port</b><br>
      "loadport"
      Valid settings are: ser, par, ether.
      When the load port is set to ether then the other parameters
      pertaining to TFTP will be enabled. Otherwise they are ignored.
<LI><b>server IP</b><br>
      "serverip"
      The IP of the remote server which will be delivering the
      TFTP based image.
<LI><b>server MAC</b><br>
      "servermac"
      The MAC of the remote server (TFTP).
<LI><b>device IP</b><br>
      "devip"
      The IP of the device which will be initiating and recieving the
      TFTP based image during an ether transfer.
<LI><b>device MAC</b><br>
      "devmac"
      The MAC of the device (TFTP).
<LI><b>Kernel Path</b><br>
      "kpath"
      This is the path name of the kernel that is to be xferred from
      the remote server to the device over the ether port using TFTP.
<LI><b>FileSys Path</b><br>
      "fpath"
      This is the path name of the file system that is to be xferred from
      the remote server to the device over the ether port using TFTP.
<LI><b>Kernel Parameters</b><br>
      "kcmdline"
      This is the command line string that will be passed to the
      kernel as it is being invoked by the bootloader.
</UL>

Note: As mentioned earlier any of these SDRAM based
values can be changed by the user and remain in effect
only for the current session.  If the user wishes the
new settings to survive power cycles then he/she needs
to take steps to erase the params section of flash and
the re-store the params to flash.  On bootup, the
bootloader will always insure that the SDRAM based
params start out initialized to the flashed set.

<p>
<hr WIDTH="100%">
<A NAME="download"><h1>Downloading a New Kernel and/or Filesystem</h1></A>

One of the main reasons the bootloader exists is to
give the user a means to load images onto the EVM
board. Specifically, we are interested in loading a
kernel and possibly a root filesystem. Without the
bootloader the user would be restricted to JTAG based
downloads which can be an attractive option except not
all users will have the supporting tools necessary to
facilitate JTAG based development. The rrload
bootloader gives the user a immediate path to getting
software components loaded and running on the board.
Additionally, the bootloader allows the user to store
the components to flash if desired.
<p>
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 easily
adding more modules to support additional image formats
or I/O ports as necessary. Currently there are two
image formats supported and three I/O ports.

<p>
<b>Image Formats</b>
<UL>
<LI>Motorola srec format
<LI>RidgeRun rrbin format.
</UL>
<p>
<b>I/O Load Ports</b>
<UL>
<LI>Ethernet Port (via TFTP)
<LI>Serial Port
<LI>Parallel Port (incomplete)
</UL>

<dl>
<p><dt><b>How to create and srec image.</b>
<dd>

The srec format is a Motorola inspired binary standard
format.  This is an ascii format used for downloading
executables, not data files. A srec file is typically
created prior to download with the following command:

<pre>
  $ arm-uclinux-objcopy -S -O myprog myprog.srec
</pre>

Where myprog is a standard executable file
format such as ELF or a.out, etc.

<p><dt><b>How to create an rrbin image.</b>
<dd>

A RidgeRun inspired format. This is tagged image binary
format use for downloading either executables or data
files such as filesystems, etc. This format is very
efficient and can be generated with the help of the
RidgeRun supplied utility called `mkimage` which is
used to prepare a file for download to the rrload
bootloader.

<pre>
  $ <a href="mkimage">mkimage</a> --LAddr 08e00000 linux linux.rr
   ..or..
  $ mkimage --LAddr 08c00000 romdisk.img romdisk.img.rr
</pre>

<pre>
  Note: The --LAddr used here is just an example, the
        actual value you use will be dependant on the
        address that you need your specific object loaded
        to. For example, in the case of a kernel, a
        command such as `arm-linux-objdump -h linux`
        could be used to find out where the image expects
        to load to. In the case of a filesystem the --LAddr
        value should match the address that your kernel
        expects to find the filesystem at during a kernel
        boot. mkimage is used to prepare both kernel images
        and filesystem images for download.
</pre>

The resulting *.rr file will be a space efficient
binary format with an additional header tacked on the
front to allow the rrload bootloader 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
and it contains the following pieces of information
which is used by rrload to process the enclosed pure
binary data. Here is an example of the internals of a
*.rr file.

<pre>
  >LoadAddr :0x08e00000
  >EntryAddr:0x08e00130
  >NumBytes :0x0000a200
  (binary block here; 0xa200 bytes)
</pre>

Note: In our example here, 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 doesn't
represent an executable, but rather represents a
filesystem (for example), 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 <a href="mkimage">mkimage</a> script.

</dl>

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 filesystem
components. Once the images are created they can be
downloaded to the EVM 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 intend on using. On the other
hand, when using the bootloader's command line mode,
the "copy" command contains all the information needed
to direct the download.  Here are some command line
mode examples:

<pre>
rrload> copy -c kernel -s serial -d ram -f rrbin
   This copies the kernel from the serial port to a
   ram destination using the rrbin input parser. The
   ram addresses written to are determined by the
   incoming file; remember the rrbin header shown above?
   The LoadAddr field of incoming file determined where
   in the system's memory map the image is loaded to. The
   image was built specifically to load and run at
   this address. Note: The header information is also
   acquired by rrload when processing incoming srec
   images as well. The bootloader will keep this
   information with the image so that it always knows
   where in memory it needs to reside when used. This
   will come into play if the user subsequently requests
   the bootloader to store the kernel to flash -- how
   does the bootloader know what a kernel is? It doesn't
   really, except in this command here the -c kernel
   informed the bootloader that this image is a kernel
   and hence when the user later requests a kernel
   boot, or kernel store, etc, the bootloader has a
   record of what image the term "kernel" corresponds
   to. Note: this command 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.

rrload> copy -c k -s s -d r -f r
   Exactly the same as the example above.

rrload> copy -c filesys -s ether -d ram -f r
   Incoming rrbin filesystem image is copied from the
   ether port to the memory map ram locations called
   out by the image. Like kernel images, the bootloader
   will maintain a record with this image that
   indicates the location in memory that it originally
   loaded to. If the user requests the filesystem be
   moved to flash and later power cycles and requests
   the filesystem be moved to SDRAM the bootloader will
   have the necessary information to place it in the
   correct location. Note: This command requests the
   bootloader to pull in the rrbin image using the ether
   port. This will only work if the bootloader has
   previously been setup with the correct TFTP related
   user configuration. For more please see
   <A HREF="#etherloads">"A Special Note About Ethernet Downloads".</A>

rrload> set
   Shows the current bootloader user configuration
   settings.

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 filesystem
   download, followed by a boot of the kernel. The
   "boot" command transfers control to the last kernel
   downloaded, or if there wasn't one, will try and
   locate one stored in flash and transfer 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
   Exactly the same as the command above. We've just
   reversed the order of the loads. Filesystem first
   this time, then the kernel, then boot the kernel.

rrload> copy -c kernel  -s flash -d ram -f na
rrload> copy -c filesys -s flash -d ram -f na
rrload> boot
   Move the kernel and filesystem stored in flash to
   SDRAM according to the LoadAddr recorded with
   it. Then boot the kernel by transferring control to
   the EntryAddr recorded with the kernel image. Note:
   We've supplied the "-f na" here since we are moving
   a pure memory image from flash to SDRAM and it
   wouldn't make sense to state "-f srec" or "-f rrbin"
   since those images are neither of those formats --
   it's just a straight memory copy.

rrload> boot_auto
   This single command is exactly the same as the three
   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
   menu option 4 of the main menu.

rrload> set bootcmd boot_auto
   Sets the bootloader's default boot command to a
   string that represents the command (or command list)
   the user would like the bootloader to automatically
   execute on each power cycle. This is how a user can
   set things up so that the kernel boots directly on a
   power cycle instead of presenting the bootloader's
   UI.  Yet, 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 force the bootloader to
   present its user interface.
</pre>

Please Note: It is really only a matter of
documentation convenience that all the examples above
where performed using the bootloader's command line
UI. All these operations could have been performed
equally well using the bootloader's menu UI.

<p>
<hr WIDTH="100%">
<A NAME="storing"><h1>Storing a New Kernel and/or Filesystem in Flash</h1></A>

As mentioned earlier a main purpose in life for the
bootloader is to facilitate getting software components
loaded onto the board (via I/O ports). Another main
purpose for the bootloader is to facilitate the storing
and retrieving of software components within on-board
flash. Specifically, the rrload bootloader has been
designed to manage four such component types.

<UL>
<LI>Bootloader code image.
<LI>Bootloader user config settings.
<LI>Kernel image.
<LI>Filesystem Image (for kernel).
</UL>

Each of these components has a very specific area of
flash dedicated to holding it. 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 4 components listed. The bootloader image
area of flash is typically not something a person would
fiddle with unless performing the steps associated with
installing a copy of rrload on the EVM board. The
bootloader's user config area of flash holds the
various configuration settings available via option 3
of the main menu but the Kernel and Filesystem areas of
flash are what we want to talk more about in this
chapter.

<UL><b>Kernels and Filesystems can be stored two ways...</b>
<LI>1...by using the store functions available from option
   2 of the main menu to copy content existing in