[U-Boot] [PATCH] arm: socfpga: control reboot from SRAM via env callback
Simon Goldschmidt
simon.k.r.goldschmidt at gmail.com
Sat May 4 19:10:11 UTC 2019
Am 04.05.2019 um 20:43 schrieb Marek Vasut:
> On 5/3/19 10:53 PM, Simon Goldschmidt wrote:
>>
>>
>> Marek Vasut <marex at denx.de <mailto: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
>> <mailto: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).
>
> Should that be runtime configurable then ?
Since it might depend on Linux putting the qspi chip into a state where
it's not accessible by the boot ROM. That might change without
rebuilding U-Boot.
On the other hand, this is probably more of a U-Boot build time config.
I could make it a Kconfig option as well...
Regards,
Simon
More information about the U-Boot
mailing list