>>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 -- LinuxBIOS mailing list LinuxBIOS@openbios.org http://www.openbios.org/mailman/listinfo/linuxbios
