Re: IT8718F support.

* Uwe Hermann <uwe <at> hermann-uwe.de> [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

Re: flashrom, uniflash.

* Uwe Hermann <uwe <at> hermann-uwe.de> [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.: +49 761 7668825 • Fax: +49 761 7664613
Email: info <at> coresystems.de  • http://www.coresystems.de/

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios

Re: License clarification, round 1

Hi,

On Tue, Aug 29, 2006 at 06:33:31PM +0200, Stefan Reinauer wrote:
> The answer here is easy. Every line of LinuxBIOS code is GPL. And 
> every line of code we will include in the future will become GPL by the
> implicit agreement of the contributor to use LinuxBIOS and to enhance
> it. 

I agree, _if_ the code is contributed willingly and knowingly by the
third-party, _and_ that fact is documented in the file (by adding a
copyright line and the GPL license header).

It's an entirely different situation if the code was taken from some
other project, in which case it's not necessarily GPL'd.

 
> This is why we have been doing code reviews and have been in close
> contact with the contributors to make sure we do not include otherwise
> licensed or protected code.

That's great to hear!

 
> All of them are GPLed, as a consequence of the inclusion in LinuxBIOS.
> Also, files do not need a header stating their license, as the license
> is absolutely obvious to everyone downloading the code.

Yes and no. The license of the project might be obvious, but I've come
over many GPL'd projects which are not actually 100% GPL'd even if they
say so. Many contained files from some other sources which were copied in

Re: flashrom, uniflash.

* Uwe Hermann <uwe <at> hermann-uwe.de> [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.: +49 761 7668825 • Fax: +49 761 7664613
Email: info <at> coresystems.de  • http://www.coresystems.de/

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios

Re: IT8718F support.

* Uwe Hermann <uwe <at> hermann-uwe.de> [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.: +49 761 7668825 • Fax: +49 761 7664613
Email: info <at> coresystems.de  • http://www.coresystems.de/

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios

Re: flashrom, uniflash.

Stefan Reinauer wrote:
> * Uwe Hermann <uwe <at> hermann-uwe.de> [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 mailing list
linuxbios <at> linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios

Re: flashrom, uniflash.

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

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios

Re: flashrom, uniflash.

* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 <at> gmx.net> [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.: +49 761 7668825 • Fax: +49 761 7664613
Email: info <at> coresystems.de  • http://www.coresystems.de/

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios

PATCH: flashrom support for all ICH chipsets.

Hi,

I've added support in flashrom for all ICH chipsets (maybe I missed one
or two; if so, please tell me).

Tested on real hardware: ICH2, ICH6-M (the rest is untested).

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

Index: util/flashrom/flash_enable.c
===================================================================
--- util/flashrom/flash_enable.c	(Revision 2394)
+++ util/flashrom/flash_enable.c	(Arbeitskopie)
@@ -3,6 +3,7 @@
  *
  *   Copyright (C) 2000-2004 ???
  *   Copyright (C) 2005 coresystems GmbH <stepan <at> openbios.org>
+ *   Copyright (C) 2006 Uwe Hermann <uwe <at> hermann-uwe.de>
  *
  *   This program is free software; you can redistribute it and/or
  *   modify it under the terms of the GNU General Public License
@@ -101,20 +102,16 @@
 	return 0;
 }

Re: Geode GX1/5530: How to forward SMI to a regular IRQ

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios