Re: [PATCH] Remove warnings for s2892

Myles Watson wrote:
> +++ cbv2/src/pc80/keyboard.c	2009-04-30 15:47:16.000000000 -0600
> @@ -112,11 +112,11 @@
>  		outb(0x60, 0x64);
>  		if (!kbc_input_buffer_empty()) return;
>  		outb(0x20, 0x60);	/* send cmd: enable keyboard and IRQ 1 */
> -		u8 resend = 10;
> +		u8 broken_resend = 10;
>  		if ((inb(0x64) & 0x01)) {
>  			regval = inb(0x60);
>  		}
> -		--resend;
> +		--broken_resend;
>  	} while (regval == 0xFE && resend > 0);

This does not look right to me. I think the good fix is to not rename
things but only remove the u8 (re)declaration on line 115. Very good
find!

//Peter

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: SeaBIOS and hp dl145g3

On Thu, Apr 30, 2009 at 09:24:22AM -0600, Myles Watson wrote:
> On Thu, Apr 30, 2009 at 9:07 AM, samuel <samuel.verstraete <at> gmail.com> wrote:
> > On Thu, Apr 30, 2009 at 2:43 AM, Kevin O'Connor <kevin <at> koconnor.net> wrote:
> >> On Wed, Apr 29, 2009 at 04:53:13PM +0200, samuel wrote:
> >>> lspci -vnn : http://merlin.ugent.be/~samuel/dl145g3/info/lspci-vnn.txt
> 
> 01:0e.0 RAID bus controller [0104]: Broadcom BCM5785 [HT1000] SATA
> (Native SATA Mode) [1166:024a] (prog-if 05)
[...]
> This forces SeaBIOS to see it as a PATA controller, but it's in SATA mode.
> 
> Is there an easy way to add SATA support to SeaBIOS?  It sounds like a
> bit of work.  It looks like you could force the device to be in PATA
> mode, but once it's booted that's not ideal.

SeaBIOS only supports PATA mode.  To the best of my knowledge, filo
also only supports PATA mode drives (or SATA drives connected to a
PATA compatible controller).

I'm not against adding support, but I don't have the knowledge to do
it at this time.

-Kevin

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [PATCH] Remove warnings for s2892

> -----Original Message-----
> From: coreboot-bounces <at> coreboot.org [mailto:coreboot-bounces <at> coreboot.org]
> On Behalf Of Peter Stuge
> Sent: Thursday, April 30, 2009 5:47 PM
> To: coreboot <at> coreboot.org
> Subject: Re: [coreboot] [PATCH] Remove warnings for s2892
> 
> Myles Watson wrote:
> > +++ cbv2/src/pc80/keyboard.c	2009-04-30 15:47:16.000000000 -0600
> > @@ -112,11 +112,11 @@
> >  		outb(0x60, 0x64);
> >  		if (!kbc_input_buffer_empty()) return;
> >  		outb(0x20, 0x60);	/* send cmd: enable keyboard and IRQ
1 */
> > -		u8 resend = 10;
> > +		u8 broken_resend = 10;
> >  		if ((inb(0x64) & 0x01)) {
> >  			regval = inb(0x60);
> >  		}
> > -		--resend;
> > +		--broken_resend;
> >  	} while (regval == 0xFE && resend > 0);
> 
> This does not look right to me. I think the good fix is to not rename
> things but only remove the u8 (re)declaration on line 115. 
I didn't do that because it would change the behavior and I wouldn't be able
to tell breakage by building.  I don't know enough about keyboard
controllers to test this part of the code.

Re: [PATCH] Remove warnings for s2892

Myles Watson wrote:
> > This does not look right to me. I think the good fix is to not rename
> > things but only remove the u8 (re)declaration on line 115. 
> 
> I didn't do that because it would change the behavior and I wouldn't
> be able to tell breakage by building.  I don't know enough about
> keyboard controllers to test this part of the code.

The semantics of the changed code are pretty simple and looking at
other parts of the same file shows that it is a common construct.

It's used to retry keyboard communication a few times in case the
keyboard is slow or just generally crappy.

If you make a patch it is

Acked-by: Peter Stuge <peter <at> stuge.se>

:)

//Peter

--

-- 
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: unexpected exception errors loading vga rom

On Thu, 30 Apr 2009 14:55:59 -0700, ron minnich <rminnich <at> gmail.com> wrote:
> On Thu, Apr 30, 2009 at 2:01 PM, Joseph Smith <joe <at> settoplinux.org>
wrote:
> 
>> Right the INT lines A,B,C, and D are hard wired. But you can asign any
> PIRQ
>> to a function and any available IRQ to the PIRQ these are software
>> controlled.
>>>
> 
> The 3d register lists what functions can assert what interrupt lines.
> what is the value of 3d for each of these four device functions? You
> can use setpci to see.
> setpci -s bus:dev.fn 3d.b
> 
> 
> 
>> Hmm. That is another way of looking at it. The doc does say the "device"
>> acts as a interrupt router (which is INTA in this case). So the other
> three
>> are directly connected to it? Like the attached image?
> 
> I doubt that is exactly it but I think it's closer to my internal
> picture. 
I wish you could make your internal picture external, so I could see what
it is then.
So to test this I theory I should just be able to pluck out oh lets say
function 2 on INTB. If everythings works great except USB2 than that theory
is correct. On the otherhand if we loose USB2, USB3, and EHCI than we know

Re: SeaBIOS, serial output, and grub

On Wed, Apr 29, 2009 at 11:04:32PM -0400, Ward Vandewege wrote:
> I tried exactly that today (gmta ;), but that didn't seem to work for me -
> and SeaBIOS complained about an option rom checksum mismatch on the
> sgabios.bin option rom.

That's odd - it works fine for me.  Can you confirm the sgabios build
and then forward me the SeaBIOS log with it in CBFS?

> Since every other component in the boot process already does serial - how
> hard would it be to make SeaBIOS do serial too?

Well, SeaBIOS does support serial.  What you're looking for is the
ability to forward vgabios requests over serial.  SeaBIOS doesn't have
any vgabios capabilities today, so it would be a bit of work.  Since
sgabios is already designed to do this, I'm not sure what the value
would be in duplicating it in SeaBIOS.

> > >   serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
> > >   terminal --timeout=5 serial console
> > 
> > The only thing I can think of is that SeaBIOS may be setting the
> > serial port settings to something that grub doesn't like.  You can try
> > disabling the code in debug_serial_setup() in src/output.c.  However,
> > if you've already tried disabling CONFIG_DEBUG_SERIAL, then I don't
> > think this will do much.  It could be a conflict with coreboot serial
> > setup and grub I suppose.
> 
> Hmm. Suggestions for debugging?

You could try disabling serial in both coreboot and seabios.  It seems

Re: unexpected exception errors loading vga rom

>> What the 3d register will tell you is what INT is wired to
>> each function. So, e.g., I would guest that 3d is like this:
>>
>> USB1 1
>> USB2 2
>> USB3 3
>> EHCI 4
>>
> Yup.
> 00:1d.0 USB Controller #1 - 0x3d = 0x01
> 00:1d.1 USB Controller #2 - 0x3d = 0x02
> 00:1d.2 USB Controller #3 - 0x3d = 0x03
> 00:1d.7 USB Controller EHCI - 0x3d = 0x04
> 
FYI, here is what the ICH4 data sheet says about these 0x3d registers.
Looks like the PIRQ is internally specific.

USB 1,2, & 3 0x3d
Interrupt Pin (INT_PN) — RO. The values of 01h, 02h, and 03h in function
0, 1, and 2, respectively,
indicate to software that the corresponding ICH4 UHCI USB controllers drive
the INTA#, INTB#, and
INTC# PCI signals.
Note that this does not determine the mapping to the ICH4 PIRQ inputs.
Function 0 will drive PIRQA.
Function 1 will drive PIRQD. Function 2 will drive PIRQC. Function 1 does
not use the corresponding
mapping in order to spread the interrupts with AC97, which has historically
been mapped to PIRQB.

Re: SeaBIOS, serial output, and grub

On Thu, Apr 30, 2009 at 09:00:59PM -0400, Kevin O'Connor wrote:
> On Wed, Apr 29, 2009 at 11:04:32PM -0400, Ward Vandewege wrote:
> > I tried exactly that today (gmta ;), but that didn't seem to work for me -
> > and SeaBIOS complained about an option rom checksum mismatch on the
> > sgabios.bin option rom.
> 
> That's odd - it works fine for me.  Can you confirm the sgabios build
> and then forward me the SeaBIOS log with it in CBFS?

Will do tomorrow.

> > Since every other component in the boot process already does serial - how
> > hard would it be to make SeaBIOS do serial too?
> 
> Well, SeaBIOS does support serial.  What you're looking for is the
> ability to forward vgabios requests over serial.  SeaBIOS doesn't have
> any vgabios capabilities today, so it would be a bit of work.  Since
> sgabios is already designed to do this, I'm not sure what the value
> would be in duplicating it in SeaBIOS.

So - here's the problem with the sgabios approach. Unless I'm
misunderstanding how this works, using sgabios means that I'd have to disable
serial in any payload started from grub, as well?

I'm trying to get as minimal a changeset as possible between proprietary
bios/coreboot.

> > > >   serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
> > > >   terminal --timeout=5 serial console
> > > 

[PATCH] i82801xx IRQ Fix Up

This is a patch to use another IRQ besides IRQ12 to fix conflicts with
i8042 - PS/2 Mouse, most commonly assigned IRQ12 by the SuperIO. It took me
this long to catch this because I usually use a USB mouse.

Signed-off-by: Joseph Smith <joe <at> settoplinux.org>

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org

Index: src/southbridge/intel/i82801xx/i82801xx_lpc.c
===================================================================
--- src/southbridge/intel/i82801xx/i82801xx_lpc.c	(revision 4240)
+++ src/southbridge/intel/i82801xx/i82801xx_lpc.c	(working copy)
@@ -58,14 +58,16 @@
  */

 #define PIRQA 0x03
-#define PIRQB 0x05
-#define PIRQC 0x06
-#define PIRQD 0x07
-#define PIRQE 0x09
-#define PIRQF 0x0A
-#define PIRQG 0x0B
-#define PIRQH 0x0C
+#define PIRQB 0x04
+#define PIRQC 0x05
+#define PIRQD 0x06

Re: PCI interrupts

Joseph Smith wrote:
> I wish you could make your internal picture external, so I could
> see what it is then.

Interrupts are a little complex. I'll try to add some things.

The PCI bus allows each PCI device (by device I mean chip, with a
device id, and possibly with several functions) to use at most four
interrupt signals. They are called INTA, INTB, INTC and INTD.

Each PCI device is allowed to use (=activate) zero or more of them.
Devices with several functions can benefit from using more interrupt
signals, because then each function can get it's own interrupt
signal, which helps throughput. When multiple bus INTx signals are
connected to a device, how the device INTx pins are connected
internally in the device to the various functions is described by the
mapping in register 3d for each function, as Ron mentioned.

Many devices only generate one interrupt signal, and that will always
be INTA on the device. Some generate more than one signal.

The mainboard designer can swizzle interrupt signals between devices,
in order to spread out interrupt load so that four devices all
signalling on "their" INTA do not have to share the INTA bus signal.

The four PCI bus interrupt signals do not (and should not!) connect
to all PCI devices in parallell. The PCI bus INTA may be connected to
device 1 INTA, and device 2 INTB. This routing is what irq_tables.c
expresses, and unfortunately it cannot be probed. It's really a small
part of the mainboard netlist.