From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lokesh Vutla Date: Mon, 24 Jun 2013 09:31:42 +0530 Subject: [U-Boot] [PATCH] arm, am33xx: move s_init to a common place In-Reply-To: <51C27C86.3010000@denx.de> References: <1371095597-8425-1-git-send-email-hs@denx.de> <20130613155337.GC5616@bill-the-cat> <51BAB13E.4060308@denx.de> <20130614145825.GH5616@bill-the-cat> <51C27C86.3010000@denx.de> Message-ID: <51C7C4A6.30200@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Heiko, On Thursday 20 June 2013 09:22 AM, Heiko Schocher wrote: > 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 >>>>> Cc: Tom Rini >>>>> Cc: Matt Porter >>>>> Cc: Lars Poeschel >>>>> Cc: Tom Rini >>>>> Cc: Enric Balletbo i Serra >>>>> >>>>> --- >>>>> 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 >>> >>> 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? We can have a timer_init for am33xx boards also. It doesn't harm. So keep timer_init in your common s_init > >>> 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? On which board it is giving a problem? Did you make sure clocks for rtc are enabled? I am making a cleanup series for am33xx boards. If you don't mind can I take this patch as part of my series. Thanks and regards, Lokesh >> >> 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 >