November 13, 2004, at 12:40 PM by tman --

Changed line 33 from:

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.

to:

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)

November 13, 2004, at 11:32 AM by rwhitby --

Added lines 39-40:

SlugImage ? has been created to be able to read a list of partition names and corresponding files and store them in the image file.

Changed line 45 from:

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 "Root" partition. Slugtool will also need to be enhanced to be able to read a list of partition names and corresponding files and store them in the image file.

to:

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.

November 12, 2004, at 07:10 AM by rwhitby --

Changed line 15 from:

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", "Root" and "User" FIS directory entries appropriately (with the "Root" and "User" 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 "Root" and "User" entries) then the "Root" and "User" 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).

to:

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).

Changed line 41 from:

Next step after that is to enable CRAMFS/SQUASHFS and JFFS2 file systems in the kernel defconfig. Then create a jffs2 partition in the "Root" area, and see if the kernel can mount it.

to:

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.

Changed line 43 from:

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 "Root" partition. Slugtool will also need to be enhanced to be able to read a ramdisk.gz or ramdisk.squashfs file, and root.jffs2 and user.jffs2 files and store them in the image file.

to:

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 "Root" partition. Slugtool will also need to be enhanced to be able to read a list of partition names and corresponding files and store them in the image file.

November 12, 2004, at 05:51 AM by rwhitby --

Changed line 15 from:

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", and "Flashdisk" FIS directory entries appropriately (with the "Flashdisk" partition 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 "Flashdisk" entry) then the "Flashdisk" entry 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).

to:

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", "Root" and "User" FIS directory entries appropriately (with the "Root" and "User" 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 "Root" and "User" entries) then the "Root" and "User" 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).

Changed line 41 from:

Next step after that is to enable CRAMFS and JFFS2 file systems in the kernel defconfig. Then create a jffs2 partition in the "Flashdisk" area, and see if the kernel can mount it.

to:

Next step after that is to enable CRAMFS/SQUASHFS and JFFS2 file systems in the kernel defconfig. Then create a jffs2 partition in the "Root" area, and see if the kernel can mount it.

Changed line 43 from:

Next step after that is to work out how small the CRAMFS area can be made (by moving non-essential stuff from the "Ramdisk" area into the "Flashdisk" area, and changing the boot sequence to mount the "Flashdisk" area appropriately). Slugtool will also need to be enhanced to be able to read both ramdisk.gz and flashdisk.jffs2 files and store them in the image file. We would identify which files are really superfluous and can be removed (to allow people to create more space in the "Flashdisk" partition).

to:

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 "Root" partition. Slugtool will also need to be enhanced to be able to read a ramdisk.gz or ramdisk.squashfs file, and root.jffs2 and user.jffs2 files and store them in the image file.

November 12, 2004, at 04:00 AM by rwhitby --

Changed line 15 from:

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", "System Configuration", "Kernel", "Ramdisk", and "Flashdisk" FIS directory entries appropriately (with the "Flashdisk" partition 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 "Flashdisk" entry) then the "Flashdisk" entry 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).

to:

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", and "Flashdisk" FIS directory entries appropriately (with the "Flashdisk" partition 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 "Flashdisk" entry) then the "Flashdisk" entry 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).

November 11, 2004, at 06:53 PM by jacques --

Changed line 15 from:

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", "System Configuration", "Kernel", "Ramdisk", and "Flashdisk" FIS directory entries appropriately (with the "Flashdisk" partition 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 "Flashdisk" entry) then the "Flashdisk" entry 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).

to:

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", "System Configuration", "Kernel", "Ramdisk", and "Flashdisk" FIS directory entries appropriately (with the "Flashdisk" partition 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 "Flashdisk" entry) then the "Flashdisk" entry 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).

November 11, 2004, at 01:24 PM by rwhitby --

Deleted lines 60-61:

<jacques> rwhitby-web1, that might be possible by using some of the existing mtd partition types

November 11, 2004, at 01:21 PM by rwhitby --

Changed line 43 from:

Next step after that is to work out how small the CRAMFS area can be made (by moving non-essential stuff from the "Ramdisk" area into the "Flashdisk" area, and changing the boot sequence to mount the "Flashdisk" area appropriately. Slugtool will also need to be enhanced to be able to read both ramdisk.gz and flashdisk.jffs2 files and store them in the image file.

to:

Next step after that is to work out how small the CRAMFS area can be made (by moving non-essential stuff from the "Ramdisk" area into the "Flashdisk" area, and changing the boot sequence to mount the "Flashdisk" area appropriately). Slugtool will also need to be enhanced to be able to read both ramdisk.gz and flashdisk.jffs2 files and store them in the image file. We would identify which files are really superfluous and can be removed (to allow people to create more space in the "Flashdisk" partition).

November 11, 2004, at 01:19 PM by rwhitby --

Changed lines 39-43 from:

Next step after that is to enable CRAMFS and JFFS2 file systems in the kernel defconfig.

to:

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 and JFFS2 file systems in the kernel defconfig. Then create a jffs2 partition in the "Flashdisk" area, and see if the kernel can mount it.

Next step after that is to work out how small the CRAMFS area can be made (by moving non-essential stuff from the "Ramdisk" area into the "Flashdisk" area, and changing the boot sequence to mount the "Flashdisk" area appropriately. Slugtool will also need to be enhanced to be able to read both ramdisk.gz and flashdisk.jffs2 files and store them in the image file.

November 11, 2004, at 01:13 PM by rwhitby --

Changed line 15 from:

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", "System Configuration", "Kernel", "Ramdisk", and "Flashdisk" FIS directory entries appropriately (with the "Flashdisk" partition 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 "Flashdisk" entry) then the "Flashdisk" entry should not be written. The "Ramdisk" partition will be a minimum size of one erase block.

to:

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", "System Configuration", "Kernel", "Ramdisk", and "Flashdisk" FIS directory entries appropriately (with the "Flashdisk" partition 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 "Flashdisk" entry) then the "Flashdisk" entry 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).

November 11, 2004, at 01:08 PM by rwhitby --

Changed line 17 from:

Slugtool must be careful to leave the existing important parts of the Trailer unchanged.

to:

Slugtool must be careful to leave the existing important parts of the Trailer unchanged (the last 16 bytes of the Trailer block).

November 11, 2004, at 01:04 PM by rwhitby --

Changed lines 15-17 from:

Next step is to change slugtool to write a partition table to 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 into the trailer which sets the "Redboot", "System Configuration", "Kernel", "Ramdisk", and "Flashdisk" FIS directory entries appropriately (with the "Flashdisk" partition 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 "Flashdisk" entry) then the "Flashdisk" entry should not be written. The "Ramdisk" partition will be a minimum size of one erase block.

to:

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", "System Configuration", "Kernel", "Ramdisk", and "Flashdisk" FIS directory entries appropriately (with the "Flashdisk" partition 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 "Flashdisk" entry) then the "Flashdisk" entry should not be written. The "Ramdisk" partition will be a minimum size of one erase block.

Slugtool must be careful to leave the existing important parts of the Trailer unchanged.

November 11, 2004, at 01:01 PM by rwhitby --

Changed line 15 from:

Next step is to change slugtool to write a partition table to the last block, and then see if it is recognised.

to:

Next step is to change slugtool to write a partition table to 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 into the trailer which sets the "Redboot", "System Configuration", "Kernel", "Ramdisk", and "Flashdisk" FIS directory entries appropriately (with the "Flashdisk" partition 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 "Flashdisk" entry) then the "Flashdisk" entry should not be written. The "Ramdisk" partition will be a minimum size of one erase block.

Changed line 17 from:

Each entry in the table is structured as follows:

to:

Each entry in the FIS directory is structured as follows:

November 11, 2004, at 12:46 PM by rwhitby --

Added lines 17-38:

Each entry in the table is structured as follows:

struct fis_image_desc {
unsigned char name[16]; // Null terminated name
unsigned long flash_base; // Address within FLASH of image
unsigned long mem_base; // Address in memory where it executes
unsigned long size; // Length of image
unsigned long entry_point; // Execution entry point
unsigned long data_length; // Length of actual data
unsigned char _pad[256-(16+7*sizeof(unsigned long))];
unsigned long desc_cksum; // Checksum over image descriptor
unsigned long file_cksum; // Checksum over image data
};

Note that the desc_cksum field is ignored by parse_redboot_partitions, so we don't need to write that to the partition table.

The table is terminated by 0xFF in name[0] - 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).

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 ...).

Changed line 41 from:

Changes required in nslu2-openslug

to:

Changes required in nslu2-openslug`

November 11, 2004, at 12:46 PM by rwhitby --

Changed line 31 from:

Note that the desc_cksum field is ignored by parse_redboot_partitions, so we don't need to write that to the partition table.

to:

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.

Changed line 33 from:

The table is terminated by 0xFF in name[0] - which is a good thing because we intend to write any free space in the last block with 0xFF.

to:

The table is terminated by an entry with 0xFF in name[0] - which is a good thing because we intend to write any free space in the last block with 0xFF.

Deleted lines 35-36:

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 ...).

November 11, 2004, at 12:11 PM by rwhitby --

Added lines 17-18:

Next step after that is to enable CRAMFS and JFFS2 file systems in the kernel defconfig.

November 11, 2004, at 12:02 PM by rwhitby --

Changed line 15 from:

Next step after that is to change slugtool to write a partition table to the last block, and then see if it is recognised.

to:

Next step is to change slugtool to write a partition table to the last block, and then see if it is recognised.

November 11, 2004, at 11:56 AM by rwhitby --

Changed line 3 from:

Looks like 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.

to:

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.

November 11, 2004, at 11:55 AM by rwhitby --

Changed lines 5-13 from:

I am hoping that if there is no partition table in the last block, then it will just default to the built-in hard-coded partition table.

to:

If there is no partition table in the last block, then it just defaults to the built-in hard-coded partition table:

No RedBoot partition table detected in IXP425 Flash
Using static MTD partitions.
Creating 4 MTD partitions on "IXP425 Flash":
0x00000000-0x00040000 : "RedBoot "
0x00040000-0x00060000 : "System Configuration"
0x00060000-0x00160000 : "Kernel"
0x00160000-0x00800000 : "Ramdisk"

November 11, 2004, at 11:43 AM by rwhitby --

Changed line 3 from:

drivers/mtd/maps/ixp425.c

to:

Looks like 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.

Changed lines 5-7 from:

Looks like all that needs to be done here is to set CONFIG_MTD_REDBOOT_PARTS, 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.

to:

I am hoping that if there is no partition table in the last block, then it will just default to the built-in hard-coded partition table.

Next step after that is to change slugtool to write a partition table to the last block, and then see if it is recognised.

November 11, 2004, at 11:40 AM by rwhitby --

Changed line 1 from:

Changes required in unslung-standard-kernel

to:

Changes required in unslung-able-kernel

November 11, 2004, at 11:39 AM by rwhitby --

Changed line 5 from:

Looks like all that needs to be done here is to set CONFIG_MTD_REDBOOT_PARTS, and then the code that is there will read a RedBoot FIS directory from the last erase block (exactly what we intended to use!).

to:

Looks like all that needs to be done here is to set CONFIG_MTD_REDBOOT_PARTS, 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.

November 11, 2004, at 11:28 AM by rwhitby --

Added lines 1-12:

Changes required in unslung-standard-kernel

drivers/mtd/maps/ixp425.c

Looks like all that needs to be done here is to set CONFIG_MTD_REDBOOT_PARTS, and then the code that is there will read a RedBoot FIS directory from the last erase block (exactly what we intended to use!).

Changes required in nslu2-openslug

TBD

Initial discussion which resulted in this HowTo

November 11, 2004, at 06:25 AM by rwhitby --

Added line 62:

November 11, 2004, at 06:25 AM by rwhitby --

Added line 56:

Added lines 64-70:

<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

November 11, 2004, at 05:15 AM by oaktree --

Changed line 1 from:

[13:44] <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

to:

<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

November 11, 2004, at 05:15 AM by oaktree --

Changed line 3 from:

[13:46] <jacques> it's starting to sound like we want a partition table in flash

to:

<jacques> it's starting to sound like we want a partition table in flash

Changed line 5 from:

[13:46] <jacques> and I know there's code for that in the kernel - just not exactly how it works

to:

<jacques> and I know there's code for that in the kernel - just not exactly how it works

Changed line 7 from:

[13:46] <jacques> a partition table that the kernel reads and acts upon

to:

<jacques> a partition table that the kernel reads and acts upon

Changed line 9 from:

[13:47] <jacques> the kernel would have to stay in the same place... hmm and first block of ramdisk part

to:

<jacques> the kernel would have to stay in the same place... hmm and first block of ramdisk part

Changed line 11 from:

[13:49] <jacques> rwhitby-web1, that might be possible by using some of the existing mtd partition types

to:

<jacques> rwhitby-web1, that might be possible by using some of the existing mtd partition types

Changed line 13 from:

[13:48] <rwhitby-web1> partition table that only allows the boundary between ramdisk and jffs2 to be moved. nothing else

to:

<rwhitby-web1> partition table that only allows the boundary between ramdisk and jffs2 to be moved. nothing else

Changed line 15 from:

[13:48] <rwhitby-web1> jacques: we control the ext2 ramdisk size, and set the rest to be jffs2

to:

<rwhitby-web1> jacques: we control the ext2 ramdisk size, and set the rest to be jffs2

Changed line 17 from:

[13:49] <rwhitby-web1> you write the calculated jffs2 size into the last block

to:

<rwhitby-web1> you write the calculated jffs2 size into the last block

Changed line 19 from:

[13:49] <jacques> rwhitby-web1, that might be possible by using some of the existing mtd partition types

to:

<jacques> rwhitby-web1, that might be possible by using some of the existing mtd partition types

Changed line 21 from:

[13:49] <rwhitby-web1> we could do that today, to use the spare space above the ramdisk which is not used today

to:

<rwhitby-web1> we could do that today, to use the spare space above the ramdisk which is not used today

Changed line 23 from:

[13:49] <jacques> if we could tell the kernel to look for a partition table in the last block

to:

<jacques> if we could tell the kernel to look for a partition table in the last block

Changed line 25 from:

[14:32] <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

to:

<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

Changed line 27 from:

[14:50] <rwhitby-web1> 1) trailer has three things in it: partition table, kernel args, sercomm trailer (plus space for more things we think of later)

to:

<rwhitby-web1> 1) trailer has three things in it: partition table, kernel args, sercomm trailer (plus space for more things we think of later)

Changed line 29 from:

[14:50] <rwhitby-web1> 2) all tools that touch the trailer (initially that's slugtool) do a read-modify_your_bit_only-write

to:

<rwhitby-web1> 2) all tools that touch the trailer (initially that's slugtool) do a read-modify_your_bit_only-write

Changed line 31 from:

[14:51] <Tiersten> Why do we need to read first? You want to preserve the args?

to:

<Tiersten> Why do we need to read first? You want to preserve the args?

Changed line 33 from:

[14:51] <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

to:

<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

Changed line 35 from:

[14:51] <Tiersten> If you require read first then you've got allow slugtool access to redboot or linux

to:

<Tiersten> If you require read first then you've got allow slugtool access to redboot or linux

Changed line 37 from:

[14:52] <rwhitby-web1> Tiersten: a tool which rewrites the whole block (like slugtool) doesn't need to read

to:

<rwhitby-web1> Tiersten: a tool which rewrites the whole block (like slugtool) doesn't need to read

Changed line 39 from:

[14:52] <Tiersten> "all tools that touch the trailer (initially that's slugtool) do a read-modify_your_bit_only-write" <-- read :p

to:

<Tiersten> "all tools that touch the trailer (initially that's slugtool) do a read-modify_your_bit_only-write" <-- read :p

Changed line 41 from:

[14:53] <rwhitby-web1> correction noted

to:

<rwhitby-web1> correction noted

Changed line 43 from:

[14:53] <rwhitby-web1> 4) if the ext2/cramfs area is null, then the kernel args are set to load rootfs from jffs2

to:

<rwhitby-web1> 4) if the ext2/cramfs area is null, then the kernel args are set to load rootfs from jffs2

Changed line 45 from:

[14:54] <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

to:

<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

Changed line 47 from:

[14:54] <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)

to:

<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)

Changed line 49 from:

[14:55] <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

to:

<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

Changed line 51 from:

[14:56] <rwhitby-web1> 8) the board specific code in the kernel looks for the kernel args signature, and if found it modifies the kernel args.

to:

<rwhitby-web1> 8) the board specific code in the kernel looks for the kernel args signature, and if found it modifies the kernel args.

Added line 56:

<rwhitby-web1> it would be added to -able immediately

Changed line 58 from:

[14:41] <rwhitby-web1> it would be added to -able immediately

to:

<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

Changed lines 60-64 from:

[14:42] <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

[14:42] <rwhitby-web1> so no new variants

[14:11] <rwhitby-web1> that partition table can get rid of sysconf for openslug, or leave it there for unslung. and redboot never needs to change

to:

<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

November 11, 2004, at 05:01 AM by rwhitby --

Changed line 53 from:

MTD Partition table signature: nSlU2LiNuX or uNsLuNg or oPeNsLuG

to:

MTD Partition table signature: sLuGmRkP

Changed line 55 from:

Kernel args signature: NsLu2lInUx ? or UnSlUnG ? or OpEnSlUg ?

to:

Kernel args signature: sLuGmRkA

November 11, 2004, at 04:45 AM by rwhitby --

Added lines 1-26: