Flameman/walnut



amcc/ibm walnut ppc405gp

= walnut - IBM PPC405GP EVB =

Overview
The board consists of:

the real time clock chip is??? there ia chip but dunno about
 * CPU PowerPC 405GP running at 200Mhz
 * RAM PC133 SDRAM slot, currently, only supports single sidded DIMMs
 * LAN On-chip 405GP ethernet, board doesn't have an ethernet MAC address (the monitor/bootloader is able to fix it)
 * UART 2xDCE serial port, speeds up to 230k, only tested to 115200bps
 * PCI for pci slots, keyed for 5V only cards
 * ROM 512k of boot flash, AMD 29LV040B (amd29lv040b.pdf), socketed
 * POWER the board need ATX power
 * System PCB  ATX board size, 310x250mm
 * RTC [[Media:ibm-walnut-rtc.pdf|DS1743]], Y2KC real-time clock/calendar 8k x 8 nonvolatile static RAM
 * RTC-power-retention [[Media:ibm-walnut-rtc-power-retention.pdf|DS9034PCX]]
 * RAM 128M PC133 SDRAM DIMM
 * FIRMWARE ibm-evb-mon (horrible), it has been replaced by uboot
 * CPLD 2x altera [[Media:ibm-walnut-cpld.pdf|EPM7128S]] (dunno used for)

apps, theorically

 * Develop embedded code on an AMCC 440GP Processor.
 * You can load QNX or UBOOT -- take your pick. VxWorks? uC/OS-II? Its a matter of preference. Its entirely up to you.
 * Monitor program on COM1 using a communication program (like Window's Hyperterminal)
 * Similarly, a dumb terminal can be used -- set to the correct parameters described below.
 * Communication parameters are 9600 baud, 8 bits, no parity and no handshake.
 * Upon power up, you can gain control to the configuration of the eval board via the "console" communication program.
 * Intial power on will show the System Info of the eval board (see pics)
 * IBM 440GP Power PC
 * CPU speed -- 400 MHz
 * PLB speed -- 133 MHz
 * PCI speed -- 100 MHz

url
http://www.openqnx.com/index.php?name=News&file=article&sid=385

http://www.appliedmicro.com/MyAMCC/jsp/public/productDetail/product_detail.jsp?productID=PPC440gp

http://www.appliedmicro.com/MyAMCC/retrieveDocument/PowerPC/440GP/PPC440GP_DS2006.pdf

http://www.appliedmicro.com/MyAMCC/retrieveDocument/PowerPC/440GP/PPC440GP_PB2003.pdf

http://fixunix.com/embedded/5012-no-u-boot-prompt-ppc440gp.html

AMCC PowerPC Single Board Computer Modules
In 2004 AMCC licensed the PowerPC 4xx system-on-a-chip design from IBM. AMCC began offering products based on the PowerPC 405 product line and has expanded the product line to include the PowerPC 440 family of products. Each family includes a PowerPC core at the center of a set of integrated peripherals. This makes for a highly scaleable architecture that can be effectively targeted at vertical market applications. As with all Embedded Planet Single Board Computer Modules the AMCC PowerPC products include a firmware suite. Embedded Linux and VxWorks BSPs are available to accelerate development.

Select a product below to see how Embedded Planet AMCC PowerPC solutions can accelerate your time-to-market.

If you have any questions about how Embedded Planet can assist with AMCC PowerPC Solutions please contact us and one of our expert sales engineers will assist you.

cpu
A fast, flexible solution for embedded developers.

General Description The AMCC PowerPC 405GP and 405GPr family of 32-bit RISC processors is designed to provide a flexible, fast time-to- market hardware solution to satisfy the demands of high-performance embedded applications. Implemented in the scalable PowerPC architecture, the 405GP and 405GPr processors maintain code compatibility with other PowerPC processors for ease in migration and faster time-to-market. An optimized balance of performance, low power, and features makes them ideal solutions for communication, data storage, and pervasive computing applications.

The 405GP and 405GPr processors support speeds of up to 266MHz and 400MHz respectively. Both incorporate a rich mix of features, such as a PCI interface, an SDRAM Controller, a 64-bit on-chip CoreConnect bus, Ethernet and other on-chip peripheral support, and the IBM CodePack™ code compression engine. In addition, power management features, a small form factor, and low power consumption make the AMCC 405 processor family an ideal platform for applications ranging from networking to video.

Highlights


 * High-performance, low-power processors for the most demanding embedded applicationsPowerPC 405GP/405GPr Embedded Processors deliver up to 400MHz performance and a rich mix of features for Internet, communication, data storage, consumer, and imaging applications
 * Includes on-chip SRAM with single-cycle access for faster processing in data-intensive applications, such as routers and switches
 * Supports full application-code compatibility with all other PowerPC® processors for seamless migration
 * Uses the award-winning 64-bit IBM CoreConnect™ high-performance on-chip bus
 * Offers a wide array of small-footprint- package options for high-density applications, such as telecommunications devices
 * Employs the IBM CodePack™ code compression core to reduce system memory requirements and cost

Features


 * On-chip SDRAM Controller
 * o Contains separate 32-byte read and 128-byte write buffers
 * o Programmable address mapping
 * External Peripheral Controller
 * o Supports ROM, EPROM, SRAM
 * o Flash and slave peripheral I/O devices
 * o 8-, 16-, 32-bit external data bus width
 * o Programmable address mapping
 * External Bus Master Controller - Allows external masters to access SDRAM and PCI
 * DMA Controller
 * o 4 independent channels
 * o Supports transfers between SDRAM, PCI, internal UARTs, and devices on the external peripheral bus
 * PCI Interface
 * o 32-bit PCI V2.2 compatible
 * o Synchronous and asynchronous operation
 * o Internal PCI arbiter supports six PCI masters
 * o Supports external arbitration
 * On-chip Ethernet Support
 * o 10/100 MAC
 * o Dedicated DMA controller
 * CodePack Decompression
 * o Stores instructions in memory in compressed format
 * o Improves code density by up to 40%
 * Other On-chip Peripherals
 * o 2 serial ports
 * o Master and slave IIC controller
 * o Up to 24 general purpose I/Os
 * o Interrupt controller including up to 13 external interrupts

WindRiver VxWorks
walnut_target(1)

walnut - IBM PPC405GP EVB

IBM PPC405GP EVB

INTRODUCTION

This reference entry provides board-specific information necessary to run VxWorks for the walnut (IBM PPC405GP) BSP. Before using a board with VxWorks, verify that the board runs in the factory configuration by using vendor-supplied ROMs and jumper settings and checking the RS-232 connection. This BSP supports the PowerPC 405GP Rev D and Rev E parts. Rev B and Rev C support is deprecated; support remains as in original release, but has not been validated nor upgraded for this release. Rev A parts are no longer supported with this release.

Boot ROMs The IBM 405GP Evaluation Board uses a single VxWorks-supplied AMD Am29F040 ROM (total 512KB). Install the ROM as follows:

ROM Socket ---    -    U27

The BSP supports the NVRAM (Dallas Semiconductor DS1743) on the walnut board. The boot parameters will be preserved when the system is powered off.

Jumpers Not applicable.

FEATURES

Supported Features The following features are supported in this release: - MMU on the PPC405GP processor (MMU_BASIC only). - System Timer (uses 405GP PIT hardware timer) - Auxiliary Timer (uses 405GP FIT hardware timer) - Watchdog Timer (uses 405GP WDT hardware timer) - Both 405GP integrated 16550-style serial ports - 405GP integrated Universal Interrupt Controller (UIC) - MAL/EMAC (integrated Memory Access Layer and 10/100 Ethernet MAC) - 405GP PCI controller - AMD 79C97x family of Ethernet controller (using ln97xEnd driver) - Allied Telesyn 2450T adapter (AMD 79C970) has been tested - Allied Telesyn 2700TX adapter (AMD 79C972) has been tested - other adapters with the same AMD controller may also work. - SDRAM autoconfiguration (the default 32MB SDRAM DIMM can be replaced    with      up to a 128MB DIMM) using IIC to read the DIMM SEEPROM - ECC SDRAM - NVRAM (Dallas Semiconductor DS1743) - Real-time clock (Dallas Semiconductor DS1743) using ds1643rtc.c driver - JTAG RISCWatch bootrom flash programming tool

HARDWARE DETAILS

This section documents the details of the device drivers and board hardware elements.

Devices The chip drivers used by this BSP are: It also provides DCR access routines for the following functional units: - IBM DMA controller - IBM external bus controller - IBM Memory Access Layer (MAL) - IBM SDRAM controller - IBM Universal Int Controller (UIC)

Memory Maps This BSP supports MMU on the PPC405GP processor. Memory is mapped using a    fixed page size of 4K.

The sysPhysMemDesc[] array in sysLib.c is used to initialize the Page Table Entry (PTE) array used by the MMU to translate addresses with single page (4k) granularity. Address translations for local RAM, memory mapped PCI bus, memory mapped IO space and local PROM/FLASH are set here. PTEs are held in a 2-level page table. There is one Level 1 page table and several Level 2 page tables. The size of the Level 1 table is 4K and the size of    each Level 2 page table is 8K. Each Level 2 table can map up to 4MB of    contiguous memory space.

Calculating size of page table required For the following memory map we can calculate the page table size required as follows:

Memory Area   Address Range Mapped   Size  Number of Level 2 pages ---    Local Memory   0 - Ram size           32MB  8 PCI Memory    0x80000000-0x83FFFFFF  64MB  16 PCI IO Regn 1 0xE8000000-0xE800FFFF  64K   1 PCI IO Regn 2 0xE8800000-0xE88FFFFF  1MB   1 PCI CFG       0xEEC00000-0xEEC00FFF  4K    1 PCI IACK      0xEED00000-0xEED00FFF  4K    0 * PP Bridge     0xEF400000-0xEF400FFF  4K    1 UART IO Space 0xEF600000-0xEF600FFF  4K    0 * NVRAM Space   0xF0000000-0xF0001FFF  8K    1 Flash         0xFFF80000-0xFFFFFFFF  512K  1

* included in previous L2 page

Total # of L2 pages = 30 Total Memory Required for page table = 30 * 8 + 4 = 244 K.

By default, to increase performance the instruction MMU (IMMU) is turned off. In this case, instruction cacheability is controlled by ICCR (which by    default is set to cache all RAM). The IMMU can be re-enabled by defining USER_I_MMU_ENABLE in config.h.

Serial Configuration The default configuration of the serial ports are 9600bps, 8 data bits, no    parity, 1 stop bit.

Network Configuration The Enhanced Network Driver (END) used with the integrated EMAC Ethernet core is "ibmEmacEnd": Note that the boot device name is now "emac", rather than "ibmEmac". The EMAC works at either 10Mbps or 100Mbps. EMAC gets the results of the PHY's auto-negotiation process over the MII interface. board. This controller uses the ln97xEnd driver provided with VxWorks.

The Ethernet hardware address is configurable at run-time. The first three bytes of the address are always assumed to be 0x0004AC (IBM) and the last three bytes are configurable and stored in NVRAM at address 0xF0000500. To    make the ethernet hardware address match the address printed on the decal attached to the Walnut board use the following example as a guide.

Ethernet hardware address on the Walnut board decal: 0004AC3E4B22 - boot VxWorks - execute the following command from the shell:

sysLanIbmEmacEnetAddrSet 0x00, 0x04, 0xAC, 0x3E, 0x4B, 0x22

Supported BootRom builds The following bootrom file types are supported in this release. When using a Rev B or Rev C processor (which are deprecated), the patch405b.exe or    patch405c.exe tool must be run on the entire ELF file. If a compressed bootrom is built, this is not possible.

bootrom_uncmp     (405GP Rev B (deprecated), C (deprecated), D, E)     bootrom_uncmp.hex  (405GP Rev B (deprecated), C (deprecated), or D, E)     bootrom            (405GP Rev D, E only) bootrom.hex       (405GP Rev D, E only)

** Note: bootrom builds are only supported through the command line makefiles -- do not use the project mechanism to build a boot ROM.

For PPC405GP_REVB (deprecated):

A batch file has been provided that will post-process the bootrom_uncmp file. After bootrom_uncmp is built, run the bootrrb.bat file. bootrrb.bat will modify bootrom_uncmp and will create a new bootrom_uncmp.hex.

For PPC405GP_REVC (deprecated):

A batch file has been provided that will post-process the bootrom_uncmp file. After bootrom_uncmp is built, run the bootrrc.bat file. bootrrc.bat will modify bootrom_uncmp and will create a new bootrom_uncmp.hex.

For PPC405GP_REVD_OR_E:

It is not necessary to post-process the bootrom files when using the 405GP Rev D or E processor.

For all processor revisions:

The standard uncompressed ROM and ROM-resident project configuration are not supplied because they will not fit in the bootrom.

Creating a bootrom, and bringing up vxWorks Create a bootrom by either

a) Rebuilding bootrom_uncmp.hex image and programming it into an     AMD 29F040 flash part using the following steps:

- For PPC405GP_REVD_OR_E - make bootrom_uncmp.hex or bootrom.hex

b) If you have a JTAG RISCWatch processor probe, you can use        vx_rw_flash.cmd to program the flash part (see below).

Connect a terminal or terminal emulator to the board (the 9 pin connector    closest to the printed circuit board). Emulator parameters should be set to    9600bps, 8 data bits, no parity, 1 stop bit. Power-up the board, you should get an error because the default boot line in config.h is not 100% correct for your environment. Type in new configuration parameters using the bootrom menu (set boot device : emac). Your new configuration will be    stored in the NVRAM.

Workbench bootrom flash programming utility a) Install the WindRiver ICE and power it on.

Connect the JTAG interface cable from the Wind River ICE to the PPC405GP board JTAG connector (J24 located on the CPU card). When all of the connections have been made, power up the target board and create a Wind River ICE connection in Workbench.

b) Configure the Workbench connection.

When creating the connection, specify the PPC405GP CPU. Enter the IP address of the Wind River ICE when requested.

c) Load the proper PPC405GP register setting for WindRiver ICE.

Once you have connected the probe to the CPU, right-click on the connection in the target manager and attach to the CPU core. At     this point, you can go to the main Workbench Window tab at the top of the view and select "show view". Browse the view list and select OCD Command Shell. This launches the original BKM command shell. Navigate to the target manager and right-click on core(405GP). Select the reset tab. You can now put the register file provided by            the installation in "play register file" (for example,              registers/PowerPC/4xx/IBM/405gp.reg). Reset with IN then click the reset download button. You have now loaded the target board with enough settings to program the boot ROM. Close the Reset and Download window after the register file playback finishes. Select "Window > show view" again and select Flash Programmer.

d) Converting the bootrom.hex file to bootrom.bin.

Select the Add/Remove tab in the flash programmer. Click "convert file" and navigate to the boot loader project you created previously e.g. WindRiver\workspace\PPC405BootProj\bootrom.hex. Select the project. The start address should be 0x0 and the end address should be set to 0xffffffff. Click "convert and add" to convert the file. At this point, the file is added to the list. Click on the start address entry (should be 0x0) and change it to 0xfff80000. The file is now ready for programming.

e) Program the PPC405GP flash.

"Erase/Program".

Go to OCD command shell and type IN. Be sure this returns the BKM

RISCWatch bootrom flash programming utility An IBM RISCWatch based command file (vx_rw_flash.cmd) is provided that will program bootrom_uncmp.hex into the AMD Am29F040 flash part on the Walnut board. A RISCWatch JTAG processor probe and RISCWatch software version 4.5 or newer is required to use this utility.

NOTE

The vx_rw_flash.cmd utility may need modification if you use a different SDRAM DIMM than was shipped with the Walnut board (see notes inside    vx_rw_flash.cmd).

To use this utility, - make bootrom_uncmp via the command line interface (not with the IDE). - Run the bootrr_.bat batch file for the correct processor revision. This step will create a patched version of bootrom_uncmp.hex NOTE: The manual step of adding the branch instruction to     bootrom_uncmp.hex is NOT necessary if using this utility! - Start IBM JTAG RISCWatch - Make sure that the RISCWatch search path is set up to find files in the Walnut BSP directory. One way to do this is to execute the following RISCWatch command: srchpath add c:\WR\VxWorks\target\config\walnut - Execute the following command to start the flash programming process. This example will place the bootrom_uncmp.hex file into the flash. exec vx_rw_flash.cmd {"bootrom_uncmp.hex"}

SPECIAL CONSIDERATIONS

PowerPC 405GP Rev A (PVR = 0x40110000) This initial hardware sample is no longer supported.

PowerPC 405GP Rev B (PVR = 0x40110040) errata There are errata in the 405GP Rev B chip that affect the operation of this Board Support Package. You should familiarize yourself with them. A current 405GP errata list is available from the PowerPC Technical support group (ppcsupp@us.ibm.com). To avoid 405GP Rev B errata a tool patch405b.exe has been included. This tool searches an ELF executable file (output of the    linker) for certain patterns of instructions related to the above errata. If it finds a potential problem, it uses reserved space provided by    patchtblb.s to create a "patch" which will avoid the errata. The patch table is allocated inside of sysALib.s because it includes patchtblb.s.

If you are using a 405GP Rev B be sure to define PPC405GP_REVB in config.h.

PowerPC 405GP Rev C (PVR = 0x40110082) errata There are errata in the 405GP Rev C chip that affect the operation of this Board Support Package. You should familiarize yourself with them. A current 405GP errata list is available from the PowerPC Technical support group (ppcsupp@us.ibm.com). To avoid 405GP Rev C errata a tool patch405c.exe has been included. This tool searches an ELF executable file (output of the    linker) for certain patterns of instructions related to the above errata. If it finds a potential problem, it uses reserved space provided by    patchtblc.s to create a "patch" which will avoid the errata. The patch If you are using a 405GP Rev D be sure to define PPC405GP_REVD_OR_E in    config.h.

PowerPC 405GP Rev E (PVR = 0x40110145) errata There are errata in the 405GP Rev E chip that affect the operation of this Board Support Package. You should familiarize yourself with them. A current 405GP errata list is available from the PowerPC Technical support group (ppcsupp@us.ibm.com).

If you are using a 405GP Rev E be sure to define PPC405GP_REVD_OR_E in    config.h.

PowerPC 405GPr Rev B (PVR = 0x50910951) errata There are errata in the 405GPr Rev B chip that affect the operation of this Board Support Package. You should familiarize yourself with them. A current 405GPr errata list is available from the PowerPC Technical support group (ppcsupp@us.ibm.com).

If you are using a 405GPr Rev B be sure to define PPC405GPR_REVB in    config.h.

BIBLIOGRAPHY

Please refer to the following documents for further information on the Walnut board.

PowerPC 405 Reference Board Manual located at    405GP_GPR/PPC405GP_EBM2006__v1_00.pdf obtained from http://www.amcc.com (also on the PowerPC Embedded Processors, Cores, and Tools CDROM)

405GP_settings.pdf included in this BSP.

SEE ALSO

VxWorks Programmer's Guide: Configuration, VxWorks Programmer's Guide: Architecture Appendix

original firmware
netbsd-guide says "Do not use the plain ELF kernel as the file provided to the firmware, use the ``netbsd.img file (which is in the format the firmware expects). Of course, you should put the matching ``netbsd as /netbsd on your root file system, otherwise some kernel grovellers won't work"

what is the binary format expected by the original firmware ?

myboard's firmware (uboot) is now expecting binaries made this way: objcopy --gap-fill=0xff -O binary app.elf app.bin

dht-walnut jtag pinout
NOTE


 * Walnut: JTAG Pin Out Connector Specifications for walnut-PPC405GP
 * AMCC-PPC4xx: JTAG Pin Out Connector Specifications for AMCC PPC 44X, 40X (4XX) Processors: 405EP, 405GP, 405GPR, 440GP, 440EP, 440GX, 440GR, 440EPX, 440GRX, 440SP, 440SPE

Pin Out description


 * TDO=JTAG Test Data Out
 * TDI=JTAG Test Data In
 * TRST=JTAG Test Reset
 * TCK=JTAG Test Clock
 * TMS=JTAG Test Mode Select
 * *NC*=not connected, used as cable reference
 * nc=simply not connected
 * SRESET=Soft-Reset
 * HRESET=Hard-Reset
 * KSTP_OUT=?
 * CKSTP_IN=?
 * Vcc=board ref voltage, 3V

firmware replacing
see dht-walnut "recover from a breakage" ... using that procedure you will be able to replace the ibm/amcc-walnut original firmware with uboot

boot from flash
Media:ibm-walnut-uboot.tgz|ibm-walnut-uboot.tgz please contact me flamemaniii@gmail.com

boot from ram
[[Media:ibm-walnut-uboot-ramboot.tgz|ibm-walnut-uboot-ramboot.tgz]]

ELF Header: Magic:  7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 Class:                            ELF32 Data:                             2's complement, big endian Version:                          1 (current) OS/ABI:                           UNIX - System V  ABI Version:                       0 Type:                             EXEC (Executable file) Machine:                          PowerPC Version:                          0x1 Entry point address:              0x400100 Start of program headers:         52 (bytes into file) Start of section headers:         561848 (bytes into file) Flags:                            0x8000, relocatable-lib Size of this header:              52 (bytes) Size of program headers:          32 (bytes) Number of program headers:        3 Size of section headers:          40 (bytes) Number of section headers:        26 Section header string table index: 23

walnut# tftpboot 400000 uboot-ram.img walnut# go 400100

adding promise chip
looking for promise pATA pci controller: to be tested


 * found promise fasttrak66 with promise PDC20262 (dht-walnut has PDC20265)



about the missing chip
"ibm walnut" has not, but the "dht walnut" mounts "promise pATA chip" called "PROMISE PDC20265", that is an ASIC 128 Pin PQFP, featuring PCI bus ATA/ATAPI controller chip which supports complete UDMA/100 specifications.

Host Bus Interface


 * 32-bit PCI interface compliant to PCI Rev 2.2
 * Up to 33MHz bus speed & 133MB/sec burst data transfer rate
 * Co-exists with built-in IDE channels or other SCSI controllers

Ultra ATA/100 Interface


 * Supports Ultra ATA/100 specification of 100MB/sec transfers with CRC error-checking
 * Support two independent IDE channels & up to four UDMA/100/66/33 or EDIE drives

about Promise
Promise is a company that is known for their dedication to IDE hard drive controllers since the days of 'EIDE' or 'enhanced IDE' had a pretty hard time when chipset makers as Intel or VIA started to integrate IDE-controllers into their chipsets.

People simply didn't need an extra hard drive controller unless they wanted to use SCSI. Each time when a new IDE-specification had been released however, Promise was able to supply a product that would upgrade current systems to the latest IDE-standards.

This was the case with 'ATA33', a IDE controller spec that offers up to 33 MB/s data transfer rate between the hard drive and the system, which was first introduced with Intel's good old 430TX-chipset in 1997. At that time, people who owned motherboards with 430FX/HX/VX chipsets (supporting only modes up to 22 MB/s) could upgrade their system with a Promise Ultra33 card, enabling ATA33 mode. Today, Intel's 8xx and VIA's latest chipsets support 'ATA66'.

This spec requires new cables between the motherboard and the hard drives, and it's offering up to 66 MB/s data transfer rate. Motherboards with Intel's BX-chipset don't support ATA66 and so Promise could sell their 'Ultra66'-controller to owners of systems with those motherboards.

Now there's one important thing to remember though. Even the fastest IDE drives today can only supply data rates of 30 MB/s when reading the data directly from the disk. Only data that happens to reside in the dedicated read/write cache on the hard drive can be transferred at a higher speed.

The same is valid for writes. Data can be transferred to the drive pretty fast, until the cache is full. Then the write speed rate is again limited by the physical abilities of the hard drive, which today is in the range of 20-30 MB/s. Thus you can hardly ever see any improvement when you switch from ATA33 to ATA66. Especially hard drives with small caches can take only little advantage of ATA66. This does of course not mean that the physical read/write rates of IDE hard drives won't skip the 33 MB/s limitation of ATA33 very soon, so ATA66 does make perfect sense as long as it doesn't come at a too high premium.

Besides the normal IDE-controller cards, Promise is also offering RAID-cards for IDE drives. This article will have a close look at Promise's RAID-controller card with ATA66-support, the 'FastTrak66'.

about RAID
When the average computer user hears the term 'RAID', he either doesn't have a clue what it is altogether, or he might have heard about it in combination with large servers and security issues. Even normal workstations are rarely using RAID, so you might wonder why I am going on about it here.

I also used to put 'RAID' into the world of high-end servers and SCSI-systems, so that it sounded pretty weird to me, when I heard of IDE-RAID for the first time sometime in 1998. However, I finally had to find out that I had been wrong. Once RAID is affordable, it also makes sense in a lot of average systems.

The definition or 'invention' of RAID goes back some 12 years. In a 1988 publication, A Case for Redundant Arrays of Inexpensive Disks (RAID), three University of California-Berkeley researchers (David Patterson, Randy Katz, and Garth Gibson) proposed guidelines for these arrays. The idea was to use 'inexpensive' hard drives to create a large, fast and reliable/secure mean of data storage. If you want to learn more about RAID, I would suggest to read the excellent white paper 'RAID Technology ' from Dell's website. I will only concentrate on the RAID levels offered by Promise's FastTrak66 controller, to keep this article at a reasonable length.

idea of crypt
http://www.saout.de/misc/dm-crypt/ ---> http://www.saout.de/tikiwiki/tiki-index.php

= uboot =

U-Boot Environment Variables
The U-Boot environment is a block of memory that is kept on NAND flash and copied to SDRAM when u-boot starts. It is used to store environment variables which can be used to configure the system. The environment is protected by a CRC32 checksum. It is much like a traditional Linux shell, the U-Boot shell uses environment variables to tailor its operation. The U-Boot commands to manipulate environment variables have the same names as the BASH shell. For instance printenv and setenv behave the same as their BASH shell counterparts.

This section lists the most important environment variables, some of which have a special meaning to u-boot. You can use these variables to configure the behaviour of u-boot to your liking.

For instance, when you have a system with 16 MB RAM, and want to reserve 4 MB from use by Linux, you can do this by adding "mem=12M" to the value of the "bootargs" variable. However, now you must make sure that the initrd image is placed in the first 12 MB as well - this can be done with
 * autoload: if set to "no" (or any string beginning with 'n'), the rarpb, bootp or dhcp commands will perform only a configuration lookup from the BOOTP / DHCP server, but not try to load any image using TFTP.
 * autostart: if set to "yes", an image loaded using the rarpb, bootp, dhcp, tftp, disk, or docb commands will be automatically started (by internally calling the bootm command).
 * baudrate: a decimal number that selects the console baudrate (in bps). Only a predefined list of baudrate settings is available. When you change the baudrate (using the "setenv baudrate ..." command), U-Boot will switch the baudrate of the console terminal and wait for a newline which must be entered with the new speed setting. This is to make sure you can actually type at the new speed. If this fails, you have to reset the board (which will operate at the old speed since you were not able to saveenv the new settings.) If no "baudrate" variable is defined, the default baudrate of 115200 is used.
 * bootargs: The contents of this variable are passed to the Linux kernel as boot arguments (aka "command line").
 * bootcmd: This variable defines a command string that is automatically executed when the initial countdown is not interrupted. This command is only executed when the variable bootdelay is also defined!
 * bootdelay: After reset, u-boot will wait this number of seconds before it executes the contents of the bootcmd variable. During this time a countdown is printed, which can be interrupted by pressing any key. Set this variable to 0 boot without delay. Be careful: depending on the contents of your bootcmd variable, this can prevent you from entering interactive commands again forever! Set this variable to -1 to disable autoboot.
 * bootfile: name of the default image to load with TFTP
 * cpuclk: On some processors, the CPU clock frequency can be adjusted by the user (for example to optimize performance versus power dissipation). On such systems the cpuclk variable can be set to the desired CPU clock value, in MHz. If the cpuclk variable exists and its value is within the compile-time defined limits (CFG_866_CPUCLK_MIN and CFG_866_CPUCLK_MAX = minimum resp. maximum allowed CPU clock), then the specified value is used. Otherwise, the default CPU clock value is set.
 * ethaddr: Ethernet MAC address for first/only ethernet interface (= eth0 in Linux). This variable can be set only once (usually during manufacturing of the board). U-Boot refuses to delete or overwrite this variable once it has been set.
 * eth1addr: Ethernet MAC address for second ethernet interface (= eth1 in Linux).
 * eth2addr: Ethernet MAC address for third ethernet interface (= eth2 in Linux).
 * initrd_high: used to restrict positioning of initrd ramdisk images: If this variable is not set, initrd images will be copied to the highest possible address in RAM; this is usually what you want since it allows for maximum initrd size. If for some reason you want to make sure that the initrd image is loaded below the CFG_BOOTMAPSZ limit, you can set this environment variable to a value of "no" or "off" or "0". Alternatively, you can set it to a maximum upper address to use (U-Boot will still check that it does not overwrite the U-Boot stack and data).

=> setenv initrd_high 00c00000

Setting initrd_high to the highest possible address in your system (0xFFFFFFFF) prevents U-Boot from copying the image to RAM at all. This allows for faster boot times, but requires a Linux kernel with zero-copy ramdisk support.


 * ipaddr: IP address; needed for tftp command
 * loadaddr: Default load address for commands like tftp or loads.
 * loads_echo: If set to 1, all characters received during a serial download (using the loads command) are echoed back. This might be needed by some terminal emulations (like cu), but may as well just take time on others.
 * pram: If the "Protected RAM" feature is enabled in your board's configuration, this variable can be defined to enable the reservation of such "protected RAM", i. e. RAM which is not overwritten by U-Boot. Define this variable to hold the number of kB you want to reserve for pRAM. Note that the board info structure will still show the full amount of RAM. If pRAM is reserved, a new environment variable "mem" will automatically be defined to hold the amount of remaining RAM in a form that can be passed as boot argument to Linux, for instance like that:

=> setenv bootargs ${bootargs} mem=\${mem} => saveenv

This way you can tell Linux not to use this memory, either, which results in a memory region that will not be affected by reboots.


 * oserverip: TFTP server IP address; needed for tftp command.
 * serial#: contains hardware identification information such as type string and/or serial number.

This variable can be set only once (usually during manufacturing of the board). U-Boot refuses to delete or overwrite this variable once it hass been set.


 * silent: If the configuration option CONFIG_SILENT_CONSOLE has been enabled for your board, setting this variable to any value will suppress all console messages. Please see doc/README.silent for details.


 * verify: If set to n or no disables the checksum calculation over the complete image in the bootm command to trade speed for safety in the boot process. Note that the header checksum is still verified.

The following environment variables may be used and automatically updated by the network boot commands (bootp, dhcp, or tftp), depending the information provided by your boot server:


 * bootfile: see above
 * dnsip: IP address of your Domain Name Server
 * gatewayip: IP address of the Gateway (Router) to use
 * hostname: Target hostname
 * ipaddr: see above
 * netmask: Subnet Mask
 * rootpath: Pathname of the root filesystem on the NFS server
 * serverip: see above
 * filesize: Size (as hex number in bytes) of the file downloaded using the last bootp, dhcp, or tftp command.

The real power of environment variable results from the fact that Unix shell like variable expansion is available. For example:

=> setenv ipaddr 192.168.3.71 => setenv serverip 192.168.3.1 => setenv netdev eth0 => setenv hostname testbox => setenv rootpath /opt/eldk/ppc_8xx => setenv ramargs setenv bootargs root=/dev/ram rw => setenv nfsargs 'setenv bootargs root=/dev/nfs rw nfsroot=${serverip}:${rootpath}' => setenv kernel_addr 40040000 => setenv ramdisk_addr 40100000 => setenv flash_ram 'run ramargs addip;bootm ${kernel_addr} ${ramdisk_addr}' => setenv flash_nfs 'run nfsargs addip;bootm ${kernel_addr}' => setenv net_nfs 'tftp 200000 ${bootfile};run nfsargs addip;bootm' => setenv net_ram 'tftp 200000 ${bootfile};run ramargs addip;bootm 200000 ${ramdisk_addr}' Boot Kernel Image in flash with ramdisk in flash: => run flash_ram Boot Kernel Image in flash with root filesystem over NFS: => run flash_nfs Download Kernel Image over network and use root filesystem over NFS: => run flash_ram Download Kernel Image over network with ramdisk in flash: => run flash_ram

U-Boot also allows to store commands or command sequences in a plain text file. Using the mkimage tool you can then convert this file into a script image which can be executed using u-boot's autoscr command. Nevertheless; U-Boot allows to dynamically load and run "standalone" applications, which can use some resources of U-Boot like console I/O functions, memory allocation or interrupt services. U-Boot supports the concept of a splash screen for booting image. If developers would like to learn more, please refer to DENX U-Boot manual.

We will detail how to download firmware (u-boot, Linux kernel and rescue root filesystems) into NAND flash using the tftp command of u-boot via Ethernet.

ram problem
with 2dimms the mobo will not boot if TWO dimms are installed. It is possible that there is a limitation on the diagnostic FW (in the flash) that causes this behavior. Keep in mind, FW is only a diagnostic routine -- nothing more.

If the SDP (I2C interface to detect config of dimms installed) reports that there are 2 dimms -- the diagnostic FW installed gets confused and causes it not to bootup.

You will have to rewrite the code -- and check the SPD on both dimms in your code -- in order for both dimms to be recognized properly.