index.html

Embeded bootloader (rrload by ridgerun) for TI linux based platform v5.36

<pre>
$ cd dsplinux/dsc21/rrload
$ cat README
$ make

This operation produces three rrload bootloader images.

1. rrload     -- This is ELF version of the
                 bootloader which can be downloaded
                 to the board's SDRAM via a JTAG
                 based emulator. Currently this is
                 the only way to get the very first
                 instance of the rrload bootloader
                 installed on the board.
2. rrload.rr  -- This is an rrbin format version of
                 the rrload bootloader as produced
                 by the Makefile using the mkimage
                 utility. It only differs from the
                 ELF version in format. This rrbin
                 format is very close to a raw binary
                 format.
                 This is used by user performing an
                 upgrade of an existing rrload
                 installation. Other areas of this
                 document discuss the process more
                 fully.
3. rrload.ForUpGrade.rr -- This is identicle to the
                 other two version of the bootloader
                 except it is built to load to a
                 different SDRAM address.
                 This is used by user performing an
                 upgrade of an existing rrload
                 installation. Other areas of this
                 document discuss the process more
                 fully.
</pre>
<p>
<hr WIDTH="100%">
<A NAME="upgrading"><h1>Upgrading An Existing rrload Installation</h1></A>

This discussion refers to the installation of the
rrload bootloader program and not the installation of a
kernel and/or filesystem normally managed by the
installed bootloader.
<p>
The Makefile of the rrload project automatically
creates two rrload rrbin images which are absolutely
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
which is necessary for performing rrload upgrades. The
main instance is called "rrload.rr" and represents the
image you really want to have loaded on the board; the
second instance is called "rrload.ForUpGrade". The
purpose of the "rrload.ForUpGrade" object is to help
provide the rrload user with the ability to upgrade an
existing rrload installation without the use of
JTAG. The reason this is useful is to allow the
following steps to occur for the user who wishes to
upgrade an old instance of rrload with a newer version
(again, without using JTAG). Assuming the user has
built the new version of rrload and has the current
(old) running rrload in command line mode, these steps
could accomplish the upgrade. Please note that in this
example we are choosing to use ethernet to load the
new image and hence we assume that you have the
necessary bootloader params established to allow
this (see menu option #3).
<p>
<h1>...Upgrading via Ethernet</h1>
<pre>
Step0:
  Start a minicom window on the desktop connected
  to the targets serial port, then hold down the
  Enter key while applying power to the board. Let
  go after a second or two when you see the rrload
  main menu appear. At the main menu select option
  3 and jot down any installation specific settings
  that you may want to re-establish later after the
  upgrade process.

Step1:
  At the main menu select option 5 to get into command
  line mode, Then...
  rrload> set kpath rrload.ForUpGrade.rr
  rrload> copy -c kernel -s ether -d ram -f rrbin
  rrload> eraseflash params
  rrload> boot

    Note: We've used the "load kernel" path to sneak
    in the second instance of rrload. Then we booted it.
    At this point the second instance of rrload should
    be running and we'll use it to perform the upgrade.
    The ram location previously used for rrload is now
    available so we can now download the new version of
    rrload to fill that spot. But please note, you will
    have to reestablish your desired bootloader params
    for this new image just loaded and running. Please
    do not store these settings to flash just yet. We
    still need to get the final bootloader image into
    memory -- the next step.

Step2:
  At the main menu select option 5 to get into command
  line mode, Then...
  rrload> set kpath rrload.rr
  rrload> copy -c kernel -s ether -d ram -f rrbin
  rrload> boot

    Note: okay, now we've got the new version in memory
    and we are running it. The only thing left to do is
    to establish your final bootloader parameter values
    (menu item #3 stuff recorded earlier) and then use
    the normal rrload commands to flash itself persistently
    as well as flash the params persistently.

Step3:
  At the main menu select option 5 to get into command
  line mode, Then...
  rrload> eraseflash bootldr
  rrload> copy -c bootldr -s ram -d flash -f na
  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 na

    Note: All done. The rrload bootloader has
    been upgraded and is stored persistently with
    its new bootloader params settings.

NoteA: Although this example assumed rrload command line
       mode, it could just as well have been performed
       using rrload's menu based UI.

NoteB: Although this example performed the image
       "loads" via ether, it could just as well have
       been performed using one of the other I/O ports.
       Below is another example using the serial port.
</pre>

<h1>...Upgrading via Serial</h1>
<pre>
Step0:
  Start a minicom window on the desktop connected
  to the targets serial port, then hold down the
  Enter key while applying power to the board. Let
  go after a second or two when you see the rrload
  main menu appear. At the main menu select option
  3 and jot down any installation specific settings
  that you may want to re-establish later after the
  upgrade process.

Step1:
  At the main menu select option 5 to get into command
  line mode, Then...
  rrload> copy -c kernel -s serial -d ram -f rrbin

  Then immediately do the following...

  On the host system, enter the following (where ttyS1
  is the serial port connected to the EVM):

  linux$ cd dsplinux/[platform]/rrload/
  linux$ cat rrload.ForUpGrade.rr > /dev/ttyS1

  ...when the download completes, proceed with the following:

  rrload> eraseflash params
  rrload> boot

    Note: We've used the "load kernel" path to sneak
    in the second instance of rrload. Then we booted it.
    At this point the second instance of rrload should
    be running and we'll use it to perform the upgrade.
    The ram location previously used for rrload is now
    available so we can now download the new version of
    rrload to fill that spot.

Step2:
  At the main menu select option 5 to get into command
  line mode, Then...
  rrload> copy -c kernel -s serial -d ram -f rrbin

  Then immediately do the following...

  On the host system, enter the following (where ttyS1
  is the serial port connected to the EVM):

  linux$ cd dsplinux/[platform]/rrload/
  linux$ cat rrload.rr > /dev/ttyS1

  ...when the download completes, proceed with the following:

  rrload> boot

    Note: okay, now we've got the new version in memory
    and we are running it. The only thing left to do is
    to establish your final bootloader parameter values
    (menu item #3 stuff recorded earlier) and then use
    the normal rrload commands to flash itself persistently
    as well as flash the params persistently.

Step3:
  At the main menu select option 5 to get into command
  line mode, Then...
  rrload> eraseflash bootldr
  rrload> copy -c bootldr -s ram -d flash -f na
  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 na

    Note: All done. The rrload bootloader has
    been upgraded and is stored persistently with
    its new bootloader params settings.
</pre>

<p>
<hr WIDTH="100%">
<A NAME="install"><h1>Installing rrload into a New Flash Chip</h1></A>

Getting the first instance of the bootloader onto the
EVM requires the use of the board's JTAG interface
since there isn't yet any code running on the board to
"pull" in that first instance; JTAG allows you to
"push" it there.  Once rrload is loaded, you can use
the rrload UI to request it to store itself in the on
board flash. With rrload present you now have the means
to load other software components such as kernel and
file system through various standard board I/O ports
(as opposed to JTAG loading).
<p>
The issue of upgrading rrload with a new version of rrload
can be performed without the use of JTAG and is described
in the section "<A HREF="#upgrading">Upgrading An Existing rrload Installation</A>"
<p>
More info:
<p>
<pre>
For C547x: 
  Standard JTAG:
     First install jumpers on JP16, JP17, and JP18.
     Then use the emulator to download and run the setup
     program (built as part of rrload). 
     Use the setup_c5471.cmm debugger script to do
     this. This will initialize h/w so that SDRAM is
     visible. Stop the emulator after a few seconds of
     running and then download rrload and run. At this
     point you can use the rrload UI to erase and
     program the flash.
  Parallel JTAG:
     First removed jumpers from JP16, JP17, and JP18.
     Then consult the gdb documentation supplied with
     your DSPLinux distribution and look at the
     example session using the sdi-arm-gdb debugger.
     This will show how to use that debugger with the
     sdserver and the parallel jtag port to install
     the bootloader.
</pre>
<p>
For omap1510: First use the emulator to download and
run the setup program (built as part of rrload). You
should use the Lauderbach script called setup_omap1510.cmm
to perform this load/run. This will initialize h/w so
that SDRAM is visible.  Now stop the jtag debugger
after a few seconds of running and then download rrload
and run. At this point you can use the rrload UI to
erase and program the flash. If you want now boot from
flash make sure that the SW2-6 switch is in the "off"
position.
<p>
For DSC21/24: First use the emulator to download and run the
setup program (built as part of rrload). This will initialize
h/w so that SDRAM is visible. Stop the emulator after a few
seconds of running and then download rrload and run. Do this
first with the SRAM/Flash jumper set to the SRAM mode. To
burn flash you will want to hot-jumper from the SRAM mode
to the Flash mode. Do this while rrload is running. At this
point you can use the rrload UI to erase and program the
flash.
<p>
For TI925: First use the emulator to reset the board and
then run until you see the TI monitor message appear on
the minicom window. At this point the h/w has been initialized
correctly to allow SDRAM to written to. Stop the emulator and
then download rrload and run.

<p>
<hr WIDTH="100%">
<A NAME="customize1"><h1>Customizing rrload with new drivers</h1></A>


A Makefile links the following tree into a runnable
bootloader image called "rrload". The individual *.o
files have been pre-built at the RidgeRun factory and
supplied in the rrload project directory along with the
Makefile and this documentation (index.html).

<pre>
                  head_*.o
                      |
                      |
                 rrload_base.o
                      |
                      |
     +-----------+----+-----+-----------+
     |           |          |           |
   sdram.h     io.h      flash.h     ether.h
   sdram_*.o   io_*.o    flash_*.o   ether_*.o
</pre>

The driver modules shown at the bottom of this
hierarchy have a *.h file associated with them that
describes the interface of each driver. This allows a
user to replace a driver with an new
implementation. The new implementation of course needs
to provide logic as described by the header file. The
user need only rename the existing *.o to some other
name such as *.o.original, and then place the new *.c
or *.S file in the directory, and type "Make". The
Makefile will compile the new driver source file and
then link it as normal forming a new rrload image
containing the replacement driver.

<p>
Here is an example:
<p>

In this example we'll replace the current sdram_dsc24.o
file with a new version that supports the 4Mx32 Mobile
SDRAM instead of the SDRAM that typically ships with a
DSC24 EVM. For starters, since we're using the DSC24 in
our example here, the specific directory structure as
shipped from the RidgeRun factory would look like this:
<p>
<pre>
                head_dsc24.o