Message-ID: <CAKR-sGegBo2M-+mHZknWBJhmgHtT21Lsd=W==5zU-raja6aJuA@mail.gmail.com>
Date:   Fri, 24 Mar 2023 18:04:38 +0100
From:   Álvaro Fernández Rojas <noltari@...il.com>
To:     Miquel Raynal <miquel.raynal@...tlin.com>
Cc:     richard@....at, vigneshr@...com, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, masonccyang@...c.com.tw,
        linux-mtd@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, Jaime Liao <jaimeliao@...c.com.tw>,
        YouChing <ycllin@...c.com.tw>
Subject: Re: [PATCH 1/2] dt-bindings: mtd: nand: Macronix: document new binding

Hi Miquèl,

2023-03-24 15:36 GMT+01:00, Miquel Raynal <miquel.raynal@...tlin.com>:
> Hi Álvaro,
>
> + YouChing and Jaime from Macronix
> TLDR for them: there is a misbehavior since Mason added block
> protection support. Just checking if the blocks are protected seems to
> misconfigure the chip entirely, see below. Any hints?

Could it be that the NAND is stuck expecting a read 0x00 command which
isn’t sent after getting the features?

>
> noltari@...il.com wrote on Fri, 24 Mar 2023 15:15:47 +0100:
>
>> Hi Miquèl,
>>
>> 2023-03-24 14:45 GMT+01:00, Miquel Raynal <miquel.raynal@...tlin.com>:
>> > Hi Álvaro,
>> >
>> > noltari@...il.com wrote on Fri, 24 Mar 2023 12:21:11 +0100:
>> >
>> >> El vie, 24 mar 2023 a las 11:49, Miquel Raynal
>> >> (<miquel.raynal@...tlin.com>) escribió:
>> >> >
>> >> > Hi Álvaro,
>> >> >
>> >> > noltari@...il.com wrote on Fri, 24 Mar 2023 11:31:17 +0100:
>> >> >
>> >> > > Hi Miquèl,
>> >> > >
>> >> > > El vie, 24 mar 2023 a las 10:40, Miquel Raynal
>> >> > > (<miquel.raynal@...tlin.com>) escribió:
>> >> > > >
>> >> > > > Hi Álvaro,
>> >> > > >
>> >> > > > noltari@...il.com wrote on Thu, 23 Mar 2023 13:45:09 +0100:
>> >> > > >
>> >> > > > > Add new "mxic,disable-block-protection" binding documentation.
>> >> > > > > This binding allows disabling block protection support for
>> >> > > > > those
>> >> > > > > devices not
>> >> > > > > supporting it.
>> >> > > > >
>> >> > > > > Signed-off-by: Álvaro Fernández Rojas <noltari@...il.com>
>> >> > > > > ---
>> >> > > > >  Documentation/devicetree/bindings/mtd/nand-macronix.txt | 3
>> >> > > > > +++
>> >> > > > >  1 file changed, 3 insertions(+)
>> >> > > > >
>> >> > > > > diff --git
>> >> > > > > a/Documentation/devicetree/bindings/mtd/nand-macronix.txt
>> >> > > > > b/Documentation/devicetree/bindings/mtd/nand-macronix.txt
>> >> > > > > index ffab28a2c4d1..03f65ca32cd3 100644
>> >> > > > > --- a/Documentation/devicetree/bindings/mtd/nand-macronix.txt
>> >> > > > > +++ b/Documentation/devicetree/bindings/mtd/nand-macronix.txt
>> >> > > > > @@ -16,6 +16,9 @@ in children nodes.
>> >> > > > >  Required NAND chip properties in children mode:
>> >> > > > >  - randomizer enable: should be "mxic,enable-randomizer-otp"
>> >> > > > >
>> >> > > > > +Optional NAND chip properties in children mode:
>> >> > > > > +- block protection disable: should be
>> >> > > > > "mxic,disable-block-protection"
>> >> > > > > +
>> >> > > >
>> >> > > > Besides the fact that nowadays we prefer to see binding
>> >> > > > conversions
>> >> > > > to
>> >> > > > yaml before adding anything, I don't think this will fly.
>> >> > > >
>> >> > > > I'm not sure exactly what "disable block protection" means, we
>> >> > > > already have similar properties like "lock" and
>> >> > > > "secure-regions",
>> >> > > > not
>> >> > > > sure they will fit but I think it's worth checking.
>> >> > >
>> >> > > As explained in 2/2, commit 03a539c7a118 introduced a regression
>> >> > > on
>> >> > > Sercomm H500-s (BCM63268) OpenWrt devices with Macronix
>> >> > > MX30LF1G18AC
>> >> > > which hangs the device.
>> >> > >
>> >> > > This is the log with block protection disabled:
>> >> > > [    0.495831] bcm6368_nand 10000200.nand: there is not valid maps
>> >> > > for
>> >> > > state default
>> >> > > [    0.504995] nand: device found, Manufacturer ID: 0xc2, Chip ID:
>> >> > > 0xf1
>> >> > > [    0.511526] nand: Macronix MX30LF1G18AC
>> >> > > [    0.515586] nand: 128 MiB, SLC, erase size: 128 KiB, page size:
>> >> > > 2048, OOB size: 64
>> >> > > [    0.523516] bcm6368_nand 10000200.nand: detected 128MiB total,
>> >> > > 128KiB blocks, 2KiB pages, 16B OOB, 8-bit, BCH-4
>> >> > > [    0.535912] Bad block table found at page 65472, version 0x01
>> >> > > [    0.544268] Bad block table found at page 65408, version 0x01
>> >> > > [    0.954329] 9 fixed-partitions partitions found on MTD device
>> >> > > brcmnand.0
>> >> > > ...
>> >> > >
>> >> > > This is the log with block protection enabled:
>> >> > > [    0.495095] bcm6368_nand 10000200.nand: there is not valid maps
>> >> > > for
>> >> > > state default
>> >> > > [    0.504249] nand: device found, Manufacturer ID: 0xc2, Chip ID:
>> >> > > 0xf1
>> >> > > [    0.510772] nand: Macronix MX30LF1G18AC
>> >> > > [    0.514874] nand: 128 MiB, SLC, erase size: 128 KiB, page size:
>> >> > > 2048, OOB size: 64
>> >> > > [    0.522780] bcm6368_nand 10000200.nand: detected 128MiB total,
>> >> > > 128KiB blocks, 2KiB pages, 16B OOB, 8-bit, BCH-4
>> >> > > [    0.539687] Bad block table not found for chip 0
>> >> > > [    0.550153] Bad block table not found for chip 0
>> >> > > [    0.555069] Scanning device for bad blocks
>> >> > > [    0.601213] CPU 1 Unable to handle kernel paging request at
>> >> > > virtual
>> >> > > address 10277f00, epc == 8039ce70, ra == 8016ad50
>> >> > > *** Device hangs ***
>> >> > >
>> >> > > Enabling macronix_nand_block_protection_support() makes the device
>> >> > > unable to detect the bad block table and hangs it when trying to
>> >> > > scan
>> >> > > for bad blocks.
>> >> >
>> >> > Please trace nand_macronix.c and look:
>> >> > - are the get_features and set_features really supported by the
>> >> >   controller driver?
>> >>
>> >> This is what I could find by debugging:
>> >> [    0.494993] bcm6368_nand 10000200.nand: there is not valid maps for
>> >> state default
>> >> [    0.505375] nand: device found, Manufacturer ID: 0xc2, Chip ID:
>> >> 0xf1
>> >> [    0.512077] nand: Macronix MX30LF1G18AC
>> >> [    0.515994] nand: 128 MiB, SLC, erase size: 128 KiB, page size:
>> >> 2048, OOB size: 64
>> >> [    0.523928] bcm6368_nand 10000200.nand: detected 128MiB total,
>> >> 128KiB blocks, 2KiB pages, 16B OOB, 8-bit, BCH-4
>> >> [    0.534415] bcm6368_nand 10000200.nand: ll_op cmd 0xa00ee
>> >> [    0.539988] bcm6368_nand 10000200.nand: ll_op cmd 0x600a0
>> >> [    0.545659] bcm6368_nand 10000200.nand: ll_op cmd 0x10000
>> >> [    0.551214] bcm6368_nand 10000200.nand: NAND_CMD_GET_FEATURES =
>> >> 0x00
>> >> [    0.557843] bcm6368_nand 10000200.nand: ll_op cmd 0x10000
>> >> [    0.563475] bcm6368_nand 10000200.nand: NAND_CMD_GET_FEATURES =
>> >> 0x00
>> >> [    0.569998] bcm6368_nand 10000200.nand: ll_op cmd 0x10000
>> >> [    0.575653] bcm6368_nand 10000200.nand: NAND_CMD_GET_FEATURES =
>> >> 0x00
>> >> [    0.582246] bcm6368_nand 10000200.nand: ll_op cmd 0x80010000
>> >> [    0.588067] bcm6368_nand 10000200.nand: NAND_CMD_GET_FEATURES =
>> >> 0x00
>> >> [    0.594657] nand: nand_get_features: addr=a0 subfeature_param=[00
>> >> 00 00 00] -> 0
>> >> [    0.602341] macronix_nand_block_protection_support:
>> >> ONFI_FEATURE_ADDR_MXIC_PROTECTION=0
>> >> [    0.610548] macronix_nand_block_protection_support: !=
>> >> MXIC_BLOCK_PROTECTION_ALL_LOCK
>> >> [    0.624760] Bad block table not found for chip 0
>> >> [    0.635542] Bad block table not found for chip 0
>> >> [    0.640270] Scanning device for bad blocks
>> >>
>> >> I don't know how to tell if get_features / set_features is really
>> >> supported...
>> >
>> > Looks like your driver does not support exec_op but the core provides a
>> > get/set_feature implementation.
>>
>> According to Florian, low level should be supported on brcmnand
>> controllers >= 4.0
>> Also:
>> https://github.com/nomis/bcm963xx_4.12L.06B_consumer/blob/e2f23ddbb20bf75689372b6e6a5a0dc613f6e313/shared/opensource/include/bcm963xx/63268_map_part.h#L1597
>
> Just to be sure, you're using a mainline controller driver, not this
> one?

Yes, this was just to prove that the HW I’m using has get/set features support.
I’m using OpenWrt, so it’s linux v5.15 driver.

>
>> >
>> >>
>> >> > - what is the state of the locking configuration in the chip when
>> >> > you
>> >> >   boot?
>> >>
>> >> Unlocked, I guess...
>> >> How can I check that?
>> >
>> > It's in your dump, the chip returns 0, meaning it's all unlocked,
>> > apparently.
>>
>> Well, I can read/write the device if block protection isn’t disabled,
>> so I guess we can confirm it’s unlocked…
>>
>> >
>> >> > - is there anything that locks the device by calling mxic_nand_lock()
>> >> > ?
>> >
>> > So nobody locks the device I guess? Did you add traces there?
>>
>> It doesn’t get to the point that it enabled the lock/unlock functions
>> since it fails when checking if feature is 0x38, so there’s no point
>> in adding those traces…
>
> Right, it returns before setting these I guess.
>
>>
>> >
>> >> > - finding no bbt is one thing, hanging is another, where is it
>> >> > hanging
>> >> >   exactly? (offset in nand/ and line in the code)
>> >>
>> >> I've got no idea...
>> >
>> > You can use ftrace or just add printks a bit everywhere and try to get
>> > closer and closer.
>>
>> I think that after trying to get the feature it just start reading
>> nonsense from the NAND and at some point it hangs due to that garbage…
>
> It should refuse to mount the device somehow, but in no case the kernel
> should hang.

Yes, I think that this is a side effect (maybe a different bug somewhere else).

>
>> Is it posible that the NAND starts behaving like this after getting
>> the feature due to some specific config of my device?
>>
>> >
>> > I looked at the patch, I don't see anything strange. Besides, I have a
>> > close enough datasheet and I don't see what could confuse the device.
>> >
>> > Are you really sure this patch is the problem? Is the WP pin wired on
>> > your design?
>>
>> There’s no WP pin in brcmnand controllers < 7.0
>
> What about the chip?

Maybe it has a GPIO controlling that, but I don’t have that info…

>
> Thanks,
> Miquèl
>

Powered by blists - more mailing lists