Current States of LinuxBios on SiS 630

[Ollie Lho]

Ron,
	We can boot the kernel from power-on now. With the romimage which will
be sent to you seperately, we can reach the point of kernel_thread(init,...);
in arch/i386/kernel/setup.c which means that everything is ready and we are
going to load/execute scripts in rc.d. We are using kernel-2.3.99pre5 with
the patch in export.tgz. If you can monitor port 0x80 with debug card you
can get 0xed at the end.

	We don't experience the keyboard problem you described, does that
happen after the kernel_thread() ?? After initrc are executed ??

	The frame buffer device driver is included in 2.4.0-test1 and later
kernel. There is some bug in Config.in which makes the option absent when
make config, but it is really easy to fix. I think we should move to 2.4.0
now since we are going to need fbdev real soon.

	Finally, could you please put your source to the FreeBIOS CVS ??
Usually we are unsure if our version matches yours, you know, things like
this make a lot of trouble.

BTW, we are asking VGA BIOS group to release more information/source code.
I hope we can turn on the monitor ASAP, using ICE and debug card is really a
pain in the ass.

P.S. Jeff, could you review the sisfb for us ?? What are we missing from the
driver for this special purpose ??

Ollie
-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Ronald G Minnich]

OK, I am now getting to mounting root. Then I start getting DMA
timeouts. I assume that some interrupt is not getting set up right. Any
hints? 

Also, my latest snap is at the usual http://www.acl.lanl.gov/linuxbios

We'll try to sync on the sourceforge as soon as we can.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Ronald G Minnich]

keyboard issues: the following code hangs right now:

void
pc_keyboard_reset()
{
  volatile unsigned char regval;
  /* reset any keyboard interrupts ... */
  (void) inb(0x60);
  /* test loop ... delete this when things seem to work ... */
  regval = inb(0x64);
  display("regval from kb is "); printint(regval); display("\n");
  regval &= 4;
  outb(0xaa, 0x64);
  while ((inb(0x64) & 1) == 0)
    ;

  display("0x60 has "); printint(inb(0x60)); display("\n");

  outb(0x60, 0x64);

  /* this test was 2, but it never worked, try 1 */
  while((inb(0x64) & 1) == 0)
    ;

  outb(0x61 | regval, 0x60);
  /* this test was 2, but it never worked, try 1 */
  while((inb(0x64) & 1) == 0)
    ;
  
}
#ifdef SIS630_KEYBOARD
void
intel_keyboard_on()
{
  unsigned char regval;

  regval = intel_conf_readb(0x80000847); 
  regval |= 8;
  intel_conf_writeb(0x80000847, regval); 
  pc_keyboard_reset();
}
#endif

The intel_keyboard_on seems to go ok, but the keyboard reset loops hang on
testing the low-order bit. Any ideas here would sure help.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Thomas J. Merritt]

|<><><><><> Original message from Ronald G Minnich  <><><><><>
|keyboard issues: the following code hangs right now:
|
|void
|pc_keyboard_reset()
|{
|  volatile unsigned char regval;
|  /* reset any keyboard interrupts ... */
|  (void) inb(0x60);

    This flushes any pending output byte (output from the PS/2 controller
perspective).  Check.

|  /* test loop ... delete this when things seem to work ... */
|  regval = inb(0x64);

    Read the status. check.

|  display("regval from kb is "); printint(regval); display("\n");
|  regval &= 4;
|  outb(0xaa, 0x64);

	Output the selftest command.  Before you do this you should ensure
that bit 1 (mask 0x02) is clear, otherwise the write of AA will be
ignored.

|  while ((inb(0x64) & 1) == 0)
|    ;

    Wait for the response byte. check.  But... we need to place a
delay between each iteration of the loop.  Otherwise the PS/2 controller
(an 8048 in disguise) will be to busy updating the status register to
complete the selftest.  Depends upon the PS/2 controller though.

|  display("0x60 has "); printint(inb(0x60)); display("\n");

    Print it out.  It should be 0x55, otherwise you will need to send
the selftest command again.

|  outb(0x60, 0x64);

	Output WRITE command, we're going to send a command to the PS/2
controller.  You need to check bit 1 again before you send this WRITE command
otherwise the PS/2 controller may not be ready for it yet.

|  /* this test was 2, but it never worked, try 1 */
|  while((inb(0x64) & 1) == 0)
|    ;

	Were spining waiting for the PS/2 controller to give us a byte.
The PS/2 controller is spining waiting for us to write the command. Deadlock.
The test about really should be on '& 2'.  If it doesn't complete it is
because you didn't spin on '& 2' before outputing the WRITE command.

|  outb(0x61 | regval, 0x60);
|  /* this test was 2, but it never worked, try 1 */

	Write the command.  I'm not sure what you're attempting to
do here.  bit 6 will enable PC/XT scan code conversion, otherwise you'll
get PC/AT scan codes.  You're also enabling PS/2 keyboard interrupts bit 0.

|  while((inb(0x64) & 1) == 0)
|    ;

	Wait for the PS/2 controller to have accepted the command.  You
	need to spin on '& 2' though.

General rules for talking to a PS/2 controller.  Before writing to
either the control or data port spin waiting for bit 1 of the status
port to be zero.  Before reading the data port.  spin waiting for
bit 0 of the status port to be one.  If you know that you have a PS/2
interrupt you can break the second rule, but you should check the status
port to ensure that you don't have a suprious interrupt.

Thomas J. Merritt
[e-mail]
1-415-834-9111
-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Ronald G Minnich]

Thanks, Thomas, for the comments. I just yanked that code out of the
kernel without wasting much time understanding it (obviously :-) )

I'll try to get a better version soon (unless someone wants to write it
:) )

Current project is getting my SiS kernel to stop oops-ing. 

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[kmliu]

Dear Ron:

Once I get your code then I can make keyboard controller work properly.
Because it is a very standard device.

Regards,
K.M. Liu
          - - - - - - - - - - SiS Corp. - - - - - - - - - -
System Software                                         Email:
[e-mail]
Software Development Division                 Tel: [phone] ext 6230
Silicon Integrated Systems Corporation      Fax: [phone]

No.16, Creation RD.1, Science-based Industrial Park
Hsin Chu, Taiwan, R.O.C.


----- Original Message -----
±H¥óªÌ: Ronald G Minnich <[e-mail]>
¦¬¥óªÌ: <[e-mail]>
°Æ¥»: K.M. Liu <[e-mail]>; Joe Wang <[e-mail]>;
<[e-mail]>
¶Ç°e¤é´Á: 2000¦~6¤ë1¤é AM 04:49
¥D¦®: Re: [OpenBIOS] Current States of LinuxBios on SiS 630
> Thanks, Thomas, for the comments. I just yanked that code out of the
> kernel without wasting much time understanding it (obviously :-) )
>
> I'll try to get a better version soon (unless someone wants to write it
> :) )
>
> Current project is getting my SiS kernel to stop oops-ing.
>
> ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[kmliu]

Dear Ron:

I attached the 8042(keyboard controller) and keyboard initialization code to
you.
I have tested the steps with H/W ICE then keyboard can work properly.
Because it is DOS assembler style so, you need to transfer to Linux
assembler style.

PS. Your original code have many bugs in 8042 and keyboard initialization.

Thanks&Best Regards,
K.M. Liu
          - - - - - - - - - - SiS Corp. - - - - - - - - - -
System Software                                         Email:
[e-mail]
Software Development Division                 Tel: [phone] ext 6230
Silicon Integrated Systems Corporation      Fax: [phone]

No.16, Creation RD.1, Science-based Industrial Park
Hsin Chu, Taiwan, R.O.C.


----- Original Message -----
±H¥óªÌ: Ronald G Minnich <[e-mail]>
¦¬¥óªÌ: kmliu <[e-mail]>
°Æ¥»: <[e-mail]>; Joe Wang
<[e-mail]>; <[e-mail]>
¶Ç°e¤é´Á: 2000¦~6¤ë1¤é AM 11:08
¥D¦®: Re: [OpenBIOS] Current States of LinuxBios on SiS 630
> I think what I really want from the linuxbios point of view is the
> absolute minimum done in linuxbios to make the keyboard work in
> linux. There's no point in initializing the keyboard twice.
>
> Anyway, the latest snap is now on the web page. Current status is we're
> mounting root, and the fbdev comes up and drives the display. I'm going to
> put some pictures on the web page this or next week.
>
> ron

[Ronald G Minnich]

I think what I really want from the linuxbios point of view is the
absolute minimum done in linuxbios to make the keyboard work in
linux. There's no point in initializing the keyboard twice.

Anyway, the latest snap is now on the web page. Current status is we're
mounting root, and the fbdev comes up and drives the display. I'm going to
put some pictures on the web page this or next week.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Ronald G Minnich]

On Thu, 1 Jun 2000, kmliu wrote:
> PS. Your original code have many bugs in 8042 and keyboard initialization.

ouch! I pulled it straight from 2.3.99-pre5! 

Thanks for your code. I will translate to C and put it in the kernel. 

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[fb-d] Current States of LinuxBios on SiS 630

[Jeff Garzik]

Ollie Lho wrote:
> The frame buffer device driver is included in 2.4.0-test1 and later
> kernel. There is some bug in Config.in which makes the option absent when
> make config, but it is really easy to fix. I think we should move to 2.4.0
> now since we are going to need fbdev real soon.

It shouldn't be a big jump from 2.3.99-pre9 to 2.4.0-test1.  Make sure
you get alan cox's latest 'ac' patch (currently ac7), which contains
mucho bug fixes.
> Finally, could you please put your source to the FreeBIOS CVS ??
> Usually we are unsure if our version matches yours, you know, things like
> this make a lot of trouble.

Let me know if any SIS engineers need CVS commit permissions.  Ronald
and Johan (original STPC BIOS author) already have CVS commit
permission.
> BTW, we are asking VGA BIOS group to release more information/source code.
> I hope we can turn on the monitor ASAP, using ICE and debug card is really a
> pain in the ass.

Note that it is normal for a lot of card initialization secrets, and
also per-OEM memory timing data, to be hidden in VGA BIOS.
> P.S. Jeff, could you review the sisfb for us ?? What are we missing from the
> driver for this special purpose ??

I'm not sure about the oops yet, but with respect to VGA BIOS init: 
I've been looking through it already to see if I can get the 6326 card
going with sisfb.

The main thing that appears to be missing is memory configuration.  Just
like linuxbios and DRAM init, the video card's memory timings must be
setup, and video memory sized.  There are many parallels between what a
VGA BIOS does to initialize a video card, and what a PC BIOS does to
initialize a PC.

Beyond that, there may be other differences which are not immediately
apparent from my reading of the specs.  For example VGA emulation mode
may need to be initialized before VGA registers/functions work at all.

You can test sisfb without VGA BIOS init simply by (a) making it the
"non-primary" VGA display card in your PC, and/or (b) removing the video
BIOS ROM from the video card if possible.  Since the PC BIOS -only-
executes the VGA BIOS for the first display card it finds, secondary
cards are not initialized at all.

	Jeff




	Jeff



-- 
Jeff Garzik              | Liberty is always dangerous, but
Building 1024            | it is the safest thing we have.
MandrakeSoft, Inc.       |      -- Harry Emerson Fosdick
-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[fb-d] Current States of LinuxBios on SiS 630

On  1 Jun, Jeff Garzik wrote:
> Ollie Lho wrote:
> > Finally, could you please put your source to the FreeBIOS CVS ??
> > Usually we are unsure if our version matches yours, you know, things like
> > this make a lot of trouble.
>
> Let me know if any SIS engineers need CVS commit permissions.  Ronald
> and Johan (original STPC BIOS author) already have CVS commit
> permission.

What is the prefered method for submitting updates from what might be
considered random people?

I downloaded several versions of the linuxbios code that were supposed
to be snapshots of "working" code that wouldn't even compile.  The
necessary changes are small but very important when the readme says
to just type make in the correct directory.

I will be doing much more work, some of which will be generic to the
freebios/linuxbios projects.  Should I request CVS commit permissions or
should I submit patches to someone?  If I should submit patches, to
whom should I submit them?

Cheers!
Ty

-- 
Tyson D Sawyer             IS Robotics                   http://www.isr.com
Senior Systems Engineer    Real World Interface Div.     http://www.rwii.com
[e-mail]           Robots for the Real World

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[fb-d] Current States of LinuxBios on SiS 630

[Jeff Garzik]

[e-mail] wrote:
> On  1 Jun, Jeff Garzik wrote:
> > Ollie Lho wrote:
> > > Finally, could you please put your source to the FreeBIOS CVS ??
> > > Usually we are unsure if our version matches yours, you know, things like
> > > this make a lot of trouble.
> >
> > Let me know if any SIS engineers need CVS commit permissions.  Ronald
> > and Johan (original STPC BIOS author) already have CVS commit
> > permission.
>
> What is the prefered method for submitting updates from what might be
> considered random people?

Use the "submit a patch" link on the home page :)

http://freebios.sourceforge.net/

Like most open source projects, if the patches are consistently good,
you'll get CVS commit access eventually.

	Jeff





-- 
Jeff Garzik              | Liberty is always dangerous, but
Building 1024            | it is the safest thing we have.
MandrakeSoft, Inc.       |      -- Harry Emerson Fosdick
-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[fb-d] Current States of LinuxBios on SiS 630

[Ronald G Minnich]

On Thu, 1 Jun 2000 [e-mail] wrote:
> I downloaded several versions of the linuxbios code that were supposed
> to be snapshots of "working" code that wouldn't even compile.  The
> necessary changes are small but very important when the readme says
> to just type make in the correct directory.

sorry about that :-)
> I will be doing much more work, some of which will be generic to the
> freebios/linuxbios projects.  Should I request CVS commit permissions or
> should I submit patches to someone?  If I should submit patches, to
> whom should I submit them?

I have to get my stuff committed back to the sourcefourge, but I'm worried
about committing such a significant delta without jeff's taking a quick
look.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[fb-d] Current States of LinuxBios on SiS 630

[Ollie Lho]

Jeff Garzik wrote:
> > Finally, could you please put your source to the FreeBIOS CVS ??
> > Usually we are unsure if our version matches yours, you know, things like
> > this make a lot of trouble.
>
> Let me know if any SIS engineers need CVS commit permissions.  Ronald
> and Johan (original STPC BIOS author) already have CVS commit
> permission.

Please put me ([e-mail]) and K.M. ([e-mail]) on the list.
> > P.S. Jeff, could you review the sisfb for us ?? What are we missing from the
> > driver for this special purpose ??
>
> I'm not sure about the oops yet, but with respect to VGA BIOS init:
> I've been looking through it already to see if I can get the 6326 card
> going with sisfb.
>
> The main thing that appears to be missing is memory configuration.  Just
> like linuxbios and DRAM init, the video card's memory timings must be
> setup, and video memory sized.  There are many parallels between what a
> VGA BIOS does to initialize a video card, and what a PC BIOS does to
> initialize a PC.

For intergated VGA in SiS 630:

	dram timming of VGA == dram timming of System
	dram sizing of VGS == How much you want, you get it.
> Beyond that, there may be other differences which are not immediately
> apparent from my reading of the specs.  For example VGA emulation mode
> may need to be initialized before VGA registers/functions work at all.

What ?? Could you be more specific ??

Ollie
-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[fb-d] Current States of LinuxBios on SiS 630

[Ronald G Minnich]

On Fri, 2 Jun 2000, Ollie Lho wrote:
> Please put me ([e-mail]) and K.M. ([e-mail]) on the list.

Just don't do any commits until later today -- I want to commit linuxbios.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[fb-d] Current States of LinuxBios on SiS 630

On  1 Jun, Jeff Garzik wrote:
> [e-mail] wrote:
> > On  1 Jun, Jeff Garzik wrote:
> > > Ollie Lho wrote:
> > > > Finally, could you please put your source to the FreeBIOS CVS ??
> > > > Usually we are unsure if our version matches yours, you know, things like
> > > > this make a lot of trouble.
> > >
> > > Let me know if any SIS engineers need CVS commit permissions.  Ronald
> > > and Johan (original STPC BIOS author) already have CVS commit
> > > permission.
> >
> > What is the prefered method for submitting updates from what might be
> > considered random people?
>
> Use the "submit a patch" link on the home page :)
>
> http://freebios.sourceforge.net/

Since I am working more with the linuxbios "branch" of things than the
freebios branch it isn't clear that what you suggest is a useful way to
get patches in.
> Like most open source projects, if the patches are consistently good,
> you'll get CVS commit access eventually.

...that works for me.  I will be working on a home-brew 440BX board. 
Direct CVS access may not be better than submitting patches so long as
there is an effective patch submitting process.

If commiting linuxbios into the freebios repository is taking place
during the next couple of days I should probably just wait and re-sync
when that is done.

Cheers!
Ty

-- 
Tyson D Sawyer             IS Robotics                   http://www.isr.com
Senior Systems Engineer    Real World Interface Div.     http://www.rwii.com
[e-mail]           Robots for the Real World

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[fb-d] Current States of LinuxBios on SiS 630

[Ronald G Minnich]

I have been looking closely at my freebios changes for linuxbios. They are
pretty much disjoint to what is there now. 

I'll wait a little longer but if I hear no objections I'm going to commit
without a branch, since basically everything I've done would be useful to
both things. 

In freebios there is now a linuxbios directory. So we have:

freebios/
	linuxbios
	chip
	include
	rom
	src

and so on. There's no real intrusion of linuxbios on the other pieces. 

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[fb-d] Current States of LinuxBios on SiS 630

[Jeff Garzik]

Ronald G Minnich wrote:
> I have been looking closely at my freebios changes for linuxbios. They are
> pretty much disjoint to what is there now.
>
> I'll wait a little longer but if I hear no objections I'm going to commit
> without a branch, since basically everything I've done would be useful to
> both things.
>
> In freebios there is now a linuxbios directory. So we have:
>
> freebios/
>         linuxbios
>         chip
>         include
>         rom
>         src
>
> and so on. There's no real intrusion of linuxbios on the other pieces.

Looks good, I would only change minor things...   PCI code doesn't
belong in chip/intel, and neither does SiS-related code (that's for
chip/sis...)

crt0.S similarly should probably go in chip/intel or chip/sis,
respectively.

the inflate code shouldn't be in the linuxbios directory.

Basically I would like to move code which it useful outside of
linuxbios, outside of the linuxbios directory.

-- 
Jeff Garzik              | Liberty is always dangerous, but
Building 1024            | it is the safest thing we have.
MandrakeSoft, Inc.       |      -- Harry Emerson Fosdick
-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[fb-d] Current States of LinuxBios on SiS 630

[Jeff Garzik]

Ollie Lho wrote:
> Jeff Garzik wrote:
> > > Finally, could you please put your source to the FreeBIOS CVS ??
> > > Usually we are unsure if our version matches yours, you know, things like
> > > this make a lot of trouble.
> >
> > Let me know if any SIS engineers need CVS commit permissions.  Ronald
> > and Johan (original STPC BIOS author) already have CVS commit
> > permission.
>
> Please put me ([e-mail]) and K.M. ([e-mail]) on the list.

You need to get accounts on sourceforge (http://sourceforge.net/) and
let me know your sourceforge usernames..
> > > P.S. Jeff, could you review the sisfb for us ?? What are we missing from the
> > > driver for this special purpose ??
> >
> > I'm not sure about the oops yet, but with respect to VGA BIOS init:
> > I've been looking through it already to see if I can get the 6326 card
> > going with sisfb.
> >
> > The main thing that appears to be missing is memory configuration.  Just
> > like linuxbios and DRAM init, the video card's memory timings must be
> > setup, and video memory sized.  There are many parallels between what a
> > VGA BIOS does to initialize a video card, and what a PC BIOS does to
> > initialize a PC.
>
> For intergated VGA in SiS 630:
>
> dram timming of VGA == dram timming of System
>         dram sizing of VGS == How much you want, you get it.
> > Beyond that, there may be other differences which are not immediately
> > apparent from my reading of the specs.  For example VGA emulation mode
> > may need to be initialized before VGA registers/functions work at all.
>
> What ?? Could you be more specific ??

Unfortunately no, the point is that the VGA BIOS is the place where OEMs
put all their customizations -- workarounds for hardware bugs, bug fixes
in legacy VGA emulation, etc.  Without seeing the VGA BIOS source code,
you cannot know whether the VGA BIOS simply initializes the card to text
mode and implements VESA support, or much much more.

	Jeff




-- 
Jeff Garzik              | Liberty is always dangerous, but
Building 1024            | it is the safest thing we have.
MandrakeSoft, Inc.       |      -- Harry Emerson Fosdick
-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[fb-d] Current States of LinuxBios on SiS 630

[Ronald G Minnich]

On Fri, 2 Jun 2000, Jeff Garzik wrote:
> Looks good, I would only change minor things...   PCI code doesn't
> belong in chip/intel, and neither does SiS-related code (that's for
> chip/sis...)

chip/sis vs. chip/intel. There's an awful lot of common stuff. That said,
I guess I don't care too much.
> the inflate code shouldn't be in the linuxbios directory.

that's ok.
> Basically I would like to move code which it useful outside of
> linuxbios, outside of the linuxbios directory.

no problem. be careful with fill_inbuf though -- it is
motherboard-specific.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message