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

Re: [nslu2-linux] slugimage issue or operator error?

Expand Messages
  • Rod Whitby
    ... Note that slugimage has a regression test suite in: http://svn.nslu2-linux.org/svnroot/slugimage/trunk/tests/ So if you find a case that doesn t work,
    Message 1 of 10 , May 5, 2008
    • 0 Attachment
      Rod Whitby wrote:
      > Try just:
      >
      > slugimage -F -p -o test.bin -L apex.bin -k vmlinuz -r Flashdisk
      >
      > If that works, then start adding options until you find the one that
      > breaks it.

      Note that slugimage has a regression test suite in:

      http://svn.nslu2-linux.org/svnroot/slugimage/trunk/tests/

      So if you find a case that doesn't work, please add it to there (or send
      me the testcase so I can add it).

      [I note that I don't have any tests that use -F in there at the moment,
      so it won't be a surprise if something doesn't work - if someone want to
      write some -F test cases I'll happily add them.]

      -- Rod
    • Rob Lockhart
      [apologies for long debugging output] ... Hmm, looks like this won t go very far: [slug@Linux ~/tmp]$ slugimage -F -p -o test.bin -L apex.bin -k vmlinuz -r
      Message 2 of 10 , May 5, 2008
      • 0 Attachment
        [apologies for long debugging output]

        On Mon, May 5, 2008 at 5:15 AM, Rod Whitby <rod@...> wrote:
        >
        > Rob Lockhart wrote:
        > > Hello, group. I just finished going through and updating the Wiki
        > > instructions for CentOS, and everything seems to build fine. Except I
        > > need to replace the MAC address, obviously (using slugimage). The
        > > build image is "slugosbe-4.10-alpha-nslu2-16mb.bin". Note I replaced
        > > the last octet of my MAC address with "XX".
        > >
        > > First I disassemble the image:
        > >
        > Try just:
        >
        > slugimage -F -p -o test.bin -L apex.bin -k vmlinuz -r Flashdisk
        >
        > If that works, then start adding options until you find the one that
        > breaks it.

        Hmm, looks like this won't go very far:

        [slug@Linux ~/tmp]$ slugimage -F -p -o test.bin -L apex.bin -k vmlinuz
        -r Flashdisk
        Read 0x00040000 bytes from "RedBoot" into <RedBoot> (2 blocks / 2 blocks)
        Read 0x00020000 bytes from "SysConf" into <SysConf> (1 blocks / 1 blocks)
        Read 0x0000BE28 bytes from "apex.bin" into <Loader> (1 blocks / 1 blocks)
        Read 0x00101A74 bytes from "vmlinuz" into <Kernel> (9 blocks / 9 blocks)
        Read 0x00E40000 bytes from "Flashdisk" into <Ramdisk> (115 blocks / 115 blocks)
        Read 0x00002EBC bytes from "NPE-B" into <Microcode> (0x02ECC bytes /
        0x03FE0 bytes)
        Read 0x00000010 bytes from "Trailer" into <Trailer> (0x00010 bytes /
        0x00010 bytes)
        Ran out of flash space in <Ramdisk> - 0x00010 bytes too large.

        I currently did a "make distclean" and rebuilding again from scratch.
        I'll try the disassembly and re-assembly again once the image is
        rebuilt.

        Note that with the debug statements, the disassembly doesn't show a
        Ramdisk. Disassembly with -d option:

        [slug@Linux ~/tmp]$ slugimage -d -u -F -i slugosbe-4.10-alpha-nslu2-16mb.bin
        Initial partition map:
        RedBoot 0x00000000 0x00040000
        EthAddr 0x0003FFB0 0x00000006
        SysConf 0x00040000 0x00020000
        Loader (undefined) (undefined)
        Kernel (undefined) (undefined)
        Ramdisk (undefined) (undefined)
        FIS directory 0x00FE0000 0x00020000
        Loader config 0x00FF8000 0x00004000
        Microcode 0x00FFC000 0x00003FE0
        Trailer 0x00FFFFF0 0x00000010
        Read 0x01000000 bytes from "slugosbe-4.10-alpha-nslu2-16mb.bin"
        Found <RedBoot> at 0x00000000 (2 blocks)
        Found <SysConf> at 0x00040000 (1 blocks)
        Found skip region at 0x00000, size 0x00010
        Found <Loader> at 0x00060000 (1 blocks) [0x00000/0x00010]
        Found skip region at 0x00000, size 0x00010
        Found skip region at 0xE0000, size 0x00010
        Found <Kernel> at 0x00080000 (9 blocks) [0x00000/0x00010, 0xE0000/0x00010]
        Found <Flashdisk> at 0x001A0000 (114 blocks)
        Found <FIS directory> at 0x00FE0000 (1 blocks)
        Found terminator for <FIS directory>
        Locating <RedBoot> at 0x00000000 (2 blocks)
        Skipped <EthAddr> (pseudo partition)
        Locating <SysConf> at 0x00040000 (1 blocks)
        Locating <Loader> at 0x00060000 (1 blocks)
        Locating <Kernel> at 0x00080000 (9 blocks)
        Splicing new partition <Flashdisk> before <Ramdisk>
        Locating <Flashdisk> at 0x001A0000 (114 blocks)
        Splicing new partition <FIS directory> before <Ramdisk>
        Locating <FIS directory> at 0x00FE0000 (1 blocks)
        Read 2 blocks into <RedBoot>
        Read 0x00006 bytes into <EthAddr>
        Read 1 blocks into <SysConf>
        Found header size of 0x0000BE28 bytes for <Loader>
        Read 0x0BE28 bytes into <Loader>
        Found header size of 0x00101A84 bytes for <Kernel>
        Removing 0x00010 bytes from offset 0xE0000
        Read 9 blocks into <Kernel>
        Read 114 blocks into <Flashdisk>
        Read 1 blocks into <FIS directory>
        Read 1 blocks into <FIS directory>
        Skipping empty pseudo partition <Loader config>
        Found header size of 0x00002EBC bytes for <Microcode>
        Read 0x02EBC bytes into <Microcode>
        Read 0x00010 bytes into <Trailer>
        After reading firmware:
        RedBoot 0x00000000 0x00040000
        EthAddr 0x0003FFB0 0x00000006
        SysConf 0x00040000 0x00020000
        Loader 0x00060000 0x00020000 [0x00000/0x00010]
        Kernel 0x00080000 0x00120000 [0x00000/0x00010,
        0xE0000/0x00010]
        Flashdisk 0x001A0000 0x00E40000
        FIS directory 0x00FE0000 0x00020000
        Ramdisk (undefined) (undefined)
        FIS directory 0x00FE0000 0x00020000
        Loader config 0x00FF8000 0x00004000
        Microcode 0x00FFC000 0x00003FE0
        Trailer 0x00FFFFF0 0x00000010
        Wrote 0x00040000 bytes from <RedBoot> into "RedBoot"
        Skipping <EthAddr> (no filename specified)
        Wrote 0x00020000 bytes from <SysConf> into "SysConf"
        Wrote 0x0000BE28 bytes from <Loader> into "apex.bin"
        Wrote 0x00101A74 bytes from <Kernel> into "vmlinuz"
        Wrote 0x00E40000 bytes from <Flashdisk> into "Flashdisk"
        Wrote 0x00020000 bytes from <FIS directory> into "FIS directory"
        Skipping <Ramdisk> (no data to write)
        Skipping <FIS directory> (no filename specified)
        Skipping <Loader config> (no filename specified)
        Wrote 0x00002EBC bytes from <Microcode> into "NPE-B"
        Wrote 0x00000010 bytes from <Trailer> into "Trailer"

        See the interesting "Found SkipRegion" with same size as overflow (10
        bytes) - coincidence? Also note it's skipping Ramdisk but yet the
        option is specified when re-assembling, if Ramdisk is different than
        Flashdisk.

        Regards,
        -Rob
      • Rob Lockhart
        ... Interesting, I went to the URL above. http://svn.nslu2-linux.org/svnroot/slugimage/trunk/tests/slugos/ looking at file: large-flashdisk.expected shows: Ran
        Message 3 of 10 , May 5, 2008
        • 0 Attachment
          On Mon, May 5, 2008 at 5:21 AM, Rod Whitby <rod@...> wrote:
          > Note that slugimage has a regression test suite in:
          >
          > http://svn.nslu2-linux.org/svnroot/slugimage/trunk/tests/
          >
          > So if you find a case that doesn't work, please add it to there (or send
          > me the testcase so I can add it).
          >
          > [I note that I don't have any tests that use -F in there at the moment,
          > so it won't be a surprise if something doesn't work - if someone want to
          > write some -F test cases I'll happily add them.]

          Interesting, I went to the URL above.
          http://svn.nslu2-linux.org/svnroot/slugimage/trunk/tests/slugos/
          looking at file:
          large-flashdisk.expected

          shows:

          Ran out of flash space in <Flashdisk> - 0x00010 bytes too large.

          Same error message I'm getting. Coincidence?

          Thanks for your help,
          -Rob
        • Rod Whitby
          ... Nope, it just means that your flashdisk file that you are providing to slugimage is 16 bytes too large. There is a 16 byte length header that is prepended
          Message 4 of 10 , May 5, 2008
          • 0 Attachment
            Rob Lockhart wrote:
            > Interesting, I went to the URL above.
            > http://svn.nslu2-linux.org/svnroot/slugimage/trunk/tests/slugos/
            > looking at file:
            > large-flashdisk.expected
            >
            > shows:
            >
            > Ran out of flash space in <Flashdisk> - 0x00010 bytes too large.
            >
            > Same error message I'm getting. Coincidence?

            Nope, it just means that your flashdisk file that you are providing to
            slugimage is 16 bytes too large.

            There is a 16 byte length header that is prepended to the kernel and
            ramdisks that you provide to slugimage before they are put in the flash
            image (this is required by the vendor RedBoot). If you provide files
            that are the exact size of the flash partitions, then they will actually
            by 16 bytes too large due to this header which must be prepended.

            So you need to work out why your Flashdisk file is too large.

            -- Rod
          • Rod Whitby
            ... I just checked in some regression tests for -F and added unpacking and repacking to all existing tests - and found a small bug. I don t think it s the
            Message 5 of 10 , May 5, 2008
            • 0 Attachment
              Rod Whitby wrote:
              > Rod Whitby wrote:
              >> Try just:
              >>
              >> slugimage -F -p -o test.bin -L apex.bin -k vmlinuz -r Flashdisk
              >>
              >> If that works, then start adding options until you find the one that
              >> breaks it.
              >
              > Note that slugimage has a regression test suite in:
              >
              > http://svn.nslu2-linux.org/svnroot/slugimage/trunk/tests/
              >
              > So if you find a case that doesn't work, please add it to there (or send
              > me the testcase so I can add it).
              >
              > [I note that I don't have any tests that use -F in there at the moment,
              > so it won't be a surprise if something doesn't work - if someone want to
              > write some -F test cases I'll happily add them.]

              I just checked in some regression tests for -F and added unpacking and
              repacking to all existing tests - and found a small bug. I don't think
              it's the cause of your problem, but you might want to try the latest
              slugimage from svn trunk.

              -- Rod
            • Rod Whitby
              ... I finally realised the problem - you re asking slugimage to put a jffs2 Flashdisk partition into the predefined Ramdisk partition. That won t work,
              Message 6 of 10 , May 6, 2008
              • 0 Attachment
                Rob Lockhart wrote:
                > [apologies for long debugging output]
                >
                > On Mon, May 5, 2008 at 5:15 AM, Rod Whitby <rod@...> wrote:
                >> Rob Lockhart wrote:
                >> > Hello, group. I just finished going through and updating the Wiki
                >> > instructions for CentOS, and everything seems to build fine. Except I
                >> > need to replace the MAC address, obviously (using slugimage). The
                >> > build image is "slugosbe-4.10-alpha-nslu2-16mb.bin". Note I replaced
                >> > the last octet of my MAC address with "XX".
                >> >
                >> > First I disassemble the image:
                >> >
                >> Try just:
                >>
                >> slugimage -F -p -o test.bin -L apex.bin -k vmlinuz -r Flashdisk
                >>
                >> If that works, then start adding options until you find the one that
                >> breaks it.
                >
                > Hmm, looks like this won't go very far:
                >
                > [slug@Linux ~/tmp]$ slugimage -F -p -o test.bin -L apex.bin -k vmlinuz
                > -r Flashdisk
                > Read 0x00040000 bytes from "RedBoot" into <RedBoot> (2 blocks / 2 blocks)
                > Read 0x00020000 bytes from "SysConf" into <SysConf> (1 blocks / 1 blocks)
                > Read 0x0000BE28 bytes from "apex.bin" into <Loader> (1 blocks / 1 blocks)
                > Read 0x00101A74 bytes from "vmlinuz" into <Kernel> (9 blocks / 9 blocks)
                > Read 0x00E40000 bytes from "Flashdisk" into <Ramdisk> (115 blocks / 115 blocks)
                > Read 0x00002EBC bytes from "NPE-B" into <Microcode> (0x02ECC bytes /
                > 0x03FE0 bytes)
                > Read 0x00000010 bytes from "Trailer" into <Trailer> (0x00010 bytes /
                > 0x00010 bytes)
                > Ran out of flash space in <Ramdisk> - 0x00010 bytes too large.

                I finally realised the problem - you're asking slugimage to put a jffs2
                Flashdisk partition into the predefined Ramdisk partition. That won't
                work, because a Ramdisk needs the length header, whereas a Flashdisk
                doesn't.

                I've added code to slugimage to catch this specific situation and give a
                better error message:

                $ ./slugimage -F -p -o slugosbe-4.10-alpha-nslu2-16mb.bin -L apex.bin -r
                Flashdisk
                Read 0x00040000 bytes from "RedBoot" into <RedBoot> (2 blocks / 2 blocks)
                Read 0x00020000 bytes from "SysConf" into <SysConf> (1 blocks / 1 blocks)
                Read 0x0000BE28 bytes from "apex.bin" into <Loader> (1 blocks / 1 blocks)
                Read 0x00101A88 bytes from "vmlinuz" into <Kernel> (9 blocks / 9 blocks)
                Read 0x00E40000 bytes from "Flashdisk" into <Ramdisk> (115 blocks / 115
                blocks)
                Read 0x00002EBC bytes from "NPE-B" into <Microcode> (0x02ECC bytes /
                0x03FE0 bytes)
                Read 0x00000010 bytes from "Trailer" into <Trailer> (0x00010 bytes /
                0x00010 bytes)
                Ran out of flash space in <Ramdisk> - 0x00010 bytes too large.
                Perhaps you meant to use the -r Flashdisk:<filename> syntax instead?

                What you need to do is:

                $ slugimage -F -p -o test.bin -L apex.bin -k vmlinuz -r Flashdisk:Flashdisk

                This tells slugimage that you're giving it a Flashdisk partition, with
                the contents in the Flashdisk filename. Slugimage then removes the
                requirement for a partition header (since you're not giving it a
                Ramdisk, and it's already added a skip region in the previous partition
                for the special 16 bytes at 0x160000), and this means the sizes now match:

                $ ./slugimage -F -p -o slugosbe-4.10-alpha-nslu2-16mb.bin -L apex.bin -r
                Flashdisk:Flashdisk
                Read 0x00040000 bytes from "RedBoot" into <RedBoot> (2 blocks / 2 blocks)
                Read 0x00020000 bytes from "SysConf" into <SysConf> (1 blocks / 1 blocks)
                Read 0x0000BE28 bytes from "apex.bin" into <Loader> (1 blocks / 1 blocks)
                Read 0x00101A88 bytes from "vmlinuz" into <Kernel> (9 blocks / 9 blocks)
                Read 0x00E40000 bytes from "Flashdisk" into <Flashdisk> (114 blocks /
                114 blocks)
                Read 0x00002EBC bytes from "NPE-B" into <Microcode> (0x02ECC bytes /
                0x03FE0 bytes)
                Read 0x00000010 bytes from "Trailer" into <Trailer> (0x00010 bytes /
                0x00010 bytes)
                Wrote 2 blocks (0x00000000 to 0x00040000) from <RedBoot> into
                "slugosbe-4.10-alpha-nslu2-16mb.bin"
                Wrote 1 blocks (0x00040000 to 0x00060000) from <SysConf> into
                "slugosbe-4.10-alpha-nslu2-16mb.bin"
                Wrote 1 blocks (0x00060000 to 0x00080000) from <Loader> into
                "slugosbe-4.10-alpha-nslu2-16mb.bin"
                Wrote 9 blocks (0x00080000 to 0x001A0000) from <Kernel> into
                "slugosbe-4.10-alpha-nslu2-16mb.bin"
                Wrote 114 blocks (0x001A0000 to 0x00FE0000) from <Flashdisk> into
                "slugosbe-4.10-alpha-nslu2-16mb.bin"
                Wrote 1 blocks (0x00FE0000 to 0x01000000) from <FIS directory> into
                "slugosbe-4.10-alpha-nslu2-16mb.bin"
                Wrote 0x03FE0 bytes (0x00FFC000 to 0x00FFFFE0) from <Microcode> into
                "slugosbe-4.10-alpha-nslu2-16mb.bin"
                Wrote 0x00010 bytes (0x00FFFFF0 to 0x01000000) from <Trailer> into
                "slugosbe-4.10-alpha-nslu2-16mb.bin"

                -- Rod
              • Rob Lockhart
                ... Thanks for the help, Rod. I modified the Slugimage wiki. Glad it was PEBKAC. -Rob
                Message 7 of 10 , May 7, 2008
                • 0 Attachment
                  On Tue, May 6, 2008 at 9:56 AM, Rod Whitby <rod@...> wrote:
                  >
                  > Rob Lockhart wrote:
                  > > [apologies for long debugging output]
                  > >
                  > > On Mon, May 5, 2008 at 5:15 AM, Rod Whitby <rod@...> wrote:
                  > >> Rob Lockhart wrote:
                  > >> > Hello, group. I just finished going through and updating the Wiki
                  > >> > instructions for CentOS, and everything seems to build fine. Except I
                  > >> > need to replace the MAC address, obviously (using slugimage). The
                  > >> > build image is "slugosbe-4.10-alpha-nslu2-16mb.bin". Note I replaced
                  > >> > the last octet of my MAC address with "XX".
                  > >> >
                  > >> > First I disassemble the image:
                  > >> >
                  > >> Try just:
                  > >>
                  > >> slugimage -F -p -o test.bin -L apex.bin -k vmlinuz -r Flashdisk
                  > >>
                  > >> If that works, then start adding options until you find the one that
                  > >> breaks it.
                  > >
                  > > Hmm, looks like this won't go very far:
                  > >
                  > > [slug@Linux ~/tmp]$ slugimage -F -p -o test.bin -L apex.bin -k vmlinuz
                  > > -r Flashdisk
                  > > Read 0x00040000 bytes from "RedBoot" into <RedBoot> (2 blocks / 2 blocks)
                  > > Read 0x00020000 bytes from "SysConf" into <SysConf> (1 blocks / 1 blocks)
                  > > Read 0x0000BE28 bytes from "apex.bin" into <Loader> (1 blocks / 1 blocks)
                  > > Read 0x00101A74 bytes from "vmlinuz" into <Kernel> (9 blocks / 9 blocks)
                  > > Read 0x00E40000 bytes from "Flashdisk" into <Ramdisk> (115 blocks / 115 blocks)
                  > > Read 0x00002EBC bytes from "NPE-B" into <Microcode> (0x02ECC bytes /
                  > > 0x03FE0 bytes)
                  > > Read 0x00000010 bytes from "Trailer" into <Trailer> (0x00010 bytes /
                  > > 0x00010 bytes)
                  > > Ran out of flash space in <Ramdisk> - 0x00010 bytes too large.
                  >
                  > I finally realised the problem - you're asking slugimage to put a jffs2
                  > Flashdisk partition into the predefined Ramdisk partition. That won't
                  > work, because a Ramdisk needs the length header, whereas a Flashdisk
                  > doesn't.
                  >
                  > I've added code to slugimage to catch this specific situation and give a
                  > better error message:
                  >
                  > $ ./slugimage -F -p -o slugosbe-4.10-alpha-nslu2-16mb.bin -L apex.bin -r
                  >
                  > Flashdisk
                  > Read 0x00040000 bytes from "RedBoot" into <RedBoot> (2 blocks / 2 blocks)
                  > Read 0x00020000 bytes from "SysConf" into <SysConf> (1 blocks / 1 blocks)
                  > Read 0x0000BE28 bytes from "apex.bin" into <Loader> (1 blocks / 1 blocks)
                  > Read 0x00101A88 bytes from "vmlinuz" into <Kernel> (9 blocks / 9 blocks)
                  >
                  > Read 0x00E40000 bytes from "Flashdisk" into <Ramdisk> (115 blocks / 115
                  > blocks)
                  > Read 0x00002EBC bytes from "NPE-B" into <Microcode> (0x02ECC bytes /
                  > 0x03FE0 bytes)
                  > Read 0x00000010 bytes from "Trailer" into <Trailer> (0x00010 bytes /
                  > 0x00010 bytes)
                  > Ran out of flash space in <Ramdisk> - 0x00010 bytes too large.
                  > Perhaps you meant to use the -r Flashdisk:<filename> syntax instead?
                  >
                  > What you need to do is:
                  >
                  > $ slugimage -F -p -o test.bin -L apex.bin -k vmlinuz -r Flashdisk:Flashdisk
                  >
                  > This tells slugimage that you're giving it a Flashdisk partition, with
                  > the contents in the Flashdisk filename. Slugimage then removes the
                  > requirement for a partition header (since you're not giving it a
                  > Ramdisk, and it's already added a skip region in the previous partition
                  > for the special 16 bytes at 0x160000), and this means the sizes now match:
                  >
                  > $ ./slugimage -F -p -o slugosbe-4.10-alpha-nslu2-16mb.bin -L apex.bin -r
                  > Flashdisk:Flashdisk
                  >
                  > Read 0x00040000 bytes from "RedBoot" into <RedBoot> (2 blocks / 2 blocks)
                  > Read 0x00020000 bytes from "SysConf" into <SysConf> (1 blocks / 1 blocks)
                  > Read 0x0000BE28 bytes from "apex.bin" into <Loader> (1 blocks / 1 blocks)
                  > Read 0x00101A88 bytes from "vmlinuz" into <Kernel> (9 blocks / 9 blocks)
                  > Read 0x00E40000 bytes from "Flashdisk" into <Flashdisk> (114 blocks /
                  > 114 blocks)

                  Thanks for the help, Rod. I modified the Slugimage wiki. Glad it was PEBKAC.

                  -Rob
                Your message has been successfully submitted and would be delivered to recipients shortly.