ARM: dts: orion5x: add device tree for kurobox-pro

Add dts file to support Buffalo/Revogear Kurobox-Pro, which is marvell orion5x based 3.5" HDD NAS.

It's a quite old product and already discontinued. So there's no official website for it. But it was an early product which used marvell orion5x 88F5182 chipset, it's popular in the community.
Some unofficial site:
- http://buffalo.nas-central.org/wiki/Category:KuroboxPro
- http://nice.kaze.com/KUROPRO_ProductSpecifications.pdf

This device tree is based on the board file:
arch/arm/mach-orion5x/kurobox_pro-setup.c

However, the NAND device, which is supported by board file, is not supported by device tree yet. So I still want to keep the board file for the time being.

+&devbus_cs0 {

arch/arm/boot/dts/orion5x-kuroboxpro.dts new file +4 -0

+	status = "disabled";
+	devbus,keep-config;
+
+	/* According to board file: arch/arm/mach-orion5x/kurobox_pro-setup.c

Quoted 10 lines · Roger Shimizu

Add dts file to support Buffalo/Revogear Kurobox-Pro, which is marvell orion5x based 3.5" HDD NAS.

It's a quite old product and already discontinued. So there's no official website for it. But it was an early product which used marvell orion5x 88F5182 chipset, it's popular in the community.
Some unofficial site:
- http://buffalo.nas-central.org/wiki/Category:KuroboxPro
- http://nice.kaze.com/KUROPRO_ProductSpecifications.pdf

Quoted 2 lines

This device tree is based on the board file:
arch/arm/mach-orion5x/kurobox_pro-setup.c

Hi Roger

This looks good, but lets try to figure out the NAND.

Quoted 9 lines

However, the NAND device, which is supported by board file, is not supported by device tree yet. So I still want to keep the board file for the time being.

+&devbus_cs0 {

arch/arm/boot/dts/orion5x-kuroboxpro.dts new file +4 -0

+     status = "disabled";
+     devbus,keep-config;
+
+     /* According to board file: arch/arm/mach-orion5x/kurobox_pro-setup.c

arch/arm/boot/dts/orion5x-kuroboxpro.dts line 97

Quoted 10 lines

arch/arm/boot/dts/orion5x-kuroboxpro.dts new file +10 -0

+      * There's a NAND flash on Device Bus CS0, but it fails on probing,
+      * so it's disabled here.
+      */
+
+     flash at 0 {
+             compatible = "cfi-flash";
+             reg = <0 0x1000000>;
+             bank-width = <1>;
+     };
+};

kurobox_pro-setup.c says:

/*
* 256K NOR flash Device bus boot chip select
*/

#define KUROBOX_PRO_NOR_BOOT_BASE 0xf4000000
#define KUROBOX_PRO_NOR_BOOT_SIZE SZ_256K

/*
* 256M NAND flash on Device bus chip select 1
*/

#define KUROBOX_PRO_NAND_BASE 0xfc000000
#define KUROBOX_PRO_NAND_SIZE SZ_2M

So there is a NOR on CS0, not NAND.

static struct platform_device kurobox_pro_nand_flash = {

        .name           = "orion_nand",
        .id             = -1,
        .dev            = {

.platform_data = &kurobox_pro_nand_data,
},
.resource = &kurobox_pro_nand_resource,
.num_resources = 1,
};

The name "orion_nand" means this fits with the driver:

drivers/mtd/nand/orion_nand.c:

static struct platform_driver orion_nand_driver = {
        .remove         = orion_nand_remove,
        .driver         = {
                .name   = "orion_nand",
                .of_match_table = of_match_ptr(orion_nand_of_match_table),
        },
};

And this uses compatible string { .compatible = "marvell,orion-nand", },

We need to add this to the dts file. The kirkwood.dtsi might be a good example to copy.

Quoted 9 lines

kurobox_pro-setup.c says:

/*
* 256K NOR flash Device bus boot chip select
*/

#define KUROBOX_PRO_NOR_BOOT_BASE 0xf4000000
#define KUROBOX_PRO_NOR_BOOT_SIZE SZ_256K

Quoted 8 lines

/*
* 256M NAND flash on Device bus chip select 1
*/

#define KUROBOX_PRO_NAND_BASE 0xfc000000
#define KUROBOX_PRO_NAND_SIZE SZ_2M

So there is a NOR on CS0, not NAND.

The NOR is on Device Bus Boot, which described in
orion5x-linkstation.dtsi and is the probed OK:

[    1.843221] Found: SST 39LF020
[    1.846391] f4000000.flash: Found 1 x8 devices at 0x0 in 8-bit bank
[    1.852715] number of JEDEC chips: 1
[    1.872860] 3 ofpart partitions found on MTD device f4000000.flash
[    1.879122] Creating 3 MTD partitions on "f4000000.flash":
[    1.884697] 0x000000000000-0x000000030000 : "header"
[    1.893209] 0x000000030000-0x00000003f000 : "uboot"
[    1.901671] 0x00000003f000-0x000000040000 : "uboot_env"

The NAND, which is on Device Bus CS0, has probing issue. I only can have it probed by the board file:

So you mean I need to refer the nand block in mbus part in kirkwood.dtsi?

        nand: nand at 012f {
            #address-cells = <1>;
            #size-cells = <1>;
            cle = <0>;
            ale = <1>;
            bank-width = <1>;
            compatible = "marvell,orion-nand";
            reg = <MBUS_ID(0x01, 0x2f) 0 0x400>;
            chip-delay = <25>;
            /* set partition map and/or chip-delay in board dts */
            clocks = <&gate_clk 7>;
            pinctrl-0 = <&pmx_nand>;
            pinctrl-names = "default";
            status = "disabled";
        };

The difficulty for me is I have no idea on
- which clock to use

- which mpp pin to use

- how to set these address

Quoted 3 lines

The NAND, which is on Device Bus CS0, has probing issue. I only can have it probed by the board file:

The comment on the board file says chip select 1, not 0.

Quoted 3 lines

The difficulty for me is I have no idea on
- which clock to use

Orion5x does not have a specific clocks for peripherals. In this case, the clock is not needed.

Quoted 1 line

- which mpp pin to use

You need to define a pinmux configuration. Looking at the board file, we have:

MPP6_NAND, /* NAND Flash REn */
MPP7_NAND, /* NAND Flash WEn */

So you can add a node to orion5x-mv88f5182.dtsi containing these two pins.

Quoted 1 line

- how to set these address

Not so sure here. The data sheet says CS1 uses Target Interface ID 1, Target Interface Attribute 0x1d.

In the soc ranges you want

reg = <MBUS_ID(0x01, 0x1d) 0 0xfc000000 0x1000000>

and in the nand node

reg = <MBUS_ID(0x01, 0x2f) 0 0x200000>;

After a few test, I found it's okay WITHOUT clock and MPP setting.

The devbus_cs0 looks like:

&devbus_cs0 {
    status = "okay";
    compatible = "marvell,orion-nand";
    reg = <MBUS_ID(0x01, 0x1e) 0 0x400>;
    cle = <0>;
    ale = <1>;
    bank-width = <1>;

    partitions {
        compatible = "fixed-partitions";
        #address-cells = <1>;
        #size-cells = <1>;

        uImage at 0 {
            reg = <0 0x400000>;
            read-only;
        };

        rootfs at 400000 {
            reg = <0x400000 0x4000000>;
            read-only;
        };

        extra at 4400000 {
            reg = <0x4400000 0xBC00000>;
            read-only;
        };
    };
};

This probes alright.

[    1.793575] nand: device found, Manufacturer ID: 0x20, Chip ID: 0xda
[    1.800006] nand: ST Micro NAND 256MiB 3,3V 8-bit
[    1.804765] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
2048, OOB size: 64
[    1.812384] Scanning device for bad blocks
[    1.876876] Bad eraseblock 1530 at 0x00000bf40000
[    1.889048] Bad eraseblock 1718 at 0x00000d6c0000
[    1.901338] Bad eraseblock 1909 at 0x00000eea0000
[    1.911572] 3 ofpart partitions found on MTD device orion_nand
[    1.917452] Creating 3 MTD partitions on "orion_nand":
[    1.922648] 0x000000000000-0x000000400000 : "uImage"
[    1.931186] 0x000000400000-0x000004400000 : "rootfs"
[    1.940139] 0x000004400000-0x000010000000 : "extra"

Quoted 8 lines

So you can add a node to orion5x-mv88f5182.dtsi containing these two pins.

Quoted 1 line

- how to set these address

Not so sure here. The data sheet says CS1 uses Target Interface ID 1, Target Interface Attribute 0x1d.

Quoted 7 lines

In the soc ranges you want

reg = <MBUS_ID(0x01, 0x1d) 0 0xfc000000 0x1000000>

and in the nand node

reg = <MBUS_ID(0x01, 0x2f) 0 0x200000>;

I also tested using "devbus_cs1" with address "<MBUS_ID(0x01, 0x1d) 0 0x400>", but with no luck. The kernel loops output full screens of "Bad eraseblock XXXX at 0xYYYY" for minutes before I forcely shutdown the device.

So it's almost sure that the NAND is on Device Bus CS0.

And I have another question.
Currently kernel probes NAND first (mtd{0,1,2}), and then jedec-flash device (mtd{3,4,5}).
Can I change something in device tree to make jedec-flash first and then NAND?

Here I paste the kernel log of jedec-flash:

[    2.000951] Found: SST 39LF020
[    2.004036] f4000000.flash: Found 1 x8 devices at 0x0 in 8-bit bank
[    2.010394] number of JEDEC chips: 1
[    2.030787] 3 ofpart partitions found on MTD device f4000000.flash
[    2.037066] Creating 3 MTD partitions on "f4000000.flash":
[    2.042649] 0x000000000000-0x000000030000 : "header"
[    2.051040] 0x000000030000-0x00000003f000 : "uboot"
[    2.059362] 0x00000003f000-0x000000040000 : "uboot_env"

Add dts file to support Buffalo/Revogear Kurobox-Pro, which is marvell orion5x based 3.5" HDD NAS.

It's a quite old product and already discontinued. So there's no official website for it. But it was an early product which used marvell orion5x 88F5182 chipset, it's popular in the community.
Some unofficial site:
- http://buffalo.nas-central.org/wiki/Category:KuroboxPro
- http://nice.kaze.com/KUROPRO_ProductSpecifications.pdf

This device tree is based on the board file:
arch/arm/mach-orion5x/kurobox_pro-setup.c
However, the probing order of NAND and JEDEC-Flash are different from the original board file, this results in incompatible minor number for a few /dev/mtdX and /dev/mtdblockX devices.
So I still want to keep the board file for the time being.

Signed-off-by Roger Shimizu <[email protected]>

Quoted 17 lines · Roger Shimizu

Add dts file to support Buffalo/Revogear Kurobox-Pro, which is marvell orion5x based 3.5" HDD NAS.

It's a quite old product and already discontinued. So there's no official website for it. But it was an early product which used marvell orion5x 88F5182 chipset, it's popular in the community.
Some unofficial site:
- http://buffalo.nas-central.org/wiki/Category:KuroboxPro
- http://nice.kaze.com/KUROPRO_ProductSpecifications.pdf

This device tree is based on the board file:
arch/arm/mach-orion5x/kurobox_pro-setup.c
However, the probing order of NAND and JEDEC-Flash are different from the original board file, this results in incompatible minor number for a few /dev/mtdX and /dev/mtdblockX devices.
So I still want to keep the board file for the time being.

Quoted 1 line

Signed-off-by Roger Shimizu <[email protected]>

Hi Roger

Looks good:

Reviewed-by Andrew Lunn <[email protected]>

Andrew