[Tfug] Media cards

[Tom Rini]

On Sun, Jan 04, 2009 at 12:02:20PM -0800, Bexley Hall wrote:
> Hi, Tom,
> 
> --- On Sun, 1/4/09, Tom Rini <trini at kernel.crashing.org> wrote:
> 
> > > There seem to be more d*mn media card standards than there
> > > are media card manufacturers!
> > > 
> > > SD, SDHC, CF, MS, SM, each of the preceding with "high speed"
> > > option, etc.  (yes, there are several others, as well :<  )
> > > 
> > > I'm trying to figure out which to use in a new design.
> > > I think all except CF are intended as "secondary storage"
> > > as they all have serial interfaces.  I.e., you can't do XIP
> > > using them (well, not unless you keep faulting in pages!)
> > > 
> > > But, CF is big, bulky, more prone to damage, etc.
> > > 
> > > Any thoughts on this?
> > 
> > All of the removable ones are designed for, well, being
> > swapped in and
> 
> Yes.  And, for most applications (besides PDAs), I suspect
> data crosses the interface very infrequently (e.g., in a
> camera, you push the images into the card and they pretty
> much sit there; in an MP3 player, you pull them off the
> card as you are playing, etc.).

Well, in a camera, each new snap is a set of writes.  In a nav system,
you've got infrequent write data (maps) and more frequent write data
("home", frequent places, etc, etc).  In a MID/NetBook, it depends on
how often media gets swapped out.

> > out.  If you want primary the question is, will the data be
> 
> <frown>  Perhaps something ^^^^ missing here?  :-/

If you want a more precise answer, the question is ...
> 
> > modified a lot or not?  The big big flash chips (the name of 
> 
> I don't want to have "redundant" components in the design.
> E.g., in a PDA, you load applications off the card into
> "RAM" where you can execute them "at CPU speed".  Or, you
> have to run an interpreter/VM in the application such that
> the slower "data stream" from the card is still fast enough
> to implement the application.
> 
> The problem with "loading" an application in either of these
> ways is it means something *else* limits the practical size
> of your application (e.g., the RAM in the device).
> 
> I'd prefer an XIP approach -- if an application grows, just
> use a bigger card to store the application (i.e., the application
> implicitly carries its baggage with it).

Well, it really really depends on what the device you're designing is
actually going to be doing, what the price point is, and so on.  The
devel boards we work with have a lot of choices for where various forms
of storage can be attached and size/formfactor.  The end devices we work
on usually have two or three, depending on what's really going on and
what the end user is allowed to do.  Two common (NAND for on-board, some
form of SD for cards and often there's host mode USB for that too.  Of
course we're pretty much a Linux-only shop and usually XIP for the apps
has been considered and then decided against as it's easy enough to get
enough RAM and still be within the price point.

-- 
Tom Rini