Hi, On Fri, Jan 16, 2015 at 01:33:40PM +0100, Lars Doelle wrote: > Hi Maxime, > > > > > working on the dts for an A20 device, I'm currently at the nand. > > I assume you are aware of the current state of the NAND, right? > > Not exactly, so I better be explicit. I assume, that the linux-sunxi > /dev/nand driver does not do any wear-level mapping on the first > blocks. > > Thus I'd be able to read the first MB out by both /dev/nand in > linux-sunxi and by the mtd driver in mainline with identical results. > > Further, I have a yet unused NAND on a Lime2 board, so I could dare > to test writing to some higher addresses. That's about the experiment > I plan to do initially. > > I'm aware, that the first sectors are precious for the boot process > and must be preserved, but they could be restored via FEX-boot in > case I break them by wrong pin settings or whatever else. > > I've not researched whether ubi would touch the boot sector, and > I will not try to install any fs before making sure, that it is preserved. > I'm booting from a SD anyway, so it is only boot0 that I have to care > for to keep the device operational. But that is all a different construction > site. > > Now if you say the current state is too experimental for any such > tries, I'd better keep hands off the mainline's NAND, and I'll appreciate > all your warnings, Maxime.
The code in the current kernel doesn't support anything but SLC NAND, which means that MLC NAND won't work unless you merge some additional patches on top of that. UBIFS doesn't deal well with MLC NAND, so you could also end up with corrupted pages in case of a power failure for example. This is also still a bit rough around the edges, so it won't work out of the box for your board, and you might encounter driver bugs. Nothing really bad if you know what you're doing, but still, you have to know what you are doing. > > > Looking at Documentation/devicetree/bindings/mtd/sunxi-nand.txt, > > > there are two parts in the example, that do not really make sense > > > to me: > > > > > > 1) interrupts > > > > > > Does anyone know what interrupt is refered to in the example? > > > The A20 handbook lists GIC 69 for NAND, while 37 in the example > > > is IR 0. > > > > All the GIC interrupts above 32 are SPIs. 69 - 32 = 37 > > So I use 37, as this is a SPI interrupt. Yep, with the first argument of the cell being 0, which corresponds to the GIC SPI. > > > 2) pinctrl-0 > > > > > > If I understand correctly, I'd setup two pinctrl groups, > > > one for all pins with function "nand0", i.e. PC00 to PC18. > > > PC19-PC22 are not mentioned in my FEX, so I'd leave the > > > later out. > > > > > > PC23 has function "spi0" and goes to the second group. > > > > I don't really know what you want to achieve, but it sounds sensible, > > even though I don't really know why SPI0 is involved here. > > Maxime, honestly, I don't know. I simply translated the FEX config, > which, like in the example of the [[Fex guide]], says: > > nand_spi = port:PC23<3><default><default><default> > > Now MUX 3 translates to function "spi0" for that pin, that's why SPI0 > is involved. That seems useless to me, but why not. > > > I'd leave out any allwinner,pull and allwinner,drive > > > properties for these groups assuming pinctrl derives > > > them from the functions. > > > > No. I cannot derive anything from any function. > > OK. My FEX spells <default> for all these values. I assume these are > the default values as in the A20 Handbook, section 1.19.4.24. to 1.19.4.27. > > These spell all pins driven by 20 mA but vary in pull-ups, which does > not really make much sense to me. It should all be NO_PULL, doesn't > it, or should I preserve these defaults? The default are 10mA, without any pull resistor. If that worked for you, you can keep it that way. > > > Now what puzzles me is, that in the example three groups > > > are setup distinguishing nand_pins_a and nand_rb0_pins_a, > > > though they have all the same function "nand0". Do I > > > misunderstand anything at that point, or is this grouping > > > just a matter of personal style? > > > > R/B and CS pins are optional and this configuration change to one from > > another. > > > > If your board use both the nand controller pins to do that, you need > > to mux them, but your board might not use them, or use GPIOs instead > > for example. In order to support the most cases, we split it into > > three groups: the main pins (needed by anyone), the rb pins and the cs > > pins. > > I've no idea how the tablet's board is wired actually, my only information > come from the FEX file, which is exactly like in the [[Fex guide]] example, > only that values for CE4-CE7 are left empty. Well, the FEX file already gives you some information on how the board is wired. You should have everything you need there. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
