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