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. > > However a few problems stands in the way of doing this: > - gpmc's ranges documentation states: "Currently, calculated values > derived from the contents of the per-CS register GPMC_CONFIG7 (as set > up by the bootloader) are used for the physical address decoding. > As this will change in the future, filling correct values here is > a requirement." This piece of documentation will need some updating. It actually works like this: If bootloader has enabled any CS, we just reserve that CS region See gpmc_mem_init() http://lxr.free-electrons.com/source/drivers/memory/omap-gpmc.c#L1374 However, if a DT node provides a range for that same CS then we adapt the already configured CS region for that. see http://lxr.free-electrons.com/source/drivers/memory/omap-gpmc.c#L1003 > But I'd end with filling something like this: > ranges = <0 0 0x20000000 0x08000000>, /* CS0: 128MB for OneNAND */ > <0 0 0x30000000 0x08000000>, /* CS0: 16MB for NAND */ for NAND size should be 0x01000000 (16MB) which is the minimum allowable segment size for OMAP GPMC CS. Also, you can only provide 1 range for CS0 here. This means that u-boot will have to update this for NAND vs OneNAND at runtime. > <5 0 0x2c000000 0x01000000>; /* CS5: 16MB for ethernet */ > Which seems unlikely to work. What are the other options? Map both > chips to the same space? That would require change in bootloader as > mapping is taken from there currently. There is no need to map both of them at the same place but just provide one CS0 configuration at a time. > - OneNAND DT child is probed differently, cs is not remapped and timings are > calculated in the code, however there are some snippets in kernel DTS' that > includes OneNAND specific timings. These are for future use? > Also, is there datasheet for OneNAND chip used in IGEPv2 available? Tried > to search for parts mentioned in igep-x-loader source and found nothing > interesting. Otherwise I could recompute register values written by > igep-x-loader to config registers to get timing, but I'd prefer to verify > them against datasheet. OneNAND is a bit complicated. There are 2 sets of timings ASYNC & SYNC. I think ASYNC timings can be provided in the DT just like for NAND case. The SYNC timings will have to be calculated at runtime based on the SYNC clock frequency. I'm not entirely sure how this could be done. For a start you could probably hardcode them, but eventually it needs to be calculated at runtime. We might need to provide a mechanism so that GPMC timings can be configured via a call from the OneNAND driver for configuring the SYNC timing bits. > > Currently omap-onenand driver fails to probe chip, but as it was probably > never tested with mainline kernel, I need to get GPMC setup right first > (or skip it and rely on botloader). Why does it fail? is gpmc_probe_onenand_child() called? Any error messages? > > Btw, is there a way to runtime distinguish between IGEPv2 and IGEP COM > in bootloader? > cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
