Difference between revisions of "Application XIP Instructions For OMAP"

From eLinux.org
Jump to: navigation, search
(Legacy Content Conversion)
 
 
(One intermediate revision by one other user not shown)
Line 35: Line 35:
  
 
Note that recent ARM community kernels contain support for, or at least partial support for, XIP (I believe Nicolas Pitre was the ARM community liason for the submittal).
 
Note that recent ARM community kernels contain support for, or at least partial support for, XIP (I believe Nicolas Pitre was the ARM community liason for the submittal).
 +
 +
[[Category:Boot Time]] [[Category:System Size]]

Latest revision as of 00:35, 13 May 2009

Todd Poynor of MontaVista wrote the following:

The MTD driver must either not be used or must be configured to not manage a flash chip used for XIP (kernel or application). I believe the CELF tree contains CONFIG symbols to individually enable MTD use of flash chips 0 and 1 on the 1510 Innovator (CONFIG_MTD_OMAP_0/1).

(Reason: flash chips are stateful devices and the state must be centrally managed by a driver such as MTD... direct memory references to read XIP executable data from the chip while the MTD driver has the chip in a non-read state, probing or writing, will probably hang.)

XIP executables (kernel or application) must be stored in uncompressed format. The usual way of doing XIP apps is to create a CramFS filesystem with XIP executables uncompressed. mkcramfs can do this by not compressing any executable with the "sticky" bit set (I think the community version has this feature). Enabling XIP support in the kernel allows the kernel CramFS filesystem driver to know that an executable with the "sticky" bit set is uncompressed (and does not need the usual copy-and-uncompress operation). You can mark XIP apps in the tree used as input to mkcramfs with "chmod +t <file>".

The XIP cramfs filesystem is then copied to a flash partition, either through the bootloader or by copying to an MTD device (booting another kernel with MTD support for that chip/partition). The kernel must also enable "Linear CRAMFS", which mounts the filesystem directly into the kernel virtual address space and bypasses the MTD layer (for reasons given above).

Mount the filesystem as a root using kernel command line options:

   root=/dev/null rootflags=physaddr=0x<physical address>

where 0x<physical address> is the physical address of the CRAMFS image in flash. Or mount a non-root filesystem from a running Linux:

   mount -t cramfs -o physaddr=0x<physical address> ...

For example, root fs on OMAP1510 Innovator flash chip normally associated with first MTD partition mtd0 (at physical addr 0x1000000):

CONFIG_CRAMFS_LINEAR=y
CONFIG_CRAMFS_LINEAR_XIP=y
CONFIG_ROOT_CRAMFS_LINEAR=y
CONFIG_CMDLINE="mem=32M console=ttyS0,115200n8 noinitrd root=/dev/null rootflags=physaddr=0x1000000"

Mount from shell:

# mount -t cramfs -o physaddr=0x1000000 /dev/mtdblock0 /mnt/cramfs

Note that recent ARM community kernels contain support for, or at least partial support for, XIP (I believe Nicolas Pitre was the ARM community liason for the submittal).