[U-Boot] [PATCH 6/8] arm, davinci, am1808: add lowlevel functions for booting from NOR

From: Christian Riesch <christian.riesch@omicron.at>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 6/8] arm, davinci, am1808: add lowlevel functions for booting from NOR
Date: Tue, 27 Sep 2011 08:57:56 +0200	[thread overview]
Message-ID: <CABkLObrh-c1EEYQ-hWxEV-i58J1oy_fv5VcZ51zPDscq91BZDw@mail.gmail.com> (raw)
In-Reply-To: <4E8037C8.5020905@denx.de>

Hello Heiko,
Thank you for your reply. I have just noticed that the patches have
already been pulled into arm/next so I guess I am quite late with my
comments. I'd like to apologize for this; apparently I need another
email filter that also filters for messages containing "am1808" and
not only "da850" ;-)

Which brings me to my next point: AFAIK Texas Instruments's AM18xx
SoCs, their OMAP-L138, and their DA850 based devices basically differ
only in the DSP/PRU part of the device. If you are (like in u-boot)
only interested in the ARM part of chip, they are basically the same
device. For some reason the Linux kernel and u-boot support for all
these devices is labelled da850... Although I have no hardware to test
it, I guess that your DDR memory controller initialization code could
be used for the OMAP-L138 and the corresponding Davinci device as
well. So since all code in u-boot for the entire device family is
labelled da850... I guess your DDR initialization functions should get
this prefix as well for consistency. Any comments from the
maintainers/TI employees who know these devices better than I do?

On Mon, Sep 26, 2011 at 10:28 AM, Heiko Schocher <hs@denx.de> wrote:
> Hello Christian,
>
> Christian Riesch wrote:
>> Heiko,
>> I am looking forward to see these patches in mainline u-boot. My
>> custom board also directly boots from NOR, so I think there is a lot I
>> can re-use for my board.
>
> Thats the goal ;-)
>
>> I have one question, please see below:
> [...]
>>> +void am1808_lpc_transition(unsigned char pscnum, unsigned char module,
>>> + ? ? ? ? ? ? ? unsigned char domain, unsigned char state)
>>> +{
> [...]
>>> + ? ? ? /* Wait for transition to complete */
>>> + ? ? ? while (readl(&reg->ptstat) & (0x00000001 << domain))
>>> + ? ? ? ? ? ? ? ;
>>> +
>>> + ? ? ? /* Wait and verify the state */
>>> + ? ? ? while ((readl(mdstat) & 0x1F) != state)
>>> + ? ? ? ? ? ? ? ;
>>> +}
>>
>> There is some similar code in arch/arm/cpu/arm926ejs/davinci/psc.c. Is
>> there any reason why you don't use this code or adapt it for your
>> needs?
>
> No, there is no reason, just missed it! I try the functions in
> arch/arm/cpu/arm926ejs/davinci/psc.c and if they work, I remove the
> am1808_lpc_transition function.

Ok. Actually you do LPSC transitions twice in your board
configuration, first in the low level initialization in
arch/arm/cpu/arm926ejs/davinci/am1808_lowlevel.c (using your own
function) and then again in your board initialization in
board/enbw/enbw_cmc/enbw_cmc.c (using the code in
arch/arm/cpu/arm926ejs/davinci/psc.c). I assume you ran into the same
problem as I did with the da850evm board. The UART is used before it
is turned on in the board_init() function. A few weeks ago I submitted
a patch [1][2] for this issue but did not get any comments on it.
Would you mind having a look at it so we could find a common solution
for both your configuration and the da850evm?

Regards, Christian

[1] http://lists.denx.de/pipermail/u-boot/2011-September/100352.html
[2] http://patchwork.ozlabs.org/patch/113335/