Subversion Repositories openrisc

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.