It works :D
And there was much rejoicing.
:D
Many thanks for your help.
No prob. I'm just glad we were able to make it work.
I'm too.
Now we need to document all this. Can you list all of the problems you had (so far) and what their solutions were. Then I'll edit it and get it up on the wiki.
Well, I will make it in the next days. Unfortunatly, the X fbdev driver does not work. Probably it is a inconsistent between viafb and fbdev. Doesn't matter. I have find out, that the TinyX Xfbdev-Server works great :D
Also I think we need to create a new mainboard for this setup with all your mods. You have had 2 seperate cases where a device difference caused you some trouble.
Eventually, there are more ie the non exist fdc port
Please create a new mainboard directory and a new target with your working setup and submit the diff for inclusion back into the tree.
No problem. But there are many calls to devices, which the epia-ml not have. I think, that makes Linuxbios a little bit slow or there are other dev_find_device calls with false device IDs :D. I will try to remove these sections before I create a new target.
Still un-answered is _what_ was trashing parts of the 0x0c0000 area. We have fixed the symptom but not the cause.
That's right. I have looked again and again at the code and it seems it is garbage, only. But I'm not sure.
I wonder is this a global via epia problem?
Not, if the write_protect_vgabios function works :) I have read somewhere in the net, that newer epias have a new designed CLE266 Chipsets. It could be the reason for the different device IDs In the X source code I have found somewhere:
1106_3122 = VT8623 [Apollo CLE266] integrated CastleRock graphics 1106_3123 = VT8623 [Apollo CLE266]
It would be helpfull if the rest of the via epia users would comment out the write protect and see if they see the same thing happen.
Good idea. chris