A10 MTD NAND driver update - let's say goodbye to LiveSuit

876 views
Skip to first unread message

Qiang Yu

unread,
Jun 25, 2013, 9:23:10 PM6/25/13
to linux...@googlegroups.com
Hi lists,

The A10 MTD driver can read/write SPL partition by itself now:

The new added character device /dev/nand1k can be used to make this done:
/dev/mtd0 (offset=0, size=128 pages) 
$ flash_eraseall /dev/mtd0
$ dd if=spl/sunxi-spl.bin of=/dev/nand1k bs=1024
$ dd if=spl/sunxi-spl.bin of=/dev/nand1k bs=1024 seek=64

The /dev/nand1k is actually an interface to access the first 128 pages in 1k, random enabled and mode 8 ECC. So "bs=1024" is fixed for every chip.

There are two places to start writing the SPL image, the 0th page and the 64th page. Both can boot the SPL. Burn both of them make the board reliable.

The nand1k interface doesn't have any lock to work exclusively with the MTD interface. So don't use it when system running on top of MTD. It is just used to burn the first SPL image when system running on SD card or NFS. (My previous way to get this image is by using LiveSuit) After that, the image can be dumped from /dev/mtd0 and write to other boards through /dev/mtd0 again.

By the way, the uboot is also updated to be able to update SPL partition from sunxi-spl.bin:
by adding a "nand read/write.1k" command.

Regards,
Qiang


Oliver Schinagl

unread,
Jun 26, 2013, 3:47:14 AM6/26/13
to linux...@googlegroups.com
On 26-06-13 03:23, Qiang Yu wrote:
> Hi lists,
>
> The A10 MTD driver can read/write SPL partition by itself now:
> https://github.com/yuq/sunxi-nfc-mtd
>
Amazing.

You should also be happy to know that rz2k has been working on
integrating the mtd driver into u-boot/kernel aswel fixing little things
as he can.

So very cool.
> --
> You received this message because you are subscribed to the Google
> Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to linux-sunxi...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

Oliver Schinagl

unread,
Jun 26, 2013, 4:00:07 AM6/26/13
to linux...@googlegroups.com
On 26-06-13 09:47, Oliver Schinagl wrote:
> On 26-06-13 03:23, Qiang Yu wrote:
>> Hi lists,
Hey, one more question
>>
>> The A10 MTD driver can read/write SPL partition by itself now:
>> https://github.com/yuq/sunxi-nfc-mtd
>>
> Amazing.
>
> You should also be happy to know that rz2k has been working on
> integrating the mtd driver into u-boot/kernel aswel fixing little things
> as he can.
>
> So very cool.
>> The new added character device /dev/nand1k can be used to make this done:
>> /dev/mtd0 (offset=0, size=128 pages)
>> $ flash_eraseall /dev/mtd0
>> $ dd if=spl/sunxi-spl.bin of=/dev/nand1k bs=1024
>> $ dd if=spl/sunxi-spl.bin of=/dev/nand1k bs=1024 seek=64
>>
>> The /dev/nand1k is actually an interface to access the first 128 pages
>> in 1k, random enabled and mode 8 ECC. So "bs=1024" is fixed for every
>> chip.
>>
>> There are two places to start writing the SPL image, the 0th page and
>> the 64th page. Both can boot the SPL. Burn both of them make the board
>> reliable.
>>
>> The nand1k interface doesn't have any lock to work exclusively with the
>> MTD interface. So don't use it when system running on top of MTD. It is
>> just used to burn the first SPL image when system running on SD card or
>> NFS. (My previous way to get this image is by using LiveSuit) After
>> that, the image can be dumped from /dev/mtd0 and write to other boards
>> through /dev/mtd0 again.
So if I understand correctly, this nand1k thing is only a 'one time
thing' to convert from nand to mtd.

threewater

unread,
Jun 26, 2013, 5:46:31 AM6/26/13
to linux...@googlegroups.com, olive...@schinagl.nl

yes.  nand1k device is only used when read or write SPL and BROM can load spl currectly when boot.

在 2013年6月26日星期三UTC+8下午4时00分07秒,Oliver Schinagl写道:

Dmitriy B.

unread,
Jun 26, 2013, 7:35:46 AM6/26/13
to linux...@googlegroups.com
Yep, I did some work on launching mtd on olinuxino, but I still have many questions regarding how NFC works.

So, Qiang, threewater:

1) How hardware ECC works in combo with MTD tools that use OOB? For example, I have 8192+448 NAND, in the standard (sunxi_nand block emulation) driver my chip, for some reason, marked as 8192+32 (0x2000+0x20). If different OOB size is needed for each type of chip, we will need to modify drivers/mtd/nand/nand_base.c (also in 3.4 kernel standard MTD driver cant decide right for chips with big OOB sizes like 448 or 640. if you have changes to nand_*.c or mtd includes, please, share them). Why driver doesnt care about blank pages ECC checking and everything, even pages with no errors go through the HWECC? I copied this check from Samsung's ECC driver: https://github.com/rzk/linux-sunxi/blob/048177f49950706978bb110387807b0103a42949/drivers/mtd/nand/sunxi-nand/nfc.c#L844

2) How ECC modes correlate with NAND ECC support. For example, my NAND chip has 100bit/2048byte ECC defined in datasheet. What ECC mode should I use for Allwinners NFC?

3) Why random is completely disabled in your driver? (https://github.com/yuq/sunxi-nfc-mtd/blob/master/nfc.c#L1046) Shouldn't it be enabled all the time for MLC NANDs?

4) What does this line mean https://github.com/yuq/sunxi-nfc-mtd/blob/master/nfc.c#L400 ? And also, driver needs to get rid of many magic numbers like this one. This should be defined somewhere with understandable naming.

5) If I have OOB less that 1024, but read_size is set to 1024, will NFC read only needed OOB size? I met a condition in my tests when I had OOB data overlapping with normal data, dont quite remember how I did it, but it was something related to read_size.


7) Right now driver works very bad with badblock table and checking. I have confirmed that last 4 blocks of my NAND are bad (wrong data after reboot is stored there), but neither system badblock check, badblock table of ubifs detect that these blocks are bad. Standard Allwinner's driver has different block quantity for my NAND chip set, it is 950 instead of full 1024 (maybe they faced same issue). Any ideas and can this be connected to NFC or could this be a particular NAND chip problem?

I want to thank you for sharing you progress and going open source, this is really appreciated. Please don't mind if some of my questions seem a bit plain.

Best Regards,
Dmitriy Beykun

2013/6/26 Oliver Schinagl <olive...@schinagl.nl>

Henrik Nordström

unread,
Jun 26, 2013, 9:37:56 AM6/26/13
to linux...@googlegroups.com
ons 2013-06-26 klockan 15:35 +0400 skrev Dmitriy B.:


> 1) How hardware ECC works in combo with MTD tools that use OOB? For
> example, I have 8192+448 NAND, in the standard (sunxi_nand block
> emulation) driver my chip, for some reason, marked as 8192+32 (0x2000
> +0x20). If different OOB size is needed for each type of chip, we will
> need to modify drivers/mtd/nand/nand_base.c (also in 3.4 kernel
> standard MTD driver cant decide right for chips with big OOB sizes
> like 448 or 640. if you have changes to nand_*.c or mtd includes,
> please, share them).

There is MTD updates in later kernel versions to properly detect OOB
size of most chips used.

> 3) Why random is completely disabled in your driver?
> (https://github.com/yuq/sunxi-nfc-mtd/blob/master/nfc.c#L1046)
> Shouldn't it be enabled all the time for MLC NANDs?

Yes the randoizer needs to be enabled for reliable MLC operation.

> 4) What does this line mean
> https://github.com/yuq/sunxi-nfc-mtd/blob/master/nfc.c#L400 ? And
> also, driver needs to get rid of many magic numbers like this one.
> This should be defined somewhere with understandable naming.

Looks like an attempt to handle raw OOB reading. Not something you
normally do on a controller with hardware ECC managing OOB data but good
for diagnostics maybe. Does not really make sense to count OOB in
sectors, and should only read the OOB size amount of data, not 1024.

> 5) If I have OOB less that 1024, but read_size is set to 1024, will
> NFC read only needed OOB size? I met a condition in my tests when I
> had OOB data overlapping with normal data, dont quite remember how I
> did it, but it was something related to read_size.

The NAND controller handles OOB reading automatically for each "sector"
read.
Looks like a workaround to upper layer MTD issues.

> 7) Right now driver works very bad with badblock table and checking. I
> have confirmed that last 4 blocks of my NAND are bad (wrong data after
> reboot is stored there), but neither system badblock check, badblock
> table of ubifs detect that these blocks are bad. Standard Allwinner's
> driver has different block quantity for my NAND chip set, it is 950
> instead of full 1024 (maybe they faced same issue). Any ideas and can
> this be connected to NFC or could this be a particular NAND chip
> problem?

Not sure how Allwinner manages the badblock table, but is something that
needs to get implemented. I tried doing a quick grep of the AW nand
driver, but only ended up in dead ends.. some magic sauce missing for my
greps I hope.

The initial bad tables is marked in OOB data by the nand chip
manufacturer, but there is additional bad block data collected runtime
managed elsewhere as relying on the OOB marker data of bad blocks is not
reliable.

Regards
Henrik


Dmitriy B.

unread,
Jun 26, 2013, 9:47:05 AM6/26/13
to linux...@googlegroups.com
Looks like a workaround to upper layer MTD issues.
Yes, without this workaround MTD in both 3.0 and 3.4 will chipselect -1 and nfc_second_init will fail to read the ID. I also added defines for sun4i and sun5i different CS pin numbers, if MTD will send horribly wrong chipselect, driver will BUG(); instead of just writing the number to register.

Qiang Yu

unread,
Jun 26, 2013, 11:35:32 AM6/26/13
to linux...@googlegroups.com
On Wed, Jun 26, 2013 at 7:35 PM, Dmitriy B. <rzk...@gmail.com> wrote:
Yep, I did some work on launching mtd on olinuxino, but I still have many questions regarding how NFC works.

So, Qiang, threewater:

1) How hardware ECC works in combo with MTD tools that use OOB? For example, I have 8192+448 NAND, in the standard (sunxi_nand block emulation) driver my chip, for some reason, marked as 8192+32 (0x2000+0x20). If different OOB size is needed for each type of chip, we will need to modify drivers/mtd/nand/nand_base.c (also in 3.4 kernel standard MTD driver cant decide right for chips with big OOB sizes like 448 or 640. if you have changes to nand_*.c or mtd includes, please, share them). Why driver doesnt care about blank pages ECC checking and everything, even pages with no errors go through the HWECC? I copied this check from Samsung's ECC driver: https://github.com/rzk/linux-sunxi/blob/048177f49950706978bb110387807b0103a42949/drivers/mtd/nand/sunxi-nand/nfc.c#L844

I don't modify anything to nand_*.c. The reason for 8192+448 NAND page being recognized as 8192+32 is for Allwinner NFC page read operation can't read out the full page. It can just read the 8192 data, then 32 bytes of OOB in USER_DATA registers. I also notice the kernel can't detect OOB size correctly, hope it will be fixed latter. 

The HWECC is completed when read, the check_ecc() just check the result. It's OK to call it for every page. Also we can't get the read_ecc because the NFC read limit (can't read out the full OOB, just user data).
 
2) How ECC modes correlate with NAND ECC support. For example, my NAND chip has 100bit/2048byte ECC defined in datasheet. What ECC mode should I use for Allwinners NFC?

This is by looking up a table provided by Allwinner:
 

3) Why random is completely disabled in your driver? (https://github.com/yuq/sunxi-nfc-mtd/blob/master/nfc.c#L1046) Shouldn't it be enabled all the time for MLC NANDs?

Yes, it should if needed. It was not enabled for nand1k didn't work at that time, so I thought it was not ready yet.
 

4) What does this line mean https://github.com/yuq/sunxi-nfc-mtd/blob/master/nfc.c#L400 ? And also, driver needs to get rid of many magic numbers like this one. This should be defined somewhere with understandable naming.

This just set the sector number to 1 for reading 1 sector from NAND chip.
 

5) If I have OOB less that 1024, but read_size is set to 1024, will NFC read only needed OOB size? I met a condition in my tests when I had OOB data overlapping with normal data, dont quite remember how I did it, but it was something related to read_size.

No, it will read out all 1024 byte data.
It should, but I don't know what to do when passed in -1. Maybe the right way is no chip is enabled, so just set it to max (-1 is 0xffffffff).
 

7) Right now driver works very bad with badblock table and checking. I have confirmed that last 4 blocks of my NAND are bad (wrong data after reboot is stored there), but neither system badblock check, badblock table of ubifs detect that these blocks are bad. Standard Allwinner's driver has different block quantity for my NAND chip set, it is 950 instead of full 1024 (maybe they faced same issue). Any ideas and can this be connected to NFC or could this be a particular NAND chip problem?

This is not the driver's problem. There may be two reasons of this:

The last 4 blocks are used by MTD bad block table itself.

There are there types of bad blocks I met before:
1. good bad block: the last page of the block's OOB user data is not 0xff. This can be detected by kernel boot bad block scan.
2. erase fail bad block: the erase op will fail with error flash chip state. This can be detected by UBI, but not kernel scan.
3. fake good block: the last page is 0xff, appeared to be good, but the first few pages are 0x00, and can't write anything to it. This also can't be detected by kernel scan, I don't remember if UBI can.

To detect all of these bad blocks, you need a user space tool: nandtest
 

--

Henrik Nordström

unread,
Jun 27, 2013, 7:46:40 AM6/27/13
to linux...@googlegroups.com
ons 2013-06-26 klockan 23:35 +0800 skrev Qiang Yu:


> I don't modify anything to nand_*.c. The reason for 8192+448 NAND page
> being recognized as 8192+32 is for Allwinner NFC page read operation
> can't read out the full page. It can just read the 8192 data, then 32
> bytes of OOB in USER_DATA registers. I also notice the kernel can't
> detect OOB size correctly, hope it will be fixed latter.

Yes, those up to 32 bytes are extra byts in addition to the ECC data.

If you want to read the actual OOB data then you need to read that page
offset explicit, with hardware ECC & randomizer disabled. But it's quite
meaningless without knowing the randomizer & ECC details.

Regards
Henrik


yassin...@gmail.com

unread,
Dec 28, 2013, 1:26:04 AM12/28/13
to linux...@googlegroups.com
I've used the original sunxi nand driver to install to the nand. I've disabled the original driver in my new kernel, and try to to use this driver now. I'm getting the following errors
<4>Bad eraseblock 4095 at 0x0000ffffe000
<3>No space left to write bad block table
<3>[MTD][NAND][SUNXI]: nand scan tail fail
<6>[MTD][NAND][SUNXI]: nand gpio_release

with to many Bad eraseblock messages.
I've managed to used in the same board (cubieboard) previously without an issue.
Any help will appreciated.

wpc...@gmail.com

unread,
Apr 3, 2014, 6:16:26 AM4/3/14
to linux...@googlegroups.com
Hello Yassin,

I have encountered exactly the same problem as you. After applying the driver, I cannot read or write due to "Bad eraseblock xx" error. I am writing to ask you whether you have solved the problem. If the answer is yes, would you please tell me the solution.

Thank you very much. Best regards.

Reply all
Reply to author
Forward
0 new messages