8d technologies

Compulab cm-x255/x270* faq/howto page

About | Working around the kernel size limit of Compulab's bootloader | Using the NOR flash on cm-x255 | /dev/nand does not work! | Contact |
< Back to main page

About
This page is part of the Compulab kernel fork project I started in order to be able to use modern kernels in our products, which use Compulab single board computers. The main project page can be found at the following address: http://raph.people.8d.com/armcore_kernel.php.


Working around the kernel size limit of the Compulab bootloader
Problem: The bootloader assumes that the kernel compressed image size wont exceed 1.4Mb.

When you download a kernel using tftp, the bootloader places the data in memory, starting at address 0xA0100000. Here the file can exceed 1.4Mb without problems. If you try to boot using the bootos command, the bootloader will detect the kernel image in memory and boot it correctly.

Now, downloading a kernel after each reboot is not practical. You need to store the kernel into flash so the bootloader can load it from there automatically instead of downloading it. This is done by typing flash kernel.

The flash kernel command copies data from memory (starting at 0xA0100000) to flash, starting at address (0x00040000). The command copies all the bytes (even if more than 1.4Mb).

Now, try this: Reset the board and type bootos. It wont work. It just hangs there. What happens is that the bootos command loads only the first 1.4 mb of data. The kernel does not start because an error occurs while is decompresses itself.

The workaround I use is to manually load the data from flash using the following command:
load a0100000 40000 1878d4. The 3rd argument is the length to copy, in hex! ugh.

Finally, we must execute the kernel. Use bootos:
bootos.
bootos overwrites the first 1.4 megs, but the remaining data that we copied manually is still in place so it works. Unfortunately, it's not possible to use setboot to do this.

Using exec also works to some extent:
exec a0100000
...but there is a major drawback: No tagged list has been setup in memory. The kernel uses default values, which is probably not what you want (eg: 16Megs of memory assumed, etc).

There is also another problem with this method: Automatic booting is not possible since the setboot command does not appear to support booting by copying data from the NOR flash to memory followed by an exec (but it does support copying from the NAND).

Fortunately, Compulab's bootloader supports executing arbitrary user code so I wrote a simple loader in assembler which copies the kernel from NOR, setup a tagged list and then run the kernel.

I flash my little code near the end of the NOR, leaving a lot of space available for the kernel.

First, download the chained loader to memory:
download a3000000 tftp chain_nor 192.168.142.55
Next, copy it to the NOR flash:
flash 3ff000 2048 a3000000

Check if it works by executing the code:
exec 3ff000

For automatic execution:
setboot absolute 3ff000

Here is the binary version of the loader:
chain_nor.bin (140 bytes)

The loader above copies only the 2 first megabytes and assumes 64Megs of memory is present but these parameters are easily changed by recompiling the source. And here is the source: chain-2.tar.gz

IMPORTANT: Values shown here may need to be adjusted depending on your options (NOR size, memory size, etc). If you use the values as-is (or change them) and bad things happen (such as erasing the boot loader), I'm not responsible. Dont follow theses instructions if you dont understand how they work and even so, be careful.

Using the NOR flash on cm-x255
The NOR flash is already supported by the mtd layer. You only need to enable and configure the right kernel options:
RAM/ROM/Flash chip drivers  --->
	[*] Detect flash chips by Common Flash Interface (CFI) probe
	[*] Support for AMD/Fujitsu flash chips
Mapping drivers for chip access  --->
	[*] CFI Flash device in physical memory map
	(0x00000000) Physical start address of flash mapping
	(0x800000) Physical length of flash mapping
	(2)   Bank width in octets (NEW)
			
If all goes well, you should see the following messages when booting:
physmap flash device: 800000 at 0
phys_mapped_flash: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
			

If you use enable the NOR flash and use the NAND patch at the same time, the NOR appears at mtd0 and the nand at mtd1.

Warning: The bootloader is in NOR so be careful not to erase it. If you do, you'll need to use JTAG to reprogram the flash or send the board back to compulab!!!

/dev/nand does not work!
Users of Compulab's patches often contact me because when they try my patches, root=/dev/nand does not work anymore.

Compulab flash driver exposes the flash as a regular block device (eg: Like a hard drive) in /dev, which is named /dev/nand. This enable users to use traditional filesystems such as ext2 on the flash. However, there is a problem. This driver is binary only, which mean that 1) It's legality is questionable, 2) If there's a bug, you cannot fix it yourself, and 3) It cannot be used with newer kernels since some structures have changed and new compilers sometimes change things such as aligment.

The standard way of exposing devices such as flash memory is to use the Linux MTD api. I wrote a drivers for the cm-x255 and cm-x270 which does exactly that, allowing you to use filesystems desigined specifically for running on flash such as jffs2.

IMPORTANT: When you use jffs2, you cannot format and program the NAND flash from Compulab's bootloader since it does not setup the flash out-of-band data correctly. Instead, install and boot the kernel with a ramdisk (or use an USB key (root=/dev/sda1 rootdelay=10)). Be sure to include the tools you need to format the flash (flash_eraseall) and download the filesystem image or archive.

For more information on MTD and JFFS2, visit http://www.linux-mtd.infradead.org/

Contact
You may contact me by email if you have suggestions, improvements, patches or questions:

Raphael Assenat <raph.armcore@8d.com>


created with vim Valid HTML 4.01 Transitional Sponsored and hosted by:8d technologies