From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] OMAP (4) boot_params
Date: Wed, 3 Apr 2013 07:56:54 +0200 [thread overview]
Message-ID: <20130403075654.78a92037@lilith> (raw)
In-Reply-To: <3D94DE59-B6E1-4C42-AF70-317CB7E468EC@prograde.net>
Hi Michael,
(please wrap your line around 70 chars max)
I won't comment on the 'u-boot' part of your message as it is quite
SPL-vs-U-Boot- and OMAP-specific, and I prefer to leave this to people
better suited for this. However, on the low level init front:
On Tue, 2 Apr 2013 18:39:17 -0400, Michael Cashwell
<mboards@prograde.net> wrote:
> Greetings,
>
> I've been fighting with SPL passing not boot_params properly to u-boot
> on OMAP4. There are many layers to this onion but I've tracked the bulk
> of the problem down to the following issues.
>
> --- SPL ---
>
> arch/arm/cpu/armv7/omap-common/hwinit-common.c sets a pointer to the
> SPL's &boot_params correctly (cpu_init_crit->lowlevel_init->s_init) but
> the definition of that pointer in common/spl/spl.c:
>
> u32 *boot_params_ptr = NULL;
>
> puts it into the spl bss section (in SDRAM) which is cleared long after
> cpu_init_crit(). Making that:
>
> u32 *boot_params_ptr __attribute__ ((section(".data")));
>
> allows the pointer to be in SPL data section (SRAM) and still have its
> value by the time image_entry() is called. But common/spl/spl.c is not
> omap-specific so changes there are a concern.
If I'm not mistaken, lowlevel_init() is not supposed to use BSS at all,
as the C runtime has not been initialized yet -- precisely, the BSS
clearing loop long after the cpu_init_crit() call belongs to the code
that sets up this environment.
Besides, it seems like SPL does not jump directly to Linux but to
U-Boot, so U-Boot itself should set up the boot params, not SPL, which
can at best prepare and store values in static RAM not mapped as data
or BSS in either SPL or U-Boot (this is normally done through GD).
> Next, image_entry() is called with the argument being indirected an
> extra time:
> u32 boot_params_ptr_addr = (u32)&boot_params_ptr;
> image_entry((u32 *)boot_params_ptr_addr);
>
> That extra level of indirection is never dealt with (on ARM anyway) and
> it ends up passing junk to u-boot. I've tested replacing those lines
> with:
> image_entry((u32 *)boot_params_ptr);
>
> and that passes a correct address in r0 to lowlevel_init.S in u-boot.
This has to be investigated indeed.
Amicalement,
--
Albert.
next prev parent reply other threads:[~2013-04-03 5:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-02 22:39 [U-Boot] OMAP (4) boot_params Michael Cashwell
2013-04-03 5:56 ` Albert ARIBAUD [this message]
2013-04-03 13:45 ` Michael Cashwell
2013-04-03 14:36 ` Albert ARIBAUD
2013-04-03 14:59 ` Michael Cashwell
2013-04-03 15:34 ` Albert ARIBAUD
2013-04-03 16:42 ` Tom Rini
2013-04-04 5:52 ` Wolfgang Denk
2013-04-04 14:18 ` Michael Cashwell
2013-04-08 9:43 ` Sricharan R
2013-04-08 12:42 ` Michael Cashwell
2013-04-04 19:54 ` Tom Rini
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=20130403075654.78a92037@lilith \
--to=albert.u.boot@aribaud.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox