[Arm-netbook] Real size of Mele A1000 NAND

[lkcl luke]

On Fri, May 11, 2012 at 2:29 AM, Tom Cubie <mr.hipboi at gmail.com> wrote:
>
> On May 11, 2012 5:19 AM, "David Given" <dg at cowlark.com> wrote:
>>
>> On 09/05/12 02:42, cnxsoft wrote:
>> [...]
>> > I also have 4GB NAND Flash (although it's more like 3800 MB) and I
>> > ordered with Deal extreme. I guess I used the dealextreme specs on my
>> > blog...
>>
>> 4GB here, too.
>>
>> The NAND driver appears to emulate a real block device, not an MTD
>> device --- most of the partitions contain ext4 file systems. My
>> partition table looks like:
>>
>> Device       Name        Location+Length (512 byte sectors)
>> -------------------------------------------------------------------
>> /dev/nanda   BOOTFS      00000800+00008000
>> /dev/nandb   LROOTFS     00008800+00010000
>> /dev/nandc   LSYSTEMFS   00018800+00080000
>> /dev/nandd   LDATAFS     00098800+00300000
>> /dev/nande   MISC        00398800+00000800
>> /dev/nandf   LRECOVERYFS 00399000+00010000
>> /dev/nandg   LCACHEFS    003a9000+00040000
>> /dev/nandh   env         003e9000+00001000
>> /dev/nandi   UDISK       003ea000 to end
>>
>> BOOTFS is the boot partition, not dissimilar from /dev/mmcblk0p1
>> (although with more stuff in it). env is a uboot environment.
>>
>> The partition table itself is stored at offset 0 in the flash device. As
>> you can see, it's not in any partition, and there I haven't found
>> anything like a raw device, which means it can't be edited...
>>
>> The device driver code is in drivers/block/sun4i_nand/nfd; the low level
>> stuff including the wear levelling code is in
>> drivers/block/sun4i_nand/src. I have utterly no idea whether it's any
>> good. Anyone know why they didn't implement an mtdblock driver and use
>> yaffs2?
> well, the people working on nand in allwinner think MTD is an out of date
> technology. i have argued many times that we need a MTD nand driver. why a
> device driver should care about things like wear leveling?

 often any automated wear leveling is completely wrong for the
application or the OS.

 i heard a few years ago that it was possible to destroy one of these
automated DOS-optimised NAND drives within a few minutes, merely by
formatting it for ext2.  the reason was very simple: the block size
chosen for the DOS-optimised NAND drive was 32k, and the ext2 file
system was using 4k blocks.  each write of any one 4k block resulted
in *EIGHT* writes to the exact same 32k block.

 jffs2 was designed to absolutely minimise wear, but it cannot operate
effectively on top of some other silly layer.

 l.