Re: [Fwd: [PATCH] Read MGA PInS data on PowerPC]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Petr Vandrovec wrote:

quoted

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 [off-list ref]'
included?

Yes.  Sorry.

quoted

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.

quoted

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)

iD8DBQFDDgOYX1gOwKyEAw8RAqXrAJ4mFRR8SaohEEZdTuRR55sRJRs1vgCfWiH2
5GmhGrUfFDlkIENEiS4bxIo=
=v5+D
-----END PGP SIGNATURE-----


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf