On Fri, 21 Feb 2020 at 14:42, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > On Fri, 21 Feb 2020 at 14:35, Robin Murphy <robin.murphy@xxxxxxx> wrote: > > > > On 20/02/2020 6:08 pm, Ard Biesheuvel wrote: > > > (+ Arnd) > > > > > > On Wed, 19 Feb 2020 at 10:43, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > >> > > >> While making changes to the EFI stub startup code, I noticed that we are > > >> still doing set/way maintenance on the caches when booting on v7 cores. > > >> This works today on VMs by virtue of the fact that KVM traps set/way ops > > >> and cleans the whole address space by VA on behalf of the guest, and on > > >> most v7 hardware, the set/way ops are in fact sufficient when only one > > >> core is running, as there usually is no system cache. But on systems > > >> like SynQuacer, for which 32-bit firmware is available, the current cache > > >> maintenance only pushes the data out to the L3 system cache, where it > > >> is not visible to the CPU once it turns the MMU and caches off. > > >> > > >> So instead, switch to the by-VA cache maintenance that the architecture > > >> requires for v7 and later (and ARM1176, as a side effect). > > >> > > >> Changes since v1: > > >> - include the EFI patch that was sent out separately before (#1) > > >> - split the preparatory work to pass the region to clean in r0/r1 in a EFI > > >> specific one and one for the decompressor - this way, the first two patches > > >> can go on a stable branch that is shared between the ARM tree and the EFI > > >> tree > > >> - document the meaning of the values in r0/r1 upon entry to cache_clean_flush > > >> - take care to treat the region end address as exclusive > > >> - switch to clean+invalidate to align with the other implementations > > >> - drop some code that manages the stack pointer value before calling > > >> cache_clean_flush(), which is no longer necessary > > >> - take care to clean the entire region that is covered by the relocated zImage > > >> if it needs to relocate itself before decompressing > > >> > > >> https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm32-efi-cache-ops > > >> > > > > > > Adding my own data point here: with these patches, I can reproducibly > > > boot on the SynQuacer platform (24x Cortex-A53 + GICv3 + L3 system > > > cache) until the point where /init is loaded, after which it hangs > > > (see below), whereas without them, it always crashes early with weird, > > > unreproducible errors, if it even makes it far enough through the > > > decompressor to produce any earlycon output. > > > > > > There is some other weird stuff going on, but this is unlikely to be > > > related to cache maintenance: > > > - multiple occurrences of > > > OF: translation of DMA address(0) to CPU address failed node(...) > > > > FWIW that implies a "dma-ranges" property in the wrong place in the DT - > > if you copied the now-gone Juno example of placing one directly in the > > root node, that was bogus, sorry. > > > > OK, so where should it be instead? Are you saying it is now required > to have a /soc or /smb node that contains all the device nodes? > Never mind - I'll just drop "dma-ranges" from the root node entirely.
