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

Fatslug memory problems (was Re: APEX 1.4.17 and fat slugs (memory upgrade))

Expand Messages
  • sdm485
    Replying to my own post.... I just tested apex 1.5.4 on my 128M 2 bank fatslug configured for a 32M NSLU2 and if I actually tell sdram-init that I have 2 banks
    Message 1 of 18 , Jun 1, 2007
    • 0 Attachment
      Replying to my own post....
      I just tested apex 1.5.4 on my 128M 2 bank fatslug configured for a
      32M NSLU2 and if I actually tell sdram-init that I have 2 banks of 64M
      chips ('sdram-init 0x4000000 2'), it reports 2 banks of 32M chips for
      a total size of 64M and not 128M (which is the actual RAM size). If I
      run sdram-init without any parameters, it finds the banks and size
      correctly on its' own. If I then run 'memscan -u 0x0+256m' it reports
      the correct memory size and updates the memory map sent to the kernel.
      If I then copy the kernel to the boot address and type boot, linux
      starts and all is fine and all memory is found.

      My flashed apex (2 banks of 64M) is sent to the kernel as 2 separate
      areas of RAM that are contiguous (0x0,size=0x4000000 and 0x4000000,
      size=0x4000000). After running sdram-init and memscan, the size passed
      is 0x000+0x8000000 which is the same size but a single block. So, I
      think it can be concluded that sdram-init and memscan find and
      configure the memory and report the size to the kernel correctly. So I
      think I actually did test these functions and found that they work.
      ..... for what it's worth..... :).

      So I built apex version 1.5.4 for an NSLU2 using the standard memory
      size. I enabled the command 'memscan' since I would be needing it; I
      overrode the kernel command line with 'root=/dev/mtdblock4
      rootfstype=jffs2 init=/linuxrc rtc-x1205.probe=0,0x6f' and set the
      startup command line to 'sdram-init; memscan 0x0+256m; copy $kernelsrc
      $bootaddr; wait 50 Type ^C to cancel autoboot.; boot'

      Not sure if the rtc statement is needed with 2.6.21 but it works...

      Ran this from RAM and it boots linux and finds all the RAM.


      --- In nslu2-linux@yahoogroups.com, "sdm485" <steve@...> wrote:
      > I installed 'memtester' via ipkg and tested 120M and it passed. I
      > tried 128M (all of the available ram) and the process was killed by
      > the kernel after running out of memory which makes sense...:).
      > However, 128M gets into the second bank and proved that the addressing
      > was working. The README on memtester mentions that if you ask it to
      > test more memory than is available, it will try regardless of getting
      > a lock on the memory or not so the error messages do start flying by...
      > Thinking you might mean 'memscan' in apex, I ran that test and it
      > found 128M of memory which again makes sense.
      > There used to be a dma related error for arm processors in some
      > previous kernel versions but this was fixed a long time ago. In fact,
      > at the time, the quick fix was to comment out the line in the dma
      > routine which was reporting the error and it worked just fine;
      > removing the symptom to effect a cure I suppose. Current kernels don't
      > have these dma problems.
      > The most likely problem IMHO is that you have a floating address line
      > pin on your second bank of RAM, assuming you have two banks of course.
      > When I first built my fatslug, it worked fine but later got flaky. I
      > discovered a bad solder joint and it has worked fine ever since.
      > Sometimes they are so close that just putting a test probe on the pin
      > will make it contact so I suggest a careful check for such a problem.
      > If you want to figure out which (if any) address lines are having
      > troubles, use apex to copy a pattern at 0x00, say 00,01,02,03,etc and
      > then look for the same pattern at the 64M boundary. Another test is
      > fill chunks of memory with a known value and look for that value up
      > higher memory on address line boundaries. Perhaps it is the chip
      > select line and the chips are not getting selected as a separate bank
      > (just thinking out loud).
      > My fatslug works just like a regular NSLU2 except that it does not
      > swap unless I ask it to do something huge like build boost. I don't
      > see any 'fatslug' unique behaviour at all other than a generally more
      > responsive unit. I have always used the zImage-ixp4xxbe as the kernel
      > since it does not fiddle with the command line from apex. I currently
      > am running the 2.6.21 kernel which is the current beta version.
      > I am still not convinced that I have actually tested the memscan and
      > sdram-init functions in apex. I say this because I have always built
      > apex with both sdram banks enabled and the memory size set to
      > 0x04000000 (64M/bank). I have never ever changed the boot command line
      > to run the memscan and sdram-init commands prior to loading the kernel
      > to RAM and booting. Maybe the problem is simply that the second bank
      > is never actually getting enabled by apex. Even the writer of Apex,
      > Marc Singer, is not fully convinced it supports 2 banks according to
      > his website 'http://wiki.buici.com/wiki/Main_Page'.
      > Hope this helps and sorry for the length (whew....;)),
      > Steve
      > --- In nslu2-linux@yahoogroups.com, "Rob Lockhart" <rlockhar@> wrote:
      > >
      > > Steve, can you please test this using memtest (just ipkg for it), and
      > > then test the entire memory. If you get some DMA errors, then that is
      > > where I am. My FatSlug works fine, so long as I don't use up to the
      > > max memory. Already posted a response to the Linux-Kernel-ARM list
      > > but I was told to contact the MM folks (I don't have such an elaborate
      > > contact list).
      > >
      > > If you use the "memtest -u 0+256m" switches, then no lines to the
      > > kernel need changing (at least that was my experience). That was with
      > > 1.4.16 Apex.
      > >
      > > The killer for me was rsync. It is a memory hog (with 30k files), and
      > > would use attempt to use all memory. Once it got close to using all
      > > the memory, I'd get DMA errors and then the PCI DMA driver would crash
      > > (then obviously the network went down). No way to fix it other than
      > > reboot or serial port login, verify network is still working (since
      > > it's not on PCI bus - dedicated MAC in IXP420), and then reboot.
      > >
      > >
      > >
      > > On 5/31/07, sdm485 <steve@> wrote:
      > > > I did not make it clear in the previous post that I have built and
      > > > tested apex-1.5.4 and found that it worked fine. I am still a bit
      > > > curious as to why I have to configure for 2 banks and the
      correct size
      > > > when building the binary if the code is figuring things out
      > > > Steve
      > > >
      > > >
      > > > --- In nslu2-linux@yahoogroups.com, "sdm485" <steve@> wrote:
      > > > >
      > > > > I just built and tested this on my 4 chip 128M fatslug and it
      > > > > perfectly. The command line passed does not include the
      mem=128M, it
      > > > > finds both banks and it indicates 127788(K) free. It was tested in
      > > > > flash as the only bootloader. Thanks to all for the update.
      > > > > Steve
      > > > >
      > > > > --- In nslu2-linux@yahoogroups.com, Rod Whitby <rod@> wrote:
      > > > > >
      > > > > > x_pic_info wrote:
      > > > > > > Steve,
      > > > > > > I'm having some problems with the same configuration as you
      > have:
      > > > > > > 2 banks of 64M. I built apex but sdram-init command says I
      > have 2
      > > > > > > banks of 128 MiB which actually is half the amount of ram i
      > have.
      > > > > >
      > > > > > There is a new release of Apex (1.5.4) which is intended to
      > fix this
      > > > > > problem. Please test it out.
      > > > > >
      > > > > > -- Rod
      > >
    Your message has been successfully submitted and would be delivered to recipients shortly.