From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Goldschmidt Date: Sun, 5 May 2019 08:05:00 +0200 Subject: [U-Boot] [PATCH] arm: socfpga: control reboot from SRAM via env callback In-Reply-To: <4963995d-3534-9af5-41fe-16cecfa4b3c0@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> Message-ID: <9375a112-79c0-4365-cd82-72c43affced7@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 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 :-) > >> 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 > >