Hi all,
I'm working on putting LinuxBIOS on an old ASUS P2B-L that I'd like to convert into an "instant-on" server for home use. It has an Intel 440BX Host Bridge with Intel PIIX4e hard disk controller, and a Winbond W83977TF SuperIO chip. I downloaded the manuals for these various chips, so I think I might have a shot at getting them working correctly as long as I can get some debug output on the serial port.
Since this will be a server, I don't need any video support, though I'd like to keep the card in the machine uninitialized for when I have to boot the factory BIOS. I've configured grub and the kernel to use the serial port as the console, which works OK. My plan is to use FILO as the LinuxBIOS payload.
I've installed a BIOS Savior in the machine and flashed it with another copy of the factory BIOS, which works OK, so (barring checks in the utility's code) I should be able to use the ASUS AFLASH program rather than flashrom.
First, I tried to build a FILO payload with serial console only and USE_GRUB=1, which didn't work - it looked like it was still trying to use the VGA console for some functions. It worked OK when I commented out the USE_GRUB line, but I'd still like to try the former configuration - any FILO experts have any tips on how to squash the VGA functions once and for all?
Then I grabbed the SVN trees for both v1 and v2. I copied the bitworks/ims mainboard and target directories, as they seemed to be using the 440bx code, and I'm slogging through changing the various bitworks & ims entries in the code to asus & p2bl entries. So far, so good, though I feel somewhat like I'm in a maze of twisty little passages, all alike.
My main question is: The W83977TF has support under v1, but not v2 - any tips on porting from one to the other? Also, once I have the superIO initialization code installed, is there some way to get some kind of debug output before RAM initialization? I'm not sure where to put my own debugging output into the code - just a "hello, I'm here" is all I need for starters. I'd be happy for pointers to some docs which might answer some of these questions - I perused some of what I could find in the SVN tree and wiki, but ended up just trying to jump right in instead.
Another big question would be - should I continue ahead with v2, or go back to v1? I noticed that v1 had the 440bx support as well, but it looked like v2's configuration setup was a lot easier to deal with, so I started there. Would it be worth it to learn how v1 does things for this project?
The other outstanding issue coming down the pike is that the machine has all ECC RAM. Is ECC supported by v1 or v2, and if not by either, which would make it easiest to add support? I'm assuming v2, but I'll try v1 if that would be easier.
Many thanks,
Don
stick with v2.
For a writeup on how to do a port, check out my two linux journal articles -- I am told they can be helpful.
Yes, it's complex. Sorry, that is one thing we want to make easier with v3.
ron
On 7/28/06, Don Waugaman dpw@email.cs.arizona.edu wrote:
Hi all,
I'm working on putting LinuxBIOS on an old ASUS P2B-L that I'd like to convert into an "instant-on" server for home use. It has an Intel 440BX
Excellent Looks like we are finally going to get the 440bx stuff working. ASUS however is a bit problematic. They hide the SMbus with a GPIO or something. More below.
Then I grabbed the SVN trees for both v1 and v2. I copied the bitworks/ims mainboard and target directories, as they seemed to be using the 440bx code, and I'm slogging through changing the various bitworks & ims entries in the code to asus & p2bl entries. So far, so good, though I feel somewhat like I'm in a maze of twisty little passages, all alike.
The learing curve is steep. Stick with it.
You are in luck. I've actually got booting code for my ASUS P2b. Both V1 and V2. In V1 you have to hammer in the RAM settings because like I said the SMbus is either not in the same location as the 440bx reference design or its hidden with a GPIO. We will proballly have to do a bit of sluthing work under a factory bios system and Linux to find out what GPIO does the magic.
In V2 its exactly the same as the Bitworks IMS suff with the superIO changed. Current issue is that again SMbus stuff is not working.
My main question is: The W83977TF has support under v1, but not v2 - any tips on porting from one to the other?
I've done this already. I'll push the code up in a few hours or so. Its on a machine I don't have local access to right now. Its pretty easy though just find an existing SuperIO in V2 copy over the structure and replace the names and guts of the functions with the stuff for the new SuperIO. The NSC chip that the Bitoworks IMS uses would be a good example.
kind of debug output before RAM initialization? I'm not sure where to put my own debugging output into the code - just a "hello, I'm here" is
After I push up the p2b stuff, you can look at it. Its got some debug output. The file you want to look at is auto.c. Thats the first part of your mainboard config that is run.
looked like v2's configuration setup was a lot easier to deal with, so I started there. Would it be worth it to learn how v1 does things for this project?
V2 totally. The only thing we are going to need V1 for is reference of a working set of code.
The other outstanding issue coming down the pike is that the machine has all ECC RAM. Is ECC supported by v1 or v2, and if not by either, which would make it easiest to add support? I'm assuming v2, but I'll try v1 if that would be easier.
Neither of the codebases support ECC for the 440BX. ECC is supported by other chips in V2 though so we do have examples. Can you run it in non-ECC (or scrape up some non-ECC Dimms) mode while we debug and get some base functionality up?
You are in luck. I've actually got booting code for my ASUS P2b. Both
My main question is: The W83977TF has support under v1, but not v2 - any tips on porting from one to the other?
I've done this already. I'll push the code up in a few hours or so. Its on a machine I don't have local access to right now.
I just committed my framework for the Asus P2B. Hopefully it works for you. It should come up and try to dump the contents of the SPD on the RAM. But like I said its broken even without the Asus magic. I'm going to try and work on that today and see if I can discover something.
So step one for P2B is to work with the board booted under factory BIOS and see if we can figure out what GPIO is used to enable the memory SMbus.
2.6 kernels know how to dump the SPD for a i440bx so see if you can do that. If that works then we just need to start comparing a northbridge dump of the Asus vs a non-asus 440bx and see if any of the GPIO are different.
On Sat, 2006-07-29 at 12:53 -0500, Richard Smith wrote:
You are in luck. I've actually got booting code for my ASUS P2b. Both
My main question is: The W83977TF has support under v1, but not v2 - any tips on porting from one to the other?
I've done this already. I'll push the code up in a few hours or so. Its on a machine I don't have local access to right now.
I just committed my framework for the Asus P2B. Hopefully it works for you. It should come up and try to dump the contents of the SPD on the RAM. But like I said its broken even without the Asus magic. I'm going to try and work on that today and see if I can discover something.
So step one for P2B is to work with the board booted under factory BIOS and see if we can figure out what GPIO is used to enable the memory SMbus.
2.6 kernels know how to dump the SPD for a i440bx so see if you can do that. If that works then we just need to start comparing a northbridge dump of the Asus vs a non-asus 440bx and see if any of the GPIO are different.
Thanks for your help on this, Richard!
This took a little longer than I expected due to my son's fourth birthday and having to change the p2b configuration to output via the second serial port (my board's first serial port has been flaky in the past), but I'm getting some results.
Here's what I get from i2cdump 0 0x5{0-3} under Linux running with the factory BIOS:
[root@matthias ~]# i2cdump 0 0x50 No size specified (using byte-data access) WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0, address 0x50, mode byte Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: 80 08 04 0c 0a 02 48 00 01 a0 60 02 80 08 08 01 ??????H.??`????? 10: 07 04 04 01 01 1f 0e 00 00 00 00 14 14 14 32 20 ???????....???2 20: 20 10 20 10 00 00 00 00 00 00 00 00 00 00 00 00 ? ?............ 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 be ..............?? 40: 7f 98 00 00 00 00 00 00 46 4b 47 4d 31 30 30 78 ??......FKGM100x 50: 37 32 52 43 33 2f 32 35 36 00 00 00 00 01 26 18 72RC3/256....?&? 60: 1a f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ??.............. 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 64 84 ..............d? 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ f0: 39 39 36 32 32 32 38 2d 30 30 31 2e 41 30 30 ff 9962228-001.A00.
[root@matthias ~]# i2cdump 0 0x51 No size specified (using byte-data access) WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0, address 0x51, mode byte Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: 80 08 04 0c 0a 02 48 00 01 a0 60 02 80 08 08 01 ??????H.??`????? 10: 07 04 04 01 01 1f 0e 00 00 00 00 14 14 14 32 20 ???????....???2 20: 20 10 20 10 00 00 00 00 00 00 00 00 00 00 00 00 ? ?............ 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 be ..............?? 40: 7f 98 00 00 00 00 00 00 46 4b 47 4d 31 30 30 78 ??......FKGM100x 50: 37 32 52 43 33 2f 32 35 36 00 00 00 00 01 23 18 72RC3/256....?#? 60: 04 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?%.............. 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 64 84 ..............d? 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
[root@matthias ~]# i2cdump 0 0x52 No size specified (using byte-data access) WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0, address 0x52, mode byte Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: 80 08 04 0c 0a 02 48 00 01 a0 60 02 80 08 08 01 ??????H.??`????? 10: 07 04 04 01 01 1f 0e 00 00 00 00 14 14 14 32 20 ???????....???2 20: 20 10 20 10 00 00 00 00 00 00 00 00 00 00 00 00 ? ?............ 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 be ..............?? 40: 7f 98 00 00 00 00 00 00 46 4b 47 4d 31 30 30 78 ??......FKGM100x 50: 37 32 52 43 33 2f 32 35 36 00 00 00 00 01 23 1c 72RC3/256....?#? 60: 04 b8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ??.............. 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 64 84 ..............d? 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
[root@matthias ~]# i2cdump 0 0x53 No size specified (using byte-data access) WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0, address 0x53, mode byte Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: 80 08 04 0c 0a 02 48 00 01 a0 60 02 80 08 08 01 ??????H.??`????? 10: 07 04 04 01 01 1f 0e 00 00 00 00 14 14 14 32 20 ???????....???2 20: 20 10 20 10 00 00 00 00 00 00 00 00 00 00 00 00 ? ?............ 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 be ..............?? 40: 7f 98 00 00 00 00 00 00 46 4b 47 4d 31 30 30 78 ??......FKGM100x 50: 37 32 52 43 33 2f 32 35 36 00 00 00 00 02 21 01 72RC3/256....?!? 60: 26 7c 26 00 00 00 00 00 00 00 00 00 00 00 00 00 &|&............. 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 64 84 ..............d? 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ f0: 39 39 36 32 32 32 38 2d 30 30 31 2e 41 30 30 00 9962228-001.A00.
These probes are byte-for-byte identical with what the p2b target LinuxBIOSv2 outputs when I flash it and start up my system.
When I ran the program to setup lm_sensors, I got this:
Driver `lm78' (may not be inserted): Misdetects: * Bus `SMBus PIIX4 adapter at e800' (Algorithm unavailable) Busdriver `i2c-piix4', I2C address 0x2d ISA bus address 0x0290 (Busdriver `i2c-isa') Chip `National Semiconductor LM78' (confidence: 6)
Driver `w83781d' (should be inserted): Detects correctly: * Bus `SMBus PIIX4 adapter at e800' (Algorithm unavailable) Busdriver `i2c-piix4', I2C address 0x2d (and 0x48 0x49) ISA bus address 0x0290 (Busdriver `i2c-isa') Chip `Winbond W83781D' (confidence: 8)
Driver `eeprom' (should be inserted): Detects correctly: * Bus `SMBus PIIX4 adapter at e800' (Algorithm unavailable) Busdriver `i2c-piix4', I2C address 0x50 Chip `SPD EEPROM' (confidence: 8) * Bus `SMBus PIIX4 adapter at e800' (Algorithm unavailable) Busdriver `i2c-piix4', I2C address 0x51 Chip `SPD EEPROM' (confidence: 8) * Bus `SMBus PIIX4 adapter at e800' (Algorithm unavailable) Busdriver `i2c-piix4', I2C address 0x52 Chip `SPD EEPROM' (confidence: 8) * Bus `SMBus PIIX4 adapter at e800' (Algorithm unavailable) Busdriver `i2c-piix4', I2C address 0x53 Chip `SPD EEPROM' (confidence: 8)
So - does this mean that the w83781d is controlling the memory SMBUS, since it's detected correctly?
Also, you mentioned a couple of changes to the 440bx code that you'd like to do. Would it be OK for me to take a shot at these changes - probably tonight or tomorrow - as a way to get my feet wet with the codebase and hopefully make a small contribution? I'd guess that the southbridge name change would be pretty trivial, but the other change might need a little more smarts - but I'd like to take a shot at 'em.
Take care,
Don
This took a little longer than I expected due to my son's fourth
No rush we got lots of time.
These probes are byte-for-byte identical with what the p2b target LinuxBIOSv2 outputs when I flash it and start up my system.
Well thats a positive sign. I don't know for a _fact_ that the asus p2b has the smbus hidden. Back when I was messing with that under V1 (several years ago) there were reports on the list that asus motherboards did funky things with the smbus. I took working V1 bitworks/IMS code and brought it up on a p2b (rev 1.04) with the exact same memory and memory didn't fly. Hardcoding the memory settings made it work fine. That + reports of asus smbus funkyness led me to believe that the smbus was as fault. At the time hardcoding the memory was fine for what I needed to test so I didn't persue it any further.
You are reporting that the spd reads work you under linuxbios. Correct? If thats the case then perhaps my V1 issues were code problems and not hardware smbus problems. Which is good. I've still got that p2b so I'll test and see if I get the same results as you.
So - does this mean that the w83781d is controlling the memory SMBUS, since it's detected correctly?
I don't think so. The W83781D is a hardware monitor chip and looking at the datasheet I don't see the ability to be an I2C master. What I think that is telling you is that the W83781D ISA's interface (it has I2C and ISA) is also available at IO 0x0290.
The spd read code only talks to the PIIX4 and you got data back from that so the W83781D really doesn't matter.
Also, you mentioned a couple of changes to the 440bx code that you'd like to do. Would it be OK for me to take a shot at these changes - probably tonight or tomorrow - as a way to get my feet wet with the codebase and hopefully make a small contribution? I'd guess that the southbridge name change would be pretty trivial, but the other change might need a little more smarts - but I'd like to take a shot at 'em.
Sure. Any and all help is very welcome.
Lets go with Stefan's suggestion and name the southbridge chip after its actual ID. i82371eb. Thats a pretty easy change.
The RAM init re-base is pertty much the same. Copy the raminit.c and raminit.h from the intel/e7501 on top of the raminit.[ch] thats there and then go though and fixup any specific e7501 names.
Then the hard part starts. We have to go though and start walking the ram init chain and make each one of those steps match the 440bx using the V1 assembly as a guide. The e7501 appears to be a DDR controller with 2 channels but its very well documented and I like the structure. It looks much nicer than the via example I used previously.
hardware smbus problems. Which is good. I've still got that p2b so I'll test and see if I get the same results as you.
I pulled out my old p2b board and manged to find all the stuff to make it boot. Then ran the current V2 p2b target build.
Indeed it dumps the SPD out just fine. So yah! Thats good news. My V1 stuff must have had some other issue that kept the RAM from getting detected properly.
On Thu, 2006-08-03 at 10:13 -0500, Richard Smith wrote:
hardware smbus problems. Which is good. I've still got that p2b so I'll test and see if I get the same results as you.
I pulled out my old p2b board and manged to find all the stuff to make it boot. Then ran the current V2 p2b target build.
Indeed it dumps the SPD out just fine. So yah! Thats good news. My V1 stuff must have had some other issue that kept the RAM from getting detected properly.
Good to hear you're getting the same results!
Since you straightened me on what to expect, I went ahead and changed the southbridge/i440bx to i82371eb, and recompiled all the 440bx targets I could find (successfully, except that the eaglelion/5bcm tried to look for a payload under /home/hamish, which for some reason didn't exist on my system :-). I've attached a patch for this - could you review and commit for me? I think it may require some svn magic to copy/remove the old 440bx directory and files - I'm not sure how well just applying the diffs here will work (I'm an svn newbie).
I'll tackle rebasing the RAM init on the e7501 next.
Thanks,
Don
my system :-). I've attached a patch for this - could you review and commit for me?
The diffs look good. You got the idea. However......
I think it may require some svn magic to copy/remove the old 440bx directory and files - I'm not sure how well just applying the diffs here will work (I'm an svn newbie).
They won't apply. :( The i8371eb/* files don't exist in the tree so the patch that modifies them fails.
The reason doesn't appear to be your fault. Did you use svn move or svn copy? Reading the svn docs indicates that svn diff does _not_ understand moves and copys. That's listed as a post 1.0 feature. So your diffs remove all the i440bx stuff but don't create the i82371eb files.
The rest of your diffs that modify existing config files are ok.
Looks like I'll have to do the remove of the old files.
I played around with a copy of the tree and here's how I think you need to create the diffs for this instance. Stefan? Ron? Do you have any suggestions?
1) Copy (filesystem cp not svn copy) your current i82371eb dir to i82371eb.orig 1.1) Look in i82371eb.orig and remove the .svn directory if there is one. 2) svn remove your i82371eb directory. You may have to use the --force option if it wines about uncommitted changes. 3) rm -rf your i440bx dir if it exists. 4) svn update. Now you should be back to what you had before your changes with an extra i82371eb.orig directory in there 5) mkdir i82371eb 6) cp i82371eb.orig/* i82371eb 7) svn add i82371eb 8) svn diff and send in the patch.
That should generate a diff that adds all the new files and keeps the mods you made to the other config files.
I will then apply the patch to my local copy and if it all looks good then I'll do a svn remove on the i440bx dir and commit.
* Richard Smith smithbone@gmail.com [060804 08:41]:
I think it may require some svn magic to copy/remove the old 440bx directory and files - I'm not sure how well just applying the diffs here will work (I'm an svn newbie).
They won't apply. :( The i8371eb/* files don't exist in the tree so the patch that modifies them fails.
Grr ;-) Never cut and paste from emails.. it's the 82371eb ;-))
So your diffs remove all the i440bx stuff but don't create the i82371eb files.
I renamed the files in the tree, to enable clean diffs here. It's untested and may fail, but it should make things easier.
Can you please send a diff against r2363?
Hope this helps ..
Stefan
I renamed the files in the tree, to enable clean diffs here. It's untested and may fail, but it should make things easier.
Can you please send a diff against r2363?
Hope this helps ..
Thanks. Looks like it will work to me and should clean up the diffs. Don had indicated that he wanted to do the diffs to start comming up to speed on things. So thats why I just didn't do the renames myself. I was going to let him go back through the process as an exercise to the reader. :)
But theres plenty more to do so on to the next.
Hi,
It's fantastic to see progress on a port to v2 for the 440BX, I had v1 working for a total of 5 minutes, about a year ago, which left me wanting more!
I've got two Asus P2B here, some P2-99, and a P2B-F.
I did an SVN checkout, configured an Etherboot payload, and flashed to SST 29F002 with Uniflash, to a P2B:
LinuxBIOS-2.0.0.0Fallback Sun Oct 1 22:50:50 EDT 2006 starting... SMBus controller enabled
dimm: 00.0: 50 00: 80 08 04 0c 09 01 40 00 01 75 54 00 80 10 00 01 10: 8f 04 04 01 01 00 0e 00 00 00 00 14 0e 14 2d 10 20: 15 08 15 08 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 a3 40: 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 50: 53 41 30 33 30 30 39 00 00 00 00 00 00 00 00 00 60: 00 00 00 4d 53 33 38 36 34 55 50 53 2d 54 38 36 70: 41 33 00 00 00 00 00 00 00 00 00 00 00 00 64 cd 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff dimm: 01.0: 51 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ..... the rest (dimm 1-3) are all 0xff, then: ..... Copying LinuxBIOS to ram. Jumping to LinuxBIOS.
my PCI POST card displays 12.
I tried a 64, 128, and 256MB module.
Any suggestions?
Regards,
Jeremy
PS - After I get this going, Tyan S2865 is next.
On Sat, 2006-07-29 at 08:24 -0500, Richard Smith wrote:
I've done this already. I'll push the code up in a few hours or so. Its on a machine I don't have local access to right now. Its pretty easy though just find an existing SuperIO in V2 copy over the structure and replace the names and guts of the functions with the stuff for the new SuperIO. The NSC chip that the Bitoworks IMS uses would be a good example.
....
After I push up the p2b stuff, you can look at it. Its got some debug output. The file you want to look at is auto.c. Thats the first part of your mainboard config that is run.
Copying LinuxBIOS to ram. Jumping to LinuxBIOS.
my PCI POST card displays 12.
I tried a 64, 128, and 256MB module.
Any suggestions?
Yeah. Add the code to actually do the ram init. :) The current setup is broken. Don't mess with it any further.
However, don't fear. We are all here at the Linux Symposium and we have at least 2 asus P2B's. A goal for either tonight or tomorrow evening is to make RAM init code work on the i440bx.
-
Don Waugaman -
Jeremy Jackson -
Richard Smith -
Ronald G Minnich -
Stefan Reinauer