Hi Ladis, On 16/08/16 21:50, Ladislav Michl wrote: > 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? If both are enabled, the first one will probe and the second one won't. And error will be printed on the console. > >>> 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 I'd double check the GPMC timing configuration and GPMC settings. You could enable CONFIG_OMAP_GPMC_DEBUG and compare the bootloader timings vs kernel timings which will be printed on the console. > 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. > 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
