NSLU2-Linux
view · edit · print · history

Info.BootFlash History

Hide minor edits - Show changes to markup

August 25, 2005, at 01:27 PM by tman --
Changed lines 16-44 from:

Depending on the type of data in an mtdblock, it may/may not have a header. "mtdblock0" is what the IXP42x boots from - there's no header (there's no code running yet that could interpret a header - headers make sense on 'data' partitions).

As Jim Buzbee has pointed out, "mtdblock1" starts with a 4-byte length, with the data immediately following that (offset 4 into the partition). The 4-byte length value reflects the length of the following data (doesn't include size of 4-byte length)

"mtdblock2" and "mtdblock3" appear to have 16-byte headers. They start with a 4-byte length, followed by 12 zeros. The length is the number of data bytes in the block excluding the 16 byte header - the data starts immediately after the header.

It's clear to me that the 4-byte length on "mtdblock3" represents the size of the upcoming data (after the 16-byte header). If you look at offset "length + 16" into "mtdblock3", you'll start to see zeros (and, there's a non-zero value just before that)

But, it's less clear on "mtdblock2". If you look at offset "length + 4", you start to see zeros (and there's a non-zero value just before that). It's possible that the image data in "mtdblock2" ends with zeros, and the definition of "length" here is the same as in "mtdblock3".

So, if we assume that the raw data stored in "mtdblock2" actually ends with some zeros, then we can interpret the "length" at the start to mean the length of the data immediately following the 16- byte header (just like "mtdblock3").

to:

Depending on the type of data in an mtdblock, it may/may not have a header. "mtdblock0" is what the IXP42x boots from - there's no header (there's no code running yet that could interpret a header - headers make sense on 'data' partitions).

As Jim Buzbee has pointed out, "mtdblock1" starts with a 4-byte length, with the data immediately following that (offset 4 into the partition). The 4-byte length value reflects the length of the following data (doesn't include size of 4-byte length)

"mtdblock2" and "mtdblock3" appear to have 16-byte headers. They start with a 4-byte length, followed by 12 zeros. The length is the number of data bytes in the block excluding the 16 byte header - the data starts immediately after the header.

It's clear to me that the 4-byte length on "mtdblock3" represents the size of the upcoming data (after the 16-byte header). If you look at offset "length + 16" into "mtdblock3", you'll start to see zeros (and, there's a non-zero value just before that)

But, it's less clear on "mtdblock2". If you look at offset "length + 4", you start to see zeros (and there's a non-zero value just before that). It's possible that the image data in "mtdblock2" ends with zeros, and the definition of "length" here is the same as in "mtdblock3".

So, if we assume that the raw data stored in "mtdblock2" actually ends with some zeros, then we can interpret the "length" at the start to mean the length of the data immediately following the 16-byte header (just like "mtdblock3").

Changed lines 30-44 from:

But, why would "mtdblock1" be different (4-byte length immediately followed by data - no 12-byte 'header pad')? One reason could be that LinkSys's own code is probably what reads/writes to "mtdblock1", whereas the (non-LinkSys) code in RedBoot is reading/writing "mtdblock2/3". I don't know - it's just speculation.

I believe that some of the 'header/trailer' stuff in 'splitnslu' is a little incorrect. The code update image from LinkSys is an exact 8MByte image of the entire flash (the 4 partitions concatenated together).

So, I think the "HEADER_OFFSET/HEADER_LENGTH" stuff is incorrect. "splitnslu" should do the following, I think:

to:

But, why would "mtdblock1" be different (4-byte length immediately followed by data - no 12-byte 'header pad')? One reason could be that LinkSys's own code is probably what reads/writes to "mtdblock1", whereas the (non-LinkSys) code in RedBoot is reading/writing "mtdblock2/3". I don't know - it's just speculation.

I believe that some of the 'header/trailer' stuff in 'splitnslu' is a little incorrect. The code update image from LinkSys is an exact 8MByte image of the entire flash (the 4 partitions concatenated together).

So, I think the "HEADER_OFFSET/HEADER_LENGTH" stuff is incorrect. "splitnslu" should do the following, I think:

Changed lines 38-49 from:

- Grab 4-byte value @ offset 0x40000, use that as length of "SysConf" image. Write that many bytes from offset 0x40004 to "SysConf"

- Grab 4-byte value @ offset 0x60000 (262144+131072), use that as length of "vmlinuz" image. Write that many bytes from offset 0x60010 to "vmlinuz"

- Grab 4-byte value @ offset 0x160000 (262144+131072+1048576), use that as length of "ramdisk.gz" image. Write that many bytes from offset 0x160010 to "ramdisk.gz"

to:

- Grab 4-byte value @ offset 0x40000, use that as length of "SysConf" image. Write that many bytes from offset 0x40004 to "SysConf"

- Grab 4-byte value @ offset 0x60000 (262144+131072), use that as length of "vmlinuz" image. Write that many bytes from offset 0x60010 to "vmlinuz"

- Grab 4-byte value @ offset 0x160000 (262144+131072+1048576), use that as length of "ramdisk.gz" image. Write that many bytes from offset 0x160010 to "ramdisk.gz"

Changed lines 46-49 from:

To re-assemble (pack):

to:

To re-assemble (pack):

Changed lines 52-60 from:

- copy "SysConf" to offset 0x40004 of allocated array, and store 4-byte length of "SysConf" @ offset 0x40000

- copy "vmlinuz" to offset 0x60010 of allocated array, and store 4-byte length of "vmlinuz" @ offset 0x60000

- copy "ramdisk.gz" to offset 0x160010 of allocated array, and store 4-byte length of "ramdisk.gz" @ offset 0x160000

to:

- copy "SysConf" to offset 0x40004 of allocated array, and store 4-byte length of "SysConf" @ offset 0x40000

- copy "vmlinuz" to offset 0x60010 of allocated array, and store 4-byte length of "vmlinuz" @ offset 0x60000

- copy "ramdisk.gz" to offset 0x160010 of allocated array, and store 4-byte length of "ramdisk.gz" @ offset 0x160000

Changed lines 62-71 from:

NOTE: Because of the mis-interpretation of 'headers' in splitnslu, it's possible that things could be patched/put back together and actually work (unlike what author Brian Lantz found). For example, if the resulting modified "ramdisk.gz" image had a different (larger) byte size than the original (stored the 4-byte header just before it) then it wouldn't decompress correctly (truncated input to gunzip)

[http://www.rwhitby.net/nslu2/boot-sequence.html][http://groups.yahoo.com/group/nslu2-linux/message/33]

to:

NOTE: Because of the mis-interpretation of 'headers' in splitnslu, it's possible that things could be patched/put back together and actually work (unlike what author Brian Lantz found). For example, if the resulting modified "ramdisk.gz" image had a different (larger) byte size than the original (stored the 4-byte header just before it) then it wouldn't decompress correctly (truncated input to gunzip)

[http://www.rwhitby.net/nslu2/boot-sequence.html][http://groups.yahoo.com/group/nslu2-linux/message/33]

July 04, 2005, at 10:47 PM by jbowler -- Clarified the Kernel/Ramdisk block headers
Changed lines 27-29 from:

start with a 4-byte length, followed by 12 zeros. I'm not 100% sure what the length represents here.

to:

start with a 4-byte length, followed by 12 zeros. The length is the number of data bytes in the block excluding the 16 byte header - the data starts immediately after the header.

Added lines 45-46:

This can be confirmed by changing the bytes at the end and examining what RedBoot copies into memory at boot.

Changed line 50 from:

to "mtdblock1", where standard Linux code is

to:

to "mtdblock1", whereas the (non-LinkSys) code in RedBoot is

Deleted line 53:
November 15, 2004, at 01:36 PM by tman --
Changed lines 7-8 from:
 Unknown0x5003FFB60x4A (74B)See "SercommRedBootTrailer"
to:
 Unknown0x5003FFB60x4 (4B)Unknown
 Sercomm Redboot Trailer0x5003FFBA0x4A (70B)SercommRedBootTrailer Sercomm RedBoot trailer?
Changed line 12 from:
 Sercomm Trailer0x507FFFF00x10 (16B)Sercomm trailer
to:
 Sercomm Flash Trailer0x507FFFF00x10 (16B)SercommFlashTrailer Sercomm flash trailer?
November 15, 2004, at 10:05 AM by dyoung --
Changed line 7 from:
 Unknown0x5003FFB60x4A (74B)Currently unknown
to:
 Unknown0x5003FFB60x4A (74B)See "SercommRedBootTrailer"
November 12, 2004, at 02:28 PM by tman --
Changed lines 6-7 from:
 MAC Address0x5003FFB00x6 (6B)The MAC address for NPE0? is stored here.
to:
 NPE0 MAC Address0x5003FFB00x6 (6B)The MAC address for NPE0 is stored here.
 Unknown0x5003FFB60x4A (74B)Currently unknown
November 12, 2004, at 03:59 AM by dyoung --
Changed lines 5-6 from:
/dev/mtdblock0RedBoot0x500000000x40000 (256K)This block contains the code from which the IXP420 boots.
 MAC Address0x5003ffb00x6 (6B)The MAC address for NPE0? is stored here.
to:
/dev/mtdblock0RedBoot0x500000000x3FFB0 (262064B)This block contains the code from which the IXP420 boots.
 MAC Address0x5003FFB00x6 (6B)The MAC address for NPE0? is stored here.
November 12, 2004, at 03:41 AM by dyoung --
Added line 6:
 MAC Address0x5003ffb00x6 (6B)The MAC address for NPE0? is stored here.
October 05, 2004, at 01:49 AM by tman --
Changed lines 8-9 from:
/dev/mtdblock3Ramdisk0x501600000x6A0000 (6.625MB)The ramdisk image for /
to:
/dev/mtdblock3Ramdisk0x501600000x69FFF0 (6946800B)The ramdisk image for /
 Sercomm Trailer0x507FFFF00x10 (16B)Sercomm trailer
September 26, 2004, at 04:52 PM by tman --
Changed lines 72-73 from:

- Write 16 bytes from offset 0x7ffff0 to "Trailer" (I don't know what this is yet...)

to:

- Write 16 bytes from offset 0x7ffff0 to "SercommFlashTrailer"

Changed line 91 from:

- copy "Trailer" to offset 0x7ffff0 of allocated array

to:

- copy "SercommFlashTrailer" to offset 0x7ffff0 of allocated array

Changed lines 101-107 from:

before it) then it wouldn't decompress correctly (truncated input to gunzip)

(The 16 byte magic values at offset 0x7ffff0 bother me still - they must represent something - the question is: are they important for re-flashing?)

to:

before it) then it wouldn't decompress correctly (truncated input to gunzip)

September 21, 2004, at 03:16 AM by tman --
Changed line 5 from:
/dev/mtdblock0RedBoot0x500000000x40000 (256K)The block contains the code from which the IXP420 boots.
to:
/dev/mtdblock0RedBoot0x500000000x40000 (256K)This block contains the code from which the IXP420 boots.
September 20, 2004, at 12:58 PM by tman --
Changed lines 3-26 from:
    *

mtdblock0 = "Redboot" (region size = 262144 bytes (256K))

      The block contains the code from which the IXP420 boots.
    *

mtdblock1 = "config" (region size = 131072 bytes (128K))

      Some explanation ....
    *

mtdblock2 = "vmlinuz" (region size = 1048576 bytes (1M))

      Some explanation ....
    *

mtdblock2 = "ramdisk" (region size = 6946816 bytes (6.625M) (remainder of 8M Flash))

      Some explanation ....
to:
Linux deviceTypeStart mem addrLengthDescription
/dev/mtdblock0RedBoot0x500000000x40000 (256K)The block contains the code from which the IXP420 boots.
/dev/mtdblock1System Configuration0x500400000x20000 (128K)The NSLU2 configuration e.g. IP address is stored here
/dev/mtdblock2Kernel0x500600000x100000 (1MB)The Linux kernel
/dev/mtdblock3Ramdisk0x501600000x6A0000 (6.625MB)The ramdisk image for /
September 13, 2004, at 05:41 AM by ka6sox --
Deleted lines 127-137:

Well, that's my first look at the device. Hopefully, I'll get some time to do some real hacking on this sometime soon.

BTW, a little bit about me/what I may be able to offer: I've done a lot of hacking on the Xbox (was part of original Xbox-Linux group, helped to crack Xbox 1.1 security). At work, we use an Intel IXP42x? chip in our product. We've got development boards, JTAG, etc (although I'm not the expert on this board/CPU, I could find out more info from others @ work)

September 13, 2004, at 05:40 AM by ka6sox --
Changed line 8 from:
      The block contains the code from which the IXP420 boots.
to:
      The block contains the code from which the IXP420 boots.
Changed line 31 from:

header. "mtdblock0" is what the IXP42x? boots from - there's no

to:

header. "mtdblock0" is what the IXP42x boots from - there's no

Changed line 36 from:

length, with the data immediately following that (offset 4 into the

to:

length, with the data immediately following that [=(offset 4 into the

Changed line 38 from:

following data (doesn't include size of 4-byte length)

to:

following data (doesn't include size of 4-byte length)=]

Changed lines 60-62 from:

But, why would "mtdblock1" be different (4-byte length immediately followed by data - no 12-byte 'header pad')? One reason could be that LinkSys?'s own code is probably what reads/writes

to:

But, why would "mtdblock1" be different (4-byte length immediately followed by data - no 12-byte 'header pad')? One reason could be that LinkSys's own code is probably what reads/writes

Changed line 69 from:

a little incorrect. The code update image from LinkSys? is an exact

to:

a little incorrect. The code update image from LinkSys is an exact

Changed lines 79-80 from:

of "SysConf?" image. Write that many bytes from offset 0x40004 to "SysConf?"

to:

of "SysConf" image. Write that many bytes from offset 0x40004 to "SysConf"

Changed lines 101-102 from:

- copy "SysConf?" to offset 0x40004 of allocated array, and store 4-byte length of "SysConf?" @ offset 0x40000

to:

- copy "SysConf" to offset 0x40004 of allocated array, and store 4-byte length of "SysConf" @ offset 0x40000

September 13, 2004, at 05:34 AM by ka6sox --
Changed line 139 from:

[http://groups.yahoo.com/group/nslu2-linux/message/33]

to:

[http://www.rwhitby.net/nslu2/boot-sequence.html][http://groups.yahoo.com/group/nslu2-linux/message/33]

September 13, 2004, at 05:32 AM by ka6sox --
Added lines 1-29:

The Flash memory is partitioned into 4 "/dev/mtdblock" devices:

    *

mtdblock0 = "Redboot" (region size = 262144 bytes (256K))

      The block contains the code from which the IXP420 boots.
    *

mtdblock1 = "config" (region size = 131072 bytes (128K))

      Some explanation ....
    *

mtdblock2 = "vmlinuz" (region size = 1048576 bytes (1M))

      Some explanation ....
    *

mtdblock2 = "ramdisk" (region size = 6946816 bytes (6.625M) (remainder of 8M Flash))

      Some explanation ....

September 13, 2004, at 05:28 AM by ka6sox --
Deleted lines 0-1:
Added lines 109-110:

[http://groups.yahoo.com/group/nslu2-linux/message/33]

September 13, 2004, at 05:27 AM by ka6sox --
Changed lines 1-110 from:

Describe BootFlash here.

to:

Depending on the type of data in an mtdblock, it may/may not have a header. "mtdblock0" is what the IXP42x? boots from - there's no header (there's no code running yet that could interpret a header - headers make sense on 'data' partitions).

As Jim Buzbee has pointed out, "mtdblock1" starts with a 4-byte length, with the data immediately following that (offset 4 into the partition). The 4-byte length value reflects the length of the following data (doesn't include size of 4-byte length)

"mtdblock2" and "mtdblock3" appear to have 16-byte headers. They start with a 4-byte length, followed by 12 zeros. I'm not 100% sure what the length represents here.

It's clear to me that the 4-byte length on "mtdblock3" represents the size of the upcoming data (after the 16-byte header). If you look at offset "length + 16" into "mtdblock3", you'll start to see zeros (and, there's a non-zero value just before that)

But, it's less clear on "mtdblock2". If you look at offset "length + 4", you start to see zeros (and there's a non-zero value just before that). It's possible that the image data in "mtdblock2" ends with zeros, and the definition of "length" here is the same as in "mtdblock3".

So, if we assume that the raw data stored in "mtdblock2" actually ends with some zeros, then we can interpret the "length" at the start to mean the length of the data immediately following the 16- byte header (just like "mtdblock3").

But, why would "mtdblock1" be different (4-byte length immediately followed by data - no 12-byte 'header pad')? One reason could be that LinkSys?'s own code is probably what reads/writes to "mtdblock1", where standard Linux code is reading/writing "mtdblock2/3". I don't know - it's just speculation.

I believe that some of the 'header/trailer' stuff in 'splitnslu' is a little incorrect. The code update image from LinkSys? is an exact 8MByte image of the entire flash (the 4 partitions concatenated together).

So, I think the "HEADER_OFFSET/HEADER_LENGTH" stuff is incorrect. "splitnslu" should do the following, I think:

- write first 262144 (0x40000) bytes to "Redboot"

- Grab 4-byte value @ offset 0x40000, use that as length of "SysConf?" image. Write that many bytes from offset 0x40004 to "SysConf?"

- Grab 4-byte value @ offset 0x60000 (262144+131072), use that as length of "vmlinuz" image. Write that many bytes from offset 0x60010 to "vmlinuz"

- Grab 4-byte value @ offset 0x160000 (262144+131072+1048576), use that as length of "ramdisk.gz" image. Write that many bytes from offset 0x160010 to "ramdisk.gz"

- Write 16 bytes from offset 0x7ffff0 to "Trailer" (I don't know what this is yet...)

To re-assemble (pack):

- allocate 8MByte image, memset to zero to be safe

- copy "Redboot" to offset 0 of allocated array

- copy "SysConf?" to offset 0x40004 of allocated array, and store 4-byte length of "SysConf?" @ offset 0x40000

- copy "vmlinuz" to offset 0x60010 of allocated array, and store 4-byte length of "vmlinuz" @ offset 0x60000

- copy "ramdisk.gz" to offset 0x160010 of allocated array, and store 4-byte length of "ramdisk.gz" @ offset 0x160000

- copy "Trailer" to offset 0x7ffff0 of allocated array

- write allocated array (8MBytes) to an output .bin file

NOTE: Because of the mis-interpretation of 'headers' in splitnslu, it's possible that things could be patched/put back together and actually work (unlike what author Brian Lantz found). For example, if the resulting modified "ramdisk.gz" image had a different (larger) byte size than the original (stored the 4-byte header just before it) then it wouldn't decompress correctly (truncated input to gunzip)

(The 16 byte magic values at offset 0x7ffff0 bother me still - they must represent something - the question is: are they important for re-flashing?)

Well, that's my first look at the device. Hopefully, I'll get some time to do some real hacking on this sometime soon.

BTW, a little bit about me/what I may be able to offer: I've done a lot of hacking on the Xbox (was part of original Xbox-Linux group, helped to crack Xbox 1.1 security). At work, we use an Intel IXP42x? chip in our product. We've got development boards, JTAG, etc (although I'm not the expert on this board/CPU, I could find out more info from others @ work)

view · edit · print · history · Last edited by tman.
Based on work by jbowler, tman, dyoung, and ka6sox.
Originally by ka6sox.
Page last modified on August 25, 2005, at 01:27 PM