09-03-2009 02:10 AM
Just a quick question, XAPP1140 says setup a flash partition called 'rootfs', however when the kernel is compiled the rootfs in included in the kernel image as a ramdisk image, so my question is, where does the filesystem reside in the system in this app note?
My aim is to have a system similar to the app note with a static rootfs in flash that doesent need to be decompressed each boot time.
Solved! Go to Solution.
09-03-2009 02:35 AM
I don't know the app note, but I'm sure Brian will speak to it, but the kernel typically can build 2 images, one with ramdisk and one without. The ramdisk image is named simpleImage.initrd.virtex440-<dts file name> while the non-ram disk image is simpleImage.virtex440-<dts file name>.
Not sure if that helps or not.
09-03-2009 07:13 AM
Yes, I set aside some space for a JFFS2 partition (which wasn't used). There's no JFFS2 image included for various reasons, the primary one being that a kernel image with a ramdisk was required to (most easily) show what I wanted to show. Namely, if the only filesystem were on the flash, it couldn't update itself. To make use of a flash root file system, I envisioned the use of pivot_root, which is not specifically addressed in XAP1140.
If you really desire no ramdisk at all, alternate schemes are possible such as 2 jffs2 filesystems. One with "everything" and another much smaller one with just enough support to upgrade flash images.
09-03-2009 07:43 AM
Yeah that is what i was thinking. Im planning to have a system running off the CF card (with a CF rootfs) for loading images into flash and another which is loaded from flash with a flash rootfs.
I guess to create a filesystem in flash i would format the partition as jffs2 or another, and copy over the rootfs from my CF rootfs?
By any chance there isnt a 10.1 version of the XPS project for the system floating around.
Thanks for your help.
09-03-2009 07:50 AM
There are 2 ways to get your files into a JFFS2 files system.
1) flash_eraseall can format the partition as JFFS2. Then, just mount and copy the files over. I've never tried this, but it seems the easies way.
2) I've only ever done it myself the 'hard' way. Create a JFFS2 image file on your server with mkfs.jffs2and then just program this image into the flash. This gives you something easy to redistribute. Note that endianness and erase block size absolutely must be specified correctly when creating this image.
09-04-2009 03:15 AM
Thanks, I am in the process if trialling it.
Is there a 10.1 version of the project that goes with this app note?
My current system in built on the top of the embedded_ref system and it has a block_ram mounted at the top end of the address range, and the flash lower down.
If i swap the addresses over so that flash is at the top is there anything i should be aware of? i.e do i need to untick "initialise block ram" on the bootloop software project and anything i need to do when i create a new software project for the loader.c file (apart from the linker script & startup clock).
I have managed to execute your pre made binary images from flash, programming them with my own CF system.
09-04-2009 06:42 AM
Ther is no 10.1 system available which matches this appnote. If, however, you map your flash at the top of the address range (PPC boot vector) and regenerate the device tree any other system should work OK. If you have BRAM in the system (which is no longer at the boot vector) it wouldn't really matter if the bootloop was in it or not.