PIC question. (fwd)

[PS: Can I somehow tell mailman to accept my email from multiple
addresses?]

hello
    I'm trying to set "bios classic/dos" like state
    on the winfast 6300max/sis630 motherboard.

one of the issues I'm having is that it seems that
    interrupt 9 (keyboard)  is not beging tiggered.
    (this is after linuxbios finish booting and I
    start bochs bios).

Initially I have suspected that the PIC in the sis630
    is not getting programmed.

However, going over boch's bios sources I found out that it
    does DO program PIC..so it is not the issue here.
    (relevant code at end of email).

Thus the question is :

What is the extra step I'm missing that has to be run after
linuxbios finish but before attempting to program PIC for
bios/dos style interrupt mapping?

Ideas?

;; PIC
  mov al, #0x11 ; send initialisation commands
  out 0x20, al
  out 0xa0, al
  mov al, #0x08
  out 0x21, al
  mov al, #0x70
  out 0xa1, al
  mov al, #0x04
  out 0x21, al
  mov al, #0x02
  out 0xa1, al
  mov al, #0x01
  out 0x21, al
  out 0xa1, al

[Bob Drzyzgula]

On Wed, Oct 23, 2002 at 09:59:17AM -0400, [e-mail] wrote:
> [PS: Can I somehow tell mailman to accept my email from multiple
> addresses?]

You need separate subscription at each address. Then,
using the mailman control panel

http://www.clustermatic.org/mailman/options/linuxbios/<email address>

disable delivery to addresses you just want to be
able to post from.

--Bob

[Adam Sulmicki]

> > [PS: Can I somehow tell mailman to accept my email from multiple
> > addresses?]
>
> You need separate subscription at each address. Then,
> disable delivery to addresses you just want to be
> able to post from.

thanks.

now if only it was so easy to solve the PIC problem.
still stuck on it :/

[ollie lho]

On Wed, 2002-10-23 at 21:59, [e-mail] wrote:
> [PS: Can I somehow tell mailman to accept my email from multiple
> addresses?]
>
> hello
>    I'm trying to set "bios classic/dos" like state
>    on the winfast 6300max/sis630 motherboard.
>
> one of the issues I'm having is that it seems that
>    interrupt 9 (keyboard)  is not beging tiggered.
>    (this is after linuxbios finish booting and I
>    start bochs bios).
>
> Initially I have suspected that the PIC in the sis630
>    is not getting programmed.
>
> However, going over boch's bios sources I found out that it
>    does DO program PIC..so it is not the issue here.
>    (relevant code at end of email).
>
> Thus the question is :
>
> What is the extra step I'm missing that has to be run after
> linuxbios finish but before attempting to program PIC for
> bios/dos style interrupt mapping?

I don't quite understand your question, but LinuxBIOS does program
the PIC to map IRQ 0-15 to INT 0x20-0x30. So the keyboard interrupt
(IRQ 1) is routed to INT0x21. This is how Linux does for its interrupt
handling.

Ollie

[Adam Sulmicki]

> I don't quite understand your question, but LinuxBIOS does program
> the PIC to map IRQ 0-15 to INT 0x20-0x30. So the keyboard interrupt
> (IRQ 1) is routed to INT0x21. This is how Linux does for its interrupt
> handling.

yes, but I'm trying to add support to "legacy applications" (such as
Windows XP) to LinuxBIOS. for example right now I can run unmodified lilo
from linuxbios with all its bios interrupts calls, and lilo is able to
start some other application.

but weirdly enough the keyboard is not working under lilo.

as far as I can tell the PIC gets reprogrammed by bios to remap
the IRQ1 to INT 0x09, yet I still do not get the interrupt 9
tiggered. So I'm sort of lost as to why.

[ollie lho]

On Thu, 2002-10-24 at 09:20, Adam Sulmicki wrote:
> > I don't quite understand your question, but LinuxBIOS does program
> > the PIC to map IRQ 0-15 to INT 0x20-0x30. So the keyboard interrupt
> > (IRQ 1) is routed to INT0x21. This is how Linux does for its interrupt
> > handling.
>
> yes, but I'm trying to add support to "legacy applications" (such as
> Windows XP) to LinuxBIOS. for example right now I can run unmodified lilo
> from linuxbios with all its bios interrupts calls, and lilo is able to
> start some other application.
>
> but weirdly enough the keyboard is not working under lilo.
>
> as far as I can tell the PIC gets reprogrammed by bios to remap
> the IRQ1 to INT 0x09, yet I still do not get the interrupt 9
> tiggered. So I'm sort of lost as to why.

Is it possible that your BIOS reprogrammed the keyboard controller
in the wrong way ??

Ollie

[Adam Sulmicki]

> Is it possible that your BIOS reprogrammed the keyboard controller
> in the wrong way ??

it is possible, in fact it the only unchecked list on my To Check
List:
    PIC not getting (re) programmed		CHECK
    PIC interrupt mask is wrong		CHECK
    IF  flag being cleared			CHECK
    keyboard controller			????

so I guess that leaves the keyboard controller only.
That brings me to the point, what sort of references did you
use to write

cvs-freebios/freebios/src/pc80/keyboard.c

[Ronald G Minnich]

On Wed, 23 Oct 2002, Adam Sulmicki wrote:
> cvs-freebios/freebios/src/pc80/keyboard.c

Ollie, didn't KM Liu tell us how that was done?

ron

[ollie lho]

On Thu, 2002-10-24 at 09:58, Adam Sulmicki wrote:
> > Is it possible that your BIOS reprogrammed the keyboard controller
> > in the wrong way ??
>
> it is possible, in fact it the only unchecked list on my To Check
> List:
>    PIC not getting (re) programmed		CHECK
>    PIC interrupt mask is wrong		CHECK
>    IF  flag being cleared			CHECK
>    keyboard controller			????
>
> so I guess that leaves the keyboard controller only.
> That brings me to the point, what sort of references did you
> use to write

Some part of it comes form old sample code by our BIOS guy. Most of it
from "The undocumented PC" by Van Gilluwe.

Ollie

[Adam Sulmicki]

> Some part of it comes form old sample code by our BIOS guy. Most of it
> from "The undocumented PC" by Van Gilluwe.

sigh. I hoped for a datascheet.

so there's no a definite reference then?

[ollie lho]

On Thu, 2002-10-24 at 10:23, Adam Sulmicki wrote:
> > Some part of it comes form old sample code by our BIOS guy. Most of it
> > from "The undocumented PC" by Van Gilluwe.
>
> sigh. I hoped for a datascheet.
>
> so there's no a definite reference then?

It is legacy device which remain unchanged over the 80s and 90s.
I think the original datasheet were all gone.

Ollie

[Adam Sulmicki]

> > sigh. I hoped for a datascheet.
> > so there's no a definite reference then?
> It is legacy device which remain unchanged over the 80s and 90s.
> I think the original datasheet were all gone.

intel still has still has those two on their web site, if this is what you
are refering to:

Intel  8742 Keyboard Controller
Intel 80C42 Keyboard Controller

http://developer.intel.com/design/periphrl/datashts/290256.htm
http://developer.intel.com/design/periphrl/datashts/290414.htm

[Bari Ari]

Adam Sulmicki wrote:
> > > sigh. I hoped for a datasheets.
> > > so there's no a definite reference then?

Try a quick search on Google.

I came up with a number of links that detail the legacy PC XT and AT 
keyboard controllers from scan codes and programming to emulation and 
interface specifications.

Bari

[Ronald G Minnich]

On Wed, 23 Oct 2002, Adam Sulmicki wrote:
> so there's no a definite reference then?

the original PC bios is useful for almost anything you see in the pc80
directory.

ron

[ollie lho]

On Thu, 2002-10-24 at 09:58, Adam Sulmicki wrote:
> > Is it possible that your BIOS reprogrammed the keyboard controller
> > in the wrong way ??
>
> it is possible, in fact it the only unchecked list on my To Check
> List:
>    PIC not getting (re) programmed		CHECK
>    PIC interrupt mask is wrong		CHECK
>    IF  flag being cleared			CHECK
>    keyboard controller			????
>
> so I guess that leaves the keyboard controller only.
> That brings me to the point, what sort of references did you
> use to write
>
> cvs-freebios/freebios/src/pc80/keyboard.c

Here is the more solid and well documented version which is used in our 
internal version of etherboot.

void pc_keyboard_init()
{
    volatile unsigned char regval;

/* ------------------- controller side ----------------------*/
    printf("reset keyboard \n");
    /* send cmd = 0xAA, self test 8042 */
    outb(0xaa, 0x64);

/* empty input buffer or any other command/data will be lost */
    while ((inb(0x64) & 0x02))
    	post_code(0);
    /* empty output buffer or any other command/data will be lost */
    while ((inb(0x64) & 0x01) == 0)
    	post_code(1);

/* read self-test result, 0x55 should be returned form 0x60 */
    if ((regval = inb(0x60) != 0x55))
    	printf("self test failed\n");

/* send cmd = 0xAA, keyboard interface test */
    outb(0xab, 0x64);

/* empty input buffer or any other command/data will be lost */
    while ((inb(0x64) & 0x02))
    	post_code(0);
    /* empty output buffer or any other command/data will be lost */
    while ((inb(0x64) & 0x01) == 0)
    	post_code(1);

/* read keyboard interface test result, 0x00 should be returned form
0x60 */
    if ((regval = inb(0x60) != 0x00))
    	printf("keyboard interface test failed\n");

/* Enable Keyboard clock */
    outb(0xae, 0x64);
    outb(0xa8, 0x64);

/* ------------------- keyboard side ------------------------*/
    /* reset kerboard and self test  (keyboard side) */
    outb(0xff, 0x60);
    /* empty inut buffer or any other command/data will be lost */
    while ((inb(0x64) & 0x02))
    	post_code(4);
    /* empty output buffer or any other command/data will be lost */
    while ((inb(0x64) & 0x01) == 0)
    	post_code(5);
    /* keyboard should return ACK */
    if ((regval = inb(0x60) != 0xfa))
    	printf("keyboard self test failed\n");

while ((inb(0x64) & 0x01) == 0)
    	post_code(6);
    if ((regval = inb(0x60) != 0xaa))
    	printf("keyboard self test failed\n");

/* Disable keyboard */
    outb(0xf5, 0x60);
    /* empty inut buffer or any other command/data will be lost */
    while ((inb(0x64) & 0x02))
    	post_code(4);
    /* empty output buffer or any other command/data will be lost */
    while ((inb(0x64) & 0x01) == 0)
    	post_code(5);
    /* keyboard should return ACK */
    if ((regval = inb(0x60) != 0xfa))
    	printf("disable keyboard failed\n");

/* Write Keyboard Mode */
    outb(0x60, 0x64);
    while ((inb(0x64) & 0x02))
    	post_code(2);
    /* send cmd: scan code convert, disable mouse, enable IRQ 1 */
    outb(0x61, 0x60);
    while ((inb(0x64) & 0x02))
    	post_code(3);

/* Enable keyboard */
    outb(0xf4, 0x60);
    /* empty inut buffer or any other command/data will be lost */
    while ((inb(0x64) & 0x02))
    	post_code(4);
    /* empty output buffer or any other command/data will be lost */
    while ((inb(0x64) & 0x01) == 0)
    	post_code(5);
    /* keyboard should return ACK */
    if ((regval = inb(0x60) != 0xfa))
    	printf("enable keyboard failed\n");
}

[Ronald G Minnich]

should we put that better version of keyboard init into linuxbios?

ron

[ollie lho]

On Thu, 2002-10-24 at 10:53, Ronald G Minnich wrote:
> should we put that better version of keyboard init into linuxbios?
>
> ron

The code was used to debug one of our customer's prototype which wired
Keyboard and Mouse signal. I have no idea why I didn't commit it
to freebios cvs at that time.

Ollie

[Adam Sulmicki]

yay, keyboard works. now I have fully functional "lilo classic"
from under LinuxBIOS.

Thanks to everyone for help.

(the "fix" was to remove the broken keyboard init code from
the bios).

LinuxBIOS PCBIOS emulation...

Adam Sulmicki  writes:
> yay, keyboard works. now I have fully functional "lilo classic"
> from under LinuxBIOS.
>
> Thanks to everyone for help.
>
> (the "fix" was to remove the broken keyboard init code from
> the bios).

Cool.  I am interested to see how far, and where this goes.

I have been working to get kexec into the kernel and figuring
out how to use it to build interesting bootloaders.  What
I have been stumbling over is how do I put in support for booting
windows.  As I do not trust BIOS calls that talk to hardware
device drivers after a Linux kernel has run.

Long term does running your code on a machine with a normal BIOS
sound like a possibility?

If so then a very interesting bootloader can be built on top of kexec,
and the linux kernel.

Eric

LinuxBIOS PCBIOS emulation...

[Adam Sulmicki]

> > yay, keyboard works. now I have fully functional "lilo classic"
> > from under LinuxBIOS.
> >
> > Thanks to everyone for help.
> >
> > (the "fix" was to remove the broken keyboard init code from
> > the bios).
>
> Cool.  I am interested to see how far, and where this goes.

I'm fairly optimistic.

However, I'm sort of reluctant to go into details before the stuff are
released.

Either way. For now, can anyone recommend any "bios tester". something
other than dos (windows), and linux? The only other thing I can think of
right now is freebsd. Basically, I Think, there's going on some sort of
corruption shortly after the control is passed off from LILO. It happens
at semi-random points and when I stop ICE it usually is in undetermined
state giving me "reboot" as the only option. Right now I don't have many
good ideas how to attack this problem short of lots of OUT ax, 0x80 and
lots of hand stepping thru code.

LinuxBIOS PCBIOS emulation...

[Jan Kok]

----- Original Message -----
From: "Adam Sulmicki"
> Either way. For now, can anyone recommend any "bios tester". something
> other than dos (windows), and linux? The only other thing I can think of
> right now is freebsd.

Another OS you could try is BeOS.  BeOS is interesting in that it has its
own loader (sort of like LILO).  And if the disk is already spun up, BeOS
boots up and is ready to use in about 5 seconds.

Does NT supply its own loader?  NT is based on a different code stream than
Windows 98, so it may exercise different parts of the BIOS.

Oh, and there's OS2.  And Minix.  A look at the file system types listed in
the linux fdisk utility may give some clues to other OSs that run on PCs.

Cheers,
- Jan

[Ronald G Minnich]

will you be contributing your mods back to linuxbios for booting etc?

ron

[Ronald G Minnich]

On Thu, 24 Oct 2002, Adam Sulmicki wrote:
> (the "fix" was to remove the broken keyboard init code from
> the bios).

well we're going to need a replacement. That code has worked for a few
years so it would be good to know what's broken and how to fix it.

ron

[Steve M. Gehlbach]

> (the "fix" was to remove the broken keyboard init code from
> > the bios).
>
> well we're going to need a replacement. That code has worked for a few
> years so it would be good to know what's broken and how to fix it.
>
> ron

The keyboard init code works for me.  I remember looking through it a while
ago, I didn't see anything wrong AFAIR.  You of course have to setup the
superio properly first.  My biggest problem initially was that the init code
was _not_ running, due to needing to set "keyboard=1" in the nsuperio config
line.  Otherwise I have used it in both the stpc and the m787cl+ and it
works fine for me (smc-fdc37b78x and Sis/950 superio).

-Steve