Port-ofppc archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: radeonfb on Pegasos



Tim Rightnour wrote:

> We need 2 segments available for the USER and KERNEL segment. However, the

And KERNEL2?


> pegasos maps 8,9,a,b,c,d and f. Leaving us only e to work with. I suspect
> we could probably get away with using b and e, as likely nothing on the
> pegasos primary pci maps as far out as b.

Right. Graphics boards appear at c,d so there should be nothing else which
requires too much memory.


> However, as a general problem, its much worse.

sigh


> I'm including a ranges map for various machines I've compiled. The problem
> becomes that we cannot pick any two values that something else doesn't
> stomp on. Notice that in particular, the 7043-140 seems to stomp on E.

Which means, the KERNEL_SR should not be fixed in vmparam.h, but a variable
determined on startup by machine type?

Or we cannot do a single GENERIC kernel, but need one for Pegasos, one for
7043-140, etc.


> I have avoided thinking about how to fix this for awhile now.. I guess
> it's time to start looking at it again. In the meantime, try B and E and
> see if you have any luck.

I did the following in vmparam.h:

#define USER_SR         11
#define KERNEL_SR       14
#include <powerpc/oea/vmparam.h>
#undef VM_MAX_KERNEL_ADDRESS
#define VM_MAX_KERNEL_ADDRESS (VM_MIN_KERNEL_ADDRESS + 0x10000000)

This leaves KERNEL2_SR at 14, which shoudln't hurt? Additionally I limited the
region to one 256MB segment. Why are two segments required anyway?

It works! radeonfb0 is successfully attached! A nice, white console with a
green font! Looks like macppc.

But it seems to ignore my DVI output, where I have my monitor plugged in.
Had to use the VGA output to see something...

-- 
    _  Frank Wille (frank%phoenix.owl.de@localhost)
 _ //  http://sun.hasenbraten.de/~frank/
 \X/   Phx @ #AmigaGer




Home | Main Index | Thread Index | Old Index