1

I'm struggling with writing the Linux root file system to a NAND device (MT29F2G08ABAEAH4-IT:E).

I have a UBI image created by Yocto as follows:

mkfs.ubifs -r /path/to/rootfs -o /path/to/output/rootfs.ubifs -m 2048 -e 129024 -c 1600 -F
ubinize -o /path/to/output/rootfs.ubi -m 2048 -p 128KiB -s 512 ubinize.cfg

ubinize.cfg:

[ubifs]
mode=ubi
image=/path/to/output/rootfs.ubifs
vol_id=0
vol_type=dynamic
vol_name=ddcu-rootfs
vol_flags=autoresize

I'm able to successfully write the filesystem with the following commands from a "manufacturing" Linux:

mount /dev/mmcblk0p3 /mnt/data/
ubiformat /dev/mtd8 -f /mnt/data/rootfs.ubi
ubiattach /dev/ubi_ctrl -m 8
mount -t ubifs ubi0_0 /mnt/rfs

This solution works but is tedious, as I first need to boot the temporary "manufacturing" Linux to prepare RFS for the production Linux. So I want to flash it directly from u-boot. I've read multiple sources (e.g. http://www.linux-mtd.infradead.org/faq/ubifs.html) and notes (e.g. http://lists.denx.de/pipermail/u-boot/2011-September/102740.html), yet I must still do something wrong or there must be a bug somewhere.

1. nand write

I tried to use the nand write command in u-boot 2011.12 and 2016.01:

nand scrub.part -y mtd_rootfs
fatload mmc 0:3 ${loadaddr} rootfs.ubi
nand write ${loadaddr} mtd_rootfs ${filesize}

Booting Linux now leads to

UBI: attaching mtd8 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    129024 bytes
UBI: smallest flash I/O unit:    2048
UBI: sub-page size:              512
UBI: VID header offset:          512 (aligned 512)
UBI: data offset:                2048
uncorrectable error : 
uncorrectable error : 
uncorrectable error : 
uncorrectable error : 
UBI error: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read 64 bytes
uncorrectable error : 
uncorrectable error : 
uncorrectable error : 
uncorrectable error : 
uncorrectable error : 
uncorrectable error : 
uncorrectable error : 
uncorrectable error : 
UBI error: ubi_io_read: error -74 (ECC error) while reading 512 bytes from PEB 0:512, read 512 bytes
uncorrectable error : 
uncorrectable error :

2. ubi

Another attend was using the ubi u-boot 2016.01 commands:

nand scrub.part -y mtd_rootfs
ext4load mmc 0:2 ${loadaddr} rootfs.ubi
ubi part mtd_rootfs
ubi create ddcu-rootfs
ubi write ${loadaddr} my-rootfs ${filesize}

Trying to mount the volume in u-boot by ubifsmount my-rootfs fails:

Error reading superblock on volume 'my-rootfs' errno=-22!

Trying to boot Linux leads to:

UBI: attaching mtd8 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    129024 bytes
UBI: smallest flash I/O unit:    2048
UBI: sub-page size:              512
UBI: VID header offset:          512 (aligned 512)
UBI: data offset:                2048
uncorrectable error : 
uncorrectable error : 
uncorrectable error : 
uncorrectable error : 
UBI error: ubi_io_read: error -74 (ECC error) while reading 64 bytes from PEB 0:0, read 64 bytes
UBI error: validate_ec_hdr: bad VID header offset 2048, expected 512
UBI error: validate_ec_hdr: bad EC header
UBI error: ubi_io_read_ec_hdr: validation failed for PEB 0
UBI error: ubi_init: cannot attach mtd8

Of course I tried more variants, but it always ends up with the error -74. Can anyone see what I'm doing wrong, or share their working solution, please?

sawdust
  • 16,103
  • 3
  • 40
  • 50
yman
  • 349
  • 4
  • 18

1 Answers1

0

Can anyone ... share their working solution, please?

(1) Rebuild U-Boot with CONFIG_CMD_NAND_TRIMFFS enabled. Use version 2016.01, since v2011.12 might not have this command option.

(2) Do not use the nand scrub ... command.
That command will remove the bad-block information provided by the factory. (You may have created future problems by destroying this bad-block information.)
Use the plain nand erase ... command.

(3) Use the nand write.trimffs ... command to install the UBI image.

The above procedure assumes that U-Boot and the Linux kernel are configured to access the NAND flash using the same parameters and ECC method.

sawdust
  • 16,103
  • 3
  • 40
  • 50
  • I used `nand scrub` to remove the bad block introduced by the successfull UBI image installation by the `ubiformat` tool. It's a good point that the `write.trimffs` should be used. Unfortunatelly, the result remains the same. – yman May 25 '16 at 13:40
  • 2
    Have you verified that your U-Boot and Linux kernel are using the exact same NAND parameters, especially for ECC? Are you using software ECC, or is there hardware? Have you tried using U-Boot (i.e `ubifsload...`) to access a file that's in a UBIFS (installed by the Linux method) (that's a sanity check that reverses your problem)? – sawdust May 26 '16 at 05:53
  • Kernel was configured with SWECC, while u-boot with HWECC. The u-boot driver does not seem to support SWECC, so I configured kernel for HWECC. That doesn't work though, I'm not able to write the FS even in Linux - `ubiattach` following `ubiformat` ends up with error 22. Which is the same error as if trying to mount the FS from u-boot with `ubifsmount` command. I deduce I would need SWECC in u-boot, which in case of my driver looks like dead end :-( Is my deduction correct? Or any other suggestions? – yman May 26 '16 at 09:05
  • What SoC is this? *"I configured kernel for HWECC. That doesn't work though,"* -- You give up too quickly. Reduce the problem to its basic components. Use U-Boot to write a text file in NAND blocks (for source data). Then use your hacked *"temporary "manufacturing" Linux"* to read those NAND blocks. IOW get NAND with HWECC working *without* UBI volumes and UBIFS in the picture. – sawdust May 26 '16 at 19:33
  • It's an NXP (Freescale) Vybrid VF6. I know there are options for further investigation (and thank you for your will to support me on this way), but yesterday I hit on multiple threads confirming that the driver is not completely okay (https://community.nxp.com/thread/317074, https://community.nxp.com/message/436215#comment-436215), so I'm not convinced I would find a _reliable_ solution in reasonable time. It's not a big project, and the configuration (new u-boot and old kernel) is also non-standard, so I'll better stick with the "manufacturing" Linux. – yman May 27 '16 at 07:49