On Thu, Aug 22, 2024 at 02:28:03AM -0700, Breno Leitao wrote: > On Mon, Jun 24, 2024 at 12:36:14PM +0100, Will Deacon wrote: > > On Tue, Jun 18, 2024 at 12:36:03PM +0100, Mark Rutland wrote: > > > On Tue, Jun 18, 2024 at 01:49:22AM -0700, Breno Leitao wrote: > > > > > Since __pa() is a macro to __virt_to_phys(): > > > > > > > > #define __pa(x) __virt_to_phys((unsigned long)(x)) > > > > > > > > I am curious why this address is special that makes __virt_to_phys() > > > > unhappy. > > > > > > It's a fixmap address rather than a linear-map address. Confusingly > > > 'virt' generally means the linear map rather than any virtual address, > > > and usually virt_to_*() only work on linear map addresses. > > > > > > I'm not sure how to fix this; the major reason we fixmap the FDT is so > > > that it can be anywhere in memory (and e.g. may not be in the linear map > > > at all), so we can't always generate a linear map VA. > > > > > > We could stash the PA at boot time, and pass this as an argument to > > > of_kexec_alloc_and_setup_fdt(). > > > > Yeah, if it was passed as an additional argument to early_init_dt_scan(), > > then the core could could track it. Alternatively, we'd need a helper > > macro to get the PA and have an arm64-variant for the fixmap (everybody > > else could use __pa()). > > > > > Rob, any thoughts? I couldn't see a neat way of doing this, but maybe we > > > could initialise an initial_boot_params_phys at setup time, with a bit > > > of churn to early_init_dt_verify() and friends? > > > > Rob? > > Hello, is there anything I can do or test to have this moving? I've not seen anything from Rob, so the best bet is probably to see if you can hack up a patch to fix it yourself and then cc the rest of us when you post it. Will
