Compulab cm-x255/x270* faq/howto page
Working around the kernel size limit of Compulab's bootloader |
Using the NOR flash on cm-x255 |
/dev/nand does not work! |
< Back to main page
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
Working around the kernel size limit of the Compulab bootloader
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
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
load a0100000 40000 1878d4
. The 3rd argument is the length to copy, in hex! ugh.
Finally, we must execute the kernel. Use 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:
...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
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
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:
For automatic execution:
setboot absolute 3ff000
Here is the binary version of the loader:
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:
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.
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
You may contact me by email if you have suggestions, improvements, patches or questions:
Raphael Assenat <firstname.lastname@example.org
Sponsored and hosted by: