Antwort: Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

Hannes Schmelzer Hannes.Schmelzer at br-automation.com
Tue Sep 1 06:31:42 PDT 2015


> 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






More information about the linux-arm-kernel mailing list