[LinuxBIOS] IT8718F support.

[Uwe Hermann]

Hi, here's some code for the IT8718F. Untested, but compiles.

Please also checkin my patch at
http://www.linuxbios.org/pipermail/linuxbios/2006-August/015412.html
I think that got overlooked (or is there a technical problem with it?).

Btw, is the code for the Super IOs supposed to initialize/enable _all_
supported devices or merely COM1/COM2 and the rest gets enabled
later on?


U "I read ITE datasheets when I'm bored" we.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org

[Richard Smith]

> Btw, is the code for the Super IOs supposed to initialize/enable _all_
> supported devices or merely COM1/COM2 and the rest gets enabled
> later on?

First it depends on the config file.  If the device is not enabled in
the config file then don't turn it on.  Com 1 being the exception..

Second depends if the kernel can turn it on or not.  In a lot of cases
if the kernel gets back an invalid read of the base address it assumes
the device is just not there or disabled for a reason.

Generally though for superIO stuff if the kernel can find it then it
can init it so just turning on the device so the base address shows up
should be enough.

-- 
Richard A. Smith

[Uwe Hermann]

Hi,

On Tue, Aug 29, 2006 at 11:57:48AM -0500, Richard Smith wrote:
> First it depends on the config file.  If the device is not enabled in
> the config file then don't turn it on.  Com 1 being the exception..

Hm, I currently just turn on every supported Super IO device (FDC, Com1,
Com2, PP, etc. etc.) in the ITE code.
Should I check for some variables/#defines in the code and only
conditionally enable them? If so, how do I do that?
Or shall I simply continue to enable everything as you state below?
> Generally though for superIO stuff if the kernel can find it then it
> can init it so just turning on the device so the base address shows up
> should be enough.

Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org

[Stefan Reinauer]

* Uwe Hermann <[e-mail]> [060830 14:41]:
> Hm, I currently just turn on every supported Super IO device (FDC, Com1,
> Com2, PP, etc. etc.) in the ITE code.
> Should I check for some variables/#defines in the code and only
> conditionally enable them?

Yes, please have a look at the other superio implementations. You want
to be able to switch off certain devices in the config file. Because
they're not wired on the board or because you want to disable them, etc.
> Or shall I simply continue to enable everything as you state below?

no, please make sure the drivers have their hooks so they can be
controlled via the mainboard config files. 

We need to get all components to have all their choices available in the
config files, or we will have to patch and patch and patch code for
every board we want to support. That is something I want to get away
from --> more modular concept.

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: [e-mail]  • http://www.coresystems.de/

[Bari Ari]

Uwe Hermann wrote:
> Hi, here's some code for the IT8718F. Untested, but compiles.

Are you working on the support for these devices by just using the data 
sheets and without hardware to test this? It's great if you are. It's a 
good starting point for someone else with hardware.

Bari

[Carl-Daniel Hailfinger]

Bari Ari wrote:
> Uwe Hermann wrote:
> > Hi, here's some code for the IT8718F. Untested, but compiles.
>
> Are you working on the support for these devices by just using the data 
> sheets and without hardware to test this? It's great if you are. It's a 
> good starting point for someone else with hardware.

Yes, he is. This has the potential to get quite a lot of people started
and getting any output at all is a major motivation factor even if the
rest of the code for bringup has yet to be written.

Can we build a ROM which does nothing but execute early serial code
for a given SuperIO, prints a few messages and then halts? So that if
somebody knows the SuperIO on his mainboard he can build a ROM testing
the code we have for it? Or does the early serial code also depend on
northbridge/southbridge/CPU?

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

[Stefan Reinauer]

* Carl-Daniel Hailfinger <[e-mail]> [060829 23:06]:
> Yes, he is. This has the potential to get quite a lot of people started
> and getting any output at all is a major motivation factor even if the
> rest of the code for bringup has yet to be written.

Definitely. Uwe, can you (or someone else) have a look what SuperIOs
boards usually use, so we can try to support an as large as possible 
set of boards theoretically. (thinking mainstream)

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: [e-mail]  • http://www.coresystems.de/

[Carl-Daniel Hailfinger]

Stefan Reinauer wrote:
> * Carl-Daniel Hailfinger <[e-mail]> [060829 23:06]:
> > Yes, he is. This has the potential to get quite a lot of people started
> > and getting any output at all is a major motivation factor even if the
> > rest of the code for bringup has yet to be written.
>
> Definitely. Uwe, can you (or someone else) have a look what SuperIOs
> boards usually use, so we can try to support an as large as possible 
> set of boards theoretically. (thinking mainstream)

The FSF has a campaign (http://www.fsf.org/campaigns/free-bios.html)
we could use for sampling which SuperIOs are used in commonly sold
boards. Their "how can you help" section could state prominently that
we need a list of boards with matching SuperIOs.

Suggested text follows:
"The LinuxBIOS project needs your help to make LinuxBIOS work on
your mainboard. A first important step is to know which SuperIO your
mainboard uses. This information can be obtained easily following
the directions on <some LinuxBIOS wiki page>. Once that is known,
you can download a matching experimental BIOS image and test the
code."

The LinuxBIOS wiki page could read as follows:
"How to find the SuperIO on your mainboard? There are two ways to
do it:
1. Find the chip on the board (usually a bigger chip with ITE, NSC,
   SMSC, VIA or Winbond written on it). See <photo> and <photo>
   for reference.
2. Find the chip with sensors-detect and look for something named
   SuperIO. See <sample output> for reference. Equipped with that
   information, you may also want to find out if that chip is really
   soldered on your board.
Please add this your findings to the wiki so others can verify
and profit from it.

<example board> <example superio> <link to bios image>
<example board> <example superio> <link to bios image>"


What do you think?

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

[Uwe Hermann]

Hi,

On Wed, Aug 30, 2006 at 12:11:14AM +0200, Carl-Daniel Hailfinger wrote:
> The FSF has a campaign (http://www.fsf.org/campaigns/free-bios.html)
> we could use for sampling which SuperIOs are used in commonly sold
> boards. Their "how can you help" section could state prominently that
> we need a list of boards with matching SuperIOs.
>
> Suggested text follows:
> "The LinuxBIOS project needs your help to make LinuxBIOS work on
> your mainboard. A first important step is to know which SuperIO your
> mainboard uses. This information can be obtained easily following
> the directions on <some LinuxBIOS wiki page>. Once that is known,
> you can download a matching experimental BIOS image and test the
> code."
>
> The LinuxBIOS wiki page could read as follows:
> "How to find the SuperIO on your mainboard? There are two ways to
> do it:
> 1. Find the chip on the board (usually a bigger chip with ITE, NSC,
>    SMSC, VIA or Winbond written on it). See <photo> and <photo>
>    for reference.
> 2. Find the chip with sensors-detect and look for something named
>    SuperIO. See <sample output> for reference. Equipped with that
>    information, you may also want to find out if that chip is really
>    soldered on your board.
> Please add this your findings to the wiki so others can verify
> and profit from it.
>
> <example board> <example superio> <link to bios image>
> <example board> <example superio> <link to bios image>"
>
> What do you think?

Asking for help in the FSF campaign is definately a good idea, as it
reaches quite a lot of people, I guess.

I'm not sure whether a list of Super IOs is all that useful, though. We can
simply support all of them (a coordinated effort shouldn't take more
than a few weeks to support almost all Super IOs you can get a datasheet
for).

I'm sure there are other areas where the project needs lots more help;
Someone who is more involved with the project than I am should
probably create a list of such areas.

IMHO these things are quite important:

 1) publicity among non-coders to make the project well-known, and to
    make the fact known that there's a viable, working Free Software
    alternative to proprietary BIOSes.

 2) Get as many coders as possible involved. Create incentive to try
    LinuxBIOS, which will result in active contributions in many
    cases. It's crucial to have support for a wide range of hardware,
    as only that will really ensure a wide-spread use of LinuxBIOS
    (I'm especially thinking about desktop machines here).

 3) Create pressure on those companies which do not give out datasheets
    for various hardware parts. This is much easier if 1) is successful
    and many people/customers demand LinuxBIOS support.


HTH, Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org

[Stefan Reinauer]

* Uwe Hermann <[e-mail]> [060830 14:37]:
> I'm not sure whether a list of Super IOs is all that useful, though. We can
> simply support all of them (a coordinated effort shouldn't take more
> than a few weeks to support almost all Super IOs you can get a datasheet
> for).

Supporting all of them for the sake of it makes no sense, by your leave.
SuperIO chips alone dont do the deed.  if we manage to get a
"coordinated effort", i'd much rather go and support "80% of the common
superio chips out there" with in the end 50% of the effort and instead
try to get some more southbridge/northbridge combinations supported with
this effort. On K8 we lack Via and ATI chipset support, for Via we lack
C7 support,... all that stuff will give us a user base. 100% superio
chips alone wont, given that in 2 months we're at 98% of the existing
superios again, and in 2 ys below 50%.
> 1) publicity among non-coders to make the project well-known, and to
>     make the fact known that there's a viable, working Free Software
>     alternative to proprietary BIOSes.

I completely agree. The key to success here is, in my opinion, to
provide ready-built and tested images on an automated base for certain
hardware. Also, we need to work on the configuration part to move more
mainboard specifics (irq routing, complete hw tree) in the config file.
A mainboard from all supported components should not need any code to be
touched. only configuration files. Well, maybe we go with an exception
of a little GPIO triggering here and there i f this can not be
automated, but other than that: no new code for _motherboards_
> 2) Get as many coders as possible involved. Create incentive to try
>     LinuxBIOS, which will result in active contributions in many
>     cases. It's crucial to have support for a wide range of hardware,
>     as only that will really ensure a wide-spread use of LinuxBIOS
>     (I'm especially thinking about desktop machines here).

Unlike normal userspace programs or even kernels, recovering from a bad
bios can be quite some work. How do we overcome this? Not everyone is
going to buy a galep iv for 400$, nor a bios savior for 30.
> 3) Create pressure on those companies which do not give out datasheets
>     for various hardware parts. This is much easier if 1) is successful
>     and many people/customers demand LinuxBIOS support.

what do you mean by pressure?
 
  Stefan



-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: [e-mail]  • http://www.coresystems.de/

[Carl-Daniel Hailfinger]

Stefan Reinauer wrote:
> * Uwe Hermann <[e-mail]> [060830 14:37]:
> > 2) Get as many coders as possible involved. Create incentive to try
> >     LinuxBIOS, which will result in active contributions in many
> >     cases. It's crucial to have support for a wide range of hardware,
> >     as only that will really ensure a wide-spread use of LinuxBIOS
> >     (I'm especially thinking about desktop machines here).
>
> Unlike normal userspace programs or even kernels, recovering from a bad
> bios can be quite some work. How do we overcome this? Not everyone is
> going to buy a galep iv for 400$, nor a bios savior for 30.

In Germany you can get cheap flash chips at http://www.bios-chip.de/ .
SST 49LF008A (8 Mbit FWH) only costs 8.50 Eur, which is really affordable.
With such a chip, there is no need for a BIOS saviour. And 8 Mbit is
enough even if you want to fit a complete kernel in ROM.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

[Uwe Hermann]

On Wed, Aug 30, 2006 at 05:28:40PM +0200, Carl-Daniel Hailfinger wrote:
> In Germany you can get cheap flash chips at http://www.bios-chip.de/ .

Yep. Or from Conrad (www.conrad.de) or other electronics vendors, I
guess. I also ripped some off of old and broken motherboards (e.g. from
flea markets etc.).


Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org

[Stefan Reinauer]

* Carl-Daniel Hailfinger <[e-mail]> [060830 17:28]:
> In Germany you can get cheap flash chips at http://www.bios-chip.de/ .
> SST 49LF008A (8 Mbit FWH) only costs 8.50 Eur, which is really affordable.
> With such a chip, there is no need for a BIOS saviour. And 8 Mbit is
> enough even if you want to fit a complete kernel in ROM.

I know, I did chip hotswapping for several years now. 

While I think it is a great opportunity to be a cheap date, you do risk
messing up the hardware physically if you swap very often. 

And this is exactly the thing that keeps people from "playing around"
with LinuxBIOS as they do with other software projects...

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: [e-mail]  • http://www.coresystems.de/

[LinuxBIOS] flashrom, uniflash.

[Uwe Hermann]

Hi,

On Wed, Aug 30, 2006 at 07:54:55PM +0200, Stefan Reinauer wrote:
> While I think it is a great opportunity to be a cheap date, you do risk
> messing up the hardware physically if you swap very often.
>
> And this is exactly the thing that keeps people from "playing around"
> with LinuxBIOS as they do with other software projects...

Yes, sure it's a bit more risky to play with important hardware parts;
that's why I think we need to support lots of older boards, chips, etc.
which people are willing to play with and/or can easily and cheaply get
from flea markets, ebay etc.

Another important issue is that flashrom should support many, many chips
and baords, as few people will be willing to buy expensive hardware just
for flashing.

There's Uniflash, but that has the problem of being Pascal+DOS,
currently. I tried for a few minutes to build it with GNU Pascal or
FreePascal, but that didn't work easily (needs more work, maybe).
Has anybody else managed to build it for Linux?


Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org

[LinuxBIOS] flashrom, uniflash.

[Stefan Reinauer]

* Uwe Hermann <[e-mail]> [060831 23:55]:
> Another important issue is that flashrom should support many, many chips
> and baords, as few people will be willing to buy expensive hardware just
> for flashing.
> There's Uniflash, but that has the problem of being Pascal+DOS,
> currently. I tried for a few minutes to build it with GNU Pascal or
> FreePascal, but that didn't work easily (needs more work, maybe).
> Has anybody else managed to build it for Linux?

Uniflash works so well because it does 16bit bios calls itself. I am not
sure we want to do this. Maybe we do? Maybe with x86emu? Ollie? Ron?

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: [e-mail]  • http://www.coresystems.de/

[LinuxBIOS] flashrom, uniflash.

[Carl-Daniel Hailfinger]

Stefan Reinauer wrote:
> * Uwe Hermann <[e-mail]> [060831 23:55]:
> > Another important issue is that flashrom should support many, many chips
> > and baords, as few people will be willing to buy expensive hardware just
> > for flashing.
> > There's Uniflash, but that has the problem of being Pascal+DOS,
> > currently. I tried for a few minutes to build it with GNU Pascal or
> > FreePascal, but that didn't work easily (needs more work, maybe).
> > Has anybody else managed to build it for Linux?
>
> Uniflash works so well because it does 16bit bios calls itself. I am not
> sure we want to do this. Maybe we do? Maybe with x86emu? Ollie? Ron?

Most PC BIOSes have a flash program in ROM, so x86emu won't help us
much. The 16bit BIOS calls are just calls to that flash program.
I know for sure that all recent Asus boards have awdflash or similar
in their ROM image.

Regards,
Carl-Daniel

[LinuxBIOS] flashrom, uniflash.

[Stefan Reinauer]

* Carl-Daniel Hailfinger <[e-mail]> [060901 02:07]:
> Most PC BIOSes have a flash program in ROM, so x86emu won't help us
> much. The 16bit BIOS calls are just calls to that flash program.

Except Asus:

Not really a flash program but functions to enable / disable write
protection of the bios chips and address spaces. There's an AWDFLASH
structure that points into this. I reverse engineered this many years
ago until I found out that I want to support hardware that is supported
by its vendor.
> I know for sure that all recent Asus boards have awdflash or similar
> in their ROM image.

Thats definitely not what the user land bios flashers like uniflash use.
it seems they want to get rid of bios updates while the os is running
completely. Not dumb, really.


Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: [e-mail]  • http://www.coresystems.de/

[LinuxBIOS] flashrom, uniflash.

[Stefan Reinauer]

* Uwe Hermann <[e-mail]> [060831 23:55]:
> Another important issue is that flashrom should support many, many chips
> and baords, as few people will be willing to buy expensive hardware just
> for flashing.
>
> There's Uniflash, but that has the problem of being Pascal+DOS,
> currently. I tried for a few minutes to build it with GNU Pascal or
> FreePascal, but that didn't work easily (needs more work, maybe).
> Has anybody else managed to build it for Linux?

And then there's /dev/bios. It supports quite a lot of hardware 
and it talks to the hardware in a smarter way than most flash drivers 
in "flashrom". This is why I still get regular mails for the driver.

But it should be all integrated in flashrom, its architecture is a lot
more sane. (And it does not need to recompile the software for every
kernel update :-/)

Stefan


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: [e-mail]  • http://www.coresystems.de/

[LinuxBIOS] flashrom, uniflash.

[Carl-Daniel Hailfinger]

Stefan Reinauer wrote:
> And then there's /dev/bios. It supports quite a lot of hardware 
> and it talks to the hardware in a smarter way than most flash drivers 
> in "flashrom". This is why I still get regular mails for the driver.
>
> But it should be all integrated in flashrom, its architecture is a lot
> more sane.

Oh. I had assumed flashrom was the successor of /dev/bios and other
flashing tools. Porting the code from /dev/bios to flashrom will
probably be a lot easier than trying to find out what uniflash does.

Stefan, do you have any plans in that direction?

Regards,
Carl-Daniel

[Uwe Hermann]

On Wed, Aug 30, 2006 at 05:10:15PM +0200, Stefan Reinauer wrote:
> Supporting all of them for the sake of it makes no sense, by your leave.
> SuperIO chips alone dont do the deed.  if we manage to get a
> "coordinated effort", i'd much rather go and support "80% of the common
> superio chips out there" with in the end 50% of the effort and instead
> try to get some more southbridge/northbridge combinations supported with
> this effort.

Sure, that's important as well. But Super IOs are (comparatively) easy to
understand and support, and the amount of code needed is small, so we
can add support for many of them quite fast...
> I completely agree. The key to success here is, in my opinion, to
> provide ready-built and tested images on an automated base for certain
> hardware.

I fully agree.
> Unlike normal userspace programs or even kernels, recovering from a bad
> bios can be quite some work. How do we overcome this? Not everyone is
> going to buy a galep iv for 400$, nor a bios savior for 30.

Here's what I did:

I created a backup BIOS image of the BIOS on my test machine; then I got a
few chips of the same size/type. I wrote the original image to 1-2 of the chips
(all with Uniflash), so I had 3 identical, working proprietary BIOS
chips (just in case) and put them in a drawer. Of course, I tested them all.

So from now on I can easily just write/overwrite all other chips, because I
always have a few backup chips I can use if something goes wrong.

Mabye a "How to recover" section in the wiki would be nice...
> > 3) Create pressure on those companies which do not give out datasheets
> >     for various hardware parts. This is much easier if 1) is successful
> >     and many people/customers demand LinuxBIOS support.
>
> what do you mean by pressure?

Peaceful, non-violent pressure, of course ;-)

The "damn, today there were another 14 customers calling our help-desk
and asking for LinuxBIOS support, maybe we should give out specs, after
all"-type of pressure.


Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org

[Stefan Reinauer]

* Uwe Hermann <[e-mail]> [060901 00:24]:
> > what do you mean by pressure?
>
> Peaceful, non-violent pressure, of course ;-)
>
> The "damn, today there were another 14 customers calling our help-desk
> and asking for LinuxBIOS support, maybe we should give out specs, after
> all"-type of pressure.

Usually if you come with a big enough number, they will open the specs.
> From what I experienced, 100 boards might not be enough for some of
> them, 1000 boards probably is.

Maybe this is an area where the FSF could help to gain momentum?
I got some pretty good contacts to some of the companies meanwhile, but
most of our customers think 1000 boards is a whole lot.

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: [e-mail]  • http://www.coresystems.de/

[Ward Vandewege]

On Wed, Aug 30, 2006 at 02:37:59PM +0200, Uwe Hermann wrote:
> Asking for help in the FSF campaign is definately a good idea, as it
> reaches quite a lot of people, I guess.

We're happy to help. Updating the campaign page is no problem; just let us
know what you'd like to see there.

Thanks,
Ward.

-- 
Ward Vandewege <[e-mail]>
Free Software Foundation - Senior System Administrator

[Carl-Daniel Hailfinger]

Ward Vandewege wrote:
> On Wed, Aug 30, 2006 at 02:37:59PM +0200, Uwe Hermann wrote:
> > Asking for help in the FSF campaign is definately a good idea, as it
> > reaches quite a lot of people, I guess.
>
> We're happy to help. Updating the campaign page is no problem; just let us
> know what you'd like to see there.

I'm working on an updated text. Once it is finished (and has reached
consensus here), I'll tell you about it.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

[LinuxBIOS] LinuxBIOS on Laptops.

[Uwe Hermann]

HI,

On Thu, Aug 31, 2006 at 04:33:11PM +0200, Carl-Daniel Hailfinger wrote:
> I'm working on an updated text. Once it is finished (and has reached
> consensus here), I'll tell you about it.

Another very interesting issue is laptop support. I know about
http://linuxbios.org/index.php/Laptop_survey but more information is
surely helpful.


Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org

[LinuxBIOS] LinuxBIOS on Laptops.

[Carl-Daniel Hailfinger]

Uwe Hermann wrote:
> On Thu, Aug 31, 2006 at 04:33:11PM +0200, Carl-Daniel Hailfinger wrote:
> > I'm working on an updated text. Once it is finished (and has reached
> > consensus here), I'll tell you about it.
>
> Another very interesting issue is laptop support. I know about
> http://linuxbios.org/index.php/Laptop_survey but more information is
> surely helpful.

I'd say we postpone laptop support until we have LinuxBIOS running on
a few cheap mainboards because laptops present additional problems:
* usually the flash chip is not socketed
* video bios is tightly integrated
* superios are different from what we know
* most of the time, embedded controllers have to be initialized as
  well if you don't want to kill the hardware
* wrong video initialization has the potential to kill the display

Stories about LinuxBIOS frying laptops are the worst we can get now,
but if we are successful enough in the traditional PC market, maybe
one laptop vendor will get interested, too. And with support from
a manufacturer, porting is a lot easier.


Regards,
Carl-Daniel

[LinuxBIOS] LinuxBIOS on Laptops.

[Kevin Purcell]

(not a troll)

What would be the selling point to the laptop maker of using LinuxBIOS?

Why would they want LinuxBIOS rather than buying (and modifying) a  
solution from a commercial BIOS company and their CPU/chipset(s)  
suppliers?

If you can answer this question in a way that would convince an MBA  
you might be able to persuade a maker to do this. If you can't give  
an argument that saves the company money I doubt you will get any  
traction.

As regards the "let's get it on cheaper motherboards" I agree entirely.

On Sep 2, 2006, at 12:16 PM, Carl-Daniel Hailfinger wrote:
> Stories about LinuxBIOS frying laptops are the worst we can get now,
> but if we are successful enough in the traditional PC market, maybe
> one laptop vendor will get interested, too. And with support from
> a manufacturer, porting is a lot easier.
> --
> Kevin Purcell
> [e-mail]

[LinuxBIOS] LinuxBIOS on Laptops.

[Stefan Reinauer]

* Kevin Purcell <[e-mail]> [060902 22:05]:
> If you can answer this question in a way that would convince an MBA  
> you might be able to persuade a maker to do this. If you can't give  
> an argument that saves the company money I doubt you will get any  
> traction.

This is easy: It makes costs more reliable as you have fixed one time
development costs and no per motherboards license fee. In addition it 
is a lot cheaper that its competitors, if you look out there.

The fact that it is a technical superior product is of no interest to
some MBAs so I do not mention this seperately in detail here ;-)

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: [e-mail]  • http://www.coresystems.de/

[LinuxBIOS] LinuxBIOS on Laptops.

[Rogelio Serrano]

On 9/3/06, Kevin Purcell <[e-mail]> wrote:
> (not a troll)
>
> What would be the selling point to the laptop maker of using LinuxBIOS?
>
> Why would they want LinuxBIOS rather than buying (and modifying) a
> solution from a commercial BIOS company and their CPU/chipset(s)
> suppliers?

many things that go beyond the bios. you cant make an argument with
the bios alone. you have to show what an open bios would bring and
actually link that to higher sales. for example if it allows
ubiquitous computing where you would rather use your laptop instead of
pen and paper then that would be convincing. instant accessibility is
a very big thing now. imagine getting a phone call and your super
compact laptop is off. you turn it on then wait for it to bootup. then
you login and wait a little more. then you look for that text editor.
then when you find it you double click on it. then you start typing
notes on it then you need to look at contacts then you need to lookup
your to do list. you would rather have a common low cost paper based
organizer. now if your pc can bootup in 3 seconds that changes a whole
lot of things. with software suspend you can have almost instant
access to your apps. you can leave your whole office suite "running"
all the time without killing your batteries. or burning your lap. now
thats a convincing argument.

-- 
the thing i like with my linux pc is that i can sum up my complaints in 5 items

[LinuxBIOS] LinuxBIOS on Laptops.

[Uwe Hermann]

Hi,

On Sat, Sep 02, 2006 at 09:16:37PM +0200, Carl-Daniel Hailfinger wrote:
> I'd say we postpone laptop support until we have LinuxBIOS running on

Yeah, that's probably a good idea (for the FSF campaign text).
> a few cheap mainboards because laptops present additional problems:
> * usually the flash chip is not socketed

Most probably, yes. Luckily I do have a working test-laptop which has
the chip in a socket... More details in my other post...
> * video bios is tightly integrated
> * superios are different from what we know

Do you have more details? As far as I can see at least some seem to be
very similar to non-laptop superios. If there's a datasheet it shouldn't
be too hard to support them.
> * most of the time, embedded controllers have to be initialized as
>   well if you don't want to kill the hardware
> * wrong video initialization has the potential to kill the display

Hm, that doesn't sound good. Which controllers in particular can become
problem?
> Stories about LinuxBIOS frying laptops are the worst we can get now,

ACK.


Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org

[LinuxBIOS] LinuxBIOS on Laptops.

[yhlu]

Arima has one Laptop with Nvidia CK804 chipset. That should be more
easier, and I hope Arima could work it out to make it support
LinuxBIOS.

YH



On 9/2/06, Uwe Hermann <[e-mail]> wrote:
> Hi,
>
> On Sat, Sep 02, 2006 at 09:16:37PM +0200, Carl-Daniel Hailfinger wrote:
> > I'd say we postpone laptop support until we have LinuxBIOS running on
>
> Yeah, that's probably a good idea (for the FSF campaign text).
> > a few cheap mainboards because laptops present additional problems:
> > * usually the flash chip is not socketed
>
> Most probably, yes. Luckily I do have a working test-laptop which has
> the chip in a socket... More details in my other post...
> > * video bios is tightly integrated
> > * superios are different from what we know
>
> Do you have more details? As far as I can see at least some seem to be
> very similar to non-laptop superios. If there's a datasheet it shouldn't
> be too hard to support them.
> > * most of the time, embedded controllers have to be initialized as
> >   well if you don't want to kill the hardware
> > * wrong video initialization has the potential to kill the display
>
> Hm, that doesn't sound good. Which controllers in particular can become
> problem?
> > Stories about LinuxBIOS frying laptops are the worst we can get now,
>
> ACK.
>
> Uwe.
> --
> Uwe Hermann
> http://www.hermann-uwe.de
> http://www.it-services-uh.de  | http://www.crazy-hacks.org
> http://www.holsham-traders.de | http://www.unmaintained-free-software.org
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
>
> iD8DBQFE+holXdVoV3jWIbQRArT1AJ9Z+BuLxfSqz1UsJ1Uh6vgQeJsxBQCfQVUH
> xUcmYdBUYxjTjeFIQRLwboE=
> =H1LG
> -----END PGP SIGNATURE-----

[LinuxBIOS] LinuxBIOS on Laptops.

[Bari Ari]

Uwe Hermann wrote:
> > * video bios is tightly integrated
> > * superios are different from what we know
>
> Do you have more details? As far as I can see at least some seem to be
> very similar to non-laptop superios. If there's a datasheet it shouldn't
> be too hard to support them.
> > * most of the time, embedded controllers have to be initialized as
> >   well if you don't want to kill the hardware
> > * wrong video initialization has the potential to kill the display
>
> Hm, that doesn't sound good. Which controllers in particular can become
> problem?

The Keyboard Scan/ Power Management Controllers are the non-standard 
parts of laptops.

Laptops use microcontrollers that do combined operations such as 
keyboard scan, Flash write enable, battery management, power management, 
lid open/close, power buttons etc.

These are the areas that we would need documentation for.

The chipset docs may all be available but not docs to the power 
management/keyboard scan controller firmware. The docs for the micros 
describe the general purpose micro itself, but that won't tell you how 
they are using all of its gpio pins and ports.

Bari

[LinuxBIOS] LinuxBIOS on Laptops.

[Ronald G Minnich]

Carl-Daniel Hailfinger wrote:
> I'd say we postpone laptop support until we have LinuxBIOS running on
> a few cheap mainboards because laptops present additional problems:

Carl-Daniel, as you well know, the laptop mass market came first with 
OLPC :-)

all we need to do is get quanta to well OLPC with adult-size keyboards :-)

ron

[LinuxBIOS] LinuxBIOS on Laptops.

[Rogelio Serrano]

On 9/4/06, Ronald G Minnich <[e-mail]> wrote:
> Carl-Daniel Hailfinger wrote:
> > I'd say we postpone laptop support until we have LinuxBIOS running on
> > a few cheap mainboards because laptops present additional problems:
>
> Carl-Daniel, as you well know, the laptop mass market came first with
> OLPC :-)
>
> all we need to do is get quanta to well OLPC with adult-size keyboards :-)

of course. that would be great!

-- 
the thing i like with my linux pc is that i can sum up my complaints in 5 items

[Uwe Hermann]

Hi,

On Tue, Aug 29, 2006 at 11:31:23PM +0200, Stefan Reinauer wrote:
> * Carl-Daniel Hailfinger <[e-mail]> [060829 23:06]:
> > Yes, he is. This has the potential to get quite a lot of people started
> > and getting any output at all is a major motivation factor even if the
> > rest of the code for bringup has yet to be written.

That's a great idea! I figure it should be possible to create a
repository of some sort which contains such ROM images.
That eliminates the need to understand the build process and compile
stuff, which will lower the entry bar for a few people and might get
them interested in the project.
> Definitely. Uwe, can you (or someone else) have a look what SuperIOs
> boards usually use, so we can try to support an as large as possible 
> set of boards theoretically. (thinking mainstream)

Yes, that shouldn't be a problem for recent boards. We can just scan all
major online computer stores for board names and then get the datasheets
of the vendors; or simply visit the websites of the 10 biggest vendors
or so and simply get _all_ their datasheets. Then we can do some
statistics etc.

As for the Super IOs I'd use another approach; simply download all
datasheets you can get your hands on and add support for the respective
part (which is what I'm doing with the ITEs; when Im done I'll probably
continue with Winbond).


Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org

[Stefan Reinauer]

* Uwe Hermann <[e-mail]> [060830 14:24]:
> Hi,
>
> On Tue, Aug 29, 2006 at 11:31:23PM +0200, Stefan Reinauer wrote:
> > * Carl-Daniel Hailfinger <[e-mail]> [060829 23:06]:
> > > Yes, he is. This has the potential to get quite a lot of people started
> > > and getting any output at all is a major motivation factor even if the
> > > rest of the code for bringup has yet to be written.
>
> That's a great idea! I figure it should be possible to create a
> repository of some sort which contains such ROM images.
> That eliminates the need to understand the build process and compile
> stuff, which will lower the entry bar for a few people and might get
> them interested in the project.

ok, lets think this further: You get a LinuxBIOS-string on serial and
then you do _what_ with that image? Have a shell? Torsten Duwe's serial
loader or llshell might be candidates here.
> As for the Super IOs I'd use another approach; simply download all
> datasheets you can get your hands on and add support for the respective
> part (which is what I'm doing with the ITEs; when Im done I'll probably
> continue with Winbond).

After my last mail, thinking about it,... how many vendors are we
talking about here,..? and how many chips per vendor? 
It might indeed be a pretty good idea to exhaust the space just to get
some ground. SuperIOs age less than southbridges, do they?

Stefan


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: [e-mail]  • http://www.coresystems.de/

[Carl-Daniel Hailfinger]

Stefan Reinauer wrote:
> * Uwe Hermann <[e-mail]> [060830 14:24]:
> > Hi,
> >
> > On Tue, Aug 29, 2006 at 11:31:23PM +0200, Stefan Reinauer wrote:
> > > * Carl-Daniel Hailfinger <[e-mail]> [060829 23:06]:
> > > > Yes, he is. This has the potential to get quite a lot of people started
> > > > and getting any output at all is a major motivation factor even if the
> > > > rest of the code for bringup has yet to be written.
> > > > That's a great idea! I figure it should be possible to create a
> > > > repository of some sort which contains such ROM images.
> > > > That eliminates the need to understand the build process and compile
> > > > stuff, which will lower the entry bar for a few people and might get
> > > > them interested in the project.
>
> ok, lets think this further: You get a LinuxBIOS-string on serial and
> then you do _what_ with that image? Have a shell? Torsten Duwe's serial
> loader or llshell might be candidates here.

Both won't help if RAM and CAR don't work yet.
But the string alone should give us an idea the specific mainboard needs
additional setup before it can speak to the SuperIO or not.
> > As for the Super IOs I'd use another approach; simply download all
> > datasheets you can get your hands on and add support for the respective
> > part (which is what I'm doing with the ITEs; when Im done I'll probably
> > continue with Winbond).
>
> After my last mail, thinking about it,... how many vendors are we
> talking about here,..? and how many chips per vendor? 
> It might indeed be a pretty good idea to exhaust the space just to get
> some ground. SuperIOs age less than southbridges, do they?

We face various constraints here:
* People are less likely to perform experiments with their newest machines
* Supporting Intel will be a headache
* flashrom should work on the systems we are targeting to eliminate the
  need for an EEPROM programmer
* Some boards are shipped without serial port
* we don't care which boards are/were best-sellers, we only care which
  boards we can find enough testers for

Considering these constraints, I suggest the following plan:
* Call for action via FSF, point to <website with further instructions>
* provide linuxbios-check .rpm/.deb/.tar.gz/ebuild with the following
  (half-)automated tests:
  - flashrom to find out on which boards we can flash the BIOS easily
  - sensors-detect for SuperIO detection
  - lspci -vvv
  - dmidecode
  - dmesg (or /var/log/boot.msg)
  - ask user whether he has a serial port onboard
  - ask user which parts of lspci are add-on cards
  - ask user for exact mainboard name
  - ask user for model of flash chip
  - ask user for SuperIO
  - upload results to <special address which feeds database>
  - if SuperIO or mainboard is known, offer ROM image for download
* once we have a reasonable overview of people willing to test and
  their respective boards, we can decide which boards to attack first
* after we have support for the first mass-marketed board, make sure
  to spread the word (and make people with unsupported boards envious)

Once I find some time, I'll implement the plan.

What do you think?

Regards,
Carl-Daniel

[Stefan Reinauer]

* Carl-Daniel Hailfinger <[e-mail]> [060830 18:17]:
> > ok, lets think this further: You get a LinuxBIOS-string on serial and
> > then you do _what_ with that image? Have a shell? Torsten Duwe's serial
> > loader or llshell might be candidates here.
>
> Both won't help if RAM and CAR don't work yet.
> But the string alone should give us an idea the specific mainboard needs
> additional setup before it can speak to the SuperIO or not.

llshell was known to work all within registers, so it needs no ram.
the serial boot was at least partly written using romcc iirc.
> We face various constraints here:
> * People are less likely to perform experiments with their newest machines

While we only care for exactly those because of the costs and time 
involved in supporting a system
> * flashrom should work on the systems we are targeting to eliminate the
>   need for an EEPROM programmer

This works on quite some systems that do not require special GPIO
sequences.
> * Some boards are shipped without serial port

which reminds me.. we purchased a net20dc usb debug device, but I 
did not get to write example code for any side of the debug connection.
I hope to find an opportunity after my current project. Or maybe one
of the USB adept experts in here can jump in?
> * we don't care which boards are/were best-sellers, we only care which
>   boards we can find enough testers for

Not all the way down. The boards that are supported in LinuxBIOS usually
are supported because there was a use case for one of the contributors
to do so. See the OLPC, or the machines that were supported because LANL
built clusters with that hardware.
> Considering these constraints, I suggest the following plan:
> * Call for action via FSF, point to <website with further instructions>

BTW, will someone from the FSF join the LinuxBIOS symposium 2006? I am
still missing FSF names on the list!
> * provide linuxbios-check .rpm/.deb/.tar.gz/ebuild with the following
>   (half-)automated tests:
>   - flashrom to find out on which boards we can flash the BIOS easily
>   - sensors-detect for SuperIO detection
>   - lspci -vvv
>   - dmidecode
>   - dmesg (or /var/log/boot.msg)
>   - ask user whether he has a serial port onboard
>   - ask user which parts of lspci are add-on cards
>   - ask user for exact mainboard name
>   - ask user for model of flash chip
>   - ask user for SuperIO
>   - upload results to <special address which feeds database>
>   - if SuperIO or mainboard is known, offer ROM image for download

can you set something up for this? I can create a database on
linuxbios.org and also create a repository to check in the code and
optimize it.

The SuperIO can also be auto detected. I think I saw the code for this
somewhere.
> * after we have support for the first mass-marketed board, make sure
>   to spread the word (and make people with unsupported boards envious)

there is plenty of support for "mass-marketed boards" already, or do I
get you wrong? Epia is among them. All the Tyan boards..
> Once I find some time, I'll implement the plan.

Let me know when you do so, we can probably coordinate.

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: [e-mail]  • http://www.coresystems.de/

[Carl-Daniel Hailfinger]

Stefan Reinauer wrote:
> * Carl-Daniel Hailfinger <[e-mail]> [060830 18:17]:
> there is plenty of support for "mass-marketed boards" already, or do I
> get you wrong? Epia is among them. All the Tyan boards..

Ah sorry, wrong wording. "Sold in masses to Linux users" would have
described it better. That unfortunately excludes both Tyan and Via Epia.
> > Once I find some time, I'll implement the plan.
>
> Let me know when you do so, we can probably coordinate.

Will do so.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

[Carl-Daniel Hailfinger]

Stefan Reinauer wrote:
> * Carl-Daniel Hailfinger <[e-mail]> [060830 18:17]:
> > We face various constraints here:
> > * People are less likely to perform experiments with their newest machines
>
> While we only care for exactly those because of the costs and time 
> involved in supporting a system

That's the question. Do we want to continue supporting highly expensive
boards like Tyan where hardly anyone will sacrifice a system to LinuxBIOS
testing or do we want to reach the masses. For the masses, anything less
than *perfect* support for the machine they use daily is unacceptable.
And we will probably not reach good support of a board until long after
the board is out of production, bringing us back to square one.
Just look at how many people use binary-only drivers to get a bit more
performance on their machines for daily use even if free drivers exist.

I'm for supporting slightly outdated systems (like AMD Socket 754/939)
and against putting any effort into the latest and greatest.
> > * flashrom should work on the systems we are targeting to eliminate the
> >   need for an EEPROM programmer
> > * provide linuxbios-check .rpm/.deb/.tar.gz/ebuild with the following
> >   (half-)automated tests:
> >   - sensors-detect for SuperIO detection
>
> The SuperIO can also be auto detected. I think I saw the code for this
> somewhere.

You mean, a different method than probing SMBus?

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

[Uwe Hermann]

On Thu, Aug 31, 2006 at 01:51:23AM +0200, Carl-Daniel Hailfinger wrote:
> That's the question. Do we want to continue supporting highly expensive
> boards like Tyan where hardly anyone will sacrifice a system to LinuxBIOS
> testing or do we want to reach the masses.

Ideally, both. I guess the corporate contributors will continue to
(mainly) support boards they have use-cases for (which makes sense from an
economical point of view).

For cheap, old, or mainstream boards you can buy in your favorite
computer shop, ebay etc. random interested contributors/coders are
important, IMHO. Given enough such contributors and enough popularity of
the project among hacker-type Free Software users/programmers it won't
take too long to have support for a good bunch of popular boards.
> I'm for supporting slightly outdated systems (like AMD Socket 754/939)
> and against putting any effort into the latest and greatest.

ACK. Although I don't think putting effort into "the latest and greatest"
is a problem, it's just that the older stuff should be worked on, too.


Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org

[Stefan Reinauer]

* Uwe Hermann <[e-mail]> [060901 00:11]:
> Ideally, both. I guess the corporate contributors will continue to
> (mainly) support boards they have use-cases for (which makes sense from an
> economical point of view).
>
> For cheap, old, or mainstream boards you can buy in your favorite
> computer shop, ebay etc. random interested contributors/coders are
> important, IMHO. Given enough such contributors and enough popularity of
> the project among hacker-type Free Software users/programmers it won't
> take too long to have support for a good bunch of popular boards.

time is playing with us. The north and south bridges that are expensive,
fast and modern today will be old and cheap tomorrow, so when K8 et al 
see a successor, we might automatically our potential userbase might
automatically become broader. 

Notice that at the moment on K8 all server chipsets are supported but
none of the consumer chipsets (Via, ATI, some NVidia hw).
> ACK. Although I don't think putting effort into "the latest and greatest"
> is a problem, it's just that the older stuff should be worked on, too.

In the old Amiga games scene there is a concept called abandonware. 
If the technology does not make a "unique selling point" for the vendor
anymore, it is released to the public for the sake of the community.

Is this a concept that hw vendors on this list could life with?
 

Regards,
Stefan


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: [phone] • Fax: [phone]
Email: [e-mail]  • http://www.coresystems.de/

[Uwe Hermann]

Hi,

On Tue, Aug 29, 2006 at 12:46:51PM -0500, Bari Ari wrote:
> Are you working on the support for these devices by just using the data 
> sheets and without hardware to test this?

Yes, exactly. I decided to just add support for _all_ ITE Super IOs for
which I'm able to find datasheets.


Uwe.
-- 
Uwe Hermann 
http://www.hermann-uwe.de
http://www.it-services-uh.de  | http://www.crazy-hacks.org 
http://www.holsham-traders.de | http://www.unmaintained-free-software.org