[U-Boot] [PATCH 3/5] arm: Allow lr to be saved by board code

[Tom Rini]

On Wed, Feb 04, 2015 at 07:51:36PM -0700, Simon Glass wrote:
> Hi Albert,
> 
> On 4 February 2015 at 01:59, Albert ARIBAUD <albert.u.boot at aribaud.net> wrote:
> > Hello Simon,
> >
> > On Tue,  3 Feb 2015 21:18:52 -0700, Simon Glass <sjg at chromium.org>
> > wrote:
> >> The link register value can be required on some boards (e.g. FEL mode on
> >> sunxi) so stash it to r4 before jumping to save_boot_params().
> >
> > I'd rather not make this there; I would like save_boot_params to start
> > with as unmodified a core state as possible, because r4 might
> > actually, now or in the future, contain important data.
> >
> > I'd even go as far as saying that save_boot_params should be branched
> > into rather than called, and should branch back to a fixed label right
> > after reset, so that even lr is preserved. For SoCs which do not need
> > to save any boot parameters, a weak version of save_boot_params would
> > just do the branching back.
> >
> > (this should help merging all start.S instances into a singe one,
> > which I still want to achieve one day)
> 
> I did consider this but was worried that some save_boot_params()
> functions are written in C (OMAP) so this would not work. But if we

Keep in mind that save_boot_params() isn't the same as
save_omap_boot_params().  On OMAP (well, OMAP/AM/etc) save_boot_params
is arch/arm/cpu/armv7/omap-common/lowlevel_init.S::save_boot_params
which copies a value from r1 to a magic SRAM location that
save_omap_boot_params() deals with.  So I agree with Albert, we can't
know what registers have important data in them and must not touch.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150205/783785a1/attachment.sig>