[LinuxBIOS] A8N5X port
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 -- Robert Millan <GPLv2> I know my rights; I want my phone call! <DRM> What use is a phone call, if you are unable to speak? (as seen on /.)
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 Millan <GPLv2> I know my rights; I want my phone call! <DRM> What use is a phone call, if you are unable to speak? (as seen on /.)
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). -- Robert Millan <GPLv2> I know my rights; I want my phone call! <DRM> What use is a phone call, if you are unable to speak? (as seen on /.)
[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 0 + chip southbridge/nvidia/ck804 # Southbridge + device pci 0.0 on end # HT + device pci 1.0 on # LPC + chip superio/ite/it8712f # Super I/O + device pnp 2e.7 off # Floppy + io 0x60 = 0x3f0 + irq 0x70 = 6 + drq 0x74 = 2 + end + device pnp 2e.8 on # Com1 + io 0x60 = 0x3f8 + irq 0x70 = 4 + end + device pnp 2e.9 on # Parallel port + io 0x60 = 0x378 + irq 0x70 = 7 + drq 0x74 = 3 + end + device pnp 2e.a on # PS/2 keyboard + io 0x60 = 0x60 + io 0x62 = 0x64 + irq 0x70 = 1 + irq 0x71 = 2 + end + device pnp 2e.b off end # Midi port + device pnp 2e.c off end # Game port + end + end + device 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 + # end + end + device pci 2.0 on end # USB 1.1 + device pci 2.1 on end # USB 2 + device pci 4.0 off end # Onboard audio (ACI) + device pci 4.1 off end # Onboard modem (MCI) + device pci 6.0 on end # IDE + device pci 7.0 on end # SATA 1 + device pci 8.0 on end # SATA 0 + device pci 9.0 on end # PCI + device pci a.0 on end # NIC + device pci b.0 on end # PCI E 3 + device pci c.0 on end # PCI E 2 + device pci d.0 on end # PCI E 1 + device pci e.0 on end # PCI E 0 + register "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" + end + end + device pci 18.1 on end + device pci 18.2 on end + device pci 18.3 on end + end + end +end + +end # if -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: info@coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
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. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
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 ;-) -- Robert Millan <GPLv2> I know my rights; I want my phone call! <DRM> What use is a phone call, if you are unable to speak? (as seen on /.)
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. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
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
On 9/28/07, Corey Osgood <corey.osgood@gmail.com> wrote:
subsystem vendor/model ids.
LinuxBIOS is supposed to set up those. YH
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 -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc.
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. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
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. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
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. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
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 -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all."
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 = 0x2f8 - irq 0x70 = 3 - end - device 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 controller - io 0x60 = 0x290 - io 0x62 = 0x0000 - irq 0x70 = 0x00 - end - device 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 mouse - irq 0x70 = 12 - irq 0x71 = 2 - end - device pnp 2e.7 on # GPIO config - io 0x60 = 0x0800 - # Set GPIO 1 & 2 - io 0x25 = 0x0000 - # Set GPIO 3 & 4 - io 0x27 = 0x2540 - # GPIO Polarity for Set 3 - io 0xb2 = 0x2100 - # GPIO Pin Internal Pull up for Set 3 - io 0xba = 0x0100 - # Simple I/O register config - io 0xc0 = 0x0000 - io 0xc2 = 0x2540 - io 0xc8 = 0x0000 - io 0xca = 0x0500 - end - device 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 = 0x310 - irq 0x70 = 11 - end end end device pci 1.1 on # SM 0 Index: 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
-- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all."
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 The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all."
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 ;-) -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all."
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. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all."
participants (8)
-
Corey Osgood -
Jordan Crouse -
Peter Stuge -
Robert Millan -
ron minnich -
Stefan Reinauer -
Uwe Hermann -
yhlu