Re: XIP kernel + MTD polling interest

[Shane Nay <shane@agendacomputing.com>]

> Cute, and not too horrible because you already had to copy the data
> section
> into RAM at startup anyway. Doing so with an extra section isn't too much
> of
> a problem, and there's enough other 'put this code in a different
> section' 
> magic in the kernel already that that bit isn't too troublesome either.

Hehe, yes :).


> In general, XIP isn't as interesting as I first thought. XIP is mutually 
> exclusive with compression, and RAM is cheaper than flash. That's even 
> _before_ you try to deal with the horrible problems that you're trying to

> work round right now.

Accurate because of the cost differential at this time :).

> But having said that, some of our customers do seem to be on crack so I'm
> looking at XIP anyway :) But I'm trying to get away with declaring 
> that the XIP flash chip is _strictly_ read-only, and that the writable 
> filesystem is to be kept on an entirely different flash chip.
> 
> I should be putting together a version of romfs designed to work on 
> read-only memory chips fairly shortly.

Our device has the flash memory mapped into the memory map of the device. 
So we use some /dev/rom stuff that's floating around on Brads ftp site, or
more recently I threw together a linear mapped version of cramfs which
works rather nicely, and has a slight boost in performance.  (Hair
splitting slight because of cache churning)

Our quandry is we're doing developers units right now, which are all flash,
and the PCB really can't work with two flash chips, so we have to have the
write-ability of the consumer units which have flash and ROM on the dev
units.  In any event, I don't expect it to be that bad on latency since the
flash chips write is really fast, and we can always call into schedule
between buffered writes or whatever.  (10 words at a time?, can't remember,
but those are imperceptable, it's the erase that's a killer)

Thanks,
Shane.



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org