Re: range of resource of PCI memory for PowerPC

[KIYOHARA Takashi <kiyohara%kk.iij4u.or.jp@localhost>]

Hi! Michael,


From: Michael <macallan%netbsd.org@localhost>
Date: Mon, 15 Dec 2008 11:58:42 -0500

> 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.

# Also prep (and ibmnws) set pcimem as extent region 0x00000000.
# you can look sys/arch/prep/prep/mainbus.c:mainbus_attach().


> > 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.



#if defined(__powerpc__)

xf86PciBusAccWindowsFromOS(void)
{
  :

   RANGE(range, PCI_MAGIC_MEM_RANGE_START, PCI_MAGIC_MEM_RANGE_END,
       ResExcMemBlock);
   ret = xf86AddResToList(ret, &range, -1);

  :
}

> 
> > 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.

hmm...
For my bebox case, original pcimem address is 0x08000000.  The fixup-ed
address is 0x80000000.  We can obtain original address perhaps, if
'0x08000000 + OUR_MAGIC_NUMBER'.  (i.e. 0x88000000)
Also, can we obtain address, if VGA-card has two or more memory-BARs?

I think that it is important not to allow fixup.

Thanks,
--
kiyohara