[RFC] Add .dts file for Netgear ReadyNAS 102

[Willy Tarreau]

On Wed, Jul 03, 2013 at 04:44:51PM -0400, Jason Cooper wrote:
> > What makes me uncomfortable is that we have guys who have started
> > some clean work and in parallel we're doing some crap which will
> > discourage Marvell from reprioritizing their work. I'd rather keep
> > that as an out of tree patch so that nobody there claims that the
> > NAND driver already exists in the kernel.
> 
> Good point.  I was thinking the exact opposite :-P  "The in tree driver
> is crap, we'd better re-prioritize our work before people default to the
> crap driver"

Do you really think that people who provide bogus kernel patches to
vendors who sell hardware with unmaintained outdated kernels and many
bugs have anything to care about the quality of the in-kernel driver ?

I'm afraid they simply don't care a dime. I bricked my mirabox a few
days after using it, I hoped to find some JTAG info to write an openocd
driver and found nothing. I asked to apply for an NDA to get access to
this precious data (Most likely the hardware is still in beta and they
don't want the remaining flaws to be unveiled). I did this exactly one
year ago and nothing moved after maybe 20 repeated attempts, nothing
moved. Finally I managed to unbrick it by reversing the boot loader
code and their image generator.

The reality is that they absolutely don't care about their hardware
being supported by mainline since they already have enough customers
who buy their crippled LSP kernel.

> However, I agree that your more cynical pov is probably more correct.
> 
> I'd love to see the mirabox etc supported by mainline debian et al, but
> it'll have to wait.

I would love it too. The platform is good. The mirabox is small and
powerful. The AX3 is absolutely marvelous (no pun intended). I would
love that they once for all understand that they just need to let
developers do the work they barely drafted with their crappy LSP and
become one of the best linux platforms for many SOHO usages. Their
marketing would be better done by their end users and community...
But at the moment, all the makers of these devices have to live with
the idea that their devices are limited by bogus and unstable code
and that their sales suffer from this. Pfff....

OK fixed the driver. The problem was the hard-coded internal register
address which was 0xfeb00000 in previous versions and is 0xfec00000
now.

Now I'm getting this upon modprobe :

calling drivers/mtd/nand/armada_nand.c:3227 orion_nfc_probe
armada-nand d00d0000.nand: Initialize HAL based NFC in 8bit mode with DMA Disabled using BCH 4bit ECC
drivers/mtd/nand/armada_nand.c:3318:orion_nfc_probe irq=105
drivers/mtd/nand/armada_nand.c:3324:orion_nfc_probe irq=105
drivers/mtd/nand/armada_nand.c:3332:orion_nfc_probe mmio_base=fecd0000
drivers/mtd/nand/armada_nand.c:3338:orion_nfc_probe base=fecd0000
drivers/mtd/nand/armada_nand.c:1531:setNANDClock nVal=0428040a
drivers/mtd/nand/armada_nand.c:1539:setNANDClock nVal=0428080a
drivers/mtd/nand/armada_nand.c:1544:setNANDClock nVal=ff000002
drivers/mtd/nand/armada_nand.c:1552:setNANDClock nVal=ff000002
drivers/mtd/nand/armada_nand.c:1531:setNANDClock nVal=0428080a
drivers/mtd/nand/armada_nand.c:1539:setNANDClock nVal=0428050a
drivers/mtd/nand/armada_nand.c:1544:setNANDClock nVal=ff000002
drivers/mtd/nand/armada_nand.c:1552:setNANDClock nVal=ff000002
NAND device: Manufacturer ID: 0x2c, Chip ID: 0x38 (Micron NAND 1GiB 1,8V 8-bit), 1024MiB, page size: 4096, OOB size: 128
Bad block table found at page 262016, version 0x01
Bad block table found at page 261888, version 0x01
6 cmdlinepart partitions found on MTD device armada-nand
Creating 6 MTD partitions on "armada-nand":
0x000000000000-0x000000400000 : "uboot"
0x000000400000-0x000000800000 : "config"
0x000000800000-0x000001000000 : "kernel"
0x000001000000-0x000002000000 : "initrd"
0x000002000000-0x000020000000 : "rootfs"
0x000020000000-0x000040000000 : "pad"
root at mirabox:~# 

I'll tidy up a little bit this ugly thing and resend something to use
as a basis to work on.

Best regards,
Willy