[Openchrome-users] Memory size detection failed: using 16MB, system has 8MB

[Luc Verhaegen]

On Tue, Feb 06, 2007 at 02:51:04PM +0100, Mark Huijgen wrote:
>
> With the code in Luc's driver I managed to fix the openchrome driver for 
> my chip regarding video memory detection.
> The problem is that on my system
>    hwp->readSeq(hwp, 0x34);
> Failes to get the memory size, Luc's driver falls back in this case to 
> call 0x39 used for other types of chips.
> This correctly detects the 8Mb video ram in my system.
> 
> Attached is a patch that adds this fallback to via_driver.c against 
> current svn, maybe usefull to include in the tree.
> 
> regards,
> Mark

Oh, you're wrong, and you're right, at the same time.

Yes, somewhere around the time the VT7205 came out, some VIA BIOS
developers decided to change which scratch register was responsible for 
the FB size. They probably accidentally changed one value in a table, 
and then no-one knew why or how it had changed, as the usage of scratch 
registers was notso straightforward before the K8M890.

This was one of the first issues i put right (to some extent) back when 
xfree86 was alive.

The trouble is that on the common CLE266 based devices, the old scratch 
is being used, and on some newer, less common semi-embedded things 
(igel thin clients perhaps?) the new scratch register is being used.

So yes, a long while ago i introduced that change.

However, the only correct solution is to not depend on those weird 
scratch registers at all.

See, I talk to the ram controller directly. No fuss, no failure. Rock 
solid. This was something VIA introduced in their code a year or so 
ago, but they originally messed up theirs as they hadn't bothered to 
test it.

Nowadays, i get everything i need (FB size, ram type, direct access 
address) from the ramcontroller directly.

The only reason those scratch registers are still used is to gloat:
"Ooh, look, another wonky BIOS."

Luc Verhaegen.