Andreas Färber wrote:
From what you're saying it sounds like the proper fix would be to rename the PPC functions ea_to_phys() (and also it's reverse mapping function) to match the SPARC definitions so they can be called from OFMEM. Does that sound reasonable?
No. The virtual address on ppc64 is something like 80 bits, whereas the effective address (64 bits) really is what we want, similar differences for 32-bit, so it shouldn't be renamed. It may need to be wrapped.
I don't think it belongs in io.h either. I wouldn't know where virt_offset is initialized, so I assume that during runtime (as opposed to forthstrap) it will be zero and all you're doing there is identity-mapping things, which buys us nothing.
For SPARC, the equivalent is va_shift which is calculated at the very beginning of arch/<foo>/entry.S (i.e. just after the MMU is enabled).
Hmmm so it looks like virt_offset isn't set for PPC at all! This is definitely where my lack of understanding the PPC code shows up.
We do have ofmem_arch_translate() or similar for the virtual-to-physical direction. Maybe we need another ofmem_* one for the opposite direction? sparc implementations could then call their *va* macros from there if it suits them. The way we map OpenBIOS into RAM in ea2phys() should guarantee physical alignment of aligned effective addresses, so that there's no need to consider it in other functions (this is an ugly hack, in theory OpenBIOS would need to be fully relocatable and just copied there).
As long as we have two functions that convert from phys to virt and virt to phys for each arch (preferably called pa2va and va2pa) then I'm happy. Note that this is not for the alignment of OpenBIOS itself, but for allow callers of ofmem_malloc() to request arbitrary alignment on requested regions. This is mainly because the various IOMMU/MMU page tables require this restriction on physical addresses at the same time for obvious reasons.
ATB,
Mark.