CerfPod 255SE is an embedded platform from Intrinsyc using 400MHz XScale processor with 64MB SDRAM and 32MB flash memory. Officially the board only supports WinCE and naturally works fine with it. But WinCE doesn’t really fit my needs so I’d like to run something else, primarily Linux at this time.
TFTP booting Linux with the existing bootloader works just fine using NFS as the root file system. But problems start when Linux would like to be saved to the board flash and booted from there as the I-Boot bootloader version onboard doesn’t support Linux or any other OS besides WinCE. Naturally the solution here would be to build a new bootloader with the preferred features. But the problem: instead of NOR flash the board uses M-Systems DiskOnChip Millennium Plus NAND flash chip. This doesn’t work like normal NOR flash and it requires it’s own somewhat complicate driver software. Also booting from the DiskOnChip is more complicated than with NOR flash. The module only support execute in place (XIP) from a special 1KByte boot block.
It is necessary to make an initial program loader (IPL) that is stored in this 1KB block which makes basic hardware initialisation and loads the secondary program loader (SPL) from the NAND to RAM and executes it from there. This SPL then loads the OS and provides other bootloader functionality.
Clearly that is more complicated than booting from NOR flash that supports XIP straight from the whole address space of the flash chip but as the board has the DiskOnChip as the only boot device I was planning to get into the process of building a new bootloader with the features I need even if it probably would be quite time consuming task. But after gathering all the public documentation about DiskOnChip that I was able to find the documentation still seemed to be missing the details of how to exactly save the IPL and SPL code on the DOC. Also it seemed that it’s not possible to obtain this information without signing an NDA with M-Systems. So quite big problem.
All this happened some time ago already and today I took the board on the desk again and started thinking about ways to solve this problem as otherwise it is a very nice board if only it didn’t use the M-Systems DiskOnChip as the only bootable storage. It occurred to me that it might be possible to add some external NOR flash to the expansion connector on the board. The expansion connector provides 16-bit databus and address bus. With some hardware hacking it could be possible to map this external NOR flash to chip select 0 on the XScale (booting can only happen from CS0) and maybe even physically remove the DOC device (currently mapped to CS0) from the board if necessary.
Then while looking at the expansion connector pinout I noticed a pin called “nBOOT_FLASH_ENA”. This name got my hopes up that maybe a remap like I’m planning with hardware hacking might be already built into the board CPLD. Unfortunately only thing mentioned in the docs is “nBOOT_FLASH_ENA is reserved for future use“. Doing some tracing I found out that the “nBOOT_FLASH_ENA” pin goes to the CPLD on the board and also the chip select from the expansion connector goes to the CPLD. More tracing revealed that the chip select from the DiskOnChip also goes to the CPLD. So everything looks like a remap like I want might be possibly implemented in the CPLD. I sent a query about “nBOOT_FLASH_ENA” and it’s functionality and I’m hoping for answer from Intrinsyc.
Otherwise it looks like the expansion connector should work nicely for a boot NOR flash as it provides the same 16-bit databus as used with the DOC and also the (probably hardwired) XScale BOOT_SEL[2:0] setup should be same for the DOC as 16-bit NOR flash. Here’s the current memory map of the board.
If the NOR flash approach works it should be possible to just forget the existence of the frustrating M-Systems DiskOnChip or maybe use it as a normal non-bootable MTD device with the Linux GPL DiskOnChip drivers.