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 <ma...@denx.de <mailto:ma...@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.goldschm...@gmail.com
<mailto:simon.k.r.goldschm...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
