Age | Commit message (Collapse) | Author |
|
This is probably quite a hack. however some bridges have multiple
"memory" segment according to the openfirmware data. one is
the pci device probe register area, and the one or two more
that are real address regions. Such as base 0x80000000 sz 0x10000000,
base 0x90000000 sz 0x10000000. This should really be one region
but detecting the "last" region to avoid the first region causes the
wrong base address to be picked. Currently this hardcodes it to
0x80000000 because it seems to work for "normal" pci currently.
openfirmware puts full address in the field and the other devices
seem to work on tested machines.
|
|
may be the same as visual width or larger.
This is seen on iMacDV systems running at 640x480 or 800x600 with a linebytes
of 1024.
|
|
|
|
|
|
|
|
instead of DISPLAY_VGA
|
|
from the pci bus. This is in preference to adding openfirmware code to
the device drivers. If there was a known way of obtaining the ethernet
hardware address from a eeprom or other methods that would be used, but
the only known way to get this information for the Apple machines with
if_gm is via openfirmware.
This modifies a previous mechanism that was used to obtain similar information
from different openfirmware systems, however the old mechanism would create
information such as media type. This information was hardcoded into
that code. Now the code only returns the actual address which is the
only informatin that openfirmware provides.
|
|
|
|
|
|
|
|
routines added to set the colormap via openfirmware.
Changes by both Matthieu and myself
|
|
would unmap the cursor at y,y rather than the real position.
|
|
independant, but not now.
|
|
|
|
|
|
The previous change would incorrectly allow the macintr interrupt
controller to configure for the openpic interrupt controller.
|
|
Openfirmware does not have entries for the interrupt controller.
|
|
retrieved, do not walk the (uninitialized?) stack until a value is found.
|
|
use the same code for read and write for easier maintance.
code to walk the openfirmware device tree when a bridge is configured
to copy the interrupt line information into the pci register so
that the device driver can use it. Apple Openfirmware doesn't do
this automatically.
|
|
|
|
|
|
devices that are not recognize by drivers, it does not seem right
to imply that fd, scsi and adb devices exist on an imac, (ok, they
really do but apple did not bring the pins out where they were useable.)
|
|
|
|
hopefully will be used to configure special items on bridges.
(such as hacks to enable devices?)
|
|
allows imac to configure ohci.
|
|
|
|
cleaned up the previous support for the macobio that was there previously.
Now registers real interupt handler devices instead of the pseudo configed
ones before.
The G4 systems are not yet working, the onboard ide configures properly
and interrupts seem to work, but the system hangs before mounting
the root drive (even ramdisks). Maybe someone will point out something
bogus in the code, so it is being checked in.
|
|
portion of the pci devices, 1,2,4,8,... instead of 1,2,3,4,5,6,7,8,...
Updated to use indirect PCI configuration, so that pci-pci buses could
be probed. And that devices > 11 on the pci bus could be detected.
|
|
it has a copyin bug after device configuration. However to get these diffs
out of my tree.
All of the UVM code is currently inside ifdef UVM the kernel works fine
without option UVM. Config files have been left without UVM for now.
Prelimiary changes for busdma, (what UVM was wanted for).
|
|
will need to be merged back in. Both are currently untested.
mac interrupt support is currently a big hack and needs to be redesigned
as part of the system, several of the mac drivers need busified also.
|
|
|
|
referring to the offset specified in the pci base address config register.
|
|
|
|
|
|
Use the pci iack cycle to determine interrupt cause instead of
polling the chip.
Probably could use some more work.
|
|
NCR driver seems to work.
Major changes are isa can be child of pci or mainbus.
ofroot is child of mainbus not root.
ofw bus configured before pci bus
Note that if a pci device configures accessing of driver will crash
the system. they need to be exclusive.
|
|
|
|
|
|
|
|
the first "network" with a "mac-address" for this. In the future this has
to be improved (probably) to handle more than one ethernet ifc.
|
|
|
|
|