Hi, here's some code for the IT8718F. Untested, but compiles.
Please also checkin my patch at http://www.linuxbios.org/pipermail/linuxbios/2006-August/015412.html I think that got overlooked (or is there a technical problem with it?).
Btw, is the code for the Super IOs supposed to initialize/enable _all_ supported devices or merely COM1/COM2 and the rest gets enabled later on?
U "I read ITE datasheets when I'm bored" we.
Btw, is the code for the Super IOs supposed to initialize/enable _all_ supported devices or merely COM1/COM2 and the rest gets enabled later on?
First it depends on the config file. If the device is not enabled in the config file then don't turn it on. Com 1 being the exception..
Second depends if the kernel can turn it on or not. In a lot of cases if the kernel gets back an invalid read of the base address it assumes the device is just not there or disabled for a reason.
Generally though for superIO stuff if the kernel can find it then it can init it so just turning on the device so the base address shows up should be enough.
Hi,
On Tue, Aug 29, 2006 at 11:57:48AM -0500, Richard Smith wrote:
First it depends on the config file. If the device is not enabled in the config file then don't turn it on. Com 1 being the exception..
Hm, I currently just turn on every supported Super IO device (FDC, Com1, Com2, PP, etc. etc.) in the ITE code. Should I check for some variables/#defines in the code and only conditionally enable them? If so, how do I do that? Or shall I simply continue to enable everything as you state below?
Generally though for superIO stuff if the kernel can find it then it can init it so just turning on the device so the base address shows up should be enough.
Uwe.
* Uwe Hermann uwe@hermann-uwe.de [060830 14:41]:
Hm, I currently just turn on every supported Super IO device (FDC, Com1, Com2, PP, etc. etc.) in the ITE code. Should I check for some variables/#defines in the code and only conditionally enable them?
Yes, please have a look at the other superio implementations. You want to be able to switch off certain devices in the config file. Because they're not wired on the board or because you want to disable them, etc.
Or shall I simply continue to enable everything as you state below?
no, please make sure the drivers have their hooks so they can be controlled via the mainboard config files.
We need to get all components to have all their choices available in the config files, or we will have to patch and patch and patch code for every board we want to support. That is something I want to get away from --> more modular concept.
Uwe Hermann wrote:
Hi, here's some code for the IT8718F. Untested, but compiles.
Are you working on the support for these devices by just using the data sheets and without hardware to test this? It's great if you are. It's a good starting point for someone else with hardware.
Bari
Bari Ari wrote:
Uwe Hermann wrote:
Hi, here's some code for the IT8718F. Untested, but compiles.
Are you working on the support for these devices by just using the data sheets and without hardware to test this? It's great if you are. It's a good starting point for someone else with hardware.
Yes, he is. This has the potential to get quite a lot of people started and getting any output at all is a major motivation factor even if the rest of the code for bringup has yet to be written.
Can we build a ROM which does nothing but execute early serial code for a given SuperIO, prints a few messages and then halts? So that if somebody knows the SuperIO on his mainboard he can build a ROM testing the code we have for it? Or does the early serial code also depend on northbridge/southbridge/CPU?
Regards, Carl-Daniel
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [060829 23:06]:
Yes, he is. This has the potential to get quite a lot of people started and getting any output at all is a major motivation factor even if the rest of the code for bringup has yet to be written.
Definitely. Uwe, can you (or someone else) have a look what SuperIOs boards usually use, so we can try to support an as large as possible set of boards theoretically. (thinking mainstream)
Stefan
Stefan Reinauer wrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [060829 23:06]:
Yes, he is. This has the potential to get quite a lot of people started and getting any output at all is a major motivation factor even if the rest of the code for bringup has yet to be written.
Definitely. Uwe, can you (or someone else) have a look what SuperIOs boards usually use, so we can try to support an as large as possible set of boards theoretically. (thinking mainstream)
The FSF has a campaign (http://www.fsf.org/campaigns/free-bios.html) we could use for sampling which SuperIOs are used in commonly sold boards. Their "how can you help" section could state prominently that we need a list of boards with matching SuperIOs.
Suggested text follows: "The LinuxBIOS project needs your help to make LinuxBIOS work on your mainboard. A first important step is to know which SuperIO your mainboard uses. This information can be obtained easily following the directions on <some LinuxBIOS wiki page>. Once that is known, you can download a matching experimental BIOS image and test the code."
The LinuxBIOS wiki page could read as follows: "How to find the SuperIO on your mainboard? There are two ways to do it: 1. Find the chip on the board (usually a bigger chip with ITE, NSC, SMSC, VIA or Winbond written on it). See <photo> and <photo> for reference. 2. Find the chip with sensors-detect and look for something named SuperIO. See <sample output> for reference. Equipped with that information, you may also want to find out if that chip is really soldered on your board. Please add this your findings to the wiki so others can verify and profit from it.
<example board> <example superio> <link to bios image> <example board> <example superio> <link to bios image>"
What do you think?
Regards, Carl-Daniel
Hi,
On Wed, Aug 30, 2006 at 12:11:14AM +0200, Carl-Daniel Hailfinger wrote:
The FSF has a campaign (http://www.fsf.org/campaigns/free-bios.html) we could use for sampling which SuperIOs are used in commonly sold boards. Their "how can you help" section could state prominently that we need a list of boards with matching SuperIOs.
Suggested text follows: "The LinuxBIOS project needs your help to make LinuxBIOS work on your mainboard. A first important step is to know which SuperIO your mainboard uses. This information can be obtained easily following the directions on <some LinuxBIOS wiki page>. Once that is known, you can download a matching experimental BIOS image and test the code."
The LinuxBIOS wiki page could read as follows: "How to find the SuperIO on your mainboard? There are two ways to do it:
- Find the chip on the board (usually a bigger chip with ITE, NSC, SMSC, VIA or Winbond written on it). See <photo> and <photo> for reference.
- Find the chip with sensors-detect and look for something named SuperIO. See <sample output> for reference. Equipped with that information, you may also want to find out if that chip is really soldered on your board.
Please add this your findings to the wiki so others can verify and profit from it.
<example board> <example superio> <link to bios image> <example board> <example superio> <link to bios image>"
What do you think?
Asking for help in the FSF campaign is definately a good idea, as it reaches quite a lot of people, I guess.
I'm not sure whether a list of Super IOs is all that useful, though. We can simply support all of them (a coordinated effort shouldn't take more than a few weeks to support almost all Super IOs you can get a datasheet for).
I'm sure there are other areas where the project needs lots more help; Someone who is more involved with the project than I am should probably create a list of such areas.
IMHO these things are quite important:
1) publicity among non-coders to make the project well-known, and to make the fact known that there's a viable, working Free Software alternative to proprietary BIOSes.
2) Get as many coders as possible involved. Create incentive to try LinuxBIOS, which will result in active contributions in many cases. It's crucial to have support for a wide range of hardware, as only that will really ensure a wide-spread use of LinuxBIOS (I'm especially thinking about desktop machines here).
3) Create pressure on those companies which do not give out datasheets for various hardware parts. This is much easier if 1) is successful and many people/customers demand LinuxBIOS support.
HTH, Uwe.
* Uwe Hermann uwe@hermann-uwe.de [060830 14:37]:
I'm not sure whether a list of Super IOs is all that useful, though. We can simply support all of them (a coordinated effort shouldn't take more than a few weeks to support almost all Super IOs you can get a datasheet for).
Supporting all of them for the sake of it makes no sense, by your leave. SuperIO chips alone dont do the deed. if we manage to get a "coordinated effort", i'd much rather go and support "80% of the common superio chips out there" with in the end 50% of the effort and instead try to get some more southbridge/northbridge combinations supported with this effort. On K8 we lack Via and ATI chipset support, for Via we lack C7 support,... all that stuff will give us a user base. 100% superio chips alone wont, given that in 2 months we're at 98% of the existing superios again, and in 2 ys below 50%.
- publicity among non-coders to make the project well-known, and to make the fact known that there's a viable, working Free Software alternative to proprietary BIOSes.
I completely agree. The key to success here is, in my opinion, to provide ready-built and tested images on an automated base for certain hardware. Also, we need to work on the configuration part to move more mainboard specifics (irq routing, complete hw tree) in the config file. A mainboard from all supported components should not need any code to be touched. only configuration files. Well, maybe we go with an exception of a little GPIO triggering here and there i f this can not be automated, but other than that: no new code for _motherboards_
- Get as many coders as possible involved. Create incentive to try LinuxBIOS, which will result in active contributions in many cases. It's crucial to have support for a wide range of hardware, as only that will really ensure a wide-spread use of LinuxBIOS (I'm especially thinking about desktop machines here).
Unlike normal userspace programs or even kernels, recovering from a bad bios can be quite some work. How do we overcome this? Not everyone is going to buy a galep iv for 400$, nor a bios savior for 30.
- Create pressure on those companies which do not give out datasheets for various hardware parts. This is much easier if 1) is successful and many people/customers demand LinuxBIOS support.
what do you mean by pressure?
Stefan
Stefan Reinauer wrote:
- Uwe Hermann uwe@hermann-uwe.de [060830 14:37]:
- Get as many coders as possible involved. Create incentive to try LinuxBIOS, which will result in active contributions in many cases. It's crucial to have support for a wide range of hardware, as only that will really ensure a wide-spread use of LinuxBIOS (I'm especially thinking about desktop machines here).
Unlike normal userspace programs or even kernels, recovering from a bad bios can be quite some work. How do we overcome this? Not everyone is going to buy a galep iv for 400$, nor a bios savior for 30.
In Germany you can get cheap flash chips at http://www.bios-chip.de/ . SST 49LF008A (8 Mbit FWH) only costs 8.50 Eur, which is really affordable. With such a chip, there is no need for a BIOS saviour. And 8 Mbit is enough even if you want to fit a complete kernel in ROM.
Regards, Carl-Daniel
On Wed, Aug 30, 2006 at 05:28:40PM +0200, Carl-Daniel Hailfinger wrote:
In Germany you can get cheap flash chips at http://www.bios-chip.de/ .
Yep. Or from Conrad (www.conrad.de) or other electronics vendors, I guess. I also ripped some off of old and broken motherboards (e.g. from flea markets etc.).
Uwe.
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [060830 17:28]:
In Germany you can get cheap flash chips at http://www.bios-chip.de/ . SST 49LF008A (8 Mbit FWH) only costs 8.50 Eur, which is really affordable. With such a chip, there is no need for a BIOS saviour. And 8 Mbit is enough even if you want to fit a complete kernel in ROM.
I know, I did chip hotswapping for several years now.
While I think it is a great opportunity to be a cheap date, you do risk messing up the hardware physically if you swap very often.
And this is exactly the thing that keeps people from "playing around" with LinuxBIOS as they do with other software projects...
Stefan
Hi,
On Wed, Aug 30, 2006 at 07:54:55PM +0200, Stefan Reinauer wrote:
While I think it is a great opportunity to be a cheap date, you do risk messing up the hardware physically if you swap very often.
And this is exactly the thing that keeps people from "playing around" with LinuxBIOS as they do with other software projects...
Yes, sure it's a bit more risky to play with important hardware parts; that's why I think we need to support lots of older boards, chips, etc. which people are willing to play with and/or can easily and cheaply get from flea markets, ebay etc.
Another important issue is that flashrom should support many, many chips and baords, as few people will be willing to buy expensive hardware just for flashing.
There's Uniflash, but that has the problem of being Pascal+DOS, currently. I tried for a few minutes to build it with GNU Pascal or FreePascal, but that didn't work easily (needs more work, maybe). Has anybody else managed to build it for Linux?
Uwe.
* Uwe Hermann uwe@hermann-uwe.de [060831 23:55]:
Another important issue is that flashrom should support many, many chips and baords, as few people will be willing to buy expensive hardware just for flashing.
There's Uniflash, but that has the problem of being Pascal+DOS, currently. I tried for a few minutes to build it with GNU Pascal or FreePascal, but that didn't work easily (needs more work, maybe). Has anybody else managed to build it for Linux?
Uniflash works so well because it does 16bit bios calls itself. I am not sure we want to do this. Maybe we do? Maybe with x86emu? Ollie? Ron?
Stefan
Stefan Reinauer wrote:
- Uwe Hermann uwe@hermann-uwe.de [060831 23:55]:
Another important issue is that flashrom should support many, many chips and baords, as few people will be willing to buy expensive hardware just for flashing.
There's Uniflash, but that has the problem of being Pascal+DOS, currently. I tried for a few minutes to build it with GNU Pascal or FreePascal, but that didn't work easily (needs more work, maybe). Has anybody else managed to build it for Linux?
Uniflash works so well because it does 16bit bios calls itself. I am not sure we want to do this. Maybe we do? Maybe with x86emu? Ollie? Ron?
Most PC BIOSes have a flash program in ROM, so x86emu won't help us much. The 16bit BIOS calls are just calls to that flash program. I know for sure that all recent Asus boards have awdflash or similar in their ROM image.
Regards, Carl-Daniel
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [060901 02:07]:
Most PC BIOSes have a flash program in ROM, so x86emu won't help us much. The 16bit BIOS calls are just calls to that flash program.
Except Asus:
Not really a flash program but functions to enable / disable write protection of the bios chips and address spaces. There's an AWDFLASH structure that points into this. I reverse engineered this many years ago until I found out that I want to support hardware that is supported by its vendor.
I know for sure that all recent Asus boards have awdflash or similar in their ROM image.
Thats definitely not what the user land bios flashers like uniflash use. it seems they want to get rid of bios updates while the os is running completely. Not dumb, really.
Stefan
* Uwe Hermann uwe@hermann-uwe.de [060831 23:55]:
Another important issue is that flashrom should support many, many chips and baords, as few people will be willing to buy expensive hardware just for flashing.
There's Uniflash, but that has the problem of being Pascal+DOS, currently. I tried for a few minutes to build it with GNU Pascal or FreePascal, but that didn't work easily (needs more work, maybe). Has anybody else managed to build it for Linux?
And then there's /dev/bios. It supports quite a lot of hardware and it talks to the hardware in a smarter way than most flash drivers in "flashrom". This is why I still get regular mails for the driver.
But it should be all integrated in flashrom, its architecture is a lot more sane. (And it does not need to recompile the software for every kernel update :-/)
Stefan
Stefan Reinauer wrote:
And then there's /dev/bios. It supports quite a lot of hardware and it talks to the hardware in a smarter way than most flash drivers in "flashrom". This is why I still get regular mails for the driver.
But it should be all integrated in flashrom, its architecture is a lot more sane.
Oh. I had assumed flashrom was the successor of /dev/bios and other flashing tools. Porting the code from /dev/bios to flashrom will probably be a lot easier than trying to find out what uniflash does.
Stefan, do you have any plans in that direction?
Regards, Carl-Daniel
On Wed, Aug 30, 2006 at 05:10:15PM +0200, Stefan Reinauer wrote:
Supporting all of them for the sake of it makes no sense, by your leave. SuperIO chips alone dont do the deed. if we manage to get a "coordinated effort", i'd much rather go and support "80% of the common superio chips out there" with in the end 50% of the effort and instead try to get some more southbridge/northbridge combinations supported with this effort.
Sure, that's important as well. But Super IOs are (comparatively) easy to understand and support, and the amount of code needed is small, so we can add support for many of them quite fast...
I completely agree. The key to success here is, in my opinion, to provide ready-built and tested images on an automated base for certain hardware.
I fully agree.
Unlike normal userspace programs or even kernels, recovering from a bad bios can be quite some work. How do we overcome this? Not everyone is going to buy a galep iv for 400$, nor a bios savior for 30.
Here's what I did:
I created a backup BIOS image of the BIOS on my test machine; then I got a few chips of the same size/type. I wrote the original image to 1-2 of the chips (all with Uniflash), so I had 3 identical, working proprietary BIOS chips (just in case) and put them in a drawer. Of course, I tested them all.
So from now on I can easily just write/overwrite all other chips, because I always have a few backup chips I can use if something goes wrong.
Mabye a "How to recover" section in the wiki would be nice...
- Create pressure on those companies which do not give out datasheets for various hardware parts. This is much easier if 1) is successful and many people/customers demand LinuxBIOS support.
what do you mean by pressure?
Peaceful, non-violent pressure, of course ;-)
The "damn, today there were another 14 customers calling our help-desk and asking for LinuxBIOS support, maybe we should give out specs, after all"-type of pressure.
Uwe.
* Uwe Hermann uwe@hermann-uwe.de [060901 00:24]:
what do you mean by pressure?
Peaceful, non-violent pressure, of course ;-)
The "damn, today there were another 14 customers calling our help-desk and asking for LinuxBIOS support, maybe we should give out specs, after all"-type of pressure.
Usually if you come with a big enough number, they will open the specs.
From what I experienced, 100 boards might not be enough for some of
them, 1000 boards probably is.
Maybe this is an area where the FSF could help to gain momentum? I got some pretty good contacts to some of the companies meanwhile, but most of our customers think 1000 boards is a whole lot.
Stefan
On Wed, Aug 30, 2006 at 02:37:59PM +0200, Uwe Hermann wrote:
Asking for help in the FSF campaign is definately a good idea, as it reaches quite a lot of people, I guess.
We're happy to help. Updating the campaign page is no problem; just let us know what you'd like to see there.
Thanks, Ward.
Ward Vandewege wrote:
On Wed, Aug 30, 2006 at 02:37:59PM +0200, Uwe Hermann wrote:
Asking for help in the FSF campaign is definately a good idea, as it reaches quite a lot of people, I guess.
We're happy to help. Updating the campaign page is no problem; just let us know what you'd like to see there.
I'm working on an updated text. Once it is finished (and has reached consensus here), I'll tell you about it.
Regards, Carl-Daniel
HI,
On Thu, Aug 31, 2006 at 04:33:11PM +0200, Carl-Daniel Hailfinger wrote:
I'm working on an updated text. Once it is finished (and has reached consensus here), I'll tell you about it.
Another very interesting issue is laptop support. I know about http://linuxbios.org/index.php/Laptop_survey but more information is surely helpful.
Uwe.
Uwe Hermann wrote:
On Thu, Aug 31, 2006 at 04:33:11PM +0200, Carl-Daniel Hailfinger wrote:
I'm working on an updated text. Once it is finished (and has reached consensus here), I'll tell you about it.
Another very interesting issue is laptop support. I know about http://linuxbios.org/index.php/Laptop_survey but more information is surely helpful.
I'd say we postpone laptop support until we have LinuxBIOS running on a few cheap mainboards because laptops present additional problems: * usually the flash chip is not socketed * video bios is tightly integrated * superios are different from what we know * most of the time, embedded controllers have to be initialized as well if you don't want to kill the hardware * wrong video initialization has the potential to kill the display
Stories about LinuxBIOS frying laptops are the worst we can get now, but if we are successful enough in the traditional PC market, maybe one laptop vendor will get interested, too. And with support from a manufacturer, porting is a lot easier.
Regards, Carl-Daniel
(not a troll)
What would be the selling point to the laptop maker of using LinuxBIOS?
Why would they want LinuxBIOS rather than buying (and modifying) a solution from a commercial BIOS company and their CPU/chipset(s) suppliers?
If you can answer this question in a way that would convince an MBA you might be able to persuade a maker to do this. If you can't give an argument that saves the company money I doubt you will get any traction.
As regards the "let's get it on cheaper motherboards" I agree entirely.
On Sep 2, 2006, at 12:16 PM, Carl-Daniel Hailfinger wrote:
Stories about LinuxBIOS frying laptops are the worst we can get now, but if we are successful enough in the traditional PC market, maybe one laptop vendor will get interested, too. And with support from a manufacturer, porting is a lot easier.
-- Kevin Purcell kevinpurcell@pobox.com
* Kevin Purcell kevinpurcell@pobox.com [060902 22:05]:
If you can answer this question in a way that would convince an MBA you might be able to persuade a maker to do this. If you can't give an argument that saves the company money I doubt you will get any traction.
This is easy: It makes costs more reliable as you have fixed one time development costs and no per motherboards license fee. In addition it is a lot cheaper that its competitors, if you look out there.
The fact that it is a technical superior product is of no interest to some MBAs so I do not mention this seperately in detail here ;-)
Stefan
On 9/3/06, Kevin Purcell kevinpurcell@pobox.com wrote:
(not a troll)
What would be the selling point to the laptop maker of using LinuxBIOS?
Why would they want LinuxBIOS rather than buying (and modifying) a solution from a commercial BIOS company and their CPU/chipset(s) suppliers?
many things that go beyond the bios. you cant make an argument with the bios alone. you have to show what an open bios would bring and actually link that to higher sales. for example if it allows ubiquitous computing where you would rather use your laptop instead of pen and paper then that would be convincing. instant accessibility is a very big thing now. imagine getting a phone call and your super compact laptop is off. you turn it on then wait for it to bootup. then you login and wait a little more. then you look for that text editor. then when you find it you double click on it. then you start typing notes on it then you need to look at contacts then you need to lookup your to do list. you would rather have a common low cost paper based organizer. now if your pc can bootup in 3 seconds that changes a whole lot of things. with software suspend you can have almost instant access to your apps. you can leave your whole office suite "running" all the time without killing your batteries. or burning your lap. now thats a convincing argument.
Hi,
On Sat, Sep 02, 2006 at 09:16:37PM +0200, Carl-Daniel Hailfinger wrote:
I'd say we postpone laptop support until we have LinuxBIOS running on
Yeah, that's probably a good idea (for the FSF campaign text).
a few cheap mainboards because laptops present additional problems:
- usually the flash chip is not socketed
Most probably, yes. Luckily I do have a working test-laptop which has the chip in a socket... More details in my other post...
- video bios is tightly integrated
- superios are different from what we know
Do you have more details? As far as I can see at least some seem to be very similar to non-laptop superios. If there's a datasheet it shouldn't be too hard to support them.
- most of the time, embedded controllers have to be initialized as well if you don't want to kill the hardware
- wrong video initialization has the potential to kill the display
Hm, that doesn't sound good. Which controllers in particular can become problem?
Stories about LinuxBIOS frying laptops are the worst we can get now,
ACK.
Uwe.
Arima has one Laptop with Nvidia CK804 chipset. That should be more easier, and I hope Arima could work it out to make it support LinuxBIOS.
YH
On 9/2/06, Uwe Hermann uwe@hermann-uwe.de wrote:
Hi,
On Sat, Sep 02, 2006 at 09:16:37PM +0200, Carl-Daniel Hailfinger wrote:
I'd say we postpone laptop support until we have LinuxBIOS running on
Yeah, that's probably a good idea (for the FSF campaign text).
a few cheap mainboards because laptops present additional problems:
- usually the flash chip is not socketed
Most probably, yes. Luckily I do have a working test-laptop which has the chip in a socket... More details in my other post...
- video bios is tightly integrated
- superios are different from what we know
Do you have more details? As far as I can see at least some seem to be very similar to non-laptop superios. If there's a datasheet it shouldn't be too hard to support them.
- most of the time, embedded controllers have to be initialized as well if you don't want to kill the hardware
- wrong video initialization has the potential to kill the display
Hm, that doesn't sound good. Which controllers in particular can become problem?
Stories about LinuxBIOS frying laptops are the worst we can get now,
ACK.
Uwe.
Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFE+holXdVoV3jWIbQRArT1AJ9Z+BuLxfSqz1UsJ1Uh6vgQeJsxBQCfQVUH xUcmYdBUYxjTjeFIQRLwboE= =H1LG -----END PGP SIGNATURE-----
-- linuxbios mailing list linuxbios@linuxbios.org http://www.openbios.org/mailman/listinfo/linuxbios
Uwe Hermann wrote:
- video bios is tightly integrated
- superios are different from what we know
Do you have more details? As far as I can see at least some seem to be very similar to non-laptop superios. If there's a datasheet it shouldn't be too hard to support them.
- most of the time, embedded controllers have to be initialized as well if you don't want to kill the hardware
- wrong video initialization has the potential to kill the display
Hm, that doesn't sound good. Which controllers in particular can become problem?
The Keyboard Scan/ Power Management Controllers are the non-standard parts of laptops.
Laptops use microcontrollers that do combined operations such as keyboard scan, Flash write enable, battery management, power management, lid open/close, power buttons etc.
These are the areas that we would need documentation for.
The chipset docs may all be available but not docs to the power management/keyboard scan controller firmware. The docs for the micros describe the general purpose micro itself, but that won't tell you how they are using all of its gpio pins and ports.
Bari
Carl-Daniel Hailfinger wrote:
I'd say we postpone laptop support until we have LinuxBIOS running on a few cheap mainboards because laptops present additional problems:
Carl-Daniel, as you well know, the laptop mass market came first with OLPC :-)
all we need to do is get quanta to well OLPC with adult-size keyboards :-)
ron
On 9/4/06, Ronald G Minnich rminnich@lanl.gov wrote:
Carl-Daniel Hailfinger wrote:
I'd say we postpone laptop support until we have LinuxBIOS running on a few cheap mainboards because laptops present additional problems:
Carl-Daniel, as you well know, the laptop mass market came first with OLPC :-)
all we need to do is get quanta to well OLPC with adult-size keyboards :-)
of course. that would be great!
Hi,
On Tue, Aug 29, 2006 at 11:31:23PM +0200, Stefan Reinauer wrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [060829 23:06]:
Yes, he is. This has the potential to get quite a lot of people started and getting any output at all is a major motivation factor even if the rest of the code for bringup has yet to be written.
That's a great idea! I figure it should be possible to create a repository of some sort which contains such ROM images. That eliminates the need to understand the build process and compile stuff, which will lower the entry bar for a few people and might get them interested in the project.
Definitely. Uwe, can you (or someone else) have a look what SuperIOs boards usually use, so we can try to support an as large as possible set of boards theoretically. (thinking mainstream)
Yes, that shouldn't be a problem for recent boards. We can just scan all major online computer stores for board names and then get the datasheets of the vendors; or simply visit the websites of the 10 biggest vendors or so and simply get _all_ their datasheets. Then we can do some statistics etc.
As for the Super IOs I'd use another approach; simply download all datasheets you can get your hands on and add support for the respective part (which is what I'm doing with the ITEs; when Im done I'll probably continue with Winbond).
Uwe.
* Uwe Hermann uwe@hermann-uwe.de [060830 14:24]:
Hi,
On Tue, Aug 29, 2006 at 11:31:23PM +0200, Stefan Reinauer wrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [060829 23:06]:
Yes, he is. This has the potential to get quite a lot of people started and getting any output at all is a major motivation factor even if the rest of the code for bringup has yet to be written.
That's a great idea! I figure it should be possible to create a repository of some sort which contains such ROM images. That eliminates the need to understand the build process and compile stuff, which will lower the entry bar for a few people and might get them interested in the project.
ok, lets think this further: You get a LinuxBIOS-string on serial and then you do _what_ with that image? Have a shell? Torsten Duwe's serial loader or llshell might be candidates here.
As for the Super IOs I'd use another approach; simply download all datasheets you can get your hands on and add support for the respective part (which is what I'm doing with the ITEs; when Im done I'll probably continue with Winbond).
After my last mail, thinking about it,... how many vendors are we talking about here,..? and how many chips per vendor? It might indeed be a pretty good idea to exhaust the space just to get some ground. SuperIOs age less than southbridges, do they?
Stefan
Stefan Reinauer wrote:
- Uwe Hermann uwe@hermann-uwe.de [060830 14:24]:
Hi,
On Tue, Aug 29, 2006 at 11:31:23PM +0200, Stefan Reinauer wrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [060829 23:06]:
Yes, he is. This has the potential to get quite a lot of people started and getting any output at all is a major motivation factor even if the rest of the code for bringup has yet to be written.
That's a great idea! I figure it should be possible to create a repository of some sort which contains such ROM images. That eliminates the need to understand the build process and compile stuff, which will lower the entry bar for a few people and might get them interested in the project.
ok, lets think this further: You get a LinuxBIOS-string on serial and then you do _what_ with that image? Have a shell? Torsten Duwe's serial loader or llshell might be candidates here.
Both won't help if RAM and CAR don't work yet. But the string alone should give us an idea the specific mainboard needs additional setup before it can speak to the SuperIO or not.
As for the Super IOs I'd use another approach; simply download all datasheets you can get your hands on and add support for the respective part (which is what I'm doing with the ITEs; when Im done I'll probably continue with Winbond).
After my last mail, thinking about it,... how many vendors are we talking about here,..? and how many chips per vendor? It might indeed be a pretty good idea to exhaust the space just to get some ground. SuperIOs age less than southbridges, do they?
We face various constraints here: * People are less likely to perform experiments with their newest machines * Supporting Intel will be a headache * flashrom should work on the systems we are targeting to eliminate the need for an EEPROM programmer * Some boards are shipped without serial port * we don't care which boards are/were best-sellers, we only care which boards we can find enough testers for
Considering these constraints, I suggest the following plan: * Call for action via FSF, point to <website with further instructions> * provide linuxbios-check .rpm/.deb/.tar.gz/ebuild with the following (half-)automated tests: - flashrom to find out on which boards we can flash the BIOS easily - sensors-detect for SuperIO detection - lspci -vvv - dmidecode - dmesg (or /var/log/boot.msg) - ask user whether he has a serial port onboard - ask user which parts of lspci are add-on cards - ask user for exact mainboard name - ask user for model of flash chip - ask user for SuperIO - upload results to <special address which feeds database> - if SuperIO or mainboard is known, offer ROM image for download * once we have a reasonable overview of people willing to test and their respective boards, we can decide which boards to attack first * after we have support for the first mass-marketed board, make sure to spread the word (and make people with unsupported boards envious)
Once I find some time, I'll implement the plan.
What do you think?
Regards, Carl-Daniel
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [060830 18:17]:
ok, lets think this further: You get a LinuxBIOS-string on serial and then you do _what_ with that image? Have a shell? Torsten Duwe's serial loader or llshell might be candidates here.
Both won't help if RAM and CAR don't work yet. But the string alone should give us an idea the specific mainboard needs additional setup before it can speak to the SuperIO or not.
llshell was known to work all within registers, so it needs no ram. the serial boot was at least partly written using romcc iirc.
We face various constraints here:
- People are less likely to perform experiments with their newest machines
While we only care for exactly those because of the costs and time involved in supporting a system
- flashrom should work on the systems we are targeting to eliminate the need for an EEPROM programmer
This works on quite some systems that do not require special GPIO sequences.
- Some boards are shipped without serial port
which reminds me.. we purchased a net20dc usb debug device, but I did not get to write example code for any side of the debug connection. I hope to find an opportunity after my current project. Or maybe one of the USB adept experts in here can jump in?
- we don't care which boards are/were best-sellers, we only care which boards we can find enough testers for
Not all the way down. The boards that are supported in LinuxBIOS usually are supported because there was a use case for one of the contributors to do so. See the OLPC, or the machines that were supported because LANL built clusters with that hardware.
Considering these constraints, I suggest the following plan:
- Call for action via FSF, point to <website with further instructions>
BTW, will someone from the FSF join the LinuxBIOS symposium 2006? I am still missing FSF names on the list!
- provide linuxbios-check .rpm/.deb/.tar.gz/ebuild with the following (half-)automated tests:
- flashrom to find out on which boards we can flash the BIOS easily
- sensors-detect for SuperIO detection
- lspci -vvv
- dmidecode
- dmesg (or /var/log/boot.msg)
- ask user whether he has a serial port onboard
- ask user which parts of lspci are add-on cards
- ask user for exact mainboard name
- ask user for model of flash chip
- ask user for SuperIO
- upload results to <special address which feeds database>
- if SuperIO or mainboard is known, offer ROM image for download
can you set something up for this? I can create a database on linuxbios.org and also create a repository to check in the code and optimize it.
The SuperIO can also be auto detected. I think I saw the code for this somewhere.
- after we have support for the first mass-marketed board, make sure to spread the word (and make people with unsupported boards envious)
there is plenty of support for "mass-marketed boards" already, or do I get you wrong? Epia is among them. All the Tyan boards..
Once I find some time, I'll implement the plan.
Let me know when you do so, we can probably coordinate.
Stefan Reinauer wrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [060830 18:17]:
there is plenty of support for "mass-marketed boards" already, or do I get you wrong? Epia is among them. All the Tyan boards..
Ah sorry, wrong wording. "Sold in masses to Linux users" would have described it better. That unfortunately excludes both Tyan and Via Epia.
Once I find some time, I'll implement the plan.
Let me know when you do so, we can probably coordinate.
Will do so.
Regards, Carl-Daniel
Stefan Reinauer wrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [060830 18:17]:
We face various constraints here:
- People are less likely to perform experiments with their newest machines
While we only care for exactly those because of the costs and time involved in supporting a system
That's the question. Do we want to continue supporting highly expensive boards like Tyan where hardly anyone will sacrifice a system to LinuxBIOS testing or do we want to reach the masses. For the masses, anything less than *perfect* support for the machine they use daily is unacceptable. And we will probably not reach good support of a board until long after the board is out of production, bringing us back to square one. Just look at how many people use binary-only drivers to get a bit more performance on their machines for daily use even if free drivers exist.
I'm for supporting slightly outdated systems (like AMD Socket 754/939) and against putting any effort into the latest and greatest.
- flashrom should work on the systems we are targeting to eliminate the need for an EEPROM programmer
- provide linuxbios-check .rpm/.deb/.tar.gz/ebuild with the following (half-)automated tests:
- sensors-detect for SuperIO detection
The SuperIO can also be auto detected. I think I saw the code for this somewhere.
You mean, a different method than probing SMBus?
Regards, Carl-Daniel
On Thu, Aug 31, 2006 at 01:51:23AM +0200, Carl-Daniel Hailfinger wrote:
That's the question. Do we want to continue supporting highly expensive boards like Tyan where hardly anyone will sacrifice a system to LinuxBIOS testing or do we want to reach the masses.
Ideally, both. I guess the corporate contributors will continue to (mainly) support boards they have use-cases for (which makes sense from an economical point of view).
For cheap, old, or mainstream boards you can buy in your favorite computer shop, ebay etc. random interested contributors/coders are important, IMHO. Given enough such contributors and enough popularity of the project among hacker-type Free Software users/programmers it won't take too long to have support for a good bunch of popular boards.
I'm for supporting slightly outdated systems (like AMD Socket 754/939) and against putting any effort into the latest and greatest.
ACK. Although I don't think putting effort into "the latest and greatest" is a problem, it's just that the older stuff should be worked on, too.
Uwe.
* Uwe Hermann uwe@hermann-uwe.de [060901 00:11]:
Ideally, both. I guess the corporate contributors will continue to (mainly) support boards they have use-cases for (which makes sense from an economical point of view).
For cheap, old, or mainstream boards you can buy in your favorite computer shop, ebay etc. random interested contributors/coders are important, IMHO. Given enough such contributors and enough popularity of the project among hacker-type Free Software users/programmers it won't take too long to have support for a good bunch of popular boards.
time is playing with us. The north and south bridges that are expensive, fast and modern today will be old and cheap tomorrow, so when K8 et al see a successor, we might automatically our potential userbase might automatically become broader.
Notice that at the moment on K8 all server chipsets are supported but none of the consumer chipsets (Via, ATI, some NVidia hw).
ACK. Although I don't think putting effort into "the latest and greatest" is a problem, it's just that the older stuff should be worked on, too.
In the old Amiga games scene there is a concept called abandonware. If the technology does not make a "unique selling point" for the vendor anymore, it is released to the public for the sake of the community.
Is this a concept that hw vendors on this list could life with?
Regards, Stefan
Hi,
On Tue, Aug 29, 2006 at 12:46:51PM -0500, Bari Ari wrote:
Are you working on the support for these devices by just using the data sheets and without hardware to test this?
Yes, exactly. I decided to just add support for _all_ ITE Super IOs for which I'm able to find datasheets.
Uwe.
-
Bari Ari -
Carl-Daniel Hailfinger -
Kevin Purcell -
Richard Smith -
Rogelio Serrano -
Ronald G Minnich -
Stefan Reinauer -
Uwe Hermann -
Ward Vandewege -
yhlu