Name
Setup — Setting up the IXDP425 board
Overview
In a typical development environment, the IXDP425 board boots from the parallel NOR Flash and runs the RedBoot ROM monitor directly. Applications are then downloaded into RAM and run directly on the board using the command line interface, or for standalone applications, via the debugger arm-eabi-gdb. Alternatively applications can be stored in Flash to be subsequently loaded into RAM for execution. Preparing the board therefore usually involves programming a suitable RedBoot image into flash memory.
The following RedBoot configurations are supported:
Configuration | Description | Use | File |
---|---|---|---|
ROM | RedBoot running from ROM | redboot_ROM.ecm | redboot_ROM.bin |
RAM | RedBoot running from RAM | redboot_RAM.ecm | redboot_RAM.bin |
ROMRAM | RedBoot running from RAM, but contained in the board's flash boot sector | redboot_ROMRAM.ecm | redboot_ROMRAM.bin |
ROM_CFIDE | Same as ROM, but with additional CompactFlash IDE and FAT FS support | redboot_ROM_CFIDE.ecm | redboot_ROM_CFIDE.bin |
ROMRAM_CFIDE | Same as ROMRAM, but with additional CompactFlash IDE and FAT FS support | redboot_ROMRAM_CFIDE.ecm | redboot_ROMRAM_CFIDE.bin |
ROMLE | RedBoot running from ROM configured for little-endian operation | redboot_ROMLE.ecm | redboot_ROMLE.bin |
RAMLE | RedBoot running from RAM configured for little-endian operation | redboot_RAMLE.ecm | redboot_RAMLE.bin |
ROMRAMLE | RedBoot running from RAM and configured for little-endian operation, but contained in the board's flash boot sector | redboot_ROMRAMLE.ecm | redboot_ROMRAMLE.bin |
For serial communications, all versions run with 8 bits, no parity, and 1 stop bit at 115200 baud. RedBoot also supports ethernet communication and flash management.
If the ROM version is to be chosen, then the RAM version is provided to allow for updating the resident RedBoot image in Flash. The ample provision of RAM memory on the board allows the ROMRAM version of RedBoot to be used instead of the standard ROM version which executes directly from Flash.
Initial Installation
Installation with a Flash programmer
This approach to initial installation may be used if a Flash device programmer is available. The IXDP425 Flash is socketed at U22. Although the supplied Flash part is an Intel StrataFlash 28F128J3, any 28FxxxJ3 part may be substituted - RedBoot will use the Common Flash Interface (CFI) to determine the Flash device geometry.
In this mode, the ROM mode RedBoot is programmed into the boot flash at offset 0x00000000.
Installation via JTAG
A JTAG device may also be used to perform initial programming. Some JTAG devices have in-built capabilities that permit programming of the Flash part. Other JTAG devices are able to load a RAM RedBoot image into SDRAM, from where a ROM RedBoot image can then in turn be loaded and then programmed.
If using a JTAG device that supports direct programming of the Flash part, the Flash is usually located at 0x50000000 in the CPU memory map, assuming the JTAG device initialisation has not remapped it elsewhere. It will usually need to first unlocked and then erased before programming.
For other JTAG devices, to load a RAM RedBoot image into SDRAM it will first be required to initialise the memory interface, and in particular configure the SDRAM controller. Consult your JTAG device documentation on how to access IXP425 registers.
One example of a JTAG device capable of direct programming of Flash is the Abatron BDI2000, and in the following sections are the steps required to program RedBoot using it.
Preparing the Abatron BDI2000 JTAG debugger
The BDI2000 must first be configured to allow communication with your local network, and configured with the parameters for interfacing with the target board. The following steps should be followed:
- Prepare a PC to act as a host PC and start a TFTP server on it.
- Connect the Abatron BDI2000 JTAG debugger via both serial and ethernet to the host PC and power it on. Use the serial cable supplied with the BDI2000.
- Install the Abatron BDI2000 bdiGDB support software on the host PC.
Confirm that the XScale firmware is resident in the BDI2000. For example, using the bdisetup utility:
$
bdisetup -v -s
BDI Type : BDI2000 Rev.C (SN: xxxxxxxx) Loader : V1.05 Firmware : V1.08 bdiGDB for XScale Logic : V1.03 XScale MAC : 00-0c-01-96-64-92 IP Addr : 192.168.7.220 Subnet : 255.255.255.0 Gateway : 192.168.7.1 Host IP : 192.168.7.9 Config : /ixdp425.cfgTo upload firmware if needed, follow the procedures in the BDI2000 manual, for example using the bdisetup utility:
$
bdisetup -u -p/dev/ttyS0 -b57 -aGDB -tXSCALE
Connecting to BDI loader Erasing CPLD Programming firmware with ./b20xscgd.108 Erasing firmware flash .... Erasing firmware flash passed Programming firmware flash .... Programming firmware flash passed Programming CPLD with ./xscjed21.103-
Locate the file
ixdp425.cfg
within the BDI2000 software installation. -
Locate the file
regIXP425.def
within the installation of the BDI2000 bdiGDB support software. -
Place the
ixdp425.cfg
file in a location on the PC accessible to the TFTP server. Later you will configure the BDI2000 to load this file via TFTP as its configuration file. -
Similarly place the file
regIXP425.def
in a location accessible to the TFTP server. -
Open
ixdp425.cfg
in an editor such as emacs or notepad and if necessary adjust the path of theregIXP425.def
file in the[REGS]
section to match its location relative to the TFTP server root. Also comment out with a ';' the IP line in the[HOST]
section, or update it to refer to the development PC. Install and configure the Abatron BDI2000 in line with the bdiGDB instruction manual. Configure the BDI2000 to use the
ixdp425.cfg
configuration file at the appropriate point of this process. For example, using the bdisetup utility:$
bdisetup -c -p/dev/ttyS0 -b57 -i192.168.7.220 -h192.168.7.9 -m255.255.255.0 -g192.168.7.1 -f/ixdp425.cfg
Connecting to BDI loader Writing network configuration Configuration passedThe above command uses the first serial port at 57,600 baud to set the BDI2000's IP address to 192.168.7.220, its default TFTP host to 192.168.7.9, the network mask to 255.255.255.0, the default gateway to 192.168.7.1, and the configuration file to load to
/ixdp425.cfg
.
Preparing the IXDP425 board for programming
Follow the steps in this section in order to allow communication between the board and the host PC, and between the board and the JTAG device.
- First you must connect a straight through DB9 serial cable between the high speed serial port labelled UART0 on the board and a serial port on the host computer.
- Start a suitable terminal emulator on the host computer such as minicom or HyperTerminal. Set the communication parameters to 115200 baud, 8 data bits, no parity bit and 1 stop bit with no flow control.
- If using a PCI ethernet card, connect the board to your host PC's LAN with an Ethernet cable.
- If using a PCI ethernet card, you may need to designate the ethernet interface with a new Ethernet MAC address. The RedBoot binary image contains a default address, but each board requires its own unique address. It is advisable to mark each board with its programmed MAC address for future identification.
- Connect the board to the BDI2000 using a 20-pin ARM/Xscale cable from the JTAG/ICE interface connector (J12) to the Target A port on the BDI2000.
- Power up the IXDP425 board. You should see the hex display and various LEDs illuminate.
Connect to the BDI2000's CLI interface via TCP/IP on the standard telnet port 23. The telnet application is suitable for this. You should see usage information followed by the prompt:
Core#0>
Confirm correct connection with the BDI2000 with the reset halt command as follows:
Core#0>
reset halt
- TARGET: processing reset request - TARGET: BDI asserts RESET and TRST - TARGET: BDI removed TRST - TARGET: Bypass check: 0x000000001 => 0x00000001 - TARGET: JTAG exists check passed - Core#0: ID code is 0x19274013 - Core#0: BDI sets hold_rst and halt mode - TARGET: BDI removes RESET - Core#0: BDI sets hold_rst and halt mode again - Core#0: BDI loads debug handler to mini IC - Core#0: BDI clears hold_rst - TARGET: resetting target passed - TARGET: processing target startup .... - TARGET: processing target startup passed Core#0>- Locate the
redboot_ROM.bin
image within theloaders
subdirectory of the base of the eCos installation. -
Copy the
redboot_ROM.bin
file into a location on the host computer accessible to its TFTP server.
Using the BDI2000 to directly program RedBoot into Flash
As previously mentioned, there are two methods of programming a RedBoot image into the parallel NOR Flash via JTAG, depending on the capabilities of the JTAG device. The BDI2000 supports direct programming of the Flash device and so that is the approach described here.
This is a three stage process. The relevant Flash blocks must first be unlocked, then erased, and finally programmed. This can be accomplished with the following steps:
- Connect to the BDI2000 telnet port as before.
Use the following commands in the BDI2000 telnet session to unlock and then erase the relevant Flash blocks that will contain RedBoot.
Core#0>
unlock 0x50000000 0x20000 4
Unlocking flash at 0x50000000 Unlocking flash at 0x50020000 Unlocking flash at 0x50040000 Unlocking flash at 0x50060000 Unlocking flash passed Core#0>erase 0x50000000 0x20000 4
Erasing flash at 0x50000000 Erasing flash at 0x50020000 Erasing flash at 0x50040000 Erasing flash at 0x50060000 Erasing flash passedProgram the RedBoot image into Flash with the following command, replacing
/RBPATH
with the location of the redboot_ROM.bin file relative to the TFTP server root directory:Core#0>
prog 0x50000000
Programming /RBPATH/redboot_ROM.bin , please wait .... Programming flash passed Core#0>/RBPATH/
redboot_ROM.bin binThis operation can take some time.
The RedBoot installation is now complete. This can be tested by powering off the board, disconnecting the JTAG, and then powering on the board again. The RedBoot banner should be visible on the serial port.
flash configuration checksum error or invalid key
This message does not indicate a problem at this stage of installation. It just means that RedBoot Flash configuration has yet to be performed, as described below.
If it proves necessary to re-install RedBoot, this may be achieved by repeating the above process. Alternatively, a new image may be downloaded and programmed into flash more directly using RedBoot's own commands. See the RedBoot documentation for details.
RedBoot Flash configuration
The following steps describe how to initialize RedBoot's Flash configuration. This must be performed when using a RAM RedBoot to program Flash, but is also applicable to initial configuration of a ROM or ROMRAM RedBoot loaded using JTAG or with a Flash device programmer.
Use the following command to initialize RedBoot's Flash Information System (FIS):
RedBoot>
fis init -f
About to initialize [format] FLASH image system - continue (y/n)?y
*** Initialize FLASH Image System ... Erase from 0x50080000-0x50fdffff: ........................................................................................... ... Unlocking from 0x50fe0000-0x50ffffff: . ... Erase from 0x50fe0000-0x50ffffff: . ... Program from 0x0ffd0000-0x0fff0000 to 0x50fe0000: . ... Locking from 0x50fe0000-0x50ffffff: . RedBoot>Now configure RedBoot's Flash configuration with the command:
RedBoot>
fconfig -i
If a BOOTP/DHCP server is not available, then IP configuration may be set manually. The default server IP address can be set to a PC that will act as a TFTP host for future RedBoot load operations, or may be left unset. The following gives an example configuration:
RedBoot>
fconfig -i
Initialize non-volatile configuration - continue (y/n)?y
Run script at boot:false
Use BOOTP for network configuration:false
Gateway IP address:192.168.7.11
Local IP address:192.168.7.222
Local IP address mask:255.255.255.0
Default server IP address:192.168.7.9
Console baud rate:115200
DNS server IP address:192.168.7.11
GDB connection port:9000
Force console for special debug messages:false
Network debug at boot time:false
Update RedBoot non-volatile configuration - continue (y/n)?y
... Unlocking from 0x50fe0000-0x50ffffff: . ... Erase from 0x50fe0000-0x50ffffff: . ... Program from 0x0ffd0000-0x0fff0000 to 0x50fe0000: . ... Locking from 0x50fe0000-0x50ffffff: . RedBoot>
Rebuilding RedBoot
Should it prove necessary to rebuild a RedBoot binary, this is done most conveniently at the command line. The steps needed to rebuild the the ROM version of RedBoot for the IXDP425 are:
$ mkdir redboot_ixdp425_romram
$ cd redboot_ixdp425_romram
$ ecosconfig new ixdp425 redboot
$ ecosconfig import $ECOS_REPOSITORY/hal/arm/xscale/ixdp425/VERSION
/misc/redboot_ROM.ecm
$ ecosconfig resolve
$ ecosconfig tree
$ make
At the end of the build the install/bin
subdirectory should contain
the file redboot.bin
.
The other versions of RedBoot - RAM, ROMRAM or the little-endian variants - may be similarly built by choosing the appropriate alternative .ecm file.
2024-12-10 | Open Publication License |