[PATCH] adding ROM chips to device tree

[PATCH] adding ROM chips to device tree

[Vitaly Wool]

Hello folks,

inlined below is the patch which adds support for flash device descriptions to the OF device tree. It's inspired by and partially borrowed from Sergei's patch which can be found at http://patchwork.ozlabs.org/linuxppc/patch?id=6526 but arranges things in a different way.
It should be used together with the corresponding MTD layer extension the current version of which was recently posted to linux-mtd list for discussion and can be found at http://lists.infradead.org/pipermail/linux-mtd/2006-November/016700.html.
In fact, currently this description can handle only flash devices mapped into memory in a linear way. For NAND flashes we'll need a whole lot different description but let's solve problems as they arise since I'm not aware of any ppc board w/ NAND chip yet :)

 Documentation/powerpc/booting-without-of.txt |   37 +++++++++++++++++++++++++++
 arch/powerpc/sysdev/Makefile                 |    1
 arch/powerpc/sysdev/flash.c                  |   27 +++++++++++++++++++
 3 files changed, 65 insertions(+)

Signed-off-by: Vitaly Wool <vwool@ru.mvista.com>

Index: powerpc/Documentation/powerpc/booting-without-of.txt
===================================================================
--- powerpc.orig/Documentation/powerpc/booting-without-of.txt
+++ powerpc/Documentation/powerpc/booting-without-of.txt
@@ -6,6 +6,8 @@
     IBM Corp.
 (c) 2005 Becky Bruce <becky.bruce at freescale.com>,
     Freescale Semiconductor, FSL SOC and 32-bit additions
+(c) 2006 MontaVista Software, Inc.
+    Flash chip node definition
 
    May 18, 2005: Rev 0.1 - Initial draft, no chapter III yet.
 
@@ -1693,6 +1696,41 @@ platforms are moved over to use the flat
 		};
 	};
 
+    viii) Flash chip nodes
+
+    Flash chips (Memory Technology Devices) are often used for solid state
+    file systems on embedded devices.
+
+    Required properties:
+
+     - device_type : has to be "rom"
+     - compatible : Should be the name of the MTD driver. Currently, this is
+       most likely to be "physmap".
+     - reg : Offset and length of the register set for the device.
+
+    Recommended properties :
+
+     - bank-width : Width of the flash data bus in bytes. Must be specified
+       for the NOR flashes.
+     - partitions : Several pairs of 32-bit values where the first value is
+       partition's offset from the start of the MTD device and the second
+       one is partition size in bytes with LSB used to signify a read only
+       partititon (so, the parition size should always be an even number).
+     - partition-names : The list of concatenated zero terminated strings
+       representing the partition names.
+
+   Example:
+
+ 	flash@ff000000 {
+ 		device_type = "rom";
+ 		compatible = "physmap";
+ 		reg = <ff000000 01000000>;
+ 		bank-width = <4>;
+ 		partitions = <00000000 00f80000
+ 			      00f80000 00080001>;
+ 		partition-names = "fs\0firmware";
+ 	};
+
    More devices will be defined as this spec matures.
 
 
Index: powerpc/arch/powerpc/sysdev/Makefile
===================================================================
--- powerpc.orig/arch/powerpc/sysdev/Makefile
+++ powerpc/arch/powerpc/sysdev/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_MMIO_NVRAM)	+= mmio_nvram.o
 obj-$(CONFIG_FSL_SOC)		+= fsl_soc.o
 obj-$(CONFIG_TSI108_BRIDGE)	+= tsi108_pci.o tsi108_dev.o
 obj-$(CONFIG_QUICC_ENGINE)	+= qe_lib/
+obj-$(CONFIG_MTD)		+= flash.o
 
 ifeq ($(CONFIG_PPC_MERGE),y)
 obj-$(CONFIG_PPC_I8259)		+= i8259.o
Index: powerpc/arch/powerpc/sysdev/flash.c
===================================================================
--- /dev/null
+++ powerpc/arch/powerpc/sysdev/flash.c
@@ -0,0 +1,27 @@
+/*
+ * arch/powerpc/sysdev/flash.c
+ *
+ * Flash memory registration
+ *
+ * (C) 2006 MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include <asm/of_device.h>
+
+static int __init powerpc_flash_init(void)
+{
+	struct device_node *node = NULL;
+	int num = 0;
+
+	while ((node = of_find_compatible_node(node, "mtd", "physmap"))
+			!= NULL) {
+		of_platform_device_create(node, "physmap-flash", NULL);
+		++num;
+	}
+	return 0;
+}
+
+arch_initcall(powerpc_flash_init);

Re: [PATCH] adding ROM chips to device tree

[Josh Boyer]

On Thu, 2006-11-02 at 14:55 +0300, Vitaly Wool wrote:
> In fact, currently this description can handle only flash devices mapped into memory in a linear way.
>  For NAND flashes we'll need a whole lot different description but let's solve problems as they arise
>  since I'm not aware of any ppc board w/ NAND chip yet :)

Um...  all of the 440EP and 440EPx boards have NAND.  And those have
been around for a while...

> +
> +    Required properties:
> +
> +     - device_type : has to be "rom"

Why "rom" instead of "NOR"?

> +     - compatible : Should be the name of the MTD driver. Currently, this is
> +       most likely to be "physmap".
> +     - reg : Offset and length of the register set for the device.

reg doesn't really describe a register set here.  It's the overall
memory space for flash.

> +
> +    Recommended properties :
> +
> +     - bank-width : Width of the flash data bus in bytes. Must be specified
> +       for the NOR flashes.

This is a required property, not a recommended one.

josh

Re: [PATCH] adding ROM chips to device tree

[Vitaly Wool]

Josh Boyer wrote:
> On Thu, 2006-11-02 at 14:55 +0300, Vitaly Wool wrote:
>   
>> In fact, currently this description can handle only flash devices mapped into memory in a linear way.
>>  For NAND flashes we'll need a whole lot different description but let's solve problems as they arise
>>  since I'm not aware of any ppc board w/ NAND chip yet :)
>>     
>
> Um...  all of the 440EP and 440EPx boards have NAND.  And those have
> been around for a while...
>
>   
Okay, that's nice to know. As you might have noticed, I'm a huge fan of 
NAND flashes :)
>> +
>> +    Required properties:
>> +
>> +     - device_type : has to be "rom"
>>     
>
> Why "rom" instead of "NOR"?
>   
Hmm, it corresponds to Sergei's version. The latter had this as "mtd" 
but following the thread I preferred to give it a more generic name.
However, thinking of it now, I realize that "NOR" is probably better 
since we'll have to define another set of properties for NAND (which 
will be of type "NAND" then) :)
>   
>> +     - compatible : Should be the name of the MTD driver. Currently, this is
>> +       most likely to be "physmap".
>> +     - reg : Offset and length of the register set for the device.
>>     
>
> reg doesn't really describe a register set here.  It's the overall
> memory space for flash.
>   
Absolutely. Basically the description was just taken from Sergei's patch 
with minimal modifications :)
>   
>> +
>> +    Recommended properties :
>> +
>> +     - bank-width : Width of the flash data bus in bytes. Must be specified
>> +       for the NOR flashes.
>>     
>
> This is a required property, not a recommended one.
>   
Yea, better have it in a separate section.


Thanks,
   Vitaly

Re: [PATCH] adding ROM chips to device tree

[Sergei Shtylyov]

Hello.

Josh Boyer wrote:

>>+
>>+    Required properties:
>>+
>>+     - device_type : has to be "rom"

> Why "rom" instead of "NOR"?

    What does "NOR" mean -- logical operator? :-)
    I'd yet agree with "nor-flash", however, the physmap-driven device may not 
always be writeable, IIUC...

>>+     - compatible : Should be the name of the MTD driver. Currently, this is
>>+       most likely to be "physmap".
>>+     - reg : Offset and length of the register set for the device.

> reg doesn't really describe a register set here.  It's the overall
> memory space for flash.

    This is no more a standard boilerplate, if you look at this file.
    Also remember that we're not describing "physmap" compatible devices only.

>>+
>>+    Recommended properties :
>>+
>>+     - bank-width : Width of the flash data bus in bytes. Must be specified
>>+       for the NOR flashes.

> This is a required property, not a recommended one.

    Required by *certain* driver. Others may not need it (know beforehand).

> josh

WBR, Sergei

Re: [PATCH] adding ROM chips to device tree

[Vitaly Wool]

>     Also remember that we're not describing "physmap" compatible devices only.

No we are. This description fits nothing else but memory-mapped flashes.

Vitaly

Re: [PATCH] adding ROM chips to device tree

[Sergei Shtylyov]

Sergei Shtylyov wrote:
> Hello.
> 
> Josh Boyer wrote:
> 
> 
>>>+
>>>+    Required properties:
>>>+
>>>+     - device_type : has to be "rom"

>>Why "rom" instead of "NOR"?

>     What does "NOR" mean -- logical operator? :-)
>     I'd yet agree with "nor-flash", however, the physmap-driven device may not 
> always be writeable, IIUC...

    Hence an idea: maybe we need to introduce the "writeable" property (just a 
logical value, i.e. absent/resent)?

>>>+     - compatible : Should be the name of the MTD driver. Currently, this is
>>>+       most likely to be "physmap".
>>>+     - reg : Offset and length of the register set for the device.

>>reg doesn't really describe a register set here.  It's the overall
>>memory space for flash.

    Since "reg" property is the way for device to claim its I/O resources, it 
must be used to describe the decoded memory range, I think. Maybe I should 
have added a comment about its meaning for direct mapped devices in the first 
place...

>     This is no more a standard boilerplate, if you look at this file.

    No more than a boilerplate, I meant to say.

WBR, Sergei

Re: [PATCH] adding ROM chips to device tree

[Grant Likely]

On 11/2/06, Vitaly Wool <vwool@ru.mvista.com> wrote:
> Hello folks,
>
> inlined below is the patch which adds support for flash device descriptions to the OF device tree. It's inspired by and partially borrowed from Sergei's patch which can be found at http://patchwork.ozlabs.org/linuxppc/patch?id=6526 but arranges things in a different way.
> It should be used together with the corresponding MTD layer extension the current version of which was recently posted to linux-mtd list for discussion and can be found at http://lists.infradead.org/pipermail/linux-mtd/2006-November/016700.html.
> In fact, currently this description can handle only flash devices mapped into memory in a linear way. For NAND flashes we'll need a whole lot different description but let's solve problems as they arise since I'm not aware of any ppc board w/ NAND chip yet :)
>
>  Documentation/powerpc/booting-without-of.txt |   37 +++++++++++++++++++++++++++
>  arch/powerpc/sysdev/Makefile                 |    1
>  arch/powerpc/sysdev/flash.c                  |   27 +++++++++++++++++++
>  3 files changed, 65 insertions(+)
>
> Signed-off-by: Vitaly Wool <vwool@ru.mvista.com>
>
> Index: powerpc/Documentation/powerpc/booting-without-of.txt
> ===================================================================
> --- powerpc.orig/Documentation/powerpc/booting-without-of.txt
> +++ powerpc/Documentation/powerpc/booting-without-of.txt
> @@ -1693,6 +1696,41 @@ platforms are moved over to use the flat
>                 };
>         };
>
> +    viii) Flash chip nodes
> +
> +    Flash chips (Memory Technology Devices) are often used for solid state
> +    file systems on embedded devices.
> +
> +    Required properties:
> +
> +     - device_type : has to be "rom"
> +     - compatible : Should be the name of the MTD driver. Currently, this is
> +       most likely to be "physmap".
> +     - reg : Offset and length of the register set for the device.
> +
> +    Recommended properties :
> +
> +     - bank-width : Width of the flash data bus in bytes. Must be specified
> +       for the NOR flashes.
> +     - partitions : Several pairs of 32-bit values where the first value is
> +       partition's offset from the start of the MTD device and the second
> +       one is partition size in bytes with LSB used to signify a read only
> +       partititon (so, the parition size should always be an even number).
> +     - partition-names : The list of concatenated zero terminated strings
> +       representing the partition names.

What about selecting driver; ie. CFI vs. non-CFI FLASH devices?
(Although I'm not sure that it really matters).


-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: [PATCH] adding ROM chips to device tree

[Vitaly Wool]

> What about selecting driver; ie. CFI vs. non-CFI FLASH devices?
> (Although I'm not sure that it really matters).

It's all left for physmap to handle.

Vitaly

Re: [PATCH] adding ROM chips to device tree

[Sergei Shtylyov]

Hello.

Vitaly Wool wrote:
> Hello folks,

> inlined below is the patch which adds support for flash device descriptions to the OF device tree. It's inspired by and partially borrowed from Sergei's patch which can be found at http://patchwork.ozlabs.org/linuxppc/patch?id=6526 but arranges things in a different way.
> It should be used together with the corresponding MTD layer extension the current version of which was recently posted to linux-mtd list for discussion and can be found at http://lists.infradead.org/pipermail/linux-mtd/2006-November/016700.html.
> In fact, currently this description can handle only flash devices mapped into memory in a linear way. For NAND flashes we'll need a whole lot different description but let's solve problems as they arise since I'm not aware of any ppc board w/ NAND chip yet :)

    The set of device properties may vary from driver to driver, anway...

>  Documentation/powerpc/booting-without-of.txt |   37 +++++++++++++++++++++++++++
>  arch/powerpc/sysdev/Makefile                 |    1
>  arch/powerpc/sysdev/flash.c                  |   27 +++++++++++++++++++

    Maybe worth renaming into mtd.c...

>  3 files changed, 65 insertions(+)

> Signed-off-by: Vitaly Wool <vwool@ru.mvista.com>

> Index: powerpc/Documentation/powerpc/booting-without-of.txt
> ===================================================================
> --- powerpc.orig/Documentation/powerpc/booting-without-of.txt
> +++ powerpc/Documentation/powerpc/booting-without-of.txt
> @@ -6,6 +6,8 @@
>      IBM Corp.
>  (c) 2005 Becky Bruce <becky.bruce at freescale.com>,
>      Freescale Semiconductor, FSL SOC and 32-bit additions
> +(c) 2006 MontaVista Software, Inc.
> +    Flash chip node definition
>  
>     May 18, 2005: Rev 0.1 - Initial draft, no chapter III yet.
>  
> @@ -1693,6 +1696,41 @@ platforms are moved over to use the flat
>  		};
>  	};
>  
> +    viii) Flash chip nodes

    Ha, it shoulf be h). The stupid roman numbering was introduced for QUICC 
engine devices. I wodner whose idea it was to have *two* i) items in a row... :-)

> +
> +    Flash chips (Memory Technology Devices) are often used for solid state
> +    file systems on embedded devices.
> +
> +    Required properties:
> +
> +     - device_type : has to be "rom"
> +     - compatible : Should be the name of the MTD driver. Currently, this is
> +       most likely to be "physmap".
> +     - reg : Offset and length of the register set for the device.
> +
> +    Recommended properties :
> +
> +     - bank-width : Width of the flash data bus in bytes. Must be specified
> +       for the NOR flashes.
> +     - partitions : Several pairs of 32-bit values where the first value is
> +       partition's offset from the start of the MTD device and the second
> +       one is partition size in bytes with LSB used to signify a read only
> +       partititon (so, the parition size should always be an even number).
> +     - partition-names : The list of concatenated zero terminated strings
> +       representing the partition names.
> +
> +   Example:
> +
> + 	flash@ff000000 {
> + 		device_type = "rom";
> + 		compatible = "physmap";
> + 		reg = <ff000000 01000000>;
> + 		bank-width = <4>;
> + 		partitions = <00000000 00f80000
> + 			      00f80000 00080001>;
> + 		partition-names = "fs\0firmware";
> + 	};
> +
>     More devices will be defined as this spec matures.
>  
>  
> Index: powerpc/arch/powerpc/sysdev/Makefile
> ===================================================================
> --- powerpc.orig/arch/powerpc/sysdev/Makefile
> +++ powerpc/arch/powerpc/sysdev/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_MMIO_NVRAM)	+= mmio_nvram.o
>  obj-$(CONFIG_FSL_SOC)		+= fsl_soc.o
>  obj-$(CONFIG_TSI108_BRIDGE)	+= tsi108_pci.o tsi108_dev.o
>  obj-$(CONFIG_QUICC_ENGINE)	+= qe_lib/
> +obj-$(CONFIG_MTD)		+= flash.o
>  
>  ifeq ($(CONFIG_PPC_MERGE),y)
>  obj-$(CONFIG_PPC_I8259)		+= i8259.o
> Index: powerpc/arch/powerpc/sysdev/flash.c
> ===================================================================
> --- /dev/null
> +++ powerpc/arch/powerpc/sysdev/flash.c
> @@ -0,0 +1,27 @@
> +/*
> + * arch/powerpc/sysdev/flash.c
> + *
> + * Flash memory registration
> + *
> + * (C) 2006 MontaVista Software, Inc. This file is licensed under
> + * the terms of the GNU General Public License version 2. This program
> + * is licensed "as is" without any warranty of any kind, whether express
> + * or implied.
> + */
> +
> +#include <asm/of_device.h>
> +
> +static int __init powerpc_flash_init(void)
> +{
> +	struct device_node *node = NULL;
> +	int num = 0;

    There's no need to count anymore...

> +	while ((node = of_find_compatible_node(node, "mtd", "physmap"))

    Hey, you just changed device_type from "mtd" to "rom", do you expect this 
to still work? :-)
    And, this actually should be registering *all* devices, not only "physmap" 
ones. The of_device probing code should figure out which drivers will get 
which devices.

> +			!= NULL) {
> +		of_platform_device_create(node, "physmap-flash", NULL);
> +		++num;
> +	}
> +	return 0;
> +}
> +
> +arch_initcall(powerpc_flash_init);

WBR, Sergei

Re: [PATCH] adding ROM chips to device tree

[Vitaly Wool]

>     The set of device properties may vary from driver to driver, anway...

It's pretty easy to define set of properties universal for each type of
flash chips.


>     Hey, you just changed device_type from "mtd" to "rom", do you expect this 
> to still work? :-)

Heh, I've put the updated description in the patch but forgot to re-diff
the rest...


>     And, this actually should be registering *all* devices, not only "physmap" 
> ones. The of_device probing code should figure out which drivers will get 
> which devices.

Fine, I guess you're eager to send a respin of the patch... Feel free
to! :)

Thanks,
  Vitaly