From: Sricharan R <r.sricharan@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] arm, arm335x: save_omap_boot_params question
Date: Thu, 13 Jun 2013 11:05:04 +0530 [thread overview]
Message-ID: <51B95A08.6050400@ti.com> (raw)
In-Reply-To: <51B95656.9070500@denx.de>
On Thursday 13 June 2013 10:49 AM, Heiko Schocher wrote:
> Hello Sricharan,
>
> Am 13.06.2013 07:08, schrieb Sricharan R:
>> On Wednesday 12 June 2013 06:19 PM, Tom Rini wrote:
>>> On Wed, Jun 12, 2013 at 02:39:13PM +0200, Heiko Schocher wrote:
>>>> Hello Tom,
>>>>
>>>> Am 12.06.2013 14:28, schrieb Tom Rini:
>>>>> On Wed, Jun 12, 2013 at 10:56:01AM +0200, Heiko Schocher wrote:
>>>>>> Hello tom,
>>>>>>
>>>>>> your
>>>>>>
>>>>>> commit 4596dcc1d4ea5763e0f92cf5becd9fc7d4c6e674
>>>>>> Author: Tom Rini <trini@ti.com>
>>>>>> Date: Fri May 31 12:31:59 2013 -0400
>>>>>>
>>>>>> am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c
>>>>>>
>>>>>> introduced, that all am335x based boards must call
>>>>>> save_omap_boot_params() from the board specific s_init function. I
>>>>>> just stumbled over it, as I updated to current head and my upcoming
>>>>>> am335x based siemens boards didn't boot anymore ... should we think
>>>>>> about to move this s_init() to a common place, and extract board
>>>>>> specific things? Maybe arch/arm/cpu/armv7/omap-common/boot-common.c
>>>>>> is a place for it?
>>>>> I think the first non-am335x_evm board pulled the code we need in board/
>>>>> a bit too far in the board-specific direction.
>>>>>
>>>>> Whacking the WDT (which could be done differently I imagine based on
>>>>> your other patches), calling save_omap_boot_params and UART stuff is
>>>>> common. Figuring out which DDR and how is not. I think we can learn
>>>>> from omap-common/hwinit-common.c::s_init but need to have our own in
>>>>> arch/arm/cpu/armv7/am33xx/board.c and declared __weak or wrapped with
>>>>> CONFIG_AM33XX since TI814x (and TI816x) are different. Or maybe some
>>>>> more thinking share still.
>>>>>
>>>>> Do you have time for this? Thanks!
>>>> I try to find some ;-)
>>>>
>>>> Maybe something like this:
>>>>
>>>> add in arch/arm/cpu/armv7/am33xx/board.c a weak s_init(), which all
>>>> am35xx boards use, and call in this s_init() a s_init_board() which
>>>> all am335x boards must have defined?
>>> s/s_init_board/sdram_init/ and yes. If we whack the UART stuff out into
>>> uart_enable (ala ti814x) and add a board_enable_early_pinmux (for the
>>> muxes needed, and put this right after save_omap_...) we might not need
>>> to make s_init __weak.
>> Just curious here, why the save_omap_boot_params is breaking things
>> in first place for your SOC. Was it not used before ??
>>
>> Also regarding DDR, is it emif and DDR3 in all those boards ?
> I am currently porting 3 am335x boards to mainline and worked with
> a few weeks old tree, where the save_omap_boot_params() patch was not
> in mainline.
>
> I am more or less finished the porting and just did a rebase to current
> head ... and due to missing save_omap_boot_params() in my board file,
> spl not found u-boot img in nand ...
>
> In the meantime I posted a patch, which moves save_omap_boot_params()
> to a common place, see here:
>
> [U-Boot] arm, am33xx: move s_init to a common place
> http://patchwork.ozlabs.org/patch/250973/
>
> bye,
> Heiko
oh ok, understood.. Thanks..
Regards,
Sricharan
prev parent reply other threads:[~2013-06-13 5:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-12 8:56 [U-Boot] arm, arm335x: save_omap_boot_params question Heiko Schocher
2013-06-12 12:28 ` Tom Rini
2013-06-12 12:39 ` Heiko Schocher
2013-06-12 12:49 ` Tom Rini
2013-06-13 5:08 ` Sricharan R
2013-06-13 5:19 ` Heiko Schocher
2013-06-13 5:35 ` Sricharan R [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51B95A08.6050400@ti.com \
--to=r.sricharan@ti.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.