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

[Marek Vasut]

On 5/5/19 10:21 PM, Simon Goldschmidt wrote:
> Am 05.05.2019 um 22:17 schrieb Marek Vasut:
>> On 5/5/19 8:05 AM, Simon Goldschmidt wrote:
>>>
>>>
>>> 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 :-)
>>
>> What's the workaround ?
> 
> The workaround is what this patch is about: the Boot ROM just branches
> off to SRAM where it expectes SPL to be still working.

But you still cannot communicate with the SPI NOR from your SPL ?

> SPL can then e.g. reset 4-byte mode or whatever to still communicate
> with the device when Boot ROM can't.

Unless, of course, the SPI NOR doesn't interpret the command as data and
corrupts something in the flash itself.

> Of course the downside is that SRAM might be overwritten meanwhile,
> which is why it's a workaround only, not the best idea how to do things...
> 
> Regards,
> Simon


-- 
Best regards,
Marek Vasut