Flash filesystem questions

[Erik Ekman]

On Thu, Jan 15, 2015 at 6:49 PM, Erik Ekman <erik at kryo.se> wrote:
>
> My code only read up to 4kB in one read command. It seems the kernel
> part attaching ubi
> did not like not getting all data in one operation. After fixing long
> reads I no longer get any
> asserts in the log. ubiattach does still not work though, but now I
> get a more normal CRC error:
>
> [  834.723114] UBI: attaching mtd0 to ubi0
> [  841.609879] UBI: scanning is finished
> [  841.612442] UBI error: vtbl_check: bad CRC at record 23:
> 0xf116c36b, not 0x000000
> [  841.612450] Volume table record 23 dump:
> [  841.612453] reserved_pebs   0
> [  841.612456] alignment       0
> [  841.612459] data_pad        0
> [  841.612462] vol_type        0
> [  841.612465] upd_marker      0
> [  841.612468] name_len        0
> [  841.612470] name            NULL
> [  841.612501] UBI error: vtbl_check: bad CRC at record 23:
> 0xf116c36b, not 0x000000
> [  841.612504] Volume table record 23 dump:
> [  841.612507] reserved_pebs   0
> [  841.612510] alignment       0
> [  841.612513] data_pad        0
> [  841.612515] vol_type        0
> [  841.612518] upd_marker      0
> [  841.612521] name_len        0
> [  841.612523] name            NULL
> [  841.612527] UBI error: process_lvol: both volume tables are corrupted
> [  841.615924] UBI error: ubi_attach_mtd_dev: failed to attach mtd0, error -22
>
> I will try with the tests and investigate more.

Ok, when reading long data actually works then attaching ubi is fine..

Next problem is bad blocks. I have not found anything in the hardware that
keeps track of them. I am thinking about using the first two working blocks as
maps, one u8 per erase block. Since I only have 8k, 16k or 32k erase blocks it
should not wear them out too much during updates.

Is this a valid strategy or is there a common smart solution?

Thanks,

Erik