Hi,
since we're aiming for broader coverage in LinuxBIOS and related tools, I think we should publish a "Call for Action" which urges interested people to give us dumps of their board configuration etc.
Example of such a call (for flashrom only, though): http://lists.us.dell.com/pipermail/firmware-tools-devel/2007-August/000121.h...
Right now, I'd like to get a list of stuff we potentially could use:
- flashrom -V - lspci -nvx - dmidecode - probe_superio - /proc/interrupts? - board name/model
Comments?
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
Hi,
since we're aiming for broader coverage in LinuxBIOS and related tools, I think we should publish a "Call for Action" which urges interested people to give us dumps of their board configuration etc.
We had such calls before, and people would send in their board information, assuming that this would be enough for us to support their hardware. Unfortunately not a single new port resulted from this, though many people participated and lots of (unaccomplished) expectations were created. So I carefully wonder what the real goal of such a call would be, except gathering random people with random boards? Something like: We have 10 people who are willing to work on this or that mainboard if you get them a system they can keep for doing the work, given that the northbridge and southbridge are already supported... Other ideas?
Stefan
Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
Hi,
since we're aiming for broader coverage in LinuxBIOS and related tools, I think we should publish a "Call for Action" which urges interested people to give us dumps of their board configuration etc.
We had such calls before, and people would send in their board information, assuming that this would be enough for us to support their hardware. Unfortunately not a single new port resulted from this, though many people participated and lots of (unaccomplished) expectations were created. So I carefully wonder what the real goal of such a call would be, except gathering random people with random boards?
Well, that's how I found this place, and that resulted in one port (so far) :) But I can very clearly see your point.
Something like: We have 10 people who are willing to work on this or that mainboard if you get them a system they can keep for doing the work, given that the northbridge and southbridge are already supported... Other ideas?
Stefan
This is a very interesting idea. Once I can get my ******* laptop fixed and wrap up the cn700 board, I'd love to do a port for Via's new pico-itx board, but I have no real incentive (or money) to purchase the hardware. Yes it's an unsupported chipset, but it should be similar enough to the cn700 that I should be able to work with it.
-Corey
On Mon, Aug 27, 2007 at 05:21:08PM -0500, Corey Osgood wrote:
We had such calls before, and people would send in their board information, assuming that this would be enough for us to support their hardware. Unfortunately not a single new port resulted from this, though many people participated and lots of (unaccomplished) expectations were created. So I carefully wonder what the real goal of such a call would be, except gathering random people with random boards?
Well, that's how I found this place, and that resulted in one port (so far) :) But I can very clearly see your point.
What exactly lead you to this project? That would be interesting to analyze...
My feeling is that a "post your lspci" call for action will result in lots of lspci's (which is totally useless) and we'll have to tell all those people "no, your board/chipset is not yet supported". That sucks, and there's really no gain in doing that.
Now, what I think would indeed be useful is a Call For Developers. Because that's what we really need, more developers, more man-power to actually write code to support new chipsets. Random lspci's from random people don't help at all. We've had tons of those already and they all end up with "no, it's not supported" answers.
Something like: We have 10 people who are willing to work on this or that mainboard if you get them a system they can keep for doing the work, given that the northbridge and southbridge are already supported... Other ideas?
Won't help either. The number of active developers doing new ports is way less than 10 anyway. Personally I have at least 4-5 board sitting here which should be relatively easy to support, I'm just lacking the required spare time.
We need more developers and/or more time.
I don't think money is a problem in most cases (if it is we can probably arrange for some hardware shipping or ask for donations or something).
The real problems (in my view) are:
1. Lack of developers 2. Lack of time 3. Lack of proper datasheets (for some/many chipsets)
Issue 2 cannot be solved easily, issue 3 depends on many factors we usually cannot influence a lot, but issue 1 is where we can get the biggest gain, IMHO.
Now, the more important question is _how_ we lure more developers into contributing to LinuxBIOS. What we need is the low-level hardware guys, so Linux or FreeBSD or whatever kernel hackers are good candidates, I guess.
This is a very interesting idea. Once I can get my ******* laptop fixed and wrap up the cn700 board, I'd love to do a port for Via's new pico-itx board, but I have no real incentive (or money) to purchase the hardware. Yes it's an unsupported chipset, but it should be similar enough to the cn700 that I should be able to work with it.
That would be great, indeed! Do you think you can get the respective datasheets from VIA without a "business case"?
Uwe.
Uwe Hermann wrote:
The real problems (in my view) are:
- Lack of developers
- Lack of time
- Lack of proper datasheets (for some/many chipsets)
I agree, but would add that #1 has a correlation to #3. I tried porting a board over waaay back in the v1 days. With the limited information I had because of #3, it never became a success. I've stayed on the list because I'm quite interested in this area, but without proper #3, I'm at a real loss as to how to proceed on any project, as I don't fully understand some of what is going on the lack of #3 is meaning that I can't actually be a developer most of the time.
Quoting "Nathanael D. Noblet" nathanael@gnat.ca:
Uwe Hermann wrote:
The real problems (in my view) are:
- Lack of developers
- Lack of time
- Lack of proper datasheets (for some/many chipsets)
I agree, but would add that #1 has a correlation to #3. I tried porting a board over waaay back in the v1 days. With the limited information I had because of #3, it never became a success. I've stayed on the list because I'm quite interested in this area, but without proper #3, I'm at a real loss as to how to proceed on any project, as I don't fully understand some of what is going on the lack of #3 is meaning that I can't actually be a developer most of the time.
--
For me #2 is my main issue. Work & Family don't leave much time for LB:-( If only there were 48 hours in the day I would spend the extra 24 just on LB!!
Thanks - Joe
Joseph Smith wrote:
Quoting "Nathanael D. Noblet" nathanael@gnat.ca:
Uwe Hermann wrote:
The real problems (in my view) are:
- Lack of developers
- Lack of time
- Lack of proper datasheets (for some/many chipsets)
I agree, but would add that #1 has a correlation to #3. I tried porting a board over waaay back in the v1 days. With the limited information I had because of #3, it never became a success. I've stayed on the list because I'm quite interested in this area, but without proper #3, I'm at a real loss as to how to proceed on any project, as I don't fully understand some of what is going on the lack of #3 is meaning that I can't actually be a developer most of the time.
--
For me #2 is my main issue. Work & Family don't leave much time for LB:-( If only there were 48 hours in the day I would spend the extra 24 just on LB!!
Thanks - Joe
I know the feeling. And it seems like every time I do have some time to work on things, something else comes up, or some piece of hardware fails. But 3 is also a huge issue as well, most of these companies aren't willing to hand out their datasheets to any old joe, especially not to be used in an open source project. Of course, more devs is always a desire in just about any project. Here, I don't think we could have enough devs to keep up with all the new hardware that's coming out, it seems like by the time a chipset is supported it's nearly obsolete.
-Corey
What i really don't get is: Why trying to support bleeding edge hardware almost nobody has datasheets for instead of writing reliable custom drivers that would support older hardware. development itself would be far easier, at least SOME hardware would be supported and people would be able to TEST linuxbios on old hardware without fearing to ruin an expensive mainboard. most of the drivers written only include a working version which is far away from a full featured support that would make a difference to the original bios versions. this is imho what drives users away.
i'm willing to write more generic full featured drivers (northbridge/southbridge) for older chipsets (i posted a list and i'll stick to that list). my problem is not that i don't understand the hardware itself but the linuxbios framework. i don't want to spend hours of code surfing just to understand how and where certain code sniplets are called or how certain config files need to be written. a documentation to the code is close to non-existant. while this might not be a problem to long-term developers it drives new ones away.
what i would like to see is: generic support for usb/cdrom boot, ide support in southbridges, an onscreen menu (nothing fancy) and a far better documentation for users and developers. Holger
Quoting popkonserve popkonserve@gmx.de:
What i really don't get is: Why trying to support bleeding edge hardware almost nobody has datasheets for instead of writing reliable custom drivers that would support older hardware. development itself would be far easier, at least SOME hardware would be supported and people would be able to TEST linuxbios on old hardware without fearing to ruin an expensive mainboard. most of the drivers written only include a working version which is far away from a full featured support that would make a difference to the original bios versions. this is imho what drives users away.
i'm willing to write more generic full featured drivers (northbridge/southbridge) for older chipsets (i posted a list and i'll stick to that list). my problem is not that i don't understand the hardware itself but the linuxbios framework. i don't want to spend hours of code surfing just to understand how and where certain code sniplets are called or how certain config files need to be written. a documentation to the code is close to non-existant. while this might not be a problem to long-term developers it drives new ones away.
what i would like to see is: generic support for usb/cdrom boot, ide support in southbridges, an onscreen menu (nothing fancy) and a far better documentation for users and developers. Holger
I would have to agree, When I first commited to LB I was quite scared due to the lack of documentation.
Thanks - Joe
* Joseph Smith joe@smittys.pointclark.net [070828 21:01]:
I would have to agree, When I first commited to LB I was quite scared due to the lack of documentation.
We hear that very often (and I keep repeating it, too)
But what documentation are you missing in the Wiki?
Have you documented the questions you had after finding out what it was, for those coming after you?
Stefan
Quoting Stefan Reinauer stepan@coresystems.de:
- Joseph Smith joe@smittys.pointclark.net [070828 21:01]:
I would have to agree, When I first commited to LB I was quite scared due to the lack of documentation.
We hear that very often (and I keep repeating it, too)
But what documentation are you missing in the Wiki?
Have you documented the questions you had after finding out what it was, for those coming after you?
Stefan, that's a little harsh. I think the Wiki is great. As for questions, most of my questions have been about "C" and hardware registers so I don't really know how I would impliment that into the Wiki? I guess it just took me a little while to get onboard on how to get started developing LB for a new board. If anything, the mailing list has been a great source for me. I have learned a ton from it:-)
Thanks - Joe
For v3, there is a lyx document I am trying to keep up to date. It's a lot of work, but it's better than what we had before (nothing).
ron
On Tue, Aug 28, 2007 at 08:59:53PM +0200, popkonserve wrote:
Why trying to support bleeding edge hardware
News value.
my problem is not that i don't understand the hardware itself but the linuxbios framework.
You are not alone.
what i would like to see is: generic support for usb/cdrom boot,
The job of FILO / GRUB2. USB is so-so in FILO - don't know about USB in GRUB2. Patrick, do you know?
ide support in southbridges,
Sure - but isn't this usually there?
an onscreen menu (nothing fancy)
Uwe's lbmenu payload for v3 will be a big hit.
and a far better documentation for users and developers.
Yep. We tried to improve both usability and developability in v3 and I think it is a big improvement over v2.
//Peter
* Peter Stuge peter@stuge.se [070829 07:31]:
On Tue, Aug 28, 2007 at 08:59:53PM +0200, popkonserve wrote:
Why trying to support bleeding edge hardware
News value.
and redemption of time investments
what i would like to see is: generic support for usb/cdrom boot,
The job of FILO / GRUB2. USB is so-so in FILO - don't know about USB in GRUB2. Patrick, do you know?
There is no USB stack, but I am sure the FILO USB stack can easily be ported.
Stefan
* popkonserve popkonserve@gmx.de [070828 20:59]:
Why trying to support bleeding edge hardware almost nobody has datasheets for instead of writing reliable custom drivers that would support older hardware.
It takes round about 6-8 weeks to port LinuxBIOS to a completely new system with new northbridge, southbridge, superio, mainboard.
This is a lot of time, and most ports that actually happen are done because there is some interest in using a large number of that hardware.
For hobbyist ports, you can boot a single machine a lot of times before those 5s you safe make up for the 6 weeks you have to put in before it works.
So most ports have been commercially used in some product, and nobody planning to use LinuxBIOS today in a product will plan to use hardware that you can not buy anymore (ie. a mainboard older than a year).
i'm willing to write more generic full featured drivers (northbridge/southbridge) for older chipsets (i posted a list and i'll stick to that list).
This is great!
my problem is not that i don't understand the hardware itself but the linuxbios framework. i don't want to spend hours of code surfing just to understand how and where certain code sniplets are called or how certain config files need to be written.
I want to invite you to help us work on v3 then. The framework got a lot simpler.
a documentation to the code is close to non-existant. while this might not be a problem to long-term developers it drives new ones away.
For understanding the code, this one has generally been pretty useful.
http://qa.linuxbios.org/docs/doxygen/
what i would like to see is: generic support for usb/cdrom boot,
FILO (soon grub2) should do this.
ide support in southbridges
..?
an onscreen menu (nothing fancy)
lbmenu!
and a far better documentation for users and developers.
I think the big problem here is that as soon as people understand the code they are too busy to document it ;) I want to give this request back. Please, if you have a specific question about the code, do document it. Ask it on the list and document the answer in a way that others don't have to ask again.
The mailing list contains 70% or more of our knowledge, the rest is stored in the Wiki.
And we really want to improve.
Stefan
popkonserve wrote:
What i really don't get is: Why trying to support bleeding edge hardware almost nobody has datasheets for instead of writing reliable custom drivers that would support older hardware. development itself would be far easier, at least SOME hardware would be supported and people would be able to TEST linuxbios on old hardware without fearing to ruin an expensive mainboard. most of the drivers written only include a working version which is far away from a full featured support that would make a difference to the original bios versions. this is imho what drives users away.
i'm willing to write more generic full featured drivers (northbridge/southbridge) for older chipsets (i posted a list and i'll stick to that list).
I think there should be some limits to what hardware we try to support. I don't think we should be trying to support socket 7 hardware (which iirc were all the chipsets you named), because for the most part those PCs have either outlived their usefulness, or have done their job for so many years now nobody wants to mess with it. I know that all my pre-pentium 2 stuff hit the garbage bin a long time ago, simply because I had no use for it and couldn't even give it away. That's not to say your work is useless, it could be applied for sdram parts that lack spd. Personally, I think P3 and k7 on up would be the best targets as far as older hardware goes, they're still dirt cheap but do have some life left in them.
If anyone wants some hardware to toy with, I've got a few older boards that I keep saying I'll get to but probably never will. If someone has the time, they're welcome to them, here's a list (although I may have more if I go digging):
Intel D815EEA: i815/i81801ba (socket 370) - not sure if it still works, need to check it out first. southbridge supported, north not. Soldered on PLCC flash! Socket included, just needs to be put on the board. FIC SD11: amd651?/vt82c686a (slot a) - serial output working with current vt82c686_early_serial.c, nothing more Asus P2-99: i440zx/i82371eb (slot 1) - sort of works with i440bx, will also send some code that was a start at spd support, but too much for romcc. Also includes the necessary 440zx change(s)
All these boards have CPUs and a stick of whatever ram I can find (probably 32 or 64mb) if you need it, all use regular sdram. If you're lucky, there might be a spare bios chip included as well. If you need anything else, power supply, hard drive, video card, etc, let me know and I'll see what I can dig up. Yes, this is a hardware donation, on the condition that you at least attempt to get LinuxBIOSv2 (or v3) working on the board, that's the only reason I've kept most of these myself. If you just give up and decide to throw it away, please send it back, but if you get it working and have a use for it, it's yours. I have the docs to both north and south bridge for all these boards, if they're not readily available I'll send them as well, and IIRC all the Super I/Os are supported. This is mainly aimed at US folks, anywhere else it'd probably be cheaper to get something off ebay than ship. Email me privately if you're interested.
my problem is not that i don't understand the hardware itself but the linuxbios framework. i don't want to spend hours of code surfing just to understand how and where certain code sniplets are called or how certain config files need to be written. a documentation to the code is close to non-existant. while this might not be a problem to long-term developers it drives new ones away.
Agreed, I've been frustrated with this as well, even today. v3 should have better documentation, but we still need to bring up to par the documentation on some of the tools.
what i would like to see is: generic support for usb/cdrom boot,
FILO can already do usb/el torito cdrom boot, but it badly needs ehci support.
ide support in southbridges,
Explain please? Where's IDE support lacking?
-Corey
* Corey Osgood corey.osgood@gmail.com [070829 09:43]:
I think there should be some limits to what hardware we try to support. I don't think we should be trying to support socket 7 hardware (which iirc were all the chipsets you named), because for the most part those PCs have either outlived their usefulness, or have done their job for so many years now nobody wants to mess with it.
If volunteers want to work on vintage hardware, lets not keep them from doing so.
I personally think we need to support more newer hardware in shorter time to gain the momentum so LinuxBIOS can become the default firmware on new mainboards that you buy. We can make this goal, and it has been done in some cases. It's just a long way, as it was for Linux, too.
Supporting old hardware of course has an academical value ;)
hardware itself but the linuxbios framework. i don't want to spend hours of code surfing just to understand how and where certain code sniplets are called or how certain config files need to be written. a documentation to the code is close to non-existant. while this might not be a problem to long-term developers it drives new ones away.
Agreed, I've been frustrated with this as well, even today. v3 should have better documentation, but we still need to bring up to par the documentation on some of the tools.
Again,... Since you still remember _what_ you have been missing and how it works now, please try to provide the missing pieces before you get code blind.
Stefan
Quoting Stefan Reinauer stepan@coresystems.de:
I personally think we need to support more newer hardware in shorter time to gain the momentum so LinuxBIOS can become the default firmware on new mainboards that you buy. We can make this goal, and it has been done in some cases. It's just a long way, as it was for Linux, too.
That would be _REALLY_ great but is this realistic?..
Also, an interesting statement, that I found in one of the Trusted Computing Group specifications (https://www.trustedcomputinggroup.org/groups/pc_client/TCG_PCSpecificSpecifi...): on page 13 one can read : "The Manufacturer MUST control the update, modification, and maintenance of the BIOS Boot Block component, while either the Manufacturer or a 3rd party supplier may update, modify, or maintain the POST BIOS component. If there are multiple execution points for the BIOS Boot Block, they must all be within the CRTM." or "The Manufacturer MUST control the update, modification, and maintenance of the entire BIOS". Maybe this is sligtly off topic here (and a little bit paranoid..), but when one consider the fact that "trusted computing" becomes more and more prevalent in new systems (mandatory soon maybe?!), doesn't this outright kill the LB project?
Florentin Demetrescu
* echelon@free.fr echelon@free.fr [070829 11:39]:
Quoting Stefan Reinauer stepan@coresystems.de:
I personally think we need to support more newer hardware in shorter time to gain the momentum so LinuxBIOS can become the default firmware on new mainboards that you buy. We can make this goal, and it has been done in some cases. It's just a long way, as it was for Linux, too.
That would be _REALLY_ great but is this realistic?..
It is the only realistic scenario for LinuxBIOS becoming wide-spread and, no doubt, we have been pretty successful so far. More than one million computers out there are running LinuxBIOS. This is a far higher number than a usual charge of mainboards produced by a manufacturer in a series.
Unlike Linux, LinuxBIOS can not be "just tried with a live CD" or something. So either it gets pre-installed or it will be something only technically skilled people will ever use.
Maybe this is sligtly off topic here (and a little bit paranoid..), but when one consider the fact that "trusted computing" becomes more and more prevalent in new systems (mandatory soon maybe?!), doesn't this outright kill the LB project?
The opposite is the case. LinuxBIOS is the _only_ chance out there that allows controlling the restrictions. It does not restrict the vendor in controlling the "bootblock" -- Since there is no such thing as the bootblock in LinuxBIOSv2, I wonder what the technical meaning of that part of the specification is supposed to be.
Stefan
Quoting Stefan Reinauer stepan@coresystems.de:
The opposite is the case. LinuxBIOS is the _only_ chance out there that allows controlling the restrictions. It does not restrict the vendor in controlling the "bootblock" -- Since there is no such thing as the bootblock in LinuxBIOSv2, I wonder what the technical meaning of that part of the specification is supposed to be.
The boot block is the "core root of trust for measurements", i.e. it is supposed to do integrity measurement on the next module in the bootchain (that would be LinuxBIOS in this scheme..). This "measurement" (an integrity hash like SHA1) would be stored in one of the protected registers of the TPM. Now a question arises : would the "bootblock" transfer the control to LinuxBIOS if the hash does not match a value "hardwired" by the manufacturer? (the decision will be taken by the CRTM (the bootblock) not by the TPM which is (for the moment) passive) Indeed, I agree, this scheme does not preclude the use of LinuxBIOS .. as a step 2 into the boot chain, but what will happen when one will need to upgrade/update the installed version of LinuxBIOS? In other words, no one other that the manufacturer will be able to install LinuxBIOS and IMHO we will unfortunately lose a great advantage of LinuxBIOS which is his flexibility/customizability..
Florentin
On Wed, Aug 29, 2007 at 01:14:55PM +0200, echelon@free.fr wrote:
The boot block is the "core root of trust for measurements", i.e. it is supposed to do integrity measurement on the next module in the bootchain (that would be LinuxBIOS in this scheme..).
Not really? LB is the boot block, it's what runs after reset.
There has been discussion about support for TPM in LB for those that want or need it. I think that's a nice benefit to have.
//Peter
Stefan Reinauer wrote:
- Corey Osgood corey.osgood@gmail.com [070829 09:43]:
I think there should be some limits to what hardware we try to support. I don't think we should be trying to support socket 7 hardware (which iirc were all the chipsets you named), because for the most part those PCs have either outlived their usefulness, or have done their job for so many years now nobody wants to mess with it.
If volunteers want to work on vintage hardware, lets not keep them from doing so.
I personally think we need to support more newer hardware in shorter time to gain the momentum so LinuxBIOS can become the default firmware on new mainboards that you buy. We can make this goal, and it has been done in some cases. It's just a long way, as it was for Linux, too.
Supporting old hardware of course has an academical value ;)
I'd argue that the academic value is minimal without the hardware to actually test it on. It's not actually all that hard to write a port that compiles and looks valid. It's much harder to make one that actually works.
hardware itself but the linuxbios framework. i don't want to spend hours of code surfing just to understand how and where certain code sniplets are called or how certain config files need to be written. a documentation to the code is close to non-existant. while this might not be a problem to long-term developers it drives new ones away.
Agreed, I've been frustrated with this as well, even today. v3 should have better documentation, but we still need to bring up to par the documentation on some of the tools.
Again,... Since you still remember _what_ you have been missing and how it works now, please try to provide the missing pieces before you get code blind.
Stefan
I'm afraid I'm not quite sure what you mean?
-Corey
On Wed, Aug 29, 2007 at 01:26:15PM -0500, Corey Osgood wrote:
Supporting old hardware of course has an academical value ;)
Not purely academical! There are people out there who can/will use such hardware for cheap (home) servers and other stuff.
Also, there are several other reasons why support for old hardware is a good thing in general, for example to get more people to use LinuxBIOS (it's easier to use old hardware for testing and risk bricking it, than using your new and shiny work machine).
I'd argue that the academic value is minimal without the hardware to actually test it on. It's not actually all that hard to write a port that compiles and looks valid. It's much harder to make one that actually works.
Agreed. However, the good thing about old hardware is that it can be had very cheap from eBay and similar sources, so it's not that much of a problem...
Uwe.
* Corey Osgood corey.osgood@gmail.com [070829 20:26]:
Agreed, I've been frustrated with this as well, even today. v3 should have better documentation, but we still need to bring up to par the documentation on some of the tools.
Again,... Since you still remember _what_ you have been missing and how it works now, please try to provide the missing pieces before you get code blind.
I'm afraid I'm not quite sure what you mean?
The documentation. In the last 2 days I read about half a dozen mails about how bad the linuxbios documentation is. Looking at the code for some years now, many "old" contributors became "code blind", ie. used to the weird things.
For me it's easy to answer to an explicit question, but if you'd ask "explain linuxbios" I might just answer questions that you would have never asked and the other way around.
So not being "code blind" is very valuable for the project. Still seeing the problems that someone coming freshly to the code has is a great chance to really improve things for upcoming generations of linuxbios hackers.
Stefan
On 30.08.2007 00:34, Stefan Reinauer wrote:
- Corey Osgood corey.osgood@gmail.com [070829 20:26]:
The documentation. In the last 2 days I read about half a dozen mails about how bad the linuxbios documentation is. Looking at the code for some years now, many "old" contributors became "code blind", ie. used to the weird things.
We have to differentiate between v2 and v3. I still have not understood the inner workings of a v2 target nor do I know how to deal with all the necessary ld trickery. v3 has pretty good documentation, less scattered source files, no #include mess and is mostly easy to understand if you read the design documentation.
For me it's easy to answer to an explicit question, but if you'd ask "explain linuxbios" I might just answer questions that you would have never asked and the other way around.
"Explain ld trickery for adjusting LB to oayloads with different size." However, I'd prefer to never having to learn that and focus on lar and v3 instead.
So not being "code blind" is very valuable for the project. Still seeing the problems that someone coming freshly to the code has is a great chance to really improve things for upcoming generations of linuxbios hackers.
So far, any of my questions about v3 have been answered either by reading the design doc or the code comments. I have some minor corrections, but I'll send a patch for them.
For me, v3 is the future and also the only viable way to get new contributors. And v3 is so easy to extend. When I get some time, I'll add code to v3 which allows us to build generic ROMs. "Works anywhere."
Carl-Daniel
Stefan Reinauer wrote:
- Corey Osgood corey.osgood@gmail.com [070829 20:26]:
Agreed, I've been frustrated with this as well, even today. v3 should have better documentation, but we still need to bring up to par the documentation on some of the tools.
Again,... Since you still remember _what_ you have been missing and how it works now, please try to provide the missing pieces before you get code blind.
I'm afraid I'm not quite sure what you mean?
The documentation. In the last 2 days I read about half a dozen mails about how bad the linuxbios documentation is. Looking at the code for some years now, many "old" contributors became "code blind", ie. used to the weird things.
For me it's easy to answer to an explicit question, but if you'd ask "explain linuxbios" I might just answer questions that you would have never asked and the other way around.
So not being "code blind" is very valuable for the project. Still seeing the problems that someone coming freshly to the code has is a great chance to really improve things for upcoming generations of linuxbios hackers.
Stefan
Okay, but how/where should documentation be placed? I can place comments in the code that I write, but there's no guarantee that a new dev will find them. I can place comments with the functions, but again it requires digging around for them. doxygen is good in some ways, I've found but it only really helps if you can pinpoint a board that uses the function you want, and there's a comment to explain it. Perhaps some pages in the wiki documenting commonly used functions, or perhaps even on a per-file basis? For instance, something like this:
Title: Commonly used functions in LinuxBIOSv2 pre-ram init (auto.c, raminit.c, *early*.c)
Menu: lists/links function names
Functions: (example) pci_write_configX(a, b, c): brief description of what pci_write_configX() does, what parameters need to be passed and what format they're in, perhaps link to another explanation of "device_t dev"
Does this sound like what people want? So far the call for documentation has been clear, just it's unclear what is wanted and where.
-Corey
* Corey Osgood corey.osgood@gmail.com [070830 02:15]:
Okay, but how/where should documentation be placed? I can place comments in the code that I write, but there's no guarantee that a new dev will find them.
Generally, code comments should be doxygen style. This will make them appear in the code documentation on the web page.
Also, the Wiki is a good place for documentation.
digging around for them. doxygen is good in some ways, I've found but it only really helps if you can pinpoint a board that uses the function you want, and there's a comment to explain it.
The generated html documentation also has a search function.
What information are you missing from the doxygen docs? Maybe we can add them?
Perhaps some pages in the wiki documenting commonly used functions, or perhaps even on a per-file basis? For instance, something like this:
Hm... what about a "LinuxBIOSv2 internals" page with sub categories for each stage (preram init, linuxbios_ram.rom etc) and have other pages link to them.
Title: Commonly used functions in LinuxBIOSv2 pre-ram init (auto.c, raminit.c, *early*.c)
Menu: lists/links function names
Functions: (example) pci_write_configX(a, b, c): brief description of what pci_write_configX() does, what parameters need to be passed and what format they're in, perhaps link to another explanation of "device_t dev"
Does this sound like what people want? So far the call for documentation has been clear, just it's unclear what is wanted and where.
-Corey
On Wed, Aug 29, 2007 at 02:43:56AM -0500, Corey Osgood wrote:
I think there should be some limits to what hardware we try to support.
Yes and no. I think it's OK to draw a line where there would be a substantial loss because of legacy. CAR is one such thing. The gain from using CAR in v3 far outweighs supporting too-old CPUs IMO.
I don't think we should be trying to support socket 7 hardware because for the most part those PCs have either outlived their usefulness, or have done their job for so many years now nobody wants to mess with it.
I disagree strongly. There is definately a point in supporting older hardware as well, sometimes LB may even be the only way to utilize older hardware to the fullest, but all the other motivations mentioned in this thread apply too. (cheap, good for experimenting, no CPU-monsters but maybe enough for simpler applications)
v3 should have better documentation,
Better than v2? That's already in place. Check out newboot.lyx. (Or was it renamed?)
Better than present? Please help out!
what i would like to see is: generic support for usb/cdrom boot,
FILO can already do usb/el torito cdrom boot, but it badly needs ehci support.
The FILO USB stack is not completely robust as I've understood things. AFAIK it also only supports OHCI and neither UHCI nor the quite desirable EHCI.
//Peter
Peter Stuge peter@stuge.se skrev:
I disagree strongly. There is definately a point in supporting older hardware as well, sometimes LB may even be the only way to utilize older hardware to the fullest, but all the other motivations mentioned in this thread apply too. (cheap, good for experimenting, no CPU-monsters but maybe enough for simpler applications)
On the other hand, have a look at e.g. the Asus M2N-MX/DVI2. It's dirt cheap, a suitable processor can also be had at a very low price, also very cheap, vga is included, it even has dvi out. Total system price will be lower than an EPIA. And you can buy it in just about any shop, right now. Brand new. Imagine if that card could run LinuxBIOS. Now, how far from the mcp55 is the nforce 430? How much will the integrated vga complicate things that are not related to graphics?
/Rasmus
On Wed, Aug 29, 2007 at 10:33:34PM +0200, Rasmus Wiman wrote:
I disagree strongly. There is definately a point in supporting older hardware as well
On the other hand, have a look at e.g. the Asus M2N-MX/DVI2.
Some can not afford to pay anything for hardware. Or put another way, hardware that comes for free is always cheaper and often more attractive than hardware that has to be payed for - no matter how cheap the price.
I'm thinking recycling of older machines.
Now, how far from the mcp55 is the nforce 430?
I don't know. :\
How much will the integrated vga complicate things that are not related to graphics?
Oh, not very much.
//Peter
Peter Stuge peter@stuge.se skrev:
On Wed, Aug 29, 2007 at 10:33:34PM +0200, Rasmus Wiman wrote:
I disagree strongly. There is definately a point in supporting older hardware as well
On the other hand, have a look at e.g. the Asus M2N-MX/DVI2.
Some can not afford to pay anything for hardware. Or put another way, hardware that comes for free is always cheaper and often more attractive than hardware that has to be payed for - no matter how cheap the price.
I'm thinking recycling of older machines.
Certainly, (right now I can't afford any new hardware) but one problem with stuff that comes for free is you don't know what you get. Which means there has to be support for lots of old MB:s for there to be a decent chance that the stuff you actually get is supported. Sure, generic BX support is probably a very good thing since they were the best you could get during almost the entire PII/PIII era, so there are lots of them around.
But I still think stuff that's still being sold is a better bet. Even the cheapest modern hardware outperforms the PIII by far, and I know that I can get the stuff at once if I want it. I can get an M57-SLI-S4 tomorrow if I have the money. But there are motherboards that cost half as much, have integrated vga and even the price of mb plus cpu end up costing less than the mcp55 cards alone. Then you need a vga card in the MCP55.
/Rasmus
On Thu, Aug 30, 2007 at 12:08:30AM +0200, Rasmus Wiman wrote:
But I still think stuff that's still being sold is a better bet.
No bets. :)
I think everything will be supported, eventually. Meanwhile, all progress is good. Simple as that.
//Peter
Peter Stuge peter@stuge.se skrev:
On Thu, Aug 30, 2007 at 12:08:30AM +0200, Rasmus Wiman wrote:
But I still think stuff that's still being sold is a better bet.
No bets. :)
:)
I think everything will be supported, eventually. Meanwhile, all progress is good. Simple as that.
Certainly. And when I can afford it, I will buy a new MB with integrated vga, probably the one I think stands the best chance of getting supported. Right now I think that would mean NVidia or VIA, but I know rather little about it. If it never gets support, it will still be a perfectly usable computer. But my main motivation is that if there was a MB with a "Works with linuxbios" sticker on it, and it didn't cost too much I'd buy it.
/Rasmus
On Thu, Aug 30, 2007 at 12:28:23AM +0200, Rasmus Wiman wrote:
when I can afford it, I will buy a new MB with integrated vga, probably the one I think stands the best chance of getting supported. Right now I think that would mean NVidia or VIA, but I know rather little about it.
Aha! I think there is a slight misunderstanding.
"Integrated" graphics are not really any different from discrete graphics as far as LB is concerned. Neither better nor worse.
There are two graphics chips supported natively in LB, they are the ATI Rage XL and the Trident Blade3d. I've only heard the former confirmed working.
Luc has generously offered to also add support for the VIA Unichrome graphics hardware when he finds the free time.
Rage XL is discrete, as is Blade3d. Unichrome is built-into the CLE266.
But my main motivation is that if there was a MB with a "Works with linuxbios" sticker on it, and it didn't cost too much I'd buy it.
I'll say M57SLI.
//Peter
On Thu, Aug 30, 2007 at 12:39:25AM +0200, Peter Stuge wrote:
But my main motivation is that if there was a MB with a "Works with linuxbios" sticker on it, and it didn't cost too much I'd buy it.
I'll say M57SLI.
Just for the record; if you buy an M57SLI now, it's a new revision with SPI rom chip. The second position is still unpopulated, but the paths are now also SPI, no longer PLCC.
I have one of these at home :/
Thanks, Ward.
Ward Vandewege ward@gnu.org wrote:
Just for the record; if you buy an M57SLI now, it's a new revision with SPI rom chip. The second position is still unpopulated, but the paths are now also SPI, no longer PLCC.
I have one of these at home :/
I read about that, yes. What does it mean? Different sockets? No sockets at all? Impossible to flash?
/Rasmus
Rasmus Wiman wrote:
Ward Vandewege ward@gnu.org wrote:
Just for the record; if you buy an M57SLI now, it's a new revision with SPI rom chip. The second position is still unpopulated, but the paths are now also SPI, no longer PLCC.
I have one of these at home :/
I read about that, yes. What does it mean? Different sockets? No sockets at all? Impossible to flash?
/Rasmus
Same problem here, my M57SLI has been at the computer shop for over one week awaiting the modification.
They say the socket that I got is wrong, (PLCC32).
Will the SST 49LF040 be wrong too.
The BIOS chip is a tiny chip soldered on long legs, where the factory chip was.
Is the modification now wrong?
Chris Lingard
Hi Chris,
On Thu, Aug 30, 2007 at 12:35:47PM +0100, Chris Lingard wrote:
Same problem here, my M57SLI has been at the computer shop for over one week awaiting the modification.
They say the socket that I got is wrong, (PLCC32).
Will the SST 49LF040 be wrong too.
Most likely if your board is not plcc.
The BIOS chip is a tiny chip soldered on long legs, where the factory chip was.
Does it look like the picture under 'SPI' that I've just put on the M57SLIS4 wiki page?
Is the modification now wrong?
ST, can you chime in here?
Thanks, Ward.
Ward Vandewege wrote:
Hi Chris,
On Thu, Aug 30, 2007 at 12:35:47PM +0100, Chris Lingard wrote:
Same problem here, my M57SLI has been at the computer shop for over one week awaiting the modification.
They say the socket that I got is wrong, (PLCC32).
Will the SST 49LF040 be wrong too.
Most likely if your board is not plcc.
The BIOS chip is a tiny chip soldered on long legs, where the factory chip was.
Does it look like the picture under 'SPI' that I've just put on the M57SLIS4 wiki page?
Yes, though the BIOS chip looks much smaller, and its legs much longer, (the machine is away, so cannot access it, this is just from memory)
It is not the "other sort" (PLCC ?)
Many thanks
Chris Lingard
Is the modification now wrong?
ST, can you chime in here?
Thanks, Ward.
On Thu, Aug 30, 2007 at 08:09:20AM -0400, Ward Vandewege wrote:
On Thu, Aug 30, 2007 at 12:35:47PM +0100, Chris Lingard wrote:
They say the socket that I got is wrong, (PLCC32).
Will the SST 49LF040 be wrong too.
Most likely if your board is not plcc.
Yes - then neither socket nor flash chip can be mounted.
Is the modification now wrong?
ST, can you chime in here?
Hard to tell without testing. I could give it a go if I had a board. But, someone please send a high-res photo of this part of the board: http://stuge.se/m57sli_spi_mod_area.jpg so that we can have a look at the traces. Please take the photo from straight above the board so that the black PCIe sockets do not obscure any traces or components.
There is also the problem of documentation re. SPI flash programming at least on the MCP55; AFAIK there's only documentation for SPI flashing on Intel southbridges.
Once we figure out the hardware, it will still be neccessary to reboot into DOS/Windows to flash either chip. :(
Re sockets I haven't seen anything that would work well for SOIC. (SOIC and PLCC are packages, SPI and LPC the bus interface.)
One easy trick is to attach a clothespin-like clip (Pomona SOIC CLIP 5250) on top of the first flash chip and then connect different flash chips to that clip. This works if the soldered-on flash chip has a HOLD# pin, which seems to be common.
A problem with the clip is that it can come off by accident or worse have a glitch in the connection (unlikely, but still) which would cause the soldered-on chip to be overwritten by mistake and bricking the board if the BIOS image was bad. This can be worked around by flashing the factory BIOS onto the clip flash chip and then only working with LB using the soldered-on flash chip. :)
Connecting a second flash chip to the clip is very simple electrically, but a bit tricky mechanically since the upper contacts on the clip move when the clip is detached/attached. The most durable method would be AMPMODU contacts for the second row, but just soldering wires should work too. A small adapter board is needed for the SOIC flash chip as well, since the flash chip has .05" pin spacing while the test clip has .1" pin spacing. Either just strip board or a ready made SOIC adapter board such as the Sunhayato Corp PC BOARD ICB-010. (non-RoHS)
//Peter
On 01.09.2007 19:57, Peter Stuge wrote:
Once we figure out the hardware, it will still be neccessary to reboot into DOS/Windows to flash either chip. :(
SPI detection/flashing support is on my list. However, it won't get done in the next 3 weeks because I'm getting married next week and will be offline for a while.
Everyone can try the probe_superio patch for IT8716, though, and send dumps for proprietary and LinuxBIOS to the list. It would be nice if I had dumps for both types of M57SLI (SPI and PLCC) to be able to compare.
Carl-Daniel
On Sat, Sep 01, 2007 at 09:30:54PM +0200, Carl-Daniel Hailfinger wrote:
Once we figure out the hardware, it will still be neccessary to reboot into DOS/Windows to flash either chip. :(
SPI detection/flashing support is on my list.
Is the SPI flash connected to the sio on the m57sli?
However, it won't get done in the next 3 weeks because I'm getting married next week and will be offline for a while.
Congratulations! :)
Everyone can try the probe_superio patch for IT8716, though, and send dumps for proprietary and LinuxBIOS to the list. It would be nice if I had dumps for both types of M57SLI (SPI and PLCC) to be able to compare.
I doubt there's much difference. The 8716F datasheet is clear on the SPI stuff - but I didn't think that's where the flash chip was actually connected. Someone mentioned CK804. I guess I'm confusing things.
//Peter
On 01.09.2007 21:50, Peter Stuge wrote:
On Sat, Sep 01, 2007 at 09:30:54PM +0200, Carl-Daniel Hailfinger wrote:
Once we figure out the hardware, it will still be neccessary to reboot into DOS/Windows to flash either chip. :(
SPI detection/flashing support is on my list.
Is the SPI flash connected to the sio on the m57sli?
No idea.
However, it won't get done in the next 3 weeks because I'm getting married next week and will be offline for a while.
Congratulations! :)
Thanks!
Everyone can try the probe_superio patch for IT8716, though, and send dumps for proprietary and LinuxBIOS to the list. It would be nice if I had dumps for both types of M57SLI (SPI and PLCC) to be able to compare.
I doubt there's much difference. The 8716F datasheet is clear on the SPI stuff - but I didn't think that's where the flash chip was actually connected. Someone mentioned CK804. I guess I'm confusing things.
AFAIK CK804/MCP55 don't have SPI support. That's why the SuperI/O adds it.
Regards, Carl-Daniel
On Sat, Sep 01, 2007 at 10:13:21PM +0200, Carl-Daniel Hailfinger wrote:
SPI detection/flashing support is on my list.
Is the SPI flash connected to the sio on the m57sli?
No idea.
So we should find out.
Ward - do you have a continuity tester? Could you see if the SPI flash chip is connected to the Super IO?
If I get a high-res photo of the Super IO and the flash chip area I can mark the pins that should be connected on both to get a yes/no indication.
I didn't think that's where the flash chip was actually connected.
AFAIK CK804/MCP55 don't have SPI support. That's why the SuperI/O adds it.
Intel ICH has SPI, but maybe different for NVIDIA chipsets.
The logic design controlled by the boot-from-PCI jumper on the m57sli is less obvious with external SPI, but it's still entirely possible. I hope it is this simple! :)
//Peter
Quoting Peter Stuge peter@stuge.se:
On Sat, Sep 01, 2007 at 10:13:21PM +0200, Carl-Daniel Hailfinger wrote:
SPI detection/flashing support is on my list.
Is the SPI flash connected to the sio on the m57sli?
No idea.
So we should find out.
Ward - do you have a continuity tester? Could you see if the SPI flash chip is connected to the Super IO?
If I get a high-res photo of the Super IO and the flash chip area I can mark the pins that should be connected on both to get a yes/no indication.
Hi Peter,
The spi clock signal (SCK - pad 25 of the SIO) doesn't seem to be directly connected to the pad 6 of the bios spi chip.. One could think that there is a serial resistor between them (for signal integrity) but when I measure the resistance value between the 2 nodes I find values greater than 1 kohm.. I think that for the operating frequency (I measured 25 MHz for this signal with the scope on the bios chip pad), if there was a serial resistor it should had much a much lower value (maybe something like 50 ohm f.ex..) Please, someone with better electronics background can correct me if Im wrong on this topic? Also when studying the board with a powerfull magnifying glass around the sio chip, one can see that the trace starting on the pad 25 apparently ends with a unpopulated smt resistor (?) footprint. In fact, there is also a via connected to this signal, but here I have no way figuring where this signal go trough this via. (btw, as a joke, has someone here a good friend which is tooth physician or radiologist to do a X-ray radiography of this board? ;-) ) Now, back to my investigations.. Florentin
echelon@free.fr schrieb:
via. (btw, as a joke, has someone here a good friend which is tooth physician or radiologist to do a X-ray radiography of this board? ;-) )
OT : reverse engineering a 4+ layer pcb with a 2D X-ray may still be tricky. I wonder how it is being done professionally ?
8 pin SOIC socket ar ~ €30 compared with 2,5€ for a plcc32 socket, see
http://www.rsonline.de/cgi-bin/bv/rswww/searchBrowseAction.do?N=0&Ntk=I1...
On Mon, Sep 03, 2007 at 10:44:35PM +0200, Quux wrote:
OT : reverse engineering a 4+ layer pcb with a 2D X-ray may still be tricky. I wonder how it is being done professionally ?
Probably not at all. For testing the board is just put on a bed of nails..
8 pin SOIC socket ar ~ ?30 compared with 2,5? for a plcc32 socket
The problem is that no SOIC sockets have SOIC footprints. I've only found that for TSOP. (From Emulation Technology)
//Peter
On Sat, Sep 01, 2007 at 11:08:16PM +0200, Peter Stuge wrote:
On Sat, Sep 01, 2007 at 10:13:21PM +0200, Carl-Daniel Hailfinger wrote:
SPI detection/flashing support is on my list.
Is the SPI flash connected to the sio on the m57sli?
No idea.
So we should find out.
Ward - do you have a continuity tester?
I have a multimeter.
Could you see if the SPI flash chip is connected to the Super IO?
They are about 5 or 6 cm apart.
I took some additional pictures of the area between the superio and the soic chips. There's an unpopulated patch that is marked as 'SPI_EN' near the superio chip - not sure if that is related. Looks like it would fit a jumper or a 2 pin connector of some sort.
http://ward.vandewege.net/m57sli_soic_detail.jpg
http://ward.vandewege.net/dscn1656.jpg http://ward.vandewege.net/dscn1657.jpg http://ward.vandewege.net/dscn1658.jpg
If I get a high-res photo of the Super IO and the flash chip area I can mark the pins that should be connected on both to get a yes/no indication.
Yes please :) Let me know if the pictures suffice.
Thanks, Ward.
Hey!
On Sun, Sep 02, 2007 at 10:11:08AM -0400, Ward Vandewege wrote:
Ward - do you have a continuity tester?
I have a multimeter.
Great!
Could you see if the SPI flash chip is connected to the Super IO?
They are about 5 or 6 cm apart.
It's not really possible to tell from visual inspection. Maybe with some measurements.
I took some additional pictures of the area between the superio and the soic chips. There's an unpopulated patch that is marked as 'SPI_EN' near the superio chip - not sure if that is related. Looks like it would fit a jumper or a 2 pin connector of some sort.
Yep, that's a jumper all right. I wonder what it does. Maybe we'll find out.
http://ward.vandewege.net/m57sli_soic_detail.jpg
http://ward.vandewege.net/dscn1656.jpg http://ward.vandewege.net/dscn1657.jpg http://ward.vandewege.net/dscn1658.jpg
If I get a high-res photo of the Super IO and the flash chip area I can mark the pins that should be connected on both to get a yes/no indication.
Yes please :) Let me know if the pictures suffice.
Good photos!
I put some labels on interesting pads on the soic detail photo; available at: http://stuge.se/m57sli_soic_detail_labels.jpg
We want to investigate two things:
1. Dual flash chip mod on this board 2. What is driving the flash chip - super io or southbridge?
For 2 I need to put some labels on a super io photo, so let's start with 1. For the first iteration, please check:
* which signals are connected straight across between U5 and U9. (I suspect SI, SCLK, HOLD#, VCC, GND, WP# and maybe also SO are all connected across.)
* what Q4-1, Q5-1, R99-1 and R102-2 connects to on U5, if anything.
//Peter
Quoting Peter Stuge peter@stuge.se:
For 2 I need to put some labels on a super io photo, so let's start with 1. For the first iteration, please check:
- which signals are connected straight across between U5 and U9. (I
suspect SI, SCLK, HOLD#, VCC, GND, WP# and maybe also SO are all connected across.)
Agree! All of them are inter-connected btw the 2 locations. (only CS is not)
- what Q4-1, Q5-1, R99-1 and R102-2 connects to on U5, if anything.
Q4-1 -> U9-CS# Q5-1 -> U5-CS# R99-1 -> VCC R99-2 -> BIOS_WP-1 R102-2 -> ? (why does it matter?)
thus spoke my multimeter.. Florentin
----- Original Message ----- From: echelon@free.fr To: linuxbios@linuxbios.org Sent: Sunday, September 02, 2007 20:13 Subject: Re: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI)
Quoting Peter Stuge peter@stuge.se:
For 2 I need to put some labels on a super io photo, so let's start with 1. For the first iteration, please check:
- which signals are connected straight across between U5 and U9. (I
suspect SI, SCLK, HOLD#, VCC, GND, WP# and maybe also SO are all connected across.)
Agree! All of them are inter-connected btw the 2 locations. (only CS is not)
are you sure the HOLD pins are connected eg 0 Ohm ?
- what Q4-1, Q5-1, R99-1 and R102-2 connects to on U5, if anything.
Q4-1 -> U9-CS#
this seems to be conected to the unpopulated resistor R89 right? to what is the other pin of this resistor connected ? i would expect ground..
Q5-1 -> U5-CS#
can you find out to which (i think populated) resistor this also connects ? what is the value of this resistor (if you measure measure both 1->2 and 2->1) ? and to what is the other pin of this resistor connected i expect ground ..?
R99-1 -> VCC R99-2 -> BIOS_WP-1 R102-2 -> ? (why does it matter?)
it might be the write protect option on this board... can you find out if WP# of both chips is connected to some pin of (or around) BIOS_WP ?
thus spoke my multimeter.. Florentin
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Hmmm.. interesting findings I made!.. First of all I have to apologize because I have given some erroneous information in my previous posts.. Here we go:
Quoting Peter Stuge peter@stuge.se:
Could you see if the SPI flash chip is connected to the Super IO?
They are about 5 or 6 cm apart.
It's not really possible to tell from visual inspection. Maybe with some measurements.
Indeed it is!!! But NOT in the way this datasheet (http://www.ite.com.tw/product_info/file/pc/IT8716F_V0.3.zip) says! Here are the real connections I found on my board:
super_io-pad55 -> spi_chip-pad5 (SI) super_io-pad56 -> spi_chip-pad6 (SCK) super_io-pad60 -> spi_chip-pad2 (SO) super_io-pad61 -> spi_chip-pad1 (nCS)
nHOLD (pad 7 of spi chip) and nWP (pad 3 of spi chip) are not controlled at all by the super io chip!
I have a little question : does someone have a more up-to-date version of the DS of the it8716 chip? It seems to me that the version that can be currently downloaded on the ite website doesn't match at all the chip revision used on gigabyte mobo.. (regarding the electrical interface at least..)
Florentin
On Mon, Sep 03, 2007 at 01:43:27AM +0200, echelon@free.fr wrote:
Quoting Peter Stuge peter@stuge.se:
Could you see if the SPI flash chip is connected to the Super IO?
They are about 5 or 6 cm apart.
It's not really possible to tell from visual inspection. Maybe with some measurements.
Indeed it is!!! But NOT in the way this datasheet (http://www.ite.com.tw/product_info/file/pc/IT8716F_V0.3.zip) says! Here are the real connections I found on my board:
super_io-pad55 -> spi_chip-pad5 (SI) super_io-pad56 -> spi_chip-pad6 (SCK) super_io-pad60 -> spi_chip-pad2 (SO)
Good news. Then we can make flashrom work.
super_io-pad61 -> spi_chip-pad1 (nCS)
Is this a 0 ohm connection?
nHOLD (pad 7 of spi chip) and nWP (pad 3 of spi chip) are not controlled at all by the super io chip!
Correct.
U5-HOLD# and U9-HOLD# are pulled high by R84. U5-WP# and U9-WP# are pulled high by R128.
WP# can be pulled low using the BIOS_WP jumper, through R127 which I believe connects to R102-2.
So, about the CS# signals then.
If CS# is a direct connection I think U5-CS# and U9-CS# should be lifted from the board and pulled high independently, then a switch added which connects one chip's CS# pin back to the U5-CS# pad.
I have a little question : does someone have a more up-to-date version of the DS of the it8716 chip? It seems to me that the version that can be currently downloaded on the ite website doesn't match at all the chip revision used on gigabyte mobo.. (regarding the electrical interface at least..)
I can't find any other documentation than that either.
The M57SLI board with SOIC flash has a version C 8716, I guess they've changed the pinout.
--8<-- 0.3 data sheet cover page Please note that the IT8716F V0.3 is applicable to D version and future versions. -->8--
//Peter
Quoting Peter Stuge peter@stuge.se:
super_io-pad61 -> spi_chip-pad1 (nCS)
Is this a 0 ohm connection?
I think so.. (at least my multimeter in bip-bip mode shouts loud when I connect the 2 pads ;-) => that means <5ohms in general..)
I have a little question : does someone have a more up-to-date version of the DS of the it8716 chip? It seems to me that the version that can be currently downloaded on the ite website doesn't match at all the chip revision used on gigabyte mobo.. (regarding the electrical interface at least..)
I can't find any other documentation than that either.
The M57SLI board with SOIC flash has a version C 8716, I guess they've changed the pinout.
--8<-- 0.3 data sheet cover page Please note that the IT8716F V0.3 is applicable to D version and future versions. -->8--
This seems a little bit strange for me : the pinout of the C version seems to replace a floppy disk interface with the spi interface.. When one think that FD is considered "antiquated peripheral" and spi a "new paradigm" for bios storage, that would mean that ver. C is "more modern" that ver. D in its design?!.. Just my 2 (euro)cents Florentin
On 03.09.2007 11:04, echelon@free.fr wrote:
Quoting Peter Stuge peter@stuge.se:
I have a little question : does someone have a more up-to-date version of the DS of the it8716 chip? It seems to me that the version that can be currently downloaded on the ite website doesn't match at all the chip revision used on gigabyte mobo.. (regarding the electrical interface at least..)
I can't find any other documentation than that either.
The M57SLI board with SOIC flash has a version C 8716, I guess they've changed the pinout.
--8<-- 0.3 data sheet cover page Please note that the IT8716F V0.3 is applicable to D version and future versions. -->8--
This seems a little bit strange for me : the pinout of the C version seems to replace a floppy disk interface with the spi interface.. When one think that FD is considered "antiquated peripheral" and spi a "new paradigm" for bios storage, that would mean that ver. C is "more modern" that ver. D in its design?!..
OK, I have the 0.2 and 0.3 datasheet of IT8716F and I can't find any difference in interfaces between the datasheets. Please be more specific what you think has been replaced (including page numbers).
Carl-Daniel
again me ;) also when probing the 25 pad (SCK) of SIO with the scope, there doesn't seem to be electrical activity on this node (it stays tied @ 5V all the time..) also I have given an erroneous measure in my previous mail: the frequency of the spi clock is 16 MHz and not 25.. Florentin
Quoting Peter Stuge peter@stuge.se:
On Sat, Sep 01, 2007 at 10:13:21PM +0200, Carl-Daniel Hailfinger wrote:
SPI detection/flashing support is on my list.
Is the SPI flash connected to the sio on the m57sli?
No idea.
So we should find out.
Ward - do you have a continuity tester? Could you see if the SPI flash chip is connected to the Super IO?
If I get a high-res photo of the Super IO and the flash chip area I can mark the pins that should be connected on both to get a yes/no indication.
I didn't think that's where the flash chip was actually connected.
AFAIK CK804/MCP55 don't have SPI support. That's why the SuperI/O adds it.
Intel ICH has SPI, but maybe different for NVIDIA chipsets.
The logic design controlled by the boot-from-PCI jumper on the m57sli is less obvious with external SPI, but it's still entirely possible. I hope it is this simple! :)
//Peter
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
On Sat, Sep 01, 2007 at 09:30:54PM +0200, Carl-Daniel Hailfinger wrote:
On 01.09.2007 19:57, Peter Stuge wrote:
Once we figure out the hardware, it will still be neccessary to reboot into DOS/Windows to flash either chip. :(
SPI detection/flashing support is on my list. However, it won't get done in the next 3 weeks because I'm getting married next week and will be offline for a while.
Everyone can try the probe_superio patch for IT8716, though, and send dumps for proprietary and LinuxBIOS to the list. It would be nice if I had dumps for both types of M57SLI (SPI and PLCC) to be able to compare.
This is the PLCC version of the M57SLI, booted into the proprietary bios. I'll get you a LinuxBIOS boot dump later in the week.
Thanks, Ward.
--------------------------------------------------
No Super I/O chip found at 0x002e No Super I/O chip found at 0x002e Super I/O found at 0x2e: id=0x8716, chipver=0x0 ITE IT8716 idx 07 20 21 22 23 24 2b val 0a 87 16 00 11 00 00 def NA 87 16 01 00 00 00 Switching to LDN 0x0 idx 30 60 61 70 74 f0 f1 val 01 03 f0 06 02 00 80 def 00 03 f0 06 02 00 00 Switching to LDN 0x1 idx 30 60 61 70 f0 f1 f2 f3 val 01 03 f8 04 00 50 00 7f def 00 03 f8 04 00 50 00 7f Switching to LDN 0x2 idx 30 60 61 70 f0 f1 f2 f3 val 00 00 00 00 00 50 00 7f def 00 02 f8 03 00 50 00 7f Switching to LDN 0x3 idx 30 60 61 62 63 70 74 f0 val 01 03 78 00 00 07 04 08 def 00 03 78 07 78 07 03 03 Switching to LDN 0x4 idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 f6 val 01 02 90 00 00 00 80 00 0a 00 80 00 e7 def 00 02 90 02 30 09 00 00 00 00 00 NA NA Switching to LDN 0x5 idx 30 60 61 62 63 70 71 f0 val 01 00 60 00 64 01 02 68 def 01 00 60 00 64 01 02 00 Switching to LDN 0x6 idx 30 70 71 f0 val 01 0c 02 00 def 00 0c 02 00 Switching to LDN 0x7 idx 25 26 27 28 29 2a 2c 60 61 62 63 64 65 70 71 72 73 74 b0 b1 b2 b3 b4 b5 b8 b9 ba bb bc bd c0 c1 c2 c3 c4 c8 c9 ca cb cc e0 e1 e2 e3 e4 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd val 00 43 20 00 81 00 1f 00 00 08 00 00 00 00 01 00 38 00 00 00 00 00 00 00 00 00 00 00 01 00 00 43 20 00 00 00 40 00 00 00 00 00 00 00 00 10 40 00 00 00 00 28 00 00 00 00 00 32 00 def 01 00 00 40 00 00 00 00 00 00 00 00 00 00 00 20 38 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 40 00 01 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 NA 00 Switching to LDN 0x8 idx 30 60 61 70 f0 val 00 03 00 0a 00 def 00 03 00 0a 00 Switching to LDN 0x9 idx 30 60 61 val 00 02 01 def 00 02 01 Switching to LDN 0xa idx 30 60 61 70 f0 val 00 03 10 0b 06 def 00 03 10 0b 00 No Super I/O chip found at 0x004e No Super I/O chip found at 0x004e No Super I/O chip found at 0x004e
On 02.09.2007 16:25, Ward Vandewege wrote:
On Sat, Sep 01, 2007 at 09:30:54PM +0200, Carl-Daniel Hailfinger wrote:
On 01.09.2007 19:57, Peter Stuge wrote:
Once we figure out the hardware, it will still be neccessary to reboot into DOS/Windows to flash either chip. :(
SPI detection/flashing support is on my list. However, it won't get done in the next 3 weeks because I'm getting married next week and will be offline for a while.
Everyone can try the probe_superio patch for IT8716, though, and send dumps for proprietary and LinuxBIOS to the list. It would be nice if I had dumps for both types of M57SLI (SPI and PLCC) to be able to compare.
This is the PLCC version of the M57SLI, booted into the proprietary bios. I'll get you a LinuxBIOS boot dump later in the week.
Thanks Ward!
Carl-Daniel
On Sat, Sep 01, 2007 at 09:30:54PM +0200, Carl-Daniel Hailfinger wrote:
On 01.09.2007 19:57, Peter Stuge wrote:
Once we figure out the hardware, it will still be neccessary to reboot into DOS/Windows to flash either chip. :(
SPI detection/flashing support is on my list. However, it won't get done in the next 3 weeks because I'm getting married next week and will be offline for a while.
Everyone can try the probe_superio patch for IT8716, though, and send dumps for proprietary and LinuxBIOS to the list. It would be nice if I had dumps for both types of M57SLI (SPI and PLCC) to be able to compare.
And here's a dump from a soic/spi version of the m57sli, again with the proprietary BIOS.
Thanks, Ward.
--------------------------------------------------------------------------
No Super I/O chip found at 0x002e No Super I/O chip found at 0x002e Super I/O found at 0x2e: id=0x8716, chipver=0x0 ITE IT8716 idx 07 20 21 22 23 24 2b val 0a 87 16 00 11 1a 00 def NA 87 16 01 00 00 00 Switching to LDN 0x0 idx 30 60 61 70 74 f0 f1 val 00 00 00 00 04 00 80 def 00 03 f0 06 02 00 00 Switching to LDN 0x1 idx 30 60 61 70 f0 f1 f2 f3 val 01 03 f8 04 00 50 00 7f def 00 03 f8 04 00 50 00 7f Switching to LDN 0x2 idx 30 60 61 70 f0 f1 f2 f3 val 00 00 00 00 00 50 00 7f def 00 02 f8 03 00 50 00 7f Switching to LDN 0x3 idx 30 60 61 62 63 70 74 f0 val 00 00 00 00 00 00 04 08 def 00 03 78 07 78 07 03 03 Switching to LDN 0x4 idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 f6 val 01 02 90 00 00 00 80 00 0a 00 80 00 ff def 00 02 90 02 30 09 00 00 00 00 00 NA NA Switching to LDN 0x5 idx 30 60 61 62 63 70 71 f0 val 01 00 60 00 64 01 02 68 def 01 00 60 00 64 01 02 00 Switching to LDN 0x6 idx 30 70 71 f0 val 01 0c 02 00 def 00 0c 02 00 Switching to LDN 0x7 idx 25 26 27 28 29 2a 2c 60 61 62 63 64 65 70 71 72 73 74 b0 b1 b2 b3 b4 b5 b8 b9 ba bb bc bd c0 c1 c2 c3 c4 c8 c9 ca cb cc e0 e1 e2 e3 e4 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd val 00 43 20 00 81 00 1f 00 00 08 00 08 20 00 00 00 38 00 00 00 00 00 00 00 00 00 00 00 01 00 00 43 20 00 00 00 40 00 00 00 00 00 00 00 00 10 40 00 00 00 00 28 00 00 00 00 00 32 00 def 01 00 00 40 00 00 00 00 00 00 00 00 00 00 00 20 38 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 40 00 01 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 NA 00 Switching to LDN 0x8 idx 30 60 61 70 f0 val 00 03 00 0a 00 def 00 03 00 0a 00 Switching to LDN 0x9 idx 30 60 61 val 00 02 01 def 00 02 01 Switching to LDN 0xa idx 30 60 61 70 f0 val 00 03 10 0b 06 def 00 03 10 0b 00 No Super I/O chip found at 0x004e No Super I/O chip found at 0x004e No Super I/O chip found at 0x004e
On 02.09.2007 16:39, Ward Vandewege wrote:
On Sat, Sep 01, 2007 at 09:30:54PM +0200, Carl-Daniel Hailfinger wrote:
On 01.09.2007 19:57, Peter Stuge wrote:
Once we figure out the hardware, it will still be neccessary to reboot into DOS/Windows to flash either chip. :(
SPI detection/flashing support is on my list. However, it won't get done in the next 3 weeks because I'm getting married next week and will be offline for a while.
Everyone can try the probe_superio patch for IT8716, though, and send dumps for proprietary and LinuxBIOS to the list. It would be nice if I had dumps for both types of M57SLI (SPI and PLCC) to be able to compare.
And here's a dump from a soic/spi version of the m57sli, again with the proprietary BIOS.
Thanks Ward!
This confirms my suspicion that the IT8716F is indeed used for LPC-to-SPI translation.
LDN 0x0, reg 0x24: val=0x1a serial flash interface at pin 29 LPC write to serial flash enabled 512kByte of flash are mapped at top of 4GByte 128kByte of flash are mapped at top of 1MByte (1152kByte can be mapped at most)
LDN 0x7, reg 0x64/0x65: val=0x08/0x20 serial flash interface base addr 0x0820 (that's an I/O port)
I have an idea what to do next, see my other mail in this thread.
Regards, Carl-Daniel
On Sat, Sep 01, 2007 at 07:57:18PM +0200, Peter Stuge wrote:
Is the modification now wrong?
ST, can you chime in here?
Hard to tell without testing. I could give it a go if I had a board. But, someone please send a high-res photo of this part of the board: http://stuge.se/m57sli_spi_mod_area.jpg so that we can have a look at the traces. Please take the photo from straight above the board so that the black PCIe sockets do not obscure any traces or components.
Something like this?
http://ward.vandewege.net/m57sli_soic_detail.jpg
Thanks, Ward.
On Wed, Sep 05, 2007 at 03:20:08PM +0200, ST wrote:
Is the modification now wrong?
ST, can you chime in here?
Mh, i don't know anything about SPI, but i think if they also have #init pins it should work.
They don't.
The only signal we can work with is CS# which is connected directly to the super io, which means we want to be a bit careful about driving it, to be on the safe side.
I'd lift the pin. At least it's in a corner.
//Peter
On Wed, Sep 05, 2007 at 07:55:59PM +0200, Peter Stuge wrote:
I'd lift the pin.
What resistance is there between U5-CS# and U5-VCC ?
What resistance is there between U9-CS# and U9-VCC ?
Thanks.
//Peter
Quoting Peter Stuge peter@stuge.se:
On Wed, Sep 05, 2007 at 07:55:59PM +0200, Peter Stuge wrote:
I'd lift the pin.
What resistance is there between U5-CS# and U5-VCC ?
8 kohm
What resistance is there between U9-CS# and U9-VCC ?
infinity
Hi
Mh, i don't know anything about SPI, but i think if they also have #init pins it should work.
They don't.
Not good.
If i remember correctly on my v1.0 M57SLI-S4 there have been SPI pins within the PLCC connectors. These pins where not connected to any of the open presumably SPI pins.
But well i don't have a new board and i don't know SPI stuff. But you should try to measure all the pins i used for my stuff. Probably there is a connection... or the CS# of both SPI chips is connected to different pins of the SuperIO?
Regards Tim
Quoting ST st@iss.tu-darmstadt.de:
But well i don't have a new board and i don't know SPI stuff. But you should try to measure all the pins i used for my stuff. Probably there is a connection... or the CS# of both SPI chips is connected to different pins of the SuperIO?
No, the second SPI CS# isn't connected directly with any SuperIO pin. OTOH, I found (using Peter's labeling): U9-CS# -> Q4-1 Q4-3 -> Q3-3 Q5-1 -> U5-CS# -> SuperIO-61 Please note that that there is no serial resistor btw U5-CS# and SuperIO-61, so you cannot force the pullup of Q5-1 (IMHO)
Florentin
Hi all, Just some little newbee questions: * What is the "romstrap" section? Does it have to be located @ a fixed physical address? * What is a "SIP table"?
thanks in advance for your answers, Florentin
On 9/7/07, echelon@free.fr echelon@free.fr wrote:
Hi all, Just some little newbee questions:
- What is the "romstrap" section? Does it have to be located @ a fixed physical
address?
- What is a "SIP table"?
you need to access Nvidia NDA info about that...
YH
how about #HOLD ? ----- Original Message ----- From: "Peter Stuge" peter@stuge.se To: linuxbios@linuxbios.org Sent: Wednesday, September 05, 2007 19:55 Subject: Re: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI)
On Wed, Sep 05, 2007 at 03:20:08PM +0200, ST wrote:
Is the modification now wrong?
ST, can you chime in here?
Mh, i don't know anything about SPI, but i think if they also have #init pins it should work.
They don't.
The only signal we can work with is CS# which is connected directly to the super io, which means we want to be a bit careful about driving it, to be on the safe side.
I'd lift the pin. At least it's in a corner.
//Peter
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
On Fri, Sep 07, 2007 at 09:17:14PM +0200, todthgie wrote:
----- Original Message ----- From: "Peter Stuge" peter@stuge.se To: linuxbios@linuxbios.org Sent: Wednesday, September 05, 2007 19:55
The only signal we can work with is CS#
how about #HOLD ?
It's not good enough on it's own.
Check out the MX flash chip data sheet.
The HOLD state in the chip depends on CS# as well, plus the HOLD# pin is connected across both U5 and U9 which makes it annoying to work with if we're going to use the U9 pads.
//Peter
On Thu, Aug 30, 2007 at 01:25:27PM +0200, Rasmus Wiman wrote:
Ward Vandewege ward@gnu.org wrote:
Just for the record; if you buy an M57SLI now, it's a new revision with SPI rom chip. The second position is still unpopulated, but the paths are now also SPI, no longer PLCC.
I have one of these at home :/
I read about that, yes. What does it mean? Different sockets? No sockets at all? Impossible to flash?
Different sockets, yes. I've updated the M57SLI howto with a picture of an SPI version; I'll make a picture of a PLCC version too at work today.
As for flashing, flashrom does not find the rom chip, which is unsurprising:
# ./flashrom -vv Calibrating delay loop... ok No LinuxBIOS table found. Found chipset "NVIDIA MCP55": Enabling flash write... OK. No EEPROM/flash device found.
Thanks, Ward.
Ward Vandewege ward@gnu.org wrote:
Different sockets, yes. I've updated the M57SLI howto with a picture of an SPI version; I'll make a picture of a PLCC version too at work today.
Just had a look and I think I could work out where the BIOS is, but how about loading the picture in gimp and just draw a circle around them? Also, I think that a few words about the status of LinuxBIOS on the SPI version would be a good thing. Right now, the howto just mentions the spi version and then goes on about how to get LinuxBIOS on the PLCC version.
Thanks, Rasmus
On Thu, Aug 30, 2007 at 08:06:08AM -0400, Ward Vandewege wrote:
On Thu, Aug 30, 2007 at 01:25:27PM +0200, Rasmus Wiman wrote:
Ward Vandewege ward@gnu.org wrote:
Just for the record; if you buy an M57SLI now, it's a new revision with SPI rom chip. The second position is still unpopulated, but the paths are now also SPI, no longer PLCC.
I have one of these at home :/
I read about that, yes. What does it mean? Different sockets? No sockets at all? Impossible to flash?
Different sockets, yes. I've updated the M57SLI howto with a picture of an SPI version; I'll make a picture of a PLCC version too at work today.
Thanks, that'll be helful for a lot of people, I guess. Please attach license to the photos, though.
Uwe.
On Thu, Aug 30, 2007 at 03:39:21PM +0200, Uwe Hermann wrote:
Thanks, that'll be helpful for a lot of people, I guess. Please attach license to the photos, though.
Done.
Thanks, Ward.
Rasmus Wiman schrieb:
I read about that, yes. What does it mean? Different sockets? No sockets at all? Impossible to flash?
there are SPI sockets out there in industry, but less common & probably pricey. plcc32 is much more commonplace.
but then soldering 8 contacts might seem less risky to do manually compared with 32 contacts.
the 1.0 pcb layout has solder pads for plcc as well as SPI (located inside of plcc ). is this still the case with 2.0 pcb revisions ?
-- Q
Quux pawn2be.wild@yahoo.de wrote:
there are SPI sockets out there in industry, but less common & probably pricey. plcc32 is much more commonplace.
but then soldering 8 contacts might seem less risky to do manually compared with 32 contacts.
the 1.0 pcb layout has solder pads for plcc as well as SPI (located inside of plcc ). is this still the case with 2.0 pcb revisions ?
From the picture it looks like there is only one set of pads. Sure 8
contacts seem easier to solder, but I like the idea of having one factory bios stuffed away in a safe place, away from the mobo and that seems easier to achieve with a socket. :)
/Rasmus
----- Original Message ----- From: "Rasmus Wiman" rasmus@wiman.org To: linuxbios@linuxbios.org Sent: Thursday, August 30, 2007 16:17 Subject: Re: [LinuxBIOS] M57 SLI SPI pads
Quux pawn2be.wild@yahoo.de wrote:
there are SPI sockets out there in industry, but less common & probably pricey. plcc32 is much more commonplace.
but then soldering 8 contacts might seem less risky to do manually compared with 32 contacts.
the 1.0 pcb layout has solder pads for plcc as well as SPI (located inside of plcc ). is this still the case with 2.0 pcb revisions ?
From the picture it looks like there is only one set of pads. Sure 8 contacts seem easier to solder, but I like the idea of having one factory bios stuffed away in a safe place, away from the mobo and that seems easier to achieve with a socket. :)
how about: - unsoldering the factory part. - soldering a 8 pin ?0.05"? pitch connector it its place - soldering a mating 8 pin connector to any chip you want to use - maybe add pushpins for easyer handling.
i did not yet look for the right connectors but they mus be out there... i would start lloking at smd connector for connecting 2 parrallel pcb's
Greetings Todthgie
/Rasmus
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Peter Stuge peter@stuge.se wrote:
On Thu, Aug 30, 2007 at 12:28:23AM +0200, Rasmus Wiman wrote:
when I can afford it, I will buy a new MB with integrated vga, probably the one I think stands the best chance of getting supported. Right now I think that would mean NVidia or VIA, but I know rather little about it.
Aha! I think there is a slight misunderstanding.
"Integrated" graphics are not really any different from discrete graphics as far as LB is concerned. Neither better nor worse.
Sounds good. I was thinking that memory initalisation might be somehow diferent when the graphics hardware wants some of the memory.
There are two graphics chips supported natively in LB, they are the ATI Rage XL and the Trident Blade3d. I've only heard the former confirmed working.
Didn't even know LB has that kind of support for any graphics chip. I only knew about the CONFIG_PCI_ROM_RUN and (if needed ) extracting the vga bios from the stock bios approach. By the way, at least Rage XL (with its own memory) seems pretty common on server mainboards.Is it a coincidence that just that chip is supported?
But my main motivation is that if there was a MB with a "Works with linuxbios" sticker on it, and it didn't cost too much I'd buy it.
I'll say M57SLI.
That was my first thought too. Or another MCP55 card. Then I started wondering if I could help put that sticker on more cards. That's when I started wondering if the nforce 430 with built-in Geforce would be very different from the mcp55, or the k8m800 would be very different from the epia chipsets.
/Rasmus
Quoting Rasmus Wiman rasmus@wiman.org:
Peter Stuge peter@stuge.se wrote:
On Thu, Aug 30, 2007 at 12:28:23AM +0200, Rasmus Wiman wrote:
when I can afford it, I will buy a new MB with integrated vga, probably the one I think stands the best chance of getting supported. Right now I think that would mean NVidia or VIA, but I know rather little about it.
Aha! I think there is a slight misunderstanding.
"Integrated" graphics are not really any different from discrete graphics as far as LB is concerned. Neither better nor worse.
Sounds good. I was thinking that memory initalisation might be somehow diferent when the graphics hardware wants some of the memory.
There are two graphics chips supported natively in LB, they are the ATI Rage XL and the Trident Blade3d. I've only heard the former confirmed working.
Didn't even know LB has that kind of support for any graphics chip. I only knew about the CONFIG_PCI_ROM_RUN and (if needed ) extracting the vga bios from the stock bios approach. By the way, at least Rage XL (with its own memory) seems pretty common on server mainboards.Is it a coincidence that just that chip is supported?
Rasmus have you read this:
http://www.linuxbios.org/data/vgabios/
It goes into pretty good detail on how graphics work in LinuxBIOS.
Thanks - Joe
Joseph Smith joe@smittys.pointclark.net skrev:
Didn't even know LB has that kind of support for any graphics chip. I only knew about the CONFIG_PCI_ROM_RUN and (if needed ) extracting the vga bios from the stock bios approach. By the way, at least Rage XL (with its own memory) seems pretty common on server mainboards.Is it a coincidence that just that chip is supported?
Rasmus have you read this:
http://www.linuxbios.org/data/vgabios/
It goes into pretty good detail on how graphics work in LinuxBIOS.
Now I have. I hadn't seen it before, I had only seen http://www.linuxbios.org/VGA_support and http://www.linuxbios.org/X11_on_EPIA-M before. The link you provided was far more informative and in-depth than the two other. Not finding the right docs seem to be one of my virtues. :)
Anyway, I suppose I think I am starting to know some basics. I guess it is actually possible to set up memory and getting serial output on the board without even knowing that there is a vga chip integrated into the chipset. I guess getting that far would be considered a good start.
I read at least one card spec that said that the GF6100 was "integrated into the north bridge". But if I understand things correctly, the north bridge sits in the K8. I guess it means that one of the HT links go to the vga chip, or to a vga chip on a PCIE controller.
Also, since the K8 is supported, does that mean that memory works "once and for all", or is that part a separate part for every MB anyway?
I assume (I really don't know too much about this stuff) that the superio is connected to the south bridge, so without knowing the south bridge, serial won't come up. Correct? That's also why I wonder how much chipsets from the same manufacturer differ from each other. If there are lots of similarities, just finding out the superIO, putting the MCP55 code in the bios and see what happens could perhaps be a good start. I know I just did tons of over-simplifications. :)
/Rasmus
Rasmus Wiman wrote:
Peter Stuge peter@stuge.se skrev:
On Wed, Aug 29, 2007 at 10:33:34PM +0200, Rasmus Wiman wrote:
I disagree strongly. There is definately a point in supporting older hardware as well
On the other hand, have a look at e.g. the Asus M2N-MX/DVI2.
Some can not afford to pay anything for hardware. Or put another way, hardware that comes for free is always cheaper and often more attractive than hardware that has to be payed for - no matter how cheap the price.
I'm thinking recycling of older machines.
Certainly, (right now I can't afford any new hardware) but one problem with stuff that comes for free is you don't know what you get. Which means there has to be support for lots of old MB:s for there to be a decent chance that the stuff you actually get is supported. Sure, generic BX support is probably a very good thing since they were the best you could get during almost the entire PII/PIII era, so there are lots of them around.
That's always a problem, no matter how hard we try I don't think it would be possible to ever fully support even every board that has a 440bx chipset. I think the best bet is to get at least one decent, fully working port for each major chipset. The 440bx isn't even fully generic yet, it has some work to go (IIRC). Then there's a bunch of i8xx-series, via vt693/694, and s3 chipsets just to cover p3 boards. That's a lot of ports, and given how few devs there are, something needs to get cut. So we need to isolate the most popular chipsets, and get at least one good port for a board with those chips.
But I still think stuff that's still being sold is a better bet. Even the cheapest modern hardware outperforms the PIII by far, and I know that I can get the stuff at once if I want it. I can get an M57-SLI-S4 tomorrow if I have the money. But there are motherboards that cost half as much, have integrated vga and even the price of mb plus cpu end up costing less than the mcp55 cards alone. Then you need a vga card in the MCP55.
/Rasmus
Although true, many users do get high-end boards/video cards/cpus because the cheap integrated solutions just don't do what they need to do. They might be great for my grandmother, but not for me, and I just can't see my grandmother understanding C.
-Corey
Corey Osgood corey.osgood@gmail.com wrote:
Although true, many users do get high-end boards/video cards/cpus because the cheap integrated solutions just don't do what they need to do. They might be great for my grandmother, but not for me, and I just can't see my grandmother understanding C.
They are splendid for generic office work though, you'll see them in many offices (esp. the Intel 945gm boxes from dell, etc). Maybe the sysadmin at such a place could see some benefit in LB? Especially if it also boots XP/Vista.
/Rasmus
* Peter Stuge peter@stuge.se [070829 22:21]:
FILO can already do usb/el torito cdrom boot, but it badly needs ehci support.
The FILO USB stack is not completely robust as I've understood things. AFAIK it also only supports OHCI and neither UHCI nor the quite desirable EHCI.
UHCI is there. But I think the stack never worked except embedded in etherboot. If anyone wants to make a grub2 module out of it... ;)
On 8/29/07, Uwe Hermann uwe@hermann-uwe.de wrote:
On Mon, Aug 27, 2007 at 05:21:08PM -0500, Corey Osgood wrote:
We had such calls before, and people would send in their board information, assuming that this would be enough for us to support
their
hardware. Unfortunately not a single new port resulted from this,
though
many people participated and lots of (unaccomplished) expectations
were
created. So I carefully wonder what the real goal of such a call would be, except gathering random people with random boards?
Well, that's how I found this place, and that resulted in one port (so far) :) But I can very clearly see your point.
What exactly lead you to this project? That would be interesting to analyze...
My feeling is that a "post your lspci" call for action will result in lots of lspci's (which is totally useless) and we'll have to tell all those people "no, your board/chipset is not yet supported". That sucks, and there's really no gain in doing that.
Now, what I think would indeed be useful is a Call For Developers. Because that's what we really need, more developers, more man-power to actually write code to support new chipsets. Random lspci's from random people don't help at all. We've had tons of those already and they all end up with "no, it's not supported" answers.
Something like: We have 10 people who are willing to work on this or that mainboard if you get them a system they can keep for doing the work, given that the northbridge and southbridge are already supported... Other ideas?
Won't help either. The number of active developers doing new ports is way less than 10 anyway. Personally I have at least 4-5 board sitting here which should be relatively easy to support, I'm just lacking the required spare time.
We need more developers and/or more time.
I don't think money is a problem in most cases (if it is we can probably arrange for some hardware shipping or ask for donations or something).
The real problems (in my view) are:
- Lack of developers
- Lack of time
- Lack of proper datasheets (for some/many chipsets)
Issue 2 cannot be solved easily, issue 3 depends on many factors we usually cannot influence a lot, but issue 1 is where we can get the biggest gain, IMHO.
I wonder if clean-room reverse engineering on commercial BIOS that comes with the board can help for case 3 because most of them have a "generic" code to boot the machine until preliminary RAM test. Personally, I view it as a *very interesting* challenge.
Regards,
Darmawan Salihun -------------------------------------------------------------------- -= Human knowledge belongs to the world =-
Darmawan Salihun wrote:
On 8/29/07, *Uwe Hermann* <uwe@hermann-uwe.de mailto:uwe@hermann-uwe.de> wrote:
The real problems (in my view) are: 1. Lack of developers 2. Lack of time 3. Lack of proper datasheets (for some/many chipsets) Issue 2 cannot be solved easily, issue 3 depends on many factors we usually cannot influence a lot, but issue 1 is where we can get the biggest gain, IMHO.I wonder if clean-room reverse engineering on commercial BIOS that comes with the board can help for case 3 because most of them have a "generic" code to boot the machine until preliminary RAM test. Personally, I view it as a *very interesting* challenge.
Very interesting, yes, but that routes directly back to problem 1. More developers could lead the creation of a separate project with that goal in mind, but for now everyone's working with what they have. If we had more people/time, such things might be feasible and very beneficial.
-Corey
----- Original Message ----- From: "Corey Osgood" corey.osgood@gmail.com To: "Darmawan Salihun" darmawan.salihun@gmail.com Cc: "linuxbios" linuxbios@linuxbios.org Sent: Thursday, August 30, 2007 00:07 Subject: Re: [LinuxBIOS] [RFC] Call for Action: LinuxBIOS foundations
Darmawan Salihun wrote:
On 8/29/07, *Uwe Hermann* <uwe@hermann-uwe.de mailto:uwe@hermann-uwe.de> wrote:
The real problems (in my view) are: 1. Lack of developers 2. Lack of time 3. Lack of proper datasheets (for some/many chipsets) Issue 2 cannot be solved easily, issue 3 depends on many factors we usually cannot influence a lot, but issue 1 is where we can get the biggest gain, IMHO.I wonder if clean-room reverse engineering on commercial BIOS that comes with the board can help for case 3 because most of them have a "generic" code to boot the machine until preliminary RAM test. Personally, I view it as a *very interesting* challenge.
Very interesting, yes, but that routes directly back to problem 1. More developers could lead the creation of a separate project with that goal in mind, but for now everyone's working with what they have. If we had more people/time, such things might be feasible and very beneficial.
suggestion: make a tool based that emits a trace of whats going on ... i would suggest first making a tool for extracting award flash enables....
-Todthgie
-Corey
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
On 8/31/07, todthgie todthgie@hotmail.com wrote:
----- Original Message ----- From: "Corey Osgood" corey.osgood@gmail.com To: "Darmawan Salihun" darmawan.salihun@gmail.com Cc: "linuxbios" linuxbios@linuxbios.org Sent: Thursday, August 30, 2007 00:07 Subject: Re: [LinuxBIOS] [RFC] Call for Action: LinuxBIOS foundations
Darmawan Salihun wrote:
On 8/29/07, *Uwe Hermann* <uwe@hermann-uwe.de mailto:uwe@hermann-uwe.de> wrote:
The real problems (in my view) are: 1. Lack of developers 2. Lack of time 3. Lack of proper datasheets (for some/many chipsets) Issue 2 cannot be solved easily, issue 3 depends on many factors we usually cannot influence a lot, but issue 1 is where we can get the biggest gain, IMHO.I wonder if clean-room reverse engineering on commercial BIOS that
comes
with the board can help for case 3 because most of them have a
"generic"
code to boot the machine until preliminary RAM test. Personally, I view it as a *very interesting* challenge.
Very interesting, yes, but that routes directly back to problem 1. More developers could lead the creation of a separate project with that goal in mind, but for now everyone's working with what they have. If we had more people/time, such things might be feasible and very beneficial.
suggestion: make a tool based that emits a trace of whats going on ... i would suggest first making a tool for extracting award flash enables....
-Todthgie
I think it's not too hard. I would need to create an IDA Pro plugin or IDA Python script that can search for the binary signatures that of interest. I have some preliminary code for different task that I think can be used for that once I'm working on it ;-). It may be just too premature to talk about it right now.
Regards,
Darmawan Salihun -------------------------------------------------------------------- -= Human knowledge belongs to the world =-
On 27.08.2007 18:12, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
Hi,
since we're aiming for broader coverage in LinuxBIOS and related tools, I think we should publish a "Call for Action" which urges interested people to give us dumps of their board configuration etc.
We had such calls before, and people would send in their board information, assuming that this would be enough for us to support their
Yes.
hardware. Unfortunately not a single new port resulted from this, though many people participated and lots of (unaccomplished) expectations were
The expectations are a bit of a problem. This also has to do with our shortage of skilled manpower and the very steep learning curve for doing a port in v2.
created. So I carefully wonder what the real goal of such a call would be, except gathering random people with random boards? Something like: We have 10 people who are willing to work on this or that mainboard if you get them a system they can keep for doing the work, given that the
Would it be possible to create sort of a pseudo-port which only ensures working RAM, serial and flashing? Such a pseudo-port would leave people with two options/payloads over serial: - reflash proprietary BIOS - try to init north-/southbridge with the current version of the code
northbridge and southbridge are already supported... Other ideas?
Maybe a call for action for tools only? Flashrom and probe_superio support are necessary requirements for easy porting. And if our tools get used for stuff besides LinuxBIOS (maybe in the lm-sensors project or somewhere else), they get wider testing coverage and maybe even outside contributors. I see this chance especially for flashrom. People want to flash their proprietary BIOS under Linux now, without having to reboot. They benefit from flashrom support for their system as much as we do. Giving people a working tool for something that is really complicated right now could even make them interested in LinuxBIOS. After all, they would have to visit our website to get flashrom.
Thoughts?
Regards, Carl-Daniel
On Tue, Aug 28, 2007 at 12:48:06AM +0200, Carl-Daniel Hailfinger wrote:
hardware. Unfortunately not a single new port resulted from this, though many people participated and lots of (unaccomplished) expectations were
The expectations are a bit of a problem. This also has to do with our shortage of skilled manpower and the very steep learning curve for doing a port in v2.
Exactly.
Which is why I think random lspci's won't help us (see my other post).
created. So I carefully wonder what the real goal of such a call would be, except gathering random people with random boards? Something like: We have 10 people who are willing to work on this or that mainboard if you get them a system they can keep for doing the work, given that the
Would it be possible to create sort of a pseudo-port which only ensures working RAM, serial and flashing? Such a pseudo-port would leave people
No, "working RAM" is already 95% of the work in most cases.
Maybe a call for action for tools only? Flashrom and probe_superio support are necessary requirements for easy porting. And if our tools get used for stuff besides LinuxBIOS (maybe in the lm-sensors project or somewhere else), they get wider testing coverage and maybe even outside contributors. I see this chance especially for flashrom.
Yes, I agree on that. We should really get more people to use flashrom, not only as cheap advertising for LinuxBIOS but also because it really _is_ a lot better than all those crappy "use DOS boot disk" or "create CDROM with DOS *.exe flasher on it" solutions people keep recommending all the time.
I've written up a short article on that already, see http://www.hermann-uwe.de/blog/flashing-a-bios-the-linux-way-tm-using-flashr...
(and I think the "flashrom on about 140 computers" was a direct result of that post)
http://www.linuxbios.org/pipermail/linuxbios/2007-July/023046.html
People want to flash their proprietary BIOS under Linux now, without having to reboot. They benefit from flashrom support for their system as much as we do. Giving people a working tool for something that is really complicated right now could even make them interested in LinuxBIOS. After all, they would have to visit our website to get flashrom.
Full ack. How can we advertise flashrom some more?
Uwe.
On 28.08.2007 19:38, Uwe Hermann wrote:
On Tue, Aug 28, 2007 at 12:48:06AM +0200, Carl-Daniel Hailfinger wrote:
created. So I carefully wonder what the real goal of such a call would be, except gathering random people with random boards? Something like: We have 10 people who are willing to work on this or that mainboard if you get them a system they can keep for doing the work, given that the
Would it be possible to create sort of a pseudo-port which only ensures working RAM, serial and flashing? Such a pseudo-port would leave people
No, "working RAM" is already 95% of the work in most cases.
If that were the case, we'd have dozens of recent boards supported. Think of all the MCP55 boards. RAM works. North- and southbridge are supported. The "little things" are what keep us from supporting them completely. A generic MCP55 port which loads the payload (additional board init etc.) over serial can be the ideal starting point.
Maybe a call for action for tools only? Flashrom and probe_superio support are necessary requirements for easy porting. And if our tools get used for stuff besides LinuxBIOS (maybe in the lm-sensors project or somewhere else), they get wider testing coverage and maybe even outside contributors. I see this chance especially for flashrom.
Yes, I agree on that. We should really get more people to use flashrom, not only as cheap advertising for LinuxBIOS but also because it really _is_ a lot better than all those crappy "use DOS boot disk" or "create CDROM with DOS *.exe flasher on it" solutions people keep recommending all the time.
I've written up a short article on that already, see http://www.hermann-uwe.de/blog/flashing-a-bios-the-linux-way-tm-using-flashr...
(and I think the "flashrom on about 140 computers" was a direct result of that post)
http://www.linuxbios.org/pipermail/linuxbios/2007-July/023046.html
Maybe publish an article on lwn/slashdot/whatever about flashrom? You'd have to make sure people merge MAC addresses and other stuff from the old into the new image, though, otherwise we'll have a load of boards with the same MAC address and quite a few of them may have 00:00:00:00:00:00, resulting in malfunction of some switches, network stacks etc.
People want to flash their proprietary BIOS under Linux now, without having to reboot. They benefit from flashrom support for their system as much as we do. Giving people a working tool for something that is really complicated right now could even make them interested in LinuxBIOS. After all, they would have to visit our website to get flashrom.
Full ack. How can we advertise flashrom some more?
Article in widely read publication. I'll contact lwn.net and report back.
Regards, Carl-Daniel
On Tue, Aug 28, 2007 at 08:17:45PM +0200, Carl-Daniel Hailfinger wrote:
On 28.08.2007 19:38, Uwe Hermann wrote:
On Tue, Aug 28, 2007 at 12:48:06AM +0200, Carl-Daniel Hailfinger wrote:
created. So I carefully wonder what the real goal of such a call would be, except gathering random people with random boards? Something like: We have 10 people who are willing to work on this or that mainboard if you get them a system they can keep for doing the work, given that the
Would it be possible to create sort of a pseudo-port which only ensures working RAM, serial and flashing? Such a pseudo-port would leave people
No, "working RAM" is already 95% of the work in most cases.
If that were the case, we'd have dozens of recent boards supported.
OK, if you talk about boards where northbridge+southbridge is already supported it's less work, yes (still not trivial, though).
Think of all the MCP55 boards. RAM works. North- and southbridge are supported. The "little things" are what keep us from supporting them completely. A generic MCP55 port which loads the payload (additional board init etc.) over serial can be the ideal starting point.
Why? I don't really see a use for this. If someone is able to run such a payload, build LinuxBIOS, test patches etc. it's not much additional work to just add proper support for the board in the first place. No need for such a "test-payload", I think.
Yes, a couple more MCP55 and CK804 boards would be nice; I'm working on A8NE-FM/S (I already sent a preliminary patch a few weeks ago), and the K9N Neo is a good candidate, too (which I have here, just lack some spare time to work on it).
Maybe publish an article on lwn/slashdot/whatever about flashrom? You'd have to make sure people merge MAC addresses and other stuff from the old into the new image, though, otherwise we'll have a load of boards with the same MAC address and quite a few of them may have 00:00:00:00:00:00, resulting in malfunction of some switches, network stacks etc.
Can you elaborate? Where is the MAC address stored? On which boards? I doubt that all boards out there do this. What happens if you download a BIOS image from $VENDOR website? Does the flasher contain special code to deal with the MAC address?
People want to flash their proprietary BIOS under Linux now, without having to reboot. They benefit from flashrom support for their system as much as we do. Giving people a working tool for something that is really complicated right now could even make them interested in LinuxBIOS. After all, they would have to visit our website to get flashrom.
Full ack. How can we advertise flashrom some more?
Article in widely read publication. I'll contact lwn.net and report back.
Great, thanks!
Uwe.
On 29.08.2007 16:47, Uwe Hermann wrote:
On Tue, Aug 28, 2007 at 08:17:45PM +0200, Carl-Daniel Hailfinger wrote:
Think of all the MCP55 boards. RAM works. North- and southbridge are supported. The "little things" are what keep us from supporting them completely. A generic MCP55 port which loads the payload (additional board init etc.) over serial can be the ideal starting point.
Why? I don't really see a use for this. If someone is able to run such a payload, build LinuxBIOS, test patches etc. it's not much additional work to just add proper support for the board in the first place. No need for such a "test-payload", I think.
The "you can always reflash the old BIOS" feeling gives confidence to porters who might not have a replacement chip handy.
Maybe publish an article on lwn/slashdot/whatever about flashrom? You'd have to make sure people merge MAC addresses and other stuff from the old into the new image, though, otherwise we'll have a load of boards with the same MAC address and quite a few of them may have 00:00:00:00:00:00, resulting in malfunction of some switches, network stacks etc.
Can you elaborate? Where is the MAC address stored? On which boards? I doubt that all boards out there do this. What happens if you download a BIOS image from $VENDOR website? Does the flasher contain special code to deal with the MAC address?
The MAC address is stored in flash for almost all CK804/MCP55 boards. All of these boards flashed with LB probably have the same MAC address. See src/southbridge/nvidia/ck804/romstrap.inc and src/southbridge/nvidia/mcp55/romstrap.inc for details. On some of these boards, the MAC address is stored in a separate EEPROM, but you can't count on that.
Regards, Carl-Daniel
On Wed, Aug 29, 2007 at 05:02:11PM +0200, Carl-Daniel Hailfinger wrote:
On 29.08.2007 16:47, Uwe Hermann wrote:
On Tue, Aug 28, 2007 at 08:17:45PM +0200, Carl-Daniel Hailfinger wrote:
Think of all the MCP55 boards. RAM works. North- and southbridge are supported. The "little things" are what keep us from supporting them completely. A generic MCP55 port which loads the payload (additional board init etc.) over serial can be the ideal starting point.
Why? I don't really see a use for this. If someone is able to run such a payload, build LinuxBIOS, test patches etc. it's not much additional work to just add proper support for the board in the first place. No need for such a "test-payload", I think.
The "you can always reflash the old BIOS" feeling gives confidence to porters who might not have a replacement chip handy.
Ah, that thing. I think I misread the whole thread. Anyway, this would require a working flashrom-like implementation as payload (which in itself is a very cool thing and Someone Should Do It(tm)).
Can you elaborate? Where is the MAC address stored? On which boards? I doubt that all boards out there do this. What happens if you download a BIOS image from $VENDOR website? Does the flasher contain special code to deal with the MAC address?
The MAC address is stored in flash for almost all CK804/MCP55 boards. All of these boards flashed with LB probably have the same MAC address. See src/southbridge/nvidia/ck804/romstrap.inc and src/southbridge/nvidia/mcp55/romstrap.inc for details. On some of these boards, the MAC address is stored in a separate EEPROM, but you can't count on that.
Hm, good candidate for the wiki FAQ and for the flashrom README then. Can you create a patch for this?
Thanks, Uwe.
-
Carl-Daniel Hailfinger -
Chris Lingard -
Corey Osgood -
Darmawan Salihun -
echelon＠free.fr -
Joseph Smith -
Nathanael D. Noblet -
Peter Stuge -
popkonserve -
Quux -
Rasmus Wiman -
ron minnich -
ST -
Stefan Reinauer -
todthgie -
Uwe Hermann -
Ward Vandewege -
yhlu