On Thu, Mar 07, 2002 at 04:03:25AM +0100, Christer Weinigel wrote: > Peter Stuge <[EMAIL PROTECTED]> wrote: > > 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
The data book we got was incorrect, the errata incomplete and the drivers broken. OTOH, that was more than a year ago, hopefully things have changed. > 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. This is cool though. > 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). Unfortunately we needed more than that. But it all worked out. Eventually we got a fb driver from National. > 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. We used the SC1200, which has lots of video stuff built-in that caused some of our headaches. We needed TV resolutions and had no real way to get them at first. > 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. The architecture is documented, but the code they're using isn't easily available, I got a mail from Bari Ari yesterday saying that they now include source code for the VSMs with "XpressLoader 3.3" which is cool, if they allow you to make opensource drivers using what you learn from it. > 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. I think so too. It is at least needed for the NSC drivers to work. > 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. Most of the features, if not all, of the SC1200 work in Linux, with the right blend of initialization code and drivers. (Stay away from the National DP83815 driver, it sucks, use natsemi from Donald Becker&co instead) Then there's the design. Lots of National software assume you're running as root and not only allow but require you to poke around at physical addresses on the bus from userspace via a neat module. This needs to be fixed, however not neccessarily here. //Peter -- irc: CareBear\ irl: Peter Stuge
