Subversion Repositories openrisc_me

Installation of RedBoot on a Target Board using RedBoot's Flash Commands
------------------------------------------------------------------------

These are generic instructions applicable to RedBoot for many platforms.
Details of what you type have been changed to refer specifically to the
nanoEngine hardware, but you should also read the further instructions for
Bright Star Engineering's nanoEngine and SA1110 boards - known as target
"nano" in eCos configuration terms - which follow.

Here's how to install RedBoot, using the redboot images you should find in
        loaders/PLATFORM/
in your installation directory (sizes and dates are just examples):
        431497 Aug  9 15:28 redboot-ram.elf
        184802 Aug  9 15:28 redboot-ram.srec
        433104 Aug  9 15:29 redboot-rom.elf      (not used in this recipe)
        194732 Aug  9 15:29 redboot-rom.srec

Copy the two '.srec' files to /tftpboot or where-ever they have to be for
your TFTP server.

Briefly, we use whatever boot flash image you have in place already (CygMon
or an eCos stub ROM) along with GDB, to execute a RAM based version of
RedBoot.  That is used, in its command-line mode, to fetch a ROM-based boot
image of RedBoot and write it into the flash memory.  "Fetching" the image
means TFTP from a server; the image must be in S-Record format.  We then
reset the target, thus running the newly-installed boot image of RedBoot.
That in turn is used, in its command-line mode, to fetch a RAM-based boot
image of RedBoot and write it into a different area of the flash memory, in
order to make it easier to do the first part (running a RAM-based RedBoot
in order to update the boot block) again in future.

NB: the instructions below refer to a system with 8Mb of flash, at address
0x50000000 in memory.  That address is common to SA11x0 CPUs.

Other boards might have a different start address, such as 0x41000000 and
different flash blocksizes.  RedBoot's startup banner will tell you the
details, if all is functioning correctly.  If the address is different, you
must use different addresses for saving the images into the Flash Image
System (fis).  The command "fis list" will tell you the addresses to use
for the "RedBoot" and "RedBoot[backup]" images, immediately after the "fis
init" command.


Alternatively you can make a plain binary from the redboot-rom.elf and
"blow" that into the boot flash using the means of your choice, as with
previous systems.


1. Load a RedBoot, built for RAM startup, into RAM using existing GDB
   stubs.  Note: do not run it yet!

   % arm-elf-gdb -nw loaders/nano/redboot-ram.elf 

   GNU gdb 4.18-ecos-99r1-991015
   Copyright 1998 Free Software Foundation, Inc.
   GDB is free software, covered by the GNU General Public License, and you are
   welcome to change it and/or distribute copies of it under certain conditions.
   Type "show copying" to see the conditions.  This version of GDB is supported
   for customers of Cygnus Solutions.  Type "show warranty" for details.
   This GDB was configured as "--host=i686-pc-linux-gnu
   --target=arm-elf"...(no debugging symbols found)...
   (gdb) set remotebaud 38400
   (gdb) tar rem /dev/ttyS0
   Remote debugging using /dev/ttyS0
   0x41000838 in ?? ()
   (gdb) load
   Loading section .rom_vectors, size 0x44 lma 0x20000
   Loading section .text, size 0xf06c lma 0x20044
   Loading section .rodata, size 0x19a8 lma 0x2f0b0
   Loading section .data, size 0x474 lma 0x30a58
   Start address 0x20044 , load size 69324
   Transfer rate: 25208 bits/sec.
   (gdb) detach
   Ending remote debugging.
   (gdb) q

2. Execute RedBoot from RAM, and initialize the flash filing system.
       Notes: the key here is the "-o" option which keeps minicom from
       sending junk.
       The magic phrase "$c#63" is important: you must type it in exactly
       thus.  It is the packet which a "continue" command in GDB would send
       to the target.  If you get no response, try "+$c#63" instead.
       The IP and server info comes from BOOTP, which is how this RedBoot
       will start up if the flash does not contain good config info.

   % minicom -o ttyS0

   $c#63
   RedBoot(tm) debug environment - built 07:45:57, Aug  7 2000
   Copyright (C) 2000, Red Hat, Inc.

   RAM: 0x00000000-0x01000000
   FLASH: 0x50000000 - 0x50400000, 32 blocks of 0x00020000 bytes ea.
   IP: 192.168.1.25, Default server: 192.168.1.101
   RedBoot> fi init
   About to initialize [format] FLASH image system - are you sure (y/n)? y
   *** Initialize FLASH Image System
       Warning: device contents not erased, some blocks may not be usable
   ... Erase from 0x503c0000-0x50400000: .
   ... Program from 0x00fb0000-0x00fb0400 at 0x503c0000: .


3. Program RedBoot image into FLASH:
       This expects the file redboot-post.srec (see below) to exist in the
       TFTP server space on the server that answered the BOOTP request.
       It loads into the free flash memory following the boot firmware, at
       address 0x50040000.

   RedBoot> lo -v /tftpboot/redboot-post.srec -b 0x00100000
   Address offset = bf100000
   Entry point: 0x50040044, address range: 0x50040000-0x50051384
   RedBoot> fi cr RedBoot[post] -f 0x50040000 -b 0x00100000 -l 0x20000
   An image named 'RedBoot[post]' exists - are you sure (y/n)? y
   ... Erase from 0x50040000-0x50060000: .
   ... Program from 0x00100000-0x00120000 at 0x50040000: .
   ... Erase from 0x503c0000-0x50400000: .
   ... Program from 0x00fb0000-0x00ff0000 at 0x503c0000: .
   RedBoot> 

****reset the board here, leaving your terminal program connected****

   RedBoot(tm) debug environment - built 07:47:35, Aug  7 2000
   Copyright (C) 2000, Red Hat, Inc.
   
   RAM: 0x00000000-0x01000000
   FLASH: 0x50000000 - 0x50400000, 32 blocks of 0x00020000 bytes ea.
   IP: 192.168.1.25, Default server: 192.168.1.101
   RedBoot> 


4. Install RAM based RedBoot for backup/update:
       Similar considerations apply: redboot-ram.srec must be an S-record
       version of RedBoot built for RAM startup.

   RedBoot> lo -v /tftpboot/redboot-ram.srec
   Entry point: 0x00020044, address range: 0x00020000-0x00030ecc
   RedBoot> fi cr RedBoot[backup] -f 0x50060000 -b 0x20000 -r 0x20000 -l 0x20000
   An image named 'RedBoot[backup]' exists - are you sure (y/n)? y
   ... Erase from 0x50060000-0x50080000: .
   ... Program from 0x00020000-0x00040000 at 0x50060000: .
   ... Erase from 0x503c0000-0x50400000: .
   ... Program from 0x00fb0000-0x00ff0000 at 0x503c0000: .
   RedBoot> 

        You have now updated your board completely.  Phew!



5. To update RedBoot with a new version of RedBoot, it is necessary to run
   a RAM-based version of RedBoot which itself re-writes the ROM-based one,
   because you can't re-write the code that is executing at the time.

   RedBoot> fi lo RedBoot[backup]
   RedBoot> g
   +
   RedBoot(tm) debug environment - built 07:45:57, Aug  7 2000
   Copyright (C) 2000, Red Hat, Inc.
   
   RAM: 0x00000000-0x01000000
   FLASH: 0x50000000 - 0x50400000, 32 blocks of 0x00020000 bytes ea.
   IP: 192.168.1.25, Default server: 192.168.1.101
   RedBoot> 
   
     .. continue with step 3, using whatever your new boot image is called
        in the TFTP-place, in .srec format.


You probably also want to set up then environment with your own IP
addresses and so on.  Recall that this IP address is the one you use for
GDB to talk to the board, not the IP address which the eCos application
will take on (by BOOTP/DHCP or whatever means according to configury as
usual).

   RedBoot> fconfig
   Network debug at boot time: false 
   Use BOOTP for network configuration: false 
   Local IP address: 192.168.1.25 
   Default server IP address: 192.168.1.101 
   GDB connection port: 1000 
   Run script at boot: false 
   RedBoot> 


RedBoot for the nanoEngine/commEngine "nano" Target
---------------------------------------------------

Unlike other targets, the nanoEngine comes equipped with boot firmware
which you cannot modify.  See chapter 5 "nanoEngine Firmware" of the
nanoEngine Hardware Reference Manual (we refer to "July 17, 2000 Rev 0.6")
from Bright Star Engineering.

Because of this, eCos and so Redboot supports only these two startup types:
RAM and POST, rather than the more usual ROM, RAM and optionally POST.

Briefly, the POST-startup RedBoot image lives in flash following the BSE
firmware.  The BSE firmware is configured, using its standard "bootcmd"
parameter, to jump into the RedBoot image at startup.

You can perform the initial load of the POST-startup RedBoot image into
flash using the BSE firmware's "load" command.  This will load, using TFTP,
a binary file and program it into flash in one neat operation.  Because no
memory management is used in the BSE firmware, flash is mapped from address
zero upwards, so the address for the RedBoot POST image is 0x40000.  You
must use the binary version of RedBoot for this, "redboot-post.bin"

This assumes you have set up the other BSE firmware config parameters such
that it can communicate over your network, to your TFTP server.

        >
        >load /tftpboot/redboot-post.bin 40000   
        loading ... erasing blk at 00040000
        erasing blk at 00050000
        94168 bytes loaded cksum 00008579
         done
        >
        > set bootcmd "go 40000"
        > get
        myip = 10.16.19.198
        netmask = 255.255.255.0
        eth = 0
        gateway = 10.16.19.66
        serverip = 10.16.19.66
        bootcmd = go 40000
        >

NB: the BSE firmware runs its serial IO at 9600 Baud; RedBoot runs instead
at 38400 Baud.  You must select the right baud rate in your terminal
program to be able to set up the BSE firmware.

After a reset, the BSE firmware will print
        Boot: BSE 2000 Sep 12 2000 14:00:30
        autoboot: "go 40000" [hit ESC to abort]
and then RedBoot starts, switching to 38400 Baud.

Once you have installed a bootable RedBoot in the system in this manner, we
advice re-installing using the generic method described first in this note
in order that the Flash Image System contains an appropriate description of
the flash entries.


Rebuilding RedBoot from Source
------------------------------

To rebuild RedBoot from source, first locate the configuration export files
for your platform in the eCos source repository.  The RAM and POST startup
configuration exports can usually be found in a directory named "misc" in
the platform HAL in the eCos source repository, named either:
   2164 Nov 29 14:59 misc/redboot_RAM.cfg
   2221 Nov 29 14:59 misc/redboot_POST.cfg
or
   1432 Feb  1 13:27 misc/redboot_RAM.ecm
   1487 Feb  1 14:38 misc/redboot_POST.ecm
Having located these files, copy them say to /tmp, say, for less typing.

To make redboot for RAM startup:
  mkdir redboot.RAM
  cd redboot.RAM
  ecosconfig new nano redboot
  ecosconfig import /tmp/redboot_RAM.ecm
  ecosconfig tree
  make

To build the POST version, in a different build/config directory, just use
the config export redboot_POST.ecm (or .cfg) instead.

The resulting files will be, in each of the POST and RAM startup build
places:
   70456     ..../install/bin/redboot.bin
  433104     ..../install/bin/redboot.elf
   91407     ..../install/bin/redboot.img
  194732     ..../install/bin/redboot.srec

The .elf and .srec files have the obvious relationship to those supplied in
the "loaders/nano" directory in the install.


Cohabiting with POST in Flash
-----------------------------

The configuration export named redboot_POST.ecm configures redboot to build
for execution at address 0x50040000 (or during bootup, 0x00040000).  This
is to allow power-on self-test (POST) code or immutable firmware to live in
the lower addresses of the flash and to run before RedBoot gets control.
The assumption is that RedBoot will be entered at its base address in
physical memory, ie. 0x00040000.  Alternatively, for testing, you can call
it in an already running system by "go 0x50040040" at another RedBoot
prompt, or a branch to that address; the address is where the reset vector
points, and is reported by RedBoot's tftp load command and listed by the
fis list command, amongst other places.

Using the POST configuration enables a normal config option which causes
linking and initialization against memory layout files called "...post..."
rather than "...rom..." or "...ram..." in the include/pkgconf directory,
specifically:
   665 Feb  9 17:57 include/pkgconf/mlt_arm_sa11x0_nano_post.h
   839 Feb  9 17:57 include/pkgconf/mlt_arm_sa11x0_nano_post.ldi
   585 Feb  9 17:57 include/pkgconf/mlt_arm_sa11x0_nano_post.mlt
It is these you should edit if you wish to move that execution address from
0x50040000 in the POST configuration.  Startup type naturally remains ROM
in this configuration.

Because the nanoEngine contains immutable boot firmware at the start of
flash, RedBoot for this target is configured to reserve that area in the
Flash Image System, and to create by default an entry for the POST startup
RedBoot.

  RedBoot> fis list
  Name              FLASH addr  Mem addr    Length      Entry point
  (reserved)        0x50000000  0x50000000  0x00040000  0x00000000
  RedBoot[post]     0x50040000  0x00100000  0x00020000  0x50040040
  RedBoot[backup]   0x50060000  0x00020000  0x00020000  0x00020040
  RedBoot config    0x503E0000  0x503E0000  0x00010000  0x00000000
  FIS directory     0x503F0000  0x503F0000  0x00010000  0x00000000
  RedBoot> 

The entry "(reserved)" ensures that the FIS cannot attempt to overwrite the
BSE firmware, thus ensuring that the board remains bootable and recoverable
even after installing a broken RedBoot image.


Special Redboot Commands
------------------------

The nanoEngine/commEngine has one or two Intel i82559 Ethernet controllers
installed, but these have no associated serial EEPROM in which to record
their Ethernet Station Address (ESA, or MAC address).  The BSE firmware
records an ESA for the device it uses, but this information is not
available to RedBoot; we cannot share it.

To keep the ESAs for the two ethernet interfaces, two new items of RedBoot
configuration data are introduced.  You can list them with the RedBoot
command "fconfig -l" thus:

  RedBoot> fconfig -l
  Run script at boot: false 
  Use BOOTP for network configuration: false 
  Local IP address: 10.16.19.91 
  Default server IP address: 10.16.19.66
  Network hardware address [MAC] for eth0: 0x00:0xB5:0xE0:0xB5:0xE0:0x99
  Network hardware address [MAC] for eth1: 0x00:0xB5:0xE0:0xB5:0xE0:0x9A
  GDB connection port: 9000 
  Network debug at boot time: false 
  RedBoot> 

You should set them before running RedBoot or eCos applications with the
board connected to a network.  The fconfig command can be used as for any
configuration data item; the entire ESA is entered in one line.


Memory Maps
-----------

The first level page table is located at physical address
0xc0004000.  No second level tables are used.

NOTE
The virtual memory maps in this section use a C and B column to
indicate whether or not the region is cached (C) or buffered (B).

Physical Address Range     Description
-----------------------    ----------------------------------
0x00000000 - 0x003fffff    4Mb FLASH (nCS0)
0x18000000 - 0x18ffffff    Internal PCI bus - 2 x i82559 ethernet
0x40000000 - 0x4fffffff    External IO or PCI bus
0x80000000 - 0xbfffffff    SA-1110 Internal Registers
0xc0000000 - 0xc7ffffff    DRAM Bank 0 - 32Mb SDRAM
0xc8000000 - 0xcfffffff    DRAM Bank 1 - empty
0xe0000000 - 0xe7ffffff    Cache Clean

Virtual Address Range    C B  Description
-----------------------  - -  ----------------------------------
0x00000000 - 0x001fffff  Y Y  DRAM - 8Mb to 32Mb
0x18000000 - 0x180fffff  N N  Internal PCI bus - 2 x i82559 ethernet
0x40000000 - 0x4fffffff  N N  External IO or PCI bus
0x50000000 - 0x51ffffff  Y Y  Up to 32Mb FLASH (nCS0)
0x80000000 - 0xbfffffff  N N  SA-1110 Internal Registers
0xc0000000 - 0xc0ffffff  N Y  DRAM Bank 0: 8 or 16Mb
0xc8000000 - 0xc8ffffff  N Y  DRAM Bank 1: 8 or 16Mb or absent
0xe0000000 - 0xe7ffffff  Y Y  Cache Clean

The FLASH based RedBoot POST-startup image occupies virtual addresses
0x50040000 - 0x5005ffff.

The ethernet devices use a "PCI window" to communicate with the CPU.  This
is 1Mb of SDRAM which is shared with the ethernet devices that are on the
PCI bus.  It is neither cached nor buffered, to ensure that CPU and PCI
accesses see correct data in the correct order.  By default it is
configured to be megabyte number 30, at addresses 0x01e00000-0x01efffff.
This can be modified - and indeed must be, if less than 32Mb of SDRAM is
installed - via the memory layout tool, or by moving the section
"__pci_window" referred to by symbols CYGMEM_SECTION_pci_window* in the
linker script.

Though the nanoEngine ships with 32Mb of SDRAM all attached to DRAM bank 0,
the code can cope with any of these combinations also; "2 x " in this
context means one device in each DRAM Bank.

  1 x 8Mb = 8Mb     2 x 8Mb = 16Mb
  1 x 16Mb = 16Mb   2 x 16Mb = 32Mb

All are programmed the same in the memory controller.

Startup code detects which is fitted and programs the memory map
accordingly.  If the device(s) is 8Mb, then there are gaps in the
physical memory map, because a high order address bit is not
connected.  The gaps are the higher 2Mb out of every 4Mb.

The SA11x0 OS timer is used as a polled timer to provide timeout
support within RedBoot.


Nano Platform Port
------------------

The nano is in the set of SA11X0-based platforms.  It uses the
arm architectural HAL, the sa11x0 variant HAL, plus the nano
platform hal.  These are components
        CYGPKG_HAL_ARM                  hal/arm/arch/
        CYGPKG_HAL_ARM_SA11X0           hal/arm/sa11x0/var
        CYGPKG_HAL_ARM_SA11X0_NANO      hal/arm/sa11x0/nano
respectively.

The target name is "nano" which includes all these, plus the
ethernet driver packages, flash driver, and so on.


Ethernet Driver
---------------

The ethernet driver is in two parts:

A generic ether driver for Intel i8255x series devices, specifically the
i82559, is devs/eth/intel/i82559.  Its package name is
CYGPKG_DEVS_ETH_INTEL_I82559.

The platform-specific ether driver is devs/eth/arm/nano.  Its package is
CYGPKG_DEVS_ETH_ARM_NANO.  This tells the generic driver the address in IO
memory of the chip, for example, and other configuration details.

This driver picks up the ESA from RedBoot's configuration data - unless
configured to use a static ESA in the usual manner.