[U-Boot] [PATCH] arm: socfpga: control reboot from SRAM via env callback

Simon Goldschmidt simon.k.r.goldschmidt at gmail.com
Fri May 3 20:53:55 UTC 2019


Marek Vasut <marex at denx.de> schrieb am Fr., 3. Mai 2019, 22:42:

> On 5/3/19 10:39 PM, Simon Goldschmidt wrote:
> >
> >
> > On 03.05.19 22:35, Marek Vasut wrote:
> >> On 5/3/19 10:30 PM, Simon Goldschmidt wrote:
> >>>
> >>>
> >>> On 03.05.19 22:28, Marek Vasut wrote:
> >>>> On 5/3/19 10:08 PM, Simon Goldschmidt wrote:
> >>>>> This moves the code that enables the Boot ROM to just jump to SRAM
> >>>>> instead
> >>>>> of loading SPL from the original boot source on warm reboot.
> >>>>>
> >>>>> Instead of always enabling this, an environment callback for the
> >>>>> env var
> >>>>> "socfpga_reboot_from_sram" is used. This way, the behaviour can be
> >>>>> enabled
> >>>>> at runtime and via saved environment.
> >>>>>
> >>>>> Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt at gmail.com>
> >>>>
> >>>> Would that be like a default "reset" command action ?
> >>>> This probably shouldn't be socfpga specific then.
> >>>
> >>> No, it's a thing that lives on and influences even the soft reset
> issued
> >>> by linux "reboot" command. This is something *very* socfpga specific.
> >>
> >> Hmmm, so isn't this a policy to be configured on the Linux end ?
> >
> > Might be, but it affects U-Boot's 'reset' command as well. And I guess
> > it's set up in U-Boot this early to ensure it always works.
>
> Drat, that's right. So there has to be some way to agree on how the
> reset works between the kernel and U-Boot ?
>
> > If it were for me, we could drop writing this magic altogether. I just
> > figured some boards might require it to be written somewhere, and came
> > up with a patch that might save those boards with the way it was before.
>
> Isn't this magic actually used by bootrom ?
>

Right. It tells the boot rom to jump to ocram on next reboot instead of
loading spl from qspi or mmc. But if that's required or not a good idea at
all depends on many factors. Some of them board related, some U-Boot
related and some Linux related (depending on the hardware and drivers used).

Regards,
Simon

>


More information about the U-Boot mailing list