Peter Stuge <[EMAIL PROTECTED]> wrote: > Had I still been there and they still been going, I would have loved to try > out your code. I had some discussions with Bari Ari on the topic some while > ago, as well. > > And what he writes in his mail on the SMM code and VSM and NSC being > unhelpful is also quite true. I don't think they'll help anyone create > an opensource BIOS for their systems when they have a subsidiary (Insyde) > whose only business is to sell BIOS software for NSC platforms..
I have quite the opposite experience with National, they have been very helpful and have provided me with a lot of documentation (the SC2200 data book, errata and some reference drivers). I have signed an NDA with National, but before I did that, I got a statement from them that it is ok for me to publish Open Source drivers that are created from the information I've got under the NDA. This is perfectly fine with me. Anyways, it's always possible to get to the information some other way if one wants to. For example, I just wrote a small program that dumps the contents of the display controller registers. Then I booted using the Insyde BIOS, and ran my little program. The next step was to do a cold boot (power off, wait a few seconds, power on) using LinuxBIOS so that the display controller is totally uninitialised. Finally I wrote another small program to program the display controller with the settings I had recorded. This way I just managed to get a 640x480, truecolor framebuffer running under Linux, without really having to understand anything about what goes into the display controller registers. (I think the same trick has been used a lot by the XFree86 people, set up the display running Windows, dump the clock chip settings and do the same thing under Linux). Of course, this was just a quick hack to see how much work is needed to get video running on the SC2200, so I am going to sit down and read the documentation and figure out what these values mean. It's much nicer to know what's going on, but it's not really neccesary to have the documentation to get something working. What I'm trying to say is that if it's important enough, somebody will write a driver, the only question is if the manufacturer will get a good reputation as a Linux-friendly company or not. Also, the quality of the driver will probably be a lot higher when the documentation is available. As for the VSA stuff, it does seem to be documented in the data book, but I'm not sure how complete the documentation is; there might be pieces missing from it. However, I'm probably going to avoid VSA as much as possible. VSA is mostly used to emulate legacy hardware, and that's not neccesary if I can write a Linux driver with native support instead. Actually, to support audio properly (which the board I'm working on doesn't have), I think some VSA or at least SMM support is needed, but I'll climb that mountain when I get to it. So I'm feeling rather confident that with the LinuxBIOS stuff I've written so far, I can get a Linux kernel running, and then the Linux kernel can have native drivers that handle video, audio, and all the other interesting features of the SC2200. I must admit that I might not release everything as Open Source yet, some drivers might have to be binary-only Linux modules for a while, if I can make money that way by selling an exclusive right to a client. I would prefer to publish everything as Open Source, but it's not always possible. /Christer -- "Just how much can I get away with and still go to heaven?"
