Thread: Time for an open maemo fork?
View Single Post
Funklord is offline Funklord
2011-03-14 , 00:33
Posts: 69 | Thanked: 41 times | Joined on Feb 2010 @ Sweden
#51
Originally Posted by wmarone View Post
I'm not quite sure what you're getting at. In any case, you can boot from NAND directly, pretty much every smartphone does it and an increasing number of basebands are. NOR, IIRC is being dumped due to its price, lack of density, and decreasing support for it in SoCs.
I don't see NOR going anywhere, especially as small boot devices, since you can execute-in-place, it saves a lot of ram, decreases boot-up times and increases performance.

I wasn't talking about SoCs, rather normal designs, which have a typical mcu, bus and maybe 8-9 memory parts etc.

Originally Posted by wmarone View Post
Not really. The problem is utilizing filesystems that are unaware of how NAND behaves and treat it like a rotating disk. Properly using SSDs is a popular research topic in industry precisely because of this problem, and those are exposed solely via a block interface. Exposing the raw NAND interfaces doesn't gain you much, and complicates things as you add devices. As for performance, that's mostly a matter of parallelism and the controller. With raw NAND your controller becomes the CPU via software (and detracts from the experience.) As for faulty blocks, they should be mapped out transparently by the eMMC's logic. If not, and you're seeing block errors, then your eMMC device is either faulty or dying and should be replaced. Hard, of course, for something soldered down, but devices like this aren't designed for frequent turnover of erase blocks.
Faulty blocks are a natural thing for flash, you're supposed to mark them as "bad" and just move on, using the rest of the flash.
What does the ftl do when there are not enough blocks to left to cover the "virtual size" of the block device? There is no solution, since a block device per definition cannot decrease in size.
Soon we'll all be using mlc-nand, which is very rare to get without bad blocks from the factory.
When using ftl It's very difficult to predict what will happen during brownouts etc. just that fact makes it unsuitable for embedded designs in general.
In my experience the speedups I've seen when using ubifs instead of ftl were huge.
Here's a good explanation of pros and cons of ftl.

Using raw nand with a suitable filesystem allows you to use the flash memory as you'd use a hard drive normally, without worrying about waring it out prematurely. You can switch on things like logging etc. And since it's transparent, you can see if your bad-blocks list is increasing at an alarming rate. (with ftl that would be hidden, or a proprietary interface)

An FTL chip will also utilise at least as much power as you'd have required for the added cpu-time and ram, so there's no difference here.

IMO FTL is just a temporary solution to use flash with old filesystems and operating systems, we don't really need it anymore and should get rid of it.

Originally Posted by wmarone View Post
Depends on how many. I haven't done much research into UBIFS, but if you look at some of the ELC presentations, you can get an idea of memory and cpu utilization various flash filesystems incur.
I checked, ubifs is suitable up to 16GiB according to them.