On 01.10.2010, at 00:28, Benjamin Herrenschmidt wrote:
On Fri, 2010-10-01 at 00:25 +0200, Alexander Graf wrote:
> On 01.10.2010, at 00:09, Benjamin Herrenschmidt wrote:
>> On Fri, 2010-10-01 at 00:03 +0200, Alexander Graf wrote:
>>> If I understand the U3 and U4 designs correctly, PCI is always bound
>>> to be within the first 32 bits. Copying Ben for verification. I don't
>>> really remember having seen 64 bit cells on any Power system either,
>>> but I could be wrong. Again, let's ask the expert here :).
>> Yes. However, on js2x, the firmware plays funny remapping tricks...
>> In general, however, OpenBIOS should be fixed. It's getting more common
>> to have even 32-bit machines with physical devices above 32-bit (even
>> ARM is now growing an equivalent of PAE for that, and almost all 4xx
>> powerpc do that).
> So how does the firmware tell the OS that a device is on a 64 bit physical
> address if it only knows about 32 bit wide cells?
#address-cells & #size-cells indicate the number of cells for an address
or a size :-)
Ah - that makes sense. So I guess cell size really does stay 32 bit on POWER. Very good
>>>> What's the plan for fixing this? Will we need an openbios-ppc64
>>> after all, or is there a way to fix these issues in openbios-ppc using
>>> uint64_t and some assembler magic? The 970 init
>>> (arch/ppc/qemu/init.c:ppc64_patch_handlers) apparently does something
>>> clever for the interrupt handlers and seems able to use 64-bit ld/std
>>> instructions in start.S. That still wouldn't help with ucell based
>>> structs and C functions of course...
>>> Those are pure fixups to get back to 32 bit mode from the interrupt
>>> handlers, as they go into 64 bit mode by default.
>> OpenBIOS should be generally fixed regardless of being 32 or 64-bit for
>> being capable of handling 64-bit physical addresses. As to accessing
>> those from 32-bit mode, for that I suppose it either
>> - runs in virtual mode exclusively on such machines so it can create
>> special mappings in the MMU (4xx)
>> - use a little asm stub that switch mode & back on real 64-bit machines
>> to access locations in the 64-bit address space
>> I'm no fan of the later due to the "issues" with doing I/Os in real
>> on many powerpc chips but that's how IBM own firmware works so ..
> Actually we should be able to do the former even for 64-bit Book3S systems.
> After all, we run in virtual mode always and own the HTAB. And that contains 64 bit
Apple OF runs in virtual mode. IBM in real. Dunno if AIX can cope with
Phew. What does SLOF run in? Btw - that'd be the alternative: emulate a U4 board and
have SLOF run inside.