[OpenBIOS] OFMEM and physical addresses

[Andreas Färber]

Hi Mark,

Am 06.11.2010 um 12:24 schrieb Mark Cave-Ayland:

> [...] the OFMEM code doesn't handle physical addresses properly.
>
> In terms of mapping I/O devices into address space, the first  
> problem is with the ofmem_arch_early_map_pages() API which looks  
> like this:
>
> ofmem_arch_early_map_pages(ucell phys, ucell virt, ucell size, ucell  
> mode);
>
> The problem here is that when setting up the QEMU firmware  
> configuration interface with an address of 0xd00000510, once we hit  
> the page mapping functions we lose the top 8 bits of the physical  
> address since sizeof(phys_addr_t) > size(ucell) on SPARC32. This  
> causes incorrect physical address mappings.
>
> My current thinking is that all physical addresses should be changed  
> to phys_addr_t in the OFMEM APIs, but this is slightly more  
> complicated because the same range_t structure is used for storing  
> both physical and virtual range mappings.
>
> I believe that if I change the OFMEM range_t structure to use  
> phys_addr_t instead of ucell then this should work assuming that  
> sizeof(phys_addr_t) is always >= sizeof(ucell). Looking at the OF  
> spec it seems that all virtual addresses always fit within 1 Forth  
> cell, and so virtual addresses should be fine in their present form.
>
> Can anyone see a flaw in the above logic before I go ahead and code  
> it up?

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. ;)

Regards,
Andreas