Joakim Tjernlund <joakim.tjernl...@transmode.se> wrote: > > > Is there any risk that the NAND device will drive the LB and > > > corrupt the bus for other devices? > > > > I think the only thing the NAND chip should be driving is the busy pin, > > OK, good. What function is actually lost if one uses an GPIO instead > of BUSY?
I tried to take this route, since it was a fairly minor board change. Unfortunately all the GPIOs were already used. I looked long and hard for a way to not have the NAND hold the bus with BUSY. If you don't connect BUSY then you can't use the LBC's flash controller (FCM mode). I haven't done it personally, but I believe that connecting BUSY to a GPIO is very common thing to do, since this is the route you'd have to take if you didn't have a built-in flash controller. The Linux MTD layer supports it. > An even better workaround would be if one could add logic between > the NAND and the CPU which would compensate for this defect without > needing special SW fixes. That probably won't work. Presumably you're talking about something like a gate so the BUSY is only passed from the NAND when the NAND's chip select is asserted. Unfortunately the NAND controller is monitoring the BUSY line, and if it sees the signal deassert then it will think the NAND is done. I don't think that using a software NAND controller instead of the LBC FCM mode is all that bad. Again, I haven't actually done it, so check the MTD docs, but I'm pretty sure the software is meant to do that, so it doesn't even really constitute a "fix". Assuming that it is supported then I doubt that configuring the NAND layer to use your setup would be any harder than configuring the FCM. And, U-Boot uses the Linux MTD code, so you'd get the same support there. There might also be a way to keep the BUSY and find a workaround with the other chips on the bus, depending on what they are. Chances are that they have a BUSY, but maybe you could move the peripheral's BUSY to another LBC line and use UPM mode to interpret that line as a BUSY. Writing UPM programs isn't really all that difficult (well, not the second time you do it anyway). That's getting into kludge territory, though. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev