[OpenBIOS] OFMEM and physical addresses
andreas.faerber at web.de
Sat Nov 6 12:36:26 CET 2010
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
> 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. ;)
More information about the OpenBIOS