John> I'm trying to fix some bugs with XFree86 drivers in an Itanium
John> (ia64) environment. ...
Egbert> I don't think you need to do too much for ia64. It works
Egbert> on all ia64 systems I have tested so far.
Unfortunately I have an example where it does not, see below.
Egbert> However Itaniums usually do have x86 BIOS cards.
Not on the 2nd generation ia64 boxes from HP. First generation
supported x86 BIOS, but HP decided to eliminate x86 BIOS emulation for
the 2nd generation, in part as I understand from a paper "Porting
Drivers to HP ZX1" by Grant Grundler of HP, to force adoption of EFI
(Extensible Firmware Interface).
John> ... is there some alternate mechanism for configuration in
John> these environments that XFree86 supports or intends to
John> support (e.g. EFI?).
Egbert> Possibly. If you can give us some information on EFI.
I'm probably the wrong person to fill you in on EFI, I've only been
just learning about it as I try to track down this problem. FWIW, in
the paper by Grundler he states "all the IO card vendors that supply
HP have committed to providing such a driver (EFI) and I know they are
delivering or have delivered."
Egbert> There are very few architectures where we build a stub
Egbert> libint10. These are mostly architectures that have an
Egbert> OpenFirmware approach. We expect libint10 to work on all
Egbert> other architectures.
see below
Egbert> Maybe you can give us some insight into what problems you
Egbert> are running into with libint10 on ia64?
O.K. here is the issue. I'm trying to make XFree86 with ATI drivers
run on both Intel and HP ia64 boxes with hopefully a common xfree86
binary package shared between them.
The Intel boxes support x86 BIOS, the HP's do not.
HP's proposed solution was to remove libint10.a from the modules
directory so that the ATI driver init code would not find the library
and load it, and initialize it. This is because xf86InitInt10 touches
some address that is not valid and causes a machine check (or at least
that is my current understanding, I'm still trying to nail down
exactly where the fault is occurring).
The lack of libint10 does not seem to cause problems for the ATI
radeon drivers which is what HP ships.
However, the ATI rage drivers do not deal well with the lack of
libint10 and seems to set really bogus video timings as a result
(there are other bugs I've fixed where the rage driver will crash if
libint10 is not present). In fact in the rage driver only part of the
code checks for the existence of libint10 and other parts of the code
blithely assumes it's existence.
On the Intel ia64 boxes libint10 does work and is necessary for the
ATI rage driver to come up correctly.
Therefore we have a situation where on two boxes that are
architecturally identical (or at least really really close) and
depending on the installed video card libint10 has to be present or
absent or really bad things happen.
I'm not a fan of the idea of not installing libint10 on ia64 to solve
this problem, its a hack solution and is not general and it makes
coming up with a common binary package for ia64 problematic and what
happens if someone switches the video card?
It seems to me that all video drivers need to be able to initialize
correctly without libint10 since its an architecturally specific
utility. While its true that many non-x86 vendors provide BIOS
emulation support to provide a legacy friendly environment there is no
requirement for them to do so and drivers should be prepared for some
other configuration option, (but what would that be?)
I'm still trying to tack down why the ATI radeon seems to initialize
correctly without libint10 but the rage does not. I'm beginning
to believe libint10 should not be installed on ia64 (unless we can
come up with a way to make it work in the absence of a x86 BIOS).
John
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
