[OpenBIOS] OFMEM and physical addresses

Andreas Färber andreas.faerber at web.de
Sat Nov 6 13:24:12 CET 2010


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?

We may need to tidy arch/ppc/qemu/ofmem.c though wrt ucell. I noticed  
there's a private get_ram/rom/sth_size() function defined in the  
header but it's only used further down in the same file, so I'll  
probably change the type to phys_addr_t and make it static.

> I'm also thinking it would be nice to have a couple of functions for  
> each arch such as POP_PHYS() and PUSH_PHYS() which will PUSH/POP  
> stack items into phys_addr_t and vice-versa. I think this will also  
> allow a nice tidy up of the areas where these conversions take  
> place, e.g. the MMU handlers.

Sounds fine to me, and making them inline functions rather than macros  
will probably make Blue happy, too. :)

> Looks like I'm busy for the rest of the day, so will try and have a  
> stab at this tomorrow.

Great. I've been postponing this to not open another can of worms on  
ppc64.

Andreas


More information about the OpenBIOS mailing list