On Tue, Jun 26, 2007 at 10:13:15AM +0930, Rod Whitby wrote:
> Marc Singer wrote:
> > I'm curious if we want to allow APEX to automatically detect more
> > memory on startup. The code in APEX that reconfigures the memory
> > controller and then scans memory to determine the amount of memory
> > installed on the slug appears to be working properly in 64MiB and
> > 128MiB slugs. I'm working through testing the upgrade for APEX right
> > now.
>
> I'm all for apex reporting whatever memory it detects. That's the only
> way we will find any remaining bugs. Someone who is replacing RAM chips
> in an embedded device should be a person who will not be totally
> surprised if there is an outstanding bug in a configuration that has not
> been well tested.
>
> BTW, we have tested Apex 1.5.6 on a 256MB slug too, and it seems to work
> well (ask Rob Lockhart for the chip configuration details). That one
> also has a 16MB flash replacement. We're calling it an "ObeseSlug" :-)
Great. I've tested APEX 1.5.8 on my 128MiB slug. The default startup
will scan for up to 256MiB of RAM (the maximum that the IXP42x can
address).
As far as I can test, it seems that the RAM detect and settings were working on the older 1.4.15 (I can't recall the exact version but it was 1.4.1x). I was able to load different stuff into different memory locations, and using Apex, do a checksum (matched file sent over xmodem). The only problem I ran into was that the kernel would have some DMA issues when accessing almost all of the memory. The DMA subsystem seemed to crash, which meant that PCI<->USB transactions were halted, which then meant a hung slug (filesystem off USB).
If you want, I can try my debian 4.0 kernel image with apex, replace apex with the newer one, and re-test. Right now, I have my FatSlug set up as 64MB via only letting it detect up to 64MB. That seems to be fine, and excess memory usage correctly uses swap. If I have Apex detect larger, it detects all the way to 256MB just fine, and using all but the last 1-2MB seems fine, but once it tries to use all of it, the DMA bug happens. I would think that memory size and proper config would affect the entire chip, not just the uppermost segment (less than one bank of memory).
I don't see how this could be an issue with Apex but I am willing to try a test in the interests of solving this problem. I don't think there are that many 256MB FatSlugs, and surely less than a handful of ObeseSlugs.
BTW, the chips used are 512Mb SDRAM, can be hard to find these days. Micron 48LC32M16A2.
Don't hesitate to let me know if there is anything that needs to be tried. I have JTAG working.
I recall that there was a thread of discussion about automatically
upgrading APEX when a new package is installed. Was this resolved?
In order for me to install a new APEX, I had to take the
/boot/apex.flash image, byte swap it, and then put the sercomm header
on it. I can also put a copy of apex with all of those steps already
taken into /boot so that it is really easy to upgrade (or downgrade
for that matter).
That sounds like what Rod's "slugimage" Perl script does.
Generally, I'm not in favor of redundancy of this sort. There should
be a simple tool for handling this, but I haven't seen one. I suppose
the alternative would be for me to write a small tool that is capable
of installing APEX into flash. It would be easy to look for an
existing version in the target partition and then do the swaps and
headerization.
I agree with you; it might be best to run that from userland. Where I work, we have two separate images in flash (backup and current image) and two boot loaders (in case one is corrupt it reverts to the backup). I don't think we have the space here with 8MB.