-------- Original Message -------- Subject: Re: Linuxbios and Linspire laptop Date: Tue, 01 Jun 2004 10:10:43 -0500 From: Bari Ari bari@onelabs.com To: Jan Macek miernik@ctnet.pl CC: Richard Stallman rms@gnu.org References: E1BSJLs-0005OB-ON@fencepost.gnu.org 40B25E08.8030401@onelabs.com 20040601140614.GA945@jaworz.ctnet.pl
Jan Macek wrote:
What about the Linspire Mobile PC laptop? Is there really anything missing to got something working at all (proprietary-BIOS-free)? Let's say we don't care about power management, lid etc. We just want to be able to use GNU operating system without booting aby proprietary firmware. Is there anything _essenstial_ missing now, the board was said to be the same as VIA EPIA.
If it's the same as a supported Epia then the port is well on its way. Can you find out what they use for the keyboard controller?
You may have to care about power management, SystemBIOS reflashing and the lid etc. or those features may not work depending on how they did the hardware design. Like I have said before there is really no standard for this. Hardware guys like myself typically use whatever I/O pins are left over to solve these issues and then make it work with firmware attached to the keyboard BIOS.
I'd really like to pick a laptop with a chipset with plenty of life left like the new Intel 9xx series due out very shortly.
http://slashdot.org/articles/04/05/31/2211233.shtml?tid=137&tid=152&...
http://www.anandtech.com/showdoc.html?i=2064&p=5
Send us an Intel chipset laptop with a Renesas super I/O and we have a winner!
I set up a page with some information about LinuxBIOS, and links to some of your posts. Please take a look if I got it right and what might I add: http://www.miernik.ctnet.pl/linuxbios/
Looks good so far!
Regards,
Bari Ari
* Bari Ari bari@onelabs.com [040601 17:12]:
You may have to care about power management, SystemBIOS reflashing and the lid etc. or those features may not work depending on how they did the hardware design. Like I have said before there is really no standard for this.
Power management and lid close detection is a matter of someone implementing the needed ACPI tables for that. ACPI support is basically implemented in LinuxBIOS but each system type needs it's specific set of tables for ACPI to do any good.
Stefan
Stefan Reinauer wrote:
- Bari Ari bari@onelabs.com [040601 17:12]:
You may have to care about power management, SystemBIOS reflashing and the lid etc. or those features may not work depending on how they did the hardware design. Like I have said before there is really no standard for this.
Power management and lid close detection is a matter of someone implementing the needed ACPI tables for that. ACPI support is basically implemented in LinuxBIOS but each system type needs it's specific set of tables for ACPI to do any good.
That's if they got ACPI right in their hardware design. Laptop hardware designers use the keyboard micro to solve lots of issues since these micros have lots of GPIO pins along with timers and other function blocks that are easily programmed.
-Bari
* Bari Ari bari@onelabs.com [040601 17:30]:
That's if they got ACPI right in their hardware design. Laptop hardware designers use the keyboard micro to solve lots of issues since these micros have lots of GPIO pins along with timers and other function blocks that are easily programmed.
ACPI does not change the fact that you have to trigger some GPIOs to get things to work. It just moves the description of these GPIOs to the firmware rather than having the OS implement them new for each mainboard(!)
While LinuxBIOS' goal is to let Linux do it, I guarantee that either these ACPI tables are put in LinuxBIOS or the features won't be available in Linux for the next decade or so.
Stefan
Stefan Reinauer wrote:
While LinuxBIOS' goal is to let Linux do it, I guarantee that either these ACPI tables are put in LinuxBIOS or the features won't be available in Linux for the next decade or so.
The offer still stands:
I'd really like to pick a laptop with a chipset with plenty of life left like the new Intel 9xx series due out very shortly.
http://slashdot.org/articles/04/05/31/2211233.shtml?tid=137&tid=152&...
http://www.anandtech.com/showdoc.html?i=2064&p=5
Send us an Intel chipset laptop with a Renesas super I/O and we have a winner (for a LinuxBIOS laptop)!
-Bari
word from someone who knows that acpi tables have many errors. Windows drivers work around the bugs in acpi tables. Linux follows the spec closely, hence the problems people see with linux+acpi.
ron
* ron minnich rminnich@lanl.gov [040601 22:50]:
word from someone who knows that acpi tables have many errors. Windows drivers work around the bugs in acpi tables. Linux follows the spec closely, hence the problems people see with linux+acpi.
Ron,
you are perfectly right with the fact that ACPI tables are very often buggy. But this strengthens the case against (some) commercial bios writers rather than against ACPI as a concept. Still it is a sound argument that the complexity of something that could be really simple drives bios writers to include these bugs.
Yet, there's often the case of ACPI tables working around bugs in Windows' ACPI implementation which can cause problems on Linux. Another one of the most stupid things I've ever seen is that ACPI can have different code paths for different OSes. Thus, of course ACPI writers go the usual way: "Works with Windows, we can ship it." I have seen quite a couple boards that were able to cope fine with Linux ACPI after Linux has been told to pass the Windows ID string to the ACPI code.
One thing that is generally good about ACPI (well in some sense) is that it is free of callbacks, which I often hear as a disadvantage of Open Firmware's interface. (While dropping callbacks in OF is just a matter of directly providing the FCode drivers to the OS and let a hosted Open Source OF implementation use it there)
Stefan
On Wed, 2 Jun 2004, Stefan Reinauer wrote:
One thing that is generally good about ACPI (well in some sense) is that it is free of callbacks, which I often hear as a disadvantage of Open Firmware's interface. (While dropping callbacks in OF is just a matter of directly providing the FCode drivers to the OS and let a hosted Open Source OF implementation use it there)
What would be neat is to decompile an ACPI table from binary, and ship that in the linuxbios image. THen you get most flexibility.
Or am I nuts?
ron
One thing that is generally good about ACPI (well in some sense) is that it is free of callbacks, which I often hear as a disadvantage of Open Firmware's interface. (While dropping callbacks in OF is just a matter of directly providing the FCode drivers to the OS and let a hosted Open Source OF implementation use it there)
What would be neat is to decompile an ACPI table from binary, and ship that in the linuxbios image. THen you get most flexibility.
FWIW, this shows how to move your ACPI's DSDT table from bios to linux kernel, perhaps potentially elimitnating need for it in linuxbios altogether.
ron minnich rminnich@lanl.gov writes:
On Wed, 2 Jun 2004, Stefan Reinauer wrote:
One thing that is generally good about ACPI (well in some sense) is that it is free of callbacks, which I often hear as a disadvantage of Open Firmware's interface. (While dropping callbacks in OF is just a matter of directly providing the FCode drivers to the OS and let a hosted Open Source OF implementation use it there)
What would be neat is to decompile an ACPI table from binary, and ship that in the linuxbios image. THen you get most flexibility.
Or am I nuts?
We need to be careful of copyright consideration there. But otherwise it looks like a possible idea.
Eric
lindows/linspire never got back to me re a laptop port.
no interest at their end.
ron
ron minnich wrote:
lindows/linspire never got back to me re a laptop port.
no interest at their end.
The Linspire laptop http://www.sub300.com/port.htm pretty much an Epia with a keyboard controller. Not very glamorous but if it has a Renesas keyboard super I/O controller I might be interested and getting it up under LinuxBIOS.
-Bari
Bari Ari bari@onelabs.com wrote:
The Linspire laptop http://www.sub300.com/port.htm pretty much an Epia with a keyboard controller.
BTW: Is it an EPIA or EPIA-M ?
Not very glamorous but if it has a Renesas keyboard super I/O controller I might be interested and getting it up under LinuxBIOS.
Can someone who has the Linspire laptop, and is willing to open the case voiding the warranty, could check what is the keyboard controller?
Bari, how do you recognize the keyboard controller chip? Are there any example images?
Miernik wrote:
Bari Ari bari@onelabs.com wrote:
The Linspire laptop http://www.sub300.com/port.htm pretty much an Epia with a keyboard controller.
BTW: Is it an EPIA or EPIA-M ?
I really have no idea. That's what someone else had posted.
Not very glamorous but if it has a Renesas keyboard super I/O controller I might be interested and getting it up under LinuxBIOS.
Can someone who has the Linspire laptop, and is willing to open the case voiding the warranty, could check what is the keyboard controller?
Bari, how do you recognize the keyboard controller chip? Are there any example images?
They just look like another chip. You have to check the part numbers to find out.
-Bari
-
Adam Sulmicki -
Bari Ari -
ebiederman＠lnxi.com -
Miernik -
ron minnich -
Stefan Reinauer