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

Re: Fatslug 256MB

Expand Messages
  • nww
    ... out). ... kernel ... without ... available ... Hi, When I do a file ramdisk.gz, it gives me the below output instead of Linux Compressed ROM File System
    Message 1 of 28 , Oct 1, 2006
      --- In nslu2-linux@yahoogroups.com, kinsa <kinsa_manka@...> wrote:
      >
      > stjopa666 wrote:
      > > But you dont get system lockups or data corruption? I could cope with
      > > some error messages if the system is stable (at least till .18 is
      out).
      > >
      > > BTW which kernel patch did you mean, couldnt find anything about it in
      > > the .18rc2 changelog.
      >
      > I had commented out the line that spews out the error message in the
      kernel
      > source and the recompiled kernel ran smoothly for more than a month
      without
      > problems.
      >
      > BTW, I was running ctorrent during that period which used up all the
      available
      > ram (128Mb).
      >
      > Kinsa
      >

      Hi,

      When I do a file ramdisk.gz, it gives me the below output instead of
      Linux Compressed ROM File System data, big endian as described in
      TestAnImageInRamUsingRedBoot. Does anyone have any idea? It suspected
      that why I can't load the image.


      root@lemon:~/images# ls -l
      total 46852
      -rw-r--r-- 1 root root 262144 Sep 30 15:32 Redbook
      -rw-r--r-- 1 root root 0 Sep 30 15:32 SysConf
      -rw-r--r-- 1 root root 16 Sep 30 15:32 Trailer
      -rw-rw-r-- 1 cyrus 500 8388608 Oct 1 2006
      openslug-nslu2-20061001004539.flashdisk.img
      -rw-r--r-- 1 cyrus 500 5111808 Oct 1 2006
      openslug-nslu2-20061001004539.rootfs.jffs2
      -rw-r--r-- 1 root root 131056 Sep 30 15:32 ramdisk.gz
      -rw-r--r-- 1 root root 992504 Sep 30 15:32 vmlinuz
      -rw-rw-r-- 1 cyrus 500 992504 Sep 30 11:32 zImage-ds101be
      -rw-rw-r-- 1 cyrus 500 992504 Sep 30 11:32 zImage-dsmg600be
      -rw-rw-r-- 1 cyrus 500 992496 Sep 30 11:32 zImage-ixp4xxbe
      -rw-rw-r-- 1 cyrus 500 992504 Sep 30 11:32 zImage-loftbe
      -rw-rw-r-- 1 cyrus 500 992504 Sep 30 11:32 zImage-nas100dbe
      -rw-rw-r-- 1 cyrus 500 992504 Sep 30 11:32 zImage-nslu2be
      root@lemon:~/images# file ramdisk.gz
      ramdisk.gz: ISO-8859 text, with very long lines, with no line terminators
      root@lemon:~/images#
    • Rod Whitby
      What you have ther is the dummy ramdisk.gz partition which we put in flashdisk-based images to stop the Linksys redboot boot command from copying invalid
      Message 2 of 28 , Oct 1, 2006
        What you have ther is the dummy ramdisk.gz partition which we put in flashdisk-based images to stop the Linksys redboot "boot" command from copying invalid data all over memory when it tries to load a ramdisk into ram.
        You want to give a "-r Ramdisk:ramdisk.gz,Flashdisk:flashdisk.jffs2" option to slugimage to unpack a flashdisk-based image. Please add that to whatever wiki page you used to find out how to unpack the image.
        -- Rod

        -----Original Message-----
        From: "nww" <csnww97@...>
        Date: Sunday, Oct 1, 2006 10:49 pm
        Subject: [nslu2-linux] Re: Fatslug 256MB

        --- In nslu2-linux@yahoogroups.com, kinsa <kinsa_manka@...> wrote:
        >
        > stjopa666 wrote:
        > > But you dont get system lockups or data corruption? I could cope with
        > > some error messages if the system is stable (at least till .18 is
        out).
        > >
        > > BTW which kernel patch did you mean, couldnt find anything about it in
        > > the .18rc2 changelog.
        >
        > I had commented out the line that spews out the error message in the
        kernel
        > source and the recompiled kernel ran smoothly for more than a month
        without
        > problems.
        >
        > BTW, I was running ctorrent during that period which used up all the
        available
        > ram (128Mb).
        >
        > Kinsa
        >

        Hi,

        When I do a file ramdisk.gz, it gives me the below output instead of
        Linux Compressed ROM File System data, big endian as described in
        TestAnImageInRamUsingRedBoot. Does anyone have any idea? It suspected
        that why I can't load the image.

        root@lemon:~/images# ls -l
        total 46852
        -rw-r--r-- 1 root root 262144 Sep 30 15:32 Redbook
        -rw-r--r-- 1 root root 0 Sep 30 15:32 SysConf
        -rw-r--r-- 1 root root 16 Sep 30 15:32 Trailer
        -rw-rw-r-- 1 cyrus 500 8388608 Oct 1 2006
        openslug-nslu2-20061001004539.flashdisk.img
        -rw-r--r-- 1 cyrus 500 5111808 Oct 1 2006
        openslug-nslu2-20061001004539.rootfs.jffs2
        -rw-r--r-- 1 root root 131056 Sep 30 15:32 ramdisk.gz
        -rw-r--r-- 1 root root 992504 Sep 30 15:32 vmlinuz
        -rw-rw-r-- 1 cyrus 500 992504 Sep 30 11:32 zImage-ds101be
        -rw-rw-r-- 1 cyrus 500 992504 Sep 30 11:32 zImage-dsmg600be
        -rw-rw-r-- 1 cyrus 500 992496 Sep 30 11:32 zImage-ixp4xxbe
        -rw-rw-r-- 1 cyrus 500 992504 Sep 30 11:32 zImage-loftbe
        -rw-rw-r-- 1 cyrus 500 992504 Sep 30 11:32 zImage-nas100dbe
        -rw-rw-r-- 1 cyrus 500 992504 Sep 30 11:32 zImage-nslu2be
        root@lemon:~/images# file ramdisk.gz
        ramdisk.gz: ISO-8859 text, with very long lines, with no line terminators
        root@lemon:~/images#
      • nww
        Thanks for your advice. I ve tried. But,... got the below results. It seems no much different. Actually, I don t know what exactly those files are used for and
        Message 3 of 28 , Oct 2, 2006
          Thanks for your advice. I've tried. But,... got the below results. It
          seems no much different. Actually, I don't know what exactly those
          files are used for and what are they. I just follow the information
          from the web and hope to test out my newly built image. Even though I
          spend a lot of time, it didn't pay out.

          [root@localhost images]# ls -l
          total 19132
          -rw-rw-r-- 1 csnww csnww 8388608 Oct 1 08:50
          openslug-nslu2-20061001004539.flashdisk.img
          -rw-r--r-- 1 csnww csnww 5111808 Oct 1 08:50
          openslug-nslu2-20061001004539.rootfs.jffs2
          -rwxr-xr-x 1 root root 31362 Oct 2 16:07 slugimage
          -rw-rw-r-- 1 csnww csnww 992504 Sep 30 19:32 zImage-ds101be
          -rw-rw-r-- 1 csnww csnww 992504 Sep 30 19:32 zImage-dsmg600be
          -rw-rw-r-- 1 csnww csnww 992496 Sep 30 19:32 zImage-ixp4xxbe
          -rw-rw-r-- 1 csnww csnww 992504 Sep 30 19:32 zImage-loftbe
          -rw-rw-r-- 1 csnww csnww 992504 Sep 30 19:32 zImage-nas100dbe
          -rw-rw-r-- 1 csnww csnww 992504 Sep 30 19:32 zImage-nslu2be
          [root@localhost images]# ./slugimage -u -i
          openslug-nslu2-20061001004539.flashdisk.img -r
          Ramdisk:ramdisk.gz,Flashdisk:flashdisk.jffs2
          Read 2 blocks into <RedBoot>
          Read 0x00006 bytes into <EthAddr>
          Read 1 blocks into <SysConf>
          Read 8 blocks into <Kernel>
          Read 0x1FFF0 bytes into <Ramdisk>
          Read 51 blocks into <Flashdisk>
          Read 1 blocks into <FIS directory>
          Read 0x000F8 bytes into <SwitchArgs>
          Read 0x00010 bytes into <Trailer>
          Wrote 0x00040000 bytes from <RedBoot> into "RedBoot"
          Wrote 0x00020000 bytes from <SysConf> into "SysConf"
          Wrote 0x000F24F8 bytes from <Kernel> into "vmlinuz"
          Wrote 0x0001FFF0 bytes from <Ramdisk> into "ramdisk.gz"
          Wrote 0x00660000 bytes from <Flashdisk> into "flashdisk.jffs2"
          Wrote 0x00000010 bytes from <Trailer> into "Trailer"
          [root@localhost images]# ls -l
          total 27200
          -rw-r--r-- 1 root root 6684672 Oct 2 16:26 flashdisk.jffs2
          -rw-rw-r-- 1 csnww csnww 8388608 Oct 1 08:50
          openslug-nslu2-20061001004539.flashdisk.img
          -rw-r--r-- 1 csnww csnww 5111808 Oct 1 08:50
          openslug-nslu2-20061001004539.rootfs.jffs2
          -rw-r--r-- 1 root root 131056 Oct 2 16:26 ramdisk.gz
          -rw-r--r-- 1 root root 262144 Oct 2 16:26 RedBoot
          -rwxr-xr-x 1 root root 31362 Oct 2 16:07 slugimage
          -rw-r--r-- 1 root root 131072 Oct 2 16:26 SysConf
          -rw-r--r-- 1 root root 16 Oct 2 16:26 Trailer
          -rw-r--r-- 1 root root 992504 Oct 2 16:26 vmlinuz
          -rw-rw-r-- 1 csnww csnww 992504 Sep 30 19:32 zImage-ds101be
          -rw-rw-r-- 1 csnww csnww 992504 Sep 30 19:32 zImage-dsmg600be
          -rw-rw-r-- 1 csnww csnww 992496 Sep 30 19:32 zImage-ixp4xxbe
          -rw-rw-r-- 1 csnww csnww 992504 Sep 30 19:32 zImage-loftbe
          -rw-rw-r-- 1 csnww csnww 992504 Sep 30 19:32 zImage-nas100dbe
          -rw-rw-r-- 1 csnww csnww 992504 Sep 30 19:32 zImage-nslu2be
          [root@localhost images]# file ramdisk.gz
          ramdisk.gz: MPEG ADTS, layer I, v1, Monaural
          [root@localhost images]#




          --- In nslu2-linux@yahoogroups.com, "Rod Whitby"
          <list.nslu2-linux@...> wrote:
          >
          > What you have ther is the dummy ramdisk.gz partition which we put in
          flashdisk-based images to stop the Linksys redboot "boot" command from
          copying invalid data all over memory when it tries to load a ramdisk
          into ram.
          > You want to give a "-r Ramdisk:ramdisk.gz,Flashdisk:flashdisk.jffs2"
          option to slugimage to unpack a flashdisk-based image. Please add
          that to whatever wiki page you used to find out how to unpack the image.
          > -- Rod
          >
          > -----Original Message-----
          > From: "nww" <csnww97@...>
          > Date: Sunday, Oct 1, 2006 10:49 pm
          > Subject: [nslu2-linux] Re: Fatslug 256MB
          >
          > --- In nslu2-linux@yahoogroups.com, kinsa <kinsa_manka@> wrote:
          > >
          > > stjopa666 wrote:
          > > > But you dont get system lockups or data corruption? I could cope
          with
          > > > some error messages if the system is stable (at least till .18 is
          > out).
          > > >
          > > > BTW which kernel patch did you mean, couldnt find anything about
          it in
          > > > the .18rc2 changelog.
          > >
          > > I had commented out the line that spews out the error message in the
          > kernel
          > > source and the recompiled kernel ran smoothly for more than a month
          > without
          > > problems.
          > >
          > > BTW, I was running ctorrent during that period which used up all the
          > available
          > > ram (128Mb).
          > >
          > > Kinsa
          > >
          >
          > Hi,
          >
          > When I do a file ramdisk.gz, it gives me the below output instead of
          > Linux Compressed ROM File System data, big endian as described in
          > TestAnImageInRamUsingRedBoot. Does anyone have any idea? It suspected
          > that why I can't load the image.
          >
          > root@lemon:~/images# ls -l
          > total 46852
          > -rw-r--r-- 1 root root 262144 Sep 30 15:32 Redbook
          > -rw-r--r-- 1 root root 0 Sep 30 15:32 SysConf
          > -rw-r--r-- 1 root root 16 Sep 30 15:32 Trailer
          > -rw-rw-r-- 1 cyrus 500 8388608 Oct 1 2006
          > openslug-nslu2-20061001004539.flashdisk.img
          > -rw-r--r-- 1 cyrus 500 5111808 Oct 1 2006
          > openslug-nslu2-20061001004539.rootfs.jffs2
          > -rw-r--r-- 1 root root 131056 Sep 30 15:32 ramdisk.gz
          > -rw-r--r-- 1 root root 992504 Sep 30 15:32 vmlinuz
          > -rw-rw-r-- 1 cyrus 500 992504 Sep 30 11:32 zImage-ds101be
          > -rw-rw-r-- 1 cyrus 500 992504 Sep 30 11:32 zImage-dsmg600be
          > -rw-rw-r-- 1 cyrus 500 992496 Sep 30 11:32 zImage-ixp4xxbe
          > -rw-rw-r-- 1 cyrus 500 992504 Sep 30 11:32 zImage-loftbe
          > -rw-rw-r-- 1 cyrus 500 992504 Sep 30 11:32 zImage-nas100dbe
          > -rw-rw-r-- 1 cyrus 500 992504 Sep 30 11:32 zImage-nslu2be
          > root@lemon:~/images# file ramdisk.gz
          > ramdisk.gz: ISO-8859 text, with very long lines, with no line
          terminators
          > root@lemon:~/images#
          >
        • Steve Gane
          As you say, the crossbuild environment Master Makefile does work amazingly well. What I can t work out is how to patch the kernel command line, and
          Message 4 of 28 , Oct 14, 2006
            As you say, the crossbuild environment 'Master Makefile' does work
            amazingly well. What I can't work out is how to patch the kernel
            command line, and specifically WHEN in the flow. The makefile does a
            lot of unpack/patch/configure/compile for lots of packages. I can't
            find a target that leaves things patched but not yet built. I think
            the file I need to edit (for openslug) is
            releases/slugos-3.10-beta/openslug-nslu2.tmp/work/ixp4xx-kernel-2.6.16-r6.6/arch/arm/mach/ixp4xx/nslu2-setup.c
            - it even has comments about fatslugs in it. But it doesn't exist
            until the kernel has been built. I suppose I can make, then edit,
            delete the stamps and go again? Or will that re-fetch the unmodified
            version?

            My eventual target is a 64MB single-bank turbo-debianslug (still with
            Redboot).

            Steve G


            --- In nslu2-linux@yahoogroups.com, "sdm485" <steve@...> wrote:
            >
            > --- In nslu2-linux@yahoogroups.com, "CN" <t4chacko@> wrote:
            > >
            > > On Sun, 16 Jul 2006 16:57:26 -0000, sdm485 wrote:
            > >
            > > > The kernels have a built in command line that includes
            'mem=32M...' so
            > > > you will have to recompile the kernel to change that. It sounds like
            > > > RedBoot configures the processor to do 64M but not necessarily
            in two
            > > > banks which is what you are talking about. I am using the Apex
            > > > bootloader configured and built for 2 banks. It would be ideal if
            > > > RedBoot could be retained as the bootloader because the upgrade
            > > > utility etc would still be available. Not really complaining about
            > > > Apex though; it works very well.
            > > >
            > > > sdm485
            > >
            > > Well, I am not setup to compile anything :( The following may not
            > even be
            > > reasonable questions... If standard RedBoot can use 64M, then what
            > type of
            > > (physicall) memory upgrade is needed to get the 'single' bank
            > system? Removing the
            > > existing chips first?
            > >
            > > Is there an already configured Apex binary out there that one can
            > use (without any
            > > compile) with the two bank system? Anyreferencess to the details
            > and steps?
            > > Thanks.
            > >
            > > Cordially, Chacko
            > >
            >
            >
            > I am not sure what memory configuration will work with RedBoot. It
            > depends upon how RedBoot is configured. Because the memory size is
            > passed to the kernel at boot time, it is entirely possible that
            > RedBoot is configured for both banks and maximum memory. It would work
            > fine but there would be multiple copies of the 32M memory in the
            > processors address space (which is fine too). But I don't know as
            > I do not have a slug available to figure it out. There is probably
            > RedBoot configuration info available somewhere.
            >
            > You can get Apex from http://wiki.buici.com/wiki/Main_Page and the
            > person who provides us with Apex is now providing binary images
            > for download. I checked the config file for them and they are built
            > for one bank of 32M so that is useful to check out but won't work with
            > more memory until it is recompiled. This website has everything I
            > needed to get Apex working. You can install the slug native build
            > environment and build it right on the slug; that is how I do it. Test
            > it in RAM though and be prepared to move to serial transfer of kernels
            > and filesystems if you replace RedBoot...
            >
            > I just got the most recent build working with 128M so they must have
            > fixed it. Wheee... :)
            >
            > There are no FatSlug images available in binary format and the
            > developers have requested that none be posted in order to keep things
            > from getting confused. The crossbuild environment 'Master Makefile'
            > works amazingly well and they provide information to get it working on
            > different operating systems. It is really the only way to do it at
            > this time.
            >
            > I hope this is useful and I am more than happy to help.
            >
            > Regards,
            >
            > Steve
            >
          • sdm485
            I managed to get it to work on Openslug 3.10 by modifying ../openembedded/packages/linux/ixp4xx-kernel.inc by commenting out the regular expression:
            Message 5 of 28 , Oct 14, 2006
              I managed to get it to work on Openslug 3.10 by modifying
              ../openembedded/packages/linux/ixp4xx-kernel.inc by commenting out
              the regular expression:
              CMDLINE_ROOT ?= "root=/dev/mtdblock4 rw rootfstype=jffs2 init=/linuxrc
              and put in its' place:
              CMDLINE_ROOT = "mem=128M"

              According to my notes, this is the change that worked.

              I use apex as the bootloader as I have 128M. It works very well
              though; I just built php-5.1.6 on it and it used up 107M doing that
              while running apache,cherokee,vsftpd,samba and ntpd.


              Steve



              --- In nslu2-linux@yahoogroups.com, "Steve Gane" <steve@...> wrote:
              >
              > As you say, the crossbuild environment 'Master Makefile' does work
              > amazingly well. What I can't work out is how to patch the kernel
              > command line, and specifically WHEN in the flow. The makefile does a
              > lot of unpack/patch/configure/compile for lots of packages. I can't
              > find a target that leaves things patched but not yet built. I think
              > the file I need to edit (for openslug) is
              >
              releases/slugos-3.10-beta/openslug-nslu2.tmp/work/ixp4xx-kernel-2.6.16-r6.6/arch/arm/mach/ixp4xx/nslu2-setup.c
              > - it even has comments about fatslugs in it. But it doesn't exist
              > until the kernel has been built. I suppose I can make, then edit,
              > delete the stamps and go again? Or will that re-fetch the unmodified
              > version?
              >
              > My eventual target is a 64MB single-bank turbo-debianslug (still with
              > Redboot).
              >
              > Steve G
              >
              >
              > --- In nslu2-linux@yahoogroups.com, "sdm485" <steve@> wrote:
              > >
              > > --- In nslu2-linux@yahoogroups.com, "CN" <t4chacko@> wrote:
              > > >
              > > > On Sun, 16 Jul 2006 16:57:26 -0000, sdm485 wrote:
              > > >
              > > > > The kernels have a built in command line that includes
              > 'mem=32M...' so
              > > > > you will have to recompile the kernel to change that. It
              sounds like
              > > > > RedBoot configures the processor to do 64M but not necessarily
              > in two
              > > > > banks which is what you are talking about. I am using the Apex
              > > > > bootloader configured and built for 2 banks. It would be ideal if
              > > > > RedBoot could be retained as the bootloader because the upgrade
              > > > > utility etc would still be available. Not really complaining about
              > > > > Apex though; it works very well.
              > > > >
              > > > > sdm485
              > > >
              > > > Well, I am not setup to compile anything :( The following may not
              > > even be
              > > > reasonable questions... If standard RedBoot can use 64M, then what
              > > type of
              > > > (physicall) memory upgrade is needed to get the 'single' bank
              > > system? Removing the
              > > > existing chips first?
              > > >
              > > > Is there an already configured Apex binary out there that one can
              > > use (without any
              > > > compile) with the two bank system? Anyreferencess to the details
              > > and steps?
              > > > Thanks.
              > > >
              > > > Cordially, Chacko
              > > >
              > >
              > >
              > > I am not sure what memory configuration will work with RedBoot. It
              > > depends upon how RedBoot is configured. Because the memory size is
              > > passed to the kernel at boot time, it is entirely possible that
              > > RedBoot is configured for both banks and maximum memory. It would work
              > > fine but there would be multiple copies of the 32M memory in the
              > > processors address space (which is fine too). But I don't know as
              > > I do not have a slug available to figure it out. There is probably
              > > RedBoot configuration info available somewhere.
              > >
              > > You can get Apex from http://wiki.buici.com/wiki/Main_Page and the
              > > person who provides us with Apex is now providing binary images
              > > for download. I checked the config file for them and they are built
              > > for one bank of 32M so that is useful to check out but won't work with
              > > more memory until it is recompiled. This website has everything I
              > > needed to get Apex working. You can install the slug native build
              > > environment and build it right on the slug; that is how I do it. Test
              > > it in RAM though and be prepared to move to serial transfer of kernels
              > > and filesystems if you replace RedBoot...
              > >
              > > I just got the most recent build working with 128M so they must have
              > > fixed it. Wheee... :)
              > >
              > > There are no FatSlug images available in binary format and the
              > > developers have requested that none be posted in order to keep things
              > > from getting confused. The crossbuild environment 'Master Makefile'
              > > works amazingly well and they provide information to get it working on
              > > different operating systems. It is really the only way to do it at
              > > this time.
              > >
              > > I hope this is useful and I am more than happy to help.
              > >
              > > Regards,
              > >
              > > Steve
              > >
              >
            • Steve Gane
              Success! I had to make debianslug-3.10-beta (or at least get as far as the SVN checkout), then edit:
              Message 6 of 28 , Oct 15, 2006
                Success! I had to "make debianslug-3.10-beta" (or at least get as far
                as the SVN checkout), then edit:
                releases/slugos-3.10-beta/openembedded/packages/linux/ixp4xx-kernel/2.6.16/94-nslu2-setup.patch
                to add "mem=64M"
                The file you specified seems not to be the kernale command line that
                is actually used :-(

                then remove some stamps:
                rm releases/slugos-3.10-beta/openslug-nslu2.tmp/stamps/ixp4xx-kernel* \
                releases/slugos-3.10-beta/openslug-nslu2.tmp/stamps/debianslug* \
                releases/slugos-3.10-beta/openslug-nslu2.tmp/stamps/slugos* \
                releases/slugos-3.10-beta/openslug-nslu2.tmp/deploy/images/*

                Finally build again:
                make debianslug-3.10-beta

                ..and I now have an image that reports 64M on boot, and the output
                from "free" shows nearly 64M as well. Now I just have to flash it...

                Steve

                --- In nslu2-linux@yahoogroups.com, "sdm485" <steve@...> wrote:
                >
                > I managed to get it to work on Openslug 3.10 by modifying
                > ../openembedded/packages/linux/ixp4xx-kernel.inc by commenting out
                > the regular expression:
                > CMDLINE_ROOT ?= "root=/dev/mtdblock4 rw rootfstype=jffs2 init=/linuxrc
                > and put in its' place:
                > CMDLINE_ROOT = "mem=128M"
                >
                > According to my notes, this is the change that worked.
                >
                > I use apex as the bootloader as I have 128M. It works very well
                > though; I just built php-5.1.6 on it and it used up 107M doing that
                > while running apache,cherokee,vsftpd,samba and ntpd.
                >
                >
                > Steve
                >
                >
                >
                > --- In nslu2-linux@yahoogroups.com, "Steve Gane" <steve@> wrote:
                > >
                > > As you say, the crossbuild environment 'Master Makefile' does work
                > > amazingly well. What I can't work out is how to patch the kernel
                > > command line, and specifically WHEN in the flow. The makefile does a
                > > lot of unpack/patch/configure/compile for lots of packages. I can't
                > > find a target that leaves things patched but not yet built. I think
                > > the file I need to edit (for openslug) is
                > >
                >
                releases/slugos-3.10-beta/openslug-nslu2.tmp/work/ixp4xx-kernel-2.6.16-r6.6/arch/arm/mach/ixp4xx/nslu2-setup.c
                > > - it even has comments about fatslugs in it. But it doesn't exist
                > > until the kernel has been built. I suppose I can make, then edit,
                > > delete the stamps and go again? Or will that re-fetch the unmodified
                > > version?
                > >
                > > My eventual target is a 64MB single-bank turbo-debianslug (still with
                > > Redboot).
                > >
                > > Steve G
                > >
                > >
                > > --- In nslu2-linux@yahoogroups.com, "sdm485" <steve@> wrote:
                > > >
                > > > --- In nslu2-linux@yahoogroups.com, "CN" <t4chacko@> wrote:
                > > > >
                > > > > On Sun, 16 Jul 2006 16:57:26 -0000, sdm485 wrote:
                > > > >
                > > > > > The kernels have a built in command line that includes
                > > 'mem=32M...' so
                > > > > > you will have to recompile the kernel to change that. It
                > sounds like
                > > > > > RedBoot configures the processor to do 64M but not necessarily
                > > in two
                > > > > > banks which is what you are talking about. I am using the Apex
                > > > > > bootloader configured and built for 2 banks. It would be
                ideal if
                > > > > > RedBoot could be retained as the bootloader because the upgrade
                > > > > > utility etc would still be available. Not really complaining
                about
                > > > > > Apex though; it works very well.
                > > > > >
                > > > > > sdm485
                > > > >
                > > > > Well, I am not setup to compile anything :( The following may not
                > > > even be
                > > > > reasonable questions... If standard RedBoot can use 64M, then what
                > > > type of
                > > > > (physicall) memory upgrade is needed to get the 'single' bank
                > > > system? Removing the
                > > > > existing chips first?
                > > > >
                > > > > Is there an already configured Apex binary out there that one can
                > > > use (without any
                > > > > compile) with the two bank system? Anyreferencess to the details
                > > > and steps?
                > > > > Thanks.
                > > > >
                > > > > Cordially, Chacko
                > > > >
                > > >
                > > >
                > > > I am not sure what memory configuration will work with RedBoot. It
                > > > depends upon how RedBoot is configured. Because the memory size is
                > > > passed to the kernel at boot time, it is entirely possible that
                > > > RedBoot is configured for both banks and maximum memory. It
                would work
                > > > fine but there would be multiple copies of the 32M memory in the
                > > > processors address space (which is fine too). But I don't know as
                > > > I do not have a slug available to figure it out. There is probably
                > > > RedBoot configuration info available somewhere.
                > > >
                > > > You can get Apex from http://wiki.buici.com/wiki/Main_Page and the
                > > > person who provides us with Apex is now providing binary images
                > > > for download. I checked the config file for them and they are built
                > > > for one bank of 32M so that is useful to check out but won't
                work with
                > > > more memory until it is recompiled. This website has everything I
                > > > needed to get Apex working. You can install the slug native build
                > > > environment and build it right on the slug; that is how I do it.
                Test
                > > > it in RAM though and be prepared to move to serial transfer of
                kernels
                > > > and filesystems if you replace RedBoot...
                > > >
                > > > I just got the most recent build working with 128M so they must have
                > > > fixed it. Wheee... :)
                > > >
                > > > There are no FatSlug images available in binary format and the
                > > > developers have requested that none be posted in order to keep
                things
                > > > from getting confused. The crossbuild environment 'Master Makefile'
                > > > works amazingly well and they provide information to get it
                working on
                > > > different operating systems. It is really the only way to do it at
                > > > this time.
                > > >
                > > > I hope this is useful and I am more than happy to help.
                > > >
                > > > Regards,
                > > >
                > > > Steve
                > > >
                > >
                >
              • dubbeltje@msn.com
                I managed to get it to work on Openslug 3.10 by modifying ../openembedded/packages/linux/ixp4xx-kernel.inc by commenting out the regular expression:
                Message 7 of 28 , Oct 15, 2006
                  I managed to get it to work on Openslug 3.10 by modifying
                  ../openembedded/packages/linux/ixp4xx-kernel.inc by commenting out
                  the regular expression:
                  CMDLINE_ROOT ?= "root=/dev/mtdblock4 rw rootfstype=jffs2 init=/linuxrc
                  and put in its' place:
                  CMDLINE_ROOT = "mem=128M"

                  According to my notes, this is the change that worked.

                  I use apex as the bootloader as I have 128M. It works very well
                  though; I just built php-5.1.6 on it and it used up 107M doing that
                  while running apache,cherokee,vsftpd,samb
                Your message has been successfully submitted and would be delivered to recipients shortly.