This patch includes config files for the asus/a8n5x port. It is the same as asus/a8n_e with a different pnp layout, so I used #include's whenever possible.
System boots and is usable with usb keyboard.
works:
- serial port - vga (old pci card) - memtest86+ succeeds, but only with Rudolf's patch for unbuffered dimms in K8. Otherwise you get spurious memory corruption. - ide disk - usb
doesn't:
- ps/2 keyboard - onboard ethernet - vga pci-e card (??) - any other pci card I tried
wasn't tested:
- sata - game port - onboard audio (not supported by alsa anyway) - ps/2 mouse
On Tue, Sep 25, 2007 at 10:11:12PM +0200, Robert Millan wrote:
doesn't:
- ps/2 keyboard
- onboard ethernet
uhm actually, onboard ethernet does work; the MAC change just broke my ifrename setup.
Robert, I understand the reason for the include of the .c files, but go ahead and just copy the code. We've tried both ways, over the years, and it's better to clone the code, since the vendors have a habit of changing things on mainboards, and code that includes other code can cause trouble in both directions.
Thanks very much for doing this port.
ron
On Tue, Sep 25, 2007 at 03:53:21PM -0700, ron minnich wrote:
Robert, I understand the reason for the include of the .c files, but go ahead and just copy the code. We've tried both ways, over the years, and it's better to clone the code, since the vendors have a habit of changing things on mainboards, and code that includes other code can cause trouble in both directions.
Ok. Here's an updated patch (with the new svn recipe included).
[Sorry for being late, I'm a bit, um... Internet-challenged at the moment. No PGP signature for the same reason.]
On Wed, Sep 26, 2007 at 11:50:52AM +0200, Robert Millan wrote:
On Tue, Sep 25, 2007 at 03:53:21PM -0700, ron minnich wrote:
Robert, I understand the reason for the include of the .c files, but go ahead and just copy the code. We've tried both ways, over the years, and it's better to clone the code, since the vendors have a habit of changing things on mainboards, and code that includes other code can cause trouble in both directions.
I strongly disagree with this approach. Duplicated code is bad, bad, bad and should be avoided whereever possible.
Now, in order to not only complain, here's a demo patch which completely avoids copying a single file. One code base for the
- ASUS A8N-E - ASUS A8N5X - ASUS A8NE-FM/S (I'll send an extra patch for that later)
No duplicated code whatsoever. Sure, this may not be too elegant (there's some room for improvements, though), but it's definately a _lot_ better than duplicating all those files.
This is (manually) build-tested for the A8N-E and A8N5X and worked for me. I did not test the produced ROMs, though.
In addition to the patch, you need to create a symlink src/mainboard/asus/a8n_e -> src/mainboard/asus/a8n5x in order to make the build system happy.
Uwe.
* Uwe Hermann uwe@hermann-uwe.de [070927 19:14]:
No duplicated code whatsoever. Sure, this may not be too elegant (there's some room for improvements, though), but it's definately a _lot_ better than duplicating all those files.
Another question: If that code needs to be duplicated for each of those boards, is it generic (NB, SB, SUPERIO) code?
+if CONFIG_BOARD_A8N_E
ouch.. this is really nasty ;-)
And it will potentially make it hard for us in v3..
+if CONFIG_BOARD_A8N5X
- device pci_domain 0 on # PCI domain
- chip northbridge/amd/amdk8 # mc0
device pci 18.0 on # Northbridge# Devices on link 0, link 0 == LDT 0chip southbridge/nvidia/ck804 # Southbridgedevice pci 0.0 on end # HTdevice pci 1.0 on # LPCchip superio/ite/it8712f # Super I/Odevice pnp 2e.7 off # Floppyio 0x60 = 0x3f0irq 0x70 = 6drq 0x74 = 2enddevice pnp 2e.8 on # Com1io 0x60 = 0x3f8irq 0x70 = 4enddevice pnp 2e.9 on # Parallel portio 0x60 = 0x378irq 0x70 = 7drq 0x74 = 3enddevice pnp 2e.a on # PS/2 keyboardio 0x60 = 0x60io 0x62 = 0x64irq 0x70 = 1irq 0x71 = 2enddevice pnp 2e.b off end # Midi portdevice pnp 2e.c off end # Game portendenddevice pci 1.1 on # SM 0# chip drivers/generic/generic #dimm 0-0-0# device i2c 50 on end# end# chip drivers/generic/generic #dimm 0-0-1# device i2c 51 on end# end# chip drivers/generic/generic #dimm 0-1-0# device i2c 52 on end# end# chip drivers/generic/generic #dimm 0-1-1# device i2c 53 on end# end# chip drivers/generic/generic #dimm 1-0-0# device i2c 54 on end# end# chip drivers/generic/generic #dimm 1-0-1# device i2c 55 on end# end# chip drivers/generic/generic #dimm 1-1-0# device i2c 56 on end# end# chip drivers/generic/generic #dimm 1-1-1# device i2c 57 on end# endenddevice pci 2.0 on end # USB 1.1device pci 2.1 on end # USB 2device pci 4.0 off end # Onboard audio (ACI)device pci 4.1 off end # Onboard modem (MCI)device pci 6.0 on end # IDEdevice pci 7.0 on end # SATA 1device pci 8.0 on end # SATA 0device pci 9.0 on end # PCIdevice pci a.0 on end # NICdevice pci b.0 on end # PCI E 3device pci c.0 on end # PCI E 2device pci d.0 on end # PCI E 1device pci e.0 on end # PCI E 0register "ide0_enable" = "1"register "ide1_enable" = "1"register "sata0_enable" = "1"register "sata1_enable" = "1"# register "mac_eeprom_smbus" = "3"# register "mac_eeprom_addr" = "0x51"endenddevice pci 18.1 on enddevice pci 18.2 on enddevice pci 18.3 on end- end
- end
+end
+end # if
On Thu, Sep 27, 2007 at 08:31:16PM +0200, Stefan Reinauer wrote:
- Uwe Hermann uwe@hermann-uwe.de [070927 19:14]:
No duplicated code whatsoever. Sure, this may not be too elegant (there's some room for improvements, though), but it's definately a _lot_ better than duplicating all those files.
Another question: If that code needs to be duplicated for each of those boards, is it generic (NB, SB, SUPERIO) code?
Parts of it, maybe. Didn't look closer, yet. Common component code should be moved into the respective directory/files, of course. But there'll still be many files/parts which are not common to the chipsets but rather common to some (very similar) mainboards. That can (and should IMO) be handled with a method similar to the one in my patch.
In this case, we could even rename the A8N-E directory to 'a8n-base' or something, and make a8n-e, a8n5x, a8ne_fm_s be symlinks with only minor differences in targets/*.
+if CONFIG_BOARD_A8N_E
ouch.. this is really nasty ;-)
Yeah, not exactly elegant.
I didn't figure out how to do something like
if BOARD_NAME == "A8N-E" ... end
in Config.lb, that would improve the code (number of variables) a bit.
And it will potentially make it hard for us in v3..
On the contrary, I think with kconfig we can handle this sort of things even more easily and elegantly.
We even already have MAINBOARD_NAME etc. there, and those macros can be used in Makefiles as well as C code, so no problem at all.
Uwe.
On Thu, Sep 27, 2007 at 07:14:08PM +0200, Uwe Hermann wrote:
[Sorry for being late, I'm a bit, um... Internet-challenged at the moment. No PGP signature for the same reason.]
On Wed, Sep 26, 2007 at 11:50:52AM +0200, Robert Millan wrote:
On Tue, Sep 25, 2007 at 03:53:21PM -0700, ron minnich wrote:
Robert, I understand the reason for the include of the .c files, but go ahead and just copy the code. We've tried both ways, over the years, and it's better to clone the code, since the vendors have a habit of changing things on mainboards, and code that includes other code can cause trouble in both directions.
I strongly disagree with this approach. Duplicated code is bad, bad, bad and should be avoided whereever possible.
If we look at it in perspective, I think the cons for each option can be summarised as:
- duplicate: someone might waste time debugging/implementing/fixing something that was already done at the other branch. - include: someone might break board A in a commit that was only tested on board B.
AFAICS, the second is no big deal, it just takes a regression test which is something even I can do ;-)
On 9/27/07, Robert Millan rmh@aybabtu.com wrote:
- include: someone might break board A in a commit that was only tested on board B.
I can only say it's been a huge problem in the past. I've had cases where I tried to rebuild linuxbios for an older board, only to find that "improvements" in "common" code rendered the board unbootable. this is a particular problem for supermicro motherboards, which change in trivial ways all the time. An irq table that is common to two boards may not be a few months later. If the newer board is changed, the older board is broken. This really happened to me.
Where a bios is concerned, the goal of common code can cause trouble.
that said, I think uwe's approach is really interesting. And I'm happy to yield on this issue, having stated my opinion. So, please don't include .c files in other files, but do what you think best otherwise.
thanks!
ron
On Thu, Sep 27, 2007 at 02:46:09PM -0700, ron minnich wrote:
On 9/27/07, Robert Millan rmh@aybabtu.com wrote:
- include: someone might break board A in a commit that was only tested on board B.
I can only say it's been a huge problem in the past. I've had cases where I tried to rebuild linuxbios for an older board, only to find that "improvements" in "common" code rendered the board unbootable. this is a particular problem for supermicro motherboards, which change in trivial ways all the time. An irq table that is common to two boards may not be a few months later. If the newer board is changed, the older board is broken. This really happened to me.
Sure, there will be such cases, but that's a bug then anyway. If someone breaks the code that's either (a) a bug, or (b) a sign that the "common" code wasn't really common in the first place and should be moved respectively.
This should not affect _users_ all too much (there's always svn, you can always checkout older/working versions, see also http://linuxbios.org/Confirmed_working_svn_revisions, which we could expand maybe). We also have abuild, and the hardware test suite which (I hope) will have a bunch of machines integrated sooner or later.
Upon the occurence of such an issue the _developers_ just Fix It (tm) and that's it. Not a big deal, IMHO.
Note: I _do_ understand your reasoning, and yes, this type of bugs may occur, but common code is still the better route IMO, and svn will save our ass until such bugs are fixed...
Uwe.
OK, these mobos are close enough to each other to share most code. Let me throw out a challenge to this group. Make the bios image that runs on each board *IDENTICAL*. You can figure out what each board is -- can you tell by which superio it is or something? -- and then case out in runtime.
Why is this good? Because a vendor can see that with proper design, a single bios image can support many mainboards -- even if the hardware differs slightly -- thus reducing the cost.
We've talked about this for years, never done it. Is this the time?
thanks
ron
On 9/28/07, ron minnich rminnich@gmail.com wrote:
OK, these mobos are close enough to each other to share most code. Let me throw out a challenge to this group. Make the bios image that runs on each board *IDENTICAL*. You can figure out what each board is -- can you tell by which superio it is or something? -- and then case out in runtime.
Why is this good? Because a vendor can see that with proper design, a single bios image can support many mainboards -- even if the hardware differs slightly -- thus reducing the cost.
how to figure out who's who? need hw gpio to tell?
YH
On 9/28/07, yhlu yinghailu@gmail.com wrote:
how to figure out who's who?
some pci device that is on one but not another superio id
not sure what else.
ron
ron minnich wrote:
On 9/28/07, yhlu yinghailu@gmail.com wrote:
how to figure out who's who?
some pci device that is on one but not another superio id
not sure what else.
ron
In the case that they're actually provided and updated correctly, subsystem vendor/model ids.
-Corey
On 9/28/07, Corey Osgood corey.osgood@gmail.com wrote:
subsystem vendor/model ids.
LinuxBIOS is supposed to set up those.
YH
yhlu wrote:
On 9/28/07, Corey Osgood corey.osgood@gmail.com wrote:
subsystem vendor/model ids.
LinuxBIOS is supposed to set up those.
YH
Oops, yeah, my bad. Not sure what I was thinking
-Corey
On 28/09/07 11:05 -0700, ron minnich wrote:
OK, these mobos are close enough to each other to share most code. Let me throw out a challenge to this group. Make the bios image that runs on each board *IDENTICAL*. You can figure out what each board is -- can you tell by which superio it is or something? -- and then case out in runtime.
There is a tipping point there though - many people chose LinuxBIOS for the very reason that you don't carry around many Ks of code that you don't need. Even traditional BIOS vendors don't try this. To me the more important thing is to show that the hardware support is there, and that it is a simple build option away.
Why is this good? Because a vendor can see that with proper design, a single bios image can support many mainboards -- even if the hardware differs slightly -- thus reducing the cost.
I just think you have to be very careful - run time detection is not what puts the butts in the seats.
Jordan
On Fri, Sep 28, 2007 at 02:51:45PM -0600, Jordan Crouse wrote:
There is a tipping point there though - many people chose LinuxBIOS for the very reason that you don't carry around many Ks of code that you don't need.
Oh, in this case the differences are so minimal that the amount of unneeded code is almost zero, I think.
Even traditional BIOS vendors don't try this. To me the more important thing is to show that the hardware support is there, and that it is a simple build option away.
Sure.
Why is this good? Because a vendor can see that with proper design, a single bios image can support many mainboards -- even if the hardware differs slightly -- thus reducing the cost.
I just think you have to be very careful - run time detection is not what puts the butts in the seats.
Only as an option, of course. We don't want to do this per default for all boards. But it's a nice option to have...
Uwe.
On Fri, Sep 28, 2007 at 11:05:29AM -0700, ron minnich wrote:
OK, these mobos are close enough to each other to share most code. Let me throw out a challenge to this group. Make the bios image that runs on each board *IDENTICAL*. You can figure out what each board is -- can you tell by which superio it is or something? -- and then case out in runtime.
Sounds possible, yes. And it's a great idea, FWIW. That's for another patch, though, as it'll need much more work. Could someone please ack this patch meanwhile (or comment on it)?
Not sure if we want to try runtime-detection in v2, but we should definately plan for it in v3.
The detection is highly board-specific of course, no generic function possible. And it has to happen very early (pre-RAM), as we have to detect a different Super I/O early enough to be able to initialize it (or at least the serial part).
Super I/O IDs are good and pretty reliable (it seems) _if_ the Super I/Os (or at least their revisions) differ for each board. Otherwise you have to find something else that differs (and can be probed pre-RAM).
Why is this good? Because a vendor can see that with proper design, a single bios image can support many mainboards -- even if the hardware differs slightly -- thus reducing the cost.
We've talked about this for years, never done it. Is this the time?
Yep.
Uwe.
On Thu, Sep 27, 2007 at 10:21:56PM +0200, Robert Millan wrote:
I strongly disagree with this approach. Duplicated code is bad, bad, bad and should be avoided whereever possible.
If we look at it in perspective, I think the cons for each option can be summarised as:
- duplicate: someone might waste time debugging/implementing/fixing something that was already done at the other branch.
- include: someone might break board A in a commit that was only tested on board B.
AFAICS, the second is no big deal, it just takes a regression test which is something even I can do ;-)
Yep. Just look at some other hardware-related projects, e.g. the Linux kernel. Nobody cut-n-pastes a new driver for every ethernet card in existence, for every sound card, every USB mouse etc. There's a common framework, the specific drivers (mostly) only contain the code which is _specific_ to the respective hardware.
That not only reduces the code complexity and the likelyness for bugs, and makes it easier for other developers to understand the code. It also makes sure that all parts using the framework benefit from bugfixes (vs. fixing one sound card code-base and the rest of the 800 cards still contain the same bug, for example).
Really, this is my #1 priority for LinuxBIOS (v3, but also v2) -- reduce code duplication as much as we can. Look at src/superio/smsc/smscsuperio (which handles 15 Super I/Os or so) and try to imagine how that would look like if we had copy-pasted each of them from some other codebase and just tweaked it here and there. We'd have 15 directories full of crap.
Common "framework" code which handles whole _families_ of hardware parts (be it mainboards or superios or chipsets, whatever) should definately be our long-term goal.
Uwe.
Hi,
After reading the rest of this (old) thread, I'm thinking that maybe a good compromise between duplicating or including code could be to include the C files (which don't need to be modified for this port), and duplicate the config files which need more intrusive changes.
This is a resynced version which does that. Please consider appliing it. Status is almost the same as before:
System boots and is usable with usb keyboard.
works:
- serial port - vga (old pci card) - memtest86+ succeeds with minor raminit.c tweaking (see the "[PATCH] Athlon64 K8 fixes" thread) - ata disk - usb
doesn't:
- ps/2 keyboard - vga pci-e card (??) - any other pci card I tried
wasn't tested:
- sata - game port - onboard audio (not supported by alsa anyway) - ps/2 mouse
On Thu, Nov 20, 2008 at 02:46:56PM +0100, Robert Millan wrote:
doesn't:
- ps/2 keyboard
Uwe pointed out that ps/2 keyboard can be fixed by simply reverting my changes in Config.lb. They were based on lspnp output, which is wrong.
I confirm that ps/2 keyboard works now, although PCI no longer (as it used to). I'll run a regression test.
Signed-off-by: Robert Millan rmh@aybabtu.com
The following files are copied from the repository:
svn mkdir src/mainboard/asus/a8n5x svn copy src/mainboard/asus/a8n_e/Config.lb src/mainboard/asus/a8n5x/ svn copy src/mainboard/asus/a8n_e/Options.lb src/mainboard/asus/a8n5x/ svn copy src/mainboard/asus/a8n_e/cmos.layout src/mainboard/asus/a8n5x/ svn mkdir targets/asus/a8n5x svn copy targets/asus/a8n_e/Config.lb targets/asus/a8n5x/
Index: src/mainboard/asus/a8n5x/Config.lb
--- src/mainboard/asus/a8n5x/Config.lb (revision 0) +++ src/mainboard/asus/a8n5x/Config.lb (working copy) @@ -165,66 +165,33 @@ chip northbridge/amd/amdk8/root_complex device pci 0.0 on end # HT device pci 1.0 on # LPC chip superio/ite/it8712f # Super I/O
device pnp 2e.0 on # Floppy
device pnp 2e.7 on # Floppy io 0x60 = 0x3f0 irq 0x70 = 6 drq 0x74 = 2 end
device pnp 2e.1 on # Com1
device pnp 2e.8 on # Com1 io 0x60 = 0x3f8 irq 0x70 = 4 end
device pnp 2e.2 off # Com2 (N/A on this board)io 0x60 = 0x2f8irq 0x70 = 3enddevice pnp 2e.3 on # Parallel port
device pnp 2e.9 on # Parallel port io 0x60 = 0x378 irq 0x70 = 7 drq 0x74 = 3 end
device pnp 2e.4 on # Environment controllerio 0x60 = 0x290io 0x62 = 0x0000irq 0x70 = 0x00enddevice pnp 2e.5 on # PS/2 keyboard
device pnp 2e.a on # PS/2 keyboard io 0x60 = 0x60 io 0x62 = 0x64 irq 0x70 = 1 irq 0x71 = 2 end
device pnp 2e.6 on # PS/2 mouseirq 0x70 = 12irq 0x71 = 2enddevice pnp 2e.7 on # GPIO configio 0x60 = 0x0800# Set GPIO 1 & 2io 0x25 = 0x0000# Set GPIO 3 & 4io 0x27 = 0x2540# GPIO Polarity for Set 3io 0xb2 = 0x2100# GPIO Pin Internal Pull up for Set 3io 0xba = 0x0100# Simple I/O register configio 0xc0 = 0x0000io 0xc2 = 0x2540io 0xc8 = 0x0000io 0xca = 0x0500enddevice pnp 2e.8 on # Midi port
device pnp 2e.b on # Midi port io 0x60 = 0x300 irq 0x70 = 10 end
device pnp 2e.9 on # Game port
device pnp 2e.c on # Game port io 0x60 = 0x201 end
device pnp 2e.a off # IR (N/A on this board)io 0x60 = 0x310irq 0x70 = 11end end end device pci 1.1 on # SM 0Index: src/mainboard/asus/a8n5x/mptable.c
--- src/mainboard/asus/a8n5x/mptable.c (revision 0) +++ src/mainboard/asus/a8n5x/mptable.c (revision 0) @@ -0,0 +1 @@ +#include "../mainboard/asus/a8n_e/mptable.c" Index: src/mainboard/asus/a8n5x/irq_tables.c =================================================================== --- src/mainboard/asus/a8n5x/irq_tables.c (revision 0) +++ src/mainboard/asus/a8n5x/irq_tables.c (revision 0) @@ -0,0 +1 @@ +#include "../mainboard/asus/a8n_e/irq_tables.c" Index: src/mainboard/asus/a8n5x/mainboard.c =================================================================== --- src/mainboard/asus/a8n5x/mainboard.c (revision 0) +++ src/mainboard/asus/a8n5x/mainboard.c (revision 0) @@ -0,0 +1 @@ +#include "../mainboard/asus/a8n_e/mainboard.c" Index: src/mainboard/asus/a8n5x/cache_as_ram_auto.c =================================================================== --- src/mainboard/asus/a8n5x/cache_as_ram_auto.c (revision 0) +++ src/mainboard/asus/a8n5x/cache_as_ram_auto.c (revision 0) @@ -0,0 +1 @@ +#include "../mainboard/asus/a8n_e/cache_as_ram_auto.c" Index: src/mainboard/asus/a8n5x/get_bus_conf.c =================================================================== --- src/mainboard/asus/a8n5x/get_bus_conf.c (revision 0) +++ src/mainboard/asus/a8n5x/get_bus_conf.c (revision 0) @@ -0,0 +1 @@ +#include "../mainboard/asus/a8n_e/get_bus_conf.c" Index: targets/asus/a8n5x/Config.lb =================================================================== --- targets/asus/a8n5x/Config.lb (revision 0) +++ targets/asus/a8n5x/Config.lb (working copy) @@ -19,8 +19,8 @@ ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA ##
-target asus_a8n_e -mainboard asus/a8n_e +target asus_a8n5x +mainboard asus/a8n5x
romimage "normal" option USE_FAILOVER_IMAGE = 0
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Thu, Nov 20, 2008 at 04:21:33PM +0100, Robert Millan wrote:
I confirm that ps/2 keyboard works now, although PCI no longer (as it used to). I'll run a regression test.
Correction: PCI never really worked, except in very specific setups. For me, this means I can only use a PCI (not PCI-e) VGA card, and access the embedded ATA bus, as long as no other cards are plugged in.
So what do we do with a8n5x support? As of now, the port is identical to the asus/a8n_e one. Is it worth adding a new target?
Robert Millan wrote:
So what do we do with a8n5x support? As of now, the port is identical to the asus/a8n_e one. Is it worth adding a new target?
Maybe not so much if it doesn't really work..
//Peter
On Thu, Nov 20, 2008 at 11:11:38PM +0100, Peter Stuge wrote:
Robert Millan wrote:
So what do we do with a8n5x support? As of now, the port is identical to the asus/a8n_e one. Is it worth adding a new target?
Maybe not so much if it doesn't really work..
Depends on what you want to do with it. For a headless box it's pretty usable ;-)
On Thu, Nov 20, 2008 at 5:26 PM, Robert Millan rmh@aybabtu.com wrote:
On Thu, Nov 20, 2008 at 11:11:38PM +0100, Peter Stuge wrote:
Robert Millan wrote:
So what do we do with a8n5x support? As of now, the port is identical to the asus/a8n_e one. Is it worth adding a new target?
Maybe not so much if it doesn't really work..
Depends on what you want to do with it. For a headless box it's pretty usable ;-)
If it doesn't currently work, then it ought to get its own port and have whatever changes are needed to make it work made.
-Corey
Corey Osgood wrote:
On Thu, Nov 20, 2008 at 5:26 PM, Robert Millan <rmh@aybabtu.com mailto:rmh@aybabtu.com> wrote:
On Thu, Nov 20, 2008 at 11:11:38PM +0100, Peter Stuge wrote: > Robert Millan wrote: > > So what do we do with a8n5x support? As of now, the port is > > identical to the asus/a8n_e one. Is it worth adding a new target? > > Maybe not so much if it doesn't really work.. Depends on what you want to do with it. For a headless box it's pretty usable ;-)
What's the issue with VGA? PCIe not set up correctly?
Try comparing different register dumps (lspci -xxx) and PIRQ tables and MP tables with different cards plugged into different slots under vendor bios and look at how values change. You'll most likely find out what's wrong with your port
Stefan
On Fri, Nov 21, 2008 at 01:35:17PM +0100, Stefan Reinauer wrote:
What's the issue with VGA? PCIe not set up correctly?
System crashes when I try to use any PCI card other than on-board ones or an S3 discrete (non-PCIe) card I have.
Try comparing different register dumps (lspci -xxx) and PIRQ tables and MP tables with different cards plugged into different slots under vendor bios and look at how values change. You'll most likely find out what's wrong with your port
I found that getpir prints different code for proprietary bios than coreboot, and fixed that by replacing the code; they're identical now, but this doesn't seem to fix anything.
For mptables, it also prints different code, but this time replacing them results in breakage. Linux complains that it's losing interrupts, and I get a very slow boot. I guess it's syncronizing with ATA hardware via timeouts.
Attached are the lspci and mptables dumps. I'm specially troubled by:
-05:06.0 VGA compatible controller: S3 Inc. 86c764/765 [Trio32/64/64V+] +01:06.0 VGA compatible controller: S3 Inc. 86c764/765 [Trio32/64/64V+]
this is my discrete S3 card, and it's in the same slot in both cases.
-
Corey Osgood -
Jordan Crouse -
Peter Stuge -
Robert Millan -
ron minnich -
Stefan Reinauer -
Uwe Hermann -
yhlu