mainline NAND

Michal Suchanek

unread,

Dec 16, 2014, 1:01:58 PM12/16/14

to linux-sunxi

Hello,

I tried to rebase the v7 patchset on top of 3.18 and add the DT
bindings on cubieboard:
https://github.com/hramrach/linux-sunxi/commit/a946d593ddcf443b0f035f6d39fe0c558189dacc

The nand driver fails equally on both cubieboard versions:

cubieboard:
[ 0.643554] calling nand_base_init+0x0/0x20 @ 1
[ 0.643565] initcall nand_base_init+0x0/0x20 returned 0 after 3 usecs
[ 0.643578] calling sunxi_nfc_driver_init+0x0/0x10 @ 1
[ 0.665751] nand: Could not find valid JEDEC parameter page; aborting
[ 0.670907] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xd7
[ 0.675949] nand: Samsung NAND 4GiB 3,3V 8-bit
[ 0.679098] nand: 4096MiB, MLC, page size: 8192, OOB size: 640
[ 0.683748] sunxi_nand 1c03000.nand: ECC init failed: -22
[ 0.687839] sunxi_nand 1c03000.nand: failed to init nand chips
[ 0.692440] sunxi_nand: probe of 1c03000.nand failed with error -22
[ 0.697500] initcall sunxi_nfc_driver_init+0x0/0x10 returned 0
after 52642 usecs
cubieboard2:
[ 0.666766] calling nand_base_init+0x0/0x20 @ 1
[ 0.666777] initcall nand_base_init+0x0/0x20 returned 0 after 3 usecs
[ 0.666790] calling sunxi_nfc_driver_init+0x0/0x10 @ 1
[ 0.683003] nand: Could not find valid JEDEC parameter page; aborting
[ 0.688159] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xd7
[ 0.693201] nand: Samsung NAND 4GiB 3,3V 8-bit
[ 0.696349] nand: 4096MiB, MLC, page size: 8192, OOB size: 640
[ 0.700956] sunxi_nand 1c03000.nand: ECC init failed: -22
[ 0.705060] sunxi_nand 1c03000.nand: failed to init nand chips
[ 0.709658] sunxi_nand: probe of 1c03000.nand failed with error -22
[ 0.714768] initcall sunxi_nfc_driver_init+0x0/0x10 returned 0
after 46833 usecs

Is this expected or does somebody have the driver working on some device?

Thanks

Michal

Henrik Nordström

unread,

Dec 16, 2014, 2:28:37 PM12/16/14

to linux...@googlegroups.com

tis 2014-12-16 klockan 19:01 +0100 skrev Michal Suchanek:
> Hello,
>
> I tried to rebase the v7 patchset on top of 3.18 and add the DT
> bindings on cubieboard:
> https://github.com/hramrach/linux-sunxi/commit/a946d593ddcf443b0f035f6d39fe0c558189dacc
>
> The nand driver fails equally on both cubieboard versions:
>
> cubieboard:
> [ 0.643554] calling nand_base_init+0x0/0x20 @ 1
> [ 0.643565] initcall nand_base_init+0x0/0x20 returned 0 after 3 usecs
> [ 0.643578] calling sunxi_nfc_driver_init+0x0/0x10 @ 1
> [ 0.665751] nand: Could not find valid JEDEC parameter page; aborting
> [ 0.670907] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xd7
> [ 0.675949] nand: Samsung NAND 4GiB 3,3V 8-bit
> [ 0.679098] nand: 4096MiB, MLC, page size: 8192, OOB size: 640
> [ 0.683748] sunxi_nand 1c03000.nand: ECC init failed: -22

Not sure what this (EINVAL on ECC init) means exactly, but it looks like
it dislikes the kind of NAND chip used.

This NAND chip is not providing JEDEC information so a lookup table
compiled in the driver is used for determining the NAND chip parameters.
Maybe there is invalid parameters in that table, or the NAND chip
requires an ECC mode not yet supported by the driver.

Regards
Henrik

Boris BREZILLON

unread,

Dec 17, 2014, 5:40:45 AM12/17/14

to linux...@googlegroups.com

Hi Michal

As Henrik already answered, it seems that your NAND chip is not properly defined in the nand_ids table [1].

Read your NAND datasheet and add a new entry (take a look at this one [2] as an example).

You should also fill the correct timing mode, though mode 0 should work correctly on all recent NANDs.

Best Regards,

Boris

[1]http://lxr.free-electrons.com/source/drivers/mtd/nand/nand_ids.c#L28

[2]http://lxr.free-electrons.com/source/drivers/mtd/nand/nand_ids.c#L49

Michal Suchanek

unread,

Dec 17, 2014, 1:07:44 PM12/17/14

to linux-sunxi

Hello,

The nand chip says Samsung 222 K9GBG08U0A SCB0

Is there some document on filling out his table?

It seems that 0xec 0xd7 matches info on top op page 80 of
http://www.datasheet4u.com/datasheet-pdf/Samsung/K9GBG08U0A/pdf.php?id=704185

But that table lists 0xec, 0xd7, 0x94, 0x76, 0x64, 0x43 and additional
debug output shows that the chip sends Manufacturer ID: 0xec, Chip
ID: 0xd7; 0x94 0x7a 0x54 0x43 0xec 0xd7 the last two bytes possibly
being wrap-around of the first two.

However, that document lists multitudes of identification strings.
Which one is used where in the table?

The document lists that there is 8k page and 640 oob which matches
existing output. It also says that that ecc is 40bit (1k + 80byte) on
page 5 which looks like value obtained by dividing that 640 oob data
by 8 to get oob amount per 1k - no staggering new information.

Some timing information is presented on pages 18-19 but the provided
table has way more data than a nand entry in the kernel table.

Thanks

Michal

Yassin Jaffer

unread,

Dec 18, 2014, 2:10:16 AM12/18/14

to linux...@googlegroups.com

Hi Michal

add the following to the nand id table

{"K9GBG08U0A 32G 3.3V 8-bit",

{ .id = {0xec, 0xd7, 0x94, 0x7a, 0x54, 0x43} },

SZ_8K, SZ_4K, SZ_1M, 0, 6, 640, NAND_ECC_INFO(40, SZ_1K),

0 },

http://lxr.free-electrons.com/source/include/linux/mtd/nand.h#L787

--
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/d/optout.

Michal Suchanek

unread,

Dec 18, 2014, 7:48:16 AM12/18/14

to linux-sunxi

> Hi Michal
>
> add the following to the nand id table
>
> {"K9GBG08U0A 32G 3.3V 8-bit",
> { .id = {0xec, 0xd7, 0x94, 0x7a, 0x54, 0x43} },
> SZ_8K, SZ_4K, SZ_1M, 0, 6, 640, NAND_ECC_INFO(40, SZ_1K),
> 0 },

Yes, that's what you can obviously do. If the ID listed in the
datasheet and the ID read by the kernel does not agree put the ID read
in the table.

However, how is Joe User with a Chinese tablet supposed to add his NAND chip?

Some people are willing to open the device and look at the chip,
especially when the case is easy to take apart. Finding a datasheet
once you have seen the chip is not that much of a problem, either.

But if the data in the datasheet is useless and the kernel does not
even print the full ID unless you patch it how do you get to your
device working form that point?

If a Joe User sent us this datasheet can we fabricate an ID entry form
that datasheet alone? How?

If not should we add a patch to the kernel to always print the full
ID? If so how can we believe *anything* in the datasheet if even
something as simple and basic as chip ID is wrong?

Thanks

Michal

Henrik Nordström

unread,

Dec 18, 2014, 8:13:44 AM12/18/14

to linux...@googlegroups.com

tor 2014-12-18 klockan 13:47 +0100 skrev Michal Suchanek:

> Yes, that's what you can obviously do. If the ID listed in the
> datasheet and the ID read by the kernel does not agree put the ID read
> in the table.
>
> However, how is Joe User with a Chinese tablet supposed to add his NAND chip?

If the chip supports JEDEC identification then it's supposedly
automatically configured.. sadly it seems most chineese tablets uses
non-JEDEC identified NAND chips.

If not then one need to go thru the manual process of finding the
datasheet and try to find needed parameters from there which means
opening the device to find the NAND chip model, search the Internet for
a datasheet (if lucky), or find something usable in the Allwinner
drivers if you can find usable source version.

> If a Joe User sent us this datasheet can we fabricate an ID entry form
> that datasheet alone? How?

Only if the datasheets lists usable identification strings, something
many get wrong even from well known NAND manufacturers.

> If not should we add a patch to the kernel to always print the full
> ID? If so how can we believe *anything* in the datasheet if even
> something as simple and basic as chip ID is wrong?

General timing data should be correct, but... honestly I have even seen
page size and OOB size being specified wrongly in datasheets.

For many chips finding any reliable information is not easy.

Regards
Henrik

Michal Suchanek

unread,

Dec 18, 2014, 10:06:51 AM12/18/14

to linux-sunxi

On 18 December 2014 at 08:10, Yassin Jaffer <yassin...@gmail.com> wrote:

> Hi Michal
>
> add the following to the nand id table
>
> {"K9GBG08U0A 32G 3.3V 8-bit",
> { .id = {0xec, 0xd7, 0x94, 0x7a, 0x54, 0x43} },
> SZ_8K, SZ_4K, SZ_1M, 0, 6, 640, NAND_ECC_INFO(40, SZ_1K),
> 0 },

So with the extra entry I get:

nand: device found, Manufacturer ID: 0xec, Chip ID: 0xd7

nand: chip id data:
0xec, 0xd7,
0x94, 0x7a,
0x54, 0x43;
0xec, 0xd7

BTW can you make kernel *NOT* insert newline after every other printk?

nand: Samsung K9GBG08U0A 32G 3.3V 8-bit

nand: 4096MiB, MLC, page size: 8192, OOB size: 640

Bad block table not found for chip 0
Bad block table not found for chip 0
Scanning device for bad blocks
Bad eraseblock 20 at 0x0000014fe000
Bad eraseblock 21 at 0x0000015fe000
Bad eraseblock 36 at 0x0000024fe000
Bad eraseblock 37 at 0x0000025fe000
Bad eraseblock 38 at 0x0000026fe000
Bad eraseblock 39 at 0x0000027fe000
Bad eraseblock 40 at 0x0000028fe000
Bad eraseblock 41 at 0x0000029fe000
Bad eraseblock 42 at 0x000002afe000
Bad eraseblock 43 at 0x000002bfe000
Bad eraseblock 44 at 0x000002cfe000
...
Bad eraseblock 4094 at 0x0000ffefe000
Bad eraseblock 4095 at 0x0000ffffe000
No space left to write bad block table
sunxi_nand 1c03000.nand: nand_scan_tail failed: -28

sunxi_nand 1c03000.nand: failed to init nand chips

sunxi_nand: probe of 1c03000.nand failed with error -28

This looks like 100% bad blocks to me so the detection probably fails.

Thanks

Michal

Michal Suchanek

unread,

Dec 18, 2014, 3:45:05 PM12/18/14

to linux-sunxi

On 18 December 2014 at 14:13, Henrik Nordström

hmm, the sunxi nand driver has this:

// NAND_CHIP_ID DieCnt SecCnt
PagCnt BlkCnt OpOpt DatBlk Freq EccMode ReadRetry DDRType
OperationPar
{ {0xec, 0xd5, 0x94, 0x29, 0xff, 0xff, 0xff, 0xff }, 1, 8,
128, 4096, 0x0008, 974, 30, 0, 0, 0,
&PhysicArchiPara3 }, // K9GAG08U0D
{ {0xec, 0xd5, 0x84, 0x72, 0xff, 0xff, 0xff, 0xff }, 1, 16,
128, 2048, 0x0000, 950, 24, 2, 0, 0,
&PhysicArchiPara3 }, // K9GAG08U0E
{ {0xec, 0xd5, 0x94, 0x76, 0x54, 0xff, 0xff, 0xff }, 1, 16,
128, 2048, 0x0408, 950, 30, 2, 0, 0,
&PhysicArchiPara3 }, // K9GAG08U0E
{ {0xec, 0xd3, 0x84, 0x72, 0xff, 0xff, 0xff, 0xff }, 1, 16,
128, 1024, 0x0000, 950, 24, 2, 0, 0,
&PhysicArchiPara3 }, // K9G8G08U0C
{ {0xec, 0xd7, 0x94, 0x76, 0xff, 0xff, 0xff, 0xff }, 1, 16,
128, 4096, 0x0088, 974, 30, 3, 0, 0,
&PhysicArchiPara3 }, // K9GBG08U0A
{ {0xec, 0xd7, 0x94, 0x7A, 0xff, 0xff, 0xff, 0xff }, 1, 16,
128, 4096, 0x0088, 974, 30, 3, 0, 0,
&PhysicArchiPara3 }, // K9GBG08U0A
{ {0xec, 0xde, 0xd5, 0x7A, 0x58, 0xff, 0xff, 0xff }, 2, 16,
128, 4096, 0x0888, 974, 30, 3, 0, 0,
&PhysicArchiPara3 }, // K9LCG08U0A
where 0x88 looks like NAND_MULTI_PROGRAM | NAND_RANDOM
and
974 ValidBlkRatio; //the valid block
ratio, based on 1024 blocks
30 AccessFreq; //the highest access
frequence of the nand flash chip, based on MHz
3 EccMode; //the Ecc Mode for the
nand flash chip, 0: bch-16, 1:bch-28, 2:bch_32

So there are two variants of the K9GBG08U0A chip ID there.

Yassin Jaffer

unread,

Dec 18, 2014, 11:53:18 PM12/18/14

to linux...@googlegroups.com

Hi Michal

This was answered previously by Brezillon . Please search the mailing list.

You have to force bad block erasure to get rid of AW's libnand layout
(which is overriding bad block markers).

Please follow these steps:
1) apply this patch [1]
2) boot on your new kernel and launch
$ flash_erase /dev/mtd0 0 0
3) revert the patch
4) Boot on your new kernel

Most of your bad blocks should be gone after that...

[1]http://code.bulix.org/k2v1hx-87237

Yes K9GBG08U0A has two variants of the chip ID and maybe more...

use some printk in the nand_base.c to get more accurate information about your nand.

Message has been deleted

Pierluigi Scacchi

unread,

Dec 23, 2014, 10:34:03 AM12/23/14

to linux...@googlegroups.com

Hello.
I have a cobieboard a10 with 4GB nand K9GBG08U0A.
I tried the kenel 3:18 nand.
I also followed the indications described by Yassin Jaffer.
I still have many errors "Bad eraseblock ... No space left to write bad block table".
(flash_erase with kernel & a10 dts modified does not reduce them).
I try a series combination changing nand_ids.c
The proposed configuration for a 32 GB K9GBG08U0A not work for 4GB.
How can I fix it?
ids for 32G
{"K9GBG08U0A 32G 3.3V 8-bit"

.id = {{0xec, 0xd7, 0x94, 0x7a, 0x54, 0x43}},
SZ_8K, SZ_4K, SZ_1M, 0, 6, 640, NAND_ECC_INFO (40, SZ_1K), 0},

ids for 4G?

the kernel SunXi for this chip contains a number of parameters that I have difficulty in translating:
NAND_CHIP_ID = {0xec, 0xd7, 0x94, 0x7A, 0xff, 0xff, 0xff, 0xff} (OK)
DieCnt = 1
SecCnt = 16
PagCnt = 128
BlkCnt = 4096
OpOpt = 0x0088
DatBlk = 974
Freq = 30
EccMode = 3
ReadRetry = 0
DDRType = 0

& PhysicArchiPara3 =
static struct __OptionalPhyOpPar_t PhysicArchiPara3 =
{
     {0x60, 0x60}, // multi-plane read command
     {0x11, 0x81}, // multi-plane program command
     {0x60, 0x60, 0x35}, // multi-plane page copy-back read command
     {0x85, 0x11, 0x81}, // multi-plane page copy-back program command
     0x70, // multi-plane operation status read command
     0xf1, // inter-leave bank0 operation status read command
     0xf2, // inter-leave bank1 operation status read command
     0x02, // bad block flag position, in the last page
     1 // multi-plane block address offset
};

Thank You.

Michal Suchanek

unread,

Dec 23, 2014, 6:07:25 PM12/23/14

to linux-sunxi

On 23 December 2014 at 16:13, <scac...@gmail.com> wrote:

> Il giorno venerdì 19 dicembre 2014 05:53:18 UTC+1, Yassin Jaffer ha scritto:
>> Hi Michal

>> This was answered previously by Brezillon . Please search the mailing list.You have to force bad block erasure to get rid of AW's libnand layout

> Hello.
> I have a cobieboard a10 with 4GB nand K9GBG08U0A.

> I tried the kernel 3.18 nand.
> I also followed the indications described by XXXX.

> I still have many errors "Bad eraseblock ... No space left to write bad block table".

This is expected.
You need to apply the two patches that make the kernel ignore bad
blocks, erase flash, and unapply patches.

Presumably that gets rid of the bogus bad block markers.

I did not try the patches. Rather I wanted to keep the bogus flash
content so that I can add proper kernel option for ignoring these
markers that could be set in DT or somewhere and test it.

Should not be overly difficult but did not get to it so far.

Such option is obviously needed so that devices can be upgraded from
factory installed image to mainline image.

The general idea is that when the option is set on a partition the
kernel would initialize the MTD although all flash is marked bad but
would flag it as unusable and only allow erasing it.

> (flash_erase with kernel & a10 dts modified does not reduce them).
> I try a series combination changing nand_ids.c
> The proposed configuration for a 32 GB K9GBG08U0A not work for 4GB.
> How can I fix it?
> ids for 32G
> {"K9GBG08U0A 32G 3.3V 8-bit"

> .id = {{0xec, 0xd7, 0x94, 0x7a, 0x54, 0x43}},

> SZ_8K, SZ_4K, SZ_1M, 0, 6, 640, NAND_ECC_INFO (40, SZ_1K), 0},
>
> ids for 4G?

It's 32gigabits ~ 4gigabytes, presumably.

>
> the kernel SunXi for this chip (4GB) contains a number of parameters that I have difficulty in translating:

You can just ignore these if you get the complaint about bad blocks.
The only interesting bit I found there so far is that the ID seems to
be matched by 5 bytes so possibly more variants of the last byte
exist.

Thanks

Michal

Pierluigi Scacchi

unread,

Dec 25, 2014, 3:54:50 AM12/25/14

to linux...@googlegroups.com

Hi all.
Resolved with
$ flash_erase -N /dev/mtd0 0 0

Now with nand kernel i see:
/dev/mtd0
/dev/mtd0ro
/dev/mtd1
/dev/mtd1ro
/dev/mtd2
/dev/mtd2ro

$ dmesg
[    5.504107] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xd7
[    5.510466] nand: Samsung K9GBG08U0A 4GB 3.3V 8-bit
[    5.515302] nand: 4096MiB, MLC, page size: 8192, OOB size: 640
[    5.710997] Bad block table not found for chip 0
[    5.768800] Bad block table not found for chip 0
[    5.773425] Scanning device for bad blocks
[    5.828759] Bad eraseblock 0 at 0x0000000fe000
[    5.867883] Bad eraseblock 1 at 0x0000001fe000
[    5.902372] Bad eraseblock 2 at 0x0000002fe000
[    5.948928] Bad eraseblock 3 at 0x0000003fe000
[    6.020716] Bad eraseblock 6 at 0x0000006fe000
[    6.059723] Bad eraseblock 7 at 0x0000007fe000
[    6.988123] random: nonblocking pool is initialized

I tried to use UBI FS on mtd2. But i have this problem.
A long series of this errors:

[ 3653.750288] CPU: 0 PID: 846 Comm: ubiattach Not tainted 3.18.0-gigi+ #10
[ 3653.757031] [<c0014440>] (unwind_backtrace) from [<c00115cc>] (show_stack+0x10/0x14)
[ 3653.764775] [<c00115cc>] (show_stack) from [<c0539e7c>] (dump_stack+0x88/0x98)
[ 3653.772023] [<c0539e7c>] (dump_stack) from [<c03653a0>] (ubi_io_read+0x128/0x304)
[ 3653.779519] [<c03653a0>] (ubi_io_read) from [<c0365788>] (ubi_io_read_ec_hdr+0x44/0x210)
[ 3653.787631] [<c0365788>] (ubi_io_read_ec_hdr) from [<c036a038>] (ubi_attach+0x150/0x1368)
[ 3653.795849] [<c036a038>] (ubi_attach) from [<c035ff10>] (ubi_attach_mtd_dev+0x648/0xc08)
[ 3653.803936] [<c035ff10>] (ubi_attach_mtd_dev) from [<c036144c>] (ctrl_cdev_ioctl+0xcc/0x198)
[ 3653.812385] [<c036144c>] (ctrl_cdev_ioctl) from [<c00e80a0>] (do_vfs_ioctl+0x3ec/0x5ac)
[ 3653.820395] [<c00e80a0>] (do_vfs_ioctl) from [<c00e8294>] (SyS_ioctl+0x34/0x5c)
[ 3653.827710] [<c00e8294>] (SyS_ioctl) from [<c000e3e0>] (ret_fast_syscall+0x0/0x30)
[ 3653.882994] UBI warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 2503:0, read only 64 bytes, retry
[ 3653.927378] UBI warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 2503:0, read only 64 bytes, retry
[ 3653.975933] UBI warning: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 2503:0, read only 64 bytes, retry
[ 3654.020387] UBI error: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 2503:0, read 64 bytes

any idea ?
Thanks

Yassin Jaffer

unread,

Dec 25, 2014, 7:02:03 AM12/25/14

to linux...@googlegroups.com

Hi Pierluigi

Can you send the output of your 'mtdinfo -a '.

and what version of mtd-utils you are using? 'versions less than 1.5.1 have a bug with MLC nands'

Pierluigi Scacchi

unread,

Dec 25, 2014, 11:16:10 AM12/25/14

to linux...@googlegroups.com

Hi Yassin,

root@cubie:~# mtdinfo -a

Count of MTD devices: 3

Present MTD devices: mtd0, mtd1, mtd2

Sysfs interface supported: yes

mtd0

Name: boot0

Type: mlc-nand

Eraseblock size: 1048576 bytes, 1024.0 KiB

Amount of eraseblocks: 2 (2097152 bytes, 2.0 MiB)

Minimum input/output unit size: 8192 bytes

Sub-page size: 8192 bytes

OOB size: 640 bytes

Character device major/minor: 90:0

Bad blocks are allowed: true

Device is writable: true

mtd1

Name: boot0-rescue

Type: mlc-nand

Eraseblock size: 1048576 bytes, 1024.0 KiB

Amount of eraseblocks: 2 (2097152 bytes, 2.0 MiB)

Minimum input/output unit size: 8192 bytes

Sub-page size: 8192 bytes

OOB size: 640 bytes

Character device major/minor: 90:2

Bad blocks are allowed: true

Device is writable: true

mtd2

Name: main

Type: mlc-nand

Eraseblock size: 1048576 bytes, 1024.0 KiB

Amount of eraseblocks: 4092 (4290772992 bytes, 4.0 GiB)

Minimum input/output unit size: 8192 bytes

Sub-page size: 8192 bytes

OOB size: 640 bytes

Character device major/minor: 90:4

Bad blocks are allowed: true

Device is writable: true

root@cubie:~# mtdinfo --version

mtdinfo 1.5.1

The version seem correct.

I have an Debian jessie/testing distribution.

Thanks.

Pierluigi Scacchi

unread,

Dec 25, 2014, 2:00:45 PM12/25/14

to linux...@googlegroups.com

Hi all.

Compiled 3:19 kernel-rc1 (https://github.com/wens/linux ) with dts/dtsi 3.18-nand.

I now have a good needed results:

root@cubie:~# dmesg

[ 5.574808] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xd7

[ 5.581167] nand: Samsung K9GBG08U0A 4GB 3.3V 8-bit

[ 5.586089] nand: 4096 MiB, MLC, erase size: 1024 KiB, page size: 8192, OOB size: 640

[ 5.710328] Bad block table found at page 524160, version 0x05

[ 5.765223] Bad block table found at page 524032, version 0x05

[ 5.818924] nand_read_bbt: bad block at 0x000000000000

[ 5.824069] nand_read_bbt: bad block at 0x000000100000

[ 5.829269] nand_read_bbt: bad block at 0x000000200000

[ 5.834400] nand_read_bbt: bad block at 0x000000300000

[ 5.839554] nand_read_bbt: bad block at 0x000000400000

[ 5.844703] nand_read_bbt: bad block at 0x000000500000

[ 5.849833] nand_read_bbt: bad block at 0x000000600000

[ 5.854980] nand_read_bbt: bad block at 0x000000700000

[ 5.860109] nand_read_bbt: bad block at 0x000000800000

[ 5.865256] nand_read_bbt: bad block at 0x000000900000

[ 5.870385] nand_read_bbt: bad block at 0x000001000000

[ 5.875534] nand_read_bbt: bad block at 0x000001100000

[ 6.003147] 3 ofpart partitions found on MTD device K9GBG08U0A 4GB 3.3V 8-bit

[ 6.010359] Creating 3 MTD partitions on "K9GBG08U0A 4GB 3.3V 8-bit":

[ 6.016824] 0x000000000000-0x000000200000 : "boot0"

[ 6.046632] 0x000000200000-0x000000400000 : "boot0-rescue"

[ 6.090295] 0x000000400000-0x000100000000 : "main"

root@cubie:~# ubiformat -s 8192 /dev/mtd2

root@cubie:~# ubiattach /dev/ubi_ctrl -m 2 -O 8192

root@cubie:~# ubimkvol /dev/ubi0 -N main -m

root@cubie:~# mount -t ubifs ubi0:main /mnt

root@cubie:~# dmesg

[ 2043.252786] UBI-0: ubi_attach_mtd_dev:default fastmap pool size: 200

[ 2043.259221] UBI-0: ubi_attach_mtd_dev:default fastmap WL pool size: 25

[ 2043.265741] UBI-0: ubi_attach_mtd_dev:attaching mtd2 to ubi0

[ 2068.980031] UBI-0: scan_all:scanning is finished

[ 2069.012442] UBI-0: ubi_attach_mtd_dev:attached mtd2 (name "main", size 4092 MiB)

[ 2069.019909] UBI-0: ubi_attach_mtd_dev:PEB size: 1048576 bytes (1024 KiB), LEB size: 1032192 bytes

[ 2069.028797] UBI-0: ubi_attach_mtd_dev:min./max. I/O unit sizes: 8192/8192, sub-page size 8192

[ 2069.037324] UBI-0: ubi_attach_mtd_dev:VID header offset: 8192 (aligned 8192), data offset: 16384

[ 2069.046097] UBI-0: ubi_attach_mtd_dev:good PEBs: 4080, bad PEBs: 12, corrupted PEBs: 0

[ 2069.054015] UBI-0: ubi_attach_mtd_dev:user volume: 1, internal volumes: 1, max. volumes count: 128

[ 2069.062977] UBI-0: ubi_attach_mtd_dev:max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 632176814

[ 2069.073756] UBI-0: ubi_attach_mtd_dev:available PEBs: 0, total reserved PEBs: 4080, PEBs reserved for bad PEB handling: 68

[ 2069.087090] UBI-0: ubi_thread:background thread "ubi_bgt0d" started, PID 840

[ 2081.562327] UBIFS: background thread "ubifs_bgt0_0" started, PID 844

[ 2083.425364] UBIFS: mounted UBI device 0, volume 0, name "main"

[ 2083.431250] UBIFS: LEB size: 1032192 bytes (1008 KiB), min./max. I/O unit sizes: 8192 bytes/8192 bytes

[ 2083.440576] UBIFS: FS size: 4124639232 bytes (3933 MiB, 3996 LEBs), journal size 33030144 bytes (31 MiB, 32 LEBs)

[ 2083.450836] UBIFS: reserved for root: 4952683 bytes (4836 KiB)

[ 2083.456677] UBIFS: media format: w4/r0 (latest is w4/r0), UUID AFE05BAF-A7FE-4CA6-94D7-FE153AE8D0E0, small LPT model

root@cubie:~# df

.

ubi0:main 3798064 28 3793200 1% /mnt

root@cubie:~# touch file /mnt; ls -al /mnt

total 4

drwxr-xr-x 2 root root 224 dic 25 19:50 .

drwxr-xr-x 22 root root 4096 dic 1 13:58 ..

-rw-r--r-- 1 root root 0 dic 25 19:49 file

Michal Suchanek

unread,

Jan 1, 2015, 8:09:50 AM1/1/15

to linux-sunxi

On 17 December 2014 at 11:40, Boris BREZILLON <b.brezi...@gmail.com> wrote:

Regarding the mode - the chip is probably meant to run at something
like mode 4 according to the timings table in datasheet.

Unfortunately, some of the longer state transitions only conform to
mode 0. The sunxi driver claims to run chip at 30 MHz which would
probably fall somewhere in between mode 2 and mode 3.

Thanks

Michal

Michal Suchanek

unread,

Jan 1, 2015, 1:38:16 PM1/1/15

to linux-sunxi

On 19 December 2014 at 05:53, Yassin Jaffer <yassin...@gmail.com> wrote:
> Hi Michal
> This was answered previously by Brezillon . Please search the mailing list.
>>
>> You have to force bad block erasure to get rid of AW's libnand layout
>> (which is overriding bad block markers).
>>
>> Please follow these steps:
>> 1) apply this patch [1]
>> 2) boot on your new kernel and launch
>> $ flash_erase /dev/mtd0 0 0
>> 3) revert the patch
>> 4) Boot on your new kernel
>>
>> Most of your bad blocks should be gone after that...
>>
>> [1]http://code.bulix.org/k2v1hx-87237
>

Ok, so I tried to butcher the kernel code to avoid this problem with
bad block markers.

https://github.com/hramrach/linux-sunxi/commit/01ccbc12b5e9b2acc8a14d47fe52d73125a634d6

Without actually erasing the flash I get tons of kernel messages about
CRC errors but I can attach an ubi device, create a volume on it,
format it.

It does not mount, however. So it does not quite live to the promise
of being able to use a blank flash.

root@sunxi-a10:~# ubinfo
UBI version: 1
Count of UBI devices: 0
UBI control device major/minor: 10:59
root@sunxi-a10:~# ubiattach -p /dev/mtd2
UBI device number 0, total 4088 LEBs (4219600896 bytes, 3.9 GiB),
available 0 LEBs (0 bytes), LEB size 1032192 bytes (1008.0 KiB)
root@sunxi-a10:~# mount -t ubifs /dev/ubi0_0 /mnt/
mount: mount /dev/ubi0_0 on /mnt failed: Bad message
root@sunxi-a10:~# mkfs.ubifs /dev/ubi0_0
mkfs.ubifs: UBI volume is not empty. Format anyways? (y/N) y
root@sunxi-a10:~# mount -t ubifs /dev/ubi0_0 /mnt/
mount: mount /dev/ubi0_0 on /mnt failed: Bad message
root@sunxi-a10:~# mount -t ubifs ubi0:root /mnt/
mount: mount ubi0:root on /mnt failed: Bad message

Before digging too deep into ubi there is one obvious issue with the bbt.

It kind of does not preserve over reboot.

Any idea why that would happen?

Might the MTD partitions with different settings clash with bbt management?

Thanks

Michal