[LinuxBIOS] Support for Intel G965 GMCH Chipset?

[Chris Ziomkowski]

I am investigating options for an embedded systems project which we need 
to launch Q1 next year.

I found linuxbios and love the idea. I have a few concerns though, and I 
thought someone here might be able to help me decide how difficult it 
might be to go this route.

First, all of the mainboards that I can find which fit our requirements 
use the Intel G965 GMCH chipset. (Requirements are mini ITX format, 
Intel Core 2 Duo desktop processor support, not socket 478, and dual 
Gbit LAN. I've only found 3 products after a week of searching. ) 
Chipset docs are available at 
http://www.intel.com/support/graphics/intelg965/

The G965 is not listed as supported, and I've been unable to find any 
comforting comments in the list archives. I am an accomplished embedded 
systems programmer, but my time is stretched very thin on this project.  
Do  you guys believe I will be able to make this work without heroic 
efforts?

Second, the mainboards all come with an 8 Mbit BIOS flash. Will this be 
enough to boot Linux directly? There is no IDE capability on these 
boards, so the only disk options are USB or SATA. I don't need video 
support. There will only be a serial console.

Assuming I can boot direct to Linux from the BIOS, would SATA or USB be 
more appropriate for loading the rest of the system?

Any comments would be appreciated. Am I getting in over my head?  Do you 
think linuxbios is stable enough to consider for a commercial product?

Thanks,

Chris

[Peter Stuge]

On Sun, Oct 29, 2006 at 05:41:17PM +0700, Chris Ziomkowski wrote:
> The G965 is not listed as supported, and I've been unable to find
> any comforting comments in the list archives. I am an accomplished
> embedded systems programmer, but my time is stretched very thin on
> this project. Do you guys believe I will be able to make this work
> without heroic efforts?

I guess it depends on whether you can get the chipset up fast enough.
It's a 400 page datasheet, some would definately say that
implementing code for that in very short time is heroic, but you may
be more used to it, and manage well. :)
> Second, the mainboards all come with an 8 Mbit BIOS flash. Will this
> be enough to boot Linux directly?

Likely yes, but it depends on how many things you must have compiled
into the initial kernel. Try compiling a kernel as you like it and
look at the size of arch/i386/boot/bzImage, or use LZMA to compress
vmlinux. It should be max 1Mb-32kb. You may want to investigate
linux-tiny as well.
> boards, so the only disk options are USB or SATA. I don't need
> video support. There will only be a serial console.

Good, you save the space for the VGA BIOS in the flash then, and
don't neccessarily have to implement support for the graphics stuff
in the 965.
> Assuming I can boot direct to Linux from the BIOS, would SATA or
> USB be more appropriate for loading the rest of the system?

I think SATA would be faster, simply because USB means at least one
more layer of code between physical disk and filesystem driver.
> Any comments would be appreciated. Am I getting in over my head?

Hard to say, it depends on your skill really. But it IS a tight
timeline.
> Do you think linuxbios is stable enough to consider for a
> commercial product?

I think LinuxBIOS is more stable than any commercial BIOS, and that's
just one of it's advantages. :)

//Peter

[Stefan Reinauer]

* Peter Stuge  [061029 15:44]:
> > Do you think linuxbios is stable enough to consider for a
> > commercial product?
>
> I think LinuxBIOS is more stable than any commercial BIOS, and that's
> just one of it's advantages. :)

I would even say 99.99% of all LinuxBIOS systems are in use in
commercial applications. Maybe even more.

[ron minnich]

Here is what I am told by commercial companies, building products, who need
to use LinuxBIOS: If you have a credible business case for LinuxBIOS on
Intel systems, Intel will help you with LinuxBIOS. This was also covered at
a talk at the LinuxBIOS summit last year. I am told that Intel continues to
be helpful to individual companies, having a credible business case, who
contact them for help on LinuxBIOS ports. The help does not extend to
programming support, just provision of documents. When it comes to coding,
you are on your own.

Thus, if you are a serious commerical customer with an opporuntity that is
measured in a reasonable number of units (and Intel has been helpful in
sales as small as 2000 units), then I think you should contact your Intel
rep, tell them what you want to do, and ask for help in the form of
documents and sample code; also, make it clear that the code you produce
will be GPL and released to the world, as it will be part of LinuxBIOS. Be
honest with them; do not try to be tricky.

Based on what a couple of companies have told me, I think Intel might help
out. Intel has not directly helped the LinuxBIOS community for over 4 years
now, in fact quite the opposite, but evidently they do occasionally help
companies.

I would be interested in hearing how it goes for you if you contact Intel.
If anyone has experiences to report we would be interested in hearing them
here. Of course, AMD continues to be the gold standard for LinuxBIOS
support, as you can see from their slides at the LinuxBIOS meeting last
month (on the web site); and the fact that one of our most prominent
contributors is an AMD employee!

As for commercial %: LinuxBIOS usage is so close to 100% commercial use,
that the other uses (including the thousands of machines here at LANL) do
not even count any more; we're lost in the noise. At one point, LANL was
100% of the worldwide  installed base of LinuxBIOS. Now we don't even count
-- we're way too small.

thanks

ron

[Richard Smith]

Chris Ziomkowski wrote:
> Any comments would be appreciated. Am I getting in over my head?  Do you 
> think linuxbios is stable enough to consider for a commercial product?

Stability is a matter of reference.  On chipsets/mainboards that have a 
bit of time under their belt they are very stable.  Usually once it 
works it just works.  That said there can be some pain associated with 
older revs and a newer toolchain.  Its caused us some trouble in the past.

However, porting to a new chipset is a whole new game.  There are many 
open end issues with respect to a short fixed timeline.  The key is the 
documentation.  If you can't get the right level of _correct_ 
documentation then you could spend months chasing bugs that reduce to 
"set this bit, in this hidden register."  Things like that just destroy 
a timeline and don't show well up the management chain.

I don't want to stop you from trying an Intel port since we get requests 
for newer Intel chips all the time, BUT what you are looking at is a 
pretty tall order.  You need to sit down with whatever vendor you have 
that reps Intel and have a long talk with them about getting the 
required docs with clear deliverables on their part.  I recommend you 
have them list the document names and numbers that they will provide.

A specific question would be to ask them if you can get example code 
that enables the RAM for that chipset.  And make sure you get a copy 
(and read) all errata notes.

[Uwe Hermann]

Hi,

On Tue, Oct 31, 2006 at 11:20:36AM -0600, Richard Smith wrote:
> I don't want to stop you from trying an Intel port since we get requests 
> for newer Intel chips all the time, BUT what you are looking at is a 
> pretty tall order.  You need to sit down with whatever vendor you have 
> that reps Intel and have a long talk with them about getting the 
> required docs with clear deliverables on their part.  I recommend you 
> have them list the document names and numbers that they will provide.
>
> A specific question would be to ask them if you can get example code 
> that enables the RAM for that chipset.  And make sure you get a copy 
> (and read) all errata notes.

The datasheet and errata are here:
http://www.intel.com/design/chipsets/datashts/313053.htm
http://www.intel.com/design/chipsets/specupdt/313054.htm

Is it common that you need more documentation than that for Intel
chipsets? Are they usually missing important bits?

I might try to look at the 845GE/PE soon, so I'm curious...

As for the example code - I'm not sure whether it's a good idea to get
code from them (even worse, under NDA), as that would probably "taint"
any contributed (GPL'd) code we might later include into LinuxBIOS.
The Intel lawyers could always argue that we illegally distributed/modified
their code or whatever...

Uwe.

[ron minnich]

On 10/31/06, Uwe Hermann  wrote:
> Is it common that you need more documentation than that for Intel
> chipsets? Are they usually missing important bits?

Those public docs, once so helpful, are now mostly useless. The important
content is not there.
> As for the example code - I'm not sure whether it's a good idea to get
> code from them (even worse, under NDA), as that would probably "taint"
> any contributed (GPL'd) code we might later include into LinuxBIOS.
> The Intel lawyers could always argue that we illegally
> distributed/modified
> their code or whatever...

This is why I tell people, 'Don't get tricky'. Tell Intel from the beginning
what you are doing, and that you intend to release code, and do it in
writing. make sure there is no confusion. Get permission.

Then there are no surprises or bad feelings at either end.

thanks

ron

[Richard Smith]

Chris Ziomkowski wrote:
> Second, the mainboards all come with an 8 Mbit BIOS flash. Will this be 
> enough to boot Linux directly? There is no IDE capability on these 
> boards, so the only disk options are USB or SATA. I don't need video 
> support. There will only be a serial console.

Missed this on the previous response.  Yes 8Mbit will work fine.  OLPC 
was doing exactly that and we lose 128KiB to binary blobs.

[ron minnich]

On 10/31/06, Richard Smith  wrote:
> Chris Ziomkowski wrote:
> > Second, the mainboards all come with an 8 Mbit BIOS flash. Will this be
> > enough to boot Linux directly? There is no IDE capability on these
> > boards, so the only disk options are USB or SATA. I don't need video
> > support. There will only be a serial console.
>
> Missed this on the previous response.  Yes 8Mbit will work fine.  OLPC
> was doing exactly that and we lose 128KiB to binary blobs.

I just shipped a K8 system (SUNW ultra40) to a user with a 1 MB flash -- in
which we put a full kernel, initrd, SATA drives, ext3, etc. etc. plus
busybox.

It's wonderful. Boots to ash in 10 seconds or less. And, unlke the
proprietary BIOS, it can boot with only one CPU installed.

ron