index.html

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

   SDRAM over to flash. Alternatively, the "copy"
   command as issued from the bootloader's command
   line UI can be used to store content into flash.
   In upcoming discussions, we'll refer to this as
   the "ram based" case.  ..or..
<LI>2...by performing a kernel or filesystem download via an
   I/O port where the incoming image indicates load
   addresses that are in the flash memory map area of
   the system. For example, a kernel built to execute
   in place (XIP) within the flash would be linked to
   load at an address within the flash portion of the
   memory map and hence an rrload download of that
   image would route the file directly to flash.
   We'll consider this a "flash based" image.
</UL>

In the "ram based" case the user can remain unaware of
the flash addresses used to store a kernel and
filesystem.  The bootloader takes care of tagging the
stored component with enough information to allow the
user to later pull this component back out of flash and
into its original SDRAM location prior to use. For
example, the following steps will load in a ram based
image and store it to flash:
<pre>
  rrload> copy -c kernel -s ether -d ram -f rrbin
  rrload> eraseflash kernel
  rrload> copy -c kernel -s ram -d flash -f na
</pre>
If the current SDRAM contents are lost (e.g. by a power
cycle) the user can retrieve the kernel from flash and
boot it with the following commands:
<pre>
  rrload> copy -c kernel -s flash -d ram -f na; boot
</pre>
Notice that at no time did the user need to be aware of
the specific addresses used for storing the component
in either flash or SDRAM. This is true of all four
component types.  Of course there's always got to be
an exception, and in this case it is revealed during
the "flash based" image case discussed next.

<A NAME="xip"><h1>XIP Images are a Special Case</h1></A>

As we mentioned earlier, the "flash based" case is
unique in that an image is written directly to flash as
a result of downloading a kernel or filesystem via an
I/O port. This occurs when the image contains load
addresses that fall within the flash area of the
system's memory map. Those address were assigned at the
time the image was produced by a linker and then
prepared by mkimage into an rrbin image. This falls in
the realm of advanced usage and requires some special
attention as mistakes in this area can corrupt the
board's flash content to the point of not permitting a
boot. In this case, the user would be forced to install
a new copy of rrload using the JTAG connector. The
critical area pertains to the selection of load address
assigned to the image. A user is not free to locate
the image any where he/she chooses since areas of the
flash have already been set aside for the bootloader's
use. These areas are reserved. Instead the user is
limited to a sub-range within the flash for placing
XIP kernel images and another specific sub-range for
placing XIP filesystem images. Loads performed to
these specific ranges are managed by rrload by way
of tagging the loaded image with the normal record
keeping info normally associated with kernels and
filesystems stored to flash -- just as when storing
components in the normal manner (copy from SDRAM to
flash). This record keeping info is stored automatically
by rrload during the download and contains enough
information that rrload knows this component is an
XIP one. For example, the following command would
not result in a copy to SDRAM since rrload can see
that the stored kernel did not originate from SDRAM
and instead was an XIP loaded one. The requested copy
is ignored and the kernel is simply booted in place.
<pre>
  rrload> copy -c k -s f -d r -f na; boot
</pre>
The steps for performing an XIP download are pretty
straight forward but it must be emphasized that it
assumes the user had taken care to build the load image
with a valid load address. If you send an image to the
wrong area of flash you are most certainly corrupting
data reserved for the bootloader's use. As always, we
erase the component's flash area first before placing
new content there. Here are the steps:
<pre>
  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
</pre>
Note: You may have expected the -d field to be "-d
flash" instead of "-d ram"; it turns out that either
one will work.
<p>
Important! These steps will only be successful if you
build the XIP kernel and XIP filesystem so as to be
fully contained within the following special flash
address ranges:
<pre>
  --C547x EVM--
  XIP kernel:  Flash range 0x00040020 to 0x0011ffff (inclusive)
  XIP Filesys: Flash range 0x00120020 to 0x003fffff (inclusive)

  --DSC21 EVM--
  XIP kernel:  Flash range 0x02020020 to 0x020bffff (inclusive)
  XIP Filesys: Flash range 0x020C0020 to 0x021fffff (inclusive)

  --DSC24 EVM--
  XIP kernel:  Flash range 0x02020020 to 0x020bffff (inclusive)
  XIP Filesys: Flash range 0x020C0020 to 0x021fffff (inclusive)

  --OMAP1510 EVM (F160 Chips) --
  XIP kernel:  Flash range 0x00020020 to 0x0021ffff (inclusive)
  XIP Filesys: Flash range 0x00220020 to 0x0081ffff (inclusive)

  --OMAP1510 EVM (F128 Chips) --
  XIP kernel:  Flash range 0x00040020 to 0x0023ffff (inclusive)
  XIP Filesys: Flash range 0x00240020 to 0x0083ffff (inclusive)

  --OMAP710 EVM (F160 Chips) --
  XIP kernel:  Flash range 0x00020020 to 0x0021ffff (inclusive)
  XIP Filesys: Flash range 0x00220020 to 0x0081ffff (inclusive)

  --OMAP710 EVM (F128 Chips) --
  XIP kernel:  Flash range 0x00040020 to 0x0023ffff (inclusive)
  XIP Filesys: Flash range 0x00240020 to 0x0083ffff (inclusive)

  --TI925 EVM (F160 Chips)--
  XIP kernel:  Flash range 0x00020020 to 0x000bffff (inclusive)
  XIP Filesys: Flash range 0x000C0020 to 0x001fffff (inclusive)

  --TI925 EVM (F128 Chips)--
  XIP kernel:  Flash range 0x00040020 to 0x000dffff (inclusive)
  XIP Filesys: Flash range 0x000e0020 to 0x001fffff (inclusive)
</pre>

<p>
<hr WIDTH="100%">
<A NAME="serialloads"><h1>A Special Note About Serial Downloads</h1></A>

Note: Recall that the serial port is used by rrload for
UI interaction and serves double duty when also used
during an image download to the target platform.  Take
the following command for example:

<pre>
  rrload> copy -c kernel -s serial -d ram -f srec
</pre>

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. Doesn't the
UI occurring over the serial line conflict with a file
transfer over the same line? No it doesn't. 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 brought in the final byte will rrload again
start using the serial line for UI operations. Now it
is also true that when rrload drops into "load" mode
that the user must insure that only file image bytes
now be transfered over the serial line since any bytes
received by the target device will be interpreted as
file bytes.  This is something the user will need to be
aware of.  In the case of using `minicom` as a terminal
window we find that we can issue the "copy" command and
then, without typing anything else in that terminal
session, go to a shell window and type:

<pre>
  $ cat linux.rr > /dev/ttyS0
</pre>

This streams the file to rrload. When rrload completes
the file transfer the user can move the cursor back
over to the minicom window and resume interacting with
the rrload UI.

<p>
<hr WIDTH="100%">
<A NAME="etherloads"><h1>A Special Note About Ethernet Downloads</h1></A>

If you are planning to use the ethernet port for your
downloads then you will have to use the UI to establish
params settings that allow the internal TFTP logic to
work with your remote server. Option 3 from the main
menu will show a list of current user settings. These
are the same settings that can viewed from command line
mode by issuing the "set" command. Here are some
example settings:

<pre>
  ui mode [cmd|menu]  : menu
  default boot cmd    : boot_auto
  I/O load format     : rrbin
  I/O load port       : ether
  Server IP    (tftp) : 192.168.1.15
  Server MAC   (tftp) : 55:3:00:c0:00:F0
  Device IP    (tftp) : 192.168.1.50
  Device MAC   (tftp) : 11:22:33:EA:cc:00
  Kernel Path  (tftp) : linux.rr
  FileSys Path (tftp) : romdisk.img.rr
  Kernel cmdline      :
</pre>

Note: Since the network stack implemented within the
bootloader does not yet support the Address Resolution
Protocol (ARP) it will be necessary to manually inform
the remote server of your device IP/MAC mapping. The
server would normally be able to use ARP at runtime to
learn this mapping. Until then, do this sort of command
on your server (may need to be root user):

<pre>
  $ arp -s 192.168.1.29 00:e0:81:10:36:cf
</pre>

Notice here that we are manually loading the server's
internal ARP cache with the IP and MAC of our EVM
device. It is also important that you have your system
admisistrator enable TFTP on your remote server since
this is often times disabled for security reasons. One
final note, as the example goes above, rrload will
expect to find a kernel file by the name of linux.rr
which should be located on the remote server in the
default TFTP directory of that machine -- in my case
that was /home/skranz.

<p>
<hr WIDTH="100%">
<A NAME="kernelargs"><h1>A Special Note About Passing A Command Line and Ethernet MAC to the Kernel</h1></A>

The DSPlinux bootloader has the ability to pass a user
supplied Kernel Command Line string to the DSPLinux
kernel as control is being transferred to it. Once the
kernel boot process is under way, special logic in the
DSPLinux kernel picks up the Command Line previously
deposited by rrload and replaces whatever original
default kernel command line was embedded within the
kernel. The command line is then parsed in the normal
way during the remaining steps of the kernel boot
process.  To implement this, a special SDRAM memory
location is agreed upon in advance which rrload and the
kernel are both built to know about. Again, this allows
the bootloader to deposit a command line string at that
specific SDRAM memory location and when the DSPLinux
kernel is booted that string will be picked up at the
same location as in the manner just described.
<p>
Note: A NULL terminated magic pattern string equal to
"kcmdline-->" actually proceeds the real kernel command
line string (if any) to let the kernel know that a
valid string really exists (even if just a NULL
string). If the pattern is found then the kernel can
assume that the command line string will immediately
follow the magic string. Both the magic string and the
command line string (if they exist) butt up against
each other, and again, are both null terminated
strings. If the pattern is not found then the kernel
will assume that it had been invoked by some other
means than the rrload bootloader and will avoid
attempting to pick up an incoming command line
string. There's probably nothing valid there anyways.
<p>
In like manner, the Device MAC rrload param configured
by the user is also deposited in a special ram location
so that the Kernel can retrieve it and make use of it
in ways necessary for Kernel ethernet initialization.
This NULL terminated ethernet MAC string
(e.g. "00:11:22:33:44:55") is deposited in the same
manner as described for the Kernel Command Line with
the NULL terminated magic pattern "etherMAC-->"
immediately proceeding it. When the kernel boots it
can use these deposited strings in ways it sees fit.
<p>
Although a user wouldn't normally need to know the
exact ram addresses used for depositing the Kernel
Command Line and Device MAC, it may help those trying
to debug kernel boot issues. The specific ram addresses
used for the kernel's incoming Command Line string and
ether MAC are:

<pre>
  Note: the quote ("..") characters are shown here for
        clarity only and the NULL label represents the
        byte value zero that terminates each string.

  --C547x EVM--
  Start Addr | Comment
  -----------+--------------------------------------------
  0xffc00020 | "kcmdline-->"NULL"Command Line string"NULL
  0xffc00100 | "etherMAC-->"NULL"00:11:22:33:44:55"NULL

  --DSC21 EVM--
  Start Addr | Comment
  -----------+--------------------------------------------
  0x08000000 | "kcmdline-->"NULL"Command Line string"NULL
  0x080000E0 | "etherMAC-->"NULL"00:11:22:33:44:55"NULL

  --DSC24 EVM--
  Start Addr | Comment
  -----------+--------------------------------------------
  0x00900000 | "kcmdline-->"NULL"Command Line string"NULL
  0x009000E0 | "etherMAC-->"NULL"00:11:22:33:44:55"NULL

  --OMAP1510 EVM--
  Start Addr | Comment
  -----------+--------------------------------------------
  0x10000100 | "kcmdline-->"NULL"Command Line string"NULL
  0x100001E0 | "etherMAC-->"NULL"00:11:22:33:44:55"NULL

  --TI925 EVM--
  Start Addr | Comment
  -----------+--------------------------------------------
  0x05e00000 | "kcmdline-->"NULL"Command Line string"NULL
  0x05e000E0 | "etherMAC-->"NULL"00:11:22:33:44:55"NULL

</pre>

Note: The bootloader will manage these addresses for
you according to the settings you have established for
the <code>kcmdline</code> parameter and <code>devmac</code>
parameter.  These parameters are settable using the
rrload menu mode interface (option 3 from main menu) or
the command line mode. An example follows:

<pre>
   rrload> set kcmdline root=/dev/rom0
   rrload> set devmac 00:11:22:33:44:55
</pre>

<p>
<hr WIDTH="100%">
<A NAME="buiding"><h1>Building the rrload bootloader</h1></A>