[U-Boot] [PATCH] arm, am33xx: move s_init to a common place
Heiko Schocher
hs at denx.de
Thu Jun 20 05:52:38 CEST 2013
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 at denx.de>
>>>> Cc: Tom Rini <trini at ti.com>
>>>> Cc: Matt Porter <mporter at ti.com>
>>>> Cc: Lars Poeschel <poeschel at lemonage.de>
>>>> Cc: Tom Rini <trini at ti.com>
>>>> Cc: Enric Balletbo i Serra <eballetbo at 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 at 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
More information about the U-Boot
mailing list