[U-Boot] [PATCH] arm: socfpga: control reboot from SRAM via env callback
Simon Goldschmidt
simon.k.r.goldschmidt at gmail.com
Sun May 5 06:05:00 UTC 2019
On 05.05.19 03:42, Marek Vasut wrote:
> On 5/4/19 9:10 PM, Simon Goldschmidt wrote:
>> 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.
>
> If Linux switches the chip into some weird mode the bootrom cannot cope
> with, it's a reset routing problem. This cannot be fixed in software.
No, it cannot be fixed, but currently there's a workaround for those
boards and I thought it was worth to keep this workaround, even though
my own boards will be fixed and not require such a workaround in the
future :-)
>
>> 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