> Hi Hannes, Hi Roger, > > On 27/08/15 08:52, Hannes Schmelzer wrote: > > Hi Tony, > > > > Did anyone test this changeset on some AM335x board? > > > > Today I ran into trouble with that because: > > > > The GPMC controller gets reseted on kernel boot due to the missing/removed > HWMOD_INIT_NO_RESET flag. > > > > Primary this should not be a big problem, but on my board (maybe on all > AM335x) the GPMC doesn't behave as described in TRM. > > Especially the GPMC_CONFIG register is not reset to 0h after reset, instead > it holds the value 0xa00 which is very strange because bit 10-31 are reserved. > > > > Further this 0xa00 means that Bit9 (WAIT1PINPOLARITY) is set, exactly this > causes my system to stall on first access the connected NAND flash because it > never becomes ready due to the wrong wait pin polarity. Maybe others dont't > run into trouble because they may use WAIT0PIN, which one has it's old polarity. > > So nand ready/busy pin is connected to waitpin1 through an inverter on your board? > > On am335x-evm we use waitpin0. Nand ready/busy is directly connected to waitpin0. No there is no inverter between flash and AM335x, the READY_nBUSY line is directly connected to waitpin1. But your sentence brings some good idea to me, i will try to solder some inverter into the READY_nBUSY line on my board and see if the problem appears again. If i'm right in my theory that the value 0xa00 in GPMC_CONFIG register is the problem, the inverter would solve it. You're right am335x-evm uses waitpin0, which one is not affected from this "bug". I have to use waitpin1, because i also have a 2nd ethernet interface connected, and there is waitpin0 uses for collission detect signal from the phy (other pinmux). > For NAND operation read/write wait monitoring must be disabled. > The nand driver uses the WAIT pin purely for Read/Busy signalling. > Unfortunately the existing driver cannot handle anything other than waitpin 0 > for nand for DT boot. for sure ? have a look to omap-gpmc.c at line #90. Here i can see that either can be used. > > I've tried to address this issue here > http://thread.gmane.org/gmane.linux.drivers.devicetree/131076 This is useful if the READY_nBUSY line cannot be connected to the GPMC itself, instead it maybe connected to some other gpio. But it doesn't solve the problem. > > cheers, > -roger best regards, Hannes -- 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
