[U-Boot] [nand] [ubi] Discrepancy Between U-Boot and Linux NAND PEBs
Hello All,
I have been working on a system using a NAND flash along with U-Boot 2018.07 and Linux Kernel 4.14. This is an Atmel based system FYI so it uses the Atmel NAND driver. I create a UBI image with 3 separate volumes - 2 of these are a specified fixed size and the third is specified as the minimum needed to hold the current files with the auto resize flag set. As a note, before the first run auto resize operation, there is over 200 MiB of unused space in the NAND - meaning there should be plenty of free space available for UBI to leave overhead when auto-resizing for bad block handling. Another point of note, is that I use UBI within U-Boot as well in order to read the kernel image and dtb out of the UBIFS.
I have noticed warnings in Linux when attaching UBI regarding not having enough reserved PEBs for bad block handling (it's short by 2). Upon further investigation into the issue, it appears as though there is a discrepancy between what U-Boot and Linux see in terms of the number of bad blocks:
U-Boot: ubi0: good PEBs: 4093, bad PEBs: 3, corrupted PEBs: 0 ubi0: user volume: 3, internal volumes: 1, max. volumes count: 128
Linux: ubi0 warning: ubi_eba_init: cannot reserve enough PEBs for bad PEB handling, reserved 71, need 73 ...... ubi0: good PEBs: 4089, bad PEBs: 7, corrupted PEBs: 0 ubi0: user volume: 3, internal volumes: 1, max. volumes count: 128
After production flashing of a UBI image to NAND (with a "dumb" non UBI aware flasher), U-Boot will be the program to mount UBI. What this means is that it will complete the one time re-size operation. I used a Linux ramdisk image to flash from Linux and mount UBI in Linux for the first time to allow it to complete the auto-resize operation instead and compared:
U-Boot: ubi0: attaching mtd1 ubi0: scanning is finished ubi0: volume 1 ("rootfs") re-sized from 1501 to 3385 LEBs ubi0: attached mtd1 (name "mtd=0", size 512 MiB) ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048 ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096 ubi0: good PEBs: 4093, bad PEBs: 3, corrupted PEBs: 0
Linux: ubi0: attaching mtd6 ubi0: scanning is finished ubi0: volume 1 ("rootfs") re-sized from 1501 to 3383 LEBs ubi0: attached mtd6 (name "atmel_nand", size 512 MiB) ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048 ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096 ubi0: good PEBs: 4089, bad PEBs: 7, corrupted PEBs: 0
As you can see, U-Boot resizes the image to 3385 blocks while Linux only 3383 - hence the 2 blocks that Linux would complain about had U-Boot resized the volume.
I am not sure exactly what is causing this discrepancy as I just figured this out - but thought I would reach out and discuss it here. Obviously there are ways around this issue (program and mount UBI from Linux initially, don't use autoresize and specify all volume sizes, etc) but was wondering if there is some underlying problem. I noticed an older mailing discussion from several years ago where someone reported a similar issue regarding number of bad PEBs and seems the issue was chalked up to a potential driver problem on one side: https://lists.denx.de/pipermail/u-boot/2015-June/216482.html
Any insight would be helpful.
Thanks, Ken Sloat
Hello Ken,
Am 20.06.2019 um 14:55 schrieb Ken Sloat:
Hello All,
I have been working on a system using a NAND flash along with U-Boot 2018.07 and Linux Kernel 4.14. This is an Atmel based system FYI so it uses the Atmel NAND driver. I create a UBI image with 3 separate volumes - 2 of these are a specified fixed size and the third is specified as the minimum needed to hold the current files with the auto resize flag set. As a note, before the first run auto resize operation, there is over 200 MiB of unused space in the NAND - meaning there should be plenty of free space available for UBI to leave overhead when auto-resizing for bad block handling. Another point of note, is that I use UBI within U-Boot as well in order to read the kernel image and dtb out of the UBIFS.
I have noticed warnings in Linux when attaching UBI regarding not having enough reserved PEBs for bad block handling (it's short by 2). Upon further investigation into the issue, it appears as though there is a discrepancy between what U-Boot and Linux see in terms of the number of bad blocks:
U-Boot: ubi0: good PEBs: 4093, bad PEBs: 3, corrupted PEBs: 0 ubi0: user volume: 3, internal volumes: 1, max. volumes count: 128
Linux: ubi0 warning: ubi_eba_init: cannot reserve enough PEBs for bad PEB handling, reserved 71, need 73 ...... ubi0: good PEBs: 4089, bad PEBs: 7, corrupted PEBs: 0 ubi0: user volume: 3, internal volumes: 1, max. volumes count: 128
After production flashing of a UBI image to NAND (with a "dumb" non UBI aware flasher), U-Boot will be the program to mount UBI. What this means is that it will complete the one time re-size operation. I used a Linux ramdisk image to flash from Linux and mount UBI in Linux for the first time to allow it to complete the auto-resize operation instead and compared:
U-Boot: ubi0: attaching mtd1 ubi0: scanning is finished ubi0: volume 1 ("rootfs") re-sized from 1501 to 3385 LEBs ubi0: attached mtd1 (name "mtd=0", size 512 MiB) ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048 ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096 ubi0: good PEBs: 4093, bad PEBs: 3, corrupted PEBs: 0
Linux: ubi0: attaching mtd6 ubi0: scanning is finished ubi0: volume 1 ("rootfs") re-sized from 1501 to 3383 LEBs ubi0: attached mtd6 (name "atmel_nand", size 512 MiB) ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048 ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096 ubi0: good PEBs: 4089, bad PEBs: 7, corrupted PEBs: 0
As you can see, U-Boot resizes the image to 3385 blocks while Linux only 3383 - hence the 2 blocks that Linux would complain about had U-Boot resized the volume.
I am not sure exactly what is causing this discrepancy as I just figured this out - but thought I would reach out and discuss it here. Obviously there are ways around this issue (program and mount UBI from Linux initially, don't use autoresize and specify all volume sizes, etc) but was wondering if there is some underlying problem. I noticed an older mailing discussion from several years ago where someone reported a similar issue regarding number of bad PEBs and seems the issue was chalked up to a potential driver problem on one side: https://lists.denx.de/pipermail/u-boot/2015-June/216482.html
Any insight would be helpful.
We use in U-Boot the code from linux 4.2 (commit 64291f7db5bd8150a74ad2036f1037e6a0428df2) (Yes, very old in the meantime)
So may there is a problem with this old code base in U-Boot?
Volunteers for rebasing the U-Boot ubi/ubifs code with a newer linux version are welcome.
But reading your Email again, may you should first investigate, why U-Boot and Linux see different good PEBs.
Also your kernel drops the warning:
ubi0 warning: ubi_eba_init: cannot reserve enough PEBs for bad PEB handling, reserved 71, need 73
You should look here deeper into it.
bye, Heiko
-----Original Message----- From: Heiko Schocher hs@denx.de Sent: Monday, June 24, 2019 3:41 AM To: Ken Sloat KSloat@aampglobal.com Cc: oss@buserror.net; tudor.ambarus@microchip.com; kmpark@infradead.org; hs@denx.de; u-boot@lists.denx.de; linux- mtd@lists.infradead.org Subject: Re: [U-Boot] [nand] [ubi] Discrepancy Between U-Boot and Linux NAND PEBs
[This is an EXTERNAL EMAIL] ________________________________
Hello Ken,
Am 20.06.2019 um 14:55 schrieb Ken Sloat:
Hello All,
I have been working on a system using a NAND flash along with U-Boot
2018.07 and Linux Kernel 4.14. This is an Atmel based system FYI so it uses the Atmel NAND driver. I create a UBI image with 3 separate volumes - 2 of these are a specified fixed size and the third is specified as the minimum needed to hold the current files with the auto resize flag set. As a note, before the first run auto resize operation, there is over 200 MiB of unused space in the NAND - meaning there should be plenty of free space available for UBI to leave overhead when auto-resizing for bad block handling. Another point of note, is that I use UBI within U-Boot as well in order to read the kernel image and dtb out of the UBIFS.
I have noticed warnings in Linux when attaching UBI regarding not having
enough reserved PEBs for bad block handling (it's short by 2). Upon further investigation into the issue, it appears as though there is a discrepancy between what U-Boot and Linux see in terms of the number of bad blocks:
U-Boot: ubi0: good PEBs: 4093, bad PEBs: 3, corrupted PEBs: 0 ubi0: user volume: 3, internal volumes: 1, max. volumes count: 128
Linux: ubi0 warning: ubi_eba_init: cannot reserve enough PEBs for bad PEB
handling, reserved 71, need 73
...... ubi0: good PEBs: 4089, bad PEBs: 7, corrupted PEBs: 0 ubi0: user volume: 3, internal volumes: 1, max. volumes count: 128
After production flashing of a UBI image to NAND (with a "dumb" non UBI
aware flasher), U-Boot will be the program to mount UBI. What this means is that it will complete the one time re-size operation. I used a Linux ramdisk image to flash from Linux and mount UBI in Linux for the first time to allow it to complete the auto-resize operation instead and compared:
U-Boot: ubi0: attaching mtd1 ubi0: scanning is finished ubi0: volume 1 ("rootfs") re-sized from 1501 to 3385 LEBs ubi0: attached mtd1 (name "mtd=0", size 512 MiB) ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048 ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096 ubi0: good PEBs: 4093, bad PEBs: 3, corrupted PEBs: 0
Linux: ubi0: attaching mtd6 ubi0: scanning is finished ubi0: volume 1 ("rootfs") re-sized from 1501 to 3383 LEBs ubi0: attached mtd6 (name "atmel_nand", size 512 MiB) ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048 ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096 ubi0: good PEBs: 4089, bad PEBs: 7, corrupted PEBs: 0
As you can see, U-Boot resizes the image to 3385 blocks while Linux only
3383 - hence the 2 blocks that Linux would complain about had U-Boot resized the volume.
I am not sure exactly what is causing this discrepancy as I just figured this
out - but thought I would reach out and discuss it here. Obviously there are ways around this issue (program and mount UBI from Linux initially, don't use autoresize and specify all volume sizes, etc) but was wondering if there is some underlying problem. I noticed an older mailing discussion from several years ago where someone reported a similar issue regarding number of bad PEBs and seems the issue was chalked up to a potential driver problem on one side:
https://lists.denx.de/pipermail/u-boot/2015-June/216482.html
Any insight would be helpful.
We use in U-Boot the code from linux 4.2 (commit 64291f7db5bd8150a74ad2036f1037e6a0428df2) (Yes, very old in the meantime)
So may there is a problem with this old code base in U-Boot?
Volunteers for rebasing the U-Boot ubi/ubifs code with a newer linux version are welcome.
But reading your Email again, may you should first investigate, why U-Boot and Linux see different good PEBs.
Also your kernel drops the warning:
ubi0 warning: ubi_eba_init: cannot reserve enough PEBs for bad PEB handling, reserved 71, need 73
You should look here deeper into it.
bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: hs@denx.de
Thanks for the info Heiko,
I will see what I can find
Thanks, Ken Sloat
participants (2)
-
Heiko Schocher -
Ken Sloat