Hello!
I've been reading the SIS630 datasheet and found out that the chipset has a watchdog timer (for some reason they call it 'software') similar to that of the i810.
Does anybody here know if there is a ready driver for that thing?
P.S. I'm inspecting the datasheet in search for ways of disabling AC97 Audio and Modem functions, as that would be a great addition to the linuxbios.
Spirit wrote:
I've been reading the SIS630 datasheet and found out that the chipset has a watchdog timer (for some reason they call it 'software') similar to that of the i810.
Does anybody here know if there is a ready driver for that thing?
Not aware of a linux driver, but you might want to turn off the software watchdog earlier, if you use compression. Right now it is disabled in southbridge.c which is too late since decompression takes a few seconds.
This will do it in chipinit.inc:
#define ACPI_BASE_ADDR 0x5000
/* Disable Auto-Reset */ movw $(ACPI_BASE_ADDR + 0x56), %dx inb %dx, %al orb 0x40, %al outb %al, %dx
/* Disable Software Watchdog */ xorb %al, %al movw $(ACPI_BASE_ADDR + 0x4b), %dx outb %al, %dx ---
There are some other simplifications that can be put into chipinit.inc (the gdt reload is not necessary after the Eric's changes in c_start.S), but I haven't had time to make a diff and send it to Ron.
-Steve
Hello Steve,
Monday, March 17, 2003, 4:56:02 AM, you wrote:
SG> Spirit wrote:
I've been reading the SIS630 datasheet and found out that the chipset has a watchdog timer (for some reason they call it 'software') similar to that of the i810.
Does anybody here know if there is a ready driver for that thing?
SG> Not aware of a linux driver, but you might want to turn off the software SG> watchdog earlier, if you use compression. Right now it is disabled in SG> southbridge.c which is too late since decompression takes a few seconds.
That shouldn't be a problem unless it takes 5 seconds to get to the southbridge.c code. But of course, moving it to an earlier position is a good idea.
However, what I was asking for is how to enable and make use of it, not how to disable it. I think I'll need to look into the i810-tco.c from the kernel sources and try to modify it for SIS630.
SG> This will do it in chipinit.inc: SG> #define ACPI_BASE_ADDR 0x5000
Speaking of ACPI... I can't get it working with LinuxBIOS. ospm_*.o modules won't load and the kernel complains on being unable to read ACPI tables.
SG> There are some other simplifications that can be put into chipinit.inc SG> (the gdt reload is not necessary after the Eric's changes in c_start.S), SG> but I haven't had time to make a diff and send it to Ron.
What I would really like to see somewhere in the LinuxBIOS code is the options to disable SiS630 embedded modem and audio controllers. I browser through the datasheet and didn't find how to disable them. I probably should re-read it, but if anyone knows the way already, I'd appreciate showing it to me.
I'm having problems with the serial console when booting LinuxBIOS on a pcchips m787cl+ motherboard. The serial works for output (I can see what the box says) but doesn't for input (I can't login from the serial console). If I boot the same kernel with the same parameters (console=ttyS0,9600n8) using the original motherboard's BIOS (AMI), I don't have any problems at all.
Any suggestions?
SG> SG> I assume you changed "option TTYS0_BAUD=38400" in SG> /mainboard/pcchips/m787cl+ to 9600?
Yes, I did. But that's not the problem. Or at least not the main one. It was a problem of an old init, as Ron suggested. I ugraded init and the problem is gone.
Best regards, Spirit mailto:spirit@reactor.ru
On Mon, 17 Mar 2003, Spirit wrote:
That shouldn't be a problem unless it takes 5 seconds to get to the southbridge.c code. But of course, moving it to an earlier position is a good idea.
It really takes 5 seconds? it did not used to. I liked having it in the southbridge code for a simple reason: if you are in that code then things are working well. If you are not in that kind at some point, you really want that watchdog reset. It is a very simple self-test.
However, what I was asking for is how to enable and make use of it, not how to disable it. I think I'll need to look into the i810-tco.c from the kernel sources and try to modify it for SIS630.
it's easy. Set the bit, and in 5 seconds or so you get a reset.
Here is a sample function that will enable reset, from the old patches.
+void +sis503_reset(struct pci_dev *dev) +{ + unsigned char b; + unsigned short acpi_base; + + printk(KERN_ERR __FUNCTION__ ": starting reset operation. \n"); + + /* Enable ACPI by set B7 on Reg 0x40, LPC */ + pci_read_config_byte(dev, 0x40, &b); + pci_write_config_byte(dev, 0x40, b | 0x80); + printk(KERN_ERR __FUNCTION__ ": enabled ACPI. \n"); + + /* get the ACPI base address for register 0x74,0x75 of LPC */ + pci_read_config_word(dev, 0x74, &acpi_base); + printk(KERN_ERR __FUNCTION__ ":acpi base: %x\n", acpi_base); + + /* Set software watchdog timer init value */ + outb(0x03, 0x4a + acpi_base); + printk(KERN_ERR __FUNCTION__ ": set the dog. \n"); + + printk(KERN_ERR __FUNCTION__ ": enabling dog. \n"); + /* Software watchdog enable, issue PCIRST# when time expire */ + outb(0x8f, 0x4b + acpi_base); + + printk(KERN_ERR __FUNCTION__ ": We should reset soon. \n"); +}
Speaking of ACPI... I can't get it working with LinuxBIOS. ospm_*.o modules won't load and the kernel complains on being unable to read ACPI tables.
that's because there are not acpi tables.
ron
"Ronald G. Minnich" rminnich@lanl.gov writes:
On Mon, 17 Mar 2003, Spirit wrote:
That shouldn't be a problem unless it takes 5 seconds to get to the southbridge.c code. But of course, moving it to an earlier position is a good idea.
It really takes 5 seconds? it did not used to. I liked having it in the southbridge code for a simple reason: if you are in that code then things are working well. If you are not in that kind at some point, you really want that watchdog reset. It is a very simple self-test.
This is something I want to look at. I have seen the decompresser taking a full second on several different machines and I find any discernible pause to be a problem.
Tentatively I have attributed this to a poorly setup cache somewhere. But I have not had a chance to really investigate it.
As it stands right now I am in inch from moving the decompresser from code that runs from ROM to code that runs from RAM, to see if that fixes the performance issue.
When I load an etherboot image I have never detected a noticeable slowdown. Which is relevant because etherboot uses exactly the same code. With just minimal changes to cope with running the code in a different environment.
Eric
On 17 Mar 2003, Eric W. Biederman wrote:
As it stands right now I am in inch from moving the decompresser from code that runs from ROM to code that runs from RAM, to see if that fixes the performance issue.
didn't we make ROM cacheable yet? Rather than keep moving things to RAM, if we make ROM cacheable that is a far simpler solution I think.
ron
"Ronald G. Minnich" rminnich@lanl.gov writes:
On 17 Mar 2003, Eric W. Biederman wrote:
As it stands right now I am in inch from moving the decompresser from code that runs from ROM to code that runs from RAM, to see if that fixes the performance issue.
didn't we make ROM cacheable yet? Rather than keep moving things to RAM, if we make ROM cacheable that is a far simpler solution I think.
Oh, I agree. I just think I have seen cases where the rom is cacheable and the code takes a noticeable amount of time anyway.
Eric
Ronald G. Minnich wrote:
On Mon, 17 Mar 2003, Spirit wrote:
That shouldn't be a problem unless it takes 5 seconds to get to the southbridge.c code. But of course, moving it to an earlier position is a good idea.
It really takes 5 seconds? it did not used to. I liked having it in the southbridge code for a simple reason: if you are in that code then things are working well. If you are not in that kind at some point, you really want that watchdog reset. It is a very simple self-test.
On PCChips m787cl+ that I have, it will definitely reset if you turn compression on, without disabling the watchdog. I suppose it must be 5 seconds, but I did not time it. Definitely a long time.
Maybe it is related to running at 0xffff0000 instead of 0xf0000. Did we cached that region? The mtrr code is there but I have not checked through it to see what regions are cached.
-Steve
On Mon, 17 Mar 2003, Steve Gehlbach wrote:
Maybe it is related to running at 0xffff0000 instead of 0xf0000. Did we cached that region? The mtrr code is there but I have not checked through it to see what regions are cached.
I am almost certain we do not cache that region. That might be it.
ron
Ronald G. Minnich wrote:
On Mon, 17 Mar 2003, Steve Gehlbach wrote:
Maybe it is related to running at 0xffff0000 instead of 0xf0000. Did we cached that region? The mtrr code is there but I have not checked through it to see what regions are cached.
I am almost certain we do not cache that region. That might be it.
ron
How about using XIP_ROM_SIZE and XIP_ROM_BASE; seems to setup WP caching on variable MTRR 0x203 (mem type=5). Or does this have other effects; maybe use a different option with same code?
-Steve
Steve Gehlbach steve@nexpath.com writes:
Ronald G. Minnich wrote:
On Mon, 17 Mar 2003, Steve Gehlbach wrote:
Maybe it is related to running at 0xffff0000 instead of 0xf0000. Did we cached that region? The mtrr code is there but I have not checked through it
to see what regions are cached.
I am almost certain we do not cache that region. That might be it. ron
How about using XIP_ROM_SIZE and XIP_ROM_BASE; seems to setup WP caching on variable MTRR 0x203 (mem type=5). Or does this have other effects; maybe use a different option with same code?
XIP is short for Execute in place. And that is exactly what it is designed for.
Eric
Eric W. Biederman wrote:
Steve Gehlbach steve@nexpath.com writes:
Ronald G. Minnich wrote: How about using XIP_ROM_SIZE and XIP_ROM_BASE; seems to setup WP caching on variable MTRR 0x203 (mem type=5). Or does this have other effects; maybe use a different option with same code?
XIP is short for Execute in place. And that is exactly what it is designed for.
Fair enough, so we'll use 0x204,5 and separate code. I assume it will speed things up, have to test it in a day or so. As it is, the 5 sec delay makes compression hard to live with.
I am also assuming the Via C3 has the variable MTRRs, that may not be a correct assumption. The Intel book says P6 family.
-Steve
Steve Gehlbach steve@nexpath.com writes:
Eric W. Biederman wrote:
Steve Gehlbach steve@nexpath.com writes:
Ronald G. Minnich wrote: How about using XIP_ROM_SIZE and XIP_ROM_BASE; seems to setup WP caching on variable MTRR 0x203 (mem type=5). Or does this have other effects; maybe use
a
different option with same code?
XIP is short for Execute in place. And that is exactly what it is designed for.
Fair enough, so we'll use 0x204,5 and separate code. I assume it will speed things up, have to test it in a day or so. As it is, the 5 sec delay makes compression hard to live with.
Error. Communications failure.
I meant this situation is exactly what it is designed for.
I am also assuming the Via C3 has the variable MTRRs, that may not be a correct assumption. The Intel book says P6 family.
Very good question what does the C3 have? I recall the strange clones not following intels variable mtrrs.
Eric
Eric W. Biederman wrote:
Error. Communications failure.
I meant this situation is exactly what it is designed for.
Sorry. I misunderstood.
I am also assuming the Via C3 has the variable MTRRs, that may not be a correct assumption. The Intel book says P6 family.
Very good question what does the C3 have? I recall the strange clones not following intels variable mtrrs.
Hard to get this out of Via, they don't do datasheets for ordinary folks, but posts on the newsgroups seem to indicate p6 compatibility in some versions anyway:
From a post in linux.kernel: cat /proc/cpuinfo:
processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 8 model name : VIA C3 Ezra stepping : 9 cpu MHz : 999.910 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow bogomips : 1989.22
I'll try the XIP_ROM_SIZE etc tomorrow.
-Steve
Steve Gehlbach steve@nexpath.com writes:
Eric W. Biederman wrote:
Error. Communications failure. I meant this situation is exactly what it is designed for.
Sorry. I misunderstood.
I am also assuming the Via C3 has the variable MTRRs, that may not be a
correct
assumption. The Intel book says P6 family.
Very good question what does the C3 have? I recall the strange clones not following intels variable mtrrs.
Hard to get this out of Via, they don't do datasheets for ordinary folks, but posts on the newsgroups seem to indicate p6 compatibility in some versions anyway:
From a post in linux.kernel: cat /proc/cpuinfo:
processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 8 model name : VIA C3 Ezra stepping : 9 cpu MHz : 999.910 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow bogomips : 1989.22
I'll try the XIP_ROM_SIZE etc tomorrow.
So it looks like they have the normal mtrrs.
For the strange cpus they should be supported in the linux kernel and have code behind /proc/mtrr.
Eric
Eric W. Biederman wrote:
So it looks like they have the normal mtrrs.
Yep, appears so.
I tried the following this morning:
option XIP_ROM_SIZE= 0x01000000 option XIP_ROM_BASE= 0xff000000
This caches the top 16M. The decompress time went from 13 seconds (!!) to less than a second. Guess we better make sure to cache the upper ROM.
cat /proc/cpuinfo for my my unit lists as "Via Samuel 2" at 551Mhz and 1101BogoMips, otherwise the same as the one I posted in this thread yesterday.
-Steve
On Mon, 2003-03-17 at 21:35, Spirit wrote:
What I would really like to see somewhere in the LinuxBIOS code is the options to disable SiS630 embedded modem and audio controllers. I browser through the datasheet and didn't find how to disable them. I probably should re-read it, but if anyone knows the way already, I'd appreciate showing it to me.
Search the keyword DISABLE_INTERNAL_DEVICE or something in the source. Try writing different value (bit patterns) to the register 0x7c (not so sure ??) in southbridge. It is undocumented.
-
ebiederman＠lnxi.com -
ollie lho -
Ronald G. Minnich -
Spirit -
Steve Gehlbach