[U-Boot] [PATCH] arm: at91sam9n12: change EBI IO to high drive mode

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Hi Bo,

On Fri, 19 Jul 2013 09:51:02 +0800, Bo Shen <voice.shen@atmel.com>
wrote:

> Hi Albert,
> 
> On 07/17/2013 06:42 PM, Albert ARIBAUD wrote:
> > Hi Bo,
> >
> > On Wed, 17 Jul 2013 18:27:29 +0800, Bo Shen <voice.shen@atmel.com>
> > wrote:
> >
> >> Hi Albert,
> >>
> >> On 07/17/2013 06:10 PM, Albert ARIBAUD wrote:
> >>> Hi Bo,
> >>>
> >>> On Wed, 17 Jul 2013 17:14:17 +0800, Bo Shen <voice.shen@atmel.com>
> >>> wrote:
> >>>
> >>>> As both the DDR SDRAM and NAND flash connect to EBI on at91sam9n12
> >>>> and share the lower 8 bits data line. If use low drive of the data
> >>>> line, it will cause DDR data access corrupt in lower address, so
> >>>> change the data line to high drive mode
> >>>>
> >>>> This will fix the Linux kernel boot issue when use Lower address
> >>>
> >>> Wait--does this mean that there is no separate chip selects for NAND and
> >>> DDR on this SoC?
> >>
> >> No. The NAND and DDR has there own chip selects.
> >> This is chip specific. If DDR and NAND share data line, if we use low
> >> drive for EBI IO, it will cause DDR low memory address content corrupt.
> >> For example, if the DDR base address is 0x20000000, if we use 0x20008000
> >> as entry address of Linux kernel, then it won't boot up successfully.
> >> So, if we need to use low memory address, we need this to fix.
> >
> > I understand the symptom. What I don't undestand is how come NAND
> > does not keep its data lines in high impedance when its chip select is
> > inactive, which it is when DDR is being accessed.
> 
> So, I expect this patch be applied in v2013.07 release, would it be OK?
> 
> Hi Andreas,
>    If no objection from Albert, would it be possible to apply it and 
> include it in v2013.07 release.

I understand that I did read 'high drive' as "driving toward Vcc"
instead of "driving stronger", which answers my question about symmetry
-- by making it pointless, but hey. :)

That leaves two questions: why does this happens only now, and how was
the conclusion drawn that this is the right solution? I mean, the
stronger drive fixes the issue, so it's definitely HW, but maybe the
real issue is some other device on the bus being misconfigured, and
driving stronger just hides it.

As for applying it to 2013.07... At this point, Tom (added to To list)
will decide, if he has not already.

> Best Regards,
> Bo Shen

Amicalement,
-- 
Albert.