[U-Boot] [PATCH] arm, am33xx: move s_init to a common place

[Heiko Schocher <hs@denx.de>]

Hello Tom,

Am 14.06.2013 16:58, schrieb Tom Rini:
> On Fri, Jun 14, 2013 at 07:59:26AM +0200, Heiko Schocher wrote:
>> Hello Tom,
>>
>> Am 13.06.2013 17:53, schrieb Tom Rini:
>>> On Thu, Jun 13, 2013 at 05:53:17AM +0200, Heiko Schocher wrote:
>>>
>>>> move s_init from every board code to a common place.
>>>>
>>>> Signed-off-by: Heiko Schocher <hs@denx.de>
>>>> Cc: Tom Rini <trini@ti.com>
>>>> Cc: Matt Porter <mporter@ti.com>
>>>> Cc: Lars Poeschel <poeschel@lemonage.de>
>>>> Cc: Tom Rini <trini@ti.com>
>>>> Cc: Enric Balletbo i Serra <eballetbo@iseebcn.com>
>>>>
>>>> ---
>>>> This patch is based on the following patches:
>>>>
>>>> - [U-Boot,v2] arm, am33xx: move rtc32k_enable() to common place
>>>>   http://patchwork.ozlabs.org/patch/248908/
>>>>
>>>> - [U-Boot] arm, am33xx: move uart soft reset code to common place
>>>>   http://patchwork.ozlabs.org/patch/248508/
>>>
>>> These two apply best to u-boot-ti, and with them this patch doesn't
>>> apply cleanly.  Please sort that out.
>>
>> I based my patches on u-boot ... I look at this ..
>>
>>> The following adds moving ti814x_evm into the mix and I've sent Matt
>>> some binaries to give a whirl to test on the board:
>>>
>> [...]
>>>  /*
>>>   * Basic board specific setup.  Pinmux has been handled already.
>>>
>>> Please fold into v2
>>>
>>> Signed-off-by: Tom Rini <trini@ti.com>
>>
>> Ok, thanks!
> 
> There's a minor bug in what I posted, however.  ti814x needs timer_init
> called _before_ pll_init() as setting the sata clocks (which are shared
> with other periphrals that we do enable right now) needs udelay(50) to
> settle as we go along.  That also needs to be commented in the code as I
> had to think about it for a bit to recall exactly what was going on.

Do you have an update here for me?

>> BTW:
>> I just realized that I have on one of the three boards a problem,
>> that in spl code calling the rtc32k_enable() crashes ... which
>> votes against moving this to a common place ... I haveno real idea
>> why ... did you heard from such a behaviour? Is there some am335x
>> soc, which differs from the others?
> 
> You aren't using a different clock crystal rate than the reference
> platforms, are you?  I know that's a problem that needs solving still.

I am prospecting, whats going on here ... but have no real idea,
why it is not possible to write this registers ... if writing this
registers, cpu hang ...

But I want to have a common function here ... maybe it is OK to make
the rtc32k_enable() call configurable through a define?

Saying "CONFIG_SPL_AM33XX_DO_NOT_ENABLE_RTC32K"

and document in the u-boot README this define, and why it is
necessary?

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany