From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Goldschmidt Date: Sun, 5 May 2019 22:21:39 +0200 Subject: [U-Boot] [PATCH] arm: socfpga: control reboot from SRAM via env callback In-Reply-To: <4c6f3d55-b5bb-eca7-efd9-b653221ab239@denx.de> References: <20190503200838.14403-1-simon.k.r.goldschmidt@gmail.com> <11fd6d31-6fd9-a033-9540-50c1113c292f@gmail.com> <5138f274-9705-2337-1df5-eb59ff697361@denx.de> <38c5009d-4303-a92e-ac76-5c0b482b6238@denx.de> <5c1416f4-a174-5a97-da53-943251d387b9@denx.de> <5b88fe86-dea0-5ded-01b0-f8f52ee874a4@gmail.com> <4963995d-3534-9af5-41fe-16cecfa4b3c0@denx.de> <9375a112-79c0-4365-cd82-72c43affced7@gmail.com> <4c6f3d55-b5bb-eca7-efd9-b653221ab239@denx.de> Message-ID: <85e84f94-7363-6cca-9cf8-87ee7cdb5fab@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de 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 > 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 >>>>>>       >>>>>       > >>>>>>       >>>> >>>>>>       >>>> 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. SPL can then e.g. reset 4-byte mode or whatever to still communicate with the device when Boot ROM can't. 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