From: Olaf Hering <hidden> Date: 2000-09-26 18:46:06
On Tue, Sep 26, Michael Schmitz wrote:
I've posted such a patch to debian-powerpc when one user there had this
problem. That was before I learned booting with yaboot avoids the problem.
If the resource conflict also happens on oldworld machines, I'd still
prefer some suggestions to foolproof the patch (as in: how can I figure
out if a region has been allocated by another card? What bits from the
config registers should I look at?).
I have a precompiled benh Kernel at penguinppc.org/~olaf with Benhs current
kerneltree, your patch is still needed - otherwise *kaboom*
Gruss Olaf
--
$ man clone
BUGS
Main feature not yet implemented...
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-09-26 19:27:02
quoted
I've posted such a patch to debian-powerpc when one user there had this
problem. That was before I learned booting with yaboot avoids the problem.
If the resource conflict also happens on oldworld machines, I'd still
prefer some suggestions to foolproof the patch (as in: how can I figure
out if a region has been allocated by another card? What bits from the
config registers should I look at?).
I have a precompiled benh Kernel at penguinppc.org/~olaf with Benhs current
kerneltree, your patch is still needed - otherwise *kaboom*
No surprise there. But I don't consider the patch clean enough for
inclusion with the 2.2 kernels, at least not without safeguarding that the
guessed PCI region isn't occupied.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-09-26 21:02:53
quoted
I've posted such a patch to debian-powerpc when one user there had this
problem. That was before I learned booting with yaboot avoids the problem.
If the resource conflict also happens on oldworld machines, I'd still
prefer some suggestions to foolproof the patch (as in: how can I figure
out if a region has been allocated by another card? What bits from the
config registers should I look at?).
I have a precompiled benh Kernel at penguinppc.org/~olaf with Benhs current
kerneltree, your patch is still needed - otherwise *kaboom*
Allocating a region is nasty. You must find a free physical region (2.2.x
has no support for that) and you must find one that is decoded by the
north bridge (we currently have no code for either reading or writing the
address space decode enable bits of Bandit and UniNorth).
That's step 2 of my PCI patches. I will a set of regions per hose (pci
controller, Apple ones can decode several non-contiguous regions).
With this done, we will be able to really allocate PCI space from the
kernel. I still have to check if the common PCI code provides enough
hooks so I can even add new decoded regions to Bandit/Uninorth, but
that's not terribly important.
One thing: I'd be interested in figuring out what happens if you simply
leave this nasty ATI BAR unassigned (write 0xffffffff and then 0 to it).
Will the controller fail ?
What I can do in the meantime is test that we are running _exactly_ on
this machine model, and them remap to a region we know is safe (that's
more or less what you patch do).
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Lanners <hidden> Date: 2000-09-27 05:32:44
Hi Ben,
On 26 Sep, this message from Benjamin Herrenschmidt echoed through cyberspace:
Allocating a region is nasty. You must find a free physical region (2.2.x
has no support for that) and you must find one that is decoded by the
north bridge (we currently have no code for either reading or writing the
address space decode enable bits of Bandit and UniNorth).
That's step 2 of my PCI patches. I will a set of regions per hose (pci
controller, Apple ones can decode several non-contiguous regions).
With this done, we will be able to really allocate PCI space from the
kernel. I still have to check if the common PCI code provides enough
hooks so I can even add new decoded regions to Bandit/Uninorth, but
that's not terribly important.
UniNorth, I don't know; but that should not be a problem. If you look at
my latest published PCI patches for 2.3/2.4 kernels, I've attempted to
do exactly that. It crashed in that code but that's a different issue...
Just allocate memory for up to 4 resources per bus, and fill those with
the regions that the hose decodes, flags included, in any order. The PCI
code will try it's best than to allocate resource demands for that bus
out of the provided bus resources, looking for the closest fit.
FWIW, I am reading the resource regions decoded by the hose from the OF
device tree. The encoding is documented somewhere in the OF to PCI
binding doc. I've also added a struct ranges_property in
include/asm-ppc/prom.h.
Cheers
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Olaf Hering <hidden> Date: 2000-09-27 10:08:10
On Tue, Sep 26, Benjamin Herrenschmidt wrote:
One thing: I'd be interested in figuring out what happens if you simply
leave this nasty ATI BAR unassigned (write 0xffffffff and then 0 to it).
Will the controller fail ?
How do I do that? Can one of you prepare a diff against Bens current
tree? He is at pre10 since last night.
What I can do in the meantime is test that we are running _exactly_ on
this machine model, and them remap to a region we know is safe (that's
more or less what you patch do).
My machine has these data:
cpuinfo:
clock : 291MHz
machine : PowerBook
motherboard : AAPL,PowerBook1998 MacRISC
lspci -n:
00:11.0 Class 0300: 1002:4c47 (rev 80)
This is what 18pre4-ben1 reports:
<6>MacOS display is /pci/ATY,264LT-G
<4>atyfb: alternate regbase 1 phys 0x82fff000 virt 0xd0004000
<4>atyfb: alternate regbase 2 phys 0x82fff000 virt 0xd0007000
<4>atyfb: framebuffer phys 0x82800000 virt 0xd000a000
<4>atyfb: region 2 ofbase 0x10000000 breg 24 io 0 pbase 0x82fff000 size
0x1000 overlaps VRAM - reassigned to pbase 0x83000000 size 0x1000 !
<4>atyfb: alternate regbase 3 phys 0x83000000 virt 0xd080b000
<4>atyfb: 3D RAGE LT-G [0x4c47 rev 0x80] 4M SGRAM, 14.31818 MHz XTAL, 230 MHz PLL, 63 Mhz MCLK
<4>BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF
<4>7b23a040 87010182 044215b7 a5000001 03000300 00280840 01a005fe
<4>PLL cd d3 21 44 e8 03 80 e1 8e 9e 98 14 a6 1b 00 00
<4>atyfb: using alternate regbase 1:
<4>BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF
<4>7b23a040 87010182 044215b7 a5000001 03000300 00280840 01a005fe
<4>PLL cd d3 21 44 e8 03 80 e1 8e 9e 98 14 a6 1b 00 00
<4>atyfb: using alternate regbase 2:
<4>BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF
<4>7b23a040 87010182 044215b7 a5000001 03000300 00280840 01a005fe
<4>PLL cd d3 21 44 e8 03 80 e1 8e 9e 98 14 a6 1b 00 00
<4>atyfb: using alternate regbase 3:
<4>BUS_CNTL DAC_CNTL MEM_CNTL EXT_MEM_CNTL CRTC_GEN_CNTL DSP_CONFIG DSP_ON_OFF
<4>7b23a040 87010182 044215b7 a5000001 03000300 00280840 01a005fe
<4>PLL cd d3 21 44 e8 03 80 e1 8e 9e 98 14 a6 1b 00 00
<6>atyfb: monitor sense=51e, maps to mode 7
<4>Console: switching to colour frame buffer device 128x48
<4>fb0: ATY Mach64 frame buffer device on /pci/ATY,264LT-G
I have currently no access to other PowerBooks, only the Wallstreets
need the patch. iBook works fine and Lombard should also work.
There is still that init problem, but it is less worse than a hard
crash.
Gruss Olaf
--
$ man clone
BUGS
Main feature not yet implemented...
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-09-27 10:33:06
FWIW, I am reading the resource regions decoded by the hose from the OF
device tree. The encoding is documented somewhere in the OF to PCI
binding doc. I've also added a struct ranges_property in
include/asm-ppc/prom.h.
I'm not very confident on the device tree content on those UniNorth
machines. I prefer reading the decoded regions from the address select
register of the bridge itself ;) (There's code in Darwin that shows how
it works).
Where can I find your patch that does this region hacking ?
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Tue, 26 Sep 2000, Benjamin Herrenschmidt wrote:
One thing: I'd be interested in figuring out what happens if you simply
leave this nasty ATI BAR unassigned (write 0xffffffff and then 0 to it).
Will the controller fail ?
Well, according to Matt Porter, 0 is a valid address in PCI 2.2. So how do you
disable BARs for PCI 2.2-compliant devices?
And I'm afraid what XFree86 4.x will do with BARs set to 0. Probably it will
try to relocate them. I guess that's how it crashes on my box with an
unitialized S3...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-09-27 17:22:30
quoted
One thing: I'd be interested in figuring out what happens if you simply
leave this nasty ATI BAR unassigned (write 0xffffffff and then 0 to it).
Will the controller fail ?
Well, according to Matt Porter, 0 is a valid address in PCI 2.2. So how
do you
disable BARs for PCI 2.2-compliant devices?
And I'm afraid what XFree86 4.x will do with BARs set to 0. Probably it will
try to relocate them. I guess that's how it crashes on my box with an
unitialized S3...
Well, I may be wrong here, but the cause of our problem (the MMIO BAR
overlapping the framebuffer BAR causing XFree to bark) may also be an
XFree problem. I think we never completely figured out if what MacOS does
to the chip is valid or not (because of priority-decoding).
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Tue, 26 Sep 2000, Benjamin Herrenschmidt wrote:
quoted
One thing: I'd be interested in figuring out what happens if you simply
leave this nasty ATI BAR unassigned (write 0xffffffff and then 0 to it).
Will the controller fail ?
Well, according to Matt Porter, 0 is a valid address in PCI 2.2. So how do you
disable BARs for PCI 2.2-compliant devices?
And I'm afraid what XFree86 4.x will do with BARs set to 0. Probably it will
try to relocate them. I guess that's how it crashes on my box with an
unitialized S3...
Yeap unless i am wrong it will try to relocate them, for prep i fear that
without correct BusAddrToHostAddr/HostAddrToBusAddr functions in the xserver
this isn't going to work at all :(
Don't expect it to initialize the S3 card in any case, the int10 module
needs ISA IO/mem accesses and both don't work at the moment for linux/ppc
you can imagine what the following code will do to your machine :(
#define V_RAM 0xA0000
INTPriv(pInt)->vRam = xf86MapVidMem(screen,VIDMEM_MMIO,V_RAM,size);
Kostas
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Lanners <hidden> Date: 2000-09-28 06:00:40
On 27 Sep, this message from Benjamin Herrenschmidt echoed through cyberspace:
I'm not very confident on the device tree content on those UniNorth
machines. I prefer reading the decoded regions from the address select
register of the bridge itself ;) (There's code in Darwin that shows how
it works).
I don't mind you doing that ;-) Is there any standard for reading these
things off the bridge?
Where can I find your patch that does this region hacking ?
On Tue, 26 Sep 2000, Benjamin Herrenschmidt wrote:
quoted
One thing: I'd be interested in figuring out what happens if you simply
leave this nasty ATI BAR unassigned (write 0xffffffff and then 0 to it).
Will the controller fail ?
Well, according to Matt Porter, 0 is a valid address in PCI 2.2. So how do you
disable BARs for PCI 2.2-compliant devices?
And I'm afraid what XFree86 4.x will do with BARs set to 0. Probably it will
try to relocate them. I guess that's how it crashes on my box with an
unitialized S3...
Yeap unless i am wrong it will try to relocate them, for prep i fear that
without correct BusAddrToHostAddr/HostAddrToBusAddr functions in the xserver
this isn't going to work at all :(
Don't expect it to initialize the S3 card in any case, the int10 module
needs ISA IO/mem accesses and both don't work at the moment for linux/ppc
you can imagine what the following code will do to your machine :(
#define V_RAM 0xA0000
INTPriv(pInt)->vRam = xf86MapVidMem(screen,VIDMEM_MMIO,V_RAM,size);
Yes, you have to know the ISA memory base address, which is machine dependent.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Don't expect it to initialize the S3 card in any case, the int10 module
needs ISA IO/mem accesses and both don't work at the moment for linux/ppc
you can imagine what the following code will do to your machine :(
#define V_RAM 0xA0000
INTPriv(pInt)->vRam = xf86MapVidMem(screen,VIDMEM_MMIO,V_RAM,size);
Yes, you have to know the ISA memory base address, which is machine dependent.
Thanks to Ben we have the pciconfig_iobase syscall now but nothing to get
the ISA memory base, if someone has the time to add such a syscall fixing
xf86MapVidMem shouldn't be hard at all.
Kostas.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/