index.html

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

                    |
                    |
               rrload_base.o
                    |
                    |
   +----------------+---------------+----------------+
   |                |               |                |
 sdram.h         io.h          flash.h           ether.h
 sdram_dsc24.o   io__dsc21.o   flash_toshiba.o   ether_cs8900.o

</pre>

The steps performed to replace the current
sdram_dsc24.o driver are as follows:

<UL>
<LI>Rename existing driver object.
<pre>
     $ cd rrload
     $ mv sdram_dsc24.o sdram_dsc24.o.orginal
</pre>
<LI>Bring in new driver impl. This would be
     implemented as per the sdram.h description.
<pre>
     $ cp sdram_dsc24.S.example sdram_dsc24.S
</pre>
<LI>Rebuild the bootloader (rrload).
<pre>
     $ make
</pre>
</UL>

For reference, the user supplied sdram_dsc24.S.example
source file contains this logic, as an example:

<pre>
  $ cat sdram_dsc24.S.example
  .text
  .align
  .global sdram_ini
  sdram_ini:
    // SDMODE Reg (0x0x000309a6)
    // =========================
    //   Bit(s) 15:    RDL select = "1 cycle"
    //   Bit(s) 14:    SDRAM bus width select = "32bits"
    //   Bit(s) 13:    DMA select = "ext mem -> SDRAM"
    //   Bit(s) 12:    Bank Number selection = "4 BANK"
    //   Bit(s) 11-10: Cas Latency selection = "3 cycle"
    //   Bit(s) 9-8:   Memory Type = "8k X 512 word"
    //   Bit(s) 7:     DQMC Control = "Normal"
    //   Bit(s) 6:     Automatic Power Down = "OFF"
    //
    // REFCTL Reg (0x0x000309a8)
    // =========================
    //   Bit(s) 8: Auto Refresh Enable = "Enabled"
    //   Bit(s) 7-0: Refresh cycle cnt = "0x10"
    //
    ldr r0,=0x000309a6
    ldr r1,=0x0000df00
    str r1,[r0]
    ldr r0,=0x000309a8
    ldr r1,=0x00000110
    str r1,[r0]
    ldr r0,=0x000309a6
    ldr r1,=0x0000df02
    str r1,[r0]
    ldr r0,=0x000309a6
    ldr r1,=0x0000df04
    str r1,[r0]
    ldr r0,=0x000309a6
    ldr r1,=0x0000df04
    str r1,[r0]
    ldr r0,=0x000309a6
    ldr r1,=0x0000df04
    str r1,[r0]
    ldr r0,=0x000309a6
    ldr r1,=0x0000df04
    str r1,[r0]
    ldr r0,=0x000309a6
    ldr r1,=0x0000df04
    str r1,[r0]
    ldr r0,=0x000309a6
    ldr r1,=0x0000df04
    str r1,[r0]
    ldr r0,=0x000309a6
    ldr r1,=0x0000df04
    str r1,[r0]
    ldr r0,=0x000309a6
    ldr r1,=0x0000df04
    str r1,[r0]
    ldr r0,=0x000309a6
    ldr r1,=0x0000df01
    str r1,[r0]
    mov pc, lr // return to caller.

</pre>
<p>
<hr WIDTH="100%">
<A NAME="customize2"><h1>Customizing the Flash Partitions</h1></A>
<p>
The rrload bootloader sets aside four areas of flash
that it will use for storing the four components it is
designed to manage; 1. the bootloader image, 2. the
bootloader params, 3. the kernel image, and 4. the
filesystem image.
<p>
Each of these components is given a very specific range
of flash addresses that will be involved whenever a
user erases/stores that component. These four ranges
are fixed at the time the rrload bootloader is built
and have been established in a way that will fit most
user needs. However, some users will want to redefine
the way the bootloader uses flash and so provisions
have been made to allow a certain amount of re-configuring.
Specifically, there are two control points we wanted to
provide:
<p>
<UL>
<LI>Change the amount of space set aside for the kernel.
<LI>Change the amount of space set aside for the filesystem.
</UL>
<p>
The default flash memory ranges used by rrload are shown
below:
<pre>
   C5471 EVM:
           kernel image: 0x00040000 - 0x0011ffff
       filesystem image: 0x00120000 - 0x007fffff

  *DSC21 EVM:
           kernel image: 0x00020000 - 0x000bffff
       filesystem image: 0x000c0000 - 0x001fffff

  *DSC24 EVM:
           kernel image: 0x00020000 - 0x000bffff
       filesystem image: 0x000c0000 - 0x001fffff

  OMAP1510 EVM:
       (F160 flash chips)
           kernel image: 0x00020000 - 0x0021ffff
       filesystem image: 0x00220000 - 0x0081ffff
       (F128 flash chips)
           kernel image: 0x00040000 - 0x0023ffff
       filesystem image: 0x00240000 - 0x00f40000

  OMAP710 EVM:
       (F160 flash chips)
           kernel image: 0x00020000 - 0x0021ffff
       filesystem image: 0x00220000 - 0x0081ffff
       (F128 flash chips)
           kernel image: 0x00040000 - 0x0023ffff
       filesystem image: 0x00240000 - 0x00f40000

* Note: These are flash range addresses, since the
        the DSC21 and DSC24 have flash positioned
        at physical address 0x00200000, instead of
        physical address 0x00000000, it means that
        flash address 0x00020000, for example, is
        really physical address 0x00220000.
</pre>
<p>
In order to facilitate changing this partitioning the
user will have to edit the rrload linker script (it is
well documented there) and then rebuild the rrload
bootloader to get a version that reflects your new
partitioning of kernel and filesystem space.
<p>
<b>To give one example:</b>
<p>
Suppose you have the c5471 EVM and you have written a
linux driver of some sort that wants to make use of the
last 0x20000 of the board's flash range. In this case
you don't want the rrload bootloader to touch that
portion of flash yet you know that by default the
rrload bootloader sets aside the whole flash range
extending from flash address 0x00200000 all the way to
the end of flash (0x007fffff) for the filesystem.  And
you know that even if you only use a fraction of that
space to store your linux filesystem the whole area is
essentially off limits to anything else since any
rrload erase operation requested for the filesystem
area will take out the whole range, not just the small
part actually used at the moment.
<p>
What you want in this scenario is to re-configure the
bootloader so that it treats the filesystem storage
as extending from 0x00200000 to 0x007dffff. That will
leave the remaining 0x20000 bytes untouched by the
rrload filesystem store/erase operations.
<p>
To accomplish this you will want to edit the c5471
linker script:
<p>
<pre>
    dsplinux/c5471/rrload/ld.c5471.script
</pre>
<p>
There are two lines in that file that we can change in
order to re-partition the flash is viewed by rrload.
The two lines are
<pre>
  FlashFileSysStart = 0x0;
  FlashFileSysEnd = 0x0;
</pre>
Documentation Inside that file describes the use of both
of these. In our example here, all we need to do is change
the one line from this:
<pre>
  FlashFileSysEnd = 0x0;
</pre>
...to this instead. Then rebuild the bootloader.
<pre>
  FlashFileSysEnd = 0x007dffff;
</pre>
<p>
For reference the snippet of documentation from that
file has been reproduced below:
<pre>
+----------doc snippet from ld.c5471.script---------------+
|                                                         |
|  When a user requests that rrload erase the             |
|  filesystem component, how does it know what range of   |
|  flash to actually erase? The answer is that the        |
|  internal source code defines the flash memory range    |
|  that each of the components will occupy (components    |
|  such as the bootloader itself, the bootloader          |
|  params, the kernel and the filesystem).                |
|                                                         |
|  The filesystem storage always follows the range set    |
|  aside for the kernel image storage which means that    |
|  if the kernel you store is significantly less than     |
|  the space set aside for it you will have a large pad   |
|  between the actual stored kernel image and the start   |
|  of the filesystem image. And likewise, if you have     |
|  kernel that is too large for the space set aside       |
|  then you will collide with the space set aside for     |
|  the filesystem. So...                                  |
|                                                         |
|  -- The Controls Offered --                             |
|                                                         |
|  The rrload linker script offers the user the ability   |
|  to override the internal location of the filesystem    |
|  and move the range of address that are set aside to    |
|  store it. This then becomes the new default for all    |
|  filesystems downloaded and stored to flash and         |
|  becomes the new default used when the user requests    |
|  rrload to erase the filesystem range. The two          |
|  controls offered to the user are FlashFileSysStart     |
|  and FlashFileSysEnd.  Each can be adjusted             |
|  independently and if either is set to 0x0 then this    |
|  turns off the override for that control and allows     |
|  the system to resort to the internal factory default   |
|  for that value.                                        |
|                                                         |
|  --FlashFileSysStart--                                  |
|                                                         |
|  This setting also influences the size of the           |
|  filesystem storage area as well as the kernel          |
|  storage area. If you make the FlashFileSysStart        |
|  address lower than the internal factory default then   |
|  you will be increasing the filesystem storage area     |
|  and decreasing the kernel storage area that proceeds   |
|  it. And likewise if you increase the FlashFileSysStart |
|  address beyond the internal factory default then you   |
|  will be decreasing the filesystem storage area and     |
|  increasing the kernel storage area.                    |
|                                                         |
|  --FlashFileSysEnd--                                    |
|                                                         |
|  If you redefine the FlashFileSysEnd address then you   |
|  can control the high address of the flash range        |
|  involved in the storage set aside for the filesystem   |
|  and likewise sets the end of the range effected by a   |
|  user request to erase the flash component. Changing    |
|  this number has no effect on the amount of storage     |
|  set aside for the kernel which proceeds the filesystem |
|  storage area.                                          |
|                                                         |
|  -- Some Rules When Picking Values --                   |
|                                                         |
|  Legal values for FlashFileSysStart is any value that   |
|  begins on a flash block erase boundary.  For           |
|  this platform that would be numbers such as            |
|  0x00040000, 0x00060000, 0x00080000, etc, since the     |
|  erase unit size of our flash is 128Kbytes (2*64; two   |
|  chips interleaved).                                    |
|                                                         |
|  Legal values for FlashFileSysStart is any value that   |
|  ends on a flash chip erase block boundary.  For this   |
|  platform that would be numbers such as 0x00003fff,     |
|  0x00005fff, 0x00007fff, etc, since                     |
|                                                         |
|  -- Ramifications to your XIP Kernel/FS Builds --       |
|                                                         |
|  Don't forget that the range of address set asided      |
|  for storing filesystem images has a header reserved    |
|  at the start of the range used for rrload meta-data    |
|  meaning that the first address actually available      |
|  for the user bits of a filesystem image are            |
|  FlashFileSysStart+0x20. See the BSPCONF_FILESYS_START  |
|  in the asm/arch/memconfig.h file. This only applies    |
|  however if you are creating an XIP kernel/filesystem   |
|  build since otherwise the BSPCONF_FILESYS_START will   |
|  be set to a SDRAM address and not a flash address and  |
|  doesn't apply to  this discussion.                     |
|                                                         |
|  -- Some Examples --                                    |
|                                                         |
|  If FlashFileSysStart is set to 0x00080000 then the     |
|  earliest location I could use for my downloaded XIP    |
|  filesystem is 0x00080020. This would honor the         |
|  reserved space mentioned.  This FlashFileSysStart      |
|  setting would allow the kernel images stored in        |
|  flash to extend to address 0x00080000-1.  And for      |
|  XIP Kernel/FS builds, the following applies...         |
|  e.g. `mkimage --LAddr 00080020 romdisk.img             |
|  romdisk.img.rr which is used when the xconfig          |
|  session has 0x00080020 value defined for               |
|  BSPCONF_FILESYS_START.                                 |
|                                                         |
|  If FlashFileSysStart is set to 0x00120000 then the     |
|  earliest location I could use for my downloaded XIP    |
|  filesystem is 0x00120020. This would honor the         |
|  reserved space mentioned.  This FlashFileSysStart      |
|  setting would allow the kernel images stored in        |
|  flash to extend to address 0x00120000-1.  And for      |
|  XIP Kernel/FS builds, the following applies...         |
|  e.g. `mkimage --LAddr 00120020 romdisk.img             |
|  romdisk.img.rr which is used when the xconfig          |
|  session has 0x00120020 value defined for               |
|  BSPCONF_FILESYS_START.                                 |
+---------------------------------------------------------+
</pre>
<p>
</body>
</html>