[OpenBIOS] OFMEM and physical addresses

[Andreas Färber]

Am 07.11.2010 um 01:38 schrieb Alexander Graf:

>
> On 06.11.2010, at 08:24, Andreas Färber wrote:
>
>> Am 06.11.2010 um 13:05 schrieb Mark Cave-Ayland:
>>
>>> Andreas Färber wrote:
>>>
>>>> I was planning to do the same thing for ppc64, please go ahead.
>>>> The alternative would've been to create separate range structs -  
>>>> cleaner API-wise, but then the range logic would need to be  
>>>> duplicated, which I consider a big con. ;)
>>>
>>> Yeah, that's what I was thinking. I know that the old SPARC64 code  
>>> used to reference addresses in the translation_t struct linked  
>>> list directly in the MMU miss handlers, but that section has now  
>>> been replaced with C code. Are there any similar gotchas on PPC?
>>
>> Not that I'm aware of. Alex?
>
> The MMU miss handler code is very simple:

> [...]
>
>        phys = ea_to_phys(nip, &mode);
>        hash_page( nip, phys, mode );

Ah! I played with that earlier today and tried to implement early  
mapping based on those two lines:

diff --git a/arch/ppc/qemu/ofmem.c b/arch/ppc/qemu/ofmem.c
index a507009..594defe 100644
--- a/arch/ppc/qemu/ofmem.c
+++ b/arch/ppc/qemu/ofmem.c
@@ -128,9 +128,15 @@ void ofmem_arch_unmap_pages(ucell virt, ucell size)
         /* kill page mappings in provided range */
  }

+//static ucell ea_to_phys( ucell ea, ucell *mode );
+static void hash_page( unsigned long ea, unsigned long phys, ucell  
mode );
+
  void ofmem_arch_early_map_pages(ucell phys, ucell virt, ucell size,  
ucell mode)
  {
-       /* none yet */
+       ucell offset;
+       for (offset = 0; offset < size; offset += 0x1000) {
+               hash_page(virt + offset, phys + offset, mode);
+       }
  }

  retain_t *ofmem_arch_get_retained(void)

No regressions on ppc, but no change on ppc64.

While it doesn't matter here, we might change unsigned long phys to  
phys_addr_t phys.

Andreas

> So as long as you're in openBIOS code or no ofmem map is available,  
> it maps linearly, otherwise it uses normal ofmem handlers. I don't  
> see any list involved here :).
>
>
> Alex