John Dennis writes:
> John Dennis writes:
>
> 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).
Interesting. Every once a while somebody comes up with something new.
At least I have a HP box which has a x86 BIOS. Possibly because it
is from the '1st generation' of machines.
>
> 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).
I've run into exactly the same issue on my box. You don't have to
eliminate the entire libint10. The problem are Lock/UnlockLegacyVGA().
I've submitted a solution for this problem to CVS. You need to put
an #ifndef __ia64__ ... #endif around the line which accesses address
0x46e8 (and possibly 0x102 - I don't remember).
This will not get you off the hook completely as the ATi drivers
probes for some Mach variants will make the box machine check, too.
I've talked to Marc Aurele about this. He proposed to add information
about host bridges to the Xserver where we can keep information on
which address ranges on the PCI bus can be probed savely.
So far I think he is still waiting for the necessary information by
HP.
My quick-n-dirty work around was to '#ifdef __ia64__'-out all probing for
'legacy' HW in the ATi driver. This however will not be in the CVS.
Yes, I've seen some of HP's hacks for XFree86. All I've seem
was not usable for XFree86.
>
> The lack of libint10 does not seem to cause problems for the ATI
> radeon drivers which is what HP ships.
The ATi driver reads information from the BIOS. On some versions
of the linux kernel the BIOS image that was created when the system
was initialized by the firmware was busted. This required some
reposting to get a clean BIOS image. I believe this kernel problem
has been fixed now.
>
> 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.
This is a bug.
>
> On the Intel ia64 boxes libint10 does work and is necessary for the
> ATI rage driver to come up correctly.
I've got it to work on my HP box, too.
>
> 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.
The solution proposed by Marc will solve this problem.
>
> 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?
Right.
Well, libint10 should work for all machines - unless the BIOS itself
accesses some registers which are prohibited on the specific
architecture.
>
> 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
We may be able to add support for other POSTing mechanisms.
Long time ago I looked into adding OpenFirmware support. However
nobody was able to provide the necessary information to me.
Now many drivers make excessive use of VESA BIOS extensions
not only to POST the cards but also to set up modes.
Other drivers know about the location of timing tables in
the x86 BIOS and access them.
> 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?)
Right.
What I see at initialization time on my system makes suggests
to me that even the EFI code makes use of the x86 BIOS.
>
> 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).
>
At the moment I don't have the latest rage code to look at.
It is however not unlikely - and I seem to recall that this
in fact happens - that the rage driver makes use of tables
from the BIOS.
Cheers,
Egbert.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
