Messages in this thread | | | Date | Tue, 16 May 2023 11:58:47 -0700 | Subject | Re: [PATCH 1/2] dt-bindings: mtd: nand: Macronix: document new binding | From | Florian Fainelli <> |
| |
+William,
On 5/16/23 11:55, Álvaro Fernández Rojas wrote: > Hi Jaime, > > I've reproduced the issue on a Comtrend VR-3032u (MX30LF1G08AA). After > forcing it to check block protection (it's not supported on that > device), the NAND controller stops reading/writing anything. > > @Florian is it possible that low level ops (GET_FEATURES/SET_FEATURES) > aren't supported on BCM63268 NAND controllers and this is causing the > issue?
Yes, this looks like what we have seen as well even with newer NAND controllers actually. Would it be possible to obtain a full log from either of you?
William, is this something you have seen before as well?
> > Best regards, > Álvaro. > > El mié, 26 abr 2023 a las 9:24, liao jaime (<jaimeliao.tw@gmail.com>) escribió: >> >> Hi Álvaro >> >> In nand_scan_tail(), each manufacturer init function call will be execute. >> In macronix_nand_init(), block protect will be execute after flash detect. >> I have validate MX30LF1G18AC in Linux kernel v5.15. >> I didn't got situation "device hangs" on my side. >> BP is to prevent incorrect operations. >> Please check the controller settings for tracing this issue. >> >> Thanks >> Jaime >> >>> >>> Hello YouChing and Jaime, >>> >>> I still didn't get any feedback from you (or Macronix) on this issue. >>> Did you have time to look into it? >>> >>> Thanks, >>> Álvaro. >>> >>> El vie, 24 mar 2023 a las 18:04, Álvaro Fernández Rojas >>> (<noltari@gmail.com>) escribió: >>>> >>>> Hi Miquèl, >>>> >>>> 2023-03-24 15:36 GMT+01:00, Miquel Raynal <miquel.raynal@bootlin.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@gmail.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@bootlin.com>: >>>>>>> Hi Álvaro, >>>>>>> >>>>>>> noltari@gmail.com wrote on Fri, 24 Mar 2023 12:21:11 +0100: >>>>>>> >>>>>>>> El vie, 24 mar 2023 a las 11:49, Miquel Raynal >>>>>>>> (<miquel.raynal@bootlin.com>) escribió: >>>>>>>>> >>>>>>>>> Hi Álvaro, >>>>>>>>> >>>>>>>>> noltari@gmail.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@bootlin.com>) escribió: >>>>>>>>>>> >>>>>>>>>>> Hi Álvaro, >>>>>>>>>>> >>>>>>>>>>> noltari@gmail.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@gmail.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 >>>>>
-- Florian
| |