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

RE: [nslu2-linux] Info on mtd partitions/possible problem with splitnslu utility

Expand Messages
  • 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 1 of 7 , Aug 10, 2004
      > 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 2 of 7 , Aug 10, 2004
        --- 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 3 of 7 , Aug 10, 2004
          > - 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 4 of 7 , Aug 10, 2004
            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 5 of 7 , Aug 10, 2004
              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 6 of 7 , Aug 10, 2004
                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.