[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKR-sGer0r0FxyOQQu7TxT0d2D981_1fQWxa_XghfyWKWSJVfQ@mail.gmail.com>
Date: Tue, 16 May 2023 21:02:13 +0200
From: Álvaro Fernández Rojas <noltari@...il.com>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: liao jaime <jaimeliao.tw@...il.com>,
"William (Zhenghao) Zhang" <william.zhang@...adcom.com>,
Miquel Raynal <miquel.raynal@...tlin.com>,
Richard Weinberger <richard@....at>,
Vignesh Raghavendra <vigneshr@...com>, robh+dt@...nel.org,
krzysztof.kozlowski+dt@...aro.org, linux-mtd@...ts.infradead.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: mtd: nand: Macronix: document new binding
Sure,
Here you go:
[ 0.000000] Linux version 5.15.111 (noltari@...antis)
(mips-openwrt-linux-musl-gcc (OpenWrt GCC 12.3.0 r0+22899-466be0612a)
12.3.0, GNU ld (GNU Binutils) 2.40.0) #0 SMP Tue May 16 14:33:20 2023
[ 0.000000] CPU0 revision is: 0002a080 (Broadcom BMIPS4350)
[ 0.000000] MIPS: machine is Sercomm H500-s vfes
[ 0.000000] 128MB of RAM installed
[ 0.000000] earlycon: bcm63xx_uart0 at MMIO 0x10000180 (options '115200n8')
[ 0.000000] printk: bootconsole [bcm63xx_uart0] enabled
[ 0.000000] Initrd not found or empty - disabling initrd
[ 0.000000] Reserving 0KB of memory at 4194303KB for kdump
[ 0.000000] Primary instruction cache 64kB, VIPT, 4-way, linesize 16 bytes.
[ 0.000000] Primary data cache 32kB, 2-way, VIPT, cache aliases,
linesize 16 bytes
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000000000000-0x0000000007ffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x0000000007ffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
[ 0.000000] percpu: Embedded 11 pages/cpu s13328 r8192 d23536 u45056
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 32480
[ 0.000000] Kernel command line: earlycon
[ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536
bytes, linear)
[ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768
bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] Memory: 108656K/131072K available (6902K kernel code,
613K rwdata, 1404K rodata, 11872K init, 215K bss, 22416K reserved, 0K
cma-reserved)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] Tracing variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay
is 10 jiffies.
[ 0.000000] NR_IRQS: 256
[ 0.000000] irq_bcm6345_l1: registered BCM6345 L1 intc (IRQs: 128)
[ 0.000000] irq_bcm6345_l1: CPU0 (irq = 2)
[ 0.000000] irq_bcm6345_l1: CPU1 (irq = 3)
[ 0.000000] brcm,bcm63268 detected @ 400 MHz
[ 0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 9556302233 ns
[ 0.000002] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps
every 10737418237ns
[ 0.008292] Calibrating delay loop... 398.13 BogoMIPS (lpj=1990656)
[ 0.074683] pid_max: default: 32768 minimum: 301
[ 0.081788] Mount-cache hash table entries: 1024 (order: 0, 4096
bytes, linear)
[ 0.089319] Mountpoint-cache hash table entries: 1024 (order: 0,
4096 bytes, linear)
[ 0.106094] rcu: Hierarchical SRCU implementation.
[ 0.112665] smp: Bringing up secondary CPUs ...
[ 0.119348] SMP: Booting CPU1...
[ 8.330979] Primary instruction cache 64kB, VIPT, 4-way, linesize 16 bytes.
[ 8.331017] Primary data cache 32kB, 2-way, VIPT, cache aliases,
linesize 16 bytes
[ 8.331294] CPU1 revision is: 0002a080 (Broadcom BMIPS4350)
[ 0.182819] Synchronize counters for CPU 1:
[ 0.203500] SMP: CPU1 is running
[ 0.203512] done.
[ 0.213401] smp: Brought up 1 node, 2 CPUs
[ 0.228870] clocksource: jiffies: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.239058] futex hash table entries: 512 (order: 3, 32768 bytes, linear)
[ 0.246439] pinctrl core: initialized pinctrl subsystem
[ 0.254917] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[ 0.312700] clocksource: Switched to clocksource MIPS
[ 0.321061] NET: Registered PF_INET protocol family
[ 0.326879] IP idents hash table entries: 2048 (order: 2, 16384
bytes, linear)
[ 0.335972] tcp_listen_portaddr_hash hash table entries: 512
(order: 0, 6144 bytes, linear)
[ 0.344721] Table-perturb hash table entries: 65536 (order: 6,
262144 bytes, linear)
[ 0.352721] TCP established hash table entries: 1024 (order: 0,
4096 bytes, linear)
[ 0.360622] TCP bind hash table entries: 1024 (order: 1, 8192 bytes, linear)
[ 0.368005] TCP: Hash tables configured (established 1024 bind 1024)
[ 0.375074] UDP hash table entries: 256 (order: 1, 8192 bytes, linear)
[ 0.381862] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes, linear)
[ 0.389762] NET: Registered PF_UNIX/PF_LOCAL protocol family
[ 0.395748] PCI: CLS 0 bytes, default 16
[ 0.403410] workingset: timestamp_bits=14 max_order=15 bucket_order=1
[ 0.426490] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 0.432492] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME)
(CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[ 0.459472] bcm63xx-power-controller 1000184c.power-controller:
registered 14 power domains
[ 0.470267] 10000180.serial: ttyS0 at MMIO 0x10000180 (irq = 8,
base_baud = 1562500) is a bcm63xx_uart
[ 0.479996] printk: console [ttyS0] enabled
[ 0.479996] printk: console [ttyS0] enabled
[ 0.488651] printk: bootconsole [bcm63xx_uart0] disabled
[ 0.488651] printk: bootconsole [bcm63xx_uart0] disabled
[ 0.533435] bcm2835-rng 10002880.rng: hwrng registered
[ 0.606025] bcm6368_nand 10000200.nand: there is not valid maps for
state default
[ 0.633977] nand: device found, Manufacturer ID: 0xc2, Chip ID: 0xf1
[ 0.640506] nand: Macronix MX30LF1G18AC
[ 0.644551] nand: 128 MiB, SLC, erase size: 128 KiB, page size:
2048, OOB size: 64
[ 0.652359] bcm6368_nand 10000200.nand: detected 128MiB total,
128KiB blocks, 2KiB pages, 16B OOB, 8-bit, BCH-4
[ 0.703373] Bad block table not found for chip 0
[ 0.732040] Bad block table not found for chip 0
[ 0.736842] Scanning device for bad blocks
[ 0.832678] CPU 0 Unable to handle kernel paging request at virtual
address 00000014, epc == 8009b300, ra == 806cc650
[ 0.843628] Oops[#1]:
[ 0.845958] CPU: 0 PID: 88 Comm: hwrng Not tainted 5.15.111 #0
[ 0.851959] $ 0 : 00000000 00000001 00000008 00000000
[ 0.857358] $ 4 : 81808464 00000064 00000000 00000001
[ 0.862753] $ 8 : 81810000 00001ff0 00001c00 815b8880
[ 0.868146] $12 : 0000b79d 00000000 00000000 00009bb
Please, tell me if you want me to add any debugging to the log.
Best regards,
Álvaro.
El mar, 16 may 2023 a las 20:58, Florian Fainelli
(<f.fainelli@...il.com>) escribió:
>
> +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@...il.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@...il.com>) escribió:
> >>>>
> >>>> 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
> >>>>>
>
> --
> Florian
>
Powered by blists - more mailing lists