Hi,
Quick (cheeky) question: does LinuxBIOS support the 440LX chipset?
MSI/AMI no longer support it (probably for some time now), and the most recent BIOS has some difficulty with "large" disks: anything much over 3G kills the boot sequence.
Cheers,
Paul.
PS I'm getting a 404 when trying to fill in the help web-form: /cgi-bin/linuxbios/help.cgi not found.
PPS output from lspci: 0000:00:00.0 Host bridge: Intel Corp. 440LX/EX - 82443LX/EX Host bridge (rev 03) 0000:00:01.0 PCI bridge: Intel Corp. 440LX/EX - 82443LX/EX AGP bridge (rev 03) 0000:00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02) 0000:00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) 0000:00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) 0000:00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02) 0000:00:0e.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev08) 0000:00:0f.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 0000:00:10.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 0000:01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage IIC AGP (rev 3a)
Quick (cheeky) question: does LinuxBIOS support the 440LX chipset?
I don't know what the difference between the 440LX and BX is Buta as long as the ram registers are the same the 440bx stuff should work fine. Unless they have done something messy with the access to the SPD on the ram.
PPS output from lspci:
What superIO is on it? if your superIO supported then V1 should at least come up and try to setup the ram. If not then the differences might be pretty easy to work out by some northbridge dumps.
On Thursday 10 February 2005 21:31, you wrote:
Quick (cheeky) question: does LinuxBIOS support the 440LX chipset?
I don't know what the difference between the 440LX and BX is Buta as long as the ram registers are the same the 440bx stuff should work fine. Unless they have done something messy with the access to the SPD on the ram.
I've no idea either, but I'll try and give it a shot. It'll probably be Sunday before I get the chance to do anything, though.
PPS output from lspci:
What superIO is on it? if your superIO supported then V1 should at least come up and try to setup the ram. If not then the differences might be pretty easy to work out by some northbridge dumps.
OK, asking the great Google in the sky: "MS-6117 superio" resulted in a single hit, with the following line. Superio: Winbond 977TF rev 0 found at port 3F0h (I can probably verify that by eyeball the motherboard at some point)
Does that sound promising?
Cheers,
Paul.
I don't know what the difference between the 440LX and BX is Buta as long as the ram registers are the same the 440bx stuff should work fine. Unless they have done something messy with the access to the SPD on the ram.
I just look on developer.intel.com and fouind the 440LX datasheet. At my (really) quick glance it looks very similar to the BX. You might just get lucky and have it come up and work.
What's the FSB speed of that board? Can it do 100Mhz or only 66?
I've no idea either, but I'll try and give it a shot. It'll probably be Sunday before I get the chance to do anything, though.
Ok I would suggest that you start with a copy of the bitworks board. (mainboard/bitworks/ims) change the superIO and rework the ROM size to match your board and work from there.
OK, asking the great Google in the sky: "MS-6117 superio" resulted in a single hit, with the following line. Superio: Winbond 977TF rev 0 found at port 3F0h (I can probably verify that by eyeball the motherboard at some point)
Does that sound promising?
Yes. Theres a few number missing but thats probally a w83977tf. Theres a w83977ef in the tree. I'm sure the differences between the tf and ef are really minor. But check your number and google for the datasheet on the part.
Let me send you my config file. I't probally won't compile against the stock V1 tree since I think I've added several config options for my own use but those should be pretty easy to fix.
On Friday 11 February 2005 16:33, Richard Smith wrote:
I just look on developer.intel.com and fouind the 440LX datasheet. At my (really) quick glance it looks very similar to the BX. You might just get lucky and have it come up and work.
Fingers crossed!
What's the FSB speed of that board? Can it do 100Mhz or only 66?
I while back I searched for BIOS upgrades for Janus' MSI 6117 motherboard. I found out that it was already at the most recent version, but I also found a set of the manuals. I've dug them out and placed them, temporarily, at [1]
[1] - http://www.astro.gla.ac.uk/users/paulm/Janus/
It looks like the motherboard supports only "officially" the 66MHz FSB.
The installation manual (6117-2.pdf) mentions support for 68MHz and 75MHz, but these are "reserved functions", whatever that means ;^)
Ok I would suggest that you start with a copy of the bitworks board. (mainboard/bitworks/ims) change the superIO and rework the ROM size to match your board and work from there.
OK, I'll give that a bash.
BTW, I've now acquired a genuine 440BX machine that I can play with without worrying about destroying it. I'm currently installing Debian on it and bringing it up to speed. Once that's done, I'll try flashing a LinuxBIOS and see how it goes.
Some questions, probably FAQ-like (sorry). I currently have the existing BIOS booting GRUB off the MBR (on both machines)
1a. LinuxBIOS can be flashed with one of several different targets, right?
1b. Do I want to use FILO as the target inside the LinuxBIOS?
2. I can't use FILO to simply chain-boot grub because either grub does BIOS calls that LinuxBIOS doesn't support, grub expects to be in real-mode, or some other problem. Is that right?
3. Does FILO support loading some configuration information off the disk, like grub does?
4. Does FILO follow symbolic links (on an ext2 filesystem) OK? My (rough) plan is to have a sym-link off the root directory pointing to the current kernel image.
A random extra bit of info, I just found this page: http://www.openbios.org/development/devbios.html
I haven't tried it yet, but if it works, it would make flashing new images a lot easier. A link from your web-page might be a good idea.
Does [winbond 977TF rev 0] sound promising?
Yes. Theres a few number missing but thats probally a w83977tf. Theres a w83977ef in the tree. I'm sure the differences between the tf and ef are really minor. But check your number and google for the datasheet on the part.
The summary table from [2] shows the two with only superficial differences:
W83977TF W83877TF plus KBC, GP I-O, Wake-Up W83977EF W83877TF plus KBC, GP I-O, Wake-Up, Power Fail Resume
... although the Power Fail Resume function sounds like the what-to do-if-the-power-fails option in the AMI BIOS. On Janus, this currently doesn't work. It would be handy if it, but hey ho.
[2] - http://www.datasheetarchive.com/datasheet/pdf/5256.html
Let me send you my config file. I't probally won't compile against the stock V1 tree since I think I've added several config options for my own use but those should be pretty easy to fix.
Ta,
Paul.
* Paul Millar paulm@astro.gla.ac.uk [050211 23:39]:
A random extra bit of info, I just found this page: http://www.openbios.org/development/devbios.html
I haven't tried it yet, but if it works, it would make flashing new images a lot easier. A link from your web-page might be a good idea.
It's not really up to date. I've got the impression that freebios2/util/flash_and_burn/ works better.
On Saturday 12 February 2005 11:20, Stefan Reinauer wrote:
- Paul Millar paulm@astro.gla.ac.uk [050211 23:39]:
A random extra bit of info, I just found this page: http://www.openbios.org/development/devbios.html
I haven't tried it yet, but if it works, it would make flashing new images a lot easier. A link from your web-page might be a good idea.
It's not really up to date. I've got the impression that freebios2/util/flash_and_burn/ works better.
OK, but this is *precisely* the information that should go in the FAQ. One of the first questions (at least for me) was: if I build LinuxBIOS, how do I "run" it?
If I've got this right the answer is: 1. that softboot thing (utility that loads the image into memory and runs it instead of halt/reboot, from /etc/init.d/S99halt)
2. Flashing via the motherboard: 2.0 procedure for flashing an external EEPROM using mobo 2.1 flash using flash_and_burn util (in freebios2) [recommended] 2.2 flash using OpenBIOS /dev/bios support 2.3 flash using 2.6-kernel MTD mobo-BIOS flash support 2.4 flash using freebios/util/sis 2.5 flash using Intel's System Update Package (this still exist?)
3. flash using external EEPROM burner: 3.1 Devices that work under Linux: 3.1.1 burn-u-like-it [link] ... 3.2 Other computer-controlled devices (boot under Windows?): 3.2.1 burn-with-gates [link] ,,, 3.3 Stand-alone devices: 3.3.1 Needham Electronics EMP 30 [link] 3.3.1 Nero's Fiddle 100 [link]
On Thu, 10 Feb 2005, Paul Millar wrote:
Quick (cheeky) question: does LinuxBIOS support the 440LX chipset?
no, sorry, I think it should be easy but it's not been of interest to anyone.
ron
On Friday 11 February 2005 16:25, Ronald G. Minnich wrote:
On Thu, 10 Feb 2005, Paul Millar wrote:
Quick (cheeky) question: does LinuxBIOS support the 440LX chipset?
no, sorry, I think it should be easy but it's not been of interest to anyone.
No problem. I'm happy to "go it alone" if you don't mind me asking a stoopid questions.
Cheers,
Paul.
On Fri, 11 Feb 2005, Paul Millar wrote:
No problem. I'm happy to "go it alone" if you don't mind me asking a stoopid questions.
there are no stupid questions, this stuff is hard. We would be very grateful for your help. I would start with richard smith's 440bx port on V2.
and, uh, as always, anybody want to help with the web page?
ron
there are no stupid questions, this stuff is hard. We would be very grateful for your help. I would start with richard smith's 440bx port on V2.
Yeah that would be great.. _If_ it worked. I got stuck getting data back from the SM controller. Its really wierd. I can see data happening on the SMbus with a scope but I always get zeros back when I try to dump the SPD values.
I had to back burner it for now... Its really hard to justify spending the time on moving to V2 when V1 pretty much does what we need. I'll get it eventually though.
Paul? How are your hacking skills? Do you write C code? I could sure use the help in the V2 port. The southbridge between the BX and LX family is exactly the same chip so anything you did would be 100% re-useable.
On Friday 11 February 2005 20:31, Ronald G. Minnich wrote:
On Fri, 11 Feb 2005, Paul Millar wrote:
No problem. I'm happy to "go it alone" if you don't mind me asking a stoopid questions.
there are no stupid questions, this stuff is hard.
Believe me, I'm sure I can find some ;^)
We would be very grateful for your help.
Always happy to try stuff; also, I'm curious to how usable it is at the moment.
I would start with richard smith's 440bx port on V2.
Silly question #1: what is V1 and V2? Do these map to the two modules under sourceforge CVS: freebios and freebios2? Which tree is better to use and more likely to work?
and, uh, as always, anybody want to help with the web page?
May I recommend having a wiki?
I've used them with a few projects and they make updating information a lot less hassle, so info stays up-to-date.
HTH,
Paul.
On Fri, 11 Feb 2005, Paul Millar wrote:
Silly question #1: what is V1 and V2? Do these map to the two modules under sourceforge CVS: freebios and freebios2? Which tree is better to use and more likely to work?
V1 was the first go-around. The increasing complexity of chipsets etc. and our better understanding of how things ought to work led to v2. You want ot use v2. co freebios2, not freebios
May I recommend having a wiki?
I'll see what stefan thinks.
ron
* Ronald G. Minnich rminnich@lanl.gov [050212 00:27]:
May I recommend having a wiki?
I'll see what stefan thinks.
A rather thought about closing dowd the existing linuxbioswiki http://openbios.org/linuxbioswiki since it was never used.
Maybe people did not feel well with "moinmoin wiki" but would rather prefer Plone or another system.
Whatever people prefer, we can do it. Static pages seem more robust in _my_ opinion, but I am for sure no hero when it comes down to updating web _content_ regularly ;)
No matter what, the solution in the end should suit the people who feed the web pages with new information.
The OpenBIOS web site is kept in an arch repository (could be any other versioning system) and can be updated on checkin to the repository.
Have a look at http://www.openbios.org/cgi-bin/viewarch.cgi/stepan@openbios.org--devel/open... to get an idea how the web page content is stored.
Stefan
On Saturday 12 February 2005 11:18, you wrote:
- Ronald G. Minnich rminnich@lanl.gov [050212 00:27]:
May I recommend having a wiki?
I'll see what stefan thinks.
A rather thought about closing dowd the existing linuxbioswiki http://openbios.org/linuxbioswiki since it was never used.
Err.. I didn't know this existed. I didn't find any links to this wiki off of the LinuxBIOS pages.
Assuming that's not atypical, that might explain why its never used....
Maybe people did not feel well with "moinmoin wiki" but would rather prefer Plone or another system.
I've used PHPWiki (mainly because it has "php" in the title ;) and it was the first one I tried. From a casual glance, there doesn't look to be anything wrong with moinmoin: it does things slightly differently to PHP but the learning curve looks to be a pretty simple one.
Whatever people prefer, we can do it. Static pages seem more robust in _my_ opinion, but I am for sure no hero when it comes down to updating web _content_ regularly ;)
I agree that static pages are generally more "robust", but the problem is one needs to make pages easy to edit (kind of anti-robust, although not the same). Otherwise the information on the page starts to rot.
Currently, there's *lots* of badly formatted (or at least badly copy-and-pasted) information on the pages, broken links, ... in LinuxBIOS. The FAQ suffers quite badly from this.
No matter what, the solution in the end should suit the people who feed the web pages with new information.
Agreed.
The OpenBIOS web site is kept in an arch repository (could be any other versioning system) and can be updated on checkin to the repository.
Have a look at http://www.openbios.org/cgi-bin/viewarch.cgi/stepan@openbios.org--d evel/openbios--website--1.0--patch-27/ to get an idea how the web page content is stored.
Fair enough; but who has commit access to the repository? How difficult is it (or how much time does it take) to get write access to the web pages?
I'm particularly looking at the LinuxBIOS pages, rather than the OpenBIOS ones, as the OpenBIOS pages seem to be well formated, edited and contain useful information.
For LinuxBIOS, one model you might like to consider is to have two tiers (or types) of information: officially sanctioned web pages (a la arch, cvs or whatever), and a more liberal access-policy wiki-like scribble area.
HTH,
Paul.
Silly question #1: what is V1 and V2? Do these map to the two modules under sourceforge CVS: freebios and freebios2? Which tree is better to use and more likely to work?
V1 is the only tree that can work. I haven't even given anybody my V2 patches which don't work yet anyway. So V1 is currently your only option.
-
Paul Millar -
Richard Smith -
Ronald G. Minnich -
Stefan Reinauer