Hi,
try:
determinate first the "Minimum input/output unit size" for mtd2 device 
(mtdinfo -a)
example of output:
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

After format the mtd2 with -s parameter and  the value of "Minimum 
input/output unit size"
example:
ubiformat -s 8192 /dev/mtd2
Answer  "YES" at all questions proposed for the bad blocks.
After:
ubiattach /dev/ubi_ctrl -m 2 -O 8192
ubimkvol /dev/ubi0 -N main -m 
mount -t ubifs ubi0:main /mnt

good luck.
bye
PS.
my config of A10 cubieboard:
Linux cubie 3.19.0-rc1
patch:
 dts/dtsi from  3.18-nand (https://github.com/wens/linux)
nand_ids.c with the following definition:
        {"K9GBG08U0A 4GB 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 },

Il giorno giovedì 1 gennaio 2015 19:38:16 UTC+1, Michal Suchanek ha scritto:
>
> On 19 December 2014 at 05:53, Yassin Jaffer <[email protected] 
> <javascript:>> 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 
>
>
> Bad block table not found for chip 0 
> Bad block table not found for chip 0 
> Bad block table written to 0x0000fff00000, version 0x01 
> Bad block table written to 0x0000ffe00000, version 0x01 
> Bad block table not found for chip 0 
> Bad block table not found for chip 0 
> Bad block table written to 0x0000fff00000, version 0x01 
> Bad block table written to 0x0000ffe00000, version 0x01 
> Bad block table not found for chip 0 
> Bad block table not found for chip 0 
> Bad block table written to 0x0000fff00000, version 0x01 
> Bad block table written to 0x0000ffe00000, version 0x01 
> Bad block table written to 0x0000fff00000, version 0x02 
> Bad block table written to 0x0000ffe00000, version 0x02 
> Bad block table written to 0x0000fff00000, version 0x03 
> Bad block table written to 0x0000ffe00000, version 0x03 
> Bad block table written to 0x0000fff00000, version 0x04 
> Bad block table written to 0x0000ffe00000, version 0x04 
> Bad block table written to 0x0000fff00000, version 0x05 
> Bad block table written to 0x0000ffe00000, version 0x05 
> Bad block table written to 0x0000fff00000, version 0x06 
> Bad block table written to 0x0000ffe00000, version 0x06 
> Bad block table written to 0x0000fff00000, version 0x07 
> Bad block table written to 0x0000ffe00000, version 0x07 
> Bad block table not found for chip 0 
> Bad block table not found for chip 0 
> Bad block table written to 0x0000fff00000, version 0x01 
> Bad block table written to 0x0000ffe00000, version 0x01 
> Bad block table written to 0x0000fff00000, version 0x02 
> Bad block table written to 0x0000ffe00000, version 0x02 
> Bad block table written to 0x0000fff00000, version 0x03 
> Bad block table written to 0x0000ffe00000, version 0x03 
> Bad block table written to 0x0000fff00000, version 0x04 
> Bad block table written to 0x0000ffe00000, version 0x04 
> Bad block table written to 0x0000fff00000, version 0x05 
> Bad block table written to 0x0000ffe00000, version 0x05 
> Bad block table written to 0x0000fff00000, version 0x06 
> Bad block table written to 0x0000ffe00000, version 0x06 
> Bad block table written to 0x0000fff00000, version 0x07 
> Bad block table written to 0x0000ffe00000, version 0x07 
> Bad block table not found for chip 0 
> Bad block table not found for chip 0 
> Bad block table written to 0x0000fff00000, version 0x01 
> Bad block table written to 0x0000ffe00000, version 0x01 
>

-- 
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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to