Andre Schwarz <andre.schw...@matrix-vision.de> wrote on 2010/12/10 09:47:10: > > Scott, > > do you think this issue also applies to MPC8377 ?
Probably, I think this is so for all eLBC controllers. > > I'm in the middle of a small redesign for series production and would > like not to miss a thing. > We have Nand, Nor and MRAM connected to LBC. > > Since RFS is running from NAND and we use the MRAM as a non-volatile > SRAM I'd like to avoid being hit by this issue. Please report back, I really want to know if this works and if there are any drawbacks. > > Any comments from your side ? > > Regards, > André > > > On Wed, 8 Dec 2010 22:26:59 +0100 > > Joakim Tjernlund<joakim.tjernl...@transmode.se> wrote: > > > >> Scott Wood<scottw...@freescale.com> wrote on 2010/12/08 21:25:51: > >>> On Wed, 8 Dec 2010 21:11:08 +0100 > >>> Joakim Tjernlund<joakim.tjernl...@transmode.se> wrote: > >>> > >>>> Scott Wood<scottw...@freescale.com> wrote on 2010/12/08 20:59:28: > >>>>> On Wed, 8 Dec 2010 20:57:03 +0100 > >>>>> Joakim Tjernlund<joakim.tjernl...@transmode.se> wrote: > >>>>> > >>>>>> Can you think of any workaround such as not connecting the BUSY pin at > >>>>>> all? > >>>>> Maybe connect the busy pin to a gpio? > >>>> Is BUSY required for sane operation or it an optimization? > >>> You could probably get away without it by inserting delays if you know > >>> the chip specs well enough. > >> Urgh, that does not feel like a good solution. > > No, but you asked if it could be done, and if it was just a > > performance issue. :-) > > > >>>> 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? > > Not much, if you enable interrupts on the GPIO pin. The driver would > > have to be reworked a bit, of course. > > > >> You think Freescale could test and validate a GPIO solution? I don't > >> think we will be very happy to design our board around an unproven > >> workaround. > > Ask your sales/support contacts. > > > >> 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. > > The problem with that is when would you assert the chipselect again to > > check if it's done? Current SW depends on being able to tell the LBC > > to interrupt (or take other action) when busy goes away. > > > > I suppose you could poll with status reads, which could at least be > > preempted if you've got something higher priority to do with the LBC. > > > > -Scott > > > > _______________________________________________ > > Linuxppc-dev mailing list > > Linuxppc-dev@lists.ozlabs.org > > https://lists.ozlabs.org/listinfo/linuxppc-dev > > > MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler > Registergericht: Amtsgericht Stuttgart, HRB 271090 > Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
