Loading ...
Sorry, an error occurred while loading the content.

Info on mtd partitions/possible problem with splitnslu utility

Expand Messages
  • paulbart1234
    Hi - I ve just recently purchased the NSLU2. Tonight, I decided to see what I could learn via telnet. I believe the following is true (some of this is a
    Message 1 of 7 , Aug 9, 2004
    • 0 Attachment
      Hi -

      I've just recently purchased the NSLU2. Tonight, I decided to see
      what I could learn via telnet.

      I believe the following is true (some of this is a repeat/variation
      on what has already been discovered):

      - Flash memory is 8MBytes

      - Flash is broken up into 4 "/dev/mtdblock" devices:
      - mtdblock0 = "Redboot" (region size=262144 bytes (256K))
      - mtdblock1 = "config" (region size=131072 bytes (128K))
      - mtdblock2 = "vmlinuz" (region size=1048576 bytes (1M))
      - mtdblock2 = "ramdisk" (region size=6946816 bytes (6.625M)
      (remainder of 8M Flash))





      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)

      Happy hacking everyone!

      - Paulb
    • Brian
      ... A PERFECT example of why Open Source is so successful! More than one set of eyes on something, makes it better! I started with the same idea, but got
      Message 2 of 7 , Aug 10, 2004
      • 0 Attachment
        > 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).

        A PERFECT example of why Open Source is so successful! More than one
        set of eyes on something, makes it better!

        I started with the same idea, but got misled by a couple of things. That added to NOT looking at the partition data directly (yet), and
        I missed a couple of clues...

        Oh well, since it was written in about 1 hour from scratch ;-)

        I'm going right now to modify the app, and try (again) to reload a modified image (fingers crossed).....

        Back soon!

        Brian

        _______________________________________________
        No banners. No pop-ups. No kidding.
        Make My Way your home on the Web - http://www.myway.com
      • paulbart1234
        ... modified image (fingers crossed)..... ... I m looking forward to hearing the results! - Paulb
        Message 3 of 7 , Aug 10, 2004
        • 0 Attachment
          --- In nslu2-linux@yahoogroups.com, "Brian" <toyseeker@m...> wrote:
          > I'm going right now to modify the app, and try (again) to reload a
          modified image (fingers crossed).....
          >
          > Back soon!

          I'm looking forward to hearing the results!

          - Paulb
        • paulbart1234
          ... Because of my confusion over what the 4-byte length value represents on this mtdblock (whether/not it includes the 16-byte header), I m concerned that if
          Message 4 of 7 , Aug 10, 2004
          • 0 Attachment
            > - copy "vmlinuz" to offset 0x60010 of allocated array, and
            > store 4-byte length of "vmlinuz" @ offset 0x60000

            Because of my confusion over what the 4-byte 'length' value
            represents on this mtdblock (whether/not it includes the 16-byte
            header), I'm concerned that if a *new* 'vmlinuz' file were
            created/re-packed into the image, the 'length' value may not be
            correct.

            In that case, you may want to 'pad' the length value by 12 bytes.

            But, keep in mind that if you extracted 'vmlinuz' from a .bin image
            with the assumption of the 16-byte header, then the length
            of 'vmlinuz' would be correct already (so you wouldn't want to 'pad'
            the length - otherwise it would 'grow' every time you
            unpacked/repacked).

            Isn't 'vmlinuz' a compressed form of 'vmlinux'? (I remember that
            from a long time ago). If we can decompress it, we can determine
            the actual length, and know what the 4-byte 'length' value should
            represent.

            - Paulb
          • joule360
            Yes, vmlinuz is a compressed vmlinux...in fact, when you boot linux on a non-embedded systme, the first message you see on the console is that the kernel is
            Message 5 of 7 , Aug 10, 2004
            • 0 Attachment
              Yes, vmlinuz is a compressed vmlinux...in fact, when you boot linux
              on a non-embedded systme, the first message you see on the console is
              that the kernel is being decompressed. Reviewing the make files for
              the kernel build will show us what program is used for the
              compression. I cannot do that here at work...


              --- In nslu2-linux@yahoogroups.com, "paulbart1234" <paulbart@b...>
              wrote:
              > > - copy "vmlinuz" to offset 0x60010 of allocated array, and
              > > store 4-byte length of "vmlinuz" @ offset 0x60000
              >
              > Because of my confusion over what the 4-byte 'length' value
              > represents on this mtdblock (whether/not it includes the 16-byte
              > header), I'm concerned that if a *new* 'vmlinuz' file were
              > created/re-packed into the image, the 'length' value may not be
              > correct.
              >
              > In that case, you may want to 'pad' the length value by 12 bytes.
              >
              > But, keep in mind that if you extracted 'vmlinuz' from a .bin image
              > with the assumption of the 16-byte header, then the length
              > of 'vmlinuz' would be correct already (so you wouldn't want
              to 'pad'
              > the length - otherwise it would 'grow' every time you
              > unpacked/repacked).
              >
              > Isn't 'vmlinuz' a compressed form of 'vmlinux'? (I remember that
              > from a long time ago). If we can decompress it, we can determine
              > the actual length, and know what the 4-byte 'length' value should
              > represent.
              >
              > - Paulb
            • David Mitchell
              I believe it uses the command bzip2 . Not sure if gzip is compatible or not. -dave ... __________________________________ Do you Yahoo!? New and Improved
              Message 6 of 7 , Aug 10, 2004
              • 0 Attachment
                I believe it uses the command "bzip2". Not sure if
                gzip is compatible or not.

                -dave


                --- joule360 <joule360@...> wrote:

                > Reviewing the
                > make files for
                > the kernel build will show us what program is used
                > for the
                > compression. I cannot do that here at work...
                >




                __________________________________
                Do you Yahoo!?
                New and Improved Yahoo! Mail - Send 10MB messages!
                http://promotions.yahoo.com/new_mail
              • paulbart1234
                It seems that gzip is used for compressing vmlinuz. I did a Google search, and found that the hex bytes 1F 8B 08 00 are the magic # for the start of a
                Message 7 of 7 , Aug 10, 2004
                • 0 Attachment
                  It seems that 'gzip' is used for compressing vmlinuz.

                  I did a Google search, and found that the hex bytes '1F 8B 08 00'
                  are the 'magic #' for the start of a gzip file.

                  I found that sequence at offset 0x2dd4 in vmlinuz (the first 0x2dd4
                  bytes are the boot loader that has the gunzip code to decompress
                  vmlinuz).

                  To decompress into vmlinux, skip the first 0x2dd4 (11732) bytes and
                  pass the rest through gunzip. Use a command like:

                  dd if=vmlinuz bs=1 skip=11732 | zcat > vmlinux

                  You should see output like:
                  855028+0 records in
                  855028+0 records out

                  zcat: stdin: decompression OK, trailing garbage ignored

                  (key is: "decompression OK" - it's OK to see the 'trailing garbage'
                  warning)

                  'vmlinux' is the decompressed kernel image - run 'strings' on it for
                  a quick glimpse into what's inside it.

                  - Paulb


                  --- In nslu2-linux@yahoogroups.com, David Mitchell <gossiphog@y...>
                  wrote:
                  >
                  > I believe it uses the command "bzip2". Not sure if
                  > gzip is compatible or not.
                  >
                  > -dave
                  >
                  >
                  > --- joule360 <joule360@y...> wrote:
                  >
                  > > Reviewing the
                  > > make files for
                  > > the kernel build will show us what program is used
                  > > for the
                  > > compression. I cannot do that here at work...
                  > >
                  >
                  >
                  >
                  >
                  > __________________________________
                  > Do you Yahoo!?
                  > New and Improved Yahoo! Mail - Send 10MB messages!
                  > http://promotions.yahoo.com/new_mail
                Your message has been successfully submitted and would be delivered to recipients shortly.