Support either NAND or OneNAND on omap3-gpmc CS0

Commit Message

Ladislav Michl Feb. 11, 2017, 12:59 p.m. UTC

Hi all,

finally found some time to dig into this deeper. It works now and patches
used will be sent as followups to this mail.

I was unable to find datasheet for OneNAND chip used on IGEPv2 boards,
so I copied timings from N900. It works, but it would be nice to have
something more reasonable. Agustí?

On Thu, Aug 18, 2016 at 12:06:01PM +0300, Roger Quadros wrote:
> On 17/08/16 17:49, Tony Lindgren wrote:
> > * Ladislav Michl <[e-mail]> [160816 11:51]:
> >> Hi Roger,
> >>
> >> On Mon, Aug 15, 2016 at 10:22:45AM +0300, Roger Quadros wrote:
> >>> Hi Ladis,
> >>>
> >>> On 14/08/16 11:43, Ladislav Michl wrote:
> >>>> Hi there,
> >>>>
> >>>> some IGEPv2 boards comes either with NAND or OneNAND flash memory and I'd
> >>>> like to support that with single kernel and fdt blob. As U-Boot can
> >>>> already detect flash type used I thought that having both onenand@0,0
> >>>> and nand@0,0 nodes in FDT would be easiest method. Bootloader could then
> >>>> set status="disabled" property on memory not detected.
> >>>
> >>> Yes, that should work.

And indeed does. Following patch against U-Boot's git was used:

Subject: [PATCH] igep00x0: fixup FDT according to detected flash type

Signed-off-by: Ladislav Michl <[e-mail]>
---
 board/isee/igep00x0/igep00x0.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)


> >> That logic should be positive or negative? There are both aproaches
> >> present in kernel and it is not immediately obvious under what cimcumstaces
> >> is one better than another. Having both enabled by default means higher
> >> probability that kernel boots even if bootloader does not support
> >> FDT manipulation, but I'm unsure wheneven probe code is robust enough
> >> not to break anything. Thoughts?
> > 
> > We "should" be able to have both enabled in the dts just fine have
> > it probed and have onenand or nand probe bail out for the one not found.
> > Not sure what happens with that right now though :)
> 
> That should work as well. As both request for CS0 space, the 2nd one will
> fail to be probed.

Once DT child is found its chip select is claimed and not returned back
even if device is not found. We had to change this if we want to be able
to leave both enabled. Is it worth doing so?

Patchset that follows is a first draft as we only support OF enabled kernels,
something should be done with all that nand and onenand stuff in
arch/arm/mach-omap2 anyway :-)

Comments are welcome and very appreciated in advance.

Thank you,
	ladis
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/board/isee/igep00x0/igep00x0.c b/board/isee/igep00x0/igep00x0.c
index 65cc7dfdec..e032f313a6 100644
--- a/board/isee/igep00x0/igep00x0.c
+++ b/board/isee/igep00x0/igep00x0.c
@@ -214,6 +214,20 @@  void board_mmc_power_init(void)
 #endif
 
 #ifdef CONFIG_OF_BOARD_SETUP
+static int ft_enable_by_compatible(void *blob, char *compat, int enable)
+{
+	int off = fdt_node_offset_by_compatible(blob, -1, compat);
+	if (off < 0)
+		return off;
+
+	if (enable)
+		fdt_status_okay(blob, off);
+	else
+		fdt_status_disabled(blob, off);
+
+	return 0;
+}
+
 int ft_board_setup(void *blob, bd_t *bd)
 {
 #ifdef CONFIG_FDT_FIXUP_PARTITIONS
@@ -224,6 +238,11 @@  int ft_board_setup(void *blob, bd_t *bd)
 
 	fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes));
 #endif
+	ft_enable_by_compatible(blob, "ti,omap2-nand",
+				gpmc_cs0_flash == MTD_DEV_TYPE_NAND);
+	ft_enable_by_compatible(blob, "ti,omap2-onenand",
+				gpmc_cs0_flash == MTD_DEV_TYPE_ONENAND);
+
 	return 0;
 }
 #endif