[OpenBIOS] OFMEM and physical addresses
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
More information about the OpenBIOS