[U-Boot] UBI: volume auto-resize
Hi,
I found an interesting situation where I can not decide whether it is a bug or functionality that should not be included at all.
If I generate UBI image consisting of 3 Volumes to NAND flash on my board, U-boot does not attach UBI to MTD. This happens only if UBI contains a volume that has auto-resize flag set. U-boot tries to resize it but fails.
Just started fixing it, but I have a question. Is it desirable that U-boot changes something in the FS? Would it not be better if U-boot would just read things out (that is all I want, to get uImage and dtb file) and leave the rest to Linux. (Linux handles the procedure without any issues).
Any opinion welcome.
Creating 1 MTD partitions on "nand0": 0x000000200000-0x000008000000 : "mtd=2" Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01 nand_read_bbt: Bad block at 0x0000011a0000 UBI: attaching mtd1 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 UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 1003:512, written 0 bytes UBI warning: ubi_eba_write_leb: failed to write VID header to LEB 2147479551:0, PEB 1003 UBI: try another PEB UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 1003:512, written 0 bytes UBI warning: ubi_eba_write_leb: failed to write VID header to LEB 2147479551:0, PEB 1003 UBI: try another PEB UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 1003:512, written 0 bytes UBI warning: ubi_eba_write_leb: failed to write VID header to LEB 2147479551:0, PEB 1003 UBI: try another PEB UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 1003:512, written 0 bytes UBI warning: ubi_eba_write_leb: failed to write VID header to LEB 2147479551:0, PEB 1003 UBI warning: ubi_ro_mode: switch to read-only mode UBI error: autoresize: cannot auto-resize volume 2 UBI error: ubi_init: cannot attach mtd1 UBI error: ubi_init: UBI error: cannot initialize UBI, error -30 UBI init error 30
Best regards, Matevz Langus
Dear Matevz Langus,
Hi,
I found an interesting situation where I can not decide whether it is a bug or functionality that should not be included at all.
If I generate UBI image consisting of 3 Volumes to NAND flash on my board, U-boot does not attach UBI to MTD. This happens only if UBI contains a volume that has auto-resize flag set. U-boot tries to resize it but fails.
Just started fixing it, but I have a question. Is it desirable that U-boot changes something in the FS? Would it not be better if U-boot would just read things out (that is all I want, to get uImage and dtb file) and leave the rest to Linux. (Linux handles the procedure without any issues).
Any opinion welcome.
Creating 1 MTD partitions on "nand0": 0x000000200000-0x000008000000 : "mtd=2" Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01 nand_read_bbt: Bad block at 0x0000011a0000 UBI: attaching mtd1 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
Is the subpage size here correct? I know at least about one driver that might misreport it under certain conditions.
Best regards, Marek Vasut
Hi,
Thanks, initial problem about the subpage size was solved fast. The question still remains, is it wise to let u-boot resize volumes if it only boots from one of the volumes.
Matevz Langus
On 13. maj 2012, at 19:09, Marek Vasut marek.vasut@gmail.com wrote:
Dear Matevz Langus,
Hi,
I found an interesting situation where I can not decide whether it is a bug or functionality that should not be included at all.
If I generate UBI image consisting of 3 Volumes to NAND flash on my board, U-boot does not attach UBI to MTD. This happens only if UBI contains a volume that has auto-resize flag set. U-boot tries to resize it but fails.
Just started fixing it, but I have a question. Is it desirable that U-boot changes something in the FS? Would it not be better if U-boot would just read things out (that is all I want, to get uImage and dtb file) and leave the rest to Linux. (Linux handles the procedure without any issues).
Any opinion welcome.
Creating 1 MTD partitions on "nand0": 0x000000200000-0x000008000000 : "mtd=2" Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01 nand_read_bbt: Bad block at 0x0000011a0000 UBI: attaching mtd1 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
Is the subpage size here correct? I know at least about one driver that might misreport it under certain conditions.
Best regards, Marek Vasut
Dear Matevz Langus,
Hi,
Thanks, initial problem about the subpage size was solved fast.
How, so you can only use 2048b big subpage?
The question still remains, is it wise to let u-boot resize volumes if it only boots from one of the volumes.
Sure, why not?
btw please avoid top-posting when replying to emails.
Matevz Langus
On 13. maj 2012, at 19:09, Marek Vasut marek.vasut@gmail.com wrote:
Dear Matevz Langus,
Hi,
I found an interesting situation where I can not decide whether it is a bug or functionality that should not be included at all.
If I generate UBI image consisting of 3 Volumes to NAND flash on my board, U-boot does not attach UBI to MTD. This happens only if UBI contains a volume that has auto-resize flag set. U-boot tries to resize it but fails.
Just started fixing it, but I have a question. Is it desirable that U-boot changes something in the FS? Would it not be better if U-boot would just read things out (that is all I want, to get uImage and dtb file) and leave the rest to Linux. (Linux handles the procedure without any issues).
Any opinion welcome.
Creating 1 MTD partitions on "nand0": 0x000000200000-0x000008000000 : "mtd=2" Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01 nand_read_bbt: Bad block at 0x0000011a0000 UBI: attaching mtd1 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
Is the subpage size here correct? I know at least about one driver that might misreport it under certain conditions.
Best regards, Marek Vasut
Best regards, Marek Vasut
Hi,
sorry for top-posting.
It is Freescale eLB NAND controller. We need to investigate a bit more why it does not work with 512B sub-pages in u-boot. It does in Linux.
In my case, I do not want to update boot-loader in the future. If any bugs in UBI are found, we can cope with this in Linux. As long as boot-loader only reads, it can not do any damage. Resizing is not read only operation.
regards, Matevz Langus
Dear Matevz Langus,
Hi,
sorry for top-posting.
It is Freescale eLB NAND controller. We need to investigate a bit more why it does not work with 512B sub-pages in u-boot. It does in Linux.
And are you sure it does use 512b subpages in linux? Because I think there's still a bug in linux that forces these controllers (at least the GPMI NAND) to use 2048b subpages.
In my case, I do not want to update boot-loader in the future. If any bugs in UBI are found, we can cope with this in Linux. As long as boot-loader only reads, it can not do any damage. Resizing is not read only operation.
Oh ok.
regards, Matevz Langus
Best regards, Marek Vasut
On 05/15/2012 11:33 AM, Marek Vasut wrote:
Dear Matevz Langus,
Hi,
sorry for top-posting.
It is Freescale eLB NAND controller. We need to investigate a bit more why it does not work with 512B sub-pages in u-boot. It does in Linux.
And are you sure it does use 512b subpages in linux? Because I think there's still a bug in linux that forces these controllers (at least the GPMI NAND) to use 2048b subpages.
eLBC hardware does not support doing ECC on subpage accesses (and thus the driver does not support subpage accesses at all). How does UBI use subpage accesses?
-Scott
Hi Scott,
yes, I have also seen that. That makes me think using 2k alignment for all UBI structure is the safest/only way to go with eLBC NAND. But really confused I was, when I saw it working in Linux. Maybe Linux driver does not use HW ECC. Will report the findings when I finish other things.
regards, Matevz
participants (4)
-
Marek Vasut -
Marek Vasut -
Matevz Langus -
Scott Wood