Hi everybody,
with the help of Harald's seaBIOS-payload I managed to run the latest coreboot (revision 4387) on my v1.0 m57sli-board. From a first look everything seems to work: kvm, sound, power-now frequency scaling. dmesg is attached for proprietary and free bios.
Minor issues:
coreboot ACPI: hda: host side 80-wire cable detection failed, limiting max speed to UDMA33 hda: UDMA/33 mode selected [...] powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ processors (2 cpu cores) (version 2.20.00) powernow-k8: 0 : fid 0x11 (2500 MHz), vid 0x9 powernow-k8: 1 : fid 0x10 (2400 MHz), vid 0xa powernow-k8: 2 : fid 0xe (2200 MHz), vid 0xc powernow-k8: 3 : fid 0xc (2000 MHz), vid 0xe powernow-k8: 4 : fid 0x2 (1000 MHz), vid 0x12 powernow-k8: ph2 null fid transition 0x11
proprietary: hda: UDMA/66 mode selected [...] powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ processors (2 cpu cores) (version 2.20.00) powernow-k8: 0 : fid 0x11 (2500 MHz), vid 0x9 powernow-k8: 1 : fid 0x10 (2400 MHz), vid 0xa powernow-k8: 2 : fid 0xe (2200 MHz), vid 0xc powernow-k8: 3 : fid 0xc (2000 MHz), vid 0xe powernow-k8: 4 : fid 0xa (1800 MHz), vid 0x10 powernow-k8: 5 : fid 0x2 (1000 MHz), vid 0x12
Many thanks to everybody involved! I'll run my board now fulltime coreboot!
Regards Andi
Hi everybody,
just noticed that my parallel port printer unfortunately only works with the prop. BIOS:
From dmesg:
coreboot: [ 54.388956] lp: driver loaded but no devices found [ 54.409159] ppdev: user-space parallel port driver
prop. BIOS: [ 179.494713] lp0: using parport0 (interrupt-driven). [ 179.516281] ppdev: user-space parallel port driver
Regards,
Andi
On Thu, 2 Jul 2009 17:56:30 +0200, "Andreas B. Mundt" andi.mundt@web.de wrote:
Hi everybody,
just noticed that my parallel port printer unfortunately only works with the prop. BIOS:
From dmesg:
coreboot: [ 54.388956] lp: driver loaded but no devices found [ 54.409159] ppdev: user-space parallel port driver
prop. BIOS: [ 179.494713] lp0: using parport0 (interrupt-driven). [ 179.516281] ppdev: user-space parallel port driver
Hmm is it enabled in by the SuperIO in coreboot? Perhaps it is related to a IRQ conflict?
Hi,
find attached the output of superiotool -dV.
The parallel port part:
coreboot: LDN 0x03 (Parallel port) idx 30 60 61 62 63 70 74 f0 val 00 03 78 07 78 07 04 03 def 00 03 78 07 78 07 03 03
prop. BIOS: LDN 0x03 (Parallel port) idx 30 60 61 62 63 70 74 f0 val 01 03 78 00 00 07 04 08 def 00 03 78 07 78 07 03 03
Any hints are appreciated.
Regards
Andi
On Thu, Jul 02, 2009 at 12:49:37PM -0400, Joseph Smith wrote:
On Thu, 2 Jul 2009 17:56:30 +0200, "Andreas B. Mundt" andi.mundt@web.de wrote:
Hi everybody,
just noticed that my parallel port printer unfortunately only works with the prop. BIOS:
From dmesg:
coreboot: [ 54.388956] lp: driver loaded but no devices found [ 54.409159] ppdev: user-space parallel port driver
prop. BIOS: [ 179.494713] lp0: using parport0 (interrupt-driven). [ 179.516281] ppdev: user-space parallel port driver
Hmm is it enabled in by the SuperIO in coreboot? Perhaps it is related to a IRQ conflict?
-- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
On Thursday 02 July 2009 20:22:50 Harald Gutmann wrote:
On Thursday 02 July 2009 17:56:30 Andreas B. Mundt wrote:
Hi everybody,
just noticed that my parallel port printer unfortunately only works
with the prop. BIOS:
From dmesg:
coreboot: [ 54.388956] lp: driver loaded but no devices found [ 54.409159] ppdev: user-space parallel port driver
prop. BIOS: [ 179.494713] lp0: using parport0 (interrupt-driven). [ 179.516281] ppdev: user-space parallel port driver
With the attached patch I get the following output on modprobe parport: [ 28.848297] lp0: using parport0 (polling). [ 28.858860] ppdev: user-space parallel port driver
The patch also turns on the floppy device, but I've none here to verify if it will work. It would be great if you can test if floppy works, so that we could mark the last two "not-working" parts as OK in the wiki, if it the floppy does its job
Sry, I forgot to sign it off: Signed-off-by: Harald Gutmann <harald.gutmann at gmx.net>
Patch tested succesfully with parallel-port printer.
Acked-by: Andreas B. Mundt
Thanks,
Andi
On Thursday 02 July 2009 20:58:42 Andreas B. Mundt wrote:
On Thursday 02 July 2009 20:22:50 Harald Gutmann wrote:
On Thursday 02 July 2009 17:56:30 Andreas B. Mundt wrote:
Hi everybody,
just noticed that my parallel port printer unfortunately only works
with the prop. BIOS:
From dmesg:
coreboot: [ 54.388956] lp: driver loaded but no devices found [ 54.409159] ppdev: user-space parallel port driver
prop. BIOS: [ 179.494713] lp0: using parport0 (interrupt-driven). [ 179.516281] ppdev: user-space parallel port driver
With the attached patch I get the following output on modprobe parport: [ 28.848297] lp0: using parport0 (polling). [ 28.858860] ppdev: user-space parallel port driver
The patch also turns on the floppy device, but I've none here to verify if it will work. It would be great if you can test if floppy works, so that we could mark the last two "not-working" parts as OK in the wiki, if it the floppy does its job
Sry, I forgot to sign it off: Signed-off-by: Harald Gutmann <harald.gutmann at gmx.net>
Patch tested succesfully with parallel-port printer.
Acked-by: Andreas B. Mundt
Thanks, r4396.
Thanks,
Andi
Regards, Harald
On Thursday 02 July 2009 21:40:52 Peter Stuge wrote:
Andreas B. Mundt wrote:
With the attached patch I get the following output on modprobe parport: [ 28.848297] lp0: using parport0 (polling).
Patch tested succesfully with parallel-port printer.
Is the port interrupt-driven, or polling, on your system, Andreas?
Here on my system it says also polling, like on Andreas system. What is the difference between interrupt driven and polling?
On vendor bios it is interrupt-driven. Is an ACPI part missing to get it interrupt driven?
//Peter
Regards, Harald
Harald Gutmann wrote:
Is the port interrupt-driven, or polling, on your system, Andreas?
Here on my system it says also polling, like on Andreas system. What is the difference between interrupt driven and polling?
Interrupt driven means the port has an interrupt assigned to it, and that communication over the port is event based.
Polling means there is a timer running in the kernel which will check the port for activity every few milliseconds or something.
On vendor bios it is interrupt-driven. Is an ACPI part missing to get it interrupt driven?
I think so, yes.
//Peter
On Thursday 02 July 2009 23:26:34 Peter Stuge wrote:
Harald Gutmann wrote:
Is the port interrupt-driven, or polling, on your system, Andreas?
Here on my system it says also polling, like on Andreas system. What is the difference between interrupt driven and polling?
Interrupt driven means the port has an interrupt assigned to it, and that communication over the port is event based.
Polling means there is a timer running in the kernel which will check the port for activity every few milliseconds or something.
On vendor bios it is interrupt-driven. Is an ACPI part missing to get it interrupt driven?
I think so, yes.
I think this should be easy to fix if it is really acpi related, just a few lines in the dsdt.asl should do the job.
But right now I'm a little bit in a hurry, and maybe I'll find time to do that on sunday or even tomorrow.
//Peter
Thanks, Harald
On Thursday 02 July 2009 23:26:34 Peter Stuge wrote:
Harald Gutmann wrote:
Is the port interrupt-driven, or polling, on your system, Andreas?
Here on my system it says also polling, like on Andreas system. What is the difference between interrupt driven and polling?
Interrupt driven means the port has an interrupt assigned to it, and that communication over the port is event based.
Polling means there is a timer running in the kernel which will check the port for activity every few milliseconds or something.
On vendor bios it is interrupt-driven. Is an ACPI part missing to get it interrupt driven?
I think so, yes.
So, I've added the missing ACPI part, but it seems that some more work is needed to get parport interrupt driven working.
The dmesg output changes a little bit, and also mentions IRQ7, but lp0 is still noticed as polling: [ 745.974254] parport_pc 00:04: reported by Plug and Play ACPI [ 745.974371] parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE] [ 746.104129] parport0: irq 7 detected [ 751.914593] ppdev: user-space parallel port driver [ 770.953504] lp0: using parport0 (polling).
I think that it is necessary to set some irq bit to get it working fine. This idea is from the vendors dsdt.asl [1] and the LPT1 (starting at line 5374) section of it. Looking at that part there is something noticed about INTR which could be the IRQ bit I assume that this is needed.
Can anyone help me out here a little bit?
[1] http://coreboot.pastebin.com/f3e965943
Kind regards, Harald
//Peter
On Saturday 04 July 2009 11:02:36 Harald Gutmann wrote:
On Thursday 02 July 2009 23:26:34 Peter Stuge wrote:
Harald Gutmann wrote:
Is the port interrupt-driven, or polling, on your system, Andreas?
Here on my system it says also polling, like on Andreas system. What is the difference between interrupt driven and polling?
Interrupt driven means the port has an interrupt assigned to it, and that communication over the port is event based.
Polling means there is a timer running in the kernel which will check the port for activity every few milliseconds or something.
On vendor bios it is interrupt-driven. Is an ACPI part missing to get it interrupt driven?
I think so, yes.
So, I've added the missing ACPI part, but it seems that some more work is needed to get parport interrupt driven working.
I just did a mistake and set no address in the IO Section.
There's already another patch on the list (which was filtered by my spam-filter, and therefore I did the job again). The difference between my patch, and the one from Andreas are minimal, but I added the ECP device which is necessary to get Parport full functional (hopefully I did everything correct, as I can't test this without Parport devices.)
The attached patch activates changes the LPT port from polling to interrupt- driven, and should be fine.
Signed-off-by: Harald Gutmann harald.gutmann@gmx.net
Kind regards, Harald
The dmesg output changes a little bit, and also mentions IRQ7, but lp0 is still noticed as polling: [ 745.974254] parport_pc 00:04: reported by Plug and Play ACPI [ 745.974371] parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE] [ 746.104129] parport0: irq 7 detected [ 751.914593] ppdev: user-space parallel port driver [ 770.953504] lp0: using parport0 (polling).
I think that it is necessary to set some irq bit to get it working fine. This idea is from the vendors dsdt.asl [1] and the LPT1 (starting at line 5374) section of it. Looking at that part there is something noticed about INTR which could be the IRQ bit I assume that this is needed.
Can anyone help me out here a little bit?
[1] http://coreboot.pastebin.com/f3e965943
//Peter
On Thu, 2 Jul 2009, Harald Gutmann wrote:
On Thursday 02 July 2009 21:40:52 Peter Stuge wrote:
Andreas B. Mundt wrote:
[..]
What is the difference between interrupt driven and polling?
Polling means the printer driver checks the printer at regular intervals to see if the printer is ready for another character.
Interrupt driven the printer tells the driver it's ready.
Thus a high speed printer will run a little slower with polling.
Russ
Hi,
Is the port interrupt-driven, or polling, on your system, Andreas?
//Peter
dmesg:
[ 63.699013] pnp: the driver 'parport_pc' has been registered [ 63.699116] parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE] [ 63.828395] parport0: irq 7 detected [ 63.853986] parport0: Printer, Hewlett-Packard HP LaserJet 5L [ 63.857440] lp0: using parport0 (polling). [ 63.878908] ppdev: user-space parallel port driver
Hi,
the patch below allows for interrupt driven parport usage (even when CONFIG_PARPORT_PC_SUPERIO is not set in the kernel config). It has been prepared with Rudolf's help on IRC. Please test and/or improve!
According to Rudolf, it would be better better to code something in ACPI code which will get the resource info from hardware, or alternatively, the superiocode should generate some simple acpi code.
from dmesg: lp0: using parport0 (interrupt-driven).
Signed-off-by: Anreas B. Mundt <andi.mundt at web.de>
Regards, Andi
Hi,
So, I've added the missing ACPI part, but it seems that some more work is needed to get parport interrupt driven working.
I just did a mistake and set no address in the IO Section.
There's already another patch on the list (which was filtered by my spam-filter, and therefore I did the job again). The difference between my patch, and the one from Andreas are minimal, but I added the ECP device which is necessary to get Parport full functional (hopefully I did everything correct, as I can't test this without Parport devices.)
my printer works fine (interrupt driven). From dmesg:
old dmesg: pnp: PnP ACPI init ACPI: bus type pnp registered pnp 00:00: parse allocated resources pnp 00:00: add io 0xcf8-0xcff flags 0x1 pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active) pnp 00:01: parse allocated resources pnp 00:01: add io 0x60-0x60 flags 0x1 pnp 00:01: add io 0x64-0x64 flags 0x1 pnp 00:01: add irq 1 flags 0x1 pnp 00:01: Plug and Play ACPI device, IDs PNP0303 (active) pnp 00:02: parse allocated resources pnp 00:02: add io 0x378-0x387 flags 0x0 pnp 00:02: add irq 7 flags 0x1 pnp 00:02: Plug and Play ACPI device, IDs PNP0400 (active) pnp 00:03: parse allocated resources pnp 00:03: add io 0x60-0x60 flags 0x1 pnp 00:03: add io 0x64-0x64 flags 0x1 pnp 00:03: add irq 12 flags 0x1 pnp 00:03: Plug and Play ACPI device, IDs PNP0f13 (active) pnp 00:04: parse allocated resources pnp 00:04: add io 0x3f0-0x3f5 flags 0x1 pnp 00:04: add io 0x3f7-0x3f7 flags 0x1 pnp 00:04: add irq 6 flags 0x1 pnp 00:04: add dma 2 flags 0x0 pnp 00:04: Plug and Play ACPI device, IDs PNP0700 (active) pnp: PnP ACPI: found 5 devices
new dmesg: pnp: PnP ACPI init ACPI: bus type pnp registered pnp 00:00: parse allocated resources pnp 00:00: add io 0xcf8-0xcff flags 0x1 pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active) pnp 00:01: parse allocated resources pnp 00:01: add io 0x60-0x60 flags 0x1 pnp 00:01: add io 0x64-0x64 flags 0x1 pnp 00:01: add irq 1 flags 0x1 pnp 00:01: Plug and Play ACPI device, IDs PNP0303 (active) pnp 00:02: parse allocated resources pnp 00:02: add io 0x60-0x60 flags 0x1 pnp 00:02: add io 0x64-0x64 flags 0x1 pnp 00:02: add irq 12 flags 0x1 pnp 00:02: Plug and Play ACPI device, IDs PNP0f13 (active) pnp 00:03: parse allocated resources pnp 00:03: add io 0x3f0-0x3f5 flags 0x1 pnp 00:03: add io 0x3f7-0x3f7 flags 0x1 pnp 00:03: add irq 6 flags 0x1 pnp 00:03: add dma 2 flags 0x0 pnp 00:03: Plug and Play ACPI device, IDs PNP0700 (active) pnp 00:04: parse allocated resources pnp 00:04: add io 0x378-0x37f flags 0x1 pnp 00:04: add irq 7 flags 0x1 pnp 00:04: Plug and Play ACPI device, IDs PNP0400 (active) pnp 00:05: parse allocated resources pnp 00:05: add io 0x378-0x37b flags 0x1 pnp 00:05: add io 0x778-0x77b flags 0x1 pnp 00:05: add irq 7 flags 0x1 pnp 00:05: add dma 0 flags 0x0 pnp 00:05: Plug and Play ACPI device, IDs PNP0401 (active) pnp: PnP ACPI: found 6 devices
The attached patch activates changes the LPT port from polling to interrupt- driven, and should be fine.
Signed-off-by: Harald Gutmann <harald.gutmann at gmx.net>
Ignoring that I do not know how to check the ECP device:
Acked-by: Andreas B. Mundt <andi.mundt at web.de>
Kind regards,
Andi
On Tuesday 07 July 2009 15:33:24 Andreas B. Mundt wrote:
Hi,
So, I've added the missing ACPI part, but it seems that some more work is needed to get parport interrupt driven working.
I just did a mistake and set no address in the IO Section.
There's already another patch on the list (which was filtered by my spam-filter, and therefore I did the job again). The difference between my patch, and the one from Andreas are minimal, but I added the ECP device which is necessary to get Parport full functional (hopefully I did everything correct, as I can't test this without Parport devices.)
my printer works fine (interrupt driven). From dmesg:
old dmesg: pnp: PnP ACPI init ACPI: bus type pnp registered pnp 00:00: parse allocated resources pnp 00:00: add io 0xcf8-0xcff flags 0x1 pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active) pnp 00:01: parse allocated resources pnp 00:01: add io 0x60-0x60 flags 0x1 pnp 00:01: add io 0x64-0x64 flags 0x1 pnp 00:01: add irq 1 flags 0x1 pnp 00:01: Plug and Play ACPI device, IDs PNP0303 (active) pnp 00:02: parse allocated resources pnp 00:02: add io 0x378-0x387 flags 0x0 pnp 00:02: add irq 7 flags 0x1 pnp 00:02: Plug and Play ACPI device, IDs PNP0400 (active) pnp 00:03: parse allocated resources pnp 00:03: add io 0x60-0x60 flags 0x1 pnp 00:03: add io 0x64-0x64 flags 0x1 pnp 00:03: add irq 12 flags 0x1 pnp 00:03: Plug and Play ACPI device, IDs PNP0f13 (active) pnp 00:04: parse allocated resources pnp 00:04: add io 0x3f0-0x3f5 flags 0x1 pnp 00:04: add io 0x3f7-0x3f7 flags 0x1 pnp 00:04: add irq 6 flags 0x1 pnp 00:04: add dma 2 flags 0x0 pnp 00:04: Plug and Play ACPI device, IDs PNP0700 (active) pnp: PnP ACPI: found 5 devices
new dmesg: pnp: PnP ACPI init ACPI: bus type pnp registered pnp 00:00: parse allocated resources pnp 00:00: add io 0xcf8-0xcff flags 0x1 pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active) pnp 00:01: parse allocated resources pnp 00:01: add io 0x60-0x60 flags 0x1 pnp 00:01: add io 0x64-0x64 flags 0x1 pnp 00:01: add irq 1 flags 0x1 pnp 00:01: Plug and Play ACPI device, IDs PNP0303 (active) pnp 00:02: parse allocated resources pnp 00:02: add io 0x60-0x60 flags 0x1 pnp 00:02: add io 0x64-0x64 flags 0x1 pnp 00:02: add irq 12 flags 0x1 pnp 00:02: Plug and Play ACPI device, IDs PNP0f13 (active) pnp 00:03: parse allocated resources pnp 00:03: add io 0x3f0-0x3f5 flags 0x1 pnp 00:03: add io 0x3f7-0x3f7 flags 0x1 pnp 00:03: add irq 6 flags 0x1 pnp 00:03: add dma 2 flags 0x0 pnp 00:03: Plug and Play ACPI device, IDs PNP0700 (active) pnp 00:04: parse allocated resources pnp 00:04: add io 0x378-0x37f flags 0x1 pnp 00:04: add irq 7 flags 0x1 pnp 00:04: Plug and Play ACPI device, IDs PNP0400 (active) pnp 00:05: parse allocated resources pnp 00:05: add io 0x378-0x37b flags 0x1 pnp 00:05: add io 0x778-0x77b flags 0x1 pnp 00:05: add irq 7 flags 0x1 pnp 00:05: add dma 0 flags 0x0 pnp 00:05: Plug and Play ACPI device, IDs PNP0401 (active) pnp: PnP ACPI: found 6 devices
What option did you set to get pnp messages? acpi=debug?
The attached patch activates changes the LPT port from polling to interrupt- driven, and should be fine.
Signed-off-by: Harald Gutmann <harald.gutmann at gmx.net>
Ignoring that I do not know how to check the ECP device:
I've also no direct idea how to test it. According to wikipedia there are two parallel port modes, EPP and ECP. Recent computers support both modes, where ECP (Extended Capabilities Parallel Port) is faster.
Acked-by: Andreas B. Mundt <andi.mundt at web.de>
Thanks, revision 4405.
Kind regards,
Andi
Regards, Harald.
Hi,
[...] pnp: PnP ACPI: found 6 devices
What option did you set to get pnp messages? acpi=debug?
No, just default dmesg on debian squeeze.
So, updated remaining minor issues for the m57sli:
* missing power state: prop. BIOS: powernow-k8: 4 : fid 0xa (1800 MHz), vid 0x10 coreboot: powernow-k8: ph2 null fid transition 0x11
* hda: UDMA/33 compared to UDMA/66 with prop. BIOS
* ??
Thanks, Andi
On Tuesday 07 July 2009 18:52:43 Andreas B. Mundt wrote:
Hi,
[...] pnp: PnP ACPI: found 6 devices
What option did you set to get pnp messages? acpi=debug?
No, just default dmesg on debian squeeze.
So, updated remaining minor issues for the m57sli:
* missing power state: prop. BIOS: powernow-k8: 4 : fid 0xa (1800 MHz), vid 0x10 coreboot: powernow-k8: ph2 null fid transition 0x11
I think that this is not directly M57SLI related. My assumption is, that there is some "logical" error in the PowerNow generator which is used to generate the P-states on m57sli. I've already looked at the code, and the BKDG, but not in the detail which would be necessary to find and fix the mistake.
* hda: UDMA/33 compared to UDMA/66 with prop. BIOS
My suggestion would be to open up a new ML-thread according to this problem. It should be "easy" to fix, and I think that it has nothing to do with the DMA modes itself, but with the "88pin-wire-cable-bit" (but I don't know if it's for real a bit which needs to be set). I also tried to investigate that problem, but ran out of time the evening I started. (check kernel ide-drivers amd7xxx.c (or similar) to find out what's going on there).
* ??Thanks, Andi
Regards, Harald
On Thursday 02 July 2009 17:56:30 Andreas B. Mundt wrote:
Hi everybody,
just noticed that my parallel port printer unfortunately only works
I've no parallel port hardware and therefore not cared about this, but I think we can fix this. The floppy issue is hopefully the same way to fix than parport. (I think that floppy is also SIO related.)
with the prop. BIOS:
From dmesg:
coreboot: [ 54.388956] lp: driver loaded but no devices found [ 54.409159] ppdev: user-space parallel port driver
prop. BIOS: [ 179.494713] lp0: using parport0 (interrupt-driven). [ 179.516281] ppdev: user-space parallel port driver
Regards,
Andi
Will try to find out something more on that topic.
Kind regards, Harald
Andreas B. Mundt wrote:
coreboot: LDN 0x03 (Parallel port) idx 30 60 61 62 63 70 74 f0 val 00 03 78 07 78 07 04 03
prop. BIOS: LDN 0x03 (Parallel port) idx 30 60 61 62 63 70 74 f0 val 01 03 78 00 00 07 04 08
LDN 30 bit 1 is almost always enable. So coreboot simply does not enable the parallel port.
Harald Gutmann wrote:
I've no parallel port hardware and therefore not cared about this, but I think we can fix this. The floppy issue is hopefully the same way to fix than parport. (I think that floppy is also SIO related.)
..
Will try to find out something more on that topic.
Maybe it's as simple as a missing "on" in Config.lb ?
//Peter
On Thursday 02 July 2009 20:08:00 Peter Stuge wrote:
Andreas B. Mundt wrote:
coreboot: LDN 0x03 (Parallel port) idx 30 60 61 62 63 70 74 f0 val 00 03 78 07 78 07 04 03
prop. BIOS: LDN 0x03 (Parallel port) idx 30 60 61 62 63 70 74 f0 val 01 03 78 00 00 07 04 08
LDN 30 bit 1 is almost always enable. So coreboot simply does not enable the parallel port.
Harald Gutmann wrote:
I've no parallel port hardware and therefore not cared about this, but I think we can fix this. The floppy issue is hopefully the same way to fix than parport. (I think that floppy is also SIO related.)
..
Will try to find out something more on that topic.
Maybe it's as simple as a missing "on" in Config.lb ?
Seems that it is that simple. I'll test it, and check if it works.
//Peter
Regards, Harald
On Thursday 02 July 2009 17:56:30 Andreas B. Mundt wrote:
Hi everybody,
just noticed that my parallel port printer unfortunately only works
with the prop. BIOS:
From dmesg:
coreboot: [ 54.388956] lp: driver loaded but no devices found [ 54.409159] ppdev: user-space parallel port driver
prop. BIOS: [ 179.494713] lp0: using parport0 (interrupt-driven). [ 179.516281] ppdev: user-space parallel port driver
With the attached patch I get the following output on modprobe parport: [ 28.848297] lp0: using parport0 (polling). [ 28.858860] ppdev: user-space parallel port driver
The patch also turns on the floppy device, but I've none here to verify if it will work. It would be great if you can test if floppy works, so that we could mark the last two "not-working" parts as OK in the wiki, if it the floppy does its job
Regards, Harald
Regards,
Andi
On Thursday 02 July 2009 20:22:50 Harald Gutmann wrote:
On Thursday 02 July 2009 17:56:30 Andreas B. Mundt wrote:
Hi everybody,
just noticed that my parallel port printer unfortunately only works
with the prop. BIOS:
From dmesg:
coreboot: [ 54.388956] lp: driver loaded but no devices found [ 54.409159] ppdev: user-space parallel port driver
prop. BIOS: [ 179.494713] lp0: using parport0 (interrupt-driven). [ 179.516281] ppdev: user-space parallel port driver
With the attached patch I get the following output on modprobe parport: [ 28.848297] lp0: using parport0 (polling). [ 28.858860] ppdev: user-space parallel port driver
The patch also turns on the floppy device, but I've none here to verify if it will work. It would be great if you can test if floppy works, so that we could mark the last two "not-working" parts as OK in the wiki, if it the floppy does its job
Sry, I forgot to sign it off: Signed-off-by: Harald Gutmann harald.gutmann@gmx.net
Regards, Harald
Regards,
Andi
Hi everybody,
the last message did not get throug completely :-( Here is the missing part:
From dmesg:
coreboot: [ 54.388956] lp: driver loaded but no devices found [ 54.409159] ppdev: user-space parallel port driver
prop. BIOS: [ 179.494713] lp0: using parport0 (interrupt-driven). [ 179.516281] ppdev: user-space parallel port driver
Regards,
Andi
On Wednesday 01 July 2009 16:21:39 Andreas B. Mundt wrote:
Hi everybody,
with the help of Harald's seaBIOS-payload I managed to run the latest coreboot (revision 4387) on my v1.0 m57sli-board. From a first look everything seems to work: kvm, sound, power-now frequency scaling. dmesg is attached for proprietary and free bios.
Nice that you could test it. The payload wasn't from me, just the link to it. (It's directly on the seabios homepage, kevin built it some time ago.)
Minor issues:
coreboot ACPI: hda: host side 80-wire cable detection failed, limiting max speed to UDMA33 hda: UDMA/33 mode selected [...] powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ processors (2 cpu cores) (version 2.20.00) powernow-k8: 0 : fid 0x11 (2500 MHz), vid 0x9 powernow-k8: 1 : fid 0x10 (2400 MHz), vid 0xa powernow-k8: 2 : fid 0xe (2200 MHz), vid 0xc powernow-k8: 3 : fid 0xc (2000 MHz), vid 0xe powernow-k8: 4 : fid 0x2 (1000 MHz), vid 0x12 powernow-k8: ph2 null fid transition 0x11
proprietary: hda: UDMA/66 mode selected [...] powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ processors (2 cpu cores) (version 2.20.00) powernow-k8: 0 : fid 0x11 (2500 MHz), vid 0x9 powernow-k8: 1 : fid 0x10 (2400 MHz), vid 0xa powernow-k8: 2 : fid 0xe (2200 MHz), vid 0xc powernow-k8: 3 : fid 0xc (2000 MHz), vid 0xe powernow-k8: 4 : fid 0xa (1800 MHz), vid 0x10 powernow-k8: 5 : fid 0x2 (1000 MHz), vid 0x12
Interesting, and good that you mention that!
When I tested the PowerNow! stuff, I also recognized that, but it seems that I flipped the results. My point of view was that coreboot offers one more stepping mode, and therefore didn't care about it. Maybe Rudolf Marek can us help here, because he wrote the automatic generation for that ACPI table (SSDT).
Many thanks to everybody involved! I'll run my board now fulltime coreboot!
Regards Andi
Regards, Harald
Maybe Rudolf Marek can us help here, because he wrote the automatic generation for that ACPI table (SSDT).
Hi,
If I understand correctly, the 1800MHz is missing? If so, please check what is the portal frequency for this CPU. Maybe it is 2000 and not 1800 (so prop bios is wrong). Check the BKDG. I'm very busy so I think better would be if someone else could check.
The interupt driven parport works now?
Rudolf
On Friday 03 July 2009 00:15:33 Rudolf Marek wrote:
Maybe Rudolf Marek can us help here, because he wrote the automatic generation for that ACPI table (SSDT).
Hi,
If I understand correctly, the 1800MHz is missing? If so, please check what is the portal frequency for this CPU. Maybe it is 2000 and not 1800 (so prop bios is wrong). Check the BKDG. I'm very busy so I think better would be if someone else could check.
I'll also check this, to see if coreboot or vendor is wrong. Thanks for you fast reply!
The interupt driven parport works now?
Right now the parport is just working with polling. But I think I can fix it to get it interrupt driven with a little dsdt.asl patch.
(Maybe sunday, or even towmorrow.)
Rudolf
Regards, Harald
Hi,
One thing I would like to ask, not just regarding this motherboard but all AM2/AM2+/AM3 boards. Would it be possible to implement a feature that would allow us to configure custom P-States to save on CMOS, other than what the manufacturer specifies? Most BIOS allow setting lower and higher multipliers than stock on some CPUs but disable CPU power management altogether when doing so. It would be quite a leap forward, when compared with vendor BIOS to be able to specify at least one VID and FID for the high power state and another FID and VID for the low power state.
With overclocking the benefits are enormous in the power bill and also for the low power state, since the manufacturer specifies 1.1v @ 1GHz and most CPUs handle 0.8v @ 800MHz quite easily. I'd love to get those low power states on my home server :)
I've been trying to get hold of one of these M57SLI-S4 boards to try and implement this but would like to know if this is something possible to achieve with the current code base.
Best regards, Tiago Marques
On Fri, Jul 3, 2009 at 3:55 PM, Harald Gutmannharald.gutmann@gmx.net wrote:
On Friday 03 July 2009 00:15:33 Rudolf Marek wrote:
Maybe Rudolf Marek can us help here, because he wrote the automatic generation for that ACPI table (SSDT).
Hi,
If I understand correctly, the 1800MHz is missing? If so, please check what is the portal frequency for this CPU. Maybe it is 2000 and not 1800 (so prop bios is wrong). Check the BKDG. I'm very busy so I think better would be if someone else could check.
I'll also check this, to see if coreboot or vendor is wrong. Thanks for you fast reply!
The interupt driven parport works now?
Right now the parport is just working with polling. But I think I can fix it to get it interrupt driven with a little dsdt.asl patch.
(Maybe sunday, or even towmorrow.)
Rudolf
Regards, Harald
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Hi all,
Can someone please answer me these questions?
Best regards, Tiago Marques
On Sat, Jul 4, 2009 at 2:06 AM, Tiago Marquestiagomnm@gmail.com wrote:
Hi,
One thing I would like to ask, not just regarding this motherboard but all AM2/AM2+/AM3 boards. Would it be possible to implement a feature that would allow us to configure custom P-States to save on CMOS, other than what the manufacturer specifies? Most BIOS allow setting lower and higher multipliers than stock on some CPUs but disable CPU power management altogether when doing so. It would be quite a leap forward, when compared with vendor BIOS to be able to specify at least one VID and FID for the high power state and another FID and VID for the low power state.
With overclocking the benefits are enormous in the power bill and also for the low power state, since the manufacturer specifies 1.1v @ 1GHz and most CPUs handle 0.8v @ 800MHz quite easily. I'd love to get those low power states on my home server :)
I've been trying to get hold of one of these M57SLI-S4 boards to try and implement this but would like to know if this is something possible to achieve with the current code base.
Best regards, Tiago Marques
On Fri, Jul 3, 2009 at 3:55 PM, Harald Gutmannharald.gutmann@gmx.net wrote:
On Friday 03 July 2009 00:15:33 Rudolf Marek wrote:
Maybe Rudolf Marek can us help here, because he wrote the automatic generation for that ACPI table (SSDT).
Hi,
If I understand correctly, the 1800MHz is missing? If so, please check what is the portal frequency for this CPU. Maybe it is 2000 and not 1800 (so prop bios is wrong). Check the BKDG. I'm very busy so I think better would be if someone else could check.
I'll also check this, to see if coreboot or vendor is wrong. Thanks for you fast reply!
The interupt driven parport works now?
Right now the parport is just working with polling. But I think I can fix it to get it interrupt driven with a little dsdt.asl patch.
(Maybe sunday, or even towmorrow.)
Rudolf
Regards, Harald
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi I was X-AFK.
One thing I would like to ask, not just regarding this motherboard but all AM2/AM2+/AM3 boards. Would it be possible to implement a feature that would allow us to configure custom P-States to save on CMOS, other than what the manufacturer specifies? Most BIOS allow setting lower and higher multipliers than stock on some CPUs but disable CPU power management altogether when doing so. It would be quite a leap forward, when compared with vendor BIOS to be able to specify at least one VID and FID for the high power state and another FID and VID for the low power state.
Yes it would be possible.
With overclocking the benefits are enormous in the power bill and also for the low power state, since the manufacturer specifies 1.1v @ 1GHz and most CPUs handle 0.8v @ 800MHz quite easily. I'd love to get those low power states on my home server :)
Aha have you the revisionG? What about idle=halt. We can fine tune what the CPU will do when doing C1 (HLT) we change the PMM register values to more aggressive power save. Enabling the ALTvid maybe?
I've been trying to get hold of one of these M57SLI-S4 boards to try
and implement this but would like to know if this is something possible to achieve with the current code base.
Yes it is. The acpigen generator will generate any ACPI powerstates you want/need. The ACPIgen generator is simply capable of generating the data structures which are holding the power state values. By altering the algorithm for P states, you can then create your own custom values. Problem is if the CPU will allow the "underclocking" sometimes it wont transition to any fid which is lower then minFID or startFID. Please consult the CPU manual (BKDG). For the Pstates algo - 10.5.1.1 P-state Recognition Algorithm and the "portal" frequencies to see how the VCO and core frequency differs.
If you have revisionG CPU (dualcore) maybe it would be quite cool to implement the C1E state. This could save much more power.
Rudolf
Hi Rudolf,
On Mon, Jul 6, 2009 at 9:20 PM, Rudolf Marekr.marek@assembler.cz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi I was X-AFK.
One thing I would like to ask, not just regarding this motherboard but all AM2/AM2+/AM3 boards. Would it be possible to implement a feature that would allow us to configure custom P-States to save on CMOS, other than what the manufacturer specifies? Most BIOS allow setting lower and higher multipliers than stock on some CPUs but disable CPU power management altogether when doing so. It would be quite a leap forward, when compared with vendor BIOS to be able to specify at least one VID and FID for the high power state and another FID and VID for the low power state.
Yes it would be possible.
Sweet :)
With overclocking the benefits are enormous in the power bill and also for the low power state, since the manufacturer specifies 1.1v @ 1GHz and most CPUs handle 0.8v @ 800MHz quite easily. I'd love to get those low power states on my home server :)
Aha have you the revisionG? What about idle=halt. We can fine tune what the CPU will do when doing C1 (HLT) we change the PMM register values to more aggressive power save. Enabling the ALTvid maybe?
I have a G1 and an F3, both dual core. The altvid isn't just the regular down to 1000MHz/1.1v power management?
I've been trying to get hold of one of these M57SLI-S4 boards to try
and implement this but would like to know if this is something possible to achieve with the current code base.
Yes it is. The acpigen generator will generate any ACPI powerstates you want/need. The ACPIgen generator is simply capable of generating the data structures which are holding the power state values. By altering the algorithm for P states, you can then create your own custom values. Problem is if the CPU will allow the "underclocking" sometimes it wont transition to any fid which is lower then minFID or startFID. Please consult the CPU manual (BKDG). For the Pstates algo - 10.5.1.1 P-state Recognition Algorithm and the "portal" frequencies to see how the VCO and core frequency differs.
Nice. Would it be possible to do that after flashing(after some heavy programming, I suppose) or would it have to be done in source code? So, about lower than minVID and startFID, one would have to use an embedded controller to change the minVID supplied by the CPU? No way around by using just the CPU registers?
If you have revisionG CPU (dualcore) maybe it would be quite cool to implement the C1E state. This could save much more power.
I do, would have to mess around with the motherboard first. It's this one:
http://www.jetway.com.tw/jw/motherboard_view.asp?productid=261&proname=M...
It's MCP55 based, so perhaps something would work if I messed around with the M57SLI-S4 code?
Best regards,
Tiago Marques
Rudolf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkpSXJgACgkQ3J9wPJqZRNUeeACeJadoueVfi3t6ItcnKKdxL3Ud ktIAnjC9ncWNQdzH//KQs7fqUmU2VCsQ =Ta4G -----END PGP SIGNATURE-----
-
Andreas B. Mundt -
Harald Gutmann -
Joseph Smith -
Peter Stuge -
Rudolf Marek -
Russell Whitaker -
Tiago Marques