From: Ian Romanick <idr@us...> - 2005-08-25 17:45:34
-----BEGIN PGP SIGNED MESSAGE-----
Petr Vandrovec wrote:
>> This updates the matroxfb code so that it can find the PInS data
>> embedded in the BIOS on PowerPC cards. The process for finding the data
>> is different on OpenFirmware cards than on x86 cards, and the code for
>> doing so was missing.
> Can you resend patch with 'Signed-off-by: Ian Romanick <idr@...>'
>> After patching, building, installing, and booting a kernel, you should
>> grep for "PInS" in /var/log/messages. You should see two messages in
>> the log:
>> PInS data found at offset XXXXX
>> PInS memtype = X
> Is not it possible to find PINS some other way, or just look at every
> 16th byte for signature, or something like that? Unless your image has
> signature at the beginning, it should take years to read EEPROM this
> way, with byte-after-byte reads. At least it is reason why I used this
> undocumented feature that PINS pointer is stored at the end of image.
> Scanning just every 16th byte in EEPROM took about 5 seconds before it
> found PINS at 0x6XXX address...
I've looked through all the documentation that I have, and I haven't
been able to find another way to do it. For x86, the PInS offset *is*
documented to be stored at offset 0x7FFC.
> As for your question about sparc in the code - what about modifying
> get_pins() to return success/failure, and then try current i386 code
> first, and if this fails to find PINS then scan whole BIOS image ? This
> way it will work even if you'll plug OpenFirmware card into i386 box.
The docs that I have indicate that offset 0x7FFC is past the end of the
end of the BIOS image on PowerPC versions of the card. I don't think
trying to access it on those cards is a good idea.
>> On the GXT135p card I get "31168" and "5". The first value is
>> irrelevant, but it's presence lets me know that the PInS data was
>> actually found. On a GXT130p, the second value should be 3. Since I
>> don't have access to that hardware, if someone can verify that, I will
>> submit a follow-on patch that rips out all the memtype parameter stuff.
> I would leave memtype untouched...
AFAIK, the only reason that parameter is needed is to support PowerPC
cards where the memtype couldn't be read from the PInS.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
-----END PGP SIGNATURE-----