Hello ollie,
This is the corrected version. The one I sent before contained an error in the raminit.inc patch and wasn't sent to the list..
However, even without my patch I was getting the following error when I set DISABLE_INTERNAL_DEVICES=1 and try to make:
crt0.s:786: Error: Symbol write_lpc_register already defined.
As I discovered that was caused by the unneeded write_lpc_register label in the raminit.inc. Thus I modified my patch to remove that line and now everything works fine.
Tuesday, March 18, 2003, 5:15:03 AM, you wrote:
ol> 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.
ol> Search the keyword DISABLE_INTERNAL_DEVICE or something in the source. ol> Try writing different value (bit patterns) to the register 0x7c (not so ol> sure ??) in southbridge. It is undocumented.
It's quite funny to hear about undocumented SiS chipset features from a SiS person :)))
Anyway, thanks for the hint. That turned out to be a FAQ and the answer can even be found on linuxbios.org/faq :)
I thought that with that information it would be nice to have configuration options to enable and disable specific embedded devices, so I wrote a small patch to sis/630/raminit.inc. I hope this will help other people. Please find the patch file attached.
I tried the patch and it works. The board boots ok and the per-device disable options work as supposed to.
can we get a second sis 630 person to test this? Just for double check.
I don't have sis 630 any more :-(
ron
Hello Ronald,
Tuesday, March 18, 2003, 11:07:34 PM, you wrote:
RGM> can we get a second sis 630 person to test this? Just for double check.
I also created another two patches: 1. Adds an IDE_SPINUP_DELAY option (defaults to 2 seconds, just as it is now). Good for IDE DiskOnModule (flash) machines that do not need to wait for a flash to spin-up :) It also replaces the unmeaningful "This is a hard coded delay" message with "IDE Spin-Up Delay". 2. Adds a CUSTOM_GREETING option to allow replacing the standard "LinuxBIOS-{version}{extraversion} {build} {booting}" message with a custom greeting "{custom_greeting} {build} {booting}"
The patches are tested and work fine for me. Do you want me to send them in?
What I would also like to add is some meaningful message before that myriad of dots starts appearing (the kernel loading process I mean). It would be nice to say "Loading kernel:" and then start printing dots. However, I don't know what is the best place for that code. Any suggestions?
On Wed, 19 Mar 2003, Spirit wrote:
The patches are tested and work fine for me. Do you want me to send them in?
yes.
Ask Eric for the best place to print "load kernel:"
but it should be "Loading payload"
ron
Hello Ronald,
Wednesday, March 19, 2003, 2:18:54 AM, you wrote:
RGM> On Wed, 19 Mar 2003, Spirit wrote:
The patches are tested and work fine for me. Do you want me to send them in?
RGM> yes.
Ok. Find them attached.
On Wed, 2003-03-19 at 04:07, Ronald G. Minnich wrote:
can we get a second sis 630 person to test this? Just for double check.
I don't have sis 630 any more :-(
I don't have any more neither :~(. Adrew, can you test it ?
I don't have any more neither :~(. Adrew, can you test it ?
I guess this is me :). I'll try it and send the result back to the list. However, we should also think about other way to enable/disable devices without rebuilding LinuxBIOS. Is it possible to do it with cmos like normal bios?
-Andrew
On Wed, 19 Mar 2003, Andrew Ip wrote:
I guess this is me :). I'll try it and send the result back to the list. However, we should also think about other way to enable/disable devices without rebuilding LinuxBIOS. Is it possible to do it with cmos like normal bios?
There are actually two cases. The first case is that you never want some feature enable because of the motherboard design. The second is that you want some features enabled/disabled.
But I have only ever seen the first case in reality. Are there other cases?
ron
There are actually two cases. The first case is that you never want some feature enable because of the motherboard design. The second is that you want some features enabled/disabled.
There are 3 pci slots on m758/m787. If I want to use all 3 slots, I need to disable audio/modem. However, some applications might not want to disable audio. Even storing IRQ assignment is also very useful for debugging purpose. Storing boot option is useful, too. I'm just thinking flexablity here.
-Andrew
On Wed, 19 Mar 2003, Andrew Ip wrote:
There are 3 pci slots on m758/m787. If I want to use all 3 slots, I need to disable audio/modem. However, some applications might not want to disable audio. Even storing IRQ assignment is also very useful for debugging purpose. Storing boot option is useful, too. I'm just thinking flexablity here.
Eric set up a nice infrastructure for CMOS, and we have not yet used it. Sounds like we now have an application. I would like to have the LinuxBIOS code that uses the CMOS written in C, however. How late in the boot process can you enable/disable this hardware and have it work correctly?
ron
Eric set up a nice infrastructure for CMOS, and we have not yet used it. Sounds like we now have an application. I would like to have the LinuxBIOS code that uses the CMOS written in C, however. How late in the boot process can you enable/disable this hardware and have it work correctly?
For most cases, it probably needs to be done before PCI probing. Besides, should we follow normal bios layout, or should we have our own.
-Andrew
On Thu, 20 Mar 2003, Andrew Ip wrote:
For most cases, it probably needs to be done before PCI probing. Besides, should we follow normal bios layout, or should we have our own.
we should have our own, but follow the conventions established for, e.g., the supermicro boards.
ron
On Thu, 2003-03-20 at 00:12, Andrew Ip wrote:
Eric set up a nice infrastructure for CMOS, and we have not yet used it. Sounds like we now have an application. I would like to have the LinuxBIOS code that uses the CMOS written in C, however. How late in the boot process can you enable/disable this hardware and have it work correctly?
For most cases, it probably needs to be done before PCI probing. Besides, should we follow normal bios layout, or should we have our own.
The CMOS layout for normal BIOS differ form vendor to vendor (chipset/MB too ??). I think we should come up with our own standard.
On Thu, 2003-03-20 at 00:03, Ronald G. Minnich wrote:
On Wed, 19 Mar 2003, Andrew Ip wrote:
There are 3 pci slots on m758/m787. If I want to use all 3 slots, I need to disable audio/modem. However, some applications might not want to disable audio. Even storing IRQ assignment is also very useful for debugging purpose. Storing boot option is useful, too. I'm just thinking flexablity here.
Eric set up a nice infrastructure for CMOS, and we have not yet used it. Sounds like we now have an application. I would like to have the LinuxBIOS code that uses the CMOS written in C, however. How late in the boot process can you enable/disable this hardware and have it work correctly?
Before PCI enumeration.
Alexander,
It works!!! I have checked in. Thanks.
-Andrew
On Tue, Mar 18, 2003 at 11:00:43PM +0300, Alexander Amelkin wrote:
Hello ollie,
This is the corrected version. The one I sent before contained an error in the raminit.inc patch and wasn't sent to the list..
However, even without my patch I was getting the following error when I set DISABLE_INTERNAL_DEVICES=1 and try to make:
crt0.s:786: Error: Symbol write_lpc_register already defined.
As I discovered that was caused by the unneeded write_lpc_register label in the raminit.inc. Thus I modified my patch to remove that line and now everything works fine.
Hello Andrew,
Thursday, March 20, 2003, 4:50:29 PM, you wrote:
AI> Alexander, AI> It works!!! I have checked in. Thanks.
I knew it! :) You're welcome.
With best regards, Alexander mailto:spirit@reactor.ru