[Balloon] Re: Balloon3 - how much (and what shape) RAM?

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Wookey
Date:  
To: balloon
Subject: [Balloon] Re: Balloon3 - how much (and what shape) RAM?
+++ Steve Wiseman [04-10-07 11:00 +0100]:
> 07/10/2004 09:45:02, "David Bisset"
> <> wrote:
>
> >Well Samsung obviously have 512M parts in BGA,
>
> I don't have any in my hand, so I don't quite believe that. It's
> plausible, though.
>
> >Given that:
> >a) Most of us have lived happily with 64M (even TCL).
>
> Partly because TCL haven't released the monster version yet.
> There is also the issue of of using Balloon as a compile box, to
> stop the need for cross-compilers.


Cross-compiling gets easier by the day. It'll always be more complicated
than native compilation, but I don't think that not being able to natively
compile openoffice on your balloon should be a major part of the design
process. We do need enough memeory for the target application. If that app
has to be cross-compiled, or natively compiled on a fatter arm system, then
so be it (IMHO).

Nick has been successfully native-compiling on 64MB machines, which is a bit
tight, but shows that it does (currently) work.

> Similarly, if Cambridge
> computerlab is thinking of letting compsci undergrads near them,
> more memory might be handy, if the project wants big datasets
> for video or whatever.


I can certainly imagine reasonable needs for more than 64Mb. 256Mb as a
limit seems adequate, 128 I could probably be persuaded to live with.

> >b) No one has owned up to ever having stacked up TSOP's,
> something you
> >could only do on a few "one offs" given that it wouldn't reflow.
>
> Certainly. It was never proposed as a mainstream solution.
> Imagine the situation where you didn't want to cross-compile. A
> couple of development boards get the stacked-RAM treatment,
> and production boards get what they need.


This does have some utility, but dave's right in saying it rather a minority
interest.

> >c) You can only work within the technology available at the time
> of
> >design.
>
> Yeah. That's why I'm designing in a CPU I don't have, 'preliminary'
> NAND devices, a power controller that's disturbing me by its lack
> of existence, and we're having this discussion about RAM. About
> the only things I'm sure about are the decouplers and resistors...
>
> >I'd say the choice was obvious go for 4 BGA's.
>
> Certainly. They're all different sizes, even though they tend to
> have the same pinout - the Samsung part isn't the same shape as
> either of the Micron offerings. Which one shall I arbitrarily pick, so
> that when the manufacturer changes the die size or shape, we're
> stuffed, since I've had to pack them in so tightly to allow 4 sites.


That is a pain. I was persuaded by dave's 'lets use 4bgas' argument, but if
there really is only one source of whichever we pick, that does indeed
encourage one to stick to TSOP....

> (Note that the PXA26x only supports 4 banks of up to 64Mbytes
> each.


And the same for 27x I presume?

> 256Mbytes is tops, and that will take 8 16-bit-wide chips.
> 32-bit chips aren't commodity, and in TSOP, they're really
> annoying to solder. Double-die SDRAMs from Micron are tempting
> me again. 2 pairs of
> MT48V32M16S2 2.5V 8 Meg x 16 x 4 banks BOTH DIE
> would let us fully populate the whole memory space, or any
> increment up to that.


These are which physical format?

> TSOP does have the benefit that Balloons could be shipped
> memoryless, and hackers could drop on whatever SDRAM and
> NAND devices they fancied / could source. Add to that TSOP54's
> universal shape, size and availability, and it's not ruled out yet. It's
> certainly the safest option.


Agreed, but it does limit production variants to 64Mb - unless the above double-die
thing is TSOP...

> >If you really want 1G then design and build an expansion board
> via the
> >LoonBus (it needs a name...) OK so it will be slower, but the
> capability
> >is there (I assume).
>
> Tricky. It'd need to present as some kind of swap device -
> PXA26x doesn't seem to want to support vast memory spaces.


That's a bit sad. This would be a good option for deveopment.

Wookey
-- 
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK  Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/     play: http://www.chaos.org.uk/~wookey/