Re: range of resource of PCI memory for PowerPC

[Michael <macallan%netbsd.org@localhost>]

Hello,

On Dec 15, 2008, at 11:12 AM, KIYOHARA Takashi wrote:

> From: Michael <macallan%netbsd.org@localhost>
> Date: Sun, 14 Dec 2008 14:40:28 -0500
>
>> On Dec 14, 2008, at 1:33 PM, KIYOHARA Takashi wrote:
>>
>>> I know, bebox and prep (and ibmnws?) has resource problem of PCI
>>> memory.
>>> We extent memory region at start 0x00000000.  However
>>> xf86PciBusAccWindowsFromOS() add to resource-list at 0x80000000.
>>
>> That's the Xserver trying to play operating system and configure PCI
>> devices. This list is largely bogus anyway - just set your entries to
>> something big enough to cover any PCI memory or IO address legal on
>> your hardware.
>> The start at 0x80000000 is more or less macppc-specific - all host
>> bridges Apple ever used in PowerPC boxes have a rimilar address space
>> layout - the lower 2GB for RAM and the upper 2GB for PCI space,
>> firmware and various hardware registers. They even did that on the G5
>> ( with more RAM above 4GB ). Many IBM and Motorola hostbridges use a
>> very similar layout ( in fact Apple used Motorola's MPC106 and IBM's
>> CPC9x5 host bridges in some Macs, either can be found in prep or  
>> ofppc
>> machines as well )
>>
>>> Shall we define PCI_MAGIC_MEM_RANGE_{START,END} in param.h, just  
>>> like
>>> PCI_MAGIC_IO_RANGE?
>>
>> I don't see a need for that as long as you can
>> mmap(some_pci_bus_address) via ttyE0 you should be fine.
>>
>
>
> hmm?
> Then, should I make xf86PciBusAccWindowsFromOS() for __ powerpc__?
>
>
> #if defined(__powerpc__)
>
> xf86PciBusAccWindowsFromOS(void)
> {
>  :
>
>    RANGE(range, 0x00000000, 0xffffffff, ResExcMemBlock);
>    ret = xf86AddResToList(ret, &range, -1);
>
>  :
> }

0x80000000 - 0xffffffff is appropriate for macppc and probably most  
prep and ofppc boxes. I'd prefer if you put them into a separate #else  
if defined(...) branch. Not that it makes much of a difference since  
we don't expect the Xserver to configure cards ( even if OF doesn't  
know a card it will still configure its BARs ) but I'd like to keep  
the entry for macppc to avoid future confusion and as a (very) basic  
sanity check.

> When the problem of this space is not solved, we see the following  
> message.
> And, this address will fixup forcedly.
>
> (WW) ****INVALID MEM ALLOCATION**** b: 0x8000000 e: 0xbffffff  
> correcting^G

Ah, so PCI allocations below 2GB are legal on bebox. In that case you  
should definitely adapt xf86PciBusAccWindowsFromOS() to whatever range  
is valid on your hardware.
I'm not sure it makes much sense to keep entries for prep, ofppc and  
bebox separate since prep and ofppc can have all kinds of funky PCI  
bridges and there's probably no fixed range for all models.

> And, we fail in mmap() to a wrong address...

Do you mmap() through /dev/ttyE0 like pretty much all non-x86 ports?  
All framebuffer console drivers I wrote should accept PCI bus  
addresses as offsets. I'm not 100% sure about vga at pci though, it  
might need some work.

have fun
Michael

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of PGP.sig]