This is a port of Harhan's StarMON PowerPC bootloader / board bring-up / debug ROM monitor to IBM/AMCC's PPC44x/46x family of processors. This particular source tree is intended to serve as an example to be copied and modified for specific chips, boards or applications: this source tree as it stands supports the PPC440GX SoC and the Ocotea reference board, but it is very easy to modify for other chips and boards. About the name "Star" was our original codename for classic PowerPC (6xx/7xx/74xx) processors, and StarMON was our ROM monitor for that architecture. The architecture implemented by IBM's PPC44x/46x cores is NOT classic PowerPC however, it is a newer architecture called Book-E. Hence our ROM monitor for the Book-E architecture is called Book-E-MON by analogy with how the one for the Star architecture was called StarMON. Design principle With Book-E-MON we went for a more pragmatic approach than we did with StarMON. StarMON tried to make the embedded PPC boards it ran on look like full-blown general purpose computers a la DEC/Sun/etc, and we tried to implement a very comprehensive console and OS booting infrastructure with traditional minicomputer-like disk, tape and Ethernet boot devices. But with Book-E-MON we have come to the realisation that the systems we run on are embedded devices, not minicomputers, hence they don't need to boot like a minicomputer and don't need a ROM monitor that imitates a VAX console. Book-E-MON is designed to give hardware and system software engineers as much direct unobstructed hardware peek and poke access as possible. A major difference between StarMON/Book-E-MON and other popular ROM monitors like Das U-Boot is that all of Harhan's ROM monitors / bootloaders are designed to run without working main RAM. Modern DDR-whatever system RAM designs almost always need complex configuration, tuning and oftentimes actual hardware debug with an oscilloscope before one can store data in that RAM and read it back correctly, and it is a great aid to have a working full-featured interactive console prompt with rich hardware peek and poke capabilities before the main RAM works. This capability is useful on field-deployed units too: since the main RAM is not depended upon for the monitor's own code to run, one can arrange for memory testing on boot and reporting errors instead of a dead hang if it's bad. The monitor's own code executes directly out of flash and is never copied anywhere. (Thanks to the CPU core's instruction cache executing directly out of flash introduces no perceptible performance penalty.) The monitor's data variables and stack are stored in the on-chip SRAM built into the SoC superstructure of most PPC44x/46x-based chips. PPC440GX (the chip supported by this example source tree) has 256 KiB of on-chip SRAM; some of the other SoCs we have worked on only have 128 KiB, but even that is an order of magnitude more than what the monitor needs for its own use, so one still has room left to load and run simple application programs on top of the monitor before the main RAM is up! Memory mapping The Book-E architecture implemented by PPC44x/46x processors is different from the classic PowerPC architecture in that the instruction and data MMUs (address translation) are always enabled and the PLB4 physical address (36 bits) is wider than the 32-bit architectured effective address (what's visible at the CPU instruction set level and hence what all software has to work with), hence one cannot really think in terms of physical addresses any more. Whereas our original StarMON on PPC750 family processors offered peek and poke commands operating on physical addresses (on that processor family one could easily get to the physical address space with any desired cache control attributes using BATs), Book-E-MON works differently. With Book-E-MON the memory peek and poke commands (EXAMINE and DEPOSIT) operate on the 32-bit effective address space constructed inside the PPC44x/46x core, and new commands are provided that give the user full control over the 64-entry UTLB, the hardware table in the CPU core that maps these 32-bit effective addresses to 36-bit PLB4 physical addresses. The cache control attributes are also set in the UTLB entries and are under the user's control. Running other code from Book-E-MON Once the monitor is running, it supports two methods for loading other code into the system: over the console serial port or over Ethernet via TFTP. Given a processor like PPC440GX that has a decent on-chip SRAM, both methods work before the main RAM is up. Once again the Book-E memory mapping scheme applies: when loading code by either method, the load address needs to be specified as a 32-bit effective address mapped by UTLB. If the code thus loaded is then to be executed, the user must ensure that the executable bit is set in the UTLB entry, which is the default for the SRAM mapping established by the base monitor. Commands are provided to transfer control to an arbitrary 32-bit effective address, either as a jump or as a call. The UTLB mappings established by the monitor and/or the user remain in effect at the time of such control transfer and the user's code must use these mappings at least initially. The processor interrupt/exception vectors also point back to the monitor until changed by the user's code. Ethernet TFTP loading: we do not implement a full TCP/IP stack as that is deemed completely unnecessary in a bootloader / processor debug monitor. Instead when the user issues a TFTP command, the Ethernet interface is brought up, the TFTP load operation is performed and the Ethernet interface is then shut down. Environment variables (see below) are used to store MAC addresses for all Ethernet interfaces on the chip (PPC440GX has 4), selection of which port is to be used for TFTP loading and the local IP address to be used for these TFTP load operations. Serial port code loading: the X command protocol is implemented like on DEC VAX and MicroVAX consoles. BootLoader File System (BLFS) The base monitor is quite small, fits into 128 KiB. Modern flash parts are much larger than that, even the small boot flashes, hence the base monitor is placed into the highest-addressed erase blocks of the flash chip where the architectured reset vector lies, leaving the rest of the boot flash chip free for other uses. Book-E-MON supports using these extra erase blocks in the boot flash chip (blocks which may be erased and reprogrammed without blowing away the base monitor) to implement BLFS: a bootloader file system. It is a very primitive writable flash file system (much simpler than JFFS2 and the like) specifically intended for bootloader rather than main OS use. BLFS can be used to store assistant programs, bootloader accessories such as FPGA configuration images, command scripts and persistent environment variables (see below). The actual file system used for BLFS is RT11FFS (RT-11 Flash File System) designed by Harhan Engineering Co. documented in rt11ffs_spec.txt. The base monitor knows how to read from BLFS, but it doesn't do any BLFS writes on its own because it runs from flash and hence can't write to flash. Instead all flash write operations are done by a dedicated assistant program called FLASHW. FLASHW.BIN is itself stored in BLFS and may be used in two ways: * The user can run FLASHW manually in which case it redirects all interrupt and exception vectors to itself (so it's safe to overwrite the base monitor) and presents a RAM-based interactive monitor prompt. At this point the user can perform arbitrary flash erase and program operations, either raw flash or BLFS. * The main monitor has some BLFS write commands. These commands work by locating FLASHW.BIN in BLFS, copying it to RAM and running it to do the work. Environment variables This is a late addition to Book-E-MON: the original StarMON had no environment variables, but this facility has been added to better compete with Das U-Boot. Environment variables in Book-E-MON are just like their counterpart in UNIX shells and in U-Boot: they are arbitrary textual name=value pairs. SETENV, UNSETENV and SHOW ENV commands are provided which work in the obvious straightforward manner. The environment block is maintained in a reserved area of SoC SRAM (volatile); SAVEENV command saves it in BLFS in ENV.DAT from where it will be automatically restored on every reboot. Book-E-MON itself uses the following environment variables: core_reset= chip_reset= system_reset= names of command scripts to execute upon each reset type ethaddr= eth1addr= eth2addr= eth3addr= Ethernet MAC address ethport= ipaddr= used by the TFTP command to select which Ethernet port to use and to give it a temporary local IP address for the duration of the operation bootargs= used by the example OSBOOT program (Linux kernel boot assistant) to get the kernel command line The user can also define arbitrary other environment variables and refer to them from command scripts. Booting Linux The version of Book-E-MON presented in this source is able to boot Linux 2.6 on the Ocotea board. One needs to take vmlinux.bin from the arch/ppc/boot/images directory in the Linux build tree (it's an intermediate step between vmlinux and uImage/zImage) and load it at address 0 using the TFTP command. Then run the OSBOOT assistant program. OSBOOT constructs a U-Boot-imitating board info structure (which is what Linux expects) from Book-E-MON's system information structure and from environment variables, and it also takes care of getting the kernel command line from the bootargs environment variable. The point of the exercise was/is that Book-E-MON can replace U-Boot.