> -----Original Message----- > From: Heiko Schocher <hs@xxxxxxx> > Sent: Monday, June 24, 2019 3:41 AM > To: Ken Sloat <KSloat@xxxxxxxxxxxxxx> > Cc: oss@xxxxxxxxxxxx; tudor.ambarus@xxxxxxxxxxxxx; > kmpark@xxxxxxxxxxxxx; hs@xxxxxxx; u-boot@xxxxxxxxxxxxx; linux- > mtd@xxxxxxxxxxxxxxxxxxx > 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@xxxxxxx Thanks for the info Heiko, I will see what I can find Thanks, Ken Sloat ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/