DT GPMC SRAM and NOR flash support ?
Subsystems (6)
There's plenty of DT support going in for NAND flash, but is there any work going on to support NOR flash ?
And how about SRAM chips or other memory mapped devices ?
Regards
Mark J.
Hi Mark,
Quoted 2 lines · Mark Jackson
There's plenty of DT support going in for NAND flash, but is there any work going on to support NOR flash ?
What board and device are you working that is using NOR? I have a OMAP2420 H4 with NOR that I have been doing a bit of maintenance for but I don't spend much time on it. Eventually it will have to be done but it is always good to know if there is a pressing need.
Quoted 1 line
And how about SRAM chips or other memory mapped devices ?
Not sure about SRAM (trying to think if I have a board with SRAM even), but definitely, boards using the GPMC to interface to ethernet chips need to be added.
Cheers
Jon
Quoted 10 lines · Jon Hunter
Hi Mark,
Quoted 2 lines · Mark Jackson
There's plenty of DT support going in for NAND flash, but is there any work going on to support NOR flash ?
What board and device are you working that is using NOR? I have a OMAP2420 H4 with NOR that I have been doing a bit of maintenance for but I don't spend much time on it. Eventually it will have to be done but it is always good to know if there is a pressing need.
We have a custom AM335x CPU board (arriving on my desk within the next few weeks) that has both NAND and NOR Flash.
Quoted 5 lines
Quoted 1 line
And how about SRAM chips or other memory mapped devices ?
Not sure about SRAM (trying to think if I have a board with SRAM even), but definitely, boards using the GPMC to interface to ethernet chips need to be added.
The board also contains an FRAM chip (which is just treated as SRAM).
If you'd anything in the pipeline, I'm glad to help in any testing. I've created a custom cape board for the BeagleBone which contains the NOR flash and FRAM chips, so I'm not waiting for the new hardware to arrive.
Cheers
Mark J.
Quoted 21 lines · Mark Jackson
Quoted 10 lines · Jon Hunter
Hi Mark,
Quoted 2 lines · Mark Jackson
There's plenty of DT support going in for NAND flash, but is there any work going on to support NOR flash ?
What board and device are you working that is using NOR? I have a OMAP2420 H4 with NOR that I have been doing a bit of maintenance for but I don't spend much time on it. Eventually it will have to be done but it is always good to know if there is a pressing need.
We have a custom AM335x CPU board (arriving on my desk within the next few weeks) that has both NAND and NOR Flash.
Quoted 5 lines
Quoted 1 line
And how about SRAM chips or other memory mapped devices ?
Not sure about SRAM (trying to think if I have a board with SRAM even), but definitely, boards using the GPMC to interface to ethernet chips need to be added.
Quoted 5 lines
The board also contains an FRAM chip (which is just treated as SRAM).
If you'd anything in the pipeline, I'm glad to help in any testing. I've created a custom cape board for the BeagleBone which contains the NOR flash and FRAM chips, so I'm not waiting for the new hardware to arrive.
I've experimented with trying to add a mtd-physmap device, but no joy.
I'm guessing that the current mtd-physmap code is (in some way) currently incompatible with the GPMC device ?
Mark J.
Quoted 22 lines · Mark Jackson
Quoted 21 lines · Mark Jackson
Quoted 10 lines · Jon Hunter
Hi Mark,
Quoted 2 lines · Mark Jackson
There's plenty of DT support going in for NAND flash, but is there any work going on to support NOR flash ?
What board and device are you working that is using NOR? I have a OMAP2420 H4 with NOR that I have been doing a bit of maintenance for but I don't spend much time on it. Eventually it will have to be done but it is always good to know if there is a pressing need.
We have a custom AM335x CPU board (arriving on my desk within the next few weeks) that has both NAND and NOR Flash.
Quoted 5 lines
Quoted 1 line
And how about SRAM chips or other memory mapped devices ?
Not sure about SRAM (trying to think if I have a board with SRAM even), but definitely, boards using the GPMC to interface to ethernet chips need to be added.
Quoted 5 lines
Quoted 5 lines
The board also contains an FRAM chip (which is just treated as SRAM).
If you'd anything in the pipeline, I'm glad to help in any testing. I've created a custom cape board for the BeagleBone which contains the NOR flash and FRAM chips, so I'm not waiting for the new hardware to arrive.
Sorry for the delay. I personally don't have anything in the pipe.
Afzal, do you know of anyone looking at this?
Quoted 4 lines
I've experimented with trying to add a mtd-physmap device, but no joy.
I'm guessing that the current mtd-physmap code is (in some way) currently incompatible with the GPMC device ?
I am not familiar with mtd-physmap to comment. Is that DT specific?
Cheers
Jon
Quoted 32 lines · Jon Hunter
Quoted 22 lines · Mark Jackson
Quoted 21 lines · Mark Jackson
Quoted 10 lines · Jon Hunter
Hi Mark,
Quoted 2 lines · Mark Jackson
There's plenty of DT support going in for NAND flash, but is there any work going on to support NOR flash ?
What board and device are you working that is using NOR? I have a OMAP2420 H4 with NOR that I have been doing a bit of maintenance for but I don't spend much time on it. Eventually it will have to be done but it is always good to know if there is a pressing need.
We have a custom AM335x CPU board (arriving on my desk within the next few weeks) that has both NAND and NOR Flash.
Quoted 5 lines
Quoted 1 line
And how about SRAM chips or other memory mapped devices ?
Not sure about SRAM (trying to think if I have a board with SRAM even), but definitely, boards using the GPMC to interface to ethernet chips need to be added.
Quoted 5 lines
Quoted 5 lines
The board also contains an FRAM chip (which is just treated as SRAM).
If you'd anything in the pipeline, I'm glad to help in any testing. I've created a custom cape board for the BeagleBone which contains the NOR flash and FRAM chips, so I'm not waiting for the new hardware to arrive.
Sorry for the delay. I personally don't have anything in the pipe.
Quoted 8 lines
Afzal, do you know of anyone looking at this?
Quoted 4 lines
I've experimented with trying to add a mtd-physmap device, but no joy.
I'm guessing that the current mtd-physmap code is (in some way) currently incompatible with the GPMC device ?
I am not familiar with mtd-physmap to comment. Is that DT specific?
Well, it's documented in Documentation/devicetree/bindings/mtd/mtd-physmap.txt, showing you can specify "cfi-flash" or "mtd-ram" devices, eg (taken from mtd-physmap.txt):-
flash@ff000000 {
compatible = "amd,am29lv128ml", "cfi-flash";
reg = <ff000000 01000000>;
bank-width = <4>;
device-width = <1>;
#address-cells = <1>;
#size-cells = <1>;
fs@0 {
label = "fs";
reg = <0 f80000>;
};
firmware@f80000 {
label ="firmware";
reg = <f80000 80000>;
read-only;
};
};
sram@2,0 {
compatible = "samsung,k6f1616u6a", "mtd-ram";
reg = <2 0 0x00200000>;
bank-width = <2>;
};But I guess the GPMC needs to be configured to enable chip selects, data widths, etc.
I did get *something* on the address / data bus by adding the patches below, but I'm getting bus contention, so something else needs setting up in the GPMC.
I'm no great device driver writer, but if anyone can give me some pointers, I'm happy to keep digging.
Cheers
Mark J.
arch/arm/mach-omap2/gpmc.c +3 -0
@@ -1265,10 +1265,13 @@ static int gpmc_probe_dt(struct platform_device *pdev)struct device_node *child;const struct of_device_id *of_id =of_match_device (gpmc_dt_ids, &pdev->dev); +unsigned long base;if (!of_id)return 0 ; +gpmc_cs_request (0 ,SZ_16M , &base); +for_each_node_by_name (child,"nand" ) { ret =gpmc_probe_nand_child (pdev, child);of_node_put (child);
arch/arm/boot/dts/am335x-bone.dts +52 -1
72 lines not on this page · raw message
Quoted 60 lines · Mark Jackson
Quoted 32 lines · Jon Hunter
Quoted 22 lines · Mark Jackson
Quoted 21 lines · Mark Jackson
Quoted 10 lines · Jon Hunter
Hi Mark,
Quoted 2 lines · Mark Jackson
There's plenty of DT support going in for NAND flash, but is there any work going on to support NOR flash ?
What board and device are you working that is using NOR? I have a OMAP2420 H4 with NOR that I have been doing a bit of maintenance for but I don't spend much time on it. Eventually it will have to be done but it is always good to know if there is a pressing need.
We have a custom AM335x CPU board (arriving on my desk within the next few weeks) that has both NAND and NOR Flash.
Quoted 5 lines
Quoted 1 line
And how about SRAM chips or other memory mapped devices ?
Not sure about SRAM (trying to think if I have a board with SRAM even), but definitely, boards using the GPMC to interface to ethernet chips need to be added.
Quoted 5 lines
Quoted 5 lines
The board also contains an FRAM chip (which is just treated as SRAM).
If you'd anything in the pipeline, I'm glad to help in any testing. I've created a custom cape board for the BeagleBone which contains the NOR flash and FRAM chips, so I'm not waiting for the new hardware to arrive.
Sorry for the delay. I personally don't have anything in the pipe.
Quoted 8 lines
Afzal, do you know of anyone looking at this?
Quoted 4 lines
I've experimented with trying to add a mtd-physmap device, but no joy.
I'm guessing that the current mtd-physmap code is (in some way) currently incompatible with the GPMC device ?
I am not familiar with mtd-physmap to comment. Is that DT specific?
Well, it's documented in
Documentation/devicetree/bindings/mtd/mtd-physmap.txt, showing you can specify "cfi-flash" or "mtd-ram" devices, eg (taken from mtd-physmap.txt):-flash@ff000000 { compatible = "amd,am29lv128ml", "cfi-flash"; reg = <ff000000 01000000>; bank-width = <4>; device-width = <1>; #address-cells = <1>; #size-cells = <1>; fs@0 { label = "fs"; reg = <0 f80000>; }; firmware@f80000 { label ="firmware"; reg = <f80000 80000>; read-only;
Quoted 8 lines
};
};
sram@2,0 {
compatible = "samsung,k6f1616u6a", "mtd-ram";
reg = <2 0 0x00200000>;
bank-width = <2>;
};Ok, I see that the NOR flash on my omap2420 H4 is named "physmap-flash" (I have not ported to DT yet). So the GPMC should work with it.
Quoted 1 line
But I guess the GPMC needs to be configured to enable chip selects, data widths, etc.
Exactly.
Quoted 13 lines
I did get *something* on the address / data bus by adding the patches below, but I'm getting bus contention, so something else needs setting up in the GPMC.
I'm no great device driver writer, but if anyone can give me some pointers, I'm happy to keep digging.
Cheers
Mark J.arch/arm/mach-omap2/gpmc.c +0
-0
arch/arm/mach-omap2/gpmc.c static int gpmc_probe_dt(struct platform_device *pdev) · line 1274
Quoted 10 lines
arch/arm/mach-omap2/gpmc.c +3
-0@@ -1265,10 +1265,13 @@ static int gpmc_probe_dt(struct platform_device *pdev)struct device_node *child;const struct of_device_id *of_id =of_match_device (gpmc_dt_ids, &pdev->dev); +unsigned long base;if (!of_id)return 0 ; +gpmc_cs_request (0 ,SZ_16M , &base); +
You should check what gpmc_cs_request returns.
Where are the NOR flash timings setup? Or are they already configured by the bootloader? If so then that is probably ok for now.
arch/arm/mach-omap2/gpmc.c static int gpmc_probe_dt(struct platform_device *pdev) · line 1277
Quoted 3 lines
arch/arm/mach-omap2/gpmc.c +0
-0for_each_node_by_name (child,"nand" ) { ret =gpmc_probe_nand_child (pdev, child);of_node_put (child);
If you look at the gpmc_probe_nand_child(), this function is setting up the NAND timings for the GPMC.
Ideally, we would have a similar function for nor (ie. gpmc_probe_nor_child()), that would read the NOR information (chip-select, size, timings, etc) from DT. However, I understand that the above is just for test purposes.
Cheers
Jon
Okay ... I have made some progress, but it's not ideal.
Currently I've hacked the GPMC DT driver (gpmc_probe_dt(), etc) so it now handles setting up the chip selects and timings for NOR devices, e.g.
gpmc: gpmc@50000000 {
status = "okay";
ranges = <0 0 0x08000000 0x08000000>; /* CS0: NOR 16M */
nor@0,0 {
compatible = "spansion,s29gl064n90t", "cfi-flash";
reg = <0 0 0>;
bank-width = <2>;
gpmc,sync-clk = <0>;
gpmc,cs-on = <10>;
gpmc,cs-rd-off = <150>;
gpmc,cs-wr-off = <150>;
gpmc,adv-on = <10>;
gpmc,adv-rd-off = <10>;
gpmc,adv-wr-off = <10>;
gpmc,oe-on = <30>;
gpmc,oe-off = <150>;
gpmc,we-on = <30>;
gpmc,we-off = <150>;
gpmc,rd-cycle = <150>;
gpmc,wr-cycle = <150>;
gpmc,access = <130>;
gpmc,page-burst-access = <10>;
gpmc,cycle2cycle-diff = <1>;
gpmc,cycle2cycle-same = <1>;
gpmc,cycle2cycle-delay = <10>;
gpmc,wr-data-mux-bus = <60>;
};
};But the physmap driver (of_flash_probe()) is unable to use this information. It seems that although I can call of_flash_probe() from my NOR setup code, the platform_device being reference is wrong.
The platform_device passed to my gpmc_probe_nor_child() routine from gpmc_probe_dt() points to my gpmc entry (above), but the physmap probe requires its own DT entry (rather than a node child such as my NOR entry with the GPMC device entry).
So I need to have any extra entry in the DT file as follows:-
nor-flash@08000000 {
compatible = "spansion,s29gl064n90t", "cfi-flash";
reg = <0x08000000 0x00800000>;
bank-width = <2>;
};So the GPMC entry handles all the chip select and timing setup, but the 2nd entry is the only one the physmap driver can see.
Would it be acceptable to re-code of_flash_probe() to allow either a child device_node to be passed or a platform_device ?
Cheers
Mark J.
Quoted 1 line · Mark Jackson
Okay ... I have made some progress, but it's not ideal.
<snip>
Quoted 15 lines
But the physmap driver (
of_flash_probe()) is unable to use this information. It seems that although I can callof_flash_probe()from my NOR setup code, theplatform_devicebeing reference is wrong.The
platform_devicepassed to mygpmc_probe_nor_child()routine fromgpmc_probe_dt()points to my gpmc entry (above), but the physmap probe requires its own DT entry (rather than a node child such as my NOR entry with the GPMC device entry).So I need to have any extra entry in the DT file as follows:-
nor-flash@08000000 { compatible = "spansion,s29gl064n90t", "cfi-flash"; reg = <0x08000000 0x00800000>; bank-width = <2>; };
Quoted 5 lines
So the GPMC entry handles all the chip select and timing setup, but the 2nd entry is the only one the physmap driver can see.
Would it be acceptable to re-code
of_flash_probe()to allow either a childdevice_nodeto be passed or aplatform_device?
Or is it acceptable to simply state the gpmc portion is for setting up the chip access, and you *do* need a separate physmap section ?
That's certainly easier, and it works without any changes to the physmap driver.
Regards
Mark J.
Quoted 51 lines · Mark Jackson
Okay ... I have made some progress, but it's not ideal.
Currently I've hacked the GPMC DT driver (
gpmc_probe_dt(), etc) so it now handles setting up the chip selects and timings for NOR devices, e.g.gpmc: gpmc@50000000 { status = "okay"; ranges = <0 0 0x08000000 0x08000000>; /* CS0: NOR 16M */ nor@0,0 { compatible = "spansion,s29gl064n90t", "cfi-flash"; reg = <0 0 0>; bank-width = <2>; gpmc,sync-clk = <0>; gpmc,cs-on = <10>; gpmc,cs-rd-off = <150>; gpmc,cs-wr-off = <150>; gpmc,adv-on = <10>; gpmc,adv-rd-off = <10>; gpmc,adv-wr-off = <10>; gpmc,oe-on = <30>; gpmc,oe-off = <150>; gpmc,we-on = <30>; gpmc,we-off = <150>; gpmc,rd-cycle = <150>; gpmc,wr-cycle = <150>; gpmc,access = <130>; gpmc,page-burst-access = <10>; gpmc,cycle2cycle-diff = <1>; gpmc,cycle2cycle-same = <1>; gpmc,cycle2cycle-delay = <10>; gpmc,wr-data-mux-bus = <60>; }; };But the physmap driver (
of_flash_probe()) is unable to use this information. It seems that although I can callof_flash_probe()from my NOR setup code, theplatform_devicebeing reference is wrong.The
platform_devicepassed to mygpmc_probe_nor_child()routine fromgpmc_probe_dt()points to my gpmc entry (above), but the physmap probe requires its own DT entry (rather than a node child such as my NOR entry with the GPMC device entry).So I need to have any extra entry in the DT file as follows:-
nor-flash@08000000 { compatible = "spansion,s29gl064n90t", "cfi-flash"; reg = <0x08000000 0x00800000>; bank-width = <2>; };
Quoted 5 lines
So the GPMC entry handles all the chip select and timing setup, but the 2nd entry is the only one the physmap driver can see.
Would it be acceptable to re-code
of_flash_probe()to allow either a childdevice_nodeto be passed or aplatform_device?
Ideally, it should be a child device of the gpmc so that if the gpmc device fails to init correctly, the child is not registered.
I need to think about this some more to figure out the best way to handle nor.
Cheers
Jon
Hi Mark,
Quoted 36 lines · Mark Jackson
Okay ... I have made some progress, but it's not ideal.
Currently I've hacked the GPMC DT driver (
gpmc_probe_dt(), etc) so it now handles setting up the chip selects and timings for NOR devices, e.g.gpmc: gpmc@50000000 { status = "okay"; ranges = <0 0 0x08000000 0x08000000>; /* CS0: NOR 16M */ nor@0,0 { compatible = "spansion,s29gl064n90t", "cfi-flash"; reg = <0 0 0>; bank-width = <2>; gpmc,sync-clk = <0>; gpmc,cs-on = <10>; gpmc,cs-rd-off = <150>; gpmc,cs-wr-off = <150>; gpmc,adv-on = <10>; gpmc,adv-rd-off = <10>; gpmc,adv-wr-off = <10>; gpmc,oe-on = <30>; gpmc,oe-off = <150>; gpmc,we-on = <30>; gpmc,we-off = <150>; gpmc,rd-cycle = <150>; gpmc,wr-cycle = <150>; gpmc,access = <130>; gpmc,page-burst-access = <10>; gpmc,cycle2cycle-diff = <1>; gpmc,cycle2cycle-same = <1>; gpmc,cycle2cycle-delay = <10>; gpmc,wr-data-mux-bus = <60>; }; };
Quoted 7 lines
But the physmap driver (
of_flash_probe()) is unable to use this information. It seems that although I can callof_flash_probe()from my NOR setup code, theplatform_devicebeing reference is wrong.The
platform_devicepassed to mygpmc_probe_nor_child()routine fromgpmc_probe_dt()points to my gpmc entry (above), but the physmap probe requires its own DT entry (rather than a node child such as my NOR entry with the GPMC device entry).
I think you can call something like:
of_platform_populate();
On your GPMC node and have the child initialize.
This way you don't need to have separate cfi-flash compatible nodes, you can have them as childs.
Although I'm not sure this is a sane approach, I'm almost sure this should work.
Signature · 1 line
Ezequiel
Quoted 41 lines · Ezequiel Garcia
Hi Mark,
Quoted 38 lines · Mark Jackson
Okay ... I have made some progress, but it's not ideal.
Currently I've hacked the GPMC DT driver (
gpmc_probe_dt(), etc) so it now handles setting up the chip selects and timings for NOR devices, e.g.gpmc: gpmc@50000000 { status = "okay"; ranges = <0 0 0x08000000 0x08000000>; /* CS0: NOR 16M */ nor@0,0 { compatible = "spansion,s29gl064n90t", "cfi-flash"; reg = <0 0 0>; bank-width = <2>; gpmc,sync-clk = <0>; gpmc,cs-on = <10>; gpmc,cs-rd-off = <150>; gpmc,cs-wr-off = <150>; gpmc,adv-on = <10>; gpmc,adv-rd-off = <10>; gpmc,adv-wr-off = <10>; gpmc,oe-on = <30>; gpmc,oe-off = <150>; gpmc,we-on = <30>; gpmc,we-off = <150>; gpmc,rd-cycle = <150>; gpmc,wr-cycle = <150>; gpmc,access = <130>; gpmc,page-burst-access = <10>; gpmc,cycle2cycle-diff = <1>; gpmc,cycle2cycle-same = <1>; gpmc,cycle2cycle-delay = <10>; gpmc,wr-data-mux-bus = <60>; }; };But the physmap driver (
of_flash_probe()) is unable to use this information. It seems that although I can callof_flash_probe()from my NOR setup code, theplatform_devicebeing reference is wrong.
By the way, you shouldn't be calling of_flash_probe directly. If we register the device correctly this should be called for us. See below on how to fix the registering of the device.
Quoted 8 lines
Quoted 4 lines
The
platform_devicepassed to mygpmc_probe_nor_child()routine fromgpmc_probe_dt()points to my gpmc entry (above), but the physmap probe requires its own DT entry (rather than a node child such as my NOR entry with the GPMC device entry).I think you can call something like:
of_platform_populate();
This is being call from the mach-omap2/board-generic.c file on boot. Where are you suggesting this is called from?
Quoted 7 lines
On your GPMC node and have the child initialize.
This way you don't need to have separate cfi-flash compatible nodes, you can have them as childs.Although I'm not sure this is a sane approach, I'm almost sure this should work.
From looking at the DT code and playing around with my omap2 board, if
we add "simple-bus" to the compatible string for the gpmc controller, then DT will register the cfi-flash device as implemented above and you don't need the extra node. For example ...
gpmc: gpmc@6800a000 {
- compatible = "ti,omap2420-gpmc";
+ compatible = "ti,omap2420-gpmc", "simple-bus";
ti,hwmods = "gpmc";
reg = <0x6800a000 0x1000>;
interrupts = <20>;I am also concerned about how gpmc_cs_request() is implemented when we are booting with device-tree. This function is mapping the CS where ever it has space available and is not looking at the DTS to see where you want the flash to be. So this needs to be addressed too.
Cheers
Jon
Hi Jon
Quoted 4 lines · Jon Hunter
This is being call from the
mach-omap2/board-generic.cfile on boot. Where are you suggesting this is called from?
I was suggesting this could be called in gpmc_probe_dt() in gpmc.c. Instead of using for_each_node_by_name() and initialize manually each node, it should be possibly (perhaps with some ugly hack) to use of_platform_populate()
to initialize gpmc child devices.
But I'm not exactly sure how this would work.
Signature · 1 line
Ezequiel
Quoted 8 lines · Mark Jackson
Okay ... I have made some progress, but it's not ideal.
Currently I've hacked the GPMC DT driver (
gpmc_probe_dt(), etc) so it now handles setting up the chip selects and timings for NOR devices, e.g.gpmc: gpmc@50000000 { status = "okay"; ranges = <0 0 0x08000000 0x08000000>; /* CS0: NOR 16M */
Is that really 16M? Looks more like 128M :-)
Quoted 3 lines
nor@0,0 {
compatible = "spansion,s29gl064n90t", "cfi-flash";
reg = <0 0 0>;I think that cfi-flash is expecting a length here. Here is what I have ...
+&gpmc {
+ ranges = <0 0 0x08000000 0x04000000>;
+
+ nor@0,0 {
+ compatible = "cfi-flash"; + linux,mtd-name= "intel,ge28f256l18b85"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0 0 0x04000000>; + bank-width = <2>;
+
+ partition@0 {
+ label = "bootloader";
+ reg = <0 0x20000>;
+ };
+ partition@0x20000 {
+ label = "params";
+ reg = <0x20000 0x20000>;
+ };
+ partition@0x40000 {
+ label = "kernel";
+ reg = <0x40000 0x200000>;
+ };
+ partition@0x240000 {
+ label = "file-system";
+ reg = <0x240000 0x3dc0000>;
+ };
+ };
Quoted 5 lines
nor-flash@08000000 {
compatible = "spansion,s29gl064n90t", "cfi-flash";
reg = <0x08000000 0x00800000>;
bank-width = <2>;
};You don't need this extra entry if you add "simple-bus" to the gpmc node compatible string.
+ gpmc: gpmc@6800a000 {
+ compatible = "ti,omap2420-gpmc", "simple-bus"; + ti,hwmods = "gpmc"; + reg = <0x6800a000 0x1000>; + interrupts = <20>; + + gpmc,num-cs = <8>; + gpmc,num-waitpins = <4>; + #address-cells = <2>; + #size-cells = <1>;
+ };
Currently I have the following and this is working for me. Please note that on my board the bootloader is configuring the timings for me and so this is missing from the below implementation and still needs to be added.
Cheers
Jon
Quoted 1 line
From
c0ede833fad704ab452b116154177e3a59166c7eMon Sep 17 00:00:00 2001
From: Jon Hunter <[email protected]>
Date: Fri, 8 Feb 2013 16:46:13 -0600
Subject: [PATCH] ARM: OMAP2+: Add device-tree support for NOR flash
--- arch/arm/mach-omap2/gpmc.c | 69 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+)
arch/arm/mach-omap2/gpmc.c +69 -0
@@ -26,6 +26,7 @@#include <linux/interrupt.h> #include <linux/platform_device.h> #include <linux/of.h> +#include <linux/of_address.h> #include <linux/of_mtd.h> #include <linux/of_device.h> #include <linux/mtd/nand.h>
@@ -517,6 +518,26 @@ static int gpmc_cs_delete_mem(int cs)return r; } +static int gpmc_cs_remap (int cs,u32 base) +{ +int r; +u32 old_base, size; + +gpmc_cs_get_memconf (cs, &old_base, &size); +if (base == old_base) +return 0 ; +gpmc_cs_disable_mem (cs); + r =gpmc_cs_delete_mem (cs); +if (IS_ERR_VALUE (r)) +return r; + r =gpmc_cs_insert_mem (cs, base, size); +if (IS_ERR_VALUE (r)) +return r; +gpmc_cs_enable_mem (cs, base, size); + +return 0 ; +} +int gpmc_cs_request (int cs,unsigned long size,unsigned long *base) {struct resource *res = &gpmc_cs_mem[cs];
@@ -1305,6 +1326,45 @@ static int gpmc_probe_onenand_child(struct platform_device *pdev, }#endif +static int gpmc_probe_nor_child (struct platform_device *pdev, +struct device_node *child) +{ +struct resource res; +unsigned long base; +int rc, cs; + +if (of_property_read_u32 (child,"reg" , &cs) <0 ) { +dev_err (&pdev->dev,"%s has no 'reg' property\n" , + child->full_name); +return -ENODEV ; + } + +if (of_address_to_resource (child,0 , &res)) { +dev_err (&pdev->dev,"%s has malformed 'reg' property\n" , + child->full_name); +return -ENODEV ; + } + + rc =gpmc_cs_request (cs, res.end - res.start, &base); +if (rc <0 ) +pr_err ("%s: cannot request GPMC CS %d\n" , __func__, cs); + +/* +* gpmc_cs_request() will map the CS to an arbitary location +* in the gpmc address space. When booting with device-tree we +* want the NOR flash to be mapped to the location specified +* in the device-tree blob. So remap the CS to this location. +*/ + rc =gpmc_cs_remap (cs, res.start); +if (rc <0 ) { +pr_err ("%s: cannot remap GPMC CS %d to 0x%x\n" , + __func__, cs, res.start); +gpmc_cs_free (cs); + } + +return rc; +} +static int gpmc_probe_dt (struct platform_device *pdev) {int ret;
@@ -1330,6 +1390,15 @@ static int gpmc_probe_dt(struct platform_device *pdev) return ret; } } + +for_each_node_by_name (child,"nor" ) { + ret =gpmc_probe_nor_child (pdev, child); +if (ret <0 ) { +of_node_put (child); +return ret; + } + } +return 0 ; }#else
Signature · 1 line
1.7.10.4
Hi Jon,
I'm working on a similar memory controller for plat-orion. I have a few questions about your approach.
Quoted 49 lines · Jon Hunter
Quoted 8 lines · Mark Jackson
Okay ... I have made some progress, but it's not ideal.
Currently I've hacked the GPMC DT driver (
gpmc_probe_dt(), etc) so it now handles setting up the chip selects and timings for NOR devices, e.g.gpmc: gpmc@50000000 { status = "okay"; ranges = <0 0 0x08000000 0x08000000>; /* CS0: NOR 16M */Is that really 16M? Looks more like 128M :-)
Quoted 3 lines
nor@0,0 { compatible = "spansion,s29gl064n90t", "cfi-flash"; reg = <0 0 0>;I think that cfi-flash is expecting a length here. Here is what I have ...
+&gpmc {
(quoted diff) +27
-0+ ranges = <0 0 0x08000000 0x04000000>; + + nor@0,0 { + compatible = "cfi-flash"; + linux,mtd-name= "intel,ge28f256l18b85"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0 0 0x04000000>; + bank-width = <2>; + + partition@0 { + label = "bootloader"; + reg = <0 0x20000>; + }; + partition@0x20000 { + label = "params"; + reg = <0x20000 0x20000>; + }; + partition@0x40000 { + label = "kernel"; + reg = <0x40000 0x200000>; + }; + partition@0x240000 { + label = "file-system"; + reg = <0x240000 0x3dc0000>; + }; + };
Quoted 9 lines
Quoted 5 lines
nor-flash@08000000 { compatible = "spansion,s29gl064n90t", "cfi-flash"; reg = <0x08000000 0x00800000>; bank-width = <2>; };You don't need this extra entry if you add "simple-bus" to the gpmc node compatible string.
That would be nice. However, I wonder what happens if cfi-flash probing
fails: will the gpmc cs request by undone? See below...
Quoted 84 lines
(quoted diff) +11
-0+ gpmc: gpmc@6800a000 { + compatible = "ti,omap2420-gpmc", "simple-bus"; + ti,hwmods = "gpmc"; + reg = <0x6800a000 0x1000>; + interrupts = <20>; + + gpmc,num-cs = <8>; + gpmc,num-waitpins = <4>; + #address-cells = <2>; + #size-cells = <1>; + };Currently I have the following and this is working for me. Please note that on my board the bootloader is configuring the timings for me and so this is missing from the below implementation and still needs to be added.
Cheers
JonFrom
c0ede833fad704ab452b116154177e3a59166c7eMon Sep 17 00:00:00 2001
From: Jon Hunter <[email protected]>
Date: Fri, 8 Feb 2013 16:46:13 -0600
Subject: [PATCH] ARM: OMAP2+: Add device-tree support for NOR flash--- arch/arm/mach-omap2/gpmc.c | 69 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+)arch/arm/mach-omap2/gpmc.c +33
-0@@ -26,6 +26,7 @@#include <linux/interrupt.h> #include <linux/platform_device.h> #include <linux/of.h> +#include <linux/of_address.h> #include <linux/of_mtd.h> #include <linux/of_device.h> #include <linux/mtd/nand.h> @@ -517,6 +518,26 @@ static int gpmc_cs_delete_mem(int cs)return r; } +static int gpmc_cs_remap (int cs,u32 base) +{ +int r; +u32 old_base, size; + +gpmc_cs_get_memconf (cs, &old_base, &size); +if (base == old_base) +return 0 ; +gpmc_cs_disable_mem (cs); + r =gpmc_cs_delete_mem (cs); +if (IS_ERR_VALUE (r)) +return r; + r =gpmc_cs_insert_mem (cs, base, size); +if (IS_ERR_VALUE (r)) +return r; +gpmc_cs_enable_mem (cs, base, size); + +return 0 ; +} +int gpmc_cs_request (int cs,unsigned long size,unsigned long *base) {struct resource *res = &gpmc_cs_mem[cs];@@ -1305,6 +1326,45 @@ static int gpmc_probe_onenand_child(struct platform_device *pdev, }#endif +static int gpmc_probe_nor_child (struct platform_device *pdev, +struct device_node *child) +{ +struct resource res; +unsigned long base; +int rc, cs; + +if (of_property_read_u32 (child,"reg" , &cs) <0 ) { +dev_err (&pdev->dev,"%s has no 'reg' property\n" , + child->full_name); +return -ENODEV ; + }
arch/arm/mach-omap2/gpmc.c static int gpmc_probe_onenand_child(struct platform_device *pdev, · line 1350
Quoted 10 lines
arch/arm/mach-omap2/gpmc.c +10
-0+ +if (of_address_to_resource (child,0 , &res)) { +dev_err (&pdev->dev,"%s has malformed 'reg' property\n" , + child->full_name); +return -ENODEV ; + } + + rc =gpmc_cs_request (cs, res.end - res.start, &base); +if (rc <0 ) +pr_err ("%s: cannot request GPMC CS %d\n" , __func__, cs);
gpmc_cs_request will request a memory region from the resource allocator using allocate_resource().
How will this be released in case cfi-flash probe fails?
IMHO, this works fine currently for NAND and OneNAND because we register the platform device explicitly and, thus, know if that fails.
Quoted 27 lines
arch/arm/mach-omap2/gpmc.c +19
-0+ +/* +* gpmc_cs_request() will map the CS to an arbitary location +* in the gpmc address space. When booting with device-tree we +* want the NOR flash to be mapped to the location specified +* in the device-tree blob. So remap the CS to this location. +*/ + rc =gpmc_cs_remap (cs, res.start); +if (rc <0 ) { +pr_err ("%s: cannot remap GPMC CS %d to 0x%x\n" , + __func__, cs, res.start); +gpmc_cs_free (cs); + } + +return rc; +} +static int gpmc_probe_dt (struct platform_device *pdev) {int ret;@@ -1330,6 +1390,15 @@ static int gpmc_probe_dt(struct platform_device *pdev)return ret; } } + +for_each_node_by_name (child,"nor" ) {
arch/arm/mach-omap2/gpmc.c static int gpmc_probe_dt(struct platform_device *pdev) · line 1404
Quoted 10 lines
arch/arm/mach-omap2/gpmc.c +7
-0+ ret =gpmc_probe_nor_child (pdev, child); +if (ret <0 ) { +of_node_put (child); +return ret; + } + } +return 0 ; }#else
Thanks,
Signature · 7 lines
Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 167 lines · Ezequiel Garcia
Hi Jon,
I'm working on a similar memory controller for plat-orion. I have a few questions about your approach.
Quoted 49 lines · Jon Hunter
Quoted 8 lines · Mark Jackson
Okay ... I have made some progress, but it's not ideal.
Currently I've hacked the GPMC DT driver (
gpmc_probe_dt(), etc) so it now handles setting up the chip selects and timings for NOR devices, e.g.gpmc: gpmc@50000000 { status = "okay"; ranges = <0 0 0x08000000 0x08000000>; /* CS0: NOR 16M */Is that really 16M? Looks more like 128M :-)
Quoted 3 lines
nor@0,0 { compatible = "spansion,s29gl064n90t", "cfi-flash"; reg = <0 0 0>;I think that cfi-flash is expecting a length here. Here is what I have ...
+&gpmc {
(quoted diff) +27
-0+ ranges = <0 0 0x08000000 0x04000000>; + + nor@0,0 { + compatible = "cfi-flash"; + linux,mtd-name= "intel,ge28f256l18b85"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0 0 0x04000000>; + bank-width = <2>; + + partition@0 { + label = "bootloader"; + reg = <0 0x20000>; + }; + partition@0x20000 { + label = "params"; + reg = <0x20000 0x20000>; + }; + partition@0x40000 { + label = "kernel"; + reg = <0x40000 0x200000>; + }; + partition@0x240000 { + label = "file-system"; + reg = <0x240000 0x3dc0000>; + }; + };Quoted 9 lines
Quoted 5 lines
nor-flash@08000000 { compatible = "spansion,s29gl064n90t", "cfi-flash"; reg = <0x08000000 0x00800000>; bank-width = <2>; };You don't need this extra entry if you add "simple-bus" to the gpmc node compatible string.
That would be nice. However, I wonder what happens if cfi-flash probing
fails: will the gpmc cs request by undone? See below...Quoted 84 lines
(quoted diff) +11
-0+ gpmc: gpmc@6800a000 { + compatible = "ti,omap2420-gpmc", "simple-bus"; + ti,hwmods = "gpmc"; + reg = <0x6800a000 0x1000>; + interrupts = <20>; + + gpmc,num-cs = <8>; + gpmc,num-waitpins = <4>; + #address-cells = <2>; + #size-cells = <1>; + };Currently I have the following and this is working for me. Please note that on my board the bootloader is configuring the timings for me and so this is missing from the below implementation and still needs to be added.
Cheers
JonFrom
c0ede833fad704ab452b116154177e3a59166c7eMon Sep 17 00:00:00 2001
From: Jon Hunter <[email protected]>
Date: Fri, 8 Feb 2013 16:46:13 -0600
Subject: [PATCH] ARM: OMAP2+: Add device-tree support for NOR flash--- arch/arm/mach-omap2/gpmc.c | 69 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+)arch/arm/mach-omap2/gpmc.c +33
-0@@ -26,6 +26,7 @@#include <linux/interrupt.h> #include <linux/platform_device.h> #include <linux/of.h> +#include <linux/of_address.h> #include <linux/of_mtd.h> #include <linux/of_device.h> #include <linux/mtd/nand.h> @@ -517,6 +518,26 @@ static int gpmc_cs_delete_mem(int cs)return r; } +static int gpmc_cs_remap (int cs,u32 base) +{ +int r; +u32 old_base, size; + +gpmc_cs_get_memconf (cs, &old_base, &size); +if (base == old_base) +return 0 ; +gpmc_cs_disable_mem (cs); + r =gpmc_cs_delete_mem (cs); +if (IS_ERR_VALUE (r)) +return r; + r =gpmc_cs_insert_mem (cs, base, size); +if (IS_ERR_VALUE (r)) +return r; +gpmc_cs_enable_mem (cs, base, size); + +return 0 ; +} +int gpmc_cs_request (int cs,unsigned long size,unsigned long *base) {struct resource *res = &gpmc_cs_mem[cs];@@ -1305,6 +1326,45 @@ static int gpmc_probe_onenand_child(struct platform_device *pdev, }#endif +static int gpmc_probe_nor_child (struct platform_device *pdev,si + struct device_node *child) +{ +struct resource res; +unsigned long base; +int rc, cs; + +if (of_property_read_u32 (child,"reg" , &cs) <0 ) { +dev_err (&pdev->dev,"%s has no 'reg' property\n" , + child->full_name); +return -ENODEV ; + }arch/arm/mach-omap2/gpmc.c static int gpmc_probe_onenand_child(struct platform_device *pdev, · line 1350
Quoted 10 lines
arch/arm/mach-omap2/gpmc.c +10
-0+ +if (of_address_to_resource (child,0 , &res)) { +dev_err (&pdev->dev,"%s has malformed 'reg' property\n" , + child->full_name); +return -ENODEV ; + } + + rc =gpmc_cs_request (cs, res.end - res.start, &base); +if (rc <0 ) +pr_err ("%s: cannot request GPMC CS %d\n" , __func__, cs);
gpmc_cs_requestwill request a memory region from the resource allocator usingallocate_resource().
How will this be released in case cfi-flash probe fails?
Quoted 2 lines
IMHO, this works fine currently for NAND and OneNAND because we register the platform device explicitly and, thus, know if that fails.
You are correct it would not be freed. However, the nice thing about this approach is that all the nor info (name, bus-width, etc) is kept in the dts file and we don't need to keep this in some platform code.
For argument sake, although I agree that if the cfi-flash probe fails ideally we should free the CS, is this really a problem? This is not a hot-pluggable bus and so even if we do not free the CS, there is no one else that would be using it. Ok there is also memory space reserved too but that should not impact other devices either.
I don't really have strong feelings on this either way, but it does seem nice to minimise the amount of platform data in the mach-omap2 directory.
Cheers
Jon
Hi Jon,
Yet more questions :-) See below...
Review
Quoted 11 lines · Jon Hunter
You don't need this extra entry if you add "simple-bus" to the gpmc node compatible string.
(quoted diff) +6
-0+ gpmc: gpmc@6800a000 { + compatible = "ti,omap2420-gpmc", "simple-bus"; + ti,hwmods = "gpmc"; + reg = <0x6800a000 0x1000>; + interrupts = <20>; +
This "simple-bus" trick is great and very clean!
I'm working on a new driver, similar to gpmc, called device-bus for Marvell SoC. One remarkable difference is that I need to *setup* the address space (sort of allocate the address region) for a child device, before I can access it.
Using simple-bus is a very clean solution. However I'm facing a strange issue:
the child (physmap driver) probe() is being called *before* the parent (device-bus driver)probe(), and so the flash device address space cannot get accessed because it hasn't been setup yet.
Am I doing something wrong? Or is this the expected behavior?
In the latter case, I won't be able to use a compatible "simple-bus" at all, right?
Signature · 1 line
Ezequiel
Quoted 24 lines · Ezequiel Garcia
Hi Jon,
Yet more questions :-) See below...
Review
Quoted 11 lines · Jon Hunter
You don't need this extra entry if you add "simple-bus" to the gpmc node compatible string.
(quoted diff) +6
-0+ gpmc: gpmc@6800a000 { + compatible = "ti,omap2420-gpmc", "simple-bus"; + ti,hwmods = "gpmc"; + reg = <0x6800a000 0x1000>; + interrupts = <20>; +This "simple-bus" trick is great and very clean!
I'm working on a new driver, similar to gpmc, called device-bus for Marvell SoC. One remarkable difference is that I need to *setup* the address space (sort of allocate the address region) for a child device, before I can access it.
Quoted 6 lines
Using simple-bus is a very clean solution. However I'm facing a strange issue:
the child (physmap driver)probe()is being called *before* the parent (device-bus driver)probe(), and so the flash device address space cannot get accessed because it hasn't been setup yet.
Ok, now I think I understand that my problem has nothing to do with simple-bus, but instead related to the driver probing order.
The physmap driver is just being probed before the device bus driver, and so it won't work.
Now: is there any clean solution?
Signature · 1 line
Ezequiel
Quoted 32 lines · Ezequiel Garcia
Quoted 24 lines · Ezequiel Garcia
Hi Jon,
Yet more questions :-) See below...
Review
Quoted 11 lines · Jon Hunter
You don't need this extra entry if you add "simple-bus" to the gpmc node compatible string.
(quoted diff) +6
-0+ gpmc: gpmc@6800a000 { + compatible = "ti,omap2420-gpmc", "simple-bus"; + ti,hwmods = "gpmc"; + reg = <0x6800a000 0x1000>; + interrupts = <20>; +This "simple-bus" trick is great and very clean!
I'm working on a new driver, similar to gpmc, called device-bus for Marvell SoC. One remarkable difference is that I need to *setup* the address space (sort of allocate the address region) for a child device, before I can access it.
Quoted 6 lines
Using simple-bus is a very clean solution. However I'm facing a strange issue:
the child (physmap driver)probe()is being called *before* the parent (device-bus driver)probe(), and so the flash device address space cannot get accessed because it hasn't been setup yet.
Quoted 7 lines
Ok, now I think I understand that my problem has nothing to do with simple-bus, but instead related to the driver probing order.
The physmap driver is just being probed before the device bus driver, and so it won't work.
Now: is there any clean solution?
I can't say I understand why if it is a child device. I have just posted a series this week to enable NOR support for OMAP with DT [1].
Cheers
Jon
[1] http://permalink.gmane.org/gmane.linux.ports.arm.omap/94378
Hi Jon,
Quoted 5 lines · Jon
Quoted 2 lines · Mark Jackson
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
There's plenty of DT support going in for NAND flash, but is there any work going on to support NOR flash ?
Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
If you'd anything in the pipeline, I'm glad to help in any testing. I've created a custom cape board for the BeagleBone which contains the NOR flash and FRAM chips, so I'm not waiting for the new hardware to arrive.
Sorry for the delay. I personally don't have anything in the pipe.
Afzal, do you know of anyone looking at this?
I am not aware of anyone working on it.
Regards
Afzal