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

Re: Fatslug 256MB

Expand Messages
  • nww
    ... I think it should be nslu2-setup.inc under the path openembeded/packages/linux/nslu2-setup.inc.
    Message 1 of 28 , Oct 1, 2006
    View Source
    • 0 Attachment
      --- In nslu2-linux@yahoogroups.com, "stjopa666" <spamstj@...> wrote:
      >
      > --- 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.
      >
      > Indeed it is. If you are in this thing, its here (but rather technical):
      >
      > http://ecos.sourceware.org/docs-latest/redboot/redboot-guide.html
      >
      > >
      > > 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...
      >
      > If you dont have good reasons for it (like we do with kernel bugs), i
      > would STRONGLY recommend NOT to fiddle with the bootloader (means
      > replacing it). If you dont have JTAG and/or a serial mod your slug can
      > end up bricked very soon.
      >
      >
      > > I just got the most recent build working with 128M so they must have
      > > fixed it. Wheee... :)
      >
      > Gooood ;). Lets summarize (correct me if im wrong):
      >
      > Redboot: - up to 64MB RAM
      > - Recompilation of kernel and modification
      > of nslu2-setup.c (contains the mem=XXX commandline) required.
      > - only single bank (means no
      > piggyback-mod)

      I think it should be nslu2-setup.inc under the path
      openembeded/packages/linux/nslu2-setup.inc.

      >
      > Apex (with .17 kernel): - up to 128MB (confirmed)
      > - kernel recomp., cmd-line
      > - allows piggybacking (thus dual banks)
      >
      > > 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.
      > >
      > FYI: http://www.nslu2-linux.org/wiki/Development/MasterMakefile
      >
      > -----------
      >
      > Well good to hear the MasterMakefile image builds work with 128MB. Still
      > we dont know if 256MB would work. Ill probably just install 128MB first
      > and add the other chips later if im in dire need of em. Or should i be
      > adventurous ;) ?
      >
    • 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 2 of 28 , Oct 1, 2006
      View Source
      • 0 Attachment
        --- 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 3 of 28 , Oct 1, 2006
        View Source
        • 0 Attachment
          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 4 of 28 , Oct 2, 2006
          View Source
          • 0 Attachment
            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 5 of 28 , Oct 14, 2006
            View Source
            • 0 Attachment
              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 6 of 28 , Oct 14, 2006
              View Source
              • 0 Attachment
                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 7 of 28 , Oct 15, 2006
                View Source
                • 0 Attachment
                  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 8 of 28 , Oct 15, 2006
                  View Source
                  • 0 Attachment
                    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.