Ah, but is it???

Yes.

total: used: free: shared: buffers: cached:
Mem: 48553984 33345536 15208448 921600 16404480 6012928
Swap: 0 0 0
MemTotal: 47416 kB
MemFree: 14852 kB
MemShared: 900 kB
Buffers: 16020 kB
Cached: 5872 kB
SwapTotal: 0 kB
SwapFree: 0 kB

HAHAHAHAHAHAHAHAH! Excellent!!! Very cool! Thanks!

Is this better???

Meanwhile, any trouble? Any ill effects? Any noticeable differences? Any photos???

48Mb of RAM ? COOL !

I'm soak testing it now. To be honest I expect that to be a formality as I have already soak tested each of the extra 32MB layers independently during testing. You've got a mlord custom kernel at the moment, needed to activate the third bank. I expect that change will make it into the next official hijack release.

I hereby offer a 6 pack to the first person to successfully install 64MB. Be warned that dealing with the RAS pins becomes an exercise in frustration and lost pins when you add a third layer.

That sounds like an interesting challenge....

I think we need photo's of this masterpiece. So, whats going to be first. 200gb of disc space or 1gb ram ;-)

Speaking of hard drives, once the empeg software takes advantage of this, even 32MB will extend the life span of hard drives quite a bit. I imagine that they'll stay spun down quite a bit.

Hijack v394 has been available for several hours now.

The only change is that I completed some coding from earlier, so that as much as 64MB of DRAM can now be used with Mk2a units. Earlier kernels detected and enabled such, but couldn't properly handle it all in other parts of the kernel. Now fixed.

The kernel on Paul's player is identical to v394 (and probably says "v394" at startup).

Cheers

Actually, I think that is still 391... It takes a lot to keep the players in sync (with the big disk drives and all), so I haven't done any updates for a little while. Edit: Nevermind... I understand now. It just took a little extra time...

Do you think there would be any added concerns with handling the player? Does the higher stacked RAM add any (extra) fragility to the player?

Is this better???

Yes!

Meanwhile, any trouble?

Ha! As I earlier predicted, adding a third layer added an order of magnitude of difficulty. The air turned blue when I lost the RAS pin of one of the middle chips in a stack. Attempts to dig the epoxy on that one hadn't suceeded by the time all the excavation had disturbed the RAS pin on the chip above it to the point where that one disappeared too. At that point I removed and replaced both chips on that stack. Fortunately desoldering the extra chips was easy (so much so that if I had known I would have not bothered digging at all). Added two new chips, wired up the RAS line for the bottom layer and and then noticed that I'd lost the top RAS pin on the other stack that now had a wire running across it (that I had absolutely no desire to remove.)
After turning the air blue again, that one did excavate (easier to excavate the top of the package down). Got the second RAS line wired.

Tested, removed one short and one open pin (not bad considering) to pass the memory test. But it fell over whenever I quit the player app on the serial port or whenever the (huge) database was being loaded, always with the same 'Bad Address' error. Spent an age carefully testing and retouching all the address lines (which aren't exhaustively tested by the kernel) to no avail, same error every time. Finally broke down and rewired the RAS lines at the CPU for 32MB only which passed a soak test. Rewired to use the other 16MB as part of 32MB which also passed a soak test. Paged Mark who spun a kernel fix in a few minutes. (New kernel should work for 64MB too apparently.) Installed kernel, tested fine on 32MB, rewired both RAS wires for 48MB, prayed to the God of Small Things Containing Magic Smoke and booted into 48MB nirvana.

Any ill effects?

Only a few frayed nerves.

Any noticeable differences?

I don't know that I'm qualified to tell. Obviously the player is still only using 16MB, and that is where you will see the biggest improvement when the empeg guys can be persuaded to spin a tweaked player binary sometime, your disks just down spin down.
The web interface is very snappy - I can refresh /proc/empeg_screen.png without any delay.

Any photos???

Not yet. My (old) digital camera doesn't do macro. I'll try and take a couple anyway.

Wow! I am just in awe!!! THANKS!!!

Does the higher stacked RAM add any (extra) fragility to the player?

The stacking itself shouldn't - you've got 49 soldered connections holding each layer down. What will add fragility is that each layer takes the RAS wires closer to the IDE cable and that vibration could be transmitted through the cable to these wires that could cause them to work loose or (worse) pull a RAS pin off of a chip. This risk will be mitigated by gluing the wires to the tops of the chips where they cross to prevent them moving. I'm also going to run a length of electrical tape across the top for extra protection. Hmm. Maybe I'll hotglue a small piece of polycarbonate across instead - less 'gooey'.

Would the longer IDE cables help in any way? I have a few of them that I meant to install next time I was inside the players...

Would the longer IDE cables help in any way?

Might do. The issue is that this is where the cable bends under the end of the drive tray and that the cable doesn't naturally bend with a zero radius. I thought about either taping or gluing the cable to the underside of the tray to keep it raised up off of the chips, but I don't think that can be done with the stock cable because there wouldn't be enough slack to insert or remove the cable end on the motherboard header. A longer cable might make this a possiblity - if it does I'd recommend doing that as an additional precaution.

Go with the (very thin) polycarbonate instead. One really does NOT want to restrict the movement of longer IDE cables in any way -- defeats the whole purpose behind them.

Cheers (and congrat's!)

I successfully soldered in the extra bank with very little difficulty, Perfoming a Ctrl-T mem test before connecting the RAS line which passed first time. I then connected the RAS line to RAS#1 on the SA. But Linux didn't detect the RAM, ( V394 of Hijack) re checked all pins with a meter and touch up a couple. But still no good, downgraded to hijack.mk2a-32mb.zImage and the modified 0e1000 image. got errors from the ramtest in the kernel, but they were the same with and without the RAS line connected!
More out of deperation than anything I removed the chips and tried a second set. Same result!

These chips were sent to the UK by Airmail is there any chance they were damaged in transit, I know a while back the US were nukeing post as a precaution. Is this still happening, or have i just f##ked up, should I order another set do you think?

On a plus note the player still works!!!

Greetings!

I don't think they are irradiating stuff anymore. If they did, I would not think that the envelope would survive with the chips being nuked.

Do you have any saved log files or boots that might show errors or if some of the RAM is being seen? It might just be a solder bridge or one line.

Boot logs would be useful (the memory test in particular). From the description it sounds like an issue with your RAS line.

To disable the extra RAM you have to tie its RAS pin high to VDDX on the SA. It's active low and will probably interfere with the original RAM is left floating. VDDX is available at pin 120.

I find it highly unlikely that two sets have been damaged in transit. Try again.

Thanks, I'll try again tommorow. Only thing is the chips ( and my empeg are covered in flux, whats the best way to remove this before i start? )

Attached is the boot log for the last attempt

Sounds like you perhaps were not getting the bank select pin correct.

-ml

Any photos???

Photo Album.

Excuse the dodgy 'macro' shots.

Photographs and memories... (How many people recognized the reference there?)

Wow!!! Very nice!!! Excellent work!!!

I am just wondering if there is any easier way of dealing with the RAS pins for other installation. They seem incredibly fragile with only two chips stacked, let alone three... Note: I am not good at this kind of thing, so I leave it to the experts to see if there are any alternatives...

But - just a thought: all of the other pins need to be straighted to make contact with the chip below it. What if the RAS pin is left bent (as original from the package) or rebent so that the bottom portion of that pin is flush against the bottom of the chip? Would it be possible to use a small piece of cardboard with a conductor on it, or a very thin wire (I am thinking circuit board trace material here), place it under the chip and solder and secure the RAS line to it from below before placing it on the stack? Run that thin wire between the stacked chips rather than above. It might be more stable and, because the RAS pin doesn't need to be bent back, might be easier for RAS soldering with less risk of the pin breaking off. I do not know how much of a gap you can have between chips - this might be too much.

A thought. I am just trying to see if there is a way to make it easier - losing a RAS pin seems both a common problem and annoying to fix.

Thats more or less what i'm going to try this afternoon, i've got some very thin enambled wire that i'm going to try runing under it's chip and out the bottom. can't think of a nice way of joining the two chips together so i guess it will be a solder joint at the bottom of the middle chip..

On another note which of the two chips is the Low half of the bank?

Is 64MB our max or could we replace the existing chips with 16mb versions and run the extra address line to the SA! 128mb would be intresting!

R.

According to Hugo, IIRC, 64Mb is indeed the maximum amount of memory the Empeg will take.

according to the guy that develops linux for the sa1100 cpu, it can take 128mb (32mb per bank). Now whether our little empegs can use 16mb chips is a different matter.

According to the SA data sheet it can take 128mb per bank, but i'm guessing that those chips would have a higher pin count!

R.

The SA-1100 CPU (Empeg/RioCar) can have up to 128MBytes of DRAM per bank. The processor supports up to four banks, so the absolute hacker's limit on the Empeg/RioCar is 512MBytes of DRAM without adding any more external logic.

The practical limit appears to be 48MB, but it may be possible to install 16MB chips in place of the current 8MB chips, which would give a practical limit of 96MB.

Cheers

If it's possible to use 16MB chips, wouldn't it be easier to use those then? I imagine it must be easier to desolder those 8MB chips and put 16MB chips in their place (to reach 32MB, which I think would be enough), than to piggy-back chips ontop of each other. There would also be less risk of breaking a pin on the chips while soldering them.
(this is just guesswork from my part ; I can't solder to save my life !)