All of lore.kernel.org
 help / color / mirror / Atom feed
* [BUG] pxa3xx: wait time out when scanning for bb
@ 2017-11-28  9:12 Sean Nyekjær
  2017-11-28 13:02 ` Miquel RAYNAL
  2017-12-09 23:22 ` Ezequiel Garcia
  0 siblings, 2 replies; 85+ messages in thread
From: Sean Nyekjær @ 2017-11-28  9:12 UTC (permalink / raw)
  To: ezequiel.garcia; +Cc: linux-mtd, Kasper Revsbech (KREV)

Hi Ezequiel

I'm currently in the process of doing bringup on a custom armada 38x board.
During the firsts boots of the Linux kernel we saw that the NAND driver 
throws a lot of timeout messages.

Like this:
[ 28.321054] pxa3xx-nand f10d0000.flash: Wait time out!!!
[ 28.521054] pxa3xx-nand f10d0000.flash: Wait time out!!!
[ 28.721054] pxa3xx-nand f10d0000.flash: Wait time out!!!

That lead me to investigate the issue and found this thread (quite old):
https://www.spinics.net/lists/arm-kernel/msg488581.html

In the thread some is describing a possible race condition when the NAND 
framework is scanning for bad blocks.
1. I tried enabling PREEMPT with no success.
2. I tried with commenting out the bad block scanning function, with 
success but not very useful :-)
3. I enabled the BBT function in uboot and the kernel, and that 
apparently fixes the problem.

Can we be sure not to see this issue/racecondition when we are up and 
running? Is there any way to test this?

Br
Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-11-28  9:12 [BUG] pxa3xx: wait time out when scanning for bb Sean Nyekjær
@ 2017-11-28 13:02 ` Miquel RAYNAL
  2017-11-28 13:12   ` Sean Nyekjær
  2017-12-09 23:04   ` Ezequiel Garcia
  2017-12-09 23:22 ` Ezequiel Garcia
  1 sibling, 2 replies; 85+ messages in thread
From: Miquel RAYNAL @ 2017-11-28 13:02 UTC (permalink / raw)
  To: Sean Nyekjær; +Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

Hi Sean,

> I'm currently in the process of doing bringup on a custom armada 38x
> board. During the firsts boots of the Linux kernel we saw that the
> NAND driver throws a lot of timeout messages.
> 
> Like this:
> [ 28.321054] pxa3xx-nand f10d0000.flash: Wait time out!!!
> [ 28.521054] pxa3xx-nand f10d0000.flash: Wait time out!!!
> [ 28.721054] pxa3xx-nand f10d0000.flash: Wait time out!!!

Could you paste the entire dmesg please ?

Also, what kernel are you using ?

> 
> That lead me to investigate the issue and found this thread (quite
> old): https://www.spinics.net/lists/arm-kernel/msg488581.html
> 
> In the thread some is describing a possible race condition when the
> NAND framework is scanning for bad blocks.

Not sure this is still relevant, but, who knows.


Thanks,
Miquèl

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-11-28 13:02 ` Miquel RAYNAL
@ 2017-11-28 13:12   ` Sean Nyekjær
  2017-11-28 13:30     ` Miquel RAYNAL
  2017-12-09 23:04   ` Ezequiel Garcia
  1 sibling, 1 reply; 85+ messages in thread
From: Sean Nyekjær @ 2017-11-28 13:12 UTC (permalink / raw)
  To: Miquel RAYNAL; +Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

Hi Miquel

On 2017-11-28 14:02, Miquel RAYNAL wrote:
> Hi Sean,
>
>> I'm currently in the process of doing bringup on a custom armada 38x
>> board. During the firsts boots of the Linux kernel we saw that the
>> NAND driver throws a lot of timeout messages.
>>
>> Like this:
>> [ 28.321054] pxa3xx-nand f10d0000.flash: Wait time out!!!
>> [ 28.521054] pxa3xx-nand f10d0000.flash: Wait time out!!!
>> [ 28.721054] pxa3xx-nand f10d0000.flash: Wait time out!!!
> Could you paste the entire dmesg please ?
Sure, se below. BBT is disabled
>
> Also, what kernel are you using ?
4.14.0 :-)
>
>> That lead me to investigate the issue and found this thread (quite
>> old): https://www.spinics.net/lists/arm-kernel/msg488581.html
>>
>> In the thread some is describing a possible race condition when the
>> NAND framework is scanning for bad blocks.
> Not sure this is still relevant, but, who knows.
>
>
> Thanks,
> Miquèl

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.14.0-00023-gd0f553c82aac-dirty (skn@skn) 
(gcc version 7.2.0 (Arch Repository)) #46 SMP PREEMPT Tue Nov 28 
12:44:43 CET 2017
[    0.000000] CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7), 
cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[    0.000000] OF: fdt: Machine model: Triax DVB-TC Output
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] random: fast init done
[    0.000000] percpu: Embedded 17 pages/cpu @ef7ca000 s37132 r8192 
d24308 u69632
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 260608
[    0.000000] Kernel command line: console=ttyS0,115200 ubi.mtd=1 
mtdparts=pxa3xx_nand-0:1m(uboot),-(ubi0) shell
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 
bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 
bytes)
[    0.000000] Memory: 1026888K/1048576K available (6144K kernel code, 
428K rwdata, 1328K rodata, 1024K init, 159K bss, 21688K reserved, 0K 
cma-reserved, 262144K highmem)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0xf0800000 - 0xff800000   ( 240 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xf0000000   ( 768 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0700000   (7136 kB)
[    0.000000]       .init : 0xc0900000 - 0xc0a00000   (1024 kB)
[    0.000000]       .data : 0xc0a00000 - 0xc0a6b230   ( 429 kB)
[    0.000000]        .bss : 0xc0a6b230 - 0xc0a9317c   ( 160 kB)
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000]     RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
[    0.000000]     Tasks RCU enabled.
[    0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000] L2C-310 enabling early BRESP for Cortex-A9
[    0.000000] L2C-310 full line of zeros enabled for Cortex-A9
[    0.000000] L2C-310 D prefetch enabled, offset 1 lines
[    0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[    0.000000] L2C-310 Coherent cache controller enabled, 16 ways, 1024 kB
[    0.000000] L2C-310 Coherent: CACHE_ID 0x410054c9, AUX_CTRL 0x56070001
[    0.000010] sched_clock: 64 bits at 533MHz, resolution 1ns, wraps 
every 2199023255551ns
[    0.000023] clocksource: arm_global_timer: mask: 0xffffffffffffffff 
max_cycles: 0x7aed16d152, max_idle_ns: 440795225656 ns
[    0.000042] Switching to timer-based delay loop, resolution 1ns
[    0.000209] Ignoring duplicate/late registration of 
read_current_timer delay
[    0.000219] clocksource: armada_370_xp_clocksource: mask: 0xffffffff 
max_cycles: 0xffffffff, max_idle_ns: 76450417870 ns
[    0.000559] Console: colour dummy device 80x30
[    0.000580] Calibrating delay loop (skipped), value calculated using 
timer frequency.. 1066.00 BogoMIPS (lpj=5330000)
[    0.000590] pid_max: default: 32768 minimum: 301
[    0.000671] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000680] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 
bytes)
[    0.001053] CPU: Testing write buffer coherency: ok
[    0.001211] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.040132] Setting up static identity map for 0x100000 - 0x100060
[    0.040228] mvebu-soc-id: MVEBU SoC ID=0x6810, Rev=0x4
[    0.040323] mvebu-pmsu: Initializing Power Management Service Unit
[    0.060106] Hierarchical SRCU implementation.
[    0.100104] smp: Bringing up secondary CPUs ...
[    0.170166] Booting CPU 1
[    1.200101] CPU1: failed to come online
[    1.200154] smp: Brought up 1 node, 1 CPU
[    1.200160] SMP: Total of 1 processors activated (1066.00 BogoMIPS).
[    1.200165] CPU: All CPU(s) started in SVC mode.
[    1.200696] devtmpfs: initialized
[    1.202583] VFP support v0.3: implementor 41 architecture 3 part 30 
variant 9 rev 4
[    1.202704] clocksource: jiffies: mask: 0xffffffff max_cycles: 
0xffffffff, max_idle_ns: 19112604462750000 ns
[    1.202715] futex hash table entries: 512 (order: 3, 32768 bytes)
[    1.202821] pinctrl core: initialized pinctrl subsystem
[    1.203212] NET: Registered protocol family 16
[    1.203846] DMA: preallocated 256 KiB pool for atomic coherent 
allocations
[    1.204397] cpuidle: using governor ladder
[    1.204462] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 
watchpoint registers.
[    1.204469] hw-breakpoint: maximum watchpoint size is 4 bytes.
[    1.204598] mvebu-pmsu: CPU hotplug support is currently broken on 
Armada 38x: disabling
[    1.204608] mvebu-pmsu: CPU idle is currently broken on Armada 38x: 
disabling
[    1.240390] SCSI subsystem initialized
[    1.260188] clocksource: Switched to clocksource arm_global_timer
[    1.286316] NET: Registered protocol family 2
[    1.286687] TCP established hash table entries: 8192 (order: 3, 32768 
bytes)
[    1.286746] TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
[    1.286841] TCP: Hash tables configured (established 8192 bind 8192)
[    1.286921] UDP hash table entries: 512 (order: 2, 16384 bytes)
[    1.286959] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[    1.287074] NET: Registered protocol family 1
[    1.307361] RPC: Registered named UNIX socket transport module.
[    1.307367] RPC: Registered udp transport module.
[    1.307372] RPC: Registered tcp transport module.
[    1.307376] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    1.307513] Unpacking initramfs...
[    1.439858] Freeing initrd memory: 2656K
[    1.440285] hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7 
counters available
[    1.441143] workingset: timestamp_bits=30 max_order=18 bucket_order=0
[    1.452415] bounce: pool size: 64 pages
[    1.452451] Block layer SCSI generic (bsg) driver version 0.4 loaded 
(major 251)
[    1.452459] io scheduler noop registered
[    1.452464] io scheduler deadline registered
[    1.452499] io scheduler cfq registered (default)
[    1.452505] io scheduler mq-deadline registered
[    1.452510] io scheduler kyber registered
[    1.453243] armada-38x-pinctrl f1018000.pinctrl: registered pinctrl 
driver
[    1.454825] mvebu-pcie soc:pcie: PCI host bridge to bus 0000:00
[    1.454837] pci_bus 0000:00: root bus resource [io 0x1000-0xfffff]
[    1.454845] pci_bus 0000:00: root bus resource [mem 
0xe0000000-0xe7ffffff]
[    1.454852] pci_bus 0000:00: root bus resource [bus 00-ff]
[    1.455028] PCI: bus0: Fast back to back transfers disabled
[    1.455037] pci 0000:00:01.0: bridge configuration invalid ([bus 
00-00]), reconfiguring
[    1.455102] PCI: bus1: Fast back to back transfers enabled
[    1.455129] pci 0000:00:01.0: PCI bridge to [bus 01]
[    1.455456] mv_xor f1060800.xor: Marvell shared XOR driver
[    1.510678] mv_xor f1060800.xor: Marvell XOR (Descriptor Mode): ( xor 
cpy intr )
[    1.510833] mv_xor f1060900.xor: Marvell shared XOR driver
[    1.570660] mv_xor f1060900.xor: Marvell XOR (Descriptor Mode): ( xor 
cpy intr )
[    1.594127] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    1.595218] console [ttyS0] disabled
[    1.615355] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 22, 
base_baud = 15625000) is a 16550A
[    2.284175] console [ttyS0] enabled
[    2.288684] pxa3xx-nand f10d0000.flash: This platform can't do DMA on 
this device
[    2.296924] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
[    2.303311] nand: Micron MT29F2G08ABAEAH4
[    2.307334] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, 
OOB size: 64
[    2.314939] pxa3xx-nand f10d0000.flash: ECC strength 16, ECC step 
size 2048
[    2.321936] Scanning device for bad blocks
[    2.530193] pxa3xx-nand f10d0000.flash: Wait time out!!!
[    2.740191] pxa3xx-nand f10d0000.flash: Wait time out!!!
[    2.950191] pxa3xx-nand f10d0000.flash: Wait time out!!!
[    3.160192] pxa3xx-nand f10d0000.flash: Wait time out!!!
[    3.370191] pxa3xx-nand f10d0000.flash: Wait time out!!!
[    3.580191] pxa3xx-nand f10d0000.flash: Wait time out!!!
[    3.790191] pxa3xx-nand f10d0000.flash: Wait time out!!!
[    4.000191] pxa3xx-nand f10d0000.flash: Wait time out!!!
[    4.210191] pxa3xx-nand f10d0000.flash: Wait time out!!!
[    4.420191] pxa3xx-nand f10d0000.flash: Wait time out!!!
...

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-11-28 13:12   ` Sean Nyekjær
@ 2017-11-28 13:30     ` Miquel RAYNAL
  2017-11-28 13:42       ` Sean Nyekjær
  2017-12-09 23:18       ` Ezequiel Garcia
  0 siblings, 2 replies; 85+ messages in thread
From: Miquel RAYNAL @ 2017-11-28 13:30 UTC (permalink / raw)
  To: Sean Nyekjær; +Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

Hi Sean,


> > Also, what kernel are you using ?  
> 4.14.0 :-)

Good !

> [    2.288684] pxa3xx-nand f10d0000.flash: This platform can't do DMA
> on this device

FYI, this is normal, the NAND controller does not have any DMA feature
on Armada 38x (NFCv2).

> [    2.296924] nand: device found, Manufacturer ID: 0x2c, Chip ID:
> 0xda [    2.303311] nand: Micron MT29F2G08ABAEAH4
> [    2.307334] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
> 2048, OOB size: 64
> [    2.314939] pxa3xx-nand f10d0000.flash: ECC strength 16, ECC step 
> size 2048

In theory, Marvell NAND flash controller does support 16-bit strength
per 512 bytes over 2048 bytes pages. However, this controller driver
(pxa3xx_nand) does not. See [1] for the supported configurations.

The ECC strength shown here is probably the best to use with this type
of NAND device but I suggest you try with 4b/512B by using these two
properties like in [2]:

        nand-ecc-strength = <4>;
        nand-ecc-step-size = <512>;


Thanks,
Miquèl

[1]
http://elixir.free-electrons.com/linux/v4.14/source/drivers/mtd/nand/pxa3xx_nand.c#L1575

[2]
http://elixir.free-electrons.com/linux/v4.14/source/arch/arm/boot/dts/armada-385-db-ap.dts#L172

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-11-28 13:30     ` Miquel RAYNAL
@ 2017-11-28 13:42       ` Sean Nyekjær
  2017-11-28 14:04         ` Miquel RAYNAL
  2017-12-09 23:18       ` Ezequiel Garcia
  1 sibling, 1 reply; 85+ messages in thread
From: Sean Nyekjær @ 2017-11-28 13:42 UTC (permalink / raw)
  To: Miquel RAYNAL; +Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

Hi Miquel

On 2017-11-28 14:30, Miquel RAYNAL wrote:
> Hi Sean,
>
>
>>> Also, what kernel are you using ?
>> 4.14.0 :-)
> Good !
>
>> [    2.288684] pxa3xx-nand f10d0000.flash: This platform can't do DMA
>> on this device
> FYI, this is normal, the NAND controller does not have any DMA feature
> on Armada 38x (NFCv2).
>
>> [    2.296924] nand: device found, Manufacturer ID: 0x2c, Chip ID:
>> 0xda [    2.303311] nand: Micron MT29F2G08ABAEAH4
>> [    2.307334] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
>> 2048, OOB size: 64
>> [    2.314939] pxa3xx-nand f10d0000.flash: ECC strength 16, ECC step
>> size 2048
> In theory, Marvell NAND flash controller does support 16-bit strength
> per 512 bytes over 2048 bytes pages. However, this controller driver
> (pxa3xx_nand) does not. See [1] for the supported configurations.
>
> The ECC strength shown here is probably the best to use with this type
> of NAND device but I suggest you try with 4b/512B by using these two
> properties like in [2]:
>
>          nand-ecc-strength = <4>;
>          nand-ecc-step-size = <512>;
My dts iscreated with great inspiration from the armada-385-dp-ap.dts

&nand {
         status = "okay";
         pinctrl-names = "default";
         pinctrl-0 = <&nand_pins>, <&nand_rb>;
         num-cs = <1>;
         nand-on-flash-bbt;
         nand-ecc-strength = <4>;
         nand-ecc-step-size = <512>;
};

Why does the driver not set these values?
(I only see the timeouts if I remove the nand-on-flash-bbt)
>
>
> Thanks,
> Miquèl
>
> [1]
> http://elixir.free-electrons.com/linux/v4.14/source/drivers/mtd/nand/pxa3xx_nand.c#L1575
>
> [2]
> http://elixir.free-electrons.com/linux/v4.14/source/arch/arm/boot/dts/armada-385-db-ap.dts#L172

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-11-28 13:42       ` Sean Nyekjær
@ 2017-11-28 14:04         ` Miquel RAYNAL
  2017-11-29  7:14           ` Sean Nyekjær
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel RAYNAL @ 2017-11-28 14:04 UTC (permalink / raw)
  To: Sean Nyekjær; +Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

Hi Sean,

> >> [    2.314939] pxa3xx-nand f10d0000.flash: ECC strength 16, ECC
> >> step size 2048  
> > In theory, Marvell NAND flash controller does support 16-bit
> > strength per 512 bytes over 2048 bytes pages. However, this
> > controller driver (pxa3xx_nand) does not. See [1] for the supported
> > configurations.
> >
> > The ECC strength shown here is probably the best to use with this
> > type of NAND device but I suggest you try with 4b/512B by using
> > these two properties like in [2]:
> >
> >          nand-ecc-strength = <4>;
> >          nand-ecc-step-size = <512>;  
> My dts iscreated with great inspiration from the armada-385-dp-ap.dts
> 
> &nand {
>          status = "okay";
>          pinctrl-names = "default";
>          pinctrl-0 = <&nand_pins>, <&nand_rb>;
>          num-cs = <1>;
>          nand-on-flash-bbt;
>          nand-ecc-strength = <4>;
>          nand-ecc-step-size = <512>;
> };

Just for testing purpose, could you also put the keep-config and
enable-arbiter properties ?

> 
> Why does the driver not set these values?

Perhaps you can add traces there [3] and see where it fails?

[3]
http://elixir.free-electrons.com/linux/v4.14/source/drivers/mtd/nand/pxa3xx_nand.c#L1721

> (I only see the timeouts if I remove the nand-on-flash-bbt)

The nand-on-flash-bbt will read some of the last pages in you NAND chip
where a bad block table is supposed to be and derive from that
whether a block is bad or not. So this does only one read. I guess you
should have at least one timeout there?

Without this property, the NAND core will read every bad block marker
(a few bytes at the beginning of the OOB area) and detect if the block
was marked bad. Each access seems to produce a timeout, hence the big
amount of errors you see.

Thanks,
Miquèl

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-11-28 14:04         ` Miquel RAYNAL
@ 2017-11-29  7:14           ` Sean Nyekjær
  2017-11-29  8:03             ` Miquel RAYNAL
  0 siblings, 1 reply; 85+ messages in thread
From: Sean Nyekjær @ 2017-11-29  7:14 UTC (permalink / raw)
  To: Miquel RAYNAL; +Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)


> Hi Sean,
>
>>>> [    2.314939] pxa3xx-nand f10d0000.flash: ECC strength 16, ECC
>>>> step size 2048
>>> In theory, Marvell NAND flash controller does support 16-bit
>>> strength per 512 bytes over 2048 bytes pages. However, this
>>> controller driver (pxa3xx_nand) does not. See [1] for the supported
>>> configurations.
>>>
>>> The ECC strength shown here is probably the best to use with this
>>> type of NAND device but I suggest you try with 4b/512B by using
>>> these two properties like in [2]:
>>>
>>>           nand-ecc-strength = <4>;
>>>           nand-ecc-step-size = <512>;
>> My dts iscreated with great inspiration from the armada-385-dp-ap.dts
>>
>> &nand {
>>           status = "okay";
>>           pinctrl-names = "default";
>>           pinctrl-0 = <&nand_pins>, <&nand_rb>;
>>           num-cs = <1>;
>>           nand-on-flash-bbt;
>>           nand-ecc-strength = <4>;
>>           nand-ecc-step-size = <512>;
>> };
> Just for testing purpose, could you also put the keep-config and
> enable-arbiter properties ?
Yes, but i don't think the arbiter have any affect in the nand controller.
Bit 12 in NDCR register is marked reserved in the datasheet.
>
>> Why does the driver not set these values?
> Perhaps you can add traces there [3] and see where it fails?
>
> [3]
> http://elixir.free-electrons.com/linux/v4.14/source/drivers/mtd/nand/pxa3xx_nand.c#L1721
See here [4] the driver is selecting 16 bit strength when we are 
specifying 4 bits in the dts.

[4]
http://elixir.free-electrons.com/linux/v4.14/source/drivers/mtd/nand/pxa3xx_nand.c#L1595
>> (I only see the timeouts if I remove the nand-on-flash-bbt)
> The nand-on-flash-bbt will read some of the last pages in you NAND chip
> where a bad block table is supposed to be and derive from that
> whether a block is bad or not. So this does only one read. I guess you
> should have at least one timeout there?
Maybe, but the flash is fine we are running a rootfs in the NAND chip.

> Without this property, the NAND core will read every bad block marker
> (a few bytes at the beginning of the OOB area) and detect if the block
> was marked bad. Each access seems to produce a timeout, hence the big
> amount of errors you see.
in the old thread I linked, they had the same issue and like me only 
when scanning for
bad blocks.

/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-11-29  7:14           ` Sean Nyekjær
@ 2017-11-29  8:03             ` Miquel RAYNAL
  2017-11-30 12:00               ` Sean Nyekjær
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel RAYNAL @ 2017-11-29  8:03 UTC (permalink / raw)
  To: Sean Nyekjær; +Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

Hi Sean,

> >>>> [    2.314939] pxa3xx-nand f10d0000.flash: ECC strength 16, ECC
> >>>> step size 2048  
> >>> In theory, Marvell NAND flash controller does support 16-bit
> >>> strength per 512 bytes over 2048 bytes pages. However, this
> >>> controller driver (pxa3xx_nand) does not. See [1] for the
> >>> supported configurations.
> >>>
> >>> The ECC strength shown here is probably the best to use with this
> >>> type of NAND device but I suggest you try with 4b/512B by using
> >>> these two properties like in [2]:
> >>>
> >>>           nand-ecc-strength = <4>;
> >>>           nand-ecc-step-size = <512>;  
> >> My dts iscreated with great inspiration from the
> >> armada-385-dp-ap.dts
> >>
> >> &nand {
> >>           status = "okay";
> >>           pinctrl-names = "default";
> >>           pinctrl-0 = <&nand_pins>, <&nand_rb>;
> >>           num-cs = <1>;
> >>           nand-on-flash-bbt;
> >>           nand-ecc-strength = <4>;
> >>           nand-ecc-step-size = <512>;
> >> };  
> > Just for testing purpose, could you also put the keep-config and
> > enable-arbiter properties ?  
> Yes, but i don't think the arbiter have any affect in the nand
> controller. Bit 12 in NDCR register is marked reserved in the
> datasheet.

Be careful with that. I recently enabled 64-bit platforms featuring
this NAND controller. After hours of digging because it was not
working, I set this bit by adding this property like in any other device
tree and it worked. I am not telling that it will solve your issue,
mostly not, but this is something you should be careful about.

> >  
> >> Why does the driver not set these values?  
> > Perhaps you can add traces there [3] and see where it fails?
> >
> > [3]
> > http://elixir.free-electrons.com/linux/v4.14/source/drivers/mtd/nand/pxa3xx_nand.c#L1721  
> See here [4] the driver is selecting 16 bit strength when we are 
> specifying 4 bits in the dts.

That is right.

> 
> [4]
> http://elixir.free-electrons.com/linux/v4.14/source/drivers/mtd/nand/pxa3xx_nand.c#L1595
> >> (I only see the timeouts if I remove the nand-on-flash-bbt)  
> > The nand-on-flash-bbt will read some of the last pages in you NAND
> > chip where a bad block table is supposed to be and derive from that
> > whether a block is bad or not. So this does only one read. I guess
> > you should have at least one timeout there?  
> Maybe, but the flash is fine we are running a rootfs in the NAND chip.

So you can safely use the content of the NAND chip? Without any timeout
neither with reads nor writes? Can you try the mtd-utils from [5]:
nanddump/nandwrite or nandpagetest?

Also, can you isolate the line that produces the timeouts?

[5] http://www.linux-mtd.infradead.org/

> 
> > Without this property, the NAND core will read every bad block
> > marker (a few bytes at the beginning of the OOB area) and detect if
> > the block was marked bad. Each access seems to produce a timeout,
> > hence the big amount of errors you see.  
> in the old thread I linked, they had the same issue and like me only 
> when scanning for
> bad blocks.
> 
> /Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-11-29  8:03             ` Miquel RAYNAL
@ 2017-11-30 12:00               ` Sean Nyekjær
  2017-11-30 17:18                 ` Miquel RAYNAL
  0 siblings, 1 reply; 85+ messages in thread
From: Sean Nyekjær @ 2017-11-30 12:00 UTC (permalink / raw)
  To: Miquel RAYNAL; +Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

Hi Miquel
>> Yes, but i don't think the arbiter have any affect in the nand
>> controller. Bit 12 in NDCR register is marked reserved in the
>> datasheet.
> Be careful with that. I recently enabled 64-bit platforms featuring
> this NAND controller. After hours of digging because it was not
> working, I set this bit by adding this property like in any other device
> tree and it worked. I am not telling that it will solve your issue,
> mostly not, but this is something you should be careful about.
I have tried with arbiter enabled, no different behaviour observed.
>>>> (I only see the timeouts if I remove the nand-on-flash-bbt)
>>> The nand-on-flash-bbt will read some of the last pages in you NAND
>>> chip where a bad block table is supposed to be and derive from that
>>> whether a block is bad or not. So this does only one read. I guess
>>> you should have at least one timeout there?
>> Maybe, but the flash is fine we are running a rootfs in the NAND chip.
> So you can safely use the content of the NAND chip? Without any timeout
> neither with reads nor writes? Can you try the mtd-utils from [5]:
> nanddump/nandwrite or nandpagetest?
>
> Also, can you isolate the line that produces the timeouts?
>
> [5]http://www.linux-mtd.infradead.org/
Yes the NAND chip is working fine and stores our data.

It is the command NAND_CMD_READOOB that causes it to timeout.

Here is a dump (booting with bbt enabled):
root@output-module:~# nanddump -oa /dev/mtd1
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 8
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x0ff00000...
[  984.580213] pxa3xx-nand f10d0000.flash: Wait time out!!!
[  984.790195] pxa3xx-nand f10d0000.flash: Wait time out!!!
[  985.000195] pxa3xx-nand f10d0000.flash: Wait time out!!!

/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-11-30 12:00               ` Sean Nyekjær
@ 2017-11-30 17:18                 ` Miquel RAYNAL
  2017-11-30 18:13                   ` Sean Nyekjær
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel RAYNAL @ 2017-11-30 17:18 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi Sean,

+Boris (NAND maintainer).

> >> Yes, but i don't think the arbiter have any affect in the nand
> >> controller. Bit 12 in NDCR register is marked reserved in the
> >> datasheet.  
> > Be careful with that. I recently enabled 64-bit platforms featuring
> > this NAND controller. After hours of digging because it was not
> > working, I set this bit by adding this property like in any other
> > device tree and it worked. I am not telling that it will solve your
> > issue, mostly not, but this is something you should be careful
> > about.  
> I have tried with arbiter enabled, no different behaviour observed.

Ok.

> >>>> (I only see the timeouts if I remove the nand-on-flash-bbt)  
> >>> The nand-on-flash-bbt will read some of the last pages in you NAND
> >>> chip where a bad block table is supposed to be and derive from
> >>> that whether a block is bad or not. So this does only one read. I
> >>> guess you should have at least one timeout there?  
> >> Maybe, but the flash is fine we are running a rootfs in the NAND
> >> chip.  
> > So you can safely use the content of the NAND chip? Without any
> > timeout neither with reads nor writes? Can you try the mtd-utils
> > from [5]: nanddump/nandwrite or nandpagetest?
> >
> > Also, can you isolate the line that produces the timeouts?
> >
> > [5]http://www.linux-mtd.infradead.org/  
> Yes the NAND chip is working fine and stores our data.
> 
> It is the command NAND_CMD_READOOB that causes it to timeout.

Ok, I had a look at the nand_cmdfunc() function which is, I suppose,
the one that is in use (because you are using 2k pages) but I could
not see anything obvious. Is your setup special in some way?

Could you enable dynamic debug by adding "#define DEBUG" *before* all
#includes at the top of the pxa3xx_nand.c driver? It should display all
register accesses. Also, can you read the content of NDCR and NDSR when
it timeouts?

Thanks,
Miquèl

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-11-30 17:18                 ` Miquel RAYNAL
@ 2017-11-30 18:13                   ` Sean Nyekjær
  2017-12-01  8:15                     ` Miquel RAYNAL
  0 siblings, 1 reply; 85+ messages in thread
From: Sean Nyekjær @ 2017-11-30 18:13 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi
>>>>>> (I only see the timeouts if I remove the nand-on-flash-bbt)
>>>>> The nand-on-flash-bbt will read some of the last pages in you NAND
>>>>> chip where a bad block table is supposed to be and derive from
>>>>> that whether a block is bad or not. So this does only one read. I
>>>>> guess you should have at least one timeout there?
>>>> Maybe, but the flash is fine we are running a rootfs in the NAND
>>>> chip.
>>> So you can safely use the content of the NAND chip? Without any
>>> timeout neither with reads nor writes? Can you try the mtd-utils
>>> from [5]: nanddump/nandwrite or nandpagetest?
>>>
>>> Also, can you isolate the line that produces the timeouts?
>>>
>>> [5]http://www.linux-mtd.infradead.org/
>> Yes the NAND chip is working fine and stores our data.
>>
>> It is the command NAND_CMD_READOOB that causes it to timeout.
> Ok, I had a look at the nand_cmdfunc() function which is, I suppose,
> the one that is in use (because you are using 2k pages) but I could
> not see anything obvious. Is your setup special in some way?
Yes it's nand_cmdfunc()
No a clean 4.14.0 kernel with a custom dts.
>
> Could you enable dynamic debug by adding "#define DEBUG" *before* all
> #includes at the top of the pxa3xx_nand.c driver? It should display all
> register accesses. Also, can you read the content of NDCR and NDSR when
> it timeouts?
>
[   32.765604] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():605 
nand_writel(0x1, 0x0028)
[   32.765609] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():625 
nand_writel(0xfff, 0x0014)
[   32.765614] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():626 
nand_writel(0x0, 0x0000)
[   32.765620] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():627 
nand_writel(0xd1078000, 0x0000)
[   32.765627] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():824 
nand_readl(0x0014) = 0x1
[   32.765632] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():874 
nand_writel(0x1, 0x0014)
[   32.765637] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():888 
nand_writel(0xd3000, 0x0048)
[   32.765643] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():889 
nand_writel(0x2060000, 0x0048)
[   32.765648] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():890 
nand_writel(0x0, 0x0048)
[   32.765653] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():894 
nand_writel(0x0, 0x0048)
[   32.765677] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():824 
nand_readl(0x0014) = 0x800
[   32.765682] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():874 
nand_writel(0x800, 0x0014)
[   32.765797] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():824 
nand_readl(0x0014) = 0x2
[   32.765886] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq_thread():804 
nand_writel(0x6, 0x0014)
[   32.765893] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():824 
nand_readl(0x0014) = 0x500
[   32.765899] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():874 
nand_writel(0x500, 0x0014)
[   32.765950] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():609 
nand_writel(0x0, 0x0028)
[   32.765956] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():625 
nand_writel(0xfff, 0x0014)
[   32.765961] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():626 
nand_writel(0x0, 0x0000)
[   32.765966] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():627 
nand_writel(0x91078000, 0x0000)
[   32.765974] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():824 
nand_readl(0x0014) = 0x1
[   32.765979] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():874 
nand_writel(0x1, 0x0014)
[   32.765984] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():888 
nand_writel(0xd3000, 0x0048)
[   32.765989] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():889 
nand_writel(0x2060000, 0x0048)
[   32.765994] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():890 
nand_writel(0x0, 0x0048)
[   32.766000] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():894 
nand_writel(0x0, 0x0048)
[   32.766022] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():824 
nand_readl(0x0014) = 0x800
[   32.766028] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():874 
nand_writel(0x800, 0x0014)
[   32.766143] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():824 
nand_readl(0x0014) = 0x2
[   32.766233] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq_thread():804 
nand_writel(0x6, 0x0014)
[   32.970203] pxa3xx-nand f10d0000.flash: Wait time out!!!
*[   32.975535] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():636 
nand_readl(0x0014) = 0x0*
*[   32.975540] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():637 
nand_readl(0x0000) = 0x91078000*
[   32.975546] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():639 
nand_readl(0x0000) = 0x91078000
[   32.975552] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():639 
nand_readl(0x0000) = 0x91078000
[   32.975559] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():639 
nand_readl(0x0000) = 0x91078000
[   32.975565] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():639 
nand_readl(0x0000) = 0x91078000
[   32.975572] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():645 
nand_writel(0x81078000, 0x0000)
[   32.975577] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():651 
nand_writel(0xfff, 0x0014)

I think I got one whole timeout sequence here :-)
Register 0x0014 is NDSR and reg 0x0000 is NDCR, I have added a read of the
NDSR register in the pxa3xx_nand_stop routine as highlighted above.
It pussles me that the nand_start is called two times before
the timeout, maybe it's okay.

/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-11-30 18:13                   ` Sean Nyekjær
@ 2017-12-01  8:15                     ` Miquel RAYNAL
  2017-12-01  8:54                       ` Sean Nyekjær
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-01  8:15 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

> >>>>>> (I only see the timeouts if I remove the nand-on-flash-bbt)  
> >>>>> The nand-on-flash-bbt will read some of the last pages in you
> >>>>> NAND chip where a bad block table is supposed to be and derive
> >>>>> from that whether a block is bad or not. So this does only one
> >>>>> read. I guess you should have at least one timeout there?  
> >>>> Maybe, but the flash is fine we are running a rootfs in the NAND
> >>>> chip.  
> >>> So you can safely use the content of the NAND chip? Without any
> >>> timeout neither with reads nor writes? Can you try the mtd-utils
> >>> from [5]: nanddump/nandwrite or nandpagetest?
> >>>
> >>> Also, can you isolate the line that produces the timeouts?
> >>>
> >>> [5]http://www.linux-mtd.infradead.org/  
> >> Yes the NAND chip is working fine and stores our data.
> >>
> >> It is the command NAND_CMD_READOOB that causes it to timeout.  
> > Ok, I had a look at the nand_cmdfunc() function which is, I suppose,
> > the one that is in use (because you are using 2k pages) but I could
> > not see anything obvious. Is your setup special in some way?  
> Yes it's nand_cmdfunc()
> No a clean 4.14.0 kernel with a custom dts.
> >
> > Could you enable dynamic debug by adding "#define DEBUG" *before*
> > all #includes at the top of the pxa3xx_nand.c driver? It should
> > display all register accesses. Also, can you read the content of
> > NDCR and NDSR when it timeouts?
> >  
> [   32.765604] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():605 
> nand_writel(0x1, 0x0028)
> [   32.765609] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():625 
> nand_writel(0xfff, 0x0014)
> [   32.765614] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():626 
> nand_writel(0x0, 0x0000)
> [   32.765620] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():627 
> nand_writel(0xd1078000, 0x0000)

This is a write command request.

> [   32.765627] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():824 
> nand_readl(0x0014) = 0x1
> [   32.765632] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():874 
> nand_writel(0x1, 0x0014)

The command is ready to be written in NDCB* registers (0x48).

> [   32.765637] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():888 
> nand_writel(0xd3000, 0x0048)
> [   32.765643] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():889 
> nand_writel(0x2060000, 0x0048)
> [   32.765648] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():890 
> nand_writel(0x0, 0x0048)
> [   32.765653] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():894 
> nand_writel(0x0, 0x0048)

"Command" registers are set:
- READ0/READSTART commands (double byte command)
- 5 address cycles: column is 0, page is 0x206 which is weird if this
  is a READOOB operation, where column should be something like 0x800
  (mtd->writesize).

> [   32.765677] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():824 
> nand_readl(0x0014) = 0x800
> [   32.765682] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():874 
> nand_writel(0x800, 0x0014)
> [   32.765797] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():824 
> nand_readl(0x0014) = 0x2
> [   32.765886] pxa3xx-nand f10d0000.flash:
> pxa3xx_nand_irq_thread():804 nand_writel(0x6, 0x0014)

Read data request received, the FIFO may be drawn.

> [   32.765893] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():824 
> nand_readl(0x0014) = 0x500
> [   32.765899] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():874 
> nand_writel(0x500, 0x0014)
> [   32.765950] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():609 
> nand_writel(0x0, 0x0028)
> [   32.765956] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():625 
> nand_writel(0xfff, 0x0014)

Command done received, it means data was read correctly.

And this is the start of another "action".

> [   32.765961] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():626 
> nand_writel(0x0, 0x0000)
> [   32.765966] pxa3xx-nand f10d0000.flash: pxa3xx_nand_start():627 
> nand_writel(0x91078000, 0x0000)
> [   32.765974] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():824 
> nand_readl(0x0014) = 0x1
> [   32.765979] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():874 
> nand_writel(0x1, 0x0014)

Same as before, command is ready to be written, single difference is
the use of the HW ECC engine. But, a few lines earlier, 0 was written
to NDECCCTRL (0x28), disabling BCH, which is weird because there we
will do an operation under Hamming ECC engine.

> [   32.765984] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():888 
> nand_writel(0xd3000, 0x0048)
> [   32.765989] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():889 
> nand_writel(0x2060000, 0x0048)
> [   32.765994] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():890 
> nand_writel(0x0, 0x0048)
> [   32.766000] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():894 
> nand_writel(0x0, 0x0048)

Same read operation as before.

> [   32.766022] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():824 
> nand_readl(0x0014) = 0x800
> [   32.766028] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():874 
> nand_writel(0x800, 0x0014)
> [   32.766143] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():824 
> nand_readl(0x0014) = 0x2
> [   32.766233] pxa3xx-nand f10d0000.flash:
> pxa3xx_nand_irq_thread():804 nand_writel(0x6, 0x0014)

Read data request received, I guess there is some ioread32_rep here
which is not traced and finally:

> [   32.970203] pxa3xx-nand f10d0000.flash: Wait time out!!!

Next lines are the error path.

> *[   32.975535] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():636 
> nand_readl(0x0014) = 0x0*
> *[   32.975540] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():637 
> nand_readl(0x0000) = 0x91078000*
> [   32.975546] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():639 
> nand_readl(0x0000) = 0x91078000
> [   32.975552] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():639 
> nand_readl(0x0000) = 0x91078000
> [   32.975559] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():639 
> nand_readl(0x0000) = 0x91078000
> [   32.975565] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():639 
> nand_readl(0x0000) = 0x91078000
> [   32.975572] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():645 
> nand_writel(0x81078000, 0x0000)
> [   32.975577] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():651 
> nand_writel(0xfff, 0x0014)
> 
> I think I got one whole timeout sequence here :-)
> Register 0x0014 is NDSR and reg 0x0000 is NDCR, I have added a read
> of the NDSR register in the pxa3xx_nand_stop routine as highlighted
> above. It pussles me that the nand_start is called two times before
> the timeout, maybe it's okay.

Can you add traces there [1] to see which path is used ?

[1]
http://elixir.free-electrons.com/linux/latest/source/drivers/mtd/nand/pxa3xx_nand.c#L669


Thanks,
Miquèl

-- 
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-01  8:15                     ` Miquel RAYNAL
@ 2017-12-01  8:54                       ` Sean Nyekjær
  2017-12-07 20:38                         ` Miquel RAYNAL
  0 siblings, 1 reply; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-01  8:54 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi
> Can you add traces there [1] to see which path is used ?
>
> [1]
> http://elixir.free-electrons.com/linux/latest/source/drivers/mtd/nand/pxa3xx_nand.c#L669
>
>
I have inserted trace in drain_fifo:
Line 672 right at the top
Line 677 inside "if (info->ecc_bch)"
Line 687 in the while loop
Line 702 just before ioread32_rep

[   37.356209] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():827 
nand_readl(0x0014) = 0x1
[   37.356214] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():877 
nand_writel(0x1, 0x0014)
[   37.356219] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():891 
nand_writel(0xd3000, 0x0048)
[   37.356224] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():892 
nand_writel(0x2040000, 0x0048)
[   37.356228] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():893 
nand_writel(0x0, 0x0048)
[   37.356233] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():897 
nand_writel(0x0, 0x0048)
[   37.356256] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():827 
nand_readl(0x0014) = 0x800
[   37.356261] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():877 
nand_writel(0x800, 0x0014)
[   37.356376] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():827 
nand_readl(0x0014) = 0x2
[   37.356386] pxa3xx-nand f10d0000.flash: drain_fifo():672
[   37.356390] pxa3xx-nand f10d0000.flash: drain_fifo():677
[   37.356394] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356400] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356405] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356410] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356415] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356420] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356425] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356430] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356435] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356440] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356446] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356451] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356456] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356461] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356466] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356471] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356476] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356481] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356486] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356491] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356497] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356502] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356507] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356512] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356517] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356522] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356527] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356532] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356537] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356542] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356548] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356553] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356558] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356563] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356568] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356573] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356578] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356583] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356588] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356593] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356598] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356604] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356609] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356614] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356619] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356624] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356629] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356634] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356639] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356644] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356650] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356655] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356660] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356665] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356670] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356675] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356680] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356685] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356690] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356695] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356700] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356705] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356711] pxa3xx-nand f10d0000.flash: drain_fifo():687
[   37.356716] pxa3xx-nand f10d0000.flash: drain_fifo():702
[   37.356721] pxa3xx-nand f10d0000.flash: drain_fifo():672
[   37.356725] pxa3xx-nand f10d0000.flash: drain_fifo():677
[   37.356728] pxa3xx-nand f10d0000.flash: drain_fifo():702
[   37.356734] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq_thread():807 
nand_writel(0x6, 0x0014)
[   37.560189] pxa3xx-nand f10d0000.flash: Wait time out!!!
[   37.565521] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():636 
nand_readl(0x0000) = 0x91078000

Thanks
/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-01  8:54                       ` Sean Nyekjær
@ 2017-12-07 20:38                         ` Miquel RAYNAL
  2017-12-08  9:04                           ` Sean Nyekjær
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-07 20:38 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi Sean,

> > Can you add traces there [1] to see which path is used ?
> >
> > [1]
> > http://elixir.free-electrons.com/linux/latest/source/drivers/mtd/nand/pxa3xx_nand.c#L669
> >
> >  
> I have inserted trace in drain_fifo:
> Line 672 right at the top
> Line 677 inside "if (info->ecc_bch)"
> Line 687 in the while loop
> Line 702 just before ioread32_rep
> 
> [   37.356209] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():827 
> nand_readl(0x0014) = 0x1
> [   37.356214] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():877 
> nand_writel(0x1, 0x0014)
> [   37.356219] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():891 
> nand_writel(0xd3000, 0x0048)
> [   37.356224] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():892 
> nand_writel(0x2040000, 0x0048)
> [   37.356228] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():893 
> nand_writel(0x0, 0x0048)
> [   37.356233] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():897 
> nand_writel(0x0, 0x0048)
> [   37.356256] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():827 
> nand_readl(0x0014) = 0x800
> [   37.356261] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():877 
> nand_writel(0x800, 0x0014)
> [   37.356376] pxa3xx-nand f10d0000.flash: pxa3xx_nand_irq():827 
> nand_readl(0x0014) = 0x2
> [   37.356386] pxa3xx-nand f10d0000.flash: drain_fifo():672
> [   37.356390] pxa3xx-nand f10d0000.flash: drain_fifo():677
> [   37.356394] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356400] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356405] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356410] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356415] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356420] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356425] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356430] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356435] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356440] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356446] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356451] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356456] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356461] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356466] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356471] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356476] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356481] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356486] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356491] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356497] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356502] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356507] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356512] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356517] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356522] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356527] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356532] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356537] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356542] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356548] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356553] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356558] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356563] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356568] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356573] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356578] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356583] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356588] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356593] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356598] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356604] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356609] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356614] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356619] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356624] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356629] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356634] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356639] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356644] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356650] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356655] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356660] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356665] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356670] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356675] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356680] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356685] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356690] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356695] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356700] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356705] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356711] pxa3xx-nand f10d0000.flash: drain_fifo():687
> [   37.356716] pxa3xx-nand f10d0000.flash: drain_fifo():702
> [   37.356721] pxa3xx-nand f10d0000.flash: drain_fifo():672
> [   37.356725] pxa3xx-nand f10d0000.flash: drain_fifo():677
> [   37.356728] pxa3xx-nand f10d0000.flash: drain_fifo():702
> [   37.356734] pxa3xx-nand f10d0000.flash:
> pxa3xx_nand_irq_thread():807 nand_writel(0x6, 0x0014)
> [   37.560189] pxa3xx-nand f10d0000.flash: Wait time out!!!
> [   37.565521] pxa3xx-nand f10d0000.flash: pxa3xx_nand_stop():636 
> nand_readl(0x0000) = 0x91078000
> 

I had a look at the traces you provided, but I could not find a
plausible explanation for the timeouts.

As you may know, I am actively working on a new interface in the NAND
core called ->exec_op() (see [1] and [2]) and the first driver to
implement this interface is a rework of pxa3xx_nand.c renamed
marvell_nand.c (see [3]).

May I suggest you to test these changes and report me if it fails? I
prepared a branch ready to be tested (just add your own device tree),
available on my Github at [4].

If you have failures, it would be great to enable dynamic debug in the
core (put #define DEBUG before all #includes in
drivers/mtd/nand/nand_core.c) and report on the mailing list what you
get. Otherwise, you may stack this commits on top of your branch, or
wait for 4.16 to be released (hopefully).

Thanks,
Miquèl

[1] https://www.spinics.net/lists/arm-kernel/msg619633.html
[2] http://lists.infradead.org/pipermail/linux-mtd/2017-December/077965.html
[3] http://lists.infradead.org/pipermail/linux-mtd/2017-December/077973.html
[4] https://github.com/miquelraynal/linux/tree/marvell/nand-next/nfc-rework

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-07 20:38                         ` Miquel RAYNAL
@ 2017-12-08  9:04                           ` Sean Nyekjær
  2017-12-08  9:21                             ` Miquel RAYNAL
  0 siblings, 1 reply; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-08  9:04 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi Miquel

> As you may know, I am actively working on a new interface in the NAND
> core called ->exec_op() (see [1] and [2]) and the first driver to
> implement this interface is a rework of pxa3xx_nand.c renamed
> marvell_nand.c (see [3]).
>
> May I suggest you to test these changes and report me if it fails? I
> prepared a branch ready to be tested (just add your own device tree),
> available on my Github at [4].
>
> If you have failures, it would be great to enable dynamic debug in the
> core (put #define DEBUG before all #includes in
> drivers/mtd/nand/nand_core.c) and report on the mailing list what you
> get. Otherwise, you may stack this commits on top of your branch, or
> wait for 4.16 to be released (hopefully).
>
> Thanks,
> Miquèl
>
> [1] https://www.spinics.net/lists/arm-kernel/msg619633.html
> [2] http://lists.infradead.org/pipermail/linux-mtd/2017-December/077965.html
> [3] http://lists.infradead.org/pipermail/linux-mtd/2017-December/077973.html
> [4] https://github.com/miquelraynal/linux/tree/marvell/nand-next/nfc-rework
>
Thanks I didn't know about that :-)

I had a look at it and I have rebased my stuff on top of your branch.
I have edited my devicetree to look like this:
&nand_controller {
     status = "okay";
     pinctrl-names = "default";
     pinctrl-0 = <&nand_pins>, <&nand_rb>;

     nand@0 {
         reg = <0>;
         label = "pxa3xx_nand-0";
         marvell,rb = <0>;
         marvell,nand-keep-config;
         nand-on-flash-bbt;
         nand-ecc-strength = <4>;
         nand-ecc-step-size = <512>;
     };
};

It produces a lot of bad eraseblocks entrys
[    2.693343] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
[    2.699717] nand: Micron MT29F2G08ABAEAH4
[    2.703772] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, 
OOB size: 64
[    2.714286] Bad block table not found for chip 0
[    2.721509] Bad block table not found for chip 0
[    2.726139] Scanning device for bad blocks
[    2.730583] Bad eraseblock 0 at 0x000000000000
[    2.735365] Bad eraseblock 1 at 0x000000020000
[    2.740145] Bad eraseblock 2 at 0x000000040000
[    2.744934] Bad eraseblock 3 at 0x000000060000
[    2.749714] Bad eraseblock 4 at 0x000000080000

Is my devicetree correct?

Br
/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-08  9:04                           ` Sean Nyekjær
@ 2017-12-08  9:21                             ` Miquel RAYNAL
  2017-12-11  8:25                               ` Sean Nyekjær
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-08  9:21 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi Sean,

> > As you may know, I am actively working on a new interface in the
> > NAND core called ->exec_op() (see [1] and [2]) and the first driver
> > to implement this interface is a rework of pxa3xx_nand.c renamed
> > marvell_nand.c (see [3]).
> >
> > May I suggest you to test these changes and report me if it fails? I
> > prepared a branch ready to be tested (just add your own device
> > tree), available on my Github at [4].
> >
> > If you have failures, it would be great to enable dynamic debug in
> > the core (put #define DEBUG before all #includes in
> > drivers/mtd/nand/nand_core.c) and report on the mailing list what
> > you get. Otherwise, you may stack this commits on top of your
> > branch, or wait for 4.16 to be released (hopefully).
> >
> > Thanks,
> > Miquèl
> >
> > [1] https://www.spinics.net/lists/arm-kernel/msg619633.html
> > [2]
> > http://lists.infradead.org/pipermail/linux-mtd/2017-December/077965.html
> > [3]
> > http://lists.infradead.org/pipermail/linux-mtd/2017-December/077973.html
> > [4]
> > https://github.com/miquelraynal/linux/tree/marvell/nand-next/nfc-rework 
> Thanks I didn't know about that :-)
> 
> I had a look at it and I have rebased my stuff on top of your branch.
> I have edited my devicetree to look like this:
> &nand_controller {
>      status = "okay";
>      pinctrl-names = "default";
>      pinctrl-0 = <&nand_pins>, <&nand_rb>;
> 
>      nand@0 {
>          reg = <0>;
>          label = "pxa3xx_nand-0";
>          marvell,rb = <0>;
>          marvell,nand-keep-config;
>          nand-on-flash-bbt;
>          nand-ecc-strength = <4>;
>          nand-ecc-step-size = <512>;
>      };
> };
> 
> It produces a lot of bad eraseblocks entrys
> [    2.693343] nand: device found, Manufacturer ID: 0x2c, Chip ID:
> 0xda [    2.699717] nand: Micron MT29F2G08ABAEAH4
> [    2.703772] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
> 2048, OOB size: 64
> [    2.714286] Bad block table not found for chip 0
> [    2.721509] Bad block table not found for chip 0
> [    2.726139] Scanning device for bad blocks
> [    2.730583] Bad eraseblock 0 at 0x000000000000
> [    2.735365] Bad eraseblock 1 at 0x000000020000
> [    2.740145] Bad eraseblock 2 at 0x000000040000
> [    2.744934] Bad eraseblock 3 at 0x000000060000
> [    2.749714] Bad eraseblock 4 at 0x000000080000
> 
> Is my devicetree correct?

It depends:
  - Did you already use bad block tables before ?
  - Is your bootloader using 4b/512B ECC strength ?

Besides:

  - What filesystem are you booting? Is it UBIFS or JFFS2 or
something else?
  - Did you show the 5 first bad eraseblocks only or all of them?
  - Do you have good blocks ?
  - Can you make use of the NAND chip after?

Thanks,
Miquèl

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-11-28 13:02 ` Miquel RAYNAL
  2017-11-28 13:12   ` Sean Nyekjær
@ 2017-12-09 23:04   ` Ezequiel Garcia
  1 sibling, 0 replies; 85+ messages in thread
From: Ezequiel Garcia @ 2017-12-09 23:04 UTC (permalink / raw)
  To: Miquel RAYNAL, Sean Nyekjær
  Cc: linux-mtd, Kasper Revsbech (KREV), Ezequiel Garcia

Hi Sean,

On 28 November 2017 at 10:02, Miquel RAYNAL
<miquel.raynal@free-electrons.com> wrote:
> Hi Sean,
>
>> I'm currently in the process of doing bringup on a custom armada 38x
>> board. During the firsts boots of the Linux kernel we saw that the
>> NAND driver throws a lot of timeout messages.
>>
>> Like this:
>> [ 28.321054] pxa3xx-nand f10d0000.flash: Wait time out!!!
>> [ 28.521054] pxa3xx-nand f10d0000.flash: Wait time out!!!
>> [ 28.721054] pxa3xx-nand f10d0000.flash: Wait time out!!!
>
> Could you paste the entire dmesg please ?
>
> Also, what kernel are you using ?
>
>>
>> That lead me to investigate the issue and found this thread (quite
>> old): https://www.spinics.net/lists/arm-kernel/msg488581.html
>>
>> In the thread some is describing a possible race condition when the
>> NAND framework is scanning for bad blocks.
>
> Not sure this is still relevant, but, who knows.
>

As far as I can recall, there isn't any possible race condition.
The pxa3xx-nand driver should be stable.

See: https://www.spinics.net/lists/arm-kernel/msg476955.html,
where I explain this.

The timeout described by that thread was caused by not using
CONFIG_PREEMPT. Just like I have described on that thread,
not using a preemptable kernel increases latency, causing
issues on drivers that are not prepared for it.

You can find the analysis of that particular timeout here:

https://www.spinics.net/lists/arm-kernel/msg487956.html

BTW, you need a very good, a *very* good, reason
not to use CONFIG_PREEMPT.
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-11-28 13:30     ` Miquel RAYNAL
  2017-11-28 13:42       ` Sean Nyekjær
@ 2017-12-09 23:18       ` Ezequiel Garcia
  2017-12-10 14:17         ` Miquel RAYNAL
  1 sibling, 1 reply; 85+ messages in thread
From: Ezequiel Garcia @ 2017-12-09 23:18 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: Sean Nyekjær, linux-mtd, Kasper Revsbech (KREV), Ezequiel Garcia

On 28 November 2017 at 10:30, Miquel RAYNAL
<miquel.raynal@free-electrons.com> wrote:
> Hi Sean,
>
>
>> > Also, what kernel are you using ?
>> 4.14.0 :-)
>
> Good !
>
>> [    2.288684] pxa3xx-nand f10d0000.flash: This platform can't do DMA
>> on this device
>
> FYI, this is normal, the NAND controller does not have any DMA feature
> on Armada 38x (NFCv2).
>
>> [    2.296924] nand: device found, Manufacturer ID: 0x2c, Chip ID:
>> 0xda [    2.303311] nand: Micron MT29F2G08ABAEAH4
>> [    2.307334] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
>> 2048, OOB size: 64
>> [    2.314939] pxa3xx-nand f10d0000.flash: ECC strength 16, ECC step
>> size 2048
>
> In theory, Marvell NAND flash controller does support 16-bit strength
> per 512 bytes over 2048 bytes pages. However, this controller driver
> (pxa3xx_nand) does not. See [1] for the supported configurations.
>

Why do you say the driver does not support it?

It's automatically selecting this:

        /*
         * Required ECC: 4-bit correction per 512 bytes
         * Select: 16-bit correction per 2048 bytes
         */
        } else if (strength == 4 && ecc_stepsize == 512 && page_size == 2048) {
                info->ecc_bch = 1;
                info->chunk_size = 2048;
                info->spare_size = 32;
                info->ecc_size = 32;
                ecc->mode = NAND_ECC_HW;
                ecc->size = info->chunk_size;
                ecc->layout = &ecc_layout_2KB_bch4bit;
                ecc->strength = 16;

Otherwise, you would have seen the "ECC strength ... at page size ...
is not supported"

> The ECC strength shown here is probably the best to use with this type
> of NAND device but I suggest you try with 4b/512B by using these two
> properties like in [2]:
>
>         nand-ecc-strength = <4>;
>         nand-ecc-step-size = <512>;
>
>
> Thanks,
> Miquèl
>
> [1]
> http://elixir.free-electrons.com/linux/v4.14/source/drivers/mtd/nand/pxa3xx_nand.c#L1575
>
> [2]
> http://elixir.free-electrons.com/linux/v4.14/source/arch/arm/boot/dts/armada-385-db-ap.dts#L172
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/



-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-11-28  9:12 [BUG] pxa3xx: wait time out when scanning for bb Sean Nyekjær
  2017-11-28 13:02 ` Miquel RAYNAL
@ 2017-12-09 23:22 ` Ezequiel Garcia
  2017-12-09 23:24   ` Ezequiel Garcia
  1 sibling, 1 reply; 85+ messages in thread
From: Ezequiel Garcia @ 2017-12-09 23:22 UTC (permalink / raw)
  To: Sean Nyekjær; +Cc: linux-mtd, Kasper Revsbech (KREV), Miquèl Raynal

On 28 November 2017 at 06:12, Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:
> Hi Ezequiel
>
> I'm currently in the process of doing bringup on a custom armada 38x board.
> During the firsts boots of the Linux kernel we saw that the NAND driver
> throws a lot of timeout messages.
>
> Like this:
> [ 28.321054] pxa3xx-nand f10d0000.flash: Wait time out!!!
> [ 28.521054] pxa3xx-nand f10d0000.flash: Wait time out!!!
> [ 28.721054] pxa3xx-nand f10d0000.flash: Wait time out!!!
>
> That lead me to investigate the issue and found this thread (quite old):
> https://www.spinics.net/lists/arm-kernel/msg488581.html
>
> In the thread some is describing a possible race condition when the NAND
> framework is scanning for bad blocks.
> 1. I tried enabling PREEMPT with no success.
> 2. I tried with commenting out the bad block scanning function, with success
> but not very useful :-)
> 3. I enabled the BBT function in uboot and the kernel, and that apparently
> fixes the problem.

Which means you were not using the BBT. Any idea why?
Storing bad-block information in the NAND block itself,
is a bad idea. I suggest you use BBT.

To be frank, I can't recall if the driver supported OOB read/writes
in all modes. It should, judging from the code, but maybe
there is a bug somewhere.

In any case, most of the OOB is used for ECC. There are
some nice notes about it here [1]
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-09 23:22 ` Ezequiel Garcia
@ 2017-12-09 23:24   ` Ezequiel Garcia
  0 siblings, 0 replies; 85+ messages in thread
From: Ezequiel Garcia @ 2017-12-09 23:24 UTC (permalink / raw)
  To: Sean Nyekjær; +Cc: linux-mtd, Kasper Revsbech (KREV), Miquèl Raynal

On 9 December 2017 at 20:22, Ezequiel Garcia
<ezequiel@vanguardiasur.com.ar> wrote:
> On 28 November 2017 at 06:12, Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:
>> Hi Ezequiel
>>
>> I'm currently in the process of doing bringup on a custom armada 38x board.
>> During the firsts boots of the Linux kernel we saw that the NAND driver
>> throws a lot of timeout messages.
>>
>> Like this:
>> [ 28.321054] pxa3xx-nand f10d0000.flash: Wait time out!!!
>> [ 28.521054] pxa3xx-nand f10d0000.flash: Wait time out!!!
>> [ 28.721054] pxa3xx-nand f10d0000.flash: Wait time out!!!
>>
>> That lead me to investigate the issue and found this thread (quite old):
>> https://www.spinics.net/lists/arm-kernel/msg488581.html
>>
>> In the thread some is describing a possible race condition when the NAND
>> framework is scanning for bad blocks.
>> 1. I tried enabling PREEMPT with no success.
>> 2. I tried with commenting out the bad block scanning function, with success
>> but not very useful :-)
>> 3. I enabled the BBT function in uboot and the kernel, and that apparently
>> fixes the problem.
>
> Which means you were not using the BBT. Any idea why?
> Storing bad-block information in the NAND block itself,
> is a bad idea. I suggest you use BBT.
>
> To be frank, I can't recall if the driver supported OOB read/writes
> in all modes. It should, judging from the code, but maybe
> there is a bug somewhere.
>
> In any case, most of the OOB is used for ECC. There are
> some nice notes about it here [1]

like I was saying...

some nice notes about it here [1].

Be aware that you need your bootloader and kernel to have
matching information about the BBT.

So, you say that enabling the BBT fixes the issue, so: fixed? :-)

[1] Documentation/mtd/nand/pxa3xx-nand.txt
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-09 23:18       ` Ezequiel Garcia
@ 2017-12-10 14:17         ` Miquel RAYNAL
  2017-12-11 12:30           ` Ezequiel Garcia
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-10 14:17 UTC (permalink / raw)
  To: Ezequiel Garcia
  Cc: Sean Nyekjær, linux-mtd, Kasper Revsbech (KREV), Ezequiel Garcia

Hi Ezequiel,

> >> [    2.296924] nand: device found, Manufacturer ID: 0x2c, Chip ID:
> >> 0xda [    2.303311] nand: Micron MT29F2G08ABAEAH4
> >> [    2.307334] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
> >> 2048, OOB size: 64
> >> [    2.314939] pxa3xx-nand f10d0000.flash: ECC strength 16, ECC
> >> step size 2048  
> >
> > In theory, Marvell NAND flash controller does support 16-bit
> > strength per 512 bytes over 2048 bytes pages. However, this
> > controller driver (pxa3xx_nand) does not. See [1] for the supported
> > configurations. 
> 
> Why do you say the driver does not support it?

My reading of the trace was incomplete as it is mentioned that the
16-bit correction applies on 2kiB chunks (a full page) while I was
referring to 512 bytes chunks.

Protecting 2kiB pages with BCH algorithm may prevent the flip of up to
16 bits per page, which may also be seen as 4 bits per 512 bytes.
Asking for 16-bit strength for 512 bytes (configuration I was referring
to) is supported by the controller but simply not implemented.

However, below code setting up ecc->strength to 16 while ecc_stepsize is
512 is, IMHO, wrong.

> 
> It's automatically selecting this:
> 
>         /*
>          * Required ECC: 4-bit correction per 512 bytes
>          * Select: 16-bit correction per 2048 bytes
>          */
>         } else if (strength == 4 && ecc_stepsize == 512 && page_size
> == 2048) { info->ecc_bch = 1;
>                 info->chunk_size = 2048;
>                 info->spare_size = 32;
>                 info->ecc_size = 32;
>                 ecc->mode = NAND_ECC_HW;
>                 ecc->size = info->chunk_size;
>                 ecc->layout = &ecc_layout_2KB_bch4bit;
>                 ecc->strength = 16;
> 
> Otherwise, you would have seen the "ECC strength ... at page size ...
> is not supported"
> 
> > The ECC strength shown here is probably the best to use with this
> > type of NAND device but I suggest you try with 4b/512B by using
> > these two properties like in [2]:
> >
> >         nand-ecc-strength = <4>;
> >         nand-ecc-step-size = <512>;
> >
> >
> > Thanks,
> > Miquèl
> >
> > [1]
> > http://elixir.free-electrons.com/linux/v4.14/source/drivers/mtd/nand/pxa3xx_nand.c#L1575
> >
> > [2]
> > http://elixir.free-electrons.com/linux/v4.14/source/arch/arm/boot/dts/armada-385-db-ap.dts#L172
> >
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/  
> 
> 
> 



-- 
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-08  9:21                             ` Miquel RAYNAL
@ 2017-12-11  8:25                               ` Sean Nyekjær
  2017-12-11  8:45                                 ` Sean Nyekjær
  2017-12-11  9:53                                 ` Miquel RAYNAL
  0 siblings, 2 replies; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-11  8:25 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi Miquel,
> Hi Sean,
>
>> Thanks I didn't know about that :-)
>>
>> I had a look at it and I have rebased my stuff on top of your branch.
>> I have edited my devicetree to look like this:
>> &nand_controller {
>>       status = "okay";
>>       pinctrl-names = "default";
>>       pinctrl-0 = <&nand_pins>, <&nand_rb>;
>>
>>       nand@0 {
>>           reg = <0>;
>>           label = "pxa3xx_nand-0";
>>           marvell,rb = <0>;
>>           marvell,nand-keep-config;
>>           nand-on-flash-bbt;
>>           nand-ecc-strength = <4>;
>>           nand-ecc-step-size = <512>;
>>       };
>> };
>>
>> It produces a lot of bad eraseblocks entrys
>> [    2.693343] nand: device found, Manufacturer ID: 0x2c, Chip ID:
>> 0xda [    2.699717] nand: Micron MT29F2G08ABAEAH4
>> [    2.703772] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
>> 2048, OOB size: 64
>> [    2.714286] Bad block table not found for chip 0
>> [    2.721509] Bad block table not found for chip 0
>> [    2.726139] Scanning device for bad blocks
>> [    2.730583] Bad eraseblock 0 at 0x000000000000
>> [    2.735365] Bad eraseblock 1 at 0x000000020000
>> [    2.740145] Bad eraseblock 2 at 0x000000040000
>> [    2.744934] Bad eraseblock 3 at 0x000000060000
>> [    2.749714] Bad eraseblock 4 at 0x000000080000
>>
>> Is my devicetree correct?
> It depends:
>    - Did you already use bad block tables before ?
Yes because if I don't i would get the timeouts described in this thread :-)
>    - Is your bootloader using 4b/512B ECC strength ?
strength 4, ecc_stepsize 512, page_size 2048 but the uboot driver sets 
it to strength 16, ecc_stepsize 512, page_size 2048,
just like the current pxa3xx driver in the kernel does.
>
> Besides:
>
>    - What filesystem are you booting? Is it UBIFS or JFFS2 or
> something else?
UBI
>    - Did you show the 5 first bad eraseblocks only or all of them?
It continues to count to:
Bad eraseblock 2047 at 0x00000ffe0000
>    - Do you have good blocks ?
No
>    - Can you make use of the NAND chip after?
No

Correct me if i'm wrong, but i can't find anywhere the 
nand-ecc-step-size is read by the new nand driver?

/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-11  8:25                               ` Sean Nyekjær
@ 2017-12-11  8:45                                 ` Sean Nyekjær
  2017-12-11  9:53                                 ` Miquel RAYNAL
  1 sibling, 0 replies; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-11  8:45 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi Miquel,
>>>
>>> It produces a lot of bad eraseblocks entrys
>>> [    2.693343] nand: device found, Manufacturer ID: 0x2c, Chip ID:
>>> 0xda [    2.699717] nand: Micron MT29F2G08ABAEAH4
>>> [    2.703772] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
>>> 2048, OOB size: 64
>>> [    2.714286] Bad block table not found for chip 0
>>> [    2.721509] Bad block table not found for chip 0
>>> [    2.726139] Scanning device for bad blocks
>>> [    2.730583] Bad eraseblock 0 at 0x000000000000
>>> [    2.735365] Bad eraseblock 1 at 0x000000020000
>>> [    2.740145] Bad eraseblock 2 at 0x000000040000
>>> [    2.744934] Bad eraseblock 3 at 0x000000060000
>>> [    2.749714] Bad eraseblock 4 at 0x000000080000
>>>
Some more tracing, boot continues with this:
[   12.939411] marvell-nfc f10d0000.nand-controller: NDCB0: 0x300d3000
[   12.939411] NDCB1: 0xff400000
[   12.939411] NDCB2: 0x00000001
[   12.939411] NDCB3: 0x00000820
[   12.939682] marvell-nfc f10d0000.nand-controller: NDCB0: 0x100ae005
[   12.939682] NDCB1: 0x00000820
[   12.939682] NDCB2: 0x00000000
[   12.939682] NDCB3: 0x00000020
[   12.939731] Bad eraseblock 2045 at 0x00000ffa0000
[   12.944462] marvell-nfc f10d0000.nand-controller: NDCB0: 0x300d3000
[   12.944462] NDCB1: 0xff800000
[   12.944462] NDCB2: 0x00000001
[   12.944462] NDCB3: 0x00000820
[   12.944731] marvell-nfc f10d0000.nand-controller: NDCB0: 0x100ae005
[   12.944731] NDCB1: 0x00000820
[   12.944731] NDCB2: 0x00000000
[   12.944731] NDCB3: 0x00000020
[   12.944781] Bad eraseblock 2046 at 0x00000ffc0000
[   12.949503] marvell-nfc f10d0000.nand-controller: NDCB0: 0x300d3000
[   12.949503] NDCB1: 0xffc00000
[   12.949503] NDCB2: 0x00000001
[   12.949503] NDCB3: 0x00000820
[   12.949771] marvell-nfc f10d0000.nand-controller: NDCB0: 0x100ae005
[   12.949771] NDCB1: 0x00000820
[   12.949771] NDCB2: 0x00000000
[   12.949771] NDCB3: 0x00000020
[   12.949821] Bad eraseblock 2047 at 0x00000ffe0000
[   12.954547] No space left to write bad block table
[   12.959353] nand_bbt: error while writing bad block table -28
[   12.965126] marvell-nfc f10d0000.nand-controller: nand_scan_tail 
failed: -28
[   12.972244] marvell-nfc: probe of f10d0000.nand-controller failed 
with error -28

/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-11  8:25                               ` Sean Nyekjær
  2017-12-11  8:45                                 ` Sean Nyekjær
@ 2017-12-11  9:53                                 ` Miquel RAYNAL
  2017-12-11 10:20                                   ` Sean Nyekjær
  1 sibling, 1 reply; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-11  9:53 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi Sean,


> >> I had a look at it and I have rebased my stuff on top of your
> >> branch. I have edited my devicetree to look like this:
> >> &nand_controller {
> >>       status = "okay";
> >>       pinctrl-names = "default";
> >>       pinctrl-0 = <&nand_pins>, <&nand_rb>;
> >>
> >>       nand@0 {
> >>           reg = <0>;
> >>           label = "pxa3xx_nand-0";
> >>           marvell,rb = <0>;
> >>           marvell,nand-keep-config;
> >>           nand-on-flash-bbt;
> >>           nand-ecc-strength = <4>;
> >>           nand-ecc-step-size = <512>;
> >>       };
> >> };
> >>
> >> It produces a lot of bad eraseblocks entrys
> >> [    2.693343] nand: device found, Manufacturer ID: 0x2c, Chip ID:
> >> 0xda [    2.699717] nand: Micron MT29F2G08ABAEAH4
> >> [    2.703772] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
> >> 2048, OOB size: 64
> >> [    2.714286] Bad block table not found for chip 0
> >> [    2.721509] Bad block table not found for chip 0
> >> [    2.726139] Scanning device for bad blocks
> >> [    2.730583] Bad eraseblock 0 at 0x000000000000
> >> [    2.735365] Bad eraseblock 1 at 0x000000020000
> >> [    2.740145] Bad eraseblock 2 at 0x000000040000
> >> [    2.744934] Bad eraseblock 3 at 0x000000060000
> >> [    2.749714] Bad eraseblock 4 at 0x000000080000
> >>
> >> Is my devicetree correct?  
> > It depends:
> >    - Did you already use bad block tables before ?  
> Yes because if I don't i would get the timeouts described in this
> thread :-)

Actually, if you look carefully to the trace behind, you are not using
the same bad block table with the bootloader ("Bad block table not
found for chip 0") so the core then reads the OOB area of every first
page for each block and looks at the first OOB bytes for the bad block
markers. If there was data there, the block will be declared as bad.

Can you please check that by using the configuration that actually
boots and use nanddump in raw mode with the OOB area (options -n and -o)
to show us the content of the first page of any block of the last NAND
MTD device?


> >    - Is your bootloader using 4b/512B ECC strength ?  
> strength 4, ecc_stepsize 512, page_size 2048 but the uboot driver
> sets it to strength 16, ecc_stepsize 512, page_size 2048,
> just like the current pxa3xx driver in the kernel does.
> >
> > Besides:
> >
> >    - What filesystem are you booting? Is it UBIFS or JFFS2 or
> > something else?  
> UBI
> >    - Did you show the 5 first bad eraseblocks only or all of them?  
> It continues to count to:
> Bad eraseblock 2047 at 0x00000ffe0000
> >    - Do you have good blocks ?  
> No
> >    - Can you make use of the NAND chip after?  
> No
> 
> Correct me if i'm wrong, but i can't find anywhere the 
> nand-ecc-step-size is read by the new nand driver?

The core does (nand_scan_tail -> nand_dt_init ->
of_get_nand_ecc_step_size).


Thanks,
Miquèl

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-11  9:53                                 ` Miquel RAYNAL
@ 2017-12-11 10:20                                   ` Sean Nyekjær
  2017-12-11 11:35                                     ` Sean Nyekjær
  2017-12-11 20:11                                     ` Miquel RAYNAL
  0 siblings, 2 replies; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-11 10:20 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi Miquel,
> Actually, if you look carefully to the trace behind, you are not using
> the same bad block table with the bootloader ("Bad block table not
> found for chip 0") so the core then reads the OOB area of every first
> page for each block and looks at the first OOB bytes for the bad block
> markers. If there was data there, the block will be declared as bad.
With the new NFC driver, is the bad block table located elsewhere?
I have not done any changes to my bootloader when i did the switch to 
the new driver,
so i guess it should work as before.
> Can you please check that by using the configuration that actually
> boots and use nanddump in raw mode with the OOB area (options -n and -o)
> to show us the content of the first page of any block of the last NAND
> MTD device?
>
>
Will do

/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-11 10:20                                   ` Sean Nyekjær
@ 2017-12-11 11:35                                     ` Sean Nyekjær
  2017-12-11 13:22                                       ` Sean Nyekjær
  2017-12-11 20:11                                     ` Miquel RAYNAL
  1 sibling, 1 reply; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-11 11:35 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi Miquel,
>> Actually, if you look carefully to the trace behind, you are not using
>> the same bad block table with the bootloader ("Bad block table not
>> found for chip 0") so the core then reads the OOB area of every first
>> page for each block and looks at the first OOB bytes for the bad block
>> markers. If there was data there, the block will be declared as bad.
> With the new NFC driver, is the bad block table located elsewhere?
> I have not done any changes to my bootloader when i did the switch to 
> the new driver,
> so i guess it should work as before.
>> Can you please check that by using the configuration that actually
>> boots and use nanddump in raw mode with the OOB area (options -n and -o)
>> to show us the content of the first page of any block of the last NAND
>> MTD device?
>>
>>
> Will do
>
Dumped from uboot:
=> nand dump.oob 0xffc0000
Page 0ffc0000 dump:
OOB:
         ff ff ff ff ff ff ff ff
         31 74 62 42 56 4d 01 ff
         ff ff ff ff ff ff ff ff
         ff ff ff ff ff ff ff ff
         ff ff ff ff ff ff ff ff
         ff ff ff ff ff ff ff ff
         ff ff ff ff ff ff ff ff
         ff ff ff ff ff ff ff ff
=> nand dump.oob 0xffe0000
Page 0ffe0000 dump:
OOB:
         ff ff ff ff ff ff ff ff
         4d 56 42 62 74 30 01 ff
         ff ff ff ff ff ff ff ff
         ff ff ff ff ff ff ff ff
         ff ff ff ff ff ff ff ff
         ff ff ff ff ff ff ff ff
         ff ff ff ff ff ff ff ff
         ff ff ff ff ff ff ff ff

I have tried to dump some random pages, and they all contain 0xFF's.
I'll try to trace what the NFC driver is reading from the OOBs.

/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-10 14:17         ` Miquel RAYNAL
@ 2017-12-11 12:30           ` Ezequiel Garcia
  2017-12-11 13:13             ` Miquel RAYNAL
       [not found]             ` <CAL92e2W7fLjVOWFgH2PpRLRP7Tf5L1vta0jduWm+bTVm647MNQ@mail.gmail.com>
  0 siblings, 2 replies; 85+ messages in thread
From: Ezequiel Garcia @ 2017-12-11 12:30 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: Sean Nyekjær, linux-mtd, Kasper Revsbech (KREV), Ezequiel Garcia

On 10 December 2017 at 11:17, Miquel RAYNAL
<miquel.raynal@free-electrons.com> wrote:
> Hi Ezequiel,
>
>> >> [    2.296924] nand: device found, Manufacturer ID: 0x2c, Chip ID:
>> >> 0xda [    2.303311] nand: Micron MT29F2G08ABAEAH4
>> >> [    2.307334] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
>> >> 2048, OOB size: 64
>> >> [    2.314939] pxa3xx-nand f10d0000.flash: ECC strength 16, ECC
>> >> step size 2048
>> >
>> > In theory, Marvell NAND flash controller does support 16-bit
>> > strength per 512 bytes over 2048 bytes pages. However, this
>> > controller driver (pxa3xx_nand) does not. See [1] for the supported
>> > configurations.
>>
>> Why do you say the driver does not support it?
>
> My reading of the trace was incomplete as it is mentioned that the
> 16-bit correction applies on 2kiB chunks (a full page) while I was
> referring to 512 bytes chunks.
>
> Protecting 2kiB pages with BCH algorithm may prevent the flip of up to
> 16 bits per page, which may also be seen as 4 bits per 512 bytes.
> Asking for 16-bit strength for 512 bytes (configuration I was referring
> to) is supported by the controller but simply not implemented.
>
> However, below code setting up ecc->strength to 16 while ecc_stepsize is
> 512 is, IMHO, wrong.
>

If you feel there's anything wrong and worth changing in the current driver,
please submit a patch.

Thanks,
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-11 12:30           ` Ezequiel Garcia
@ 2017-12-11 13:13             ` Miquel RAYNAL
  2017-12-11 16:08               ` Ezequiel Garcia
       [not found]             ` <CAL92e2W7fLjVOWFgH2PpRLRP7Tf5L1vta0jduWm+bTVm647MNQ@mail.gmail.com>
  1 sibling, 1 reply; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-11 13:13 UTC (permalink / raw)
  To: Ezequiel Garcia
  Cc: Sean Nyekjær, linux-mtd, Kasper Revsbech (KREV), Ezequiel Garcia

On Mon, 11 Dec 2017 09:30:53 -0300
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> wrote:

> On 10 December 2017 at 11:17, Miquel RAYNAL
> <miquel.raynal@free-electrons.com> wrote:
> > Hi Ezequiel,
> >  
> >> >> [    2.296924] nand: device found, Manufacturer ID: 0x2c, Chip
> >> >> ID: 0xda [    2.303311] nand: Micron MT29F2G08ABAEAH4
> >> >> [    2.307334] nand: 256 MiB, SLC, erase size: 128 KiB, page
> >> >> size: 2048, OOB size: 64
> >> >> [    2.314939] pxa3xx-nand f10d0000.flash: ECC strength 16, ECC
> >> >> step size 2048  
> >> >
> >> > In theory, Marvell NAND flash controller does support 16-bit
> >> > strength per 512 bytes over 2048 bytes pages. However, this
> >> > controller driver (pxa3xx_nand) does not. See [1] for the
> >> > supported configurations.  
> >>
> >> Why do you say the driver does not support it?  
> >
> > My reading of the trace was incomplete as it is mentioned that the
> > 16-bit correction applies on 2kiB chunks (a full page) while I was
> > referring to 512 bytes chunks.
> >
> > Protecting 2kiB pages with BCH algorithm may prevent the flip of up
> > to 16 bits per page, which may also be seen as 4 bits per 512 bytes.
> > Asking for 16-bit strength for 512 bytes (configuration I was
> > referring to) is supported by the controller but simply not
> > implemented.
> >
> > However, below code setting up ecc->strength to 16 while
> > ecc_stepsize is 512 is, IMHO, wrong.
> >  
> 
> If you feel there's anything wrong and worth changing in the current
> driver, please submit a patch.

Somehow I did it last week, by sending the first version of a rework :)

Thanks,
Miquèl

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-11 11:35                                     ` Sean Nyekjær
@ 2017-12-11 13:22                                       ` Sean Nyekjær
  2017-12-11 14:02                                         ` Miquel RAYNAL
  0 siblings, 1 reply; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-11 13:22 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi Miquel,
>>> Actually, if you look carefully to the trace behind, you are not using
>>> the same bad block table with the bootloader ("Bad block table not
>>> found for chip 0") so the core then reads the OOB area of every first
>>> page for each block and looks at the first OOB bytes for the bad block
>>> markers. If there was data there, the block will be declared as bad.
>> With the new NFC driver, is the bad block table located elsewhere?
>> I have not done any changes to my bootloader when i did the switch to 
>> the new driver,
>> so i guess it should work as before.
>>> Can you please check that by using the configuration that actually
>>> boots and use nanddump in raw mode with the OOB area (options -n and 
>>> -o)
>>> to show us the content of the first page of any block of the last NAND
>>> MTD device?
>>>
>>>
>> Will do
>>
> Dumped from uboot:
> => nand dump.oob 0xffc0000
> Page 0ffc0000 dump:
> OOB:
>         ff ff ff ff ff ff ff ff
>         31 74 62 42 56 4d 01 ff
>         ff ff ff ff ff ff ff ff
>         ff ff ff ff ff ff ff ff
>         ff ff ff ff ff ff ff ff
>         ff ff ff ff ff ff ff ff
>         ff ff ff ff ff ff ff ff
>         ff ff ff ff ff ff ff ff
> => nand dump.oob 0xffe0000
> Page 0ffe0000 dump:
> OOB:
>         ff ff ff ff ff ff ff ff
>         4d 56 42 62 74 30 01 ff
>         ff ff ff ff ff ff ff ff
>         ff ff ff ff ff ff ff ff
>         ff ff ff ff ff ff ff ff
>         ff ff ff ff ff ff ff ff
>         ff ff ff ff ff ff ff ff
>         ff ff ff ff ff ff ff ff
>
> I have tried to dump some random pages, and they all contain 0xFF's.
> I'll try to trace what the NFC driver is reading from the OOBs.
>
What function is called in the marvel_nand.c driver here [1].
 From my tracing i can see:
mtd->_read_oob(mtd, from, ops);
->    marvell_nfc_hw_ecc_bch_read_oob
->        marvell_nfc_hw_ecc_bch_read_page
marvell_nfc_hw_ecc_bch_read_page is returning 0 (bitflips)
But the mtd->_read_oob is returning -74.

Some of the tracing:
[    2.947220] Scanning device for bad blocks
[    2.951334] mtd_read_oob
[    2.953874] marvell_nfc_hw_ecc_bch_read_oob
[    2.958393] marvell_nfc_hw_ecc_bch_read_page: max_bitflips: 0, page 0x0
[    2.965034] marvell_nfc_hw_ecc_bch_read_oob: returns 0
[    2.970194] mtd_read_oob: ret_code -74
[    2.983669] Bad eraseblock 0 at 0x000000000000


[1]: 
https://github.com/miquelraynal/linux/blob/marvell/nand-next/nfc-rework/drivers/mtd/mtdcore.c#L1154

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-11 13:22                                       ` Sean Nyekjær
@ 2017-12-11 14:02                                         ` Miquel RAYNAL
  2017-12-11 14:09                                           ` Miquel RAYNAL
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-11 14:02 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

On Mon, 11 Dec 2017 14:22:18 +0100
Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:

> Hi Miquel,
> >>> Actually, if you look carefully to the trace behind, you are not
> >>> using the same bad block table with the bootloader ("Bad block
> >>> table not found for chip 0") so the core then reads the OOB area
> >>> of every first page for each block and looks at the first OOB
> >>> bytes for the bad block markers. If there was data there, the
> >>> block will be declared as bad.  
> >> With the new NFC driver, is the bad block table located elsewhere?
> >> I have not done any changes to my bootloader when i did the switch
> >> to the new driver,
> >> so i guess it should work as before.  
> >>> Can you please check that by using the configuration that actually
> >>> boots and use nanddump in raw mode with the OOB area (options -n
> >>> and -o)
> >>> to show us the content of the first page of any block of the last
> >>> NAND MTD device?
> >>>
> >>>  
> >> Will do
> >>  
> > Dumped from uboot:  
> > => nand dump.oob 0xffc0000  
> > Page 0ffc0000 dump:
> > OOB:
> >         ff ff ff ff ff ff ff ff
> >         31 74 62 42 56 4d 01 ff
> >         ff ff ff ff ff ff ff ff
> >         ff ff ff ff ff ff ff ff
> >         ff ff ff ff ff ff ff ff
> >         ff ff ff ff ff ff ff ff
> >         ff ff ff ff ff ff ff ff
> >         ff ff ff ff ff ff ff ff  
> > => nand dump.oob 0xffe0000  
> > Page 0ffe0000 dump:
> > OOB:
> >         ff ff ff ff ff ff ff ff
> >         4d 56 42 62 74 30 01 ff
> >         ff ff ff ff ff ff ff ff
> >         ff ff ff ff ff ff ff ff
> >         ff ff ff ff ff ff ff ff
> >         ff ff ff ff ff ff ff ff
> >         ff ff ff ff ff ff ff ff
> >         ff ff ff ff ff ff ff ff
> >
> > I have tried to dump some random pages, and they all contain 0xFF's.
> > I'll try to trace what the NFC driver is reading from the OOBs.
> >  
> What function is called in the marvel_nand.c driver here [1].
>  From my tracing i can see:
> mtd->_read_oob(mtd, from, ops);
> ->    marvell_nfc_hw_ecc_bch_read_oob
> ->        marvell_nfc_hw_ecc_bch_read_page  
> marvell_nfc_hw_ecc_bch_read_page is returning 0 (bitflips)
> But the mtd->_read_oob is returning -74.

This means the hardware detected an ECC error (and the page was not
empty).

> 
> Some of the tracing:
> [    2.947220] Scanning device for bad blocks
> [    2.951334] mtd_read_oob
> [    2.953874] marvell_nfc_hw_ecc_bch_read_oob
> [    2.958393] marvell_nfc_hw_ecc_bch_read_page: max_bitflips: 0,
> page 0x0 [    2.965034] marvell_nfc_hw_ecc_bch_read_oob: returns 0
> [    2.970194] mtd_read_oob: ret_code -74
> [    2.983669] Bad eraseblock 0 at 0x000000000000

This behavior is "normal", it is because the number of failure has
been incremented (probably by marvell_nfc_hw_ecc_correct()).


Can you hack the code right before this line [1] and add:
1/ A dump of both the data buffer and the oob buffer (entirely)
2/ Add a memset(mtd->oob_poi, 0xff, mtd->oobsize) conditionally until
the probe is finished (you may want to add a global boolean value that
changes its state after the nand_scan_tail() call).

Then please do a raw dump with nanddump from Linux.


Also, please try booting without the nand-keep-config property.

Thank you,
Miquèl

[1]
https://github.com/miquelraynal/linux/blob/marvell/nand-next/nfc-rework/drivers/mtd/nand/marvell_nand.c#L1351

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-11 14:02                                         ` Miquel RAYNAL
@ 2017-12-11 14:09                                           ` Miquel RAYNAL
  2017-12-11 14:49                                             ` Boris Brezillon
  2017-12-12  8:44                                             ` Sean Nyekjær
  0 siblings, 2 replies; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-11 14:09 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

On Mon, 11 Dec 2017 15:02:00 +0100
Miquel RAYNAL <miquel.raynal@free-electrons.com> wrote:

> On Mon, 11 Dec 2017 14:22:18 +0100
> Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:
> 
> > Hi Miquel,  
> > >>> Actually, if you look carefully to the trace behind, you are not
> > >>> using the same bad block table with the bootloader ("Bad block
> > >>> table not found for chip 0") so the core then reads the OOB area
> > >>> of every first page for each block and looks at the first OOB
> > >>> bytes for the bad block markers. If there was data there, the
> > >>> block will be declared as bad.    
> > >> With the new NFC driver, is the bad block table located
> > >> elsewhere? I have not done any changes to my bootloader when i
> > >> did the switch to the new driver,
> > >> so i guess it should work as before.    
> > >>> Can you please check that by using the configuration that
> > >>> actually boots and use nanddump in raw mode with the OOB area
> > >>> (options -n and -o)
> > >>> to show us the content of the first page of any block of the
> > >>> last NAND MTD device?
> > >>>
> > >>>    
> > >> Will do
> > >>    
> > > Dumped from uboot:    
> > > => nand dump.oob 0xffc0000    
> > > Page 0ffc0000 dump:
> > > OOB:
> > >         ff ff ff ff ff ff ff ff
> > >         31 74 62 42 56 4d 01 ff
> > >         ff ff ff ff ff ff ff ff
> > >         ff ff ff ff ff ff ff ff
> > >         ff ff ff ff ff ff ff ff
> > >         ff ff ff ff ff ff ff ff
> > >         ff ff ff ff ff ff ff ff
> > >         ff ff ff ff ff ff ff ff    
> > > => nand dump.oob 0xffe0000    
> > > Page 0ffe0000 dump:
> > > OOB:
> > >         ff ff ff ff ff ff ff ff
> > >         4d 56 42 62 74 30 01 ff
> > >         ff ff ff ff ff ff ff ff
> > >         ff ff ff ff ff ff ff ff
> > >         ff ff ff ff ff ff ff ff
> > >         ff ff ff ff ff ff ff ff
> > >         ff ff ff ff ff ff ff ff
> > >         ff ff ff ff ff ff ff ff
> > >
> > > I have tried to dump some random pages, and they all contain
> > > 0xFF's. I'll try to trace what the NFC driver is reading from the
> > > OOBs. 
> > What function is called in the marvel_nand.c driver here [1].
> >  From my tracing i can see:
> > mtd->_read_oob(mtd, from, ops);  
> > ->    marvell_nfc_hw_ecc_bch_read_oob
> > ->        marvell_nfc_hw_ecc_bch_read_page    
> > marvell_nfc_hw_ecc_bch_read_page is returning 0 (bitflips)
> > But the mtd->_read_oob is returning -74.  
> 
> This means the hardware detected an ECC error (and the page was not
> empty).
> 
> > 
> > Some of the tracing:
> > [    2.947220] Scanning device for bad blocks
> > [    2.951334] mtd_read_oob
> > [    2.953874] marvell_nfc_hw_ecc_bch_read_oob
> > [    2.958393] marvell_nfc_hw_ecc_bch_read_page: max_bitflips: 0,
> > page 0x0 [    2.965034] marvell_nfc_hw_ecc_bch_read_oob: returns 0
> > [    2.970194] mtd_read_oob: ret_code -74
> > [    2.983669] Bad eraseblock 0 at 0x000000000000  
> 
> This behavior is "normal", it is because the number of failure has
> been incremented (probably by marvell_nfc_hw_ecc_correct()).
> 
> 
> Can you hack the code right before this line [1] and add:
> 1/ A dump of both the data buffer and the oob buffer (entirely)
> 2/ Add a memset(mtd->oob_poi, 0xff, mtd->oobsize) conditionally until
> the probe is finished (you may want to add a global boolean value that
> changes its state after the nand_scan_tail() call).

Instead of hacking this way, to boot until you get a prompt, you may
add this property to the nand controller node:

nand-ecc-mode = "none";

Then please use nanddump over a programmed page, including the OOB area.


> 
> Then please do a raw dump with nanddump from Linux.
> 
> 
> Also, please try booting without the nand-keep-config property.
> 
> Thank you,
> Miquèl
> 
> [1]
> https://github.com/miquelraynal/linux/blob/marvell/nand-next/nfc-rework/drivers/mtd/nand/marvell_nand.c#L1351



-- 
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-11 14:09                                           ` Miquel RAYNAL
@ 2017-12-11 14:49                                             ` Boris Brezillon
  2017-12-12  8:44                                             ` Sean Nyekjær
  1 sibling, 0 replies; 85+ messages in thread
From: Boris Brezillon @ 2017-12-11 14:49 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: Sean Nyekjær, ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

On Mon, 11 Dec 2017 15:09:29 +0100
Miquel RAYNAL <miquel.raynal@free-electrons.com> wrote:

> On Mon, 11 Dec 2017 15:02:00 +0100
> Miquel RAYNAL <miquel.raynal@free-electrons.com> wrote:
> 
> > On Mon, 11 Dec 2017 14:22:18 +0100
> > Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:
> >   
> > > Hi Miquel,    
> > > >>> Actually, if you look carefully to the trace behind, you are not
> > > >>> using the same bad block table with the bootloader ("Bad block
> > > >>> table not found for chip 0") so the core then reads the OOB area
> > > >>> of every first page for each block and looks at the first OOB
> > > >>> bytes for the bad block markers. If there was data there, the
> > > >>> block will be declared as bad.      
> > > >> With the new NFC driver, is the bad block table located
> > > >> elsewhere? I have not done any changes to my bootloader when i
> > > >> did the switch to the new driver,
> > > >> so i guess it should work as before.      
> > > >>> Can you please check that by using the configuration that
> > > >>> actually boots and use nanddump in raw mode with the OOB area
> > > >>> (options -n and -o)
> > > >>> to show us the content of the first page of any block of the
> > > >>> last NAND MTD device?
> > > >>>
> > > >>>      
> > > >> Will do
> > > >>      
> > > > Dumped from uboot:      
> > > > => nand dump.oob 0xffc0000      
> > > > Page 0ffc0000 dump:
> > > > OOB:
> > > >         ff ff ff ff ff ff ff ff
> > > >         31 74 62 42 56 4d 01 ff
> > > >         ff ff ff ff ff ff ff ff
> > > >         ff ff ff ff ff ff ff ff
> > > >         ff ff ff ff ff ff ff ff
> > > >         ff ff ff ff ff ff ff ff
> > > >         ff ff ff ff ff ff ff ff
> > > >         ff ff ff ff ff ff ff ff      
> > > > => nand dump.oob 0xffe0000      
> > > > Page 0ffe0000 dump:
> > > > OOB:
> > > >         ff ff ff ff ff ff ff ff
> > > >         4d 56 42 62 74 30 01 ff
> > > >         ff ff ff ff ff ff ff ff
> > > >         ff ff ff ff ff ff ff ff
> > > >         ff ff ff ff ff ff ff ff
> > > >         ff ff ff ff ff ff ff ff
> > > >         ff ff ff ff ff ff ff ff
> > > >         ff ff ff ff ff ff ff ff
> > > >
> > > > I have tried to dump some random pages, and they all contain
> > > > 0xFF's. I'll try to trace what the NFC driver is reading from the
> > > > OOBs.   
> > > What function is called in the marvel_nand.c driver here [1].
> > >  From my tracing i can see:
> > > mtd->_read_oob(mtd, from, ops);    
> > > ->    marvell_nfc_hw_ecc_bch_read_oob
> > > ->        marvell_nfc_hw_ecc_bch_read_page      
> > > marvell_nfc_hw_ecc_bch_read_page is returning 0 (bitflips)
> > > But the mtd->_read_oob is returning -74.    
> > 
> > This means the hardware detected an ECC error (and the page was not
> > empty).
> >   
> > > 
> > > Some of the tracing:
> > > [    2.947220] Scanning device for bad blocks
> > > [    2.951334] mtd_read_oob
> > > [    2.953874] marvell_nfc_hw_ecc_bch_read_oob
> > > [    2.958393] marvell_nfc_hw_ecc_bch_read_page: max_bitflips: 0,
> > > page 0x0 [    2.965034] marvell_nfc_hw_ecc_bch_read_oob: returns 0
> > > [    2.970194] mtd_read_oob: ret_code -74
> > > [    2.983669] Bad eraseblock 0 at 0x000000000000    
> > 
> > This behavior is "normal", it is because the number of failure has
> > been incremented (probably by marvell_nfc_hw_ecc_correct()).
> > 
> > 
> > Can you hack the code right before this line [1] and add:
> > 1/ A dump of both the data buffer and the oob buffer (entirely)
> > 2/ Add a memset(mtd->oob_poi, 0xff, mtd->oobsize) conditionally until
> > the probe is finished (you may want to add a global boolean value that
> > changes its state after the nand_scan_tail() call).  
> 
> Instead of hacking this way, to boot until you get a prompt, you may
> add this property to the nand controller node:

I guess you mean the nand node, not the nand-controller node?

> 
> nand-ecc-mode = "none";
> 
> Then please use nanddump over a programmed page, including the OOB area.
> 

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-11 13:13             ` Miquel RAYNAL
@ 2017-12-11 16:08               ` Ezequiel Garcia
  2017-12-11 16:41                 ` Miquel RAYNAL
  0 siblings, 1 reply; 85+ messages in thread
From: Ezequiel Garcia @ 2017-12-11 16:08 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: Sean Nyekjær, linux-mtd, Kasper Revsbech (KREV), Ezequiel Garcia

On 11 December 2017 at 10:13, Miquel RAYNAL
<miquel.raynal@free-electrons.com> wrote:
> On Mon, 11 Dec 2017 09:30:53 -0300
> Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> wrote:
>
>> On 10 December 2017 at 11:17, Miquel RAYNAL
>> <miquel.raynal@free-electrons.com> wrote:
>> > Hi Ezequiel,
>> >
>> >> >> [    2.296924] nand: device found, Manufacturer ID: 0x2c, Chip
>> >> >> ID: 0xda [    2.303311] nand: Micron MT29F2G08ABAEAH4
>> >> >> [    2.307334] nand: 256 MiB, SLC, erase size: 128 KiB, page
>> >> >> size: 2048, OOB size: 64
>> >> >> [    2.314939] pxa3xx-nand f10d0000.flash: ECC strength 16, ECC
>> >> >> step size 2048
>> >> >
>> >> > In theory, Marvell NAND flash controller does support 16-bit
>> >> > strength per 512 bytes over 2048 bytes pages. However, this
>> >> > controller driver (pxa3xx_nand) does not. See [1] for the
>> >> > supported configurations.
>> >>
>> >> Why do you say the driver does not support it?
>> >
>> > My reading of the trace was incomplete as it is mentioned that the
>> > 16-bit correction applies on 2kiB chunks (a full page) while I was
>> > referring to 512 bytes chunks.
>> >
>> > Protecting 2kiB pages with BCH algorithm may prevent the flip of up
>> > to 16 bits per page, which may also be seen as 4 bits per 512 bytes.
>> > Asking for 16-bit strength for 512 bytes (configuration I was
>> > referring to) is supported by the controller but simply not
>> > implemented.
>> >
>> > However, below code setting up ecc->strength to 16 while
>> > ecc_stepsize is 512 is, IMHO, wrong.
>> >
>>
>> If you feel there's anything wrong and worth changing in the current
>> driver, please submit a patch.
>
> Somehow I did it last week, by sending the first version of a rework :)
>

Sure, and I'm happy to see the rework.

However, this driver will still be around, possibly for many years
given vendors using stable kernels.

So, really: if there's anything you think is worth discussing and fixing,
please submit a patch.

Thanks!
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
       [not found]             ` <CAL92e2W7fLjVOWFgH2PpRLRP7Tf5L1vta0jduWm+bTVm647MNQ@mail.gmail.com>
@ 2017-12-11 16:24               ` Ezequiel Garcia
  2017-12-11 16:45                 ` Boris Brezillon
  2017-12-11 21:16                 ` Boris Brezillon
  2017-12-12  6:36               ` Sean Nyekjær
  1 sibling, 2 replies; 85+ messages in thread
From: Ezequiel Garcia @ 2017-12-11 16:24 UTC (permalink / raw)
  To: Greg Cook
  Cc: Miquel RAYNAL, linux-mtd, Kasper Revsbech (KREV),
	Ezequiel Garcia, Sean Nyekjær

Greg,

On 11 December 2017 at 10:18, Greg Cook <greg@morpheus.ws> wrote:
> Sean,
>
> I am not completely up-to-date on this, but everything in your traces reads
> like the same issue I was having on bringup for Armada 385 nand (under 4.9).
> I've been stuck on another project, so I haven't had time to follow up
> further, but I just diffed against linux-stable v4.12 pxa3xx_nand.c and it
> looks like the problem is still there.
>
> As far as I can see, the driver is broken for OOB reads when BCH is enabled
> because the setup in prepare_set_command() results in drain_fifo() not
> reading enough words from the read fifo in the nfc2 IP block.
>

Yes, this sounds just like the bug I was expecting for OOB reads.

> The patch we are using is below. I have the following in my DTS.
> nand-keep-config is commented out because I was having some issues with
> u-boot at the time and it may no longer be relevant:

Probably.

> flash@d0000 {
> status = "okay";
> num-cs = <1>;
> //marvell,nand-keep-config;
> marvell,nand-enable-arbiter;
> nand-on-flash-bbt;
> nand-ecc-strength = <4>;
> nand-ecc-step-size = <512>;
> };
>
> --- /home/user/build/linux-stable/drivers/mtd/nand/pxa3xx_nand.c
> +++
> /home/user/build/beam/openwrt/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/linux-mvebu/linux-4.9.34/drivers/mtd/nand/pxa3xx_nand.c
> @@ -668,7 +669,7 @@
>
>  static void drain_fifo(struct pxa3xx_nand_info *info, void *data, int len)
>  {
> - if (info->ecc_bch) {
> + if (info->use_ecc && info->ecc_bch) {
>   u32 val;
>   int ret;
>
> @@ -1012,7 +1014,11 @@
>
>   if (info->cur_chunk < info->nfullchunks) {
>   info->step_chunk_size = info->chunk_size;
> - info->step_spare_size = info->spare_size;
> + if (info->use_ecc) {
> + info->step_spare_size = info->spare_size;
> + } else {
> + info->step_spare_size = info->spare_size + info->ecc_size;
> + }
>   } else {
>   info->step_chunk_size = info->last_chunk_size;
>   info->step_spare_size = info->last_spare_size;
>

Looks like a decent change.

Boris: do you think this is stable material worth backporting?
In other words, does it make sense to fix it, given the reworked driver?
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-11 16:08               ` Ezequiel Garcia
@ 2017-12-11 16:41                 ` Miquel RAYNAL
  0 siblings, 0 replies; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-11 16:41 UTC (permalink / raw)
  To: Ezequiel Garcia
  Cc: Sean Nyekjær, linux-mtd, Kasper Revsbech (KREV), Ezequiel Garcia

On Mon, 11 Dec 2017 13:08:23 -0300
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> wrote:

> On 11 December 2017 at 10:13, Miquel RAYNAL
> <miquel.raynal@free-electrons.com> wrote:
> > On Mon, 11 Dec 2017 09:30:53 -0300
> > Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> wrote:
> >  
> >> On 10 December 2017 at 11:17, Miquel RAYNAL
> >> <miquel.raynal@free-electrons.com> wrote:  
> >> > Hi Ezequiel,
> >> >  
> >> >> >> [    2.296924] nand: device found, Manufacturer ID: 0x2c,
> >> >> >> Chip ID: 0xda [    2.303311] nand: Micron MT29F2G08ABAEAH4
> >> >> >> [    2.307334] nand: 256 MiB, SLC, erase size: 128 KiB, page
> >> >> >> size: 2048, OOB size: 64
> >> >> >> [    2.314939] pxa3xx-nand f10d0000.flash: ECC strength 16,
> >> >> >> ECC step size 2048  
> >> >> >
> >> >> > In theory, Marvell NAND flash controller does support 16-bit
> >> >> > strength per 512 bytes over 2048 bytes pages. However, this
> >> >> > controller driver (pxa3xx_nand) does not. See [1] for the
> >> >> > supported configurations.  
> >> >>
> >> >> Why do you say the driver does not support it?  
> >> >
> >> > My reading of the trace was incomplete as it is mentioned that
> >> > the 16-bit correction applies on 2kiB chunks (a full page) while
> >> > I was referring to 512 bytes chunks.
> >> >
> >> > Protecting 2kiB pages with BCH algorithm may prevent the flip of
> >> > up to 16 bits per page, which may also be seen as 4 bits per 512
> >> > bytes. Asking for 16-bit strength for 512 bytes (configuration I
> >> > was referring to) is supported by the controller but simply not
> >> > implemented.
> >> >
> >> > However, below code setting up ecc->strength to 16 while
> >> > ecc_stepsize is 512 is, IMHO, wrong.
> >> >  
> >>
> >> If you feel there's anything wrong and worth changing in the
> >> current driver, please submit a patch.  
> >
> > Somehow I did it last week, by sending the first version of a
> > rework :) 
> 
> Sure, and I'm happy to see the rework.

Thanks!

> 
> However, this driver will still be around, possibly for many years
> given vendors using stable kernels.

That's right. I won't hesitate to send patches for stable kernels.

Cheers,
Miquèl

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-11 16:24               ` Ezequiel Garcia
@ 2017-12-11 16:45                 ` Boris Brezillon
  2017-12-11 21:16                 ` Boris Brezillon
  1 sibling, 0 replies; 85+ messages in thread
From: Boris Brezillon @ 2017-12-11 16:45 UTC (permalink / raw)
  To: Ezequiel Garcia
  Cc: Greg Cook, Sean Nyekjær, linux-mtd, Kasper Revsbech (KREV),
	Ezequiel Garcia, Miquel RAYNAL

On Mon, 11 Dec 2017 13:24:56 -0300
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> wrote:

> Greg,
> 
> On 11 December 2017 at 10:18, Greg Cook <greg@morpheus.ws> wrote:
> > Sean,
> >
> > I am not completely up-to-date on this, but everything in your traces reads
> > like the same issue I was having on bringup for Armada 385 nand (under 4.9).
> > I've been stuck on another project, so I haven't had time to follow up
> > further, but I just diffed against linux-stable v4.12 pxa3xx_nand.c and it
> > looks like the problem is still there.
> >
> > As far as I can see, the driver is broken for OOB reads when BCH is enabled
> > because the setup in prepare_set_command() results in drain_fifo() not
> > reading enough words from the read fifo in the nfc2 IP block.
> >  
> 
> Yes, this sounds just like the bug I was expecting for OOB reads.
> 
> > The patch we are using is below. I have the following in my DTS.
> > nand-keep-config is commented out because I was having some issues with
> > u-boot at the time and it may no longer be relevant:  
> 
> Probably.
> 
> > flash@d0000 {
> > status = "okay";
> > num-cs = <1>;
> > //marvell,nand-keep-config;
> > marvell,nand-enable-arbiter;
> > nand-on-flash-bbt;
> > nand-ecc-strength = <4>;
> > nand-ecc-step-size = <512>;
> > };
> >
> > --- /home/user/build/linux-stable/drivers/mtd/nand/pxa3xx_nand.c
> > +++
> > /home/user/build/beam/openwrt/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/linux-mvebu/linux-4.9.34/drivers/mtd/nand/pxa3xx_nand.c
> > @@ -668,7 +669,7 @@
> >
> >  static void drain_fifo(struct pxa3xx_nand_info *info, void *data, int len)
> >  {
> > - if (info->ecc_bch) {
> > + if (info->use_ecc && info->ecc_bch) {
> >   u32 val;
> >   int ret;
> >
> > @@ -1012,7 +1014,11 @@
> >
> >   if (info->cur_chunk < info->nfullchunks) {
> >   info->step_chunk_size = info->chunk_size;
> > - info->step_spare_size = info->spare_size;
> > + if (info->use_ecc) {
> > + info->step_spare_size = info->spare_size;
> > + } else {
> > + info->step_spare_size = info->spare_size + info->ecc_size;
> > + }
> >   } else {
> >   info->step_chunk_size = info->last_chunk_size;
> >   info->step_spare_size = info->last_spare_size;
> >  
> 
> Looks like a decent change.
> 
> Boris: do you think this is stable material worth backporting?
> In other words, does it make sense to fix it, given the reworked driver?

Ye it's always worth fixing existing bugs in stable releases, even if
the driver has been completely rewritten in newer kernels.

I can't tell if the fix is correct though, so I'll let Miquel who has
worked on the driver rework for last couple months answer this
question.
Miquel, is this fix valid?

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-11 10:20                                   ` Sean Nyekjær
  2017-12-11 11:35                                     ` Sean Nyekjær
@ 2017-12-11 20:11                                     ` Miquel RAYNAL
  1 sibling, 0 replies; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-11 20:11 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi Sean,

I don't remember having answered that, forgive me if I am repeating
myself.

On Mon,
11 Dec 2017 11:20:40 +0100 Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:

> Hi Miquel,
> > Actually, if you look carefully to the trace behind, you are not
> > using the same bad block table with the bootloader ("Bad block
> > table not found for chip 0") so the core then reads the OOB area of
> > every first page for each block and looks at the first OOB bytes
> > for the bad block markers. If there was data there, the block will
> > be declared as bad.  
> With the new NFC driver, is the bad block table located elsewhere?
> I have not done any changes to my bootloader when i did the switch to 
> the new driver,
> so i guess it should work as before.

The bad block table should always be located in the first pages of the
last blocks of the NAND chip. The data area contains the information.
Every pair of bits refers to a block. For each pair, b'11 means the
block is good. Otherwise it is marked bad (factory marked bad or became
bad). Multiple pages may be used if there is not enough space in one
page to fit the information about all the blocks. The spare area stores
the pattern that must start at offset 8 (It is "MVBbt0" in the case of
Marvell driver).

So yes, it should work as before. However, we can't really assume that
it actually "worked" before.

> > Can you please check that by using the configuration that actually
> > boots and use nanddump in raw mode with the OOB area (options -n
> > and -o) to show us the content of the first page of any block of
> > the last NAND MTD device?
> >
> >  
> Will do
> 
> /Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-11 16:24               ` Ezequiel Garcia
  2017-12-11 16:45                 ` Boris Brezillon
@ 2017-12-11 21:16                 ` Boris Brezillon
  2017-12-12  6:01                   ` Greg Cook
  1 sibling, 1 reply; 85+ messages in thread
From: Boris Brezillon @ 2017-12-11 21:16 UTC (permalink / raw)
  To: Ezequiel Garcia
  Cc: Greg Cook, Sean Nyekjær, linux-mtd, Kasper Revsbech (KREV),
	Ezequiel Garcia, Miquel RAYNAL

On Mon, 11 Dec 2017 13:24:56 -0300
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> wrote:

> Greg,
> 
> On 11 December 2017 at 10:18, Greg Cook <greg@morpheus.ws> wrote:
> > Sean,
> >
> > I am not completely up-to-date on this, but everything in your traces reads
> > like the same issue I was having on bringup for Armada 385 nand (under 4.9).
> > I've been stuck on another project, so I haven't had time to follow up
> > further, but I just diffed against linux-stable v4.12 pxa3xx_nand.c and it
> > looks like the problem is still there.
> >
> > As far as I can see, the driver is broken for OOB reads when BCH is enabled
> > because the setup in prepare_set_command() results in drain_fifo() not
> > reading enough words from the read fifo in the nfc2 IP block.

May I ask how you you get to this conclusion? What makes you think
there's still unread data in the FIFO?

> >  
> 
> Yes, this sounds just like the bug I was expecting for OOB reads.
> 
> > The patch we are using is below. I have the following in my DTS.
> > nand-keep-config is commented out because I was having some issues with
> > u-boot at the time and it may no longer be relevant:  
> 
> Probably.
> 
> > flash@d0000 {
> > status = "okay";
> > num-cs = <1>;
> > //marvell,nand-keep-config;
> > marvell,nand-enable-arbiter;
> > nand-on-flash-bbt;
> > nand-ecc-strength = <4>;
> > nand-ecc-step-size = <512>;
> > };
> >
> > --- /home/user/build/linux-stable/drivers/mtd/nand/pxa3xx_nand.c
> > +++
> > /home/user/build/beam/openwrt/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/linux-mvebu/linux-4.9.34/drivers/mtd/nand/pxa3xx_nand.c
> > @@ -668,7 +669,7 @@
> >
> >  static void drain_fifo(struct pxa3xx_nand_info *info, void *data, int len)
> >  {
> > - if (info->ecc_bch) {
> > + if (info->use_ecc && info->ecc_bch) {

This one might explain timeouts occurring when you drain the FIFO for
an operation that does not enable the ECC engine (like
READ_PARAM_PAGE).

So this fix is indeed valid, but I'm almost sure it won't fix Sean's
problem.

> >   u32 val;
> >   int ret;
> >
> > @@ -1012,7 +1014,11 @@
> >
> >   if (info->cur_chunk < info->nfullchunks) {
> >   info->step_chunk_size = info->chunk_size;
> > - info->step_spare_size = info->spare_size;
> > + if (info->use_ecc) {
> > + info->step_spare_size = info->spare_size;
> > + } else {
> > + info->step_spare_size = info->spare_size + info->ecc_size;
> > + }

The only case this change would fix is when you try to read/write pages
in raw mode, and I'm pretty sure this driver does not support raw
accesses.

> >   } else {
> >   info->step_chunk_size = info->last_chunk_size;
> >   info->step_spare_size = info->last_spare_size;
> >  
> 
> Looks like a decent change.
> 
> Boris: do you think this is stable material worth backporting?
> In other words, does it make sense to fix it, given the reworked driver?

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-11 21:16                 ` Boris Brezillon
@ 2017-12-12  6:01                   ` Greg Cook
  2017-12-12  7:09                     ` Ezequiel Garcia
  0 siblings, 1 reply; 85+ messages in thread
From: Greg Cook @ 2017-12-12  6:01 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Ezequiel Garcia, Sean Nyekjær, linux-mtd,
	Kasper Revsbech (KREV),
	Ezequiel Garcia, Miquel RAYNAL

On 12 December 2017 at 05:16, Boris Brezillon
<boris.brezillon@free-electrons.com> wrote:
> On Mon, 11 Dec 2017 13:24:56 -0300
> Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> wrote:
>
>> Greg,
>>
>> On 11 December 2017 at 10:18, Greg Cook <greg@morpheus.ws> wrote:
>> > Sean,
>> >
>> > I am not completely up-to-date on this, but everything in your traces reads
>> > like the same issue I was having on bringup for Armada 385 nand (under 4.9).
>> > I've been stuck on another project, so I haven't had time to follow up
>> > further, but I just diffed against linux-stable v4.12 pxa3xx_nand.c and it
>> > looks like the problem is still there.
>> >
>> > As far as I can see, the driver is broken for OOB reads when BCH is enabled
>> > because the setup in prepare_set_command() results in drain_fifo() not
>> > reading enough words from the read fifo in the nfc2 IP block.
>
> May I ask how you you get to this conclusion? What makes you think
> there's still unread data in the FIFO?

Because I added some debug lines to count the number of bytes read and
I could  see handle_data_pio() was reading 2048 bytes, followed by 32
bytes of spare. If you have Marvell MV-S109094-00 REV C handy, you can
see in Table 36 that this is not correct. The correct number of spare
bytes for the NFCv2 IP block is
- 64 bytes when SPARE_EN==1 and ECC_EN==0
- 32 bytes when SPARE_EN==1 and ECC_EN==1

>> >
>>
>> Yes, this sounds just like the bug I was expecting for OOB reads.
>>
>> > The patch we are using is below. I have the following in my DTS.
>> > nand-keep-config is commented out because I was having some issues with
>> > u-boot at the time and it may no longer be relevant:
>>
>> Probably.
>>
>> > flash@d0000 {
>> > status = "okay";
>> > num-cs = <1>;
>> > //marvell,nand-keep-config;
>> > marvell,nand-enable-arbiter;
>> > nand-on-flash-bbt;
>> > nand-ecc-strength = <4>;
>> > nand-ecc-step-size = <512>;
>> > };
>> >
>> > --- /home/user/build/linux-stable/drivers/mtd/nand/pxa3xx_nand.c
>> > +++
>> > /home/user/build/beam/openwrt/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/linux-mvebu/linux-4.9.34/drivers/mtd/nand/pxa3xx_nand.c
>> > @@ -668,7 +669,7 @@
>> >
>> >  static void drain_fifo(struct pxa3xx_nand_info *info, void *data, int len)
>> >  {
>> > - if (info->ecc_bch) {
>> > + if (info->use_ecc && info->ecc_bch) {
>
> This one might explain timeouts occurring when you drain the FIFO for
> an operation that does not enable the ECC engine (like
> READ_PARAM_PAGE).
>
> So this fix is indeed valid, but I'm almost sure it won't fix Sean's
> problem.

>From memory, I don't *think* specific line wasn't causing me any
issues, but I noticed it was not correct because of the way use_ecc
and ecc_bch flags are initialised and then used. As you say, without
this patch, you can get timeouts on non-ECC operations when you have
BCH ECC enabled generally.

>
>> >   u32 val;
>> >   int ret;
>> >
>> > @@ -1012,7 +1014,11 @@
>> >
>> >   if (info->cur_chunk < info->nfullchunks) {
>> >   info->step_chunk_size = info->chunk_size;
>> > - info->step_spare_size = info->spare_size;
>> > + if (info->use_ecc) {
>> > + info->step_spare_size = info->spare_size;
>> > + } else {
>> > + info->step_spare_size = info->spare_size + info->ecc_size;
>> > + }
>
> The only case this change would fix is when you try to read/write pages
> in raw mode, and I'm pretty sure this driver does not support raw
> accesses.

Why do you say it would only affect raw mode? This code is not
specific to raw mode, nor
is the related code in handle_data_pio(), which uses the value of
step_spare_size to drain
the hardware FIFO.

>> >   } else {
>> >   info->step_chunk_size = info->last_chunk_size;
>> >   info->step_spare_size = info->last_spare_size;
>> >
>>
>> Looks like a decent change.
>>
>> Boris: do you think this is stable material worth backporting?
>> In other words, does it make sense to fix it, given the reworked driver?
>

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
       [not found]             ` <CAL92e2W7fLjVOWFgH2PpRLRP7Tf5L1vta0jduWm+bTVm647MNQ@mail.gmail.com>
  2017-12-11 16:24               ` Ezequiel Garcia
@ 2017-12-12  6:36               ` Sean Nyekjær
  2017-12-12  6:50                 ` Ezequiel Garcia
  1 sibling, 1 reply; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-12  6:36 UTC (permalink / raw)
  To: Greg Cook, Ezequiel Garcia
  Cc: Miquel RAYNAL, linux-mtd, Kasper Revsbech (KREV), Ezequiel Garcia

Hi Greg
>
> I am not completely up-to-date on this, but everything in your traces 
> reads like the same issue I was having on bringup for Armada 385 nand 
> (under 4.9). I've been stuck on another project, so I haven't had time 
> to follow up further, but I just diffed against linux-stable v4.12 
> pxa3xx_nand.c and it looks like the problem is still there.
>
> As far as I can see, the driver is broken for OOB reads when BCH is 
> enabled because the setup in prepare_set_command() results in 
> drain_fifo() not reading enough words from the read fifo in the nfc2 
> IP block.
>
> The patch we are using is below. I have the following in my DTS. 
> nand-keep-config is commented out because I was having some issues 
> with u-boot at the time and it may no longer be relevant:
> flash@d0000 {
> status = "okay";
> num-cs = <1>;
> //marvell,nand-keep-config;
> marvell,nand-enable-arbiter;
> nand-on-flash-bbt;
> nand-ecc-strength = <4>;
> nand-ecc-step-size = <512>;
> };
>
> --- /home/user/build/linux-stable/drivers/mtd/nand/pxa3xx_nand.c
> +++ 
> /home/user/build/beam/openwrt/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/linux-mvebu/linux-4.9.34/drivers/mtd/nand/pxa3xx_nand.c
> @@ -668,7 +669,7 @@
>  static void drain_fifo(struct pxa3xx_nand_info *info, void *data, int 
> len)
>  {
> -if (info->ecc_bch) {
> +if (info->use_ecc && info->ecc_bch) {
> u32 val;
> int ret;
> @@ -1012,7 +1014,11 @@
> if (info->cur_chunk < info->nfullchunks) {
> info->step_chunk_size = info->chunk_size;
> -info->step_spare_size = info->spare_size;
> +if (info->use_ecc) {
> +info->step_spare_size = info->spare_size;
> +} else {
> +info->step_spare_size = info->spare_size + info->ecc_size;
> +}
> } else {
> info->step_chunk_size = info->last_chunk_size;
> info->step_spare_size = info->last_spare_size;
>
> Regards,
> Greg
>
This patch does indeed fix our issues :-)
I'm able to run the nanddump command without any timeouts and
run without bbt (not that i would prefer that).

root@output-module:~# nanddump -oa /dev/mtd1
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 8
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x0ff00000...
UBIXS

Please submit a patch.

Thanks
/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-12  6:36               ` Sean Nyekjær
@ 2017-12-12  6:50                 ` Ezequiel Garcia
  2017-12-12  7:17                   ` Greg Cook
  0 siblings, 1 reply; 85+ messages in thread
From: Ezequiel Garcia @ 2017-12-12  6:50 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: Greg Cook, Miquel RAYNAL, linux-mtd, Kasper Revsbech (KREV),
	Ezequiel Garcia

On 12 December 2017 at 03:36, Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:
> Hi Greg
>>
>>
>> I am not completely up-to-date on this, but everything in your traces
>> reads like the same issue I was having on bringup for Armada 385 nand (under
>> 4.9). I've been stuck on another project, so I haven't had time to follow up
>> further, but I just diffed against linux-stable v4.12 pxa3xx_nand.c and it
>> looks like the problem is still there.
>>
>> As far as I can see, the driver is broken for OOB reads when BCH is
>> enabled because the setup in prepare_set_command() results in drain_fifo()
>> not reading enough words from the read fifo in the nfc2 IP block.
>>
>> The patch we are using is below. I have the following in my DTS.
>> nand-keep-config is commented out because I was having some issues with
>> u-boot at the time and it may no longer be relevant:
>> flash@d0000 {
>> status = "okay";
>> num-cs = <1>;
>> //marvell,nand-keep-config;
>> marvell,nand-enable-arbiter;
>> nand-on-flash-bbt;
>> nand-ecc-strength = <4>;
>> nand-ecc-step-size = <512>;
>> };
>>
>> --- /home/user/build/linux-stable/drivers/mtd/nand/pxa3xx_nand.c
>> +++
>> /home/user/build/beam/openwrt/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/linux-mvebu/linux-4.9.34/drivers/mtd/nand/pxa3xx_nand.c
>> @@ -668,7 +669,7 @@
>>  static void drain_fifo(struct pxa3xx_nand_info *info, void *data, int
>> len)
>>  {
>> -if (info->ecc_bch) {
>> +if (info->use_ecc && info->ecc_bch) {
>> u32 val;
>> int ret;
>> @@ -1012,7 +1014,11 @@
>> if (info->cur_chunk < info->nfullchunks) {
>> info->step_chunk_size = info->chunk_size;
>> -info->step_spare_size = info->spare_size;
>> +if (info->use_ecc) {
>> +info->step_spare_size = info->spare_size;
>> +} else {
>> +info->step_spare_size = info->spare_size + info->ecc_size;
>> +}
>> } else {
>> info->step_chunk_size = info->last_chunk_size;
>> info->step_spare_size = info->last_spare_size;
>>
>> Regards,
>> Greg
>>
> This patch does indeed fix our issues :-)
> I'm able to run the nanddump command without any timeouts and
> run without bbt (not that i would prefer that).
>
> root@output-module:~# nanddump -oa /dev/mtd1
> ECC failed: 0
> ECC corrected: 0
> Number of bad blocks: 0
> Number of bbt blocks: 8
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x00000000 and ending at 0x0ff00000...
> UBIXS
>
> Please submit a patch.
>

Greg,

If you prefer, I can re-submit your patch with your author and signed-off-by.
If you want to submit yourself, that's of course better.

Once we have a proper patch, we can start tests an
discuss merging (or not) in its own thread.


Thanks,
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-12  6:01                   ` Greg Cook
@ 2017-12-12  7:09                     ` Ezequiel Garcia
  2017-12-12  7:30                       ` Greg Cook
  0 siblings, 1 reply; 85+ messages in thread
From: Ezequiel Garcia @ 2017-12-12  7:09 UTC (permalink / raw)
  To: Greg Cook
  Cc: Boris Brezillon, Sean Nyekjær, linux-mtd,
	Kasper Revsbech (KREV),
	Ezequiel Garcia, Miquel RAYNAL

On 12 December 2017 at 03:01, Greg Cook <greg@morpheus.ws> wrote:
> On 12 December 2017 at 05:16, Boris Brezillon
> <boris.brezillon@free-electrons.com> wrote:
>> On Mon, 11 Dec 2017 13:24:56 -0300
>> Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> wrote:
>>
>>> Greg,
>>>
>>> On 11 December 2017 at 10:18, Greg Cook <greg@morpheus.ws> wrote:
>>> > Sean,
>>> >
>>> > I am not completely up-to-date on this, but everything in your traces reads
>>> > like the same issue I was having on bringup for Armada 385 nand (under 4.9).
>>> > I've been stuck on another project, so I haven't had time to follow up
>>> > further, but I just diffed against linux-stable v4.12 pxa3xx_nand.c and it
>>> > looks like the problem is still there.
>>> >
>>> > As far as I can see, the driver is broken for OOB reads when BCH is enabled
>>> > because the setup in prepare_set_command() results in drain_fifo() not
>>> > reading enough words from the read fifo in the nfc2 IP block.
>>
>> May I ask how you you get to this conclusion? What makes you think
>> there's still unread data in the FIFO?
>
> Because I added some debug lines to count the number of bytes read and
> I could  see handle_data_pio() was reading 2048 bytes, followed by 32
> bytes of spare. If you have Marvell MV-S109094-00 REV C handy, you can
> see in Table 36 that this is not correct. The correct number of spare
> bytes for the NFCv2 IP block is
> - 64 bytes when SPARE_EN==1 and ECC_EN==0
> - 32 bytes when SPARE_EN==1 and ECC_EN==1
>
>>> >
>>>
>>> Yes, this sounds just like the bug I was expecting for OOB reads.
>>>
>>> > The patch we are using is below. I have the following in my DTS.
>>> > nand-keep-config is commented out because I was having some issues with
>>> > u-boot at the time and it may no longer be relevant:
>>>
>>> Probably.
>>>
>>> > flash@d0000 {
>>> > status = "okay";
>>> > num-cs = <1>;
>>> > //marvell,nand-keep-config;
>>> > marvell,nand-enable-arbiter;
>>> > nand-on-flash-bbt;
>>> > nand-ecc-strength = <4>;
>>> > nand-ecc-step-size = <512>;
>>> > };
>>> >
>>> > --- /home/user/build/linux-stable/drivers/mtd/nand/pxa3xx_nand.c
>>> > +++
>>> > /home/user/build/beam/openwrt/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/linux-mvebu/linux-4.9.34/drivers/mtd/nand/pxa3xx_nand.c
>>> > @@ -668,7 +669,7 @@
>>> >
>>> >  static void drain_fifo(struct pxa3xx_nand_info *info, void *data, int len)
>>> >  {
>>> > - if (info->ecc_bch) {
>>> > + if (info->use_ecc && info->ecc_bch) {
>>
>> This one might explain timeouts occurring when you drain the FIFO for
>> an operation that does not enable the ECC engine (like
>> READ_PARAM_PAGE).
>>
>> So this fix is indeed valid, but I'm almost sure it won't fix Sean's
>> problem.
>
> From memory, I don't *think* specific line wasn't causing me any
> issues, but I noticed it was not correct because of the way use_ecc
> and ecc_bch flags are initialised and then used. As you say, without
> this patch, you can get timeouts on non-ECC operations when you have
> BCH ECC enabled generally.
>
>>
>>> >   u32 val;
>>> >   int ret;
>>> >
>>> > @@ -1012,7 +1014,11 @@
>>> >
>>> >   if (info->cur_chunk < info->nfullchunks) {
>>> >   info->step_chunk_size = info->chunk_size;
>>> > - info->step_spare_size = info->spare_size;
>>> > + if (info->use_ecc) {
>>> > + info->step_spare_size = info->spare_size;
>>> > + } else {
>>> > + info->step_spare_size = info->spare_size + info->ecc_size;
>>> > + }
>>
>> The only case this change would fix is when you try to read/write pages
>> in raw mode, and I'm pretty sure this driver does not support raw
>> accesses.
>
> Why do you say it would only affect raw mode? This code is not
> specific to raw mode, nor
> is the related code in handle_data_pio(), which uses the value of
> step_spare_size to drain
> the hardware FIFO.
>

AFAICS, this patch affects READOOB commands, which are
issued when there is no BBT to detect bad blocks.

It "fixes" the timeout, but I wouldn't go as far as assuring
it makes the on-flash bad block scheme work, given
OOB writes will still be done with ECC enabled.

It seems this drivers mandates a BBT to work properly,
so perhaps a better patch would be to (a) force BBT usage,
and avoid OOB operations altogether, avoiding nasty
timeouts and unhappy board-bringupers.

Or (b) fix the READOOB and then
WARN/pr_warning about OOB I/O being broken.

The new driver under discussion, apparently makes AOOB
actually usable (arguably, without much utility as OOB
is mostly used for ECC anyway).

Ideas?
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-12  6:50                 ` Ezequiel Garcia
@ 2017-12-12  7:17                   ` Greg Cook
  0 siblings, 0 replies; 85+ messages in thread
From: Greg Cook @ 2017-12-12  7:17 UTC (permalink / raw)
  To: Ezequiel Garcia
  Cc: Sean Nyekjær, Miquel RAYNAL, linux-mtd,
	Kasper Revsbech (KREV),
	Ezequiel Garcia

On 12 December 2017 at 14:50, Ezequiel Garcia
<ezequiel@vanguardiasur.com.ar> wrote:
> On 12 December 2017 at 03:36, Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:
>> Hi Greg
>>>
>>>
>>> I am not completely up-to-date on this, but everything in your traces
>>> reads like the same issue I was having on bringup for Armada 385 nand (under
>>> 4.9). I've been stuck on another project, so I haven't had time to follow up
>>> further, but I just diffed against linux-stable v4.12 pxa3xx_nand.c and it
>>> looks like the problem is still there.
>>>
>>> As far as I can see, the driver is broken for OOB reads when BCH is
>>> enabled because the setup in prepare_set_command() results in drain_fifo()
>>> not reading enough words from the read fifo in the nfc2 IP block.
>>>
>>> The patch we are using is below. I have the following in my DTS.
>>> nand-keep-config is commented out because I was having some issues with
>>> u-boot at the time and it may no longer be relevant:
>>> flash@d0000 {
>>> status = "okay";
>>> num-cs = <1>;
>>> //marvell,nand-keep-config;
>>> marvell,nand-enable-arbiter;
>>> nand-on-flash-bbt;
>>> nand-ecc-strength = <4>;
>>> nand-ecc-step-size = <512>;
>>> };
>>>
>>> --- /home/user/build/linux-stable/drivers/mtd/nand/pxa3xx_nand.c
>>> +++
>>> /home/user/build/beam/openwrt/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/linux-mvebu/linux-4.9.34/drivers/mtd/nand/pxa3xx_nand.c
>>> @@ -668,7 +669,7 @@
>>>  static void drain_fifo(struct pxa3xx_nand_info *info, void *data, int
>>> len)
>>>  {
>>> -if (info->ecc_bch) {
>>> +if (info->use_ecc && info->ecc_bch) {
>>> u32 val;
>>> int ret;
>>> @@ -1012,7 +1014,11 @@
>>> if (info->cur_chunk < info->nfullchunks) {
>>> info->step_chunk_size = info->chunk_size;
>>> -info->step_spare_size = info->spare_size;
>>> +if (info->use_ecc) {
>>> +info->step_spare_size = info->spare_size;
>>> +} else {
>>> +info->step_spare_size = info->spare_size + info->ecc_size;
>>> +}
>>> } else {
>>> info->step_chunk_size = info->last_chunk_size;
>>> info->step_spare_size = info->last_spare_size;
>>>
>>> Regards,
>>> Greg
>>>
>> This patch does indeed fix our issues :-)
>> I'm able to run the nanddump command without any timeouts and
>> run without bbt (not that i would prefer that).
>>
>> root@output-module:~# nanddump -oa /dev/mtd1
>> ECC failed: 0
>> ECC corrected: 0
>> Number of bad blocks: 0
>> Number of bbt blocks: 8
>> Block size 131072, page size 2048, OOB size 64
>> Dumping data starting at 0x00000000 and ending at 0x0ff00000...
>> UBIXS
>>
>> Please submit a patch.
>>
>
> Greg,
>
> If you prefer, I can re-submit your patch with your author and signed-off-by.
> If you want to submit yourself, that's of course better.
>
> Once we have a proper patch, we can start tests an
> discuss merging (or not) in its own thread.

Ezequiel,

I'm *relatively* new to this, but recognise I should learn. Is this
link a good place to start, or is there something newer?
https://www.kernel.org/doc/html/v4.12/process/submitting-patches.html

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-12  7:09                     ` Ezequiel Garcia
@ 2017-12-12  7:30                       ` Greg Cook
  2017-12-12  8:15                         ` Boris Brezillon
  0 siblings, 1 reply; 85+ messages in thread
From: Greg Cook @ 2017-12-12  7:30 UTC (permalink / raw)
  To: Ezequiel Garcia
  Cc: Boris Brezillon, Sean Nyekjær, linux-mtd,
	Kasper Revsbech (KREV),
	Ezequiel Garcia, Miquel RAYNAL

On 12 December 2017 at 15:09, Ezequiel Garcia
<ezequiel@vanguardiasur.com.ar> wrote:
> On 12 December 2017 at 03:01, Greg Cook <greg@morpheus.ws> wrote:
>> On 12 December 2017 at 05:16, Boris Brezillon
>> <boris.brezillon@free-electrons.com> wrote:
>>> On Mon, 11 Dec 2017 13:24:56 -0300
>>> Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> wrote:
>>>
>>>> Greg,
>>>>
>>>> On 11 December 2017 at 10:18, Greg Cook <greg@morpheus.ws> wrote:
>>>> > Sean,
>>>> >
>>>> > I am not completely up-to-date on this, but everything in your traces reads
>>>> > like the same issue I was having on bringup for Armada 385 nand (under 4.9).
>>>> > I've been stuck on another project, so I haven't had time to follow up
>>>> > further, but I just diffed against linux-stable v4.12 pxa3xx_nand.c and it
>>>> > looks like the problem is still there.
>>>> >
>>>> > As far as I can see, the driver is broken for OOB reads when BCH is enabled
>>>> > because the setup in prepare_set_command() results in drain_fifo() not
>>>> > reading enough words from the read fifo in the nfc2 IP block.
>>>
>>> May I ask how you you get to this conclusion? What makes you think
>>> there's still unread data in the FIFO?
>>
>> Because I added some debug lines to count the number of bytes read and
>> I could  see handle_data_pio() was reading 2048 bytes, followed by 32
>> bytes of spare. If you have Marvell MV-S109094-00 REV C handy, you can
>> see in Table 36 that this is not correct. The correct number of spare
>> bytes for the NFCv2 IP block is
>> - 64 bytes when SPARE_EN==1 and ECC_EN==0
>> - 32 bytes when SPARE_EN==1 and ECC_EN==1
>>
>>>> >
>>>>
>>>> Yes, this sounds just like the bug I was expecting for OOB reads.
>>>>
>>>> > The patch we are using is below. I have the following in my DTS.
>>>> > nand-keep-config is commented out because I was having some issues with
>>>> > u-boot at the time and it may no longer be relevant:
>>>>
>>>> Probably.
>>>>
>>>> > flash@d0000 {
>>>> > status = "okay";
>>>> > num-cs = <1>;
>>>> > //marvell,nand-keep-config;
>>>> > marvell,nand-enable-arbiter;
>>>> > nand-on-flash-bbt;
>>>> > nand-ecc-strength = <4>;
>>>> > nand-ecc-step-size = <512>;
>>>> > };
>>>> >
>>>> > --- /home/user/build/linux-stable/drivers/mtd/nand/pxa3xx_nand.c
>>>> > +++
>>>> > /home/user/build/beam/openwrt/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/linux-mvebu/linux-4.9.34/drivers/mtd/nand/pxa3xx_nand.c
>>>> > @@ -668,7 +669,7 @@
>>>> >
>>>> >  static void drain_fifo(struct pxa3xx_nand_info *info, void *data, int len)
>>>> >  {
>>>> > - if (info->ecc_bch) {
>>>> > + if (info->use_ecc && info->ecc_bch) {
>>>
>>> This one might explain timeouts occurring when you drain the FIFO for
>>> an operation that does not enable the ECC engine (like
>>> READ_PARAM_PAGE).
>>>
>>> So this fix is indeed valid, but I'm almost sure it won't fix Sean's
>>> problem.
>>
>> From memory, I don't *think* specific line wasn't causing me any
>> issues, but I noticed it was not correct because of the way use_ecc
>> and ecc_bch flags are initialised and then used. As you say, without
>> this patch, you can get timeouts on non-ECC operations when you have
>> BCH ECC enabled generally.
>>
>>>
>>>> >   u32 val;
>>>> >   int ret;
>>>> >
>>>> > @@ -1012,7 +1014,11 @@
>>>> >
>>>> >   if (info->cur_chunk < info->nfullchunks) {
>>>> >   info->step_chunk_size = info->chunk_size;
>>>> > - info->step_spare_size = info->spare_size;
>>>> > + if (info->use_ecc) {
>>>> > + info->step_spare_size = info->spare_size;
>>>> > + } else {
>>>> > + info->step_spare_size = info->spare_size + info->ecc_size;
>>>> > + }
>>>
>>> The only case this change would fix is when you try to read/write pages
>>> in raw mode, and I'm pretty sure this driver does not support raw
>>> accesses.
>>
>> Why do you say it would only affect raw mode? This code is not
>> specific to raw mode, nor
>> is the related code in handle_data_pio(), which uses the value of
>> step_spare_size to drain
>> the hardware FIFO.
>>
>
> AFAICS, this patch affects READOOB commands, which are
> issued when there is no BBT to detect bad blocks.

Agree that this only really affects READOOB, because READ0 will always
use ECC. I guess this is why it's only catching people at bringup
because we are booting into Linux with a blank device.

>
> It "fixes" the timeout, but I wouldn't go as far as assuring
> it makes the on-flash bad block scheme work, given
> OOB writes will still be done with ECC enabled.
>
> It seems this drivers mandates a BBT to work properly,
> so perhaps a better patch would be to (a) force BBT usage,
> and avoid OOB operations altogether, avoiding nasty
> timeouts and unhappy board-bringupers.
>
> Or (b) fix the READOOB and then
> WARN/pr_warning about OOB I/O being broken.
>
> The new driver under discussion, apparently makes AOOB
> actually usable (arguably, without much utility as OOB
> is mostly used for ECC anyway).
>
> Ideas?

Does mandating BBT usage avoid the bug? Aren't you always going to hit
it on a blank NAND device straight off the production line?

> --
> Ezequiel García, VanguardiaSur
> www.vanguardiasur.com.ar

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-12  7:30                       ` Greg Cook
@ 2017-12-12  8:15                         ` Boris Brezillon
  2017-12-12 16:22                           ` Ezequiel Garcia
  0 siblings, 1 reply; 85+ messages in thread
From: Boris Brezillon @ 2017-12-12  8:15 UTC (permalink / raw)
  To: Greg Cook
  Cc: Ezequiel Garcia, Sean Nyekjær, linux-mtd,
	Kasper Revsbech (KREV),
	Ezequiel Garcia, Miquel RAYNAL

On Tue, 12 Dec 2017 15:30:03 +0800
Greg Cook <greg@morpheus.ws> wrote:

> On 12 December 2017 at 15:09, Ezequiel Garcia
> <ezequiel@vanguardiasur.com.ar> wrote:
> > On 12 December 2017 at 03:01, Greg Cook <greg@morpheus.ws> wrote:  
> >> On 12 December 2017 at 05:16, Boris Brezillon
> >> <boris.brezillon@free-electrons.com> wrote:  
> >>> On Mon, 11 Dec 2017 13:24:56 -0300
> >>> Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> wrote:
> >>>  
> >>>> Greg,
> >>>>
> >>>> On 11 December 2017 at 10:18, Greg Cook <greg@morpheus.ws> wrote:  
> >>>> > Sean,
> >>>> >
> >>>> > I am not completely up-to-date on this, but everything in your traces reads
> >>>> > like the same issue I was having on bringup for Armada 385 nand (under 4.9).
> >>>> > I've been stuck on another project, so I haven't had time to follow up
> >>>> > further, but I just diffed against linux-stable v4.12 pxa3xx_nand.c and it
> >>>> > looks like the problem is still there.
> >>>> >
> >>>> > As far as I can see, the driver is broken for OOB reads when BCH is enabled
> >>>> > because the setup in prepare_set_command() results in drain_fifo() not
> >>>> > reading enough words from the read fifo in the nfc2 IP block.  
> >>>
> >>> May I ask how you you get to this conclusion? What makes you think
> >>> there's still unread data in the FIFO?  
> >>
> >> Because I added some debug lines to count the number of bytes read and
> >> I could  see handle_data_pio() was reading 2048 bytes, followed by 32
> >> bytes of spare. If you have Marvell MV-S109094-00 REV C handy, you can
> >> see in Table 36 that this is not correct. The correct number of spare
> >> bytes for the NFCv2 IP block is
> >> - 64 bytes when SPARE_EN==1 and ECC_EN==0
> >> - 32 bytes when SPARE_EN==1 and ECC_EN==1
> >>  
> >>>> >  
> >>>>
> >>>> Yes, this sounds just like the bug I was expecting for OOB reads.
> >>>>  
> >>>> > The patch we are using is below. I have the following in my DTS.
> >>>> > nand-keep-config is commented out because I was having some issues with
> >>>> > u-boot at the time and it may no longer be relevant:  
> >>>>
> >>>> Probably.
> >>>>  
> >>>> > flash@d0000 {
> >>>> > status = "okay";
> >>>> > num-cs = <1>;
> >>>> > //marvell,nand-keep-config;
> >>>> > marvell,nand-enable-arbiter;
> >>>> > nand-on-flash-bbt;
> >>>> > nand-ecc-strength = <4>;
> >>>> > nand-ecc-step-size = <512>;
> >>>> > };
> >>>> >
> >>>> > --- /home/user/build/linux-stable/drivers/mtd/nand/pxa3xx_nand.c
> >>>> > +++
> >>>> > /home/user/build/beam/openwrt/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/linux-mvebu/linux-4.9.34/drivers/mtd/nand/pxa3xx_nand.c
> >>>> > @@ -668,7 +669,7 @@
> >>>> >
> >>>> >  static void drain_fifo(struct pxa3xx_nand_info *info, void *data, int len)
> >>>> >  {
> >>>> > - if (info->ecc_bch) {
> >>>> > + if (info->use_ecc && info->ecc_bch) {  
> >>>
> >>> This one might explain timeouts occurring when you drain the FIFO for
> >>> an operation that does not enable the ECC engine (like
> >>> READ_PARAM_PAGE).
> >>>
> >>> So this fix is indeed valid, but I'm almost sure it won't fix Sean's
> >>> problem.  
> >>
> >> From memory, I don't *think* specific line wasn't causing me any
> >> issues, but I noticed it was not correct because of the way use_ecc
> >> and ecc_bch flags are initialised and then used. As you say, without
> >> this patch, you can get timeouts on non-ECC operations when you have
> >> BCH ECC enabled generally.
> >>  
> >>>  
> >>>> >   u32 val;
> >>>> >   int ret;
> >>>> >
> >>>> > @@ -1012,7 +1014,11 @@
> >>>> >
> >>>> >   if (info->cur_chunk < info->nfullchunks) {
> >>>> >   info->step_chunk_size = info->chunk_size;
> >>>> > - info->step_spare_size = info->spare_size;
> >>>> > + if (info->use_ecc) {
> >>>> > + info->step_spare_size = info->spare_size;
> >>>> > + } else {
> >>>> > + info->step_spare_size = info->spare_size + info->ecc_size;
> >>>> > + }  
> >>>
> >>> The only case this change would fix is when you try to read/write pages
> >>> in raw mode, and I'm pretty sure this driver does not support raw
> >>> accesses.  
> >>
> >> Why do you say it would only affect raw mode? This code is not
> >> specific to raw mode, nor
> >> is the related code in handle_data_pio(), which uses the value of
> >> step_spare_size to drain
> >> the hardware FIFO.
> >>  
> >
> > AFAICS, this patch affects READOOB commands, which are
> > issued when there is no BBT to detect bad blocks.  
> 
> Agree that this only really affects READOOB, because READ0 will always
> use ECC. I guess this is why it's only catching people at bringup
> because we are booting into Linux with a blank device.

I overlooked the READOOB case. What I don't understand though is why we
are disabling ECC in this case. I mean, free OOB bytes seem to be
ECC protected (at least for BCH), so ECC should stay enabled when
reading those bytes, unless we're in raw mode.

> 
> >
> > It "fixes" the timeout, but I wouldn't go as far as assuring
> > it makes the on-flash bad block scheme work, given
> > OOB writes will still be done with ECC enabled.
> >
> > It seems this drivers mandates a BBT to work properly,
> > so perhaps a better patch would be to (a) force BBT usage,
> > and avoid OOB operations altogether, avoiding nasty
> > timeouts and unhappy board-bringupers.
> >
> > Or (b) fix the READOOB and then
> > WARN/pr_warning about OOB I/O being broken.
> >
> > The new driver under discussion, apparently makes AOOB
> > actually usable (arguably, without much utility as OOB
> > is mostly used for ECC anyway).
> >
> > Ideas?  
> 
> Does mandating BBT usage avoid the bug? Aren't you always going to hit
> it on a blank NAND device straight off the production line?

The timeout bug should be fixed. The fact that a valid BBT is required
after the device has been programmed (because BBM are screwed up by the
controller) is orthogonal to timeout on READOOB commands.

Regards,

Boris

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-11 14:09                                           ` Miquel RAYNAL
  2017-12-11 14:49                                             ` Boris Brezillon
@ 2017-12-12  8:44                                             ` Sean Nyekjær
  2017-12-12  8:51                                               ` Miquel RAYNAL
  1 sibling, 1 reply; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-12  8:44 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi Miquel,

>> This behavior is "normal", it is because the number of failure has
>> been incremented (probably by marvell_nfc_hw_ecc_correct()).
>>
>>
>> Can you hack the code right before this line [1] and add:
>> 1/ A dump of both the data buffer and the oob buffer (entirely)
>> 2/ Add a memset(mtd->oob_poi, 0xff, mtd->oobsize) conditionally until
>> the probe is finished (you may want to add a global boolean value that
>> changes its state after the nand_scan_tail() call).
> Instead of hacking this way, to boot until you get a prompt, you may
> add this property to the nand controller node:
>
> nand-ecc-mode = "none";
>
> Then please use nanddump over a programmed page, including the OOB area.
>
>
Boot log:
[    2.692856] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
[    2.699231] nand: Micron MT29F2G08ABAEAH4
[    2.703286] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, 
OOB size: 64
[    2.711135] nand: NAND_ECC_NONE selected by board driver. This is not 
recommended!
[    2.718730] nand: WARNING: pxa3xx_nand-0: the ECC used on your system 
is too weak compared to the one required by the NAND chip
[    2.732632] Bad block table not found for chip 0
[    2.739609] Bad block table not found for chip 0
[    2.744250] Scanning device for bad blocks
[    2.985502] Bad block table written to 0x00000ffe0000, version 0x01
[    2.992760] Bad block table written to 0x00000ffc0000, version 0x01

Nanddump:
root@output-module:~# nanddump -oa /dev/mtd1
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x0ff00000...
UBIXS...

I guess it's safe to say something is not right with ECC enabled.
>> Then please do a raw dump with nanddump from Linux.
>>
>>
/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-12  8:44                                             ` Sean Nyekjær
@ 2017-12-12  8:51                                               ` Miquel RAYNAL
  2017-12-12  8:56                                                 ` Sean Nyekjær
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-12  8:51 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi Sean,

On Tue, 12 Dec 2017 09:44:43 +0100
Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:

> Hi Miquel,
> 
> >> This behavior is "normal", it is because the number of failure has
> >> been incremented (probably by marvell_nfc_hw_ecc_correct()).
> >>
> >>
> >> Can you hack the code right before this line [1] and add:
> >> 1/ A dump of both the data buffer and the oob buffer (entirely)
> >> 2/ Add a memset(mtd->oob_poi, 0xff, mtd->oobsize) conditionally
> >> until the probe is finished (you may want to add a global boolean
> >> value that changes its state after the nand_scan_tail() call).  
> > Instead of hacking this way, to boot until you get a prompt, you may
> > add this property to the nand controller node:
> >
> > nand-ecc-mode = "none";
> >
> > Then please use nanddump over a programmed page, including the OOB
> > area.
> >
> >  
> Boot log:
> [    2.692856] nand: device found, Manufacturer ID: 0x2c, Chip ID:
> 0xda [    2.699231] nand: Micron MT29F2G08ABAEAH4
> [    2.703286] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
> 2048, OOB size: 64
> [    2.711135] nand: NAND_ECC_NONE selected by board driver. This is
> not recommended!
> [    2.718730] nand: WARNING: pxa3xx_nand-0: the ECC used on your
> system is too weak compared to the one required by the NAND chip
> [    2.732632] Bad block table not found for chip 0
> [    2.739609] Bad block table not found for chip 0
> [    2.744250] Scanning device for bad blocks
> [    2.985502] Bad block table written to 0x00000ffe0000, version 0x01
> [    2.992760] Bad block table written to 0x00000ffc0000, version 0x01
> 
> Nanddump:
> root@output-module:~# nanddump -oa /dev/mtd1
> ECC failed: 0
> ECC corrected: 0
> Number of bad blocks: 0
> Number of bbt blocks: 0
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x00000000 and ending at 0x0ff00000...
> UBIXS...
> 
> I guess it's safe to say something is not right with ECC enabled.
> >> Then please do a raw dump with nanddump from Linux.

Thanks for testing this, but I _really_ need the entire output of

        nanddump -o -n -p -l 0x800 /dev/mtd1

Thank you,
Miquèl

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-12  8:51                                               ` Miquel RAYNAL
@ 2017-12-12  8:56                                                 ` Sean Nyekjær
  2017-12-12 10:12                                                   ` Miquel RAYNAL
  0 siblings, 1 reply; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-12  8:56 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi Miquel,
>> Boot log:
>> [    2.692856] nand: device found, Manufacturer ID: 0x2c, Chip ID:
>> 0xda [    2.699231] nand: Micron MT29F2G08ABAEAH4
>> [    2.703286] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
>> 2048, OOB size: 64
>> [    2.711135] nand: NAND_ECC_NONE selected by board driver. This is
>> not recommended!
>> [    2.718730] nand: WARNING: pxa3xx_nand-0: the ECC used on your
>> system is too weak compared to the one required by the NAND chip
>> [    2.732632] Bad block table not found for chip 0
>> [    2.739609] Bad block table not found for chip 0
>> [    2.744250] Scanning device for bad blocks
>> [    2.985502] Bad block table written to 0x00000ffe0000, version 0x01
>> [    2.992760] Bad block table written to 0x00000ffc0000, version 0x01
>>
>> Nanddump:
>> root@output-module:~# nanddump -oa /dev/mtd1
>> ECC failed: 0
>> ECC corrected: 0
>> Number of bad blocks: 0
>> Number of bbt blocks: 0
>> Block size 131072, page size 2048, OOB size 64
>> Dumping data starting at 0x00000000 and ending at 0x0ff00000...
>> UBIXS...
>>
>> I guess it's safe to say something is not right with ECC enabled.
>>>> Then please do a raw dump with nanddump from Linux.
> Thanks for testing this, but I _really_ need the entire output of
>
>          nanddump -o -n -p -l 0x800 /dev/mtd1
root@output-module:~# nanddump -o -n -p -l 0x800 /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x00000000 and ending at 0x00000800...
0x00000000: 55 42 49 23 01 00 00 00 00 00 00 00 00 00 00 01
0x00000010: 00 00 08 00 00 00 10 00 00 00 00 00 00 00 00 00
0x00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000030: 00 00 00 00 00 00 00 00 00 00 00 00 7f 58 53 19
0x00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000001a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000001b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000001c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000001d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000001e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000001f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000002a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000002b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000002c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000002d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000002e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000002f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000310: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000003a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000003b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000003c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000003d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000003e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000003f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000004a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000004b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000004c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000004d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000004e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000004f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000005a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000005b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000005c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000005d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000005e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000005f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000006a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000006b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000006c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000006d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000006e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000006f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000710: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00000790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000007a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000007b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000007c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000007d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000007e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x000007f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: c1 eb aa 03 d3 5c d8 ae fa fd ba 34 2a a5 20 38
   OOB Data: fd 0b 22 59 c1 8c 3c a5 a4 62 df f2 d4 7e ff ff

/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-12  8:56                                                 ` Sean Nyekjær
@ 2017-12-12 10:12                                                   ` Miquel RAYNAL
  2017-12-12 10:55                                                     ` Sean Nyekjær
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-12 10:12 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hello Sean,

On Tue, 12 Dec 2017 09:56:19 +0100
Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:

> Hi Miquel,
> >> Boot log:
> >> [    2.692856] nand: device found, Manufacturer ID: 0x2c, Chip ID:
> >> 0xda [    2.699231] nand: Micron MT29F2G08ABAEAH4
> >> [    2.703286] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
> >> 2048, OOB size: 64
> >> [    2.711135] nand: NAND_ECC_NONE selected by board driver. This
> >> is not recommended!
> >> [    2.718730] nand: WARNING: pxa3xx_nand-0: the ECC used on your
> >> system is too weak compared to the one required by the NAND chip
> >> [    2.732632] Bad block table not found for chip 0
> >> [    2.739609] Bad block table not found for chip 0
> >> [    2.744250] Scanning device for bad blocks
> >> [    2.985502] Bad block table written to 0x00000ffe0000, version
> >> 0x01 [    2.992760] Bad block table written to 0x00000ffc0000,
> >> version 0x01
> >>
> >> Nanddump:
> >> root@output-module:~# nanddump -oa /dev/mtd1
> >> ECC failed: 0
> >> ECC corrected: 0
> >> Number of bad blocks: 0
> >> Number of bbt blocks: 0
> >> Block size 131072, page size 2048, OOB size 64
> >> Dumping data starting at 0x00000000 and ending at 0x0ff00000...
> >> UBIXS...
> >>
> >> I guess it's safe to say something is not right with ECC enabled.  
> >>>> Then please do a raw dump with nanddump from Linux.  
> > Thanks for testing this, but I _really_ need the entire output of
> >
> >          nanddump -o -n -p -l 0x800 /dev/mtd1  
> root@output-module:~# nanddump -o -n -p -l 0x800 /dev/mtd1
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x00000000 and ending at 0x00000800...

[...]

>    OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>    OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>    OOB Data: c1 eb aa 03 d3 5c d8 ae fa fd ba 34 2a a5 20 38
>    OOB Data: fd 0b 22 59 c1 8c 3c a5 a4 62 df f2 d4 7e ff ff

This is exactly what the driver expects, an empty spare area (free OOB)
of 32B, 30B of ECC and 2B lost.

Are you sure your U-Boot does actually use the BBT?

The last two blocks (supposedly written by U-Boot) are usually declared
bad by Linux when it does not find the BBT. This is not the case, like
if the last blocks were empty.

Could you try this, still with "ecc-none" and without the
"nand-keep-config" property:

1/ From U-Boot, scrub the last 4 blocks. As your NAND is 256MiB
wide with 128kiB blocks, this should do the trick:

        nand scrub 0xFF80000 0x80000

2/ At this point, U-Boot should tell you it cannot find a bad block
table, a second later it will tell you that it created it twice at the
end of the NAND chip.

3/ Boot Linux with ECC == none
4/ Dump the first page of the 4 last blocks:

        nanddump -nop -l 0x800 -s <adddr> /dev/mtd1

Supposedly that /dev/mtd1 is the _last_ MTD partition of your NAND
device and <addr> being sequentially:

        0xFF80000
        0xFFA0000
        0xFFC0000
        0xFFE0000

Please copy/paste the overall trace without any cuts (including U-Boot
traces, literally everything).

Thanks for your effort,
Miquèl

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-12 10:12                                                   ` Miquel RAYNAL
@ 2017-12-12 10:55                                                     ` Sean Nyekjær
  2017-12-12 11:08                                                       ` Miquel RAYNAL
  0 siblings, 1 reply; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-12 10:55 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi Miquel
> Are you sure your U-Boot does actually use the BBT?
>
> The last two blocks (supposedly written by U-Boot) are usually declared
> bad by Linux when it does not find the BBT. This is not the case, like
> if the last blocks were empty.
>
> Could you try this, still with "ecc-none" and without the
> "nand-keep-config" property:
&nand_controller {
         status = "okay";
         pinctrl-names = "default";
         pinctrl-0 = <&nand_pins>, <&nand_rb>;

         nand@0 {
                 reg = <0>;
                 label = "pxa3xx_nand-0";
                 marvell,rb = <0>;
                 nand-ecc-mode = "none";
                 nand-on-flash-bbt;
     };
};
>
> 1/ From U-Boot, scrub the last 4 blocks. As your NAND is 256MiB
> wide with 128kiB blocks, this should do the trick:
>
>          nand scrub 0xFF80000 0x80000
>
> 2/ At this point, U-Boot should tell you it cannot find a bad block
> table, a second later it will tell you that it created it twice at the
> end of the NAND chip.
Yes uboot is recreating the bbt and after a new reset it recognise the 
new bbt.
>
> 3/ Boot Linux with ECC == none
> 4/ Dump the first page of the 4 last blocks:
>
>          nanddump -nop -l 0x800 -s <adddr> /dev/mtd1
See tracing below
>
> Supposedly that /dev/mtd1 is the _last_ MTD partition of your NAND
> device and <addr> being sequentially:
>
>          0xFF80000
>          0xFFA0000
>          0xFFC0000
>          0xFFE0000
>
> Please copy/paste the overall trace without any cuts (including U-Boot
> traces, literally everything).
>


U-Boot 2017.11-00035-ge9282bb30b-dirty (Dec 12 2017 - 11:22:21 +0100)

SoC:   MV88F6810-A0 at 1066 MHz
DRAM:  1 GiB (533 MHz, 16-bit, ECC not enabled)
WDT:   Enabling Armada 385 watchdog.
NAND:  PXA3xx: strength 4, ecc_stepsize 512, page_size 2048
256 MiB
Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
Model: Triax dvb-tc output
Board: Triax dvb-tc output
Net:
Warning: ethernet@30000 (eth0) using random MAC address - 26:d3:56:98:ca:b4
eth0: ethernet@30000
=> nand scrub 0xFF80000 0x80000

NAND scrub: device 0 offset 0xff80000, size 0x80000
Warning: scrub option will erase all factory set bad blocks!
          There is no reliable way to recover them.
          Use this command only for testing purposes if you
          are sure of what you are doing!

Really scrub this NAND flash? <y/N>
y
Erasing at 0xffe0000 -- 100% complete.
OK
=> boot

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.15.0-rc1-00094-g1791eb8f2475-dirty 
(skn@skn) (gcc version 7.2.0 (Arch Repository)) #30 SMP PREEMPT Tue Dec 
12 09:28:30 CET 2017
...
[    2.692801] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
[    2.699176] nand: Micron MT29F2G08ABAEAH4
[    2.703232] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, 
OOB size: 64
[    2.710928] nand: NAND_ECC_NONE selected by board driver. This is not 
recommended!
[    2.718523] nand: WARNING: pxa3xx_nand-0: the ECC used on your system 
is too weak compared to the one required by the NAND chip
[    2.731429] Bad block table not found for chip 0
[    2.737384] Bad block table not found for chip 0
[    2.742024] Scanning device for bad blocks
[    2.891818] Bad block table written to 0x00000ffe0000, version 0x01
[    2.898837] Bad block table written to 0x00000ffc0000, version 0x01
[    2.905152] 2 cmdlinepart partitions found on MTD device pxa3xx_nand-0
[    2.911708] Creating 2 MTD partitions on "pxa3xx_nand-0":
[    2.917130] 0x000000000000-0x000000100000 : "uboot"
[    2.922512] 0x000000100000-0x000010000000 : "ubi0"
...
output-module login: root
Password:
root@output-module:~#
root@output-module:~# nanddump -nop -l 0x800 -s 0xFF80000 /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0ff80000 and ending at 0x0ff80800...
root@output-module:~# nanddump -nop -l 0x800 -s 0xFFA0000 /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0ffa0000 and ending at 0x0ffa0800...
root@output-module:~# nanddump -nop -l 0x800 -s 0xFFC0000 /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0ffc0000 and ending at 0x0ffc0800...
root@output-module:~# nanddump -nop -l 0x800 -s 0xFFE0000 /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0ffe0000 and ending at 0x0ffe0800...
root@output-module:~# reboot
...
U-Boot 2017.11-00035-ge9282bb30b-dirty (Dec 12 2017 - 11:22:21 +0100)

SoC:   MV88F6810-A0 at 1066 MHz
DRAM:  1 GiB (533 MHz, 16-bit, ECC not enabled)
WDT:   Enabling Armada 385 watchdog.
NAND:  PXA3xx: strength 4, ecc_stepsize 512, page_size 2048
256 MiB
Bad block table not found for chip 0
Bad block table not found for chip 0
Scanning device for bad blocks
Bad block table written to 0x00000ffe0000, version 0x01
Bad block table written to 0x00000ffc0000, version 0x01

If I reboot uboot is unable recognise the bbt, but recreates it. But the 
kernel is scanning on every boot.
Am I doing anything wrong in the nanddump command?

/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-12 10:55                                                     ` Sean Nyekjær
@ 2017-12-12 11:08                                                       ` Miquel RAYNAL
  2017-12-12 11:28                                                         ` Sean Nyekjær
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-12 11:08 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

On Tue, 12 Dec 2017 11:55:22 +0100
Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:

> Hi Miquel
> > Are you sure your U-Boot does actually use the BBT?
> >
> > The last two blocks (supposedly written by U-Boot) are usually
> > declared bad by Linux when it does not find the BBT. This is not
> > the case, like if the last blocks were empty.
> >
> > Could you try this, still with "ecc-none" and without the
> > "nand-keep-config" property:  
> &nand_controller {
>          status = "okay";
>          pinctrl-names = "default";
>          pinctrl-0 = <&nand_pins>, <&nand_rb>;
> 
>          nand@0 {
>                  reg = <0>;
>                  label = "pxa3xx_nand-0";
>                  marvell,rb = <0>;
>                  nand-ecc-mode = "none";
>                  nand-on-flash-bbt;
>      };
> };
> >
> > 1/ From U-Boot, scrub the last 4 blocks. As your NAND is 256MiB
> > wide with 128kiB blocks, this should do the trick:
> >
> >          nand scrub 0xFF80000 0x80000
> >
> > 2/ At this point, U-Boot should tell you it cannot find a bad block
> > table, a second later it will tell you that it created it twice at
> > the end of the NAND chip.  
> Yes uboot is recreating the bbt and after a new reset it recognise
> the new bbt.
> >
> > 3/ Boot Linux with ECC == none
> > 4/ Dump the first page of the 4 last blocks:
> >
> >          nanddump -nop -l 0x800 -s <adddr> /dev/mtd1  
> See tracing below
> >
> > Supposedly that /dev/mtd1 is the _last_ MTD partition of your NAND
> > device and <addr> being sequentially:
> >
> >          0xFF80000
> >          0xFFA0000
> >          0xFFC0000
> >          0xFFE0000
> >
> > Please copy/paste the overall trace without any cuts (including
> > U-Boot traces, literally everything).
> >  
> 
> 
> U-Boot 2017.11-00035-ge9282bb30b-dirty (Dec 12 2017 - 11:22:21 +0100)
> 
> SoC:   MV88F6810-A0 at 1066 MHz
> DRAM:  1 GiB (533 MHz, 16-bit, ECC not enabled)
> WDT:   Enabling Armada 385 watchdog.
> NAND:  PXA3xx: strength 4, ecc_stepsize 512, page_size 2048
> 256 MiB
> Bad block table found at page 131008, version 0x01
> Bad block table found at page 130944, version 0x01
> Model: Triax dvb-tc output
> Board: Triax dvb-tc output
> Net:
> Warning: ethernet@30000 (eth0) using random MAC address -
> 26:d3:56:98:ca:b4 eth0: ethernet@30000
> => nand scrub 0xFF80000 0x80000  
> 
> NAND scrub: device 0 offset 0xff80000, size 0x80000
> Warning: scrub option will erase all factory set bad blocks!
>           There is no reliable way to recover them.
>           Use this command only for testing purposes if you
>           are sure of what you are doing!
> 
> Really scrub this NAND flash? <y/N>
> y
> Erasing at 0xffe0000 -- 100% complete.
> OK
> => boot  
> 
> Starting kernel ...
> 
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 4.15.0-rc1-00094-g1791eb8f2475-dirty 
> (skn@skn) (gcc version 7.2.0 (Arch Repository)) #30 SMP PREEMPT Tue
> Dec 12 09:28:30 CET 2017
> ...
> [    2.692801] nand: device found, Manufacturer ID: 0x2c, Chip ID:
> 0xda [    2.699176] nand: Micron MT29F2G08ABAEAH4
> [    2.703232] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
> 2048, OOB size: 64
> [    2.710928] nand: NAND_ECC_NONE selected by board driver. This is
> not recommended!
> [    2.718523] nand: WARNING: pxa3xx_nand-0: the ECC used on your
> system is too weak compared to the one required by the NAND chip
> [    2.731429] Bad block table not found for chip 0
> [    2.737384] Bad block table not found for chip 0
> [    2.742024] Scanning device for bad blocks
> [    2.891818] Bad block table written to 0x00000ffe0000, version 0x01
> [    2.898837] Bad block table written to 0x00000ffc0000, version 0x01
> [    2.905152] 2 cmdlinepart partitions found on MTD device
> pxa3xx_nand-0 [    2.911708] Creating 2 MTD partitions on
> "pxa3xx_nand-0": [    2.917130] 0x000000000000-0x000000100000 :
> "uboot" [    2.922512] 0x000000100000-0x000010000000 : "ubi0"
> ...
> output-module login: root
> Password:
> root@output-module:~#
> root@output-module:~# nanddump -nop -l 0x800 -s 0xFF80000 /dev/mtd1
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x0ff80000 and ending at 0x0ff80800...
> root@output-module:~# nanddump -nop -l 0x800 -s 0xFFA0000 /dev/mtd1
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x0ffa0000 and ending at 0x0ffa0800...
> root@output-module:~# nanddump -nop -l 0x800 -s 0xFFC0000 /dev/mtd1
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x0ffc0000 and ending at 0x0ffc0800...
> root@output-module:~# nanddump -nop -l 0x800 -s 0xFFE0000 /dev/mtd1
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x0ffe0000 and ending at 0x0ffe0800...
> root@output-module:~# reboot
> ...
> U-Boot 2017.11-00035-ge9282bb30b-dirty (Dec 12 2017 - 11:22:21 +0100)
> 
> SoC:   MV88F6810-A0 at 1066 MHz
> DRAM:  1 GiB (533 MHz, 16-bit, ECC not enabled)
> WDT:   Enabling Armada 385 watchdog.
> NAND:  PXA3xx: strength 4, ecc_stepsize 512, page_size 2048
> 256 MiB
> Bad block table not found for chip 0
> Bad block table not found for chip 0
> Scanning device for bad blocks
> Bad block table written to 0x00000ffe0000, version 0x01
> Bad block table written to 0x00000ffc0000, version 0x01
> 
> If I reboot uboot is unable recognise the bbt, but recreates it. But
> the kernel is scanning on every boot.
> Am I doing anything wrong in the nanddump command?

I did not realize your NAND had 2 partitions (I though /dev/mtd0 was
something else).

In Linux, the offset your give to nanddump is from the beginning of the
MTD device, not the NAND device. Because /dev/mtd1 starts at 0x100000
(8 blocks are used for U-Boot), you have to substract 0x100000 from the
offsets I gave you otherwise you read beyond the device (ie. nothing).

Please try again with:

        0xFE80000
        0xFEA0000
        0xFEC0000
        0xFEE0000

Thank you,
Miquèl

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-12 11:08                                                       ` Miquel RAYNAL
@ 2017-12-12 11:28                                                         ` Sean Nyekjær
  2017-12-12 11:35                                                           ` Miquel RAYNAL
  0 siblings, 1 reply; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-12 11:28 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon



On 2017-12-12 12:08, Miquel RAYNAL wrote:
> On Tue, 12 Dec 2017 11:55:22 +0100
> Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:
>
>> Hi Miquel
>>> Are you sure your U-Boot does actually use the BBT?
>>>
>>> The last two blocks (supposedly written by U-Boot) are usually
>>> declared bad by Linux when it does not find the BBT. This is not
>>> the case, like if the last blocks were empty.
>>>
>>> Could you try this, still with "ecc-none" and without the
>>> "nand-keep-config" property:
>> &nand_controller {
>>           status = "okay";
>>           pinctrl-names = "default";
>>           pinctrl-0 = <&nand_pins>, <&nand_rb>;
>>
>>           nand@0 {
>>                   reg = <0>;
>>                   label = "pxa3xx_nand-0";
>>                   marvell,rb = <0>;
>>                   nand-ecc-mode = "none";
>>                   nand-on-flash-bbt;
>>       };
>> };
>>> 1/ From U-Boot, scrub the last 4 blocks. As your NAND is 256MiB
>>> wide with 128kiB blocks, this should do the trick:
>>>
>>>           nand scrub 0xFF80000 0x80000
>>>
>>> 2/ At this point, U-Boot should tell you it cannot find a bad block
>>> table, a second later it will tell you that it created it twice at
>>> the end of the NAND chip.
>> Yes uboot is recreating the bbt and after a new reset it recognise
>> the new bbt.
>>> 3/ Boot Linux with ECC == none
>>> 4/ Dump the first page of the 4 last blocks:
>>>
>>>           nanddump -nop -l 0x800 -s <adddr> /dev/mtd1
>> See tracing below
>>> Supposedly that /dev/mtd1 is the _last_ MTD partition of your NAND
>>> device and <addr> being sequentially:
>>>
>>>           0xFF80000
>>>           0xFFA0000
>>>           0xFFC0000
>>>           0xFFE0000
>>>
>>> Please copy/paste the overall trace without any cuts (including
>>> U-Boot traces, literally everything).
>>>   
>>
>> U-Boot 2017.11-00035-ge9282bb30b-dirty (Dec 12 2017 - 11:22:21 +0100)
>>
>> SoC:   MV88F6810-A0 at 1066 MHz
>> DRAM:  1 GiB (533 MHz, 16-bit, ECC not enabled)
>> WDT:   Enabling Armada 385 watchdog.
>> NAND:  PXA3xx: strength 4, ecc_stepsize 512, page_size 2048
>> 256 MiB
>> Bad block table found at page 131008, version 0x01
>> Bad block table found at page 130944, version 0x01
>> Model: Triax dvb-tc output
>> Board: Triax dvb-tc output
>> Net:
>> Warning: ethernet@30000 (eth0) using random MAC address -
>> 26:d3:56:98:ca:b4 eth0: ethernet@30000
>> => nand scrub 0xFF80000 0x80000
>>
>> NAND scrub: device 0 offset 0xff80000, size 0x80000
>> Warning: scrub option will erase all factory set bad blocks!
>>            There is no reliable way to recover them.
>>            Use this command only for testing purposes if you
>>            are sure of what you are doing!
>>
>> Really scrub this NAND flash? <y/N>
>> y
>> Erasing at 0xffe0000 -- 100% complete.
>> OK
>> => boot
>>
>> Starting kernel ...
>>
>> [    0.000000] Booting Linux on physical CPU 0x0
>> [    0.000000] Linux version 4.15.0-rc1-00094-g1791eb8f2475-dirty
>> (skn@skn) (gcc version 7.2.0 (Arch Repository)) #30 SMP PREEMPT Tue
>> Dec 12 09:28:30 CET 2017
>> ...
>> [    2.692801] nand: device found, Manufacturer ID: 0x2c, Chip ID:
>> 0xda [    2.699176] nand: Micron MT29F2G08ABAEAH4
>> [    2.703232] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
>> 2048, OOB size: 64
>> [    2.710928] nand: NAND_ECC_NONE selected by board driver. This is
>> not recommended!
>> [    2.718523] nand: WARNING: pxa3xx_nand-0: the ECC used on your
>> system is too weak compared to the one required by the NAND chip
>> [    2.731429] Bad block table not found for chip 0
>> [    2.737384] Bad block table not found for chip 0
>> [    2.742024] Scanning device for bad blocks
>> [    2.891818] Bad block table written to 0x00000ffe0000, version 0x01
>> [    2.898837] Bad block table written to 0x00000ffc0000, version 0x01
>> [    2.905152] 2 cmdlinepart partitions found on MTD device
>> pxa3xx_nand-0 [    2.911708] Creating 2 MTD partitions on
>> "pxa3xx_nand-0": [    2.917130] 0x000000000000-0x000000100000 :
>> "uboot" [    2.922512] 0x000000100000-0x000010000000 : "ubi0"
>> ...
>> output-module login: root
>> Password:
>> root@output-module:~#
>> root@output-module:~# nanddump -nop -l 0x800 -s 0xFF80000 /dev/mtd1
>> Block size 131072, page size 2048, OOB size 64
>> Dumping data starting at 0x0ff80000 and ending at 0x0ff80800...
>> root@output-module:~# nanddump -nop -l 0x800 -s 0xFFA0000 /dev/mtd1
>> Block size 131072, page size 2048, OOB size 64
>> Dumping data starting at 0x0ffa0000 and ending at 0x0ffa0800...
>> root@output-module:~# nanddump -nop -l 0x800 -s 0xFFC0000 /dev/mtd1
>> Block size 131072, page size 2048, OOB size 64
>> Dumping data starting at 0x0ffc0000 and ending at 0x0ffc0800...
>> root@output-module:~# nanddump -nop -l 0x800 -s 0xFFE0000 /dev/mtd1
>> Block size 131072, page size 2048, OOB size 64
>> Dumping data starting at 0x0ffe0000 and ending at 0x0ffe0800...
>> root@output-module:~# reboot
>> ...
>> U-Boot 2017.11-00035-ge9282bb30b-dirty (Dec 12 2017 - 11:22:21 +0100)
>>
>> SoC:   MV88F6810-A0 at 1066 MHz
>> DRAM:  1 GiB (533 MHz, 16-bit, ECC not enabled)
>> WDT:   Enabling Armada 385 watchdog.
>> NAND:  PXA3xx: strength 4, ecc_stepsize 512, page_size 2048
>> 256 MiB
>> Bad block table not found for chip 0
>> Bad block table not found for chip 0
>> Scanning device for bad blocks
>> Bad block table written to 0x00000ffe0000, version 0x01
>> Bad block table written to 0x00000ffc0000, version 0x01
>>
>> If I reboot uboot is unable recognise the bbt, but recreates it. But
>> the kernel is scanning on every boot.
>> Am I doing anything wrong in the nanddump command?
> I did not realize your NAND had 2 partitions (I though /dev/mtd0 was
> something else).
Sorry i should have said that :-)
>
> In Linux, the offset your give to nanddump is from the beginning of the
> MTD device, not the NAND device. Because /dev/mtd1 starts at 0x100000
> (8 blocks are used for U-Boot), you have to substract 0x100000 from the
> offsets I gave you otherwise you read beyond the device (ie. nothing).
>
> Please try again with:
>
>          0xFE80000
>          0xFEA0000
>          0xFEC0000
>          0xFEE0000
root@wandboard:~# nanddump -nop -l 0x800 -s 0xFE80000 /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fe80000 and ending at 0x0fe80800...
root@wandboard:~# nanddump -nop -l 0x800 -s 0xFEA0000 /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fea0000 and ending at 0x0fea0800...
root@wandboard:~# nanddump -nop -l 0x800 -s 0xFEC0000 /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fec0000 and ending at 0x0fec0800...
root@wandboard:~# nanddump -nop -l 0x800 -s 0xFEE0000 /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fee0000 and ending at 0x0fee0800...

/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-12 11:28                                                         ` Sean Nyekjær
@ 2017-12-12 11:35                                                           ` Miquel RAYNAL
  2017-12-12 11:49                                                             ` Sean Nyekjær
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-12 11:35 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

On Tue, 12 Dec 2017 12:28:46 +0100
Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:

> On 2017-12-12 12:08, Miquel RAYNAL wrote:
> > On Tue, 12 Dec 2017 11:55:22 +0100
> > Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:
> >  
> >> Hi Miquel  
> >>> Are you sure your U-Boot does actually use the BBT?
> >>>
> >>> The last two blocks (supposedly written by U-Boot) are usually
> >>> declared bad by Linux when it does not find the BBT. This is not
> >>> the case, like if the last blocks were empty.
> >>>
> >>> Could you try this, still with "ecc-none" and without the
> >>> "nand-keep-config" property:  
> >> &nand_controller {
> >>           status = "okay";
> >>           pinctrl-names = "default";
> >>           pinctrl-0 = <&nand_pins>, <&nand_rb>;
> >>
> >>           nand@0 {
> >>                   reg = <0>;
> >>                   label = "pxa3xx_nand-0";
> >>                   marvell,rb = <0>;
> >>                   nand-ecc-mode = "none";
> >>                   nand-on-flash-bbt;
> >>       };
> >> };  
> >>> 1/ From U-Boot, scrub the last 4 blocks. As your NAND is 256MiB
> >>> wide with 128kiB blocks, this should do the trick:
> >>>
> >>>           nand scrub 0xFF80000 0x80000
> >>>
> >>> 2/ At this point, U-Boot should tell you it cannot find a bad
> >>> block table, a second later it will tell you that it created it
> >>> twice at the end of the NAND chip.  
> >> Yes uboot is recreating the bbt and after a new reset it recognise
> >> the new bbt.  
> >>> 3/ Boot Linux with ECC == none
> >>> 4/ Dump the first page of the 4 last blocks:
> >>>
> >>>           nanddump -nop -l 0x800 -s <adddr> /dev/mtd1  
> >> See tracing below  
> >>> Supposedly that /dev/mtd1 is the _last_ MTD partition of your NAND
> >>> device and <addr> being sequentially:
> >>>
> >>>           0xFF80000
> >>>           0xFFA0000
> >>>           0xFFC0000
> >>>           0xFFE0000
> >>>
> >>> Please copy/paste the overall trace without any cuts (including
> >>> U-Boot traces, literally everything).
> >>>     
> >>
> >> U-Boot 2017.11-00035-ge9282bb30b-dirty (Dec 12 2017 - 11:22:21
> >> +0100)
> >>
> >> SoC:   MV88F6810-A0 at 1066 MHz
> >> DRAM:  1 GiB (533 MHz, 16-bit, ECC not enabled)
> >> WDT:   Enabling Armada 385 watchdog.
> >> NAND:  PXA3xx: strength 4, ecc_stepsize 512, page_size 2048
> >> 256 MiB
> >> Bad block table found at page 131008, version 0x01
> >> Bad block table found at page 130944, version 0x01
> >> Model: Triax dvb-tc output
> >> Board: Triax dvb-tc output
> >> Net:
> >> Warning: ethernet@30000 (eth0) using random MAC address -
> >> 26:d3:56:98:ca:b4 eth0: ethernet@30000  
> >> => nand scrub 0xFF80000 0x80000  
> >>
> >> NAND scrub: device 0 offset 0xff80000, size 0x80000
> >> Warning: scrub option will erase all factory set bad blocks!
> >>            There is no reliable way to recover them.
> >>            Use this command only for testing purposes if you
> >>            are sure of what you are doing!
> >>
> >> Really scrub this NAND flash? <y/N>
> >> y
> >> Erasing at 0xffe0000 -- 100% complete.
> >> OK  
> >> => boot  
> >>
> >> Starting kernel ...
> >>
> >> [    0.000000] Booting Linux on physical CPU 0x0
> >> [    0.000000] Linux version 4.15.0-rc1-00094-g1791eb8f2475-dirty
> >> (skn@skn) (gcc version 7.2.0 (Arch Repository)) #30 SMP PREEMPT Tue
> >> Dec 12 09:28:30 CET 2017
> >> ...
> >> [    2.692801] nand: device found, Manufacturer ID: 0x2c, Chip ID:
> >> 0xda [    2.699176] nand: Micron MT29F2G08ABAEAH4
> >> [    2.703232] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
> >> 2048, OOB size: 64
> >> [    2.710928] nand: NAND_ECC_NONE selected by board driver. This
> >> is not recommended!
> >> [    2.718523] nand: WARNING: pxa3xx_nand-0: the ECC used on your
> >> system is too weak compared to the one required by the NAND chip
> >> [    2.731429] Bad block table not found for chip 0
> >> [    2.737384] Bad block table not found for chip 0
> >> [    2.742024] Scanning device for bad blocks
> >> [    2.891818] Bad block table written to 0x00000ffe0000, version
> >> 0x01 [    2.898837] Bad block table written to 0x00000ffc0000,
> >> version 0x01 [    2.905152] 2 cmdlinepart partitions found on MTD
> >> device pxa3xx_nand-0 [    2.911708] Creating 2 MTD partitions on
> >> "pxa3xx_nand-0": [    2.917130] 0x000000000000-0x000000100000 :
> >> "uboot" [    2.922512] 0x000000100000-0x000010000000 : "ubi0"
> >> ...
> >> output-module login: root
> >> Password:
> >> root@output-module:~#
> >> root@output-module:~# nanddump -nop -l 0x800 -s 0xFF80000 /dev/mtd1
> >> Block size 131072, page size 2048, OOB size 64
> >> Dumping data starting at 0x0ff80000 and ending at 0x0ff80800...
> >> root@output-module:~# nanddump -nop -l 0x800 -s 0xFFA0000 /dev/mtd1
> >> Block size 131072, page size 2048, OOB size 64
> >> Dumping data starting at 0x0ffa0000 and ending at 0x0ffa0800...
> >> root@output-module:~# nanddump -nop -l 0x800 -s 0xFFC0000 /dev/mtd1
> >> Block size 131072, page size 2048, OOB size 64
> >> Dumping data starting at 0x0ffc0000 and ending at 0x0ffc0800...
> >> root@output-module:~# nanddump -nop -l 0x800 -s 0xFFE0000 /dev/mtd1
> >> Block size 131072, page size 2048, OOB size 64
> >> Dumping data starting at 0x0ffe0000 and ending at 0x0ffe0800...
> >> root@output-module:~# reboot
> >> ...
> >> U-Boot 2017.11-00035-ge9282bb30b-dirty (Dec 12 2017 - 11:22:21
> >> +0100)
> >>
> >> SoC:   MV88F6810-A0 at 1066 MHz
> >> DRAM:  1 GiB (533 MHz, 16-bit, ECC not enabled)
> >> WDT:   Enabling Armada 385 watchdog.
> >> NAND:  PXA3xx: strength 4, ecc_stepsize 512, page_size 2048
> >> 256 MiB
> >> Bad block table not found for chip 0
> >> Bad block table not found for chip 0
> >> Scanning device for bad blocks
> >> Bad block table written to 0x00000ffe0000, version 0x01
> >> Bad block table written to 0x00000ffc0000, version 0x01
> >>
> >> If I reboot uboot is unable recognise the bbt, but recreates it.
> >> But the kernel is scanning on every boot.
> >> Am I doing anything wrong in the nanddump command?  
> > I did not realize your NAND had 2 partitions (I though /dev/mtd0 was
> > something else).  
> Sorry i should have said that :-)
> >
> > In Linux, the offset your give to nanddump is from the beginning of
> > the MTD device, not the NAND device. Because /dev/mtd1 starts at
> > 0x100000 (8 blocks are used for U-Boot), you have to substract
> > 0x100000 from the offsets I gave you otherwise you read beyond the
> > device (ie. nothing).
> >
> > Please try again with:
> >
> >          0xFE80000
> >          0xFEA0000
> >          0xFEC0000
> >          0xFEE0000  
> root@wandboard:~# nanddump -nop -l 0x800 -s 0xFE80000 /dev/mtd1
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x0fe80000 and ending at 0x0fe80800...
> root@wandboard:~# nanddump -nop -l 0x800 -s 0xFEA0000 /dev/mtd1
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x0fea0000 and ending at 0x0fea0800...
> root@wandboard:~# nanddump -nop -l 0x800 -s 0xFEC0000 /dev/mtd1
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x0fec0000 and ending at 0x0fec0800...
> root@wandboard:~# nanddump -nop -l 0x800 -s 0xFEE0000 /dev/mtd1
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x0fee0000 and ending at 0x0fee0800...
> 

Failure is on me for this one: Linux marks the block containing the BBT
as bad to avoid user accesses on it, please use --bb=dumpbad in the
nanddump command.

Once you will have the trace, please do the same again without
on-flash-bbt, this way we can compare both U-Boot and Linux layouts and
find what is wrong.

Thank you,
Miquèl

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-12 11:35                                                           ` Miquel RAYNAL
@ 2017-12-12 11:49                                                             ` Sean Nyekjær
  2017-12-12 12:47                                                               ` Miquel RAYNAL
  0 siblings, 1 reply; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-12 11:49 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi Miquel,
> On Tue, 12 Dec 2017 12:28:46 +0100
> Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:
>
>> On 2017-12-12 12:08, Miquel RAYNAL wrote:
>>> On Tue, 12 Dec 2017 11:55:22 +0100
>>> Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:
>>>   
>>>> Hi Miquel
>>>>> Are you sure your U-Boot does actually use the BBT?
>>>>>
>>>>> The last two blocks (supposedly written by U-Boot) are usually
>>>>> declared bad by Linux when it does not find the BBT. This is not
>>>>> the case, like if the last blocks were empty.
>>>>>
>>>>> Could you try this, still with "ecc-none" and without the
>>>>> "nand-keep-config" property:
>>>> &nand_controller {
>>>>            status = "okay";
>>>>            pinctrl-names = "default";
>>>>            pinctrl-0 = <&nand_pins>, <&nand_rb>;
>>>>
>>>>            nand@0 {
>>>>                    reg = <0>;
>>>>                    label = "pxa3xx_nand-0";
>>>>                    marvell,rb = <0>;
>>>>                    nand-ecc-mode = "none";
>>>>                    nand-on-flash-bbt;
>>>>        };
>>>> };
>>>>> 1/ From U-Boot, scrub the last 4 blocks. As your NAND is 256MiB
>>>>> wide with 128kiB blocks, this should do the trick:
>>>>>
>>>>>            nand scrub 0xFF80000 0x80000
>>>>>
>>>>> 2/ At this point, U-Boot should tell you it cannot find a bad
>>>>> block table, a second later it will tell you that it created it
>>>>> twice at the end of the NAND chip.
>>>> Yes uboot is recreating the bbt and after a new reset it recognise
>>>> the new bbt.
>>>>> 3/ Boot Linux with ECC == none
>>>>> 4/ Dump the first page of the 4 last blocks:
>>>>>
>>>>>            nanddump -nop -l 0x800 -s <adddr> /dev/mtd1
>>>> See tracing below
>>>>> Supposedly that /dev/mtd1 is the _last_ MTD partition of your NAND
>>>>> device and <addr> being sequentially:
>>>>>
>>>>>            0xFF80000
>>>>>            0xFFA0000
>>>>>            0xFFC0000
>>>>>            0xFFE0000
>>>>>
>>>>> Please copy/paste the overall trace without any cuts (including
>>>>> U-Boot traces, literally everything).
>>>>>      
>>>> U-Boot 2017.11-00035-ge9282bb30b-dirty (Dec 12 2017 - 11:22:21
>>>> +0100)
>>>>
>>>> SoC:   MV88F6810-A0 at 1066 MHz
>>>> DRAM:  1 GiB (533 MHz, 16-bit, ECC not enabled)
>>>> WDT:   Enabling Armada 385 watchdog.
>>>> NAND:  PXA3xx: strength 4, ecc_stepsize 512, page_size 2048
>>>> 256 MiB
>>>> Bad block table found at page 131008, version 0x01
>>>> Bad block table found at page 130944, version 0x01
>>>> Model: Triax dvb-tc output
>>>> Board: Triax dvb-tc output
>>>> Net:
>>>> Warning: ethernet@30000 (eth0) using random MAC address -
>>>> 26:d3:56:98:ca:b4 eth0: ethernet@30000
>>>> => nand scrub 0xFF80000 0x80000
>>>>
>>>> NAND scrub: device 0 offset 0xff80000, size 0x80000
>>>> Warning: scrub option will erase all factory set bad blocks!
>>>>             There is no reliable way to recover them.
>>>>             Use this command only for testing purposes if you
>>>>             are sure of what you are doing!
>>>>
>>>> Really scrub this NAND flash? <y/N>
>>>> y
>>>> Erasing at 0xffe0000 -- 100% complete.
>>>> OK
>>>> => boot
>>>>
>>>> Starting kernel ...
>>>>
>>>> [    0.000000] Booting Linux on physical CPU 0x0
>>>> [    0.000000] Linux version 4.15.0-rc1-00094-g1791eb8f2475-dirty
>>>> (skn@skn) (gcc version 7.2.0 (Arch Repository)) #30 SMP PREEMPT Tue
>>>> Dec 12 09:28:30 CET 2017
>>>> ...
>>>> [    2.692801] nand: device found, Manufacturer ID: 0x2c, Chip ID:
>>>> 0xda [    2.699176] nand: Micron MT29F2G08ABAEAH4
>>>> [    2.703232] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
>>>> 2048, OOB size: 64
>>>> [    2.710928] nand: NAND_ECC_NONE selected by board driver. This
>>>> is not recommended!
>>>> [    2.718523] nand: WARNING: pxa3xx_nand-0: the ECC used on your
>>>> system is too weak compared to the one required by the NAND chip
>>>> [    2.731429] Bad block table not found for chip 0
>>>> [    2.737384] Bad block table not found for chip 0
>>>> [    2.742024] Scanning device for bad blocks
>>>> [    2.891818] Bad block table written to 0x00000ffe0000, version
>>>> 0x01 [    2.898837] Bad block table written to 0x00000ffc0000,
>>>> version 0x01 [    2.905152] 2 cmdlinepart partitions found on MTD
>>>> device pxa3xx_nand-0 [    2.911708] Creating 2 MTD partitions on
>>>> "pxa3xx_nand-0": [    2.917130] 0x000000000000-0x000000100000 :
>>>> "uboot" [    2.922512] 0x000000100000-0x000010000000 : "ubi0"
>>>> ...
>>>> output-module login: root
>>>> Password:
>>>> root@output-module:~#
>>>> root@output-module:~# nanddump -nop -l 0x800 -s 0xFF80000 /dev/mtd1
>>>> Block size 131072, page size 2048, OOB size 64
>>>> Dumping data starting at 0x0ff80000 and ending at 0x0ff80800...
>>>> root@output-module:~# nanddump -nop -l 0x800 -s 0xFFA0000 /dev/mtd1
>>>> Block size 131072, page size 2048, OOB size 64
>>>> Dumping data starting at 0x0ffa0000 and ending at 0x0ffa0800...
>>>> root@output-module:~# nanddump -nop -l 0x800 -s 0xFFC0000 /dev/mtd1
>>>> Block size 131072, page size 2048, OOB size 64
>>>> Dumping data starting at 0x0ffc0000 and ending at 0x0ffc0800...
>>>> root@output-module:~# nanddump -nop -l 0x800 -s 0xFFE0000 /dev/mtd1
>>>> Block size 131072, page size 2048, OOB size 64
>>>> Dumping data starting at 0x0ffe0000 and ending at 0x0ffe0800...
>>>> root@output-module:~# reboot
>>>> ...
>>>> U-Boot 2017.11-00035-ge9282bb30b-dirty (Dec 12 2017 - 11:22:21
>>>> +0100)
>>>>
>>>> SoC:   MV88F6810-A0 at 1066 MHz
>>>> DRAM:  1 GiB (533 MHz, 16-bit, ECC not enabled)
>>>> WDT:   Enabling Armada 385 watchdog.
>>>> NAND:  PXA3xx: strength 4, ecc_stepsize 512, page_size 2048
>>>> 256 MiB
>>>> Bad block table not found for chip 0
>>>> Bad block table not found for chip 0
>>>> Scanning device for bad blocks
>>>> Bad block table written to 0x00000ffe0000, version 0x01
>>>> Bad block table written to 0x00000ffc0000, version 0x01
>>>>
>>>> If I reboot uboot is unable recognise the bbt, but recreates it.
>>>> But the kernel is scanning on every boot.
>>>> Am I doing anything wrong in the nanddump command?
>>> I did not realize your NAND had 2 partitions (I though /dev/mtd0 was
>>> something else).
>> Sorry i should have said that :-)
>>> In Linux, the offset your give to nanddump is from the beginning of
>>> the MTD device, not the NAND device. Because /dev/mtd1 starts at
>>> 0x100000 (8 blocks are used for U-Boot), you have to substract
>>> 0x100000 from the offsets I gave you otherwise you read beyond the
>>> device (ie. nothing).
>>>
>>> Please try again with:
>>>
>>>           0xFE80000
>>>           0xFEA0000
>>>           0xFEC0000
>>>           0xFEE0000
>> root@wandboard:~# nanddump -nop -l 0x800 -s 0xFE80000 /dev/mtd1
>> Block size 131072, page size 2048, OOB size 64
>> Dumping data starting at 0x0fe80000 and ending at 0x0fe80800...
>> root@wandboard:~# nanddump -nop -l 0x800 -s 0xFEA0000 /dev/mtd1
>> Block size 131072, page size 2048, OOB size 64
>> Dumping data starting at 0x0fea0000 and ending at 0x0fea0800...
>> root@wandboard:~# nanddump -nop -l 0x800 -s 0xFEC0000 /dev/mtd1
>> Block size 131072, page size 2048, OOB size 64
>> Dumping data starting at 0x0fec0000 and ending at 0x0fec0800...
>> root@wandboard:~# nanddump -nop -l 0x800 -s 0xFEE0000 /dev/mtd1
>> Block size 131072, page size 2048, OOB size 64
>> Dumping data starting at 0x0fee0000 and ending at 0x0fee0800...
>>
> Failure is on me for this one: Linux marks the block containing the BBT
> as bad to avoid user accesses on it, please use --bb=dumpbad in the
> nanddump command.
nanddump -nop -l 0x800 -s 0xFE80000  --bb=dumpbad /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fe80000 and ending at 0x0fe80800...
0x0fe80000: 55 42 49 23 01 00 00 00 00 00 00 00 00 00 00 01
0x0fe80010: 00 00 08 00 00 00 10 00 00 00 00 00 00 00 00 00
0x0fe80020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80030: 00 00 00 00 00 00 00 00 00 00 00 00 7f 58 53 19
0x0fe80040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe800a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe800b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe800c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe800d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe800e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe800f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe801a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe801b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe801c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe801d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe801e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe801f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe802a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe802b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe802c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe802d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe802e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe802f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80310: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe803a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe803b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe803c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe803d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe803e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe803f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe804a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe804b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe804c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe804d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe804e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe804f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe805a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe805b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe805c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe805d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe805e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe805f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe806a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe806b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe806c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe806d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe806e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe806f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80710: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe80790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe807a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe807b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe807c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe807d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe807e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe807f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: c1 eb aa 03 d3 5c d8 ae fa fd ba 34 2a a5 20 38
   OOB Data: fd 0b 22 59 c1 8c 3c a5 a4 62 df f2 d4 7e ff ff

nanddump -nop -l 0x800 -s 0xFEA0000  --bb=dumpbad /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fea0000 and ending at 0x0fea0800...
0x0fea0000: 55 42 49 23 01 00 00 00 00 00 00 00 00 00 00 01
0x0fea0010: 00 00 08 00 00 00 10 00 00 00 00 00 00 00 00 00
0x0fea0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0030: 00 00 00 00 00 00 00 00 00 00 00 00 7f 58 53 19
0x0fea0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea01a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea01b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea01c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea01d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea01e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea01f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea02a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea02b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea02c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea02d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea02e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea02f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0310: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea03a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea03b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea03c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea03d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea03e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea03f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea04a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea04b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea04c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea04d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea04e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea04f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea05a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea05b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea05c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea05d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea05e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea05f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea06a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea06b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea06c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea06d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea06e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea06f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0710: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea0790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea07a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea07b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea07c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea07d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea07e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fea07f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: c1 eb aa 03 d3 5c d8 ae fa fd ba 34 2a a5 20 38
   OOB Data: fd 0b 22 59 c1 8c 3c a5 a4 62 df f2 d4 7e ff ff

nanddump -nop -l 0x800 -s 0xFEC0000  --bb=dumpbad /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fec0000 and ending at 0x0fec0800...
0x0fec0000: 55 42 49 23 01 00 00 00 00 00 00 00 00 00 00 07
0x0fec0010: 00 00 08 00 00 00 10 00 00 00 00 00 00 00 00 00
0x0fec0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 ce ae 33
0x0fec0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec01a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec01b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec01c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec01d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec01e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec01f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec02a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec02b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec02c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec02d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec02e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec02f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0310: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec03a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec03b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec03c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec03d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec03e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec03f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec04a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec04b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec04c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec04d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec04e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec04f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec05a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec05b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec05c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec05d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec05e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec05f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec06a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec06b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec06c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec06d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec06e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec06f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0710: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec0790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec07a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec07b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec07c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec07d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec07e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fec07f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   OOB Data: ff ff ff ff ff ff ff ff 31 74 62 42 56 4d 01 ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: 35 5d 8f b6 13 7e 01 97 f5 09 1d a5 6f 06 05 2b
   OOB Data: ae c6 8c d5 73 ac 38 4e 61 0f c7 99 cc 5a ff ff

nanddump -nop -l 0x800 -s 0xFEE0000  --bb=dumpbad /dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fee0000 and ending at 0x0fee0800...
0x0fee0000: 55 42 49 23 01 00 00 00 00 00 00 00 00 00 00 07
0x0fee0010: 00 00 08 00 00 00 10 00 00 00 00 00 00 00 00 00
0x0fee0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 ce ae 33
0x0fee0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee01a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee01b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee01c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee01d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee01e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee01f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee02a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee02b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee02c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee02d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee02e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee02f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0310: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee03a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee03b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee03c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee03d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee03e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee03f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee04a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee04b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee04c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee04d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee04e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee04f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee05a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee05b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee05c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee05d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee05e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee05f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee06a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee06b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee06c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee06d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee06e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee06f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0710: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee0790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee07a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee07b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee07c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee07d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee07e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fee07f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   OOB Data: ff ff ff ff ff ff ff ff 4d 56 42 62 74 30 01 ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: 35 5d 8f b6 13 7e 01 97 f5 09 1d a5 6f 06 05 2b
   OOB Data: ae c6 8c d5 73 ac 38 4e 61 0f c7 99 cc 5a ff ff


>
> Once you will have the trace, please do the same again without
> on-flash-bbt, this way we can compare both U-Boot and Linux layouts and
> find what is wrong.
>
Should I compile a new uboot without on-flash-bbt, disable it in the 
kernel dts and finally scrub the last nand pages?

/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-12 11:49                                                             ` Sean Nyekjær
@ 2017-12-12 12:47                                                               ` Miquel RAYNAL
  2017-12-12 13:09                                                                 ` Sean Nyekjær
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-12 12:47 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

On Tue, 12 Dec 2017 12:49:35 +0100
Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:

> Hi Miquel,
> > On Tue, 12 Dec 2017 12:28:46 +0100
> > Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:
> >  
> >> On 2017-12-12 12:08, Miquel RAYNAL wrote:  
> >>> On Tue, 12 Dec 2017 11:55:22 +0100
> >>> Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:
> >>>     
> >>>> Hi Miquel  
> >>>>> Are you sure your U-Boot does actually use the BBT?
> >>>>>
> >>>>> The last two blocks (supposedly written by U-Boot) are usually
> >>>>> declared bad by Linux when it does not find the BBT. This is not
> >>>>> the case, like if the last blocks were empty.
> >>>>>
> >>>>> Could you try this, still with "ecc-none" and without the
> >>>>> "nand-keep-config" property:  
> >>>> &nand_controller {
> >>>>            status = "okay";
> >>>>            pinctrl-names = "default";
> >>>>            pinctrl-0 = <&nand_pins>, <&nand_rb>;
> >>>>
> >>>>            nand@0 {
> >>>>                    reg = <0>;
> >>>>                    label = "pxa3xx_nand-0";
> >>>>                    marvell,rb = <0>;
> >>>>                    nand-ecc-mode = "none";
> >>>>                    nand-on-flash-bbt;
> >>>>        };
> >>>> };  
> >>>>> 1/ From U-Boot, scrub the last 4 blocks. As your NAND is 256MiB
> >>>>> wide with 128kiB blocks, this should do the trick:
> >>>>>
> >>>>>            nand scrub 0xFF80000 0x80000
> >>>>>
> >>>>> 2/ At this point, U-Boot should tell you it cannot find a bad
> >>>>> block table, a second later it will tell you that it created it
> >>>>> twice at the end of the NAND chip.  
> >>>> Yes uboot is recreating the bbt and after a new reset it
> >>>> recognise the new bbt.  
> >>>>> 3/ Boot Linux with ECC == none
> >>>>> 4/ Dump the first page of the 4 last blocks:
> >>>>>
> >>>>>            nanddump -nop -l 0x800 -s <adddr> /dev/mtd1  
> >>>> See tracing below  
> >>>>> Supposedly that /dev/mtd1 is the _last_ MTD partition of your
> >>>>> NAND device and <addr> being sequentially:
> >>>>>
> >>>>>            0xFF80000
> >>>>>            0xFFA0000
> >>>>>            0xFFC0000
> >>>>>            0xFFE0000
> >>>>>
> >>>>> Please copy/paste the overall trace without any cuts (including
> >>>>> U-Boot traces, literally everything).
> >>>>>        
> >>>> U-Boot 2017.11-00035-ge9282bb30b-dirty (Dec 12 2017 - 11:22:21
> >>>> +0100)
> >>>>
> >>>> SoC:   MV88F6810-A0 at 1066 MHz
> >>>> DRAM:  1 GiB (533 MHz, 16-bit, ECC not enabled)
> >>>> WDT:   Enabling Armada 385 watchdog.
> >>>> NAND:  PXA3xx: strength 4, ecc_stepsize 512, page_size 2048
> >>>> 256 MiB
> >>>> Bad block table found at page 131008, version 0x01
> >>>> Bad block table found at page 130944, version 0x01
> >>>> Model: Triax dvb-tc output
> >>>> Board: Triax dvb-tc output
> >>>> Net:
> >>>> Warning: ethernet@30000 (eth0) using random MAC address -
> >>>> 26:d3:56:98:ca:b4 eth0: ethernet@30000  
> >>>> => nand scrub 0xFF80000 0x80000  
> >>>>
> >>>> NAND scrub: device 0 offset 0xff80000, size 0x80000
> >>>> Warning: scrub option will erase all factory set bad blocks!
> >>>>             There is no reliable way to recover them.
> >>>>             Use this command only for testing purposes if you
> >>>>             are sure of what you are doing!
> >>>>
> >>>> Really scrub this NAND flash? <y/N>
> >>>> y
> >>>> Erasing at 0xffe0000 -- 100% complete.
> >>>> OK  
> >>>> => boot  
> >>>>
> >>>> Starting kernel ...
> >>>>
> >>>> [    0.000000] Booting Linux on physical CPU 0x0
> >>>> [    0.000000] Linux version 4.15.0-rc1-00094-g1791eb8f2475-dirty
> >>>> (skn@skn) (gcc version 7.2.0 (Arch Repository)) #30 SMP PREEMPT
> >>>> Tue Dec 12 09:28:30 CET 2017
> >>>> ...
> >>>> [    2.692801] nand: device found, Manufacturer ID: 0x2c, Chip
> >>>> ID: 0xda [    2.699176] nand: Micron MT29F2G08ABAEAH4
> >>>> [    2.703232] nand: 256 MiB, SLC, erase size: 128 KiB, page
> >>>> size: 2048, OOB size: 64
> >>>> [    2.710928] nand: NAND_ECC_NONE selected by board driver. This
> >>>> is not recommended!
> >>>> [    2.718523] nand: WARNING: pxa3xx_nand-0: the ECC used on your
> >>>> system is too weak compared to the one required by the NAND chip
> >>>> [    2.731429] Bad block table not found for chip 0
> >>>> [    2.737384] Bad block table not found for chip 0
> >>>> [    2.742024] Scanning device for bad blocks
> >>>> [    2.891818] Bad block table written to 0x00000ffe0000, version
> >>>> 0x01 [    2.898837] Bad block table written to 0x00000ffc0000,
> >>>> version 0x01 [    2.905152] 2 cmdlinepart partitions found on MTD
> >>>> device pxa3xx_nand-0 [    2.911708] Creating 2 MTD partitions on
> >>>> "pxa3xx_nand-0": [    2.917130] 0x000000000000-0x000000100000 :
> >>>> "uboot" [    2.922512] 0x000000100000-0x000010000000 : "ubi0"
> >>>> ...
> >>>> output-module login: root
> >>>> Password:
> >>>> root@output-module:~#
> >>>> root@output-module:~# nanddump -nop -l 0x800 -s
> >>>> 0xFF80000 /dev/mtd1 Block size 131072, page size 2048, OOB size
> >>>> 64 Dumping data starting at 0x0ff80000 and ending at
> >>>> 0x0ff80800... root@output-module:~# nanddump -nop -l 0x800 -s
> >>>> 0xFFA0000 /dev/mtd1 Block size 131072, page size 2048, OOB size
> >>>> 64 Dumping data starting at 0x0ffa0000 and ending at
> >>>> 0x0ffa0800... root@output-module:~# nanddump -nop -l 0x800 -s
> >>>> 0xFFC0000 /dev/mtd1 Block size 131072, page size 2048, OOB size
> >>>> 64 Dumping data starting at 0x0ffc0000 and ending at
> >>>> 0x0ffc0800... root@output-module:~# nanddump -nop -l 0x800 -s
> >>>> 0xFFE0000 /dev/mtd1 Block size 131072, page size 2048, OOB size
> >>>> 64 Dumping data starting at 0x0ffe0000 and ending at
> >>>> 0x0ffe0800... root@output-module:~# reboot
> >>>> ...
> >>>> U-Boot 2017.11-00035-ge9282bb30b-dirty (Dec 12 2017 - 11:22:21
> >>>> +0100)
> >>>>
> >>>> SoC:   MV88F6810-A0 at 1066 MHz
> >>>> DRAM:  1 GiB (533 MHz, 16-bit, ECC not enabled)
> >>>> WDT:   Enabling Armada 385 watchdog.
> >>>> NAND:  PXA3xx: strength 4, ecc_stepsize 512, page_size 2048
> >>>> 256 MiB
> >>>> Bad block table not found for chip 0
> >>>> Bad block table not found for chip 0
> >>>> Scanning device for bad blocks
> >>>> Bad block table written to 0x00000ffe0000, version 0x01
> >>>> Bad block table written to 0x00000ffc0000, version 0x01
> >>>>
> >>>> If I reboot uboot is unable recognise the bbt, but recreates it.
> >>>> But the kernel is scanning on every boot.
> >>>> Am I doing anything wrong in the nanddump command?  
> >>> I did not realize your NAND had 2 partitions (I though /dev/mtd0
> >>> was something else).  
> >> Sorry i should have said that :-)  
> >>> In Linux, the offset your give to nanddump is from the beginning
> >>> of the MTD device, not the NAND device. Because /dev/mtd1 starts
> >>> at 0x100000 (8 blocks are used for U-Boot), you have to substract
> >>> 0x100000 from the offsets I gave you otherwise you read beyond the
> >>> device (ie. nothing).
> >>>
> >>> Please try again with:
> >>>
> >>>           0xFE80000
> >>>           0xFEA0000
> >>>           0xFEC0000
> >>>           0xFEE0000  
> >> root@wandboard:~# nanddump -nop -l 0x800 -s 0xFE80000 /dev/mtd1
> >> Block size 131072, page size 2048, OOB size 64
> >> Dumping data starting at 0x0fe80000 and ending at 0x0fe80800...
> >> root@wandboard:~# nanddump -nop -l 0x800 -s 0xFEA0000 /dev/mtd1
> >> Block size 131072, page size 2048, OOB size 64
> >> Dumping data starting at 0x0fea0000 and ending at 0x0fea0800...
> >> root@wandboard:~# nanddump -nop -l 0x800 -s 0xFEC0000 /dev/mtd1
> >> Block size 131072, page size 2048, OOB size 64
> >> Dumping data starting at 0x0fec0000 and ending at 0x0fec0800...
> >> root@wandboard:~# nanddump -nop -l 0x800 -s 0xFEE0000 /dev/mtd1
> >> Block size 131072, page size 2048, OOB size 64
> >> Dumping data starting at 0x0fee0000 and ending at 0x0fee0800...
> >>  
> > Failure is on me for this one: Linux marks the block containing the
> > BBT as bad to avoid user accesses on it, please use --bb=dumpbad in
> > the nanddump command.  
> nanddump -nop -l 0x800 -s 0xFE80000  --bb=dumpbad /dev/mtd1
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x0fe80000 and ending at 0x0fe80800...
> 0x0fe80000: 55 42 49 23 01 00 00 00 00 00 00 00 00 00 00 01
> 0x0fe80010: 00 00 08 00 00 00 10 00 00 00 00 00 00 00 00 00
> 0x0fe80020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80030: 00 00 00 00 00 00 00 00 00 00 00 00 7f 58 53 19
> 0x0fe80040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe800a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe800b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe800c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe800d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe800e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe800f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe801a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe801b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe801c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe801d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe801e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe801f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe802a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe802b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe802c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe802d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe802e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe802f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80310: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe803a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe803b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe803c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe803d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe803e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe803f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe804a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe804b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe804c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe804d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe804e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe804f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe805a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe805b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe805c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe805d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe805e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe805f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe806a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe806b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe806c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe806d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe806e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe806f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80710: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe80790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe807a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe807b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe807c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe807d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe807e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fe807f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>    OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>    OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>    OOB Data: c1 eb aa 03 d3 5c d8 ae fa fd ba 34 2a a5 20 38
>    OOB Data: fd 0b 22 59 c1 8c 3c a5 a4 62 df f2 d4 7e ff ff
> 
> nanddump -nop -l 0x800 -s 0xFEA0000  --bb=dumpbad /dev/mtd1
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x0fea0000 and ending at 0x0fea0800...
> 0x0fea0000: 55 42 49 23 01 00 00 00 00 00 00 00 00 00 00 01
> 0x0fea0010: 00 00 08 00 00 00 10 00 00 00 00 00 00 00 00 00
> 0x0fea0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0030: 00 00 00 00 00 00 00 00 00 00 00 00 7f 58 53 19
> 0x0fea0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea01a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea01b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea01c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea01d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea01e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea01f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea02a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea02b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea02c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea02d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea02e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea02f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0310: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea03a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea03b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea03c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea03d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea03e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea03f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea04a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea04b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea04c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea04d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea04e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea04f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea05a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea05b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea05c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea05d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea05e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea05f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea06a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea06b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea06c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea06d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea06e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea06f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0710: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea0790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea07a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea07b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea07c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea07d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea07e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fea07f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>    OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>    OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>    OOB Data: c1 eb aa 03 d3 5c d8 ae fa fd ba 34 2a a5 20 38
>    OOB Data: fd 0b 22 59 c1 8c 3c a5 a4 62 df f2 d4 7e ff ff
> 
> nanddump -nop -l 0x800 -s 0xFEC0000  --bb=dumpbad /dev/mtd1
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x0fec0000 and ending at 0x0fec0800...
> 0x0fec0000: 55 42 49 23 01 00 00 00 00 00 00 00 00 00 00 07
> 0x0fec0010: 00 00 08 00 00 00 10 00 00 00 00 00 00 00 00 00
> 0x0fec0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 ce ae 33
> 0x0fec0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec01a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec01b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec01c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec01d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec01e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec01f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec02a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec02b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec02c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec02d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec02e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec02f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0310: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec03a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec03b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec03c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec03d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec03e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec03f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec04a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec04b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec04c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec04d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec04e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec04f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec05a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec05b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec05c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec05d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec05e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec05f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec06a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec06b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec06c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec06d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec06e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec06f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0710: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec0790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec07a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec07b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec07c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec07d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec07e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fec07f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>    OOB Data: ff ff ff ff ff ff ff ff 31 74 62 42 56 4d 01 ff
>    OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>    OOB Data: 35 5d 8f b6 13 7e 01 97 f5 09 1d a5 6f 06 05 2b
>    OOB Data: ae c6 8c d5 73 ac 38 4e 61 0f c7 99 cc 5a ff ff
> 
> nanddump -nop -l 0x800 -s 0xFEE0000  --bb=dumpbad /dev/mtd1
> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x0fee0000 and ending at 0x0fee0800...
> 0x0fee0000: 55 42 49 23 01 00 00 00 00 00 00 00 00 00 00 07
> 0x0fee0010: 00 00 08 00 00 00 10 00 00 00 00 00 00 00 00 00
> 0x0fee0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 ce ae 33
> 0x0fee0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee01a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee01b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee01c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee01d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee01e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee01f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee02a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee02b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee02c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee02d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee02e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee02f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0310: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0350: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0360: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0370: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0390: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee03a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee03b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee03c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee03d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee03e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee03f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee04a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee04b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee04c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee04d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee04e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee04f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee05a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee05b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee05c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee05d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee05e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee05f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee06a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee06b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee06c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee06d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee06e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee06f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0710: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee0790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee07a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee07b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee07c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee07d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee07e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0fee07f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>    OOB Data: ff ff ff ff ff ff ff ff 4d 56 42 62 74 30 01 ff
>    OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>    OOB Data: 35 5d 8f b6 13 7e 01 97 f5 09 1d a5 6f 06 05 2b
>    OOB Data: ae c6 8c d5 73 ac 38 4e 61 0f c7 99 cc 5a ff ff
> 
> 
> >
> > Once you will have the trace, please do the same again without
> > on-flash-bbt, this way we can compare both U-Boot and Linux layouts
> > and find what is wrong.
> >  
> Should I compile a new uboot without on-flash-bbt, disable it in the 
> kernel dts and finally scrub the last nand pages?

Please prevent the script attaching UBI to run on boot (or remove the
ubi.mtd thing from the cmdline) because it fails the test. As you can
see, the BBT (the last two pages) are filled with UBI data because the
blocks are marked free after scrubbing.

Also, please give us the traces twice, one time with and one time
without the on-flash-bbt property in the Linux DT (do not recompile
u-boot).

Thank you,
Miquèl

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-12 12:47                                                               ` Miquel RAYNAL
@ 2017-12-12 13:09                                                                 ` Sean Nyekjær
  2017-12-12 13:35                                                                   ` Miquel RAYNAL
  0 siblings, 1 reply; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-12 13:09 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi Miquel
> Please prevent the script attaching UBI to run on boot (or remove the
> ubi.mtd thing from the cmdline) because it fails the test. As you can
> see, the BBT (the last two pages) are filled with UBI data because the
> blocks are marked free after scrubbing.
>
> Also, please give us the traces twice, one time with and one time
> without the on-flash-bbt property in the Linux DT (do not recompile
> u-boot).
Without kernel bbt (nand scrubbed in uboot just before boot):
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fe80000 and ending at 0x0fe80800...
0x0fe80000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe800a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe800b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe800c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe800d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe800e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe800f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80110: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80120: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80130: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80140: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80150: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80160: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80170: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80190: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe801a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe801b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe801c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe801d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe801e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe801f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80210: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80220: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80230: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80240: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80250: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80260: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80270: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80290: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe802a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe802b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe802c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe802d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe802e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe802f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80310: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80320: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80330: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80340: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80350: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80360: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80370: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80390: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe803a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe803b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe803c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe803d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe803e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe803f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80400: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80410: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80420: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80430: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80440: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80450: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80460: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80470: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80490: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe804a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe804b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe804c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe804d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe804e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe804f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80510: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80520: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80530: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80540: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80550: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80560: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80570: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80590: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe805a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe805b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe805c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe805d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe805e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe805f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80610: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80620: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80630: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80640: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80650: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80660: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80670: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80690: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe806a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe806b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe806c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe806d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe806e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe806f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80710: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80720: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80730: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80740: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80750: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80760: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80770: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80790: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe807a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe807b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe807c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe807d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe807e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe807f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fea0000 and ending at 0x0fea0800...
0x0fea0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea00a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea00b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea00c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea00d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea00e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea00f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0110: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0120: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0130: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0140: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0150: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0160: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0170: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0190: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea01a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea01b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea01c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea01d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea01e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea01f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0210: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0220: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0230: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0240: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0250: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0260: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0270: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0290: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea02a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea02b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea02c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea02d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea02e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea02f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0310: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0320: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0330: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0340: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0350: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0360: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0370: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0390: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea03a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea03b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea03c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea03d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea03e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea03f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0400: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0410: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0420: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0430: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0440: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0450: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0460: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0470: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0490: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea04a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea04b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea04c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea04d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea04e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea04f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0510: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0520: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0530: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0540: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0550: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0560: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0570: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0590: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea05a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea05b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea05c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea05d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea05e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea05f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0610: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0620: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0630: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0640: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0650: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0660: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0670: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0690: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea06a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea06b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea06c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea06d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea06e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea06f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0710: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0720: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0730: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0740: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0750: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0760: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0770: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0790: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea07a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea07b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea07c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea07d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea07e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea07f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fec0000 and ending at 0x0fec0800...
0x0fec0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec00a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec00b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec00c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec00d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec00e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec00f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0110: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0120: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0130: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0140: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0150: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0160: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0170: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0190: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec01a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec01b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec01c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec01d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec01e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec01f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0210: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0220: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0230: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0240: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0250: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0260: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0270: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0290: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec02a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec02b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec02c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec02d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec02e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec02f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0310: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0320: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0330: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0340: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0350: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0360: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0370: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0390: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec03a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec03b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec03c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec03d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec03e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec03f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0400: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0410: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0420: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0430: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0440: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0450: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0460: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0470: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0490: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec04a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec04b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec04c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec04d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec04e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec04f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0510: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0520: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0530: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0540: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0550: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0560: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0570: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0590: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec05a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec05b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec05c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec05d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec05e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec05f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0610: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0620: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0630: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0640: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0650: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0660: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0670: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0690: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec06a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec06b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec06c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec06d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec06e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec06f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0710: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0720: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0730: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0740: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0750: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0760: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0770: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0790: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec07a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec07b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec07c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec07d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec07e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec07f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fee0000 and ending at 0x0fee0800...
0x0fee0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee00a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee00b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee00c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee00d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee00e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee00f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0110: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0120: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0130: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0140: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0150: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0160: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0170: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0190: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee01a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee01b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee01c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee01d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee01e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee01f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0210: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0220: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0230: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0240: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0250: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0260: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0270: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0290: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee02a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee02b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee02c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee02d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee02e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee02f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0310: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0320: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0330: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0340: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0350: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0360: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0370: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0390: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee03a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee03b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee03c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee03d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee03e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee03f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0400: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0410: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0420: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0430: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0440: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0450: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0460: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0470: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0490: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee04a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee04b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee04c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee04d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee04e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee04f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0510: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0520: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0530: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0540: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0550: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0560: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0570: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0590: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee05a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee05b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee05c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee05d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee05e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee05f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0610: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0620: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0630: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0640: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0650: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0660: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0670: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0690: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee06a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee06b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee06c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee06d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee06e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee06f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0710: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0720: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0730: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0740: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0750: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0760: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0770: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0790: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee07a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee07b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee07c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee07d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee07e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee07f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

With kernel bbt (nand scrubbed in uboot just before boot):
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fe80000 and ending at 0x0fe80800...
0x0fe80000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe800a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe800b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe800c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe800d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe800e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe800f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80110: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80120: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80130: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80140: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80150: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80160: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80170: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80190: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe801a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe801b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe801c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe801d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe801e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe801f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80210: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80220: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80230: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80240: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80250: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80260: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80270: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80290: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe802a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe802b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe802c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe802d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe802e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe802f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80310: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80320: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80330: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80340: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80350: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80360: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80370: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80390: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe803a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe803b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe803c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe803d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe803e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe803f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80400: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80410: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80420: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80430: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80440: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80450: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80460: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80470: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80490: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe804a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe804b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe804c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe804d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe804e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe804f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80510: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80520: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80530: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80540: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80550: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80560: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80570: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80590: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe805a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe805b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe805c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe805d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe805e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe805f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80610: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80620: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80630: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80640: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80650: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80660: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80670: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80690: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe806a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe806b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe806c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe806d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe806e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe806f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80710: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80720: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80730: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80740: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80750: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80760: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80770: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80790: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe807a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe807b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe807c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe807d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe807e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe807f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fea0000 and ending at 0x0fea0800...
0x0fea0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea00a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea00b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea00c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea00d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea00e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea00f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0110: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0120: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0130: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0140: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0150: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0160: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0170: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0190: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea01a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea01b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea01c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea01d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea01e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea01f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0210: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0220: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0230: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0240: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0250: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0260: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0270: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0290: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea02a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea02b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea02c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea02d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea02e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea02f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0310: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0320: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0330: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0340: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0350: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0360: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0370: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0390: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea03a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea03b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea03c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea03d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea03e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea03f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0400: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0410: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0420: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0430: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0440: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0450: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0460: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0470: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0490: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea04a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea04b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea04c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea04d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea04e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea04f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0510: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0520: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0530: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0540: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0550: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0560: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0570: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0590: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea05a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea05b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea05c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea05d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea05e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea05f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0610: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0620: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0630: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0640: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0650: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0660: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0670: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0690: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea06a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea06b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea06c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea06d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea06e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea06f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0710: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0720: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0730: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0740: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0750: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0760: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0770: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0790: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea07a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea07b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea07c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea07d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea07e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea07f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fec0000 and ending at 0x0fec0800...
0x0fec0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec00a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec00b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec00c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec00d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec00e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec00f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0110: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0120: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0130: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0140: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0150: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0160: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0170: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0190: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec01a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec01b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec01c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec01d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec01e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec01f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0210: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0220: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0230: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0240: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0250: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0260: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0270: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0290: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec02a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec02b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec02c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec02d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec02e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec02f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0310: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0320: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0330: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0340: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0350: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0360: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0370: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0390: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec03a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec03b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec03c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec03d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec03e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec03f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0400: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0410: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0420: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0430: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0440: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0450: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0460: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0470: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0490: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec04a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec04b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec04c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec04d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec04e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec04f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0510: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0520: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0530: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0540: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0550: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0560: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0570: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0590: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec05a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec05b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec05c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec05d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec05e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec05f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0610: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0620: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0630: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0640: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0650: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0660: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0670: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0690: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec06a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec06b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec06c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec06d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec06e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec06f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0710: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0720: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0730: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0740: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0750: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0760: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0770: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0790: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec07a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec07b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec07c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec07d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec07e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec07f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff 31 74 62 42 56 4d 01 ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fee0000 and ending at 0x0fee0800...
0x0fee0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee00a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee00b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee00c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee00d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee00e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee00f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0110: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0120: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0130: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0140: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0150: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0160: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0170: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0190: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee01a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee01b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee01c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee01d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee01e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee01f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0210: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0220: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0230: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0240: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0250: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0260: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0270: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0290: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee02a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee02b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee02c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee02d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee02e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee02f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0310: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0320: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0330: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0340: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0350: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0360: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0370: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0390: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee03a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee03b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee03c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee03d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee03e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee03f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0400: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0410: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0420: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0430: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0440: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0450: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0460: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0470: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0490: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee04a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee04b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee04c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee04d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee04e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee04f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0510: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0520: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0530: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0540: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0550: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0560: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0570: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0590: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee05a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee05b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee05c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee05d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee05e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee05f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0610: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0620: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0630: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0640: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0650: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0660: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0670: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0690: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee06a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee06b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee06c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee06d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee06e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee06f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0710: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0720: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0730: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0740: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0750: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0760: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0770: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0790: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee07a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee07b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee07c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee07d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee07e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee07f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff 4d 56 42 62 74 30 01 ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-12 13:09                                                                 ` Sean Nyekjær
@ 2017-12-12 13:35                                                                   ` Miquel RAYNAL
  2017-12-12 18:10                                                                     ` Sean Nyekjær
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-12 13:35 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hello Sean,


> Without kernel bbt (nand scrubbed in uboot just before boot):

[...]

> Block size 131072, page size 2048, OOB size 64
> Dumping data starting at 0x0fec0000 and ending at 0x0fec0800...

[...]

>    OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>    OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>    OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>    OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

As you can see, your U-Boot version does not recreate the BBT
automatically as I told you it should. Please try rebooting the board
after scrubbing and then check U-Boot creates the BBT from U-Boot
command line.

I insist on the fact that this is something I could have spotted earlier
if you had blindlessly copy/pasted the *entire* trace, I don't
mind if it is big, it can be really interesting for others to get the
full trace.

This time I only need the trace without the "on-flash-bbt" property.

Thank you,
Miquèl

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-12  8:15                         ` Boris Brezillon
@ 2017-12-12 16:22                           ` Ezequiel Garcia
  0 siblings, 0 replies; 85+ messages in thread
From: Ezequiel Garcia @ 2017-12-12 16:22 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Greg Cook, Sean Nyekjær, linux-mtd, Kasper Revsbech (KREV),
	Ezequiel Garcia, Miquel RAYNAL

On 12 December 2017 at 05:15, Boris Brezillon
<boris.brezillon@free-electrons.com> wrote:
> On Tue, 12 Dec 2017 15:30:03 +0800
> Greg Cook <greg@morpheus.ws> wrote:
>
>> On 12 December 2017 at 15:09, Ezequiel Garcia
>> <ezequiel@vanguardiasur.com.ar> wrote:
>> > On 12 December 2017 at 03:01, Greg Cook <greg@morpheus.ws> wrote:
>> >> On 12 December 2017 at 05:16, Boris Brezillon
>> >> <boris.brezillon@free-electrons.com> wrote:
>> >>> On Mon, 11 Dec 2017 13:24:56 -0300
>> >>> Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> wrote:
>> >>>
>> >>>> Greg,
>> >>>>
>> >>>> On 11 December 2017 at 10:18, Greg Cook <greg@morpheus.ws> wrote:
>> >>>> > Sean,
>> >>>> >
>> >>>> > I am not completely up-to-date on this, but everything in your traces reads
>> >>>> > like the same issue I was having on bringup for Armada 385 nand (under 4.9).
>> >>>> > I've been stuck on another project, so I haven't had time to follow up
>> >>>> > further, but I just diffed against linux-stable v4.12 pxa3xx_nand.c and it
>> >>>> > looks like the problem is still there.
>> >>>> >
>> >>>> > As far as I can see, the driver is broken for OOB reads when BCH is enabled
>> >>>> > because the setup in prepare_set_command() results in drain_fifo() not
>> >>>> > reading enough words from the read fifo in the nfc2 IP block.
>> >>>
>> >>> May I ask how you you get to this conclusion? What makes you think
>> >>> there's still unread data in the FIFO?
>> >>
>> >> Because I added some debug lines to count the number of bytes read and
>> >> I could  see handle_data_pio() was reading 2048 bytes, followed by 32
>> >> bytes of spare. If you have Marvell MV-S109094-00 REV C handy, you can
>> >> see in Table 36 that this is not correct. The correct number of spare
>> >> bytes for the NFCv2 IP block is
>> >> - 64 bytes when SPARE_EN==1 and ECC_EN==0
>> >> - 32 bytes when SPARE_EN==1 and ECC_EN==1
>> >>
>> >>>> >
>> >>>>
>> >>>> Yes, this sounds just like the bug I was expecting for OOB reads.
>> >>>>
>> >>>> > The patch we are using is below. I have the following in my DTS.
>> >>>> > nand-keep-config is commented out because I was having some issues with
>> >>>> > u-boot at the time and it may no longer be relevant:
>> >>>>
>> >>>> Probably.
>> >>>>
>> >>>> > flash@d0000 {
>> >>>> > status = "okay";
>> >>>> > num-cs = <1>;
>> >>>> > //marvell,nand-keep-config;
>> >>>> > marvell,nand-enable-arbiter;
>> >>>> > nand-on-flash-bbt;
>> >>>> > nand-ecc-strength = <4>;
>> >>>> > nand-ecc-step-size = <512>;
>> >>>> > };
>> >>>> >
>> >>>> > --- /home/user/build/linux-stable/drivers/mtd/nand/pxa3xx_nand.c
>> >>>> > +++
>> >>>> > /home/user/build/beam/openwrt/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/linux-mvebu/linux-4.9.34/drivers/mtd/nand/pxa3xx_nand.c
>> >>>> > @@ -668,7 +669,7 @@
>> >>>> >
>> >>>> >  static void drain_fifo(struct pxa3xx_nand_info *info, void *data, int len)
>> >>>> >  {
>> >>>> > - if (info->ecc_bch) {
>> >>>> > + if (info->use_ecc && info->ecc_bch) {
>> >>>
>> >>> This one might explain timeouts occurring when you drain the FIFO for
>> >>> an operation that does not enable the ECC engine (like
>> >>> READ_PARAM_PAGE).
>> >>>
>> >>> So this fix is indeed valid, but I'm almost sure it won't fix Sean's
>> >>> problem.
>> >>
>> >> From memory, I don't *think* specific line wasn't causing me any
>> >> issues, but I noticed it was not correct because of the way use_ecc
>> >> and ecc_bch flags are initialised and then used. As you say, without
>> >> this patch, you can get timeouts on non-ECC operations when you have
>> >> BCH ECC enabled generally.
>> >>
>> >>>
>> >>>> >   u32 val;
>> >>>> >   int ret;
>> >>>> >
>> >>>> > @@ -1012,7 +1014,11 @@
>> >>>> >
>> >>>> >   if (info->cur_chunk < info->nfullchunks) {
>> >>>> >   info->step_chunk_size = info->chunk_size;
>> >>>> > - info->step_spare_size = info->spare_size;
>> >>>> > + if (info->use_ecc) {
>> >>>> > + info->step_spare_size = info->spare_size;
>> >>>> > + } else {
>> >>>> > + info->step_spare_size = info->spare_size + info->ecc_size;
>> >>>> > + }
>> >>>
>> >>> The only case this change would fix is when you try to read/write pages
>> >>> in raw mode, and I'm pretty sure this driver does not support raw
>> >>> accesses.
>> >>
>> >> Why do you say it would only affect raw mode? This code is not
>> >> specific to raw mode, nor
>> >> is the related code in handle_data_pio(), which uses the value of
>> >> step_spare_size to drain
>> >> the hardware FIFO.
>> >>
>> >
>> > AFAICS, this patch affects READOOB commands, which are
>> > issued when there is no BBT to detect bad blocks.
>>
>> Agree that this only really affects READOOB, because READ0 will always
>> use ECC. I guess this is why it's only catching people at bringup
>> because we are booting into Linux with a blank device.
>

Right, READ0 use ECC. But also, OOB writes are not fixed by this
patch. Proper OOB support is something this driver doesn't support
well.

> I overlooked the READOOB case. What I don't understand though is why we
> are disabling ECC in this case. I mean, free OOB bytes seem to be
> ECC protected (at least for BCH), so ECC should stay enabled when
> reading those bytes, unless we're in raw mode.
>

You can't read those bytes with ECC enabled. AFAICR, the controller
simply won't allow you to read the OBB region, because it's using it
for ECC.

>>
>> >
>> > It "fixes" the timeout, but I wouldn't go as far as assuring
>> > it makes the on-flash bad block scheme work, given
>> > OOB writes will still be done with ECC enabled.
>> >
>> > It seems this drivers mandates a BBT to work properly,
>> > so perhaps a better patch would be to (a) force BBT usage,
>> > and avoid OOB operations altogether, avoiding nasty
>> > timeouts and unhappy board-bringupers.
>> >
>> > Or (b) fix the READOOB and then
>> > WARN/pr_warning about OOB I/O being broken.
>> >
>> > The new driver under discussion, apparently makes AOOB
>> > actually usable (arguably, without much utility as OOB
>> > is mostly used for ECC anyway).
>> >
>> > Ideas?
>>
>> Does mandating BBT usage avoid the bug? Aren't you always going to hit
>> it on a blank NAND device straight off the production line?
>
> The timeout bug should be fixed. The fact that a valid BBT is required
> after the device has been programmed (because BBM are screwed up by the
> controller) is orthogonal to timeout on READOOB commands.
>

Right. This patch is required. I overlooked the fact that we need to
read the BBM to create the BBT in the first place.

Once the BBT is created, I don't think OOB will be needed.
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-12 13:35                                                                   ` Miquel RAYNAL
@ 2017-12-12 18:10                                                                     ` Sean Nyekjær
  2017-12-12 18:23                                                                       ` Miquel RAYNAL
  0 siblings, 1 reply; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-12 18:10 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon



Hi Miquel
>
>> Without kernel bbt (nand scrubbed in uboot just before boot):
>
>[...]
>
>> Block size 131072, page size 2048, OOB size 64
>> Dumping data starting at 0x0fec0000 and ending at 0x0fec0800...
>
>[...]
>
>>    OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>    OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>    OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>    OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>
>As you can see, your U-Boot version does not recreate the BBT
>automatically as I told you it should. Please try rebooting the board
>after scrubbing and then check U-Boot creates the BBT from U-Boot
>command line.

My uboot is recreating the bbt, I have been scrubbing it just before running the bootcmd that's why the OOB is empty :-)
I thought that was what you needed but I guess I was wrong.

>
>I insist on the fact that this is something I could have spotted
>earlier
>if you had blindlessly copy/pasted the *entire* trace, I don't
>mind if it is big, it can be really interesting for others to get the
>full trace.
>
>This time I only need the trace without the "on-flash-bbt" property.

I see what you want now, you want me to dump what uboot is writing in the bbt and what the new driver is writing :-)
Correct?
I'm sending some tracing the first thing tomorrow.

/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-12 18:10                                                                     ` Sean Nyekjær
@ 2017-12-12 18:23                                                                       ` Miquel RAYNAL
  2017-12-13  6:25                                                                         ` Sean Nyekjær
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-12 18:23 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

On Tue, 12 Dec 2017 19:10:10 +0100
Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:

> Hi Miquel
> >  
> >> Without kernel bbt (nand scrubbed in uboot just before boot):  
> >
> >[...]
> >  
> >> Block size 131072, page size 2048, OOB size 64
> >> Dumping data starting at 0x0fec0000 and ending at 0x0fec0800...  
> >
> >[...]
> >  
> >>    OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >>    OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >>    OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> >>    OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  
> >
> >As you can see, your U-Boot version does not recreate the BBT
> >automatically as I told you it should. Please try rebooting the board
> >after scrubbing and then check U-Boot creates the BBT from U-Boot
> >command line.  
> 
> My uboot is recreating the bbt, I have been scrubbing it just before
> running the bootcmd that's why the OOB is empty :-) I thought that
> was what you needed but I guess I was wrong.
> 
> >
> >I insist on the fact that this is something I could have spotted
> >earlier
> >if you had blindlessly copy/pasted the *entire* trace, I don't
> >mind if it is big, it can be really interesting for others to get the
> >full trace.
> >
> >This time I only need the trace without the "on-flash-bbt"
> >property.  
> 
> I see what you want now, you want me to dump what uboot is writing in
> the bbt and what the new driver is writing :-) Correct?

Correct :)

You already gave me what the driver writes (without ECC, but it does
not matter, we know the ECC engine will be used in regular conditions),
what I seek now is effectively what U-Boot is writing to understand
where  the mismatch is.

> I'm sending some tracing the first thing tomorrow.

Nice!

Thanks,
Miquèl

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-12 18:23                                                                       ` Miquel RAYNAL
@ 2017-12-13  6:25                                                                         ` Sean Nyekjær
  2017-12-13  8:41                                                                           ` Miquel RAYNAL
  0 siblings, 1 reply; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-13  6:25 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi Miquel
>
>>>> Without kernel bbt (nand scrubbed in uboot just before boot):
>>> [...]
>>>   
>>>> Block size 131072, page size 2048, OOB size 64
>>>> Dumping data starting at 0x0fec0000 and ending at 0x0fec0800...
>>> [...]
>>>   
>>>>     OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>>     OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>>     OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>>>     OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>> As you can see, your U-Boot version does not recreate the BBT
>>> automatically as I told you it should. Please try rebooting the board
>>> after scrubbing and then check U-Boot creates the BBT from U-Boot
>>> command line.
>> My uboot is recreating the bbt, I have been scrubbing it just before
>> running the bootcmd that's why the OOB is empty :-) I thought that
>> was what you needed but I guess I was wrong.
>>
>>> I insist on the fact that this is something I could have spotted
>>> earlier
>>> if you had blindlessly copy/pasted the *entire* trace, I don't
>>> mind if it is big, it can be really interesting for others to get the
>>> full trace.
>>>
>>> This time I only need the trace without the "on-flash-bbt"
>>> property.
>
I have double checked the result without kernel bbt and the bbt written 
from uboot, the marvell_nand driver is reading 0xFF's...

Tracing:
U-Boot 2017.11-00035-ge9282bb30b-dirty (Dec 12 2017 - 11:22:21 +0100)

SoC:   MV88F6810-A0 at 1066 MHz
DRAM:  1 GiB (533 MHz, 16-bit, ECC not enabled)
WDT:   Enabling Armada 385 watchdog.
NAND:  PXA3xx: strength 4, ecc_stepsize 512, page_size 2048
256 MiB
Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01
Model: Triax dvb-tc output
Board: Triax dvb-tc output
Net:
Warning: ethernet@30000 (eth0) using random MAC address - d6:4c:37:5e:b6:28
eth0: ethernet@30000
=> nand erase.part ubi0; nand scrub 0xFF80000 0x80000; nand bad

NAND erase.part: device 0 offset 0x100000, size 0xff00000
Skipping bad block at 0x0ff00000
Skipping bad block at 0x0ff20000
Skipping bad block at 0x0ff40000
Skipping bad block at 0x0ff60000
Skipping bad block at 0x0ff80000
Skipping bad block at  0x0ffa0000
Skipping bad block at  0x0ffc0000
Skipping bad block at  0x0ffe0000

OK

NAND scrub: device 0 offset 0xff80000, size 0x80000
Warning: scrub option will erase all factory set bad blocks!
          There is no reliable way to recover them.
          Use this command only for testing purposes if you
          are sure of what you are doing!

Really scrub this NAND flash? <y/N>
y
Erasing at 0xffe0000 -- 100% complete.
OK

Device 0 bad blocks:
Bad block table not found for chip 0
Bad block table not found for chip 0
Scanning device for bad blocks
Bad block table written to 0x00000ffe0000, version 0x01
Bad block table written to 0x00000ffc0000, version 0x01
   0ff00000
   0ff20000
   0ff40000
   0ff60000
   0ff80000
   0ffa0000
   0ffc0000
   0ffe0000
=> boot
[ ... ]
[    2.699996] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
[    2.706413] nand: Micron MT29F2G08ABAEAH4
[    2.710461] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, 
OOB size: 64
[    2.718122] nand: NAND_ECC_NONE selected by board driver. This is not 
recommended!
[    2.725750] nand: WARNING: pxa3xx_nand-0: the ECC used on your system 
is too weak compared to the one required by the NAND chip
[    2.737295] Scanning device for bad blocks
[    2.886451] 2 cmdlinepart partitions found on MTD device pxa3xx_nand-0
[    2.893008] Creating 2 MTD partitions on "pxa3xx_nand-0":
[    2.898429] 0x000000000000-0x000000100000 : "uboot"
[    2.903806] 0x000000100000-0x000010000000 : "ubi0"
[ ... ]
root@output-module:~# nanddump -nop -l 0x800 --bb=dumpbad -s 0xFE80000 
/dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fe80000 and ending at 0x0fe80800...
0x0fe80000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe800a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe800b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe800c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe800d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe800e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe800f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80110: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80120: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80130: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80140: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80150: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80160: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80170: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80190: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe801a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe801b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe801c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe801d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe801e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe801f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80210: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80220: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80230: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80240: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80250: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80260: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80270: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80290: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe802a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe802b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe802c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe802d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe802e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe802f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80310: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80320: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80330: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80340: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80350: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80360: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80370: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80390: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe803a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe803b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe803c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe803d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe803e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe803f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80400: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80410: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80420: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80430: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80440: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80450: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80460: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80470: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80490: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe804a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe804b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe804c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe804d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe804e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe804f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80510: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80520: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80530: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80540: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80550: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80560: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80570: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80590: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe805a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe805b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe805c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe805d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe805e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe805f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80610: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80620: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80630: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80640: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80650: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80660: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80670: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80690: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe806a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe806b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe806c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe806d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe806e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe806f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80710: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80720: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80730: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80740: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80750: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80760: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80770: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe80790: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe807a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe807b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe807c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe807d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe807e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fe807f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
root@output-module:~# nanddump -nop -l 0x800 --bb=dumpbad -s 0xFEA0000 
/dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fea0000 and ending at 0x0fea0800...
0x0fea0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea00a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea00b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea00c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea00d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea00e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea00f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0110: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0120: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0130: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0140: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0150: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0160: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0170: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0190: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea01a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea01b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea01c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea01d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea01e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea01f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0210: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0220: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0230: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0240: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0250: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0260: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0270: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0290: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea02a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea02b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea02c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea02d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea02e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea02f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0310: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0320: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0330: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0340: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0350: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0360: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0370: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0390: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea03a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea03b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea03c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea03d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea03e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea03f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0400: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0410: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0420: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0430: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0440: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0450: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0460: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0470: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0490: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea04a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea04b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea04c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea04d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea04e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea04f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0510: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0520: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0530: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0540: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0550: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0560: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0570: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0590: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea05a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea05b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea05c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea05d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea05e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea05f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0610: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0620: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0630: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0640: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0650: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0660: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0670: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0690: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea06a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea06b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea06c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea06d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea06e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea06f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0710: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0720: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0730: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0740: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0750: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0760: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0770: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea0790: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea07a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea07b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea07c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea07d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea07e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fea07f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
root@output-module:~# nanddump -nop -l 0x800 --bb=dumpbad -s 0xFEC0000 
/dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fec0000 and ending at 0x0fec0800...
0x0fec0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec00a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec00b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec00c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec00d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec00e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec00f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0110: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0120: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0130: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0140: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0150: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0160: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0170: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0190: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec01a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec01b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec01c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec01d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec01e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec01f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0210: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0220: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0230: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0240: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0250: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0260: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0270: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0290: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec02a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec02b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec02c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec02d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec02e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec02f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0310: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0320: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0330: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0340: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0350: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0360: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0370: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0390: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec03a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec03b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec03c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec03d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec03e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec03f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0400: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0410: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0420: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0430: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0440: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0450: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0460: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0470: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0490: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec04a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec04b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec04c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec04d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec04e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec04f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0510: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0520: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0530: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0540: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0550: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0560: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0570: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0590: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec05a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec05b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec05c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec05d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec05e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec05f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0610: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0620: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0630: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0640: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0650: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0660: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0670: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0690: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec06a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec06b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec06c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec06d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec06e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec06f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0710: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0720: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0730: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0740: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0750: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0760: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0770: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec0790: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec07a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec07b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec07c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec07d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec07e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fec07f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
root@output-module:~# nanddump -nop -l 0x800 --bb=dumpbad -s 0xFEE0000 
/dev/mtd1
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x0fee0000 and ending at 0x0fee0800...
0x0fee0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee00a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee00b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee00c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee00d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee00e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee00f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0110: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0120: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0130: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0140: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0150: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0160: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0170: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0190: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee01a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee01b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee01c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee01d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee01e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee01f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0210: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0220: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0230: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0240: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0250: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0260: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0270: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0290: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee02a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee02b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee02c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee02d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee02e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee02f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0310: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0320: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0330: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0340: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0350: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0360: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0370: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0390: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee03a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee03b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee03c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee03d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee03e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee03f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0400: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0410: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0420: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0430: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0440: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0450: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0460: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0470: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0490: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee04a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee04b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee04c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee04d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee04e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee04f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0510: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0520: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0530: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0540: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0550: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0560: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0570: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0590: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee05a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee05b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee05c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee05d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee05e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee05f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0610: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0620: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0630: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0640: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0650: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0660: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0670: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0690: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee06a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee06b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee06c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee06d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee06e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee06f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0710: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0720: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0730: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0740: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0750: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0760: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0770: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee0790: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee07a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee07b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee07c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee07d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee07e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0fee07f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
   OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
root@output-module:~# reboot
[ ... ]
U-Boot 2017.11-00035-ge9282bb30b-dirty (Dec 12 2017 - 11:22:21 +0100)

SoC:   MV88F6810-A0 at 1066 MHz
DRAM:  1 GiB (533 MHz, 16-bit, ECC not enabled)
WDT:   Enabling Armada 385 watchdog.
NAND:  PXA3xx: strength 4, ecc_stepsize 512, page_size 2048
256 MiB
Bad block table found at page 131008, version 0x01
Bad block table found at page 130944, version 0x01

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-13  6:25                                                                         ` Sean Nyekjær
@ 2017-12-13  8:41                                                                           ` Miquel RAYNAL
  2017-12-13  9:31                                                                             ` Sean Nyekjær
  2017-12-15 17:25                                                                             ` Miquel RAYNAL
  0 siblings, 2 replies; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-13  8:41 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi Sean,

> >>> I insist on the fact that this is something I could have spotted
> >>> earlier
> >>> if you had blindlessly copy/pasted the *entire* trace, I don't
> >>> mind if it is big, it can be really interesting for others to get
> >>> the full trace.
> >>>
> >>> This time I only need the trace without the "on-flash-bbt"
> >>> property.  
> >  
> I have double checked the result without kernel bbt and the bbt
> written from uboot, the marvell_nand driver is reading 0xFF's...

That is weird. I am gonna check with my setup if the sequence I ask you
actually works.

> 
> Tracing:
> U-Boot 2017.11-00035-ge9282bb30b-dirty (Dec 12 2017 - 11:22:21 +0100)

"-dirty"? Is the 17.11 U-Boot clean around the NAND area? What did you
change from mainline code?


> 
> SoC:   MV88F6810-A0 at 1066 MHz
> DRAM:  1 GiB (533 MHz, 16-bit, ECC not enabled)
> WDT:   Enabling Armada 385 watchdog.
> NAND:  PXA3xx: strength 4, ecc_stepsize 512, page_size 2048
> 256 MiB
> Bad block table found at page 131008, version 0x01
> Bad block table found at page 130944, version 0x01
> Model: Triax dvb-tc output
> Board: Triax dvb-tc output
> Net:
> Warning: ethernet@30000 (eth0) using random MAC address -
> d6:4c:37:5e:b6:28 eth0: ethernet@30000
> => nand erase.part ubi0; nand scrub 0xFF80000 0x80000; nand bad  
> 
> NAND erase.part: device 0 offset 0x100000, size 0xff00000
> Skipping bad block at 0x0ff00000
> Skipping bad block at 0x0ff20000
> Skipping bad block at 0x0ff40000
> Skipping bad block at 0x0ff60000
> Skipping bad block at 0x0ff80000
> Skipping bad block at  0x0ffa0000
> Skipping bad block at  0x0ffc0000
> Skipping bad block at  0x0ffe0000
> 
> OK
> 
> NAND scrub: device 0 offset 0xff80000, size 0x80000
> Warning: scrub option will erase all factory set bad blocks!
>           There is no reliable way to recover them.
>           Use this command only for testing purposes if you
>           are sure of what you are doing!
> 
> Really scrub this NAND flash? <y/N>
> y
> Erasing at 0xffe0000 -- 100% complete.
> OK
> 
> Device 0 bad blocks:
> Bad block table not found for chip 0
> Bad block table not found for chip 0
> Scanning device for bad blocks
> Bad block table written to 0x00000ffe0000, version 0x01
> Bad block table written to 0x00000ffc0000, version 0x01
>    0ff00000
>    0ff20000
>    0ff40000
>    0ff60000
>    0ff80000
>    0ffa0000
>    0ffc0000
>    0ffe0000
> => boot  
> [ ... ]

Please, stop doing this, we _really_ _really_ _really_ want the *full*
log, no matter if you think this part is irrelevant.

If for you the trace is too big, please use
http://code.bulix.org/ or https://pastebin.com/

> [    2.699996] nand: device found, Manufacturer ID: 0x2c, Chip ID:
> 0xda [    2.706413] nand: Micron MT29F2G08ABAEAH4
> [    2.710461] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
> 2048, OOB size: 64
> [    2.718122] nand: NAND_ECC_NONE selected by board driver. This is
> not recommended!
> [    2.725750] nand: WARNING: pxa3xx_nand-0: the ECC used on your
> system is too weak compared to the one required by the NAND chip
> [    2.737295] Scanning device for bad blocks
> [    2.886451] 2 cmdlinepart partitions found on MTD device
> pxa3xx_nand-0 [    2.893008] Creating 2 MTD partitions on
> "pxa3xx_nand-0": [    2.898429] 0x000000000000-0x000000100000 :
> "uboot" [    2.903806] 0x000000100000-0x000010000000 : "ubi0"
> [ ... ]
> root@output-module:~# nanddump -nop -l 0x800 --bb=dumpbad -s
> 0xFE80000 /dev/mtd1

While I am investigating on my side, could you please:
- dump the same pages as before from U-Boot, with the OOB area of
  course (do not substract the 0x100000 offset from U-Boot), I want
  to see if there is actually something in these pages.
- dump the entire MTD1 device from Linux (same configuration as before)
  and grep for the string "MVBbt".

Thanks,
Miquèl

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-13  8:41                                                                           ` Miquel RAYNAL
@ 2017-12-13  9:31                                                                             ` Sean Nyekjær
  2017-12-15 17:25                                                                             ` Miquel RAYNAL
  1 sibling, 0 replies; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-13  9:31 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi Miquel
> Hi Sean,
>
>>>>> I insist on the fact that this is something I could have spotted
>>>>> earlier
>>>>> if you had blindlessly copy/pasted the *entire* trace, I don't
>>>>> mind if it is big, it can be really interesting for others to get
>>>>> the full trace.
>>>>>
>>>>> This time I only need the trace without the "on-flash-bbt"
>>>>> property.
>>>   
>> I have double checked the result without kernel bbt and the bbt
>> written from uboot, the marvell_nand driver is reading 0xFF's...
> That is weird. I am gonna check with my setup if the sequence I ask you
> actually works.
>
>> Tracing:
>> U-Boot 2017.11-00035-ge9282bb30b-dirty (Dec 12 2017 - 11:22:21 +0100)
> "-dirty"? Is the 17.11 U-Boot clean around the NAND area? What did you
> change from mainline code?
Clean nand code, just added debug print so we are able to see if the bbt 
is read correctly etc.
>
>
>> SoC:   MV88F6810-A0 at 1066 MHz
>> DRAM:  1 GiB (533 MHz, 16-bit, ECC not enabled)
>> WDT:   Enabling Armada 385 watchdog.
>> NAND:  PXA3xx: strength 4, ecc_stepsize 512, page_size 2048
>> 256 MiB
>> Bad block table found at page 131008, version 0x01
>> Bad block table found at page 130944, version 0x01
>> Model: Triax dvb-tc output
>> Board: Triax dvb-tc output
>> Net:
>> Warning: ethernet@30000 (eth0) using random MAC address -
>> d6:4c:37:5e:b6:28 eth0: ethernet@30000
>> => nand erase.part ubi0; nand scrub 0xFF80000 0x80000; nand bad
>>
>> NAND erase.part: device 0 offset 0x100000, size 0xff00000
>> Skipping bad block at 0x0ff00000
>> Skipping bad block at 0x0ff20000
>> Skipping bad block at 0x0ff40000
>> Skipping bad block at 0x0ff60000
>> Skipping bad block at 0x0ff80000
>> Skipping bad block at  0x0ffa0000
>> Skipping bad block at  0x0ffc0000
>> Skipping bad block at  0x0ffe0000
>>
>> OK
>>
>> NAND scrub: device 0 offset 0xff80000, size 0x80000
>> Warning: scrub option will erase all factory set bad blocks!
>>            There is no reliable way to recover them.
>>            Use this command only for testing purposes if you
>>            are sure of what you are doing!
>>
>> Really scrub this NAND flash? <y/N>
>> y
>> Erasing at 0xffe0000 -- 100% complete.
>> OK
>>
>> Device 0 bad blocks:
>> Bad block table not found for chip 0
>> Bad block table not found for chip 0
>> Scanning device for bad blocks
>> Bad block table written to 0x00000ffe0000, version 0x01
>> Bad block table written to 0x00000ffc0000, version 0x01
>>     0ff00000
>>     0ff20000
>>     0ff40000
>>     0ff60000
>>     0ff80000
>>     0ffa0000
>>     0ffc0000
>>     0ffe0000
>> => boot
>> [ ... ]
> Please, stop doing this, we _really_ _really_ _really_ want the *full*
> log, no matter if you think this part is irrelevant.
>
> If for you the trace is too big, please use
> http://code.bulix.org/ or https://pastebin.com/
Nothing magic happens, just tftpboot.  I will dump to gist next time ;-)
See link below
>> [    2.699996] nand: device found, Manufacturer ID: 0x2c, Chip ID:
>> 0xda [    2.706413] nand: Micron MT29F2G08ABAEAH4
>> [    2.710461] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
>> 2048, OOB size: 64
>> [    2.718122] nand: NAND_ECC_NONE selected by board driver. This is
>> not recommended!
>> [    2.725750] nand: WARNING: pxa3xx_nand-0: the ECC used on your
>> system is too weak compared to the one required by the NAND chip
>> [    2.737295] Scanning device for bad blocks
>> [    2.886451] 2 cmdlinepart partitions found on MTD device
>> pxa3xx_nand-0 [    2.893008] Creating 2 MTD partitions on
>> "pxa3xx_nand-0": [    2.898429] 0x000000000000-0x000000100000 :
>> "uboot" [    2.903806] 0x000000100000-0x000010000000 : "ubi0"
>> [ ... ]
>> root@output-module:~# nanddump -nop -l 0x800 --bb=dumpbad -s
>> 0xFE80000 /dev/mtd1
> While I am investigating on my side, could you please:
> - dump the same pages as before from U-Boot, with the OOB area of
>    course (do not substract the 0x100000 offset from U-Boot), I want
>    to see if there is actually something in these pages.
=> nand dump 0xFFC0000
Page 0ffc0000 dump:
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
OOB:
     ff ff ff ff ff ff ff ff
     31 74 62 42 56 4d 01 ff
     ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff
=> nand dump 0xFFE0000
Page 0ffe0000 dump:
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff
OOB:
     ff ff ff ff ff ff ff ff
     4d 56 42 62 74 30 01 ff
     ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff
     ff ff ff ff ff ff ff ff
=>
> - dump the entire MTD1 device from Linux (same configuration as before)
>    and grep for the string "MVBbt".
https://gist.github.com/anonymous/2264abdc94e5d12e3efa8fc085fa1dd5

/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-13  8:41                                                                           ` Miquel RAYNAL
  2017-12-13  9:31                                                                             ` Sean Nyekjær
@ 2017-12-15 17:25                                                                             ` Miquel RAYNAL
  2017-12-15 18:56                                                                               ` Sean Nyekjær
  1 sibling, 1 reply; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-15 17:25 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hello Sean,

I am very sorry for the delay but it took me some time to figure a way
to reproduce your situation until I started doing the exact sequence I
asked you to follow. It turns out there was a nasty error in the parser
so you could not observe the last blocks of your chip because I messed
up with high addresses.

I updated the Github branch [1], can you rebase on top of it? I think
this time we should get something :)

[1] https://github.com/miquelraynal/linux/tree/marvell/nand-next/nfc

Thanks for your time,
Miquèl

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-15 17:25                                                                             ` Miquel RAYNAL
@ 2017-12-15 18:56                                                                               ` Sean Nyekjær
  2017-12-15 19:19                                                                                 ` Miquel RAYNAL
  0 siblings, 1 reply; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-15 18:56 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon



Hi Miquel

>I am very sorry for the delay but it took me some time to figure a way
>to reproduce your situation until I started doing the exact sequence I
>asked you to follow. It turns out there was a nasty error in the parser
>so you could not observe the last blocks of your chip because I messed
>up with high addresses.

Fantastic always nice to be able to reproduce the issue. Glad to be able to help :-)

>
>I updated the Github branch [1], can you rebase on top of it? I think
>this time we should get something :)

I just did a quick boot with the new commits, and the kernel is able to find the bbt table :-)

I also tried booting with ECC enabled and with that enabled the driver is unable to read the bbt and marked all blocks bad.

/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-15 18:56                                                                               ` Sean Nyekjær
@ 2017-12-15 19:19                                                                                 ` Miquel RAYNAL
  2017-12-17 11:56                                                                                   ` Sean Nyekjaer
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-15 19:19 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi Sean,

On Fri, 15 Dec 2017 19:56:27 +0100
Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:

> Hi Miquel
> 
> >I am very sorry for the delay but it took me some time to figure a
> >way to reproduce your situation until I started doing the exact
> >sequence I asked you to follow. It turns out there was a nasty error
> >in the parser so you could not observe the last blocks of your chip
> >because I messed up with high addresses.  
> 
> Fantastic always nice to be able to reproduce the issue. Glad to be
> able to help :-)
> 
> >
> >I updated the Github branch [1], can you rebase on top of it? I think
> >this time we should get something :)  
> 
> I just did a quick boot with the new commits, and the kernel is able
> to find the bbt table :-)

Good ! :-)

So with nand-ecc-mode = "none" + on-flash-bbt, there is no more issue,
right?

> 
> I also tried booting with ECC enabled and with that enabled the
> driver is unable to read the bbt and marked all blocks bad.

And if I understand correctly, if you remove nand-ecc-mode = "none" (or
set it to "hw"), the kernel fails to find the BBT, that is right?

As I was not expecting such a quick answer, I did push another patch
after sending my email that fixes an issue in mtdcore.c, please check
you have it (there are a few "fixup!" patches, and on top of them you
must find one which is a well-formatted patch about
mtd_check_oob_ops()).

I learned that today: to get a prompt while all blocks are bad, you can
add:

    chip->options |= NAND_SKIP_BBTSCAN;

Before nand_scan_tail().

If you can reach a prompt with the failing configuration and when you
will have the time, I will welcome a dump of the same area as before
so we will try to understand what is wrong now ! :)

Thank you,
Miquèl

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-15 19:19                                                                                 ` Miquel RAYNAL
@ 2017-12-17 11:56                                                                                   ` Sean Nyekjaer
  2017-12-17 13:19                                                                                     ` Boris Brezillon
  2017-12-17 13:48                                                                                     ` Boris Brezillon
  0 siblings, 2 replies; 85+ messages in thread
From: Sean Nyekjaer @ 2017-12-17 11:56 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV), Boris Brezillon

Hi Miquel
>>> I am very sorry for the delay but it took me some time to figure a
>>> way to reproduce your situation until I started doing the exact
>>> sequence I asked you to follow. It turns out there was a nasty error
>>> in the parser so you could not observe the last blocks of your chip
>>> because I messed up with high addresses.
>> Fantastic always nice to be able to reproduce the issue. Glad to be
>> able to help :-)
>>
>>> I updated the Github branch [1], can you rebase on top of it? I think
>>> this time we should get something :)
>> I just did a quick boot with the new commits, and the kernel is able
>> to find the bbt table :-)
> Good ! :-)
>
> So with nand-ecc-mode = "none" + on-flash-bbt, there is no more issue,
> right?
No more issue with reading the bbt :-)
>
>> I also tried booting with ECC enabled and with that enabled the
>> driver is unable to read the bbt and marked all blocks bad.
> And if I understand correctly, if you remove nand-ecc-mode = "none" (or
> set it to "hw"), the kernel fails to find the BBT, that is right?
Yes.
>
> As I was not expecting such a quick answer, I did push another patch
> after sending my email that fixes an issue in mtdcore.c, please check
> you have it (there are a few "fixup!" patches, and on top of them you
> must find one which is a well-formatted patch about
> mtd_check_oob_ops()).
I have rebased on top of 9aee88a618f8 mtd: Fix mtd_check_oob_ops()
>
> I learned that today: to get a prompt while all blocks are bad, you can
> add:
>
>      chip->options |= NAND_SKIP_BBTSCAN;
>
> Before nand_scan_tail().
>
> If you can reach a prompt with the failing configuration and when you
> will have the time, I will welcome a dump of the same area as before
> so we will try to understand what is wrong now ! :)
Nice one, a lot easier to read whats happens

nanddump of BBT without ECC enabled:
https://gist.github.com/anonymous/627e5be058ed93c106d61641f6aa5da0

nanddump of BBT with ECC enabled:
https://gist.github.com/anonymous/76b3240f156c6547cf76d59f2aae49fe
bootsnippet with ECC and NAND_SKIP_BBTSCAN enabled.
https://gist.github.com/anonymous/0d9be95cd9c36ff006f7aa03e7c2cc85

Please let me know what traces you need to fix the ECC :-)

/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-17 11:56                                                                                   ` Sean Nyekjaer
@ 2017-12-17 13:19                                                                                     ` Boris Brezillon
  2017-12-17 21:47                                                                                       ` Sean Nyekjaer
  2017-12-17 13:48                                                                                     ` Boris Brezillon
  1 sibling, 1 reply; 85+ messages in thread
From: Boris Brezillon @ 2017-12-17 13:19 UTC (permalink / raw)
  To: Sean Nyekjaer
  Cc: Miquel RAYNAL, ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

Hi Sean,

On Sun, 17 Dec 2017 12:56:01 +0100
Sean Nyekjaer <sean.nyekjaer@prevas.dk> wrote:

> Hi Miquel
> >>> I am very sorry for the delay but it took me some time to figure a
> >>> way to reproduce your situation until I started doing the exact
> >>> sequence I asked you to follow. It turns out there was a nasty error
> >>> in the parser so you could not observe the last blocks of your chip
> >>> because I messed up with high addresses.  
> >> Fantastic always nice to be able to reproduce the issue. Glad to be
> >> able to help :-)
> >>  
> >>> I updated the Github branch [1], can you rebase on top of it? I think
> >>> this time we should get something :)  
> >> I just did a quick boot with the new commits, and the kernel is able
> >> to find the bbt table :-)  
> > Good ! :-)
> >
> > So with nand-ecc-mode = "none" + on-flash-bbt, there is no more issue,
> > right?  
> No more issue with reading the bbt :-)
> >  
> >> I also tried booting with ECC enabled and with that enabled the
> >> driver is unable to read the bbt and marked all blocks bad.  
> > And if I understand correctly, if you remove nand-ecc-mode = "none" (or
> > set it to "hw"), the kernel fails to find the BBT, that is right?  
> Yes.
> >
> > As I was not expecting such a quick answer, I did push another patch
> > after sending my email that fixes an issue in mtdcore.c, please check
> > you have it (there are a few "fixup!" patches, and on top of them you
> > must find one which is a well-formatted patch about
> > mtd_check_oob_ops()).  
> I have rebased on top of 9aee88a618f8 mtd: Fix mtd_check_oob_ops()
> >
> > I learned that today: to get a prompt while all blocks are bad, you can
> > add:
> >
> >      chip->options |= NAND_SKIP_BBTSCAN;
> >
> > Before nand_scan_tail().
> >
> > If you can reach a prompt with the failing configuration and when you
> > will have the time, I will welcome a dump of the same area as before
> > so we will try to understand what is wrong now ! :)  
> Nice one, a lot easier to read whats happens
> 
> nanddump of BBT without ECC enabled:
> https://gist.github.com/anonymous/627e5be058ed93c106d61641f6aa5da0
> 
> nanddump of BBT with ECC enabled:
> https://gist.github.com/anonymous/76b3240f156c6547cf76d59f2aae49fe
> bootsnippet with ECC and NAND_SKIP_BBTSCAN enabled.
> https://gist.github.com/anonymous/0d9be95cd9c36ff006f7aa03e7c2cc85
> 
> Please let me know what traces you need to fix the ECC :-)

The dumps look good (at least, the BBT pattern is correct, we have the
number of ECC bytes we expect and they are where we expect them).

My gut feeling is that something is wrong with ECC (or something related
to ECC) in u-boot.

Can you try to let Linux create the BBT on its own and dump the last
block as you did previously?

So, to sum-up

1/ put the following in your DT

	nand-ecc-mode = "hw";
	nand-on-flash-bbt;

2/ scrub the NAND from u-boot and make sure you don't reboot after that,
   so that u-boot can't recreate its own BBT.

3/ Let Linux boot and dump the pages (in raw mode) where BBTs created by
Linux are supposed to be (should be the same addresses as before)

If we end up with different ECC bytes than what u-boot produces then
there's a mismatch somewhere.

Regards,

Boris

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-17 11:56                                                                                   ` Sean Nyekjaer
  2017-12-17 13:19                                                                                     ` Boris Brezillon
@ 2017-12-17 13:48                                                                                     ` Boris Brezillon
  1 sibling, 0 replies; 85+ messages in thread
From: Boris Brezillon @ 2017-12-17 13:48 UTC (permalink / raw)
  To: Sean Nyekjaer
  Cc: Miquel RAYNAL, ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

On Sun, 17 Dec 2017 12:56:01 +0100
Sean Nyekjaer <sean.nyekjaer@prevas.dk> wrote:

> Hi Miquel
> >>> I am very sorry for the delay but it took me some time to figure a
> >>> way to reproduce your situation until I started doing the exact
> >>> sequence I asked you to follow. It turns out there was a nasty error
> >>> in the parser so you could not observe the last blocks of your chip
> >>> because I messed up with high addresses.  
> >> Fantastic always nice to be able to reproduce the issue. Glad to be
> >> able to help :-)
> >>  
> >>> I updated the Github branch [1], can you rebase on top of it? I think
> >>> this time we should get something :)  
> >> I just did a quick boot with the new commits, and the kernel is able
> >> to find the bbt table :-)  
> > Good ! :-)
> >
> > So with nand-ecc-mode = "none" + on-flash-bbt, there is no more issue,
> > right?  
> No more issue with reading the bbt :-)
> >  
> >> I also tried booting with ECC enabled and with that enabled the
> >> driver is unable to read the bbt and marked all blocks bad.  
> > And if I understand correctly, if you remove nand-ecc-mode = "none" (or
> > set it to "hw"), the kernel fails to find the BBT, that is right?  
> Yes.
> >
> > As I was not expecting such a quick answer, I did push another patch
> > after sending my email that fixes an issue in mtdcore.c, please check
> > you have it (there are a few "fixup!" patches, and on top of them you
> > must find one which is a well-formatted patch about
> > mtd_check_oob_ops()).  
> I have rebased on top of 9aee88a618f8 mtd: Fix mtd_check_oob_ops()
> >
> > I learned that today: to get a prompt while all blocks are bad, you can
> > add:
> >
> >      chip->options |= NAND_SKIP_BBTSCAN;
> >
> > Before nand_scan_tail().
> >
> > If you can reach a prompt with the failing configuration and when you
> > will have the time, I will welcome a dump of the same area as before
> > so we will try to understand what is wrong now ! :)  
> Nice one, a lot easier to read whats happens
> 
> nanddump of BBT without ECC enabled:
> https://gist.github.com/anonymous/627e5be058ed93c106d61641f6aa5da0
> 
> nanddump of BBT with ECC enabled:
> https://gist.github.com/anonymous/76b3240f156c6547cf76d59f2aae49fe

Another test that is worth doing: try to dump with ECC enabled:

# nanddump -op -l 0x800 --bb=dumpbad -s 0xYYYYYYY /dev/mtd1

> bootsnippet with ECC and NAND_SKIP_BBTSCAN enabled.
> https://gist.github.com/anonymous/0d9be95cd9c36ff006f7aa03e7c2cc85
> 
> Please let me know what traces you need to fix the ECC :-)
> 
> /Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-17 13:19                                                                                     ` Boris Brezillon
@ 2017-12-17 21:47                                                                                       ` Sean Nyekjaer
  2017-12-17 22:00                                                                                         ` Boris Brezillon
  0 siblings, 1 reply; 85+ messages in thread
From: Sean Nyekjaer @ 2017-12-17 21:47 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Miquel RAYNAL, ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

Hi Boris and Miquel
>>>   
>>>> I also tried booting with ECC enabled and with that enabled the
>>>> driver is unable to read the bbt and marked all blocks bad.
>>> And if I understand correctly, if you remove nand-ecc-mode = "none" (or
>>> set it to "hw"), the kernel fails to find the BBT, that is right?
>> Yes.
>>> As I was not expecting such a quick answer, I did push another patch
>>> after sending my email that fixes an issue in mtdcore.c, please check
>>> you have it (there are a few "fixup!" patches, and on top of them you
>>> must find one which is a well-formatted patch about
>>> mtd_check_oob_ops()).
>> I have rebased on top of 9aee88a618f8 mtd: Fix mtd_check_oob_ops()
>>> I learned that today: to get a prompt while all blocks are bad, you can
>>> add:
>>>
>>>       chip->options |= NAND_SKIP_BBTSCAN;
>>>
>>> Before nand_scan_tail().
>>>
>>> If you can reach a prompt with the failing configuration and when you
>>> will have the time, I will welcome a dump of the same area as before
>>> so we will try to understand what is wrong now ! :)
>> Nice one, a lot easier to read whats happens
>>
>> nanddump of BBT without ECC enabled:
>> https://gist.github.com/anonymous/627e5be058ed93c106d61641f6aa5da0
>>
>> nanddump of BBT with ECC enabled:
>> https://gist.github.com/anonymous/76b3240f156c6547cf76d59f2aae49fe
>> bootsnippet with ECC and NAND_SKIP_BBTSCAN enabled.
>> https://gist.github.com/anonymous/0d9be95cd9c36ff006f7aa03e7c2cc85
>>
>> Please let me know what traces you need to fix the ECC :-)
> The dumps look good (at least, the BBT pattern is correct, we have the
> number of ECC bytes we expect and they are where we expect them).
>
> My gut feeling is that something is wrong with ECC (or something related
> to ECC) in u-boot.
>
> Can you try to let Linux create the BBT on its own and dump the last
> block as you did previously?
>
> So, to sum-up
>
> 1/ put the following in your DT
>
> 	nand-ecc-mode = "hw";
> 	nand-on-flash-bbt;
>
> 2/ scrub the NAND from u-boot and make sure you don't reboot after that,
>     so that u-boot can't recreate its own BBT.
>
> 3/ Let Linux boot and dump the pages (in raw mode) where BBTs created by
> Linux are supposed to be (should be the same addresses as before)
Trace with nand scrub in uboot and ecc enabled:
https://gist.github.com/anonymous/3ce389b9276fddbd46f59c89b99ee4ff

Same as above with "chip->options |= NAND_SKIP_BBTSCAN;" in the marvell 
nand driver
https://gist.github.com/anonymous/3aed159b5a5ee22f27403fe79ba97400

If I dump 0xFEC0000/0xFFC0000 or 0xFEE0000/0xFFE0000 (the bbt pages) 
they contain
only 0xFF's as the kernel does not write to the blocks.

To me it seem a little bit difficult to say why the new marvell nand driver
(with ecc enabled) thinks all the freshly scrubbed blocks are bad.

/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-17 21:47                                                                                       ` Sean Nyekjaer
@ 2017-12-17 22:00                                                                                         ` Boris Brezillon
  2017-12-17 22:15                                                                                           ` [SPAM] " Sean Nyekjær
  0 siblings, 1 reply; 85+ messages in thread
From: Boris Brezillon @ 2017-12-17 22:00 UTC (permalink / raw)
  To: Sean Nyekjaer
  Cc: Miquel RAYNAL, ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

On Sun, 17 Dec 2017 22:47:26 +0100
Sean Nyekjaer <sean.nyekjaer@prevas.dk> wrote:

> Hi Boris and Miquel
> >>>     
> >>>> I also tried booting with ECC enabled and with that enabled the
> >>>> driver is unable to read the bbt and marked all blocks bad.  
> >>> And if I understand correctly, if you remove nand-ecc-mode = "none" (or
> >>> set it to "hw"), the kernel fails to find the BBT, that is right?  
> >> Yes.  
> >>> As I was not expecting such a quick answer, I did push another patch
> >>> after sending my email that fixes an issue in mtdcore.c, please check
> >>> you have it (there are a few "fixup!" patches, and on top of them you
> >>> must find one which is a well-formatted patch about
> >>> mtd_check_oob_ops()).  
> >> I have rebased on top of 9aee88a618f8 mtd: Fix mtd_check_oob_ops()  
> >>> I learned that today: to get a prompt while all blocks are bad, you can
> >>> add:
> >>>
> >>>       chip->options |= NAND_SKIP_BBTSCAN;
> >>>
> >>> Before nand_scan_tail().
> >>>
> >>> If you can reach a prompt with the failing configuration and when you
> >>> will have the time, I will welcome a dump of the same area as before
> >>> so we will try to understand what is wrong now ! :)  
> >> Nice one, a lot easier to read whats happens
> >>
> >> nanddump of BBT without ECC enabled:
> >> https://gist.github.com/anonymous/627e5be058ed93c106d61641f6aa5da0
> >>
> >> nanddump of BBT with ECC enabled:
> >> https://gist.github.com/anonymous/76b3240f156c6547cf76d59f2aae49fe
> >> bootsnippet with ECC and NAND_SKIP_BBTSCAN enabled.
> >> https://gist.github.com/anonymous/0d9be95cd9c36ff006f7aa03e7c2cc85
> >>
> >> Please let me know what traces you need to fix the ECC :-)  
> > The dumps look good (at least, the BBT pattern is correct, we have the
> > number of ECC bytes we expect and they are where we expect them).
> >
> > My gut feeling is that something is wrong with ECC (or something related
> > to ECC) in u-boot.
> >
> > Can you try to let Linux create the BBT on its own and dump the last
> > block as you did previously?
> >
> > So, to sum-up
> >
> > 1/ put the following in your DT
> >
> > 	nand-ecc-mode = "hw";
> > 	nand-on-flash-bbt;
> >
> > 2/ scrub the NAND from u-boot and make sure you don't reboot after that,
> >     so that u-boot can't recreate its own BBT.
> >
> > 3/ Let Linux boot and dump the pages (in raw mode) where BBTs created by
> > Linux are supposed to be (should be the same addresses as before)  
> Trace with nand scrub in uboot and ecc enabled:
> https://gist.github.com/anonymous/3ce389b9276fddbd46f59c89b99ee4ff
> 
> Same as above with "chip->options |= NAND_SKIP_BBTSCAN;" in the marvell 
> nand driver
> https://gist.github.com/anonymous/3aed159b5a5ee22f27403fe79ba97400
> 
> If I dump 0xFEC0000/0xFFC0000 or 0xFEE0000/0xFFE0000 (the bbt pages) 
> they contain
> only 0xFF's as the kernel does not write to the blocks.
> 
> To me it seem a little bit difficult to say why the new marvell nand driver
> (with ecc enabled) thinks all the freshly scrubbed blocks are bad.

Ok, now I really need the dump without the -n option. It seems that
dumping in non-raw mode does not return the expected value.

Thanks,

Boris

^ permalink raw reply	[flat|nested] 85+ messages in thread

* [SPAM] Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-17 22:00                                                                                         ` Boris Brezillon
@ 2017-12-17 22:15                                                                                           ` Sean Nyekjær
  2017-12-17 22:19                                                                                             ` Boris Brezillon
  2017-12-17 22:19                                                                                             ` Miquel RAYNAL
  0 siblings, 2 replies; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-17 22:15 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Miquel RAYNAL, ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)



On 17 December 2017 23:00:32 CET, Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
>On Sun, 17 Dec 2017 22:47:26 +0100
>Sean Nyekjaer <sean.nyekjaer@prevas.dk> wrote:
>
>> Hi Boris and Miquel
>> >>>     
>> >>>> I also tried booting with ECC enabled and with that enabled the
>> >>>> driver is unable to read the bbt and marked all blocks bad.  
>> >>> And if I understand correctly, if you remove nand-ecc-mode =
>"none" (or
>> >>> set it to "hw"), the kernel fails to find the BBT, that is right?
> 
>> >> Yes.  
>> >>> As I was not expecting such a quick answer, I did push another
>patch
>> >>> after sending my email that fixes an issue in mtdcore.c, please
>check
>> >>> you have it (there are a few "fixup!" patches, and on top of them
>you
>> >>> must find one which is a well-formatted patch about
>> >>> mtd_check_oob_ops()).  
>> >> I have rebased on top of 9aee88a618f8 mtd: Fix mtd_check_oob_ops()
> 
>> >>> I learned that today: to get a prompt while all blocks are bad,
>you can
>> >>> add:
>> >>>
>> >>>       chip->options |= NAND_SKIP_BBTSCAN;
>> >>>
>> >>> Before nand_scan_tail().
>> >>>
>> >>> If you can reach a prompt with the failing configuration and when
>you
>> >>> will have the time, I will welcome a dump of the same area as
>before
>> >>> so we will try to understand what is wrong now ! :)  
>> >> Nice one, a lot easier to read whats happens
>> >>
>> >> nanddump of BBT without ECC enabled:
>> >> https://gist.github.com/anonymous/627e5be058ed93c106d61641f6aa5da0
>> >>
>> >> nanddump of BBT with ECC enabled:
>> >> https://gist.github.com/anonymous/76b3240f156c6547cf76d59f2aae49fe
>> >> bootsnippet with ECC and NAND_SKIP_BBTSCAN enabled.
>> >> https://gist.github.com/anonymous/0d9be95cd9c36ff006f7aa03e7c2cc85
>> >>
>> >> Please let me know what traces you need to fix the ECC :-)  
>> > The dumps look good (at least, the BBT pattern is correct, we have
>the
>> > number of ECC bytes we expect and they are where we expect them).
>> >
>> > My gut feeling is that something is wrong with ECC (or something
>related
>> > to ECC) in u-boot.
>> >
>> > Can you try to let Linux create the BBT on its own and dump the
>last
>> > block as you did previously?
>> >
>> > So, to sum-up
>> >
>> > 1/ put the following in your DT
>> >
>> > 	nand-ecc-mode = "hw";
>> > 	nand-on-flash-bbt;
>> >
>> > 2/ scrub the NAND from u-boot and make sure you don't reboot after
>that,
>> >     so that u-boot can't recreate its own BBT.
>> >
>> > 3/ Let Linux boot and dump the pages (in raw mode) where BBTs
>created by
>> > Linux are supposed to be (should be the same addresses as before)  
>> Trace with nand scrub in uboot and ecc enabled:
>> https://gist.github.com/anonymous/3ce389b9276fddbd46f59c89b99ee4ff
>> 
>> Same as above with "chip->options |= NAND_SKIP_BBTSCAN;" in the
>marvell 
>> nand driver
>> https://gist.github.com/anonymous/3aed159b5a5ee22f27403fe79ba97400
>> 
>> If I dump 0xFEC0000/0xFFC0000 or 0xFEE0000/0xFFE0000 (the bbt pages) 
>> they contain
>> only 0xFF's as the kernel does not write to the blocks.
>> 
>> To me it seem a little bit difficult to say why the new marvell nand
>driver
>> (with ecc enabled) thinks all the freshly scrubbed blocks are bad.
>
>Ok, now I really need the dump without the -n option. It seems that
>dumping in non-raw mode does not return the expected value.
>
How can I get the driver to write a bbt when it have marked all the blocks bad?

So I do a trace, without the -n option, with ecc enabled and NAND_SKIP_BBTSCAN set?
Is that what you need?

/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [SPAM] Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-17 22:15                                                                                           ` [SPAM] " Sean Nyekjær
@ 2017-12-17 22:19                                                                                             ` Boris Brezillon
  2017-12-17 22:19                                                                                             ` Miquel RAYNAL
  1 sibling, 0 replies; 85+ messages in thread
From: Boris Brezillon @ 2017-12-17 22:19 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: Miquel RAYNAL, ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

On Sun, 17 Dec 2017 23:15:42 +0100
Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:

> On 17 December 2017 23:00:32 CET, Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> >On Sun, 17 Dec 2017 22:47:26 +0100
> >Sean Nyekjaer <sean.nyekjaer@prevas.dk> wrote:
> >  
> >> Hi Boris and Miquel  
> >> >>>       
> >> >>>> I also tried booting with ECC enabled and with that enabled the
> >> >>>> driver is unable to read the bbt and marked all blocks bad.    
> >> >>> And if I understand correctly, if you remove nand-ecc-mode =  
> >"none" (or  
> >> >>> set it to "hw"), the kernel fails to find the BBT, that is right?  
> >   
> >> >> Yes.    
> >> >>> As I was not expecting such a quick answer, I did push another  
> >patch  
> >> >>> after sending my email that fixes an issue in mtdcore.c, please  
> >check  
> >> >>> you have it (there are a few "fixup!" patches, and on top of them  
> >you  
> >> >>> must find one which is a well-formatted patch about
> >> >>> mtd_check_oob_ops()).    
> >> >> I have rebased on top of 9aee88a618f8 mtd: Fix mtd_check_oob_ops()  
> >   
> >> >>> I learned that today: to get a prompt while all blocks are bad,  
> >you can  
> >> >>> add:
> >> >>>
> >> >>>       chip->options |= NAND_SKIP_BBTSCAN;
> >> >>>
> >> >>> Before nand_scan_tail().
> >> >>>
> >> >>> If you can reach a prompt with the failing configuration and when  
> >you  
> >> >>> will have the time, I will welcome a dump of the same area as  
> >before  
> >> >>> so we will try to understand what is wrong now ! :)    
> >> >> Nice one, a lot easier to read whats happens
> >> >>
> >> >> nanddump of BBT without ECC enabled:
> >> >> https://gist.github.com/anonymous/627e5be058ed93c106d61641f6aa5da0
> >> >>
> >> >> nanddump of BBT with ECC enabled:
> >> >> https://gist.github.com/anonymous/76b3240f156c6547cf76d59f2aae49fe
> >> >> bootsnippet with ECC and NAND_SKIP_BBTSCAN enabled.
> >> >> https://gist.github.com/anonymous/0d9be95cd9c36ff006f7aa03e7c2cc85
> >> >>
> >> >> Please let me know what traces you need to fix the ECC :-)    
> >> > The dumps look good (at least, the BBT pattern is correct, we have  
> >the  
> >> > number of ECC bytes we expect and they are where we expect them).
> >> >
> >> > My gut feeling is that something is wrong with ECC (or something  
> >related  
> >> > to ECC) in u-boot.
> >> >
> >> > Can you try to let Linux create the BBT on its own and dump the  
> >last  
> >> > block as you did previously?
> >> >
> >> > So, to sum-up
> >> >
> >> > 1/ put the following in your DT
> >> >
> >> > 	nand-ecc-mode = "hw";
> >> > 	nand-on-flash-bbt;
> >> >
> >> > 2/ scrub the NAND from u-boot and make sure you don't reboot after  
> >that,  
> >> >     so that u-boot can't recreate its own BBT.
> >> >
> >> > 3/ Let Linux boot and dump the pages (in raw mode) where BBTs  
> >created by  
> >> > Linux are supposed to be (should be the same addresses as before)    
> >> Trace with nand scrub in uboot and ecc enabled:
> >> https://gist.github.com/anonymous/3ce389b9276fddbd46f59c89b99ee4ff
> >> 
> >> Same as above with "chip->options |= NAND_SKIP_BBTSCAN;" in the  
> >marvell   
> >> nand driver
> >> https://gist.github.com/anonymous/3aed159b5a5ee22f27403fe79ba97400
> >> 
> >> If I dump 0xFEC0000/0xFFC0000 or 0xFEE0000/0xFFE0000 (the bbt pages) 
> >> they contain
> >> only 0xFF's as the kernel does not write to the blocks.
> >> 
> >> To me it seem a little bit difficult to say why the new marvell nand  
> >driver  
> >> (with ecc enabled) thinks all the freshly scrubbed blocks are bad.  
> >
> >Ok, now I really need the dump without the -n option. It seems that
> >dumping in non-raw mode does not return the expected value.
> >  
> How can I get the driver to write a bbt when it have marked all the blocks bad?
> 
> So I do a trace, without the -n option, with ecc enabled and NAND_SKIP_BBTSCAN set?
> Is that what you need?

Yes, that would be a good start.

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [SPAM] Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-17 22:15                                                                                           ` [SPAM] " Sean Nyekjær
  2017-12-17 22:19                                                                                             ` Boris Brezillon
@ 2017-12-17 22:19                                                                                             ` Miquel RAYNAL
  2017-12-18  6:23                                                                                               ` Sean Nyekjær
  1 sibling, 1 reply; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-17 22:19 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: Boris Brezillon, ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

Hi Sean,

On Sun, 17 Dec 2017 23:15:42 +0100
Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:

> On 17 December 2017 23:00:32 CET, Boris Brezillon
> <boris.brezillon@free-electrons.com> wrote:
> >On Sun, 17 Dec 2017 22:47:26 +0100
> >Sean Nyekjaer <sean.nyekjaer@prevas.dk> wrote:
> >  
> >> Hi Boris and Miquel  
> >> >>>       
> >> >>>> I also tried booting with ECC enabled and with that enabled
> >> >>>> the driver is unable to read the bbt and marked all blocks
> >> >>>> bad.    
> >> >>> And if I understand correctly, if you remove nand-ecc-mode =  
> >"none" (or  
> >> >>> set it to "hw"), the kernel fails to find the BBT, that is
> >> >>> right?  
> >   
> >> >> Yes.    
> >> >>> As I was not expecting such a quick answer, I did push
> >> >>> another  
> >patch  
> >> >>> after sending my email that fixes an issue in mtdcore.c,
> >> >>> please  
> >check  
> >> >>> you have it (there are a few "fixup!" patches, and on top of
> >> >>> them  
> >you  
> >> >>> must find one which is a well-formatted patch about
> >> >>> mtd_check_oob_ops()).    
> >> >> I have rebased on top of 9aee88a618f8 mtd: Fix
> >> >> mtd_check_oob_ops()  
> >   
> >> >>> I learned that today: to get a prompt while all blocks are
> >> >>> bad,  
> >you can  
> >> >>> add:
> >> >>>
> >> >>>       chip->options |= NAND_SKIP_BBTSCAN;
> >> >>>
> >> >>> Before nand_scan_tail().
> >> >>>
> >> >>> If you can reach a prompt with the failing configuration and
> >> >>> when  
> >you  
> >> >>> will have the time, I will welcome a dump of the same area as  
> >before  
> >> >>> so we will try to understand what is wrong now ! :)    
> >> >> Nice one, a lot easier to read whats happens
> >> >>
> >> >> nanddump of BBT without ECC enabled:
> >> >> https://gist.github.com/anonymous/627e5be058ed93c106d61641f6aa5da0
> >> >>
> >> >> nanddump of BBT with ECC enabled:
> >> >> https://gist.github.com/anonymous/76b3240f156c6547cf76d59f2aae49fe
> >> >> bootsnippet with ECC and NAND_SKIP_BBTSCAN enabled.
> >> >> https://gist.github.com/anonymous/0d9be95cd9c36ff006f7aa03e7c2cc85
> >> >>
> >> >> Please let me know what traces you need to fix the ECC :-)    
> >> > The dumps look good (at least, the BBT pattern is correct, we
> >> > have  
> >the  
> >> > number of ECC bytes we expect and they are where we expect them).
> >> >
> >> > My gut feeling is that something is wrong with ECC (or
> >> > something  
> >related  
> >> > to ECC) in u-boot.
> >> >
> >> > Can you try to let Linux create the BBT on its own and dump the  
> >last  
> >> > block as you did previously?
> >> >
> >> > So, to sum-up
> >> >
> >> > 1/ put the following in your DT
> >> >
> >> > 	nand-ecc-mode = "hw";
> >> > 	nand-on-flash-bbt;
> >> >
> >> > 2/ scrub the NAND from u-boot and make sure you don't reboot
> >> > after  
> >that,  
> >> >     so that u-boot can't recreate its own BBT.
> >> >
> >> > 3/ Let Linux boot and dump the pages (in raw mode) where BBTs  
> >created by  
> >> > Linux are supposed to be (should be the same addresses as
> >> > before)    
> >> Trace with nand scrub in uboot and ecc enabled:
> >> https://gist.github.com/anonymous/3ce389b9276fddbd46f59c89b99ee4ff
> >> 
> >> Same as above with "chip->options |= NAND_SKIP_BBTSCAN;" in the  
> >marvell   
> >> nand driver
> >> https://gist.github.com/anonymous/3aed159b5a5ee22f27403fe79ba97400
> >> 
> >> If I dump 0xFEC0000/0xFFC0000 or 0xFEE0000/0xFFE0000 (the bbt
> >> pages) they contain
> >> only 0xFF's as the kernel does not write to the blocks.
> >> 
> >> To me it seem a little bit difficult to say why the new marvell
> >> nand  
> >driver  
> >> (with ecc enabled) thinks all the freshly scrubbed blocks are
> >> bad.  
> >
> >Ok, now I really need the dump without the -n option. It seems that
> >dumping in non-raw mode does not return the expected value.
> >  
> How can I get the driver to write a bbt when it have marked all the
> blocks bad?

I think the easier way is to let U-Boot do it. So I guess you'll have
to reboot the board after scrubbing.

> 
> So I do a trace, without the -n option, with ecc enabled and
> NAND_SKIP_BBTSCAN set? Is that what you need?

It will be helpful, yes!

Thanks,
Miquèl

> 
> /Sean



-- 
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [SPAM] Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-17 22:19                                                                                             ` Miquel RAYNAL
@ 2017-12-18  6:23                                                                                               ` Sean Nyekjær
  2017-12-18  8:56                                                                                                 ` Miquel RAYNAL
  2017-12-18  8:57                                                                                                 ` [SPAM] " Boris Brezillon
  0 siblings, 2 replies; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-18  6:23 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: Boris Brezillon, ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

Hi Boris and Miquel


>>>>>>>        
>>>>>>>> I also tried booting with ECC enabled and with that enabled
>>>>>>>> the driver is unable to read the bbt and marked all blocks
>>>>>>>> bad.
>>>>>>> And if I understand correctly, if you remove nand-ecc-mode =
>>> "none" (or
>>>>>>> set it to "hw"), the kernel fails to find the BBT, that is
>>>>>>> right?
>>>    
>>>>>> Yes.
>>>>>>> As I was not expecting such a quick answer, I did push
>>>>>>> another
>>> patch
>>>>>>> after sending my email that fixes an issue in mtdcore.c,
>>>>>>> please
>>> check
>>>>>>> you have it (there are a few "fixup!" patches, and on top of
>>>>>>> them
>>> you
>>>>>>> must find one which is a well-formatted patch about
>>>>>>> mtd_check_oob_ops()).
>>>>>> I have rebased on top of 9aee88a618f8 mtd: Fix
>>>>>> mtd_check_oob_ops()
>>>    
>>>>>>> I learned that today: to get a prompt while all blocks are
>>>>>>> bad,
>>> you can
>>>>>>> add:
>>>>>>>
>>>>>>>        chip->options |= NAND_SKIP_BBTSCAN;
>>>>>>>
>>>>>>> Before nand_scan_tail().
>>>>>>>
>>>>>>> If you can reach a prompt with the failing configuration and
>>>>>>> when
>>> you
>>>>>>> will have the time, I will welcome a dump of the same area as
>>> before
>>>>>>> so we will try to understand what is wrong now ! :)
>>>>>> Nice one, a lot easier to read whats happens
>>>>>>
>>>>>> nanddump of BBT without ECC enabled:
>>>>>> https://gist.github.com/anonymous/627e5be058ed93c106d61641f6aa5da0
>>>>>>
>>>>>> nanddump of BBT with ECC enabled:
>>>>>> https://gist.github.com/anonymous/76b3240f156c6547cf76d59f2aae49fe
>>>>>> bootsnippet with ECC and NAND_SKIP_BBTSCAN enabled.
>>>>>> https://gist.github.com/anonymous/0d9be95cd9c36ff006f7aa03e7c2cc85
>>>>>>
>>>>>> Please let me know what traces you need to fix the ECC :-)
>>>>> The dumps look good (at least, the BBT pattern is correct, we
>>>>> have
>>> the
>>>>> number of ECC bytes we expect and they are where we expect them).
>>>>>
>>>>> My gut feeling is that something is wrong with ECC (or
>>>>> something
>>> related
>>>>> to ECC) in u-boot.
>>>>>
>>>>> Can you try to let Linux create the BBT on its own and dump the
>>> last
>>>>> block as you did previously?
>>>>>
>>>>> So, to sum-up
>>>>>
>>>>> 1/ put the following in your DT
>>>>>
>>>>> 	nand-ecc-mode = "hw";
>>>>> 	nand-on-flash-bbt;
>>>>>
>>>>> 2/ scrub the NAND from u-boot and make sure you don't reboot
>>>>> after
>>> that,
>>>>>      so that u-boot can't recreate its own BBT.
>>>>>
>>>>> 3/ Let Linux boot and dump the pages (in raw mode) where BBTs
>>> created by
>>>>> Linux are supposed to be (should be the same addresses as
>>>>> before)
>>>> Trace with nand scrub in uboot and ecc enabled:
>>>> https://gist.github.com/anonymous/3ce389b9276fddbd46f59c89b99ee4ff
>>>>
>>>> Same as above with "chip->options |= NAND_SKIP_BBTSCAN;" in the
>>> marvell
>>>> nand driver
>>>> https://gist.github.com/anonymous/3aed159b5a5ee22f27403fe79ba97400
>>>>
>>>> If I dump 0xFEC0000/0xFFC0000 or 0xFEE0000/0xFFE0000 (the bbt
>>>> pages) they contain
>>>> only 0xFF's as the kernel does not write to the blocks.
>>>>
>>>> To me it seem a little bit difficult to say why the new marvell
>>>> nand
>>> driver
>>>> (with ecc enabled) thinks all the freshly scrubbed blocks are
>>>> bad.
>>> Ok, now I really need the dump without the -n option. It seems that
>>> dumping in non-raw mode does not return the expected value.
>>>   
>> How can I get the driver to write a bbt when it have marked all the
>> blocks bad?
> I think the easier way is to let U-Boot do it. So I guess you'll have
> to reboot the board after scrubbing.
>
>> So I do a trace, without the -n option, with ecc enabled and
>> NAND_SKIP_BBTSCAN set? Is that what you need?
> It will be helpful, yes!
>
https://gist.github.com/anonymous/08049fbb46bf6df2d24a07aab8783833

/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [SPAM] Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-18  6:23                                                                                               ` Sean Nyekjær
@ 2017-12-18  8:56                                                                                                 ` Miquel RAYNAL
  2017-12-18  9:26                                                                                                   ` Sean Nyekjær
  2017-12-18  8:57                                                                                                 ` [SPAM] " Boris Brezillon
  1 sibling, 1 reply; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-18  8:56 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: Boris Brezillon, ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

Hi Sean,

On Mon, 18 Dec 2017 07:23:04 +0100
Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:

> Hi Boris and Miquel
> 
> 
> >>>>>>>          
> >>>>>>>> I also tried booting with ECC enabled and with that enabled
> >>>>>>>> the driver is unable to read the bbt and marked all blocks
> >>>>>>>> bad.  
> >>>>>>> And if I understand correctly, if you remove nand-ecc-mode =  
> >>> "none" (or  
> >>>>>>> set it to "hw"), the kernel fails to find the BBT, that is
> >>>>>>> right?  
> >>>      
> >>>>>> Yes.  
> >>>>>>> As I was not expecting such a quick answer, I did push
> >>>>>>> another  
> >>> patch  
> >>>>>>> after sending my email that fixes an issue in mtdcore.c,
> >>>>>>> please  
> >>> check  
> >>>>>>> you have it (there are a few "fixup!" patches, and on top of
> >>>>>>> them  
> >>> you  
> >>>>>>> must find one which is a well-formatted patch about
> >>>>>>> mtd_check_oob_ops()).  
> >>>>>> I have rebased on top of 9aee88a618f8 mtd: Fix
> >>>>>> mtd_check_oob_ops()  
> >>>      
> >>>>>>> I learned that today: to get a prompt while all blocks are
> >>>>>>> bad,  
> >>> you can  
> >>>>>>> add:
> >>>>>>>
> >>>>>>>        chip->options |= NAND_SKIP_BBTSCAN;
> >>>>>>>
> >>>>>>> Before nand_scan_tail().
> >>>>>>>
> >>>>>>> If you can reach a prompt with the failing configuration and
> >>>>>>> when  
> >>> you  
> >>>>>>> will have the time, I will welcome a dump of the same area
> >>>>>>> as  
> >>> before  
> >>>>>>> so we will try to understand what is wrong now ! :)  
> >>>>>> Nice one, a lot easier to read whats happens
> >>>>>>
> >>>>>> nanddump of BBT without ECC enabled:
> >>>>>> https://gist.github.com/anonymous/627e5be058ed93c106d61641f6aa5da0
> >>>>>>
> >>>>>> nanddump of BBT with ECC enabled:
> >>>>>> https://gist.github.com/anonymous/76b3240f156c6547cf76d59f2aae49fe
> >>>>>> bootsnippet with ECC and NAND_SKIP_BBTSCAN enabled.
> >>>>>> https://gist.github.com/anonymous/0d9be95cd9c36ff006f7aa03e7c2cc85
> >>>>>>
> >>>>>> Please let me know what traces you need to fix the ECC :-)  
> >>>>> The dumps look good (at least, the BBT pattern is correct, we
> >>>>> have  
> >>> the  
> >>>>> number of ECC bytes we expect and they are where we expect
> >>>>> them).
> >>>>>
> >>>>> My gut feeling is that something is wrong with ECC (or
> >>>>> something  
> >>> related  
> >>>>> to ECC) in u-boot.
> >>>>>
> >>>>> Can you try to let Linux create the BBT on its own and dump
> >>>>> the  
> >>> last  
> >>>>> block as you did previously?
> >>>>>
> >>>>> So, to sum-up
> >>>>>
> >>>>> 1/ put the following in your DT
> >>>>>
> >>>>> 	nand-ecc-mode = "hw";
> >>>>> 	nand-on-flash-bbt;
> >>>>>
> >>>>> 2/ scrub the NAND from u-boot and make sure you don't reboot
> >>>>> after  
> >>> that,  
> >>>>>      so that u-boot can't recreate its own BBT.
> >>>>>
> >>>>> 3/ Let Linux boot and dump the pages (in raw mode) where BBTs  
> >>> created by  
> >>>>> Linux are supposed to be (should be the same addresses as
> >>>>> before)  
> >>>> Trace with nand scrub in uboot and ecc enabled:
> >>>> https://gist.github.com/anonymous/3ce389b9276fddbd46f59c89b99ee4ff
> >>>>
> >>>> Same as above with "chip->options |= NAND_SKIP_BBTSCAN;" in the  
> >>> marvell  
> >>>> nand driver
> >>>> https://gist.github.com/anonymous/3aed159b5a5ee22f27403fe79ba97400
> >>>>
> >>>> If I dump 0xFEC0000/0xFFC0000 or 0xFEE0000/0xFFE0000 (the bbt
> >>>> pages) they contain
> >>>> only 0xFF's as the kernel does not write to the blocks.
> >>>>
> >>>> To me it seem a little bit difficult to say why the new marvell
> >>>> nand  
> >>> driver  
> >>>> (with ecc enabled) thinks all the freshly scrubbed blocks are
> >>>> bad.  
> >>> Ok, now I really need the dump without the -n option. It seems
> >>> that dumping in non-raw mode does not return the expected value.
> >>>     
> >> How can I get the driver to write a bbt when it have marked all the
> >> blocks bad?  
> > I think the easier way is to let U-Boot do it. So I guess you'll
> > have to reboot the board after scrubbing.
> >  
> >> So I do a trace, without the -n option, with ecc enabled and
> >> NAND_SKIP_BBTSCAN set? Is that what you need?  
> > It will be helpful, yes!
> >  
> https://gist.github.com/anonymous/08049fbb46bf6df2d24a07aab8783833

This is really helpful. It shows the driver is the problem. I don't
know yet why it reads the NAND status instead of the actual data at
this moment. I am looking into it.

I added one fixup in my github branch that could possibly help, could
you give it a try while I am going deeper in my research?

Thank you,
Miquèl

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [SPAM] Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-18  6:23                                                                                               ` Sean Nyekjær
  2017-12-18  8:56                                                                                                 ` Miquel RAYNAL
@ 2017-12-18  8:57                                                                                                 ` Boris Brezillon
  1 sibling, 0 replies; 85+ messages in thread
From: Boris Brezillon @ 2017-12-18  8:57 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: Miquel RAYNAL, ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

On Mon, 18 Dec 2017 07:23:04 +0100
Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:

> Hi Boris and Miquel
> 
> 
> >>>>>>>          
> >>>>>>>> I also tried booting with ECC enabled and with that enabled
> >>>>>>>> the driver is unable to read the bbt and marked all blocks
> >>>>>>>> bad.  
> >>>>>>> And if I understand correctly, if you remove nand-ecc-mode =  
> >>> "none" (or  
> >>>>>>> set it to "hw"), the kernel fails to find the BBT, that is
> >>>>>>> right?  
> >>>      
> >>>>>> Yes.  
> >>>>>>> As I was not expecting such a quick answer, I did push
> >>>>>>> another  
> >>> patch  
> >>>>>>> after sending my email that fixes an issue in mtdcore.c,
> >>>>>>> please  
> >>> check  
> >>>>>>> you have it (there are a few "fixup!" patches, and on top of
> >>>>>>> them  
> >>> you  
> >>>>>>> must find one which is a well-formatted patch about
> >>>>>>> mtd_check_oob_ops()).  
> >>>>>> I have rebased on top of 9aee88a618f8 mtd: Fix
> >>>>>> mtd_check_oob_ops()  
> >>>      
> >>>>>>> I learned that today: to get a prompt while all blocks are
> >>>>>>> bad,  
> >>> you can  
> >>>>>>> add:
> >>>>>>>
> >>>>>>>        chip->options |= NAND_SKIP_BBTSCAN;
> >>>>>>>
> >>>>>>> Before nand_scan_tail().
> >>>>>>>
> >>>>>>> If you can reach a prompt with the failing configuration and
> >>>>>>> when  
> >>> you  
> >>>>>>> will have the time, I will welcome a dump of the same area as  
> >>> before  
> >>>>>>> so we will try to understand what is wrong now ! :)  
> >>>>>> Nice one, a lot easier to read whats happens
> >>>>>>
> >>>>>> nanddump of BBT without ECC enabled:
> >>>>>> https://gist.github.com/anonymous/627e5be058ed93c106d61641f6aa5da0
> >>>>>>
> >>>>>> nanddump of BBT with ECC enabled:
> >>>>>> https://gist.github.com/anonymous/76b3240f156c6547cf76d59f2aae49fe
> >>>>>> bootsnippet with ECC and NAND_SKIP_BBTSCAN enabled.
> >>>>>> https://gist.github.com/anonymous/0d9be95cd9c36ff006f7aa03e7c2cc85
> >>>>>>
> >>>>>> Please let me know what traces you need to fix the ECC :-)  
> >>>>> The dumps look good (at least, the BBT pattern is correct, we
> >>>>> have  
> >>> the  
> >>>>> number of ECC bytes we expect and they are where we expect them).
> >>>>>
> >>>>> My gut feeling is that something is wrong with ECC (or
> >>>>> something  
> >>> related  
> >>>>> to ECC) in u-boot.
> >>>>>
> >>>>> Can you try to let Linux create the BBT on its own and dump the  
> >>> last  
> >>>>> block as you did previously?
> >>>>>
> >>>>> So, to sum-up
> >>>>>
> >>>>> 1/ put the following in your DT
> >>>>>
> >>>>> 	nand-ecc-mode = "hw";
> >>>>> 	nand-on-flash-bbt;
> >>>>>
> >>>>> 2/ scrub the NAND from u-boot and make sure you don't reboot
> >>>>> after  
> >>> that,  
> >>>>>      so that u-boot can't recreate its own BBT.
> >>>>>
> >>>>> 3/ Let Linux boot and dump the pages (in raw mode) where BBTs  
> >>> created by  
> >>>>> Linux are supposed to be (should be the same addresses as
> >>>>> before)  
> >>>> Trace with nand scrub in uboot and ecc enabled:
> >>>> https://gist.github.com/anonymous/3ce389b9276fddbd46f59c89b99ee4ff
> >>>>
> >>>> Same as above with "chip->options |= NAND_SKIP_BBTSCAN;" in the  
> >>> marvell  
> >>>> nand driver
> >>>> https://gist.github.com/anonymous/3aed159b5a5ee22f27403fe79ba97400
> >>>>
> >>>> If I dump 0xFEC0000/0xFFC0000 or 0xFEE0000/0xFFE0000 (the bbt
> >>>> pages) they contain
> >>>> only 0xFF's as the kernel does not write to the blocks.
> >>>>
> >>>> To me it seem a little bit difficult to say why the new marvell
> >>>> nand  
> >>> driver  
> >>>> (with ecc enabled) thinks all the freshly scrubbed blocks are
> >>>> bad.  
> >>> Ok, now I really need the dump without the -n option. It seems that
> >>> dumping in non-raw mode does not return the expected value.
> >>>     
> >> How can I get the driver to write a bbt when it have marked all the
> >> blocks bad?  
> > I think the easier way is to let U-Boot do it. So I guess you'll have
> > to reboot the board after scrubbing.
> >  
> >> So I do a trace, without the -n option, with ecc enabled and
> >> NAND_SKIP_BBTSCAN set? Is that what you need?  
> > It will be helpful, yes!
> >  
> https://gist.github.com/anonymous/08049fbb46bf6df2d24a07aab8783833

Can you try to do the same, but this time without the -o option:

# nanddump -p -l 0x800 --bb=dumpbad -s 0xFEC0000 /dev/mtd1

Thanks,

Boris

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [SPAM] Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-18  8:56                                                                                                 ` Miquel RAYNAL
@ 2017-12-18  9:26                                                                                                   ` Sean Nyekjær
  2017-12-18  9:35                                                                                                     ` Miquel RAYNAL
  0 siblings, 1 reply; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-18  9:26 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: Boris Brezillon, ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

Hi Miquel
>>>>>>>>>> I also tried booting with ECC enabled and with that enabled
>>>>>>>>>> the driver is unable to read the bbt and marked all blocks
>>>>>>>>>> bad.
>>>>>>>>> And if I understand correctly, if you remove nand-ecc-mode =
>>>>> "none" (or
>>>>>>>>> set it to "hw"), the kernel fails to find the BBT, that is
>>>>>>>>> right?
>>>>>       
>>>>>>>> Yes.
>>>>>>>>> As I was not expecting such a quick answer, I did push
>>>>>>>>> another
>>>>> patch
>>>>>>>>> after sending my email that fixes an issue in mtdcore.c,
>>>>>>>>> please
>>>>> check
>>>>>>>>> you have it (there are a few "fixup!" patches, and on top of
>>>>>>>>> them
>>>>> you
>>>>>>>>> must find one which is a well-formatted patch about
>>>>>>>>> mtd_check_oob_ops()).
>>>>>>>> I have rebased on top of 9aee88a618f8 mtd: Fix
>>>>>>>> mtd_check_oob_ops()
>>>>>       
>>>>>>>>> I learned that today: to get a prompt while all blocks are
>>>>>>>>> bad,
>>>>> you can
>>>>>>>>> add:
>>>>>>>>>
>>>>>>>>>         chip->options |= NAND_SKIP_BBTSCAN;
>>>>>>>>>
>>>>>>>>> Before nand_scan_tail().
>>>>>>>>>
>>>>>>>>> If you can reach a prompt with the failing configuration and
>>>>>>>>> when
>>>>> you
>>>>>>>>> will have the time, I will welcome a dump of the same area
>>>>>>>>> as
>>>>> before
>>>>>>>>> so we will try to understand what is wrong now ! :)
>>>>>>>> Nice one, a lot easier to read whats happens
>>>>>>>>
>>>>>>>> nanddump of BBT without ECC enabled:
>>>>>>>> https://gist.github.com/anonymous/627e5be058ed93c106d61641f6aa5da0
>>>>>>>>
>>>>>>>> nanddump of BBT with ECC enabled:
>>>>>>>> https://gist.github.com/anonymous/76b3240f156c6547cf76d59f2aae49fe
>>>>>>>> bootsnippet with ECC and NAND_SKIP_BBTSCAN enabled.
>>>>>>>> https://gist.github.com/anonymous/0d9be95cd9c36ff006f7aa03e7c2cc85
>>>>>>>>
>>>>>>>> Please let me know what traces you need to fix the ECC :-)
>>>>>>> The dumps look good (at least, the BBT pattern is correct, we
>>>>>>> have
>>>>> the
>>>>>>> number of ECC bytes we expect and they are where we expect
>>>>>>> them).
>>>>>>>
>>>>>>> My gut feeling is that something is wrong with ECC (or
>>>>>>> something
>>>>> related
>>>>>>> to ECC) in u-boot.
>>>>>>>
>>>>>>> Can you try to let Linux create the BBT on its own and dump
>>>>>>> the
>>>>> last
>>>>>>> block as you did previously?
>>>>>>>
>>>>>>> So, to sum-up
>>>>>>>
>>>>>>> 1/ put the following in your DT
>>>>>>>
>>>>>>> 	nand-ecc-mode = "hw";
>>>>>>> 	nand-on-flash-bbt;
>>>>>>>
>>>>>>> 2/ scrub the NAND from u-boot and make sure you don't reboot
>>>>>>> after
>>>>> that,
>>>>>>>       so that u-boot can't recreate its own BBT.
>>>>>>>
>>>>>>> 3/ Let Linux boot and dump the pages (in raw mode) where BBTs
>>>>> created by
>>>>>>> Linux are supposed to be (should be the same addresses as
>>>>>>> before)
>>>>>> Trace with nand scrub in uboot and ecc enabled:
>>>>>> https://gist.github.com/anonymous/3ce389b9276fddbd46f59c89b99ee4ff
>>>>>>
>>>>>> Same as above with "chip->options |= NAND_SKIP_BBTSCAN;" in the
>>>>> marvell
>>>>>> nand driver
>>>>>> https://gist.github.com/anonymous/3aed159b5a5ee22f27403fe79ba97400
>>>>>>
>>>>>> If I dump 0xFEC0000/0xFFC0000 or 0xFEE0000/0xFFE0000 (the bbt
>>>>>> pages) they contain
>>>>>> only 0xFF's as the kernel does not write to the blocks.
>>>>>>
>>>>>> To me it seem a little bit difficult to say why the new marvell
>>>>>> nand
>>>>> driver
>>>>>> (with ecc enabled) thinks all the freshly scrubbed blocks are
>>>>>> bad.
>>>>> Ok, now I really need the dump without the -n option. It seems
>>>>> that dumping in non-raw mode does not return the expected value.
>>>>>      
>>>> How can I get the driver to write a bbt when it have marked all the
>>>> blocks bad?
>>> I think the easier way is to let U-Boot do it. So I guess you'll
>>> have to reboot the board after scrubbing.
>>>   
>>>> So I do a trace, without the -n option, with ecc enabled and
>>>> NAND_SKIP_BBTSCAN set? Is that what you need?
>>> It will be helpful, yes!
>>>   
>> https://gist.github.com/anonymous/08049fbb46bf6df2d24a07aab8783833
> This is really helpful. It shows the driver is the problem. I don't
> know yet why it reads the NAND status instead of the actual data at
> this moment. I am looking into it.
>
> I added one fixup in my github branch that could possibly help, could
> you give it a try while I am going deeper in my research?
>
Rebased on top of 8cec3f8653e0fe914d831f05cf91ab9face5c1a5
The "print_req_error: I/O error, dev mtdblock1, sector 0" is gone

And what you did have apperently fixed the issue with ecc.
The driver is reading the bbt uboot have written :-)

https://gist.github.com/anonymous/4476819c081896e5e265b3282db52e46

/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [SPAM] Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-18  9:26                                                                                                   ` Sean Nyekjær
@ 2017-12-18  9:35                                                                                                     ` Miquel RAYNAL
  2017-12-18 10:12                                                                                                       ` Sean Nyekjær
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-18  9:35 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: Boris Brezillon, ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

Hello Sean,
  
> >> https://gist.github.com/anonymous/08049fbb46bf6df2d24a07aab8783833  
> > This is really helpful. It shows the driver is the problem. I don't
> > know yet why it reads the NAND status instead of the actual data at
> > this moment. I am looking into it.
> >
> > I added one fixup in my github branch that could possibly help,
> > could you give it a try while I am going deeper in my research?
> >  
> Rebased on top of 8cec3f8653e0fe914d831f05cf91ab9face5c1a5
> The "print_req_error: I/O error, dev mtdblock1, sector 0" is gone
> 
> And what you did have apperently fixed the issue with ecc.
> The driver is reading the bbt uboot have written :-)
> 
> https://gist.github.com/anonymous/4476819c081896e5e265b3282db52e46

That is good news but can you please also do a dump without -n but with
-o, it failed in this configuration until now and if I am not doing any
mistake, you did not try this with the last fix?

I know the boot should have failed like the previous ones, but it is
just to be sure ;)

Thanks, we are getting closer.
Miquèl

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [SPAM] Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-18  9:35                                                                                                     ` Miquel RAYNAL
@ 2017-12-18 10:12                                                                                                       ` Sean Nyekjær
  2017-12-18 10:19                                                                                                         ` Miquel RAYNAL
  0 siblings, 1 reply; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-18 10:12 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: Boris Brezillon, ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

Hi Miquel
>>>> https://gist.github.com/anonymous/08049fbb46bf6df2d24a07aab8783833
>>> This is really helpful. It shows the driver is the problem. I don't
>>> know yet why it reads the NAND status instead of the actual data at
>>> this moment. I am looking into it.
>>>
>>> I added one fixup in my github branch that could possibly help,
>>> could you give it a try while I am going deeper in my research?
>>>   
>> Rebased on top of 8cec3f8653e0fe914d831f05cf91ab9face5c1a5
>> The "print_req_error: I/O error, dev mtdblock1, sector 0" is gone
>>
>> And what you did have apperently fixed the issue with ecc.
>> The driver is reading the bbt uboot have written :-)
>>
>> https://gist.github.com/anonymous/4476819c081896e5e265b3282db52e46
> That is good news but can you please also do a dump without -n but with
> -o, it failed in this configuration until now and if I am not doing any
> mistake, you did not try this with the last fix?
Last fix?
I have rebase my kernel on top of marvell/nand-next/nfc-rework 8cec3f865
>
> I know the boot should have failed like the previous ones, but it is
> just to be sure ;)
>
https://gist.github.com/anonymous/5ee7f82c59f3f58fdc4f8392ec1afbc7

/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [SPAM] Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-18 10:12                                                                                                       ` Sean Nyekjær
@ 2017-12-18 10:19                                                                                                         ` Miquel RAYNAL
  2017-12-18 10:26                                                                                                           ` Sean Nyekjær
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel RAYNAL @ 2017-12-18 10:19 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: Boris Brezillon, ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

Hi Sean,

On Mon, 18 Dec 2017 11:12:19 +0100
Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:

> Hi Miquel
> >>>> https://gist.github.com/anonymous/08049fbb46bf6df2d24a07aab8783833  
> >>> This is really helpful. It shows the driver is the problem. I
> >>> don't know yet why it reads the NAND status instead of the actual
> >>> data at this moment. I am looking into it.
> >>>
> >>> I added one fixup in my github branch that could possibly help,
> >>> could you give it a try while I am going deeper in my research?
> >>>     
> >> Rebased on top of 8cec3f8653e0fe914d831f05cf91ab9face5c1a5
> >> The "print_req_error: I/O error, dev mtdblock1, sector 0" is gone
> >>
> >> And what you did have apperently fixed the issue with ecc.
> >> The driver is reading the bbt uboot have written :-)
> >>
> >> https://gist.github.com/anonymous/4476819c081896e5e265b3282db52e46  
> > That is good news but can you please also do a dump without -n but
> > with -o, it failed in this configuration until now and if I am not
> > doing any mistake, you did not try this with the last fix?  
> Last fix?
> I have rebase my kernel on top of marvell/nand-next/nfc-rework
> 8cec3f865

Ok that should be fine!

I have added another fix just now for the same problem on write side.

I did not spot all of that because I only worked with NAND chips
bigger than 2k, where read/writes are split.

Thank you very much for your time.
Miquèl

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-18 10:19                                                                                                         ` Miquel RAYNAL
@ 2017-12-18 10:26                                                                                                           ` Sean Nyekjær
  2017-12-18 10:45                                                                                                             ` Boris Brezillon
  0 siblings, 1 reply; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-18 10:26 UTC (permalink / raw)
  To: Miquel RAYNAL
  Cc: Boris Brezillon, ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

Hi Miquel

> Ok that should be fine!
>
> I have added another fix just now for the same problem on write side.
>
> I did not spot all of that because I only worked with NAND chips
> bigger than 2k, where read/writes are split.
>
> Thank you very much for your time.
You are welcome :-)
You could add me as a Tested-By ;-)

Will this be ready for 4.16?
What would you recommend, running with these patches
on top af 4.14 LTS or just stick with the pxa3xx driver?

/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-18 10:26                                                                                                           ` Sean Nyekjær
@ 2017-12-18 10:45                                                                                                             ` Boris Brezillon
  2017-12-18 10:48                                                                                                               ` Sean Nyekjær
  0 siblings, 1 reply; 85+ messages in thread
From: Boris Brezillon @ 2017-12-18 10:45 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: Miquel RAYNAL, ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

Hi Sean,

On Mon, 18 Dec 2017 11:26:29 +0100
Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:

> Hi Miquel
> 
> > Ok that should be fine!
> >
> > I have added another fix just now for the same problem on write side.
> >
> > I did not spot all of that because I only worked with NAND chips
> > bigger than 2k, where read/writes are split.
> >
> > Thank you very much for your time.  
> You are welcome :-)
> You could add me as a Tested-By ;-)
> 
> Will this be ready for 4.16?

If no one is complaining about regressions with the new driver, then
yes, it will be queued to the nand/next branch targeting 4.16.

> What would you recommend, running with these patches
> on top af 4.14 LTS or just stick with the pxa3xx driver?

Depends whether the old driver works fine on your board or not.
Backporting is likely to be painful because of the ->exec_op()
infrastructure which was introduced recently, but if it solves issues
you had with the old driver, then it's worth it.

Regards,

Boris

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-18 10:45                                                                                                             ` Boris Brezillon
@ 2017-12-18 10:48                                                                                                               ` Sean Nyekjær
  2017-12-18 12:43                                                                                                                 ` Boris Brezillon
  0 siblings, 1 reply; 85+ messages in thread
From: Sean Nyekjær @ 2017-12-18 10:48 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Miquel RAYNAL, ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

Hi Boris
>> Will this be ready for 4.16?
> If no one is complaining about regressions with the new driver, then
> yes, it will be queued to the nand/next branch targeting 4.16.
>
>> What would you recommend, running with these patches
>> on top af 4.14 LTS or just stick with the pxa3xx driver?
> Depends whether the old driver works fine on your board or not.
> Backporting is likely to be painful because of the ->exec_op()
> infrastructure which was introduced recently, but if it solves issues
> you had with the old driver, then it's worth it.
Your newly submitted patch fixes our issues :-)
[PATCH] mtd: nand: pxa3xx: Fix READOOB implementation

Thanks
/Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [BUG] pxa3xx: wait time out when scanning for bb
  2017-12-18 10:48                                                                                                               ` Sean Nyekjær
@ 2017-12-18 12:43                                                                                                                 ` Boris Brezillon
  0 siblings, 0 replies; 85+ messages in thread
From: Boris Brezillon @ 2017-12-18 12:43 UTC (permalink / raw)
  To: Sean Nyekjær
  Cc: Miquel RAYNAL, ezequiel.garcia, linux-mtd, Kasper Revsbech (KREV)

On Mon, 18 Dec 2017 11:48:16 +0100
Sean Nyekjær <sean.nyekjaer@prevas.dk> wrote:

> Hi Boris
> >> Will this be ready for 4.16?  
> > If no one is complaining about regressions with the new driver, then
> > yes, it will be queued to the nand/next branch targeting 4.16.
> >  
> >> What would you recommend, running with these patches
> >> on top af 4.14 LTS or just stick with the pxa3xx driver?  
> > Depends whether the old driver works fine on your board or not.
> > Backporting is likely to be painful because of the ->exec_op()
> > infrastructure which was introduced recently, but if it solves issues
> > you had with the old driver, then it's worth it.  
> Your newly submitted patch fixes our issues :-)
> [PATCH] mtd: nand: pxa3xx: Fix READOOB implementation

Can you add your Tested-by?

> 
> Thanks
> /Sean

^ permalink raw reply	[flat|nested] 85+ messages in thread

end of thread, other threads:[~2017-12-18 12:44 UTC | newest]

Thread overview: 85+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-28  9:12 [BUG] pxa3xx: wait time out when scanning for bb Sean Nyekjær
2017-11-28 13:02 ` Miquel RAYNAL
2017-11-28 13:12   ` Sean Nyekjær
2017-11-28 13:30     ` Miquel RAYNAL
2017-11-28 13:42       ` Sean Nyekjær
2017-11-28 14:04         ` Miquel RAYNAL
2017-11-29  7:14           ` Sean Nyekjær
2017-11-29  8:03             ` Miquel RAYNAL
2017-11-30 12:00               ` Sean Nyekjær
2017-11-30 17:18                 ` Miquel RAYNAL
2017-11-30 18:13                   ` Sean Nyekjær
2017-12-01  8:15                     ` Miquel RAYNAL
2017-12-01  8:54                       ` Sean Nyekjær
2017-12-07 20:38                         ` Miquel RAYNAL
2017-12-08  9:04                           ` Sean Nyekjær
2017-12-08  9:21                             ` Miquel RAYNAL
2017-12-11  8:25                               ` Sean Nyekjær
2017-12-11  8:45                                 ` Sean Nyekjær
2017-12-11  9:53                                 ` Miquel RAYNAL
2017-12-11 10:20                                   ` Sean Nyekjær
2017-12-11 11:35                                     ` Sean Nyekjær
2017-12-11 13:22                                       ` Sean Nyekjær
2017-12-11 14:02                                         ` Miquel RAYNAL
2017-12-11 14:09                                           ` Miquel RAYNAL
2017-12-11 14:49                                             ` Boris Brezillon
2017-12-12  8:44                                             ` Sean Nyekjær
2017-12-12  8:51                                               ` Miquel RAYNAL
2017-12-12  8:56                                                 ` Sean Nyekjær
2017-12-12 10:12                                                   ` Miquel RAYNAL
2017-12-12 10:55                                                     ` Sean Nyekjær
2017-12-12 11:08                                                       ` Miquel RAYNAL
2017-12-12 11:28                                                         ` Sean Nyekjær
2017-12-12 11:35                                                           ` Miquel RAYNAL
2017-12-12 11:49                                                             ` Sean Nyekjær
2017-12-12 12:47                                                               ` Miquel RAYNAL
2017-12-12 13:09                                                                 ` Sean Nyekjær
2017-12-12 13:35                                                                   ` Miquel RAYNAL
2017-12-12 18:10                                                                     ` Sean Nyekjær
2017-12-12 18:23                                                                       ` Miquel RAYNAL
2017-12-13  6:25                                                                         ` Sean Nyekjær
2017-12-13  8:41                                                                           ` Miquel RAYNAL
2017-12-13  9:31                                                                             ` Sean Nyekjær
2017-12-15 17:25                                                                             ` Miquel RAYNAL
2017-12-15 18:56                                                                               ` Sean Nyekjær
2017-12-15 19:19                                                                                 ` Miquel RAYNAL
2017-12-17 11:56                                                                                   ` Sean Nyekjaer
2017-12-17 13:19                                                                                     ` Boris Brezillon
2017-12-17 21:47                                                                                       ` Sean Nyekjaer
2017-12-17 22:00                                                                                         ` Boris Brezillon
2017-12-17 22:15                                                                                           ` [SPAM] " Sean Nyekjær
2017-12-17 22:19                                                                                             ` Boris Brezillon
2017-12-17 22:19                                                                                             ` Miquel RAYNAL
2017-12-18  6:23                                                                                               ` Sean Nyekjær
2017-12-18  8:56                                                                                                 ` Miquel RAYNAL
2017-12-18  9:26                                                                                                   ` Sean Nyekjær
2017-12-18  9:35                                                                                                     ` Miquel RAYNAL
2017-12-18 10:12                                                                                                       ` Sean Nyekjær
2017-12-18 10:19                                                                                                         ` Miquel RAYNAL
2017-12-18 10:26                                                                                                           ` Sean Nyekjær
2017-12-18 10:45                                                                                                             ` Boris Brezillon
2017-12-18 10:48                                                                                                               ` Sean Nyekjær
2017-12-18 12:43                                                                                                                 ` Boris Brezillon
2017-12-18  8:57                                                                                                 ` [SPAM] " Boris Brezillon
2017-12-17 13:48                                                                                     ` Boris Brezillon
2017-12-11 20:11                                     ` Miquel RAYNAL
2017-12-09 23:18       ` Ezequiel Garcia
2017-12-10 14:17         ` Miquel RAYNAL
2017-12-11 12:30           ` Ezequiel Garcia
2017-12-11 13:13             ` Miquel RAYNAL
2017-12-11 16:08               ` Ezequiel Garcia
2017-12-11 16:41                 ` Miquel RAYNAL
     [not found]             ` <CAL92e2W7fLjVOWFgH2PpRLRP7Tf5L1vta0jduWm+bTVm647MNQ@mail.gmail.com>
2017-12-11 16:24               ` Ezequiel Garcia
2017-12-11 16:45                 ` Boris Brezillon
2017-12-11 21:16                 ` Boris Brezillon
2017-12-12  6:01                   ` Greg Cook
2017-12-12  7:09                     ` Ezequiel Garcia
2017-12-12  7:30                       ` Greg Cook
2017-12-12  8:15                         ` Boris Brezillon
2017-12-12 16:22                           ` Ezequiel Garcia
2017-12-12  6:36               ` Sean Nyekjær
2017-12-12  6:50                 ` Ezequiel Garcia
2017-12-12  7:17                   ` Greg Cook
2017-12-09 23:04   ` Ezequiel Garcia
2017-12-09 23:22 ` Ezequiel Garcia
2017-12-09 23:24   ` Ezequiel Garcia

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.