On Wed, Apr 30, 2025 at 09:27:30PM +0530, Anshul Dalal wrote: > On Wed Apr 30, 2025 at 7:46 PM IST, Tom Rini wrote: > > On Wed, Apr 30, 2025 at 07:27:50PM +0530, Anshul Dalal wrote: > > > >> As discussed here[1], the go command causes undefined behavior when used > >> for running custom OSes since the icache might hold outdated data. OSes > >> usually also expect the MMU to be disabled upon execution. > >> > >> Therefore this patch adds a call to cleanup_before_linux before we jump > >> to the loaded program/os which disables both the caches and the MMU. > >> This makes the go command's behavior consistent with riscv platforms. > >> > >> NOTE: This might cause regressions with users expecting a configured MMU > >> but I'm unsure if it's a supported use case for the go command anyway. > >> > >> [1]: https://lore.kernel.org/u-boot/d9dxl95mtq8i.3euy0c6m2l...@ti.com/ > >> > >> Signed-off-by: Anshul Dalal <ansh...@ti.com> > > > > This is the inverse of what needs to be done, sorry. RISC-V shouldn't be > > doing this type of cleanup. I know it sounds reductive but "go means > > go". We have all of the other bootX commands for "prepare the system and > > boot the thing at $address". > > Well, "go means go" implies we jump to the necessary DDR address and > start executing. But with caches enabled, it fails in cases where we > have that specific address in the icache already. In that case the > execution starts from whatever's stored in the icache and not really > DDR.
Yes, and if you're using go you're supposed to disable the cache and force a flush. Or you're doing something Interesting and nothing else should be getting in the way. -- Tom
signature.asc
Description: PGP signature
