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@aribaud.net wrote:
Hello Simon,
On Tue, 3 Feb 2015 21:18:52 -0700, Simon Glass sjg@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.