Changes required in unslung-able-kernel
All that needs to be done here is to set CONFIG_MTD_REDBOOT_PARTS (which affects the code in drivers/mtd/maps/ixp425.c), and then the code that is there will read a RedBoot FIS directory from the last erase block (exactly what we intended to use!). This is done by enabling this in packages/linux/unslung-kernel-*/able/defconfig and recompiling unslung-able-image.
If there is no partition table in the last block, then it just defaults to the built-in hard-coded partition table:
Next step is to change slugtool to write a partition table at the very start of the last block, and then see if it is recognised. Slugtool should look at the size of the ramdisk passed to it, and then round that up to the next erase block size, then write a partition table at the very start of the trailer block which sets the "RedBoot", "SysConf?", "Kernel", "Ramdisk", "Rootdisk" and "Userdisk" FIS directory entries appropriately (with the "Rootdisk" and "Userdisk" partitions starting at the next erase block boundary after the ramdisk, and ending just before the last block). If the ramdisk fills the complete area (leaving no room for the "Rootdisk" and "Userdisk" entries) then the "Rootdisk" and "Userdisk" entries should not be written. The "Ramdisk" partition will be a minimum size of one erase block. Note that the last entry in the table should be called "FIS directory", and cover the last block only (i.e. the minimum size partition possible).
Slugtool must be careful to leave the existing important parts of the Trailer unchanged (the last 16 bytes of the Trailer block).
Each entry in the FIS directory is structured as follows:
Only the name, flash_base and size fields are actually used. All other bytes can be set to 0x00 (unless we decide to use them for something else - e.g. we could create a pseudo-partition which holds some sort of flags which are read by the kernel ...). In particular, the desc_cksum field is ignored by parse_redboot_partitions, so we don't need to worry about that. (tman: Is it ignored by RedBoot however? Don't want to reuse it if it turns out RedBoot pays attention to that field which will mean we'll have problems down the line for people replacing RedBoot)
The table is terminated by an entry with 0xFF in name - which is a good thing because we intend to write any free space in the last block with 0xFF.
The first slot in the table should be called "RedBoot" (note that there is no space at the end of that string, unlike the static mapping which does have a space at the end of the "RedBoot " name).
Next step after that is to test that the FIS directory is created properly, and that the kernel reads it correctly, and still boots and loads the ramdisk as before. Then we need to add a couple more sets of /dev/mtd* entries in the device_table.txt for unslung to accomodate the new partitions.
Next step after that is to enable CRAMFS/SQUASHFS and JFFS2 file systems in the kernel defconfig. Then create a jffs2 partition in the "Rootdisk" area, and see if the kernel can mount it.
Next step after that is to work out how small the CRAMFS/SQUASHFS area can be made for a /linuxrc which pivots to either an external unslung disk, or a jffs2 "Rootdisk" partition.
Changes required in nslu2-openslug`
Initial discussion which resulted in this HowTo
<rwhitby-web1> jacques: can the start of the jffs2 paritition be read from the last block (before sercomm header) at boot, and then mtdblock4 created based on that, and then the ramdisk loads it - then we can have varying sizes of ramdisk and jfffs2
<jacques> it's starting to sound like we want a partition table in flash
<jacques> and I know there's code for that in the kernel - just not exactly how it works
<jacques> a partition table that the kernel reads and acts upon
<jacques> the kernel would have to stay in the same place... hmm and first block of ramdisk part
<rwhitby-web1> partition table that only allows the boundary between ramdisk and jffs2 to be moved. nothing else
<rwhitby-web1> jacques: we control the ext2 ramdisk size, and set the rest to be jffs2
<rwhitby-web1> you write the calculated jffs2 size into the last block
<jacques> rwhitby-web1, that might be possible by using some of the existing mtd partition types
<rwhitby-web1> we could do that today, to use the spare space above the ramdisk which is not used today
<jacques> if we could tell the kernel to look for a partition table in the last block
<rwhitby-web1> so the serious proposal here is to have slugtool determine the size of the ext2 (or cramfs) ramdisk image, and then create a parition table in the trailer which makes the rest of the space into a JFFS2 partition, Then we have the mtd partition table code in the nslu2 specific startup part of the kernel read that parition table
<rwhitby-web1> 1) trailer has three things in it: partition table, kernel args, sercomm trailer (plus space for more things we think of later)
<rwhitby-web1> 2) all tools that touch the trailer (initially that's slugtool) do a read-modify_your_bit_only-write
<Tiersten> Why do we need to read first? You want to preserve the args?
<rwhitby-web1> 3) the tool which creates a firmware 8MB image detects the size of the ext2/cramfs root filesystem image, and sets up the partition table so the rest of the space is jffs2
<Tiersten> If you require read first then you've got allow slugtool access to redboot or linux
<rwhitby-web1> Tiersten: a tool which rewrites the whole block (like slugtool) doesn't need to read
<Tiersten> "all tools that touch the trailer (initially that's slugtool) do a read-modify_your_bit_only-write" <-- read :p
<rwhitby-web1> correction noted
<rwhitby-web1> 4) if the ext2/cramfs area is null, then the kernel args are set to load rootfs from jffs2
<rwhitby-web1> 5) if the ext2/cramfs area is not null, then the kernel args are set to load ramdisk - and ramdisk can mount jffs2 where it desires
<rwhitby-web1> 6) if the ext2/cramfs area is full, then the partition table does not contain jffs2 partition (or maybe it sets it to empty)
<rwhitby-web1> 7) the board-specific code in the kernel reads the table (if it exists) and sets up the mtd table accordingly. if it can't find the table, then it defaults to stock partition table
<rwhitby-web1> 8) the board specific code in the kernel looks for the kernel args signature, and if found it modifies the kernel args.
MTD Partition table signature: sLuGmRkP
Kernel args signature: sLuGmRkA
<rwhitby-web1> it would be added to -able immediately
<rwhitby-web1> one extreme of the partition split is stock partition. The other extreme is root jffs2. Because we read the kernel args from trailer, then we can have the same kernel and ramdisk for both, and the choice is made at image creation time
<rwhitby-web1> so no new variants
<rwhitby-web1> that partition table can get rid of sysconf for openslug, or leave it there for unslung. and redboot never needs to change
<rwhitby-web1> so what is the openslug camp#4 custom redboot partitioning scheme?
<[g2]-camp4> right now I don't know
<dyoung-web> fis in the last block?
<rwhitby-web1> ok - for now we will run with an FIS table in last block until we decide otherwise