[PATCH] ARM: dts: imx6ull: fix ubi mount failed on MYS-6ULX-IOT board
Sascha Hauer
s.hauer at pengutronix.de
Wed Mar 17 14:10:52 GMT 2021
On Wed, Mar 10, 2021 at 10:54:05AM +0800, dillon min wrote:
> Hi Sascha,
>
> Thanks for reviewing.
>
> On Tue, Mar 9, 2021 at 8:18 PM Sascha Hauer <s.hauer at pengutronix.de> wrote:
> >
> > On Tue, Mar 09, 2021 at 02:15:19PM +0800, dillon.minfei at gmail.com wrote:
> > > From: dillon min <dillon.minfei at gmail.com>
> > >
> > > This patch intend to fix ubi filesystem mount failed on MYS-6ULX-IOT board,
> > > from Micron MT29F2G08ABAEAWP's datasheets, we need to choose 4-bit ECC.
> > >
> > > Table 18: Error Management Details
> > >
> > > Description Requirement
> > >
> > > Minimum number of valid blocks (NVB) per LUN 2008
> > > Total available blocks per LUN 2048
> > > First spare area location x8: byte 2048 x16: word 1024
> > > Bad-block mark x8: 00h x16: 0000h
> > > Minimum required ECC 4-bit ECC per 528 bytes
> > > Minimum ECC with internal ECC enabled 4-bit ECC per 516 bytes (user data) + 8
> > > bytes (parity data)
> > > Minimum required ECC for block 0 if PROGRAM/
> > > ERASE cycles are less than 1000 1-bit ECC per 528 bytes
> >
> > 4-bit ECC is the minimum this chip requires. There's nothing wrong with
> > choosing a better ECC like the GPMI driver does by default.
> >
> Yes, indeed, the mt29f2g08's minimum ecc is 4-bit, you can use 8-bits ecc.
> but there is a dependency between new kernel gpmi-nand with the old
> mfg-kernel's , which means
> if the old nand ecc layout is 4-bits, you should use ecc 4-bit in the
> new kernel (by fsl,use-minimum-ecc),
> else use 8-bits.
>
> For my case, the ubifs filesystem was created by ecc 4-bits, without
> reflash filesystem or change
Then this is the justification for this patch, not anything from the
datasheet like you've written in your commit message.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
More information about the linux-arm-kernel
mailing list