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. > 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 -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
