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. 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? > > 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 it doesn't seem to work, as I'm getting: omap2-onenand omap2-onenand: initializing on CS0, phys base 0x01000000, virtual base e0840000, freq 83 MHz onenand_wait: timeout! ctrl=0x0000 intr=0x0000 OneNAND Manufacturer: Unknown (0x0) with current Linus' tree, while in U-Boot device works: NAND: Muxed OneNAND(DDP) 512MB 1.8V 16-bit (0x58) OneNAND version = 0x0031 Chip support all block unlock Chip has 2 plane block = 2048, wp status = 0x2 OneNAND is mapped at 0x20000000, while NAND when present maps CS0 at 0x30000000. I have to admit that it's probably not a briliant idea and I did it this way just because those map bases where there when separate U-Boot configurations existed for OneNAND and NAND - and those numbers were probably taken from x-loader... > > 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. It already does runtime CS0 configuration updates, so we are getting correct range for free (I hope it is correct range as I used the same constants as x-loader without verification) > > <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. I'd happily start with reading datasheet, but so far noone provided pointer :-) (GPMC part is well documented, but OneNAND datasheet seems to be unavailable so far) > > 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? Please see above. regards, ladis -- 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
