Hi all
I contacted Intel via the form on their pages asking them to support FSF and the free bios project.
I received an elusive response that I'm forwarding you.
Does it open a channel for communication or you already know about this project they talk about?
Is there a vendor that showed some interest in the free bios project?
Is there something I could do to push vendors to help?
Thanks for all your wonderful work!
Keep on fighting.
You have no hope of influencing a large company through channels like this one. You are talking with a low-level person who has no authority to change anything, and whose job is only to try to convince you to accept what Intel is doing.
What you got is therefore only the statement Intel uses to justify not cooperating with us.
It could be that the Coreboot developers can find statements which are misleading or false, and publish an article which would put pressure on Intel.
Some of the points are simply distractions or illogical. For instance:
BIOS is a part of the reliability and performance promise of the hardware.
Is that true? If so, so what? That is no reason not to let us run our own BIOS.
Chipset specifications at the level being discussed are commonly considered proprietary by all silicon vendors, not just Intel.
In other words, "Everyone spits on your freedom". Even if it were true, so what?
However, it is false: some computer models do work with free BIOS. Intel compares badly with them. This is one of the statements that maybe could be criticized in a published response.
The open source firmware work that Intel *is* sponsoring could lead to a solution where proprietary low-level chipset initialization code from silicon vendors is made compatible with open source higher-level platform initialization and pre-boot management.
As they say, this is not a complete free BIOS, just part of one.
If the "proprietary low-level chipset initialization code" is in ROM on the chips that it initializes, then it is tolerable. (It might as well be circuits on that chip.) Otherwise, it is insufficient unless made complete.
On Thu, 01 May 2008 06:11:14 -0400, Richard M Stallman rms@gnu.org wrote:
You have no hope of influencing a large company through channels like this one. You are talking with a low-level person who has no authority to change anything, and whose job is only to try to convince you to accept what Intel is doing.
What you got is therefore only the statement Intel uses to justify not cooperating with us.
It could be that the Coreboot developers can find statements which are misleading or false, and publish an article which would put pressure on Intel.
Some of the points are simply distractions or illogical. For instance:
BIOS is a part of the reliability and performance promise of the hardware.Is that true? If so, so what? That is no reason not to let us run our own BIOS.
Chipset specifications at the level being discussed are commonly considered proprietary by all silicon vendors, not just Intel.In other words, "Everyone spits on your freedom". Even if it were true, so what?
However, it is false: some computer models do work with free BIOS. Intel compares badly with them. This is one of the statements that maybe could be criticized in a published response.
The open source firmware work that Intel *is* sponsoring could lead to a solution where proprietary low-level chipset initialization code from silicon vendors is made compatible with open source higher-level platform initialization and pre-boot management.As they say, this is not a complete free BIOS, just part of one.
If the "proprietary low-level chipset initialization code" is in ROM on the chips that it initializes, then it is tolerable. (It might as well be circuits on that chip.) Otherwise, it is insufficient unless made complete.
I couldn't agree with you more Richard, but on the other hand it is nice to think someday Intel will wake up and realize the world is changing around them :-)
On Thu, May 1, 2008 at 5:23 AM, Joe joe@settoplinux.org wrote:
I couldn't agree with you more Richard, but on the other hand it is nice to think someday Intel will wake up and realize the world is changing around them :-)
that's a form letter that we have seen before. It's a "canned response". So, they have thought enough about the issue to have a standard corporately-approved position letter all ready to go when folks ask this question. And, we all know it's baloney.
What I find amusing about their "third party BIOS" comment is that *every* BIOS is a third party BIOS, and many if not all of them are based on reverse engineering done years ago. The least of the worries was chipset specs; the chipset specs were mostly open.
Ah well. They're either going to win, and BIOSes will remain proprietary; or, we'll win, and the x86 BIOS world will be as open as the ARM, MIPS, PPC, and others are. One thing I've noticed -- no matter how long the odds may seem, it's always a mistake to bet against free/open source. So far, every time Intel has worked against free and open source, they've lost -- and they've tried many times in the last 30 years.
ron
On Thu, 1 May 2008 08:12:52 -0700, "ron minnich" rminnich@gmail.com wrote:
On Thu, May 1, 2008 at 5:23 AM, Joe joe@settoplinux.org wrote:
I couldn't agree with you more Richard, but on the other hand it is
nice to
think someday Intel will wake up and realize the world is changing
around
them :-)
that's a form letter that we have seen before. It's a "canned response". So, they have thought enough about the issue to have a standard corporately-approved position letter all ready to go when folks ask this question. And, we all know it's baloney.
I thought I had seen that one before. They sent me that when I contacted them about their Intel ACSF bios (Applied Computing System Firmware Library).
What I find amusing about their "third party BIOS" comment is that *every* BIOS is a third party BIOS, and many if not all of them are based on reverse engineering done years ago. The least of the worries was chipset specs; the chipset specs were mostly open.
Ah well. They're either going to win, and BIOSes will remain proprietary; or, we'll win, and the x86 BIOS world will be as open as the ARM, MIPS, PPC, and others are. One thing I've noticed -- no matter how long the odds may seem, it's always a mistake to bet against free/open source. So far, every time Intel has worked against free and open source, they've lost -- and they've tried many times in the last 30 years.
I think our only hope of getting Intel involved with coreboot, is through the guys at http://www.linuxfirmwarekit.org
On Thu, May 1, 2008 at 8:44 AM, Joe joe@settoplinux.org wrote:
I think our only hope of getting Intel involved with coreboot, is through the guys at http://www.linuxfirmwarekit.org
excellent idea.
There are lots of people at intel (they talk to me from time to time) who want to see intel and coreboot work together.
ron
2008/5/1 ron minnich rminnich@gmail.com:
On Thu, May 1, 2008 at 8:44 AM, Joe joe@settoplinux.org wrote:
I think our only hope of getting Intel involved with coreboot, is through the guys at http://www.linuxfirmwarekit.org
excellent idea.
There are lots of people at intel (they talk to me from time to time) who want to see intel and coreboot work together.
Can't believe. Intel spends a lot of efforts to promote their own EFI - why they will to help their competitors?
On Thu, May 1, 2008 at 9:09 AM, Peter Lemenkov lemenkov@gmail.com wrote:
Can't believe. Intel spends a lot of efforts to promote their own EFI
- why they will to help their competitors?
intel is not a monolith. It's too big for that.
And not everyone at Intel likes EFI.
ron
Peter Lemenkov wrote:
2008/5/1 ron minnich rminnich@gmail.com:
On Thu, May 1, 2008 at 8:44 AM, Joe joe@settoplinux.org wrote:
I think our only hope of getting Intel involved with coreboot, is through the guys at http://www.linuxfirmwarekit.org
excellent idea.
There are lots of people at intel (they talk to me from time to time) who want to see intel and coreboot work together.
Can't believe. Intel spends a lot of efforts to promote their own EFI
- why they will to help their competitors?
Maybe for the same reasons IBM and SUN are doing Linux, despite the fact that they had their own OSes.
Am Thu, 01 May 2008 18:14:14 +0200 schrieb Stefan Reinauer stepan@coresystems.de:
Maybe for the same reasons IBM and SUN are doing Linux, despite the fact that they had their own OSes.
still have, both of them.. (and both of them happily give you linux, but propose "the real thing" for "real deployments")
Regards, Patrick
Maybe for the same reasons IBM and SUN are doing Linux, despite the fact that they had their own OSes.
What they are doing is the GNU/Linux system, not Linux by itself.
See http://www.gnu.org/gnu/gnu-linux-faq.html for more explanation.
Richard M Stallman wrote:
Maybe for the same reasons IBM and SUN are doing Linux, despite the fact that they had their own OSes.What they are doing is the GNU/Linux system, not Linux by itself.
See http://www.gnu.org/gnu/gnu-linux-faq.html for more explanation.
Thanks for lecturing me, Richard. I think your opinion on this is widely known. I hope you got the point anyways.
Thanks for lecturing me, Richard. I think your opinion on this is widely known. I hope you got the point anyways.
The facts about the system are widely misreported. Most people who have heard of the GNU/Linux system have never heard it called anything but "Linux", and this leads them to suppose it was started by Linus Torvalds.
I know that denying the GNU Project credit for its work was not the main intention of your message. It was just something you did on the side. It still isn't right.
Can't believe. Intel spends a lot of efforts to promote their own EFI - why they will to help their competitors?
The technical difference between traditional BIOS and EFI is not crucial for the ethics. What matters ethically is whether the program, as used, is free. If an EFI implementation works with 100% free software, except for subroutines in rom on the chips that they initialize, it would be just as good as any other implementation of a BIOS.
What I find amusing about their "third party BIOS" comment is that *every* BIOS is a third party BIOS, and many if not all of them are based on reverse engineering done years ago. The least of the worries was chipset specs; the chipset specs were mostly open.
Would you like me to refer a friendly journalist your way?
Hi Richard,
I normally do not reply to threads started by someone (arc@gnu.org) who is unwilling to state his/her real name and announces that he has blacklisted the e-mail address of the founder of coreboot.
Then again, this reply is directed to you, Richard, because you made some very good points and I wish to supply you with quotable statements to justify a free firmware/BIOS.
On 01.05.2008 12:11, Richard M Stallman wrote:
It could be that the Coreboot developers can find statements which are misleading or false, and publish an article which would put pressure on Intel.
Some of the points are simply distractions or illogical. For instance:
BIOS is a part of the reliability and performance promise of the hardware.Is that true? If so, so what? That is no reason not to let us run our own BIOS.
Yes, it is true. The BIOS is responsible to fix up (work around) all the soft-fixable bugs in the hardware so the OS won't see them. Initialization of the various buses and memory has to be done correctly and in an efficient way. Setting up things the wrong way or without efficiency/performance considerations has serious effects on benchmarks and reliablity.
However, that's exactly the reason why we MUST have a free/open BIOS/firmware. - It allows us to get the best possible performance. AMD has stated that the coreboot Hypertransport setup is the most efficient one available. (I can probably dig up who made that statement.) - We get the ablity to fix hardware bugs even at times when the vendor doesn't care anymore (and that happens faster than most people like). - We also can add new features for old mainboards as long as the hardware can do it. The IDE LBA48 hard drive support in proprietary BIOS versions was one such example. Vendors simply didn't care about older boards and didn't release BIOS updates which could have added LBA48 support for IDE hard drives with sizes over 127 GB (a pure software thing) and people were forced to upgrade to newer boards. With coreboot, people would have recompiled a new BIOS version for their board, using the generic LBA48 support without any problems.
If the "proprietary low-level chipset initialization code" is in ROM on the chips that it initializes, then it is tolerable. (It might as well be circuits on that chip.) Otherwise, it is insufficient unless made complete.
None of the current mainstream x86 board manufacturers uses real ROMs anymore. There are simply too many bugs in the hardware and firmware to be able to afford a no-upgrade solution. Besides that, EEPROMs are very cheap nowadays and the firmware for the board and the separate firmware for the onboard NIC can be stored in the same EEPROM which saves board space.
Regards, Carl-Daniel
> If the "proprietary low-level chipset initialization code" is in ROM > on the chips that it initializes, then it is tolerable. (It might as > well be circuits on that chip.) Otherwise, it is insufficient unless > made complete. >
None of the current mainstream x86 board manufacturers uses real ROMs anymore.
We may be partly miscommunicating, talking about different questions. I'm talking about where we should draw the line of what's acceptable. What is done in any particular product is a different question. Both questions are important, but they are different.
If memory is physically writable, but is never updated once users get the product, that is more or less equivalent to ROM in my view. Thus, an EEPROM in a chip (or in a device) that contains the code to initialize the chip (or device) is tolerable if people treat it as a ROM.
ISTR that it was necessary for free BIOSes to run some initialization code for the video card which is stored on the video card. Is that correct? Is this still necessary? If so, it is an example of what I am talking about.
On 02.05.2008 23:13, Richard M Stallman wrote:
> If the "proprietary low-level chipset initialization code" is in ROM > on the chips that it initializes, then it is tolerable. (It might as > well be circuits on that chip.) Otherwise, it is insufficient unless > made complete. > None of the current mainstream x86 board manufacturers uses real ROMs anymore.We may be partly miscommunicating, talking about different questions. I'm talking about where we should draw the line of what's acceptable. What is done in any particular product is a different question. Both questions are important, but they are different.
Understood.
If memory is physically writable, but is never updated once users get the product, that is more or less equivalent to ROM in my view. Thus, an EEPROM in a chip (or in a device) that contains the code to initialize the chip (or device) is tolerable if people treat it as a ROM.
The x86 world is difficult. We have network cards where the firmware EEPROM is updatable, but the vendor will never offer an update. That would qualify as ROM in your definition. However, another network card with exactly the same chips and the same firmware, but a different model number, may get firmware updates from the vendor. That would _not_ qualify as ROM in your definition, at least as I understand it. The technical side of the ROM equivalence question does not allow for such distinctions.
It gets even worse once you look at CD/DVD burners and hard disks. Depending on the model number (not the product itself), a vendor may offer updates for such storage devices or not. CD/DVD burners very often offer firmware updates, but it is extremely uncommon for hard disk vendors to do that.
Firmware blobs which are loaded into devices, but where the blob never changes even for different versions of the driver, would be tolerable according to your definition (please correct me if I'm wrong).
ISTR that it was necessary for free BIOSes to run some initialization code for the video card which is stored on the video card. Is that correct?
Yes and no. It depends on the model of the video card.
Is this still necessary?
There is free/open source code which can initialize some graphics chipsets without having to run non-free code stored in the ROM of a video card. This depends a lot on vendor cooperation and since the code for each grapics card is different, you lose a lot of flexibility by avoiding the execution of on-card routines.
If so, it is an example of what I am talking about.
As I explained above, free software politics based on "ROM equivalence" in the firmware category do not make sense from a technical point of view. Please note that any laptop where the manufacturer refuses to provide BIOS updates would be tolerable according to you because "memory is physically writable, but is never updated once users get the product".
Regards, Carl-Daniel
Drawing an ethical line thru a gray area is generally not straightforward. Often it is not possible to find a unique best place to draw it, and sometimes we should treat certain areas as in-betweens.
However, another network card with exactly the same chips and the same firmware, but a different model number, may get firmware updates from the vendor. That would _not_ qualify as ROM in your definition, at least as I understand it. The technical side of the ROM equivalence question does not allow for such distinctions.
This is a gray area. I think we can treat it as barely acceptable if we do not install firmware upgrades. But only barely, so we should move to free firmware if possible.
Firmware blobs which are loaded into devices, but where the blob never changes even for different versions of the driver, would be tolerable according to your definition (please correct me if I'm wrong).
If "loaded into devices" means "loaded by your CPU from your disk", that is never acceptable, because (1) the non-free software is in your file system and (2) you (always) do install it into the device.
As I explained above, free software politics based on "ROM equivalence" in the firmware category do not make sense from a technical point of view.
I think it does make sense, when interpreted as described above.
Please note that any laptop where the manufacturer refuses to provide BIOS updates would be tolerable according to you because "memory is physically writable, but is never updated once users get the product".
Even if the manufacturer does offer BIOS updates, I think we can treat it as barely acceptable if we do not install them. But only barely, so we should move to free BIOS if possible.
Richard, at this point I think your just beating a dead horse. I think we all got the point and we should just move forward towards accomplishing our goals.
Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
----- Original Message ----- From: "Richard M Stallman" rms@gnu.org To: "Carl-Daniel Hailfinger" c-d.hailfinger.devel.2006@gmx.net Cc: arc@gnu.org; coreboot@coreboot.org Sent: Sunday, May 04, 2008 5:37 AM Subject: Re: [coreboot] [Fwd: Re: Contact Intel]
Drawing an ethical line thru a gray area is generally not straightforward. Often it is not possible to find a unique best place to draw it, and sometimes we should treat certain areas as in-betweens.
However, another network card with exactly the same chips and the same firmware, but a different model number, may get firmware updates from the vendor. That would _not_ qualify as ROM in your definition, at least as I understand it. The technical side of the ROM equivalence question does not allow for such distinctions.
This is a gray area. I think we can treat it as barely acceptable if we do not install firmware upgrades. But only barely, so we should move to free firmware if possible.
It isn't only software or firmware that's of concern. There should be no compromise: everything should be transparent and therefor auditable. (You doubt the importance of this for voting machines ?) See http://it.slashdot.org/article.pl?sid=08/05/01/1233244
(snip)
It isn't only software or firmware that's of concern. There should be no compromise: everything should be transparent and therefor auditable. (You doubt the importance of this for voting machines ?) See http://it.slashdot.org/article.pl?sid=08/05/01/1233244
Voting machines are a very special case because you cannot trust the election authority to run them honestly. Using free software in these machines is not sufficient.
I do not trust computers for voting. Ballots should be on paper so that a recount is possible.
Howdy, I don't think I am seeing the whole thread here, so I may be commenting back to the wrong person. I have run local elections several times as the presiding election judge. In Texas, that is what they call the person who runs the election at the precinct level. I also do not trust most of the electronic voting systems. There are some good auditable ones out there, and I keep talking about those whenever I can. There are real benefits to the electronic systems and as long as we can keep transparency and auditability, then I say they are a good thing. It is kind of like the BIOS to me. It is not that I don't trust Award or Phoenix, but I like to option of an open honest BIOS and I think it will keep the others a little more honest. I have been looking for a good motherboard to try coreboot on and I look forward to using it. And for something off-topic, I tried the gNewSense 2.0 on two systems this weekend and it failed to install where Ubuntu went on fine. I am trying to figure out what was missing so I can file a bug report. Good day, Ralph Green, Jr.
Richard M Stallman wrote:
It isn't only software or firmware that's of concern. There should be no compromise: everything should be transparent and therefor auditable. (You doubt the importance of this for voting machines ?) See http://it.slashdot.org/article.pl?sid=08/05/01/1233244Voting machines are a very special case because you cannot trust the election authority to run them honestly. Using free software in these machines is not sufficient.
I do not trust computers for voting. Ballots should be on paper so that a recount is possible.
You as an election judge may be honest, but not all of them are. At least one election in Mexico was stolen by computer manipulation by the central election commission. It appears that Bush stole the 2004 election through fiddling with the electro-optical vote counting machines. I've seen evidence that other elections in the US were stolen thru voting machine manipulation.
Whatever the technology, we cannot rely on the election authorities to be honest. So we must reject technology that forces us to rely on this.
----- Original Message ----- From: "Richard M Stallman" rms@gnu.org To: "Ralph Green" rgreen@zeomega.com Cc: coreboot@coreboot.org Sent: Monday, May 05, 2008 6:06 PM Subject: Re: [coreboot] [Fwd: Re: Contact Intel]
You as an election judge may be honest, but not all of them are. At least one election in Mexico was stolen by computer manipulation by the central election commission. It appears that Bush stole the 2004 election through fiddling with the electro-optical vote counting machines. I've seen evidence that other elections in the US were stolen thru voting machine manipulation.
Whatever the technology, we cannot rely on the election authorities to be honest. So we must reject technology that forces us to rely on this.
-- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
The point is: It is not enough that the software and the BIOS are free, the graphics, the motherboard, chips, and the entire package need to be free, open, and auditable. It is important for voting machines (http://www.seconnecticut.com/elections.htm), but even for personal use it is a concern.
The point is: It is not enough that the software and the BIOS are free, the graphics, the motherboard, chips, and the entire package need to be free, open, and auditable.
For elections, this is not sufficient, because how to you know the election authority didn't substitute a modified version of the free program for the actual election.
Would you like me to encourage a friendly journalist to contact you to write about Intel's refusal to cooperate?
On 07.05.2008 01:06, Richard M Stallman wrote:
Would you like me to encourage a friendly journalist to contact you to write about Intel's refusal to cooperate?
The preferred way would be to focus any article on praising the companies supporting coreboot. We had a detailed list somewhere, we could dig it up and mail it to you. Usually, shaming companies into contributing doesn't work, but giving the good ones lots of good publicity strengthens the positions of coreboot supporters in those companies. Besides that, while the tech media like to bash "evil" companies every so often, writing about cool gadgets with cool features is what lures readers to them.
I'd suggest we wait with contacting any journalist until we can offer all the information needed for an article in one neat package.
Regards, Carl-Daniel
On Tue, May 6, 2008 at 7:32 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net> wrote:
On 07.05.2008 01:06, Richard M Stallman wrote:
Would you like me to encourage a friendly journalist to contact you to
write about Intel's refusal to cooperate?
The preferred way would be to focus any article on praising the companies supporting coreboot. We had a detailed list somewhere, we could dig it up and mail it to you. Usually, shaming companies into contributing doesn't work, but giving the good ones lots of good publicity strengthens the positions of coreboot supporters in those companies.
Also, Intel could be doing a lot less to help us, and linux in general. Truncated datasheets are better then no datasheets.
-Corey
Corey Osgood wrote:
On Tue, May 6, 2008 at 7:32 PM, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net mailto:c-d.hailfinger.devel.2006@gmx.net> wrote:
On 07.05.2008 01:06, Richard M Stallman wrote: > Would you like me to encourage a friendly journalist to contact you to write about Intel's refusal to cooperate? > The preferred way would be to focus any article on praising the companies supporting coreboot. We had a detailed list somewhere, we could dig it up and mail it to you. Usually, shaming companies into contributing doesn't work, but giving the good ones lots of good publicity strengthens the positions of coreboot supporters in those companies.Also, Intel could be doing a lot less to help us, and linux in general. Truncated datasheets are better then no datasheets.
-Corey
I think we really should avoid the bashing at all. It is going to make a nice hype and some technocrates will probably buy their hardware from AMD instead of Intel, but this isn't changing the world. It isn't even showing up in serious numbers.
So here's a story. I removed all the names to keep it neutral.
I remember it suddenly got harder talking to a very friendly CPU vendor after they bought a graphics chip vendor, because one guy started running around with a halo, telling that people should not buy from that very graphics chip vendor, in a half-reflected way, similar to those my ancestor countrymen suggested not to buy from certain groups of people. Sorry, in my opinion this is absolutely the wrong direction. It just creates hate, and makes talking to people harder.
I know that Intel is watching coreboot very well, and they had themselves and their products inspired from us, feature-wise. Also, there are many people working for Intel that love free and open source software, and they think their corporate decisions toward certain areas of software, where intel is still closed should be improved. And they see very well that a bootloader that has 235MB checked out size, is not a suitable solution for many of their customers. I think what we need to do is get in contact with those people and convince them to help us, not pointing fingers at corporations. Us expecting corporations to be good or bad, doesn't work out. Corporations have no soul, so they will never be. _People_ can do good, though, and we need to find those that can help us and that we can convince that we are doing the right thing.
Stefan
I remember it suddenly got harder talking to a very friendly CPU vendor after they bought a graphics chip vendor, because one guy started running around with a halo, telling that people should not buy from that very graphics chip vendor, in a half-reflected way, similar to those my ancestor countrymen suggested not to buy from certain groups of people.
As far as I know, I am the only person who protested a graphics chip vendor, so this must be intended to refer to me. Which means it is inaccurate. Omitting my name doesn't make that ok.
Whether or not you agree with my approach, calling it "half-reflected" is sheer name-calling based on ignorance.
To equate boycotting a company with racism is worse than ignorance. It is absurd.
Come on Richard, enough is enough. No one is talking about racism here. You are taking this way too far. You have too much time on your hands. Can we just move on, please.
Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
-----Original Message----- From: coreboot-bounces+joe=settoplinux.org@coreboot.org [mailto:coreboot- bounces+joe=settoplinux.org@coreboot.org] On Behalf Of Richard M Stallman Sent: Thursday, May 08, 2008 4:44 AM To: Stefan Reinauer Cc: corey.osgood@gmail.com; c-d.hailfinger.devel.2006@gmx.net; coreboot@coreboot.org Subject: Re: [coreboot] [Fwd: Re: Contact Intel]
I remember it suddenly got harder talking to a very friendly CPU vendor after they bought a graphics chip vendor, because one guy started running around with a halo, telling that people should not buy from that very graphics chip vendor, in a half-reflected way, similar to those my ancestor countrymen suggested not to buy from certain groups of people.
As far as I know, I am the only person who protested a graphics chip vendor, so this must be intended to refer to me. Which means it is inaccurate. Omitting my name doesn't make that ok.
Whether or not you agree with my approach, calling it "half-reflected" is sheer name-calling based on ignorance.
To equate boycotting a company with racism is worse than ignorance. It is absurd.
-- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Come on Richard, enough is enough. No one is talking about racism here.
No? It definitely looks that way. Here is what Reinauer wrote:
>> that very graphics chip vendor, in a half-reflected way, similar to those >> my ancestor countrymen suggested not to buy from certain groups of >> people.
As far as I can tell, that is a thinly veiled reference to racism, and it asserts that boycotting a company is equivalent to racism.
If I misunderstood, that's not my fault. The statement was written to be unclear. If Reinauer intended some other meaning, he should state it clearly, and then we can set aside any misinterpretations.
On 09.05.2008 13:13, Richard M Stallman wrote:
Come on Richard, enough is enough. No one is talking about racism here.No? It definitely looks that way. Here is what Reinauer wrote:
>> that very graphics chip vendor, in a half-reflected way, similar to those >> my ancestor countrymen suggested not to buy from certain groups of >> people.As far as I can tell, that is a thinly veiled reference to racism, and it asserts that boycotting a company is equivalent to racism.
You're missing a point here because you don't know German history well enough (Stefan and I are from Germany). Germany saw campaigns where people suggested not to buy from groupsof peopley with whom they disagreed politically. NO racism involved AT ALL. Granted, that's one of the lesser known aspects of German history.
If I misunderstood, that's not my fault. The statement was written to be unclear. If Reinauer intended some other meaning, he should state it clearly, and then we can set aside any misinterpretations.
It's really much less ambiguous once you know the background. Besides that, there were people besides you who ran around and suggested not to buy grapics cards/chipsets from ATI/Nvidia/Intel/etc. Most companies had less than stellar behaviour in their past, but I know of no example where trying to shame a company into doing something beneficial to free software worked. It's either polite requests and workign behind the scenes, together with praising their competitors, or (if there are any GPL violations) suing them into compliance, a thing that worked remarkably well in the past here in Germany (see the injunction granted and upheld against Skype).
Regards, Carl-Daniel
On Fri, May 09, 2008 at 01:49:16PM +0200, Carl-Daniel Hailfinger wrote:
On 09.05.2008 13:13, Richard M Stallman wrote:
Come on Richard, enough is enough. No one is talking about racism here.No? It definitely looks that way. Here is what Reinauer wrote:
>> that very graphics chip vendor, in a half-reflected way, similar to those >> my ancestor countrymen suggested not to buy from certain groups of >> people.As far as I can tell, that is a thinly veiled reference to racism, and it asserts that boycotting a company is equivalent to racism.
You're missing a point here because you don't know German history well enough (Stefan and I are from Germany). Germany saw campaigns where people suggested not to buy from groupsof peopley with whom they disagreed politically. NO racism involved AT ALL. Granted, that's one of the lesser known aspects of German history.
Well, I admit that the pictures that came to my mind reading Stephan's mail can be seen by typing "kauft nicht bei Juden" in google images. And I agree with rms that this comparison is worse than absurd. However, I suggest to close this topic now. It's getting destructive.
Regards,
Andi
It's really much less ambiguous once you know the background. Besides that, there were people besides you who ran around and suggested not to buy grapics cards/chipsets from ATI/Nvidia/Intel/etc. Most companies had less than stellar behaviour in their past, but I know of no example where trying to shame a company into doing something beneficial to free software worked.
It's either polite requests and workign behind the scenes, together with praising their competitors,
I think the best approach is often to use both in parallel.
Dear Richard,
I honestly want to apologize if you understood my (undoubtably scathing) remark as an accuse of racism. This was by no means my intention (and would undoubtedly be absurd, as you reckoned).
Instead my point was that following the boycott of a political, religious or societal leading figure under the semblance of idealism can indeed have undesirable results. In the case that I mentioned, the results were not as fatal for us, but still a further obstacle to cope with.
I might be indicted for judging people by the results of their actions rather than their intent, and probably also being snappy about this. Nonetheless, I believe we do have the same goals, namely getting as many vendors to support coreboot. Now, however, I don't think a boycott, or keeping a vendors marketing support guys busy will have the effect that we desire. People stop listening to you, if they feel accused -- I fear I proved that point almost too clearly. In fact, this mailing list has a very long history of side blows against certain less-than-desired cooperative vendors, and I am inclined to say that it got us nowhere.
My suggestion is that we try to work with these guys, and find the right people inside the vendors and convince them that helping coreboot can only be a corporate advantage for them. I _know_ there is quite a reasonable number of such people in any of the corporations we're facing, including both Intel and NVidia. These are huge corporations, and finding the right people and building up a reliable and complementary relationship between them and our community is a challenge that can take years of work.
Again, please accept my apologies for the misunderstandings I seem to have caused. I really appreciate your efforts in our project. Now let's figure out how we can make our goals actually become reality.
Best regards, Stefan
All,
To help move us forward.
Some of you know that I am looking at coreboot as the *first choice* for a project I am working on here at Sun. There are still a lot of details to be worked out, but the more information I gather, the better things are looking. What I need to do is get a stable environment up and running on SimNOW. The GPLing of the AGESA code and how this all fits into Coreboot is also a major item.
I am working on the SimNOW issue, trying to get LAB working first, but would need to show multiple (LAB, gPXE, etc.) running on SimNOW. This would greatly help my case within Sun. The target for this is to be able to boot over the network/fabric. Local storage/boot media needs to be limited to flash.
Marc
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Stefan Reinauer wrote:
Dear Richard,
I honestly want to apologize if you understood my (undoubtably scathing) remark as an accuse of racism. This was by no means my intention (and would undoubtedly be absurd, as you reckoned).
Instead my point was that following the boycott of a political, religious or societal leading figure under the semblance of idealism can indeed have undesirable results. In the case that I mentioned, the results were not as fatal for us, but still a further obstacle to cope with.
I might be indicted for judging people by the results of their actions rather than their intent, and probably also being snappy about this. Nonetheless, I believe we do have the same goals, namely getting as many vendors to support coreboot. Now, however, I don't think a boycott, or keeping a vendors marketing support guys busy will have the effect that we desire. People stop listening to you, if they feel accused -- I fear I proved that point almost too clearly. In fact, this mailing list has a very long history of side blows against certain less-than-desired cooperative vendors, and I am inclined to say that it got us nowhere.
My suggestion is that we try to work with these guys, and find the right people inside the vendors and convince them that helping coreboot can only be a corporate advantage for them. I _know_ there is quite a reasonable number of such people in any of the corporations we're facing, including both Intel and NVidia. These are huge corporations, and finding the right people and building up a reliable and complementary relationship between them and our community is a challenge that can take years of work.
Again, please accept my apologies for the misunderstandings I seem to have caused. I really appreciate your efforts in our project. Now let's figure out how we can make our goals actually become reality.
Best regards, Stefan
Some reason this bounced...
********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************
Marc Karasek wrote:
All,
To help move us forward.
Some of you know that I am looking at coreboot as the *first choice* for a project I am working on here at Sun. There are still a lot of details to be worked out, but the more information I gather, the better things are looking. What I need to do is get a stable environment up and running on SimNOW. The GPLing of the AGESA code and how this all fits into Coreboot is also a major item. I am working on the SimNOW issue, trying to get LAB working first, but would need to show multiple (LAB, gPXE, etc.) running on SimNOW. This would greatly help my case within Sun. The target for this is to be able to boot over the network/fabric. Local storage/boot media needs to be limited to flash. Marc
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Stefan Reinauer wrote:
Dear Richard,
I honestly want to apologize if you understood my (undoubtably scathing) remark as an accuse of racism. This was by no means my intention (and would undoubtedly be absurd, as you reckoned).
Instead my point was that following the boycott of a political, religious or societal leading figure under the semblance of idealism can indeed have undesirable results. In the case that I mentioned, the results were not as fatal for us, but still a further obstacle to cope with.
I might be indicted for judging people by the results of their actions rather than their intent, and probably also being snappy about this. Nonetheless, I believe we do have the same goals, namely getting as many vendors to support coreboot. Now, however, I don't think a boycott, or keeping a vendors marketing support guys busy will have the effect that we desire. People stop listening to you, if they feel accused -- I fear I proved that point almost too clearly. In fact, this mailing list has a very long history of side blows against certain less-than-desired cooperative vendors, and I am inclined to say that it got us nowhere.
My suggestion is that we try to work with these guys, and find the right people inside the vendors and convince them that helping coreboot can only be a corporate advantage for them. I _know_ there is quite a reasonable number of such people in any of the corporations we're facing, including both Intel and NVidia. These are huge corporations, and finding the right people and building up a reliable and complementary relationship between them and our community is a challenge that can take years of work.
Again, please accept my apologies for the misunderstandings I seem to have caused. I really appreciate your efforts in our project. Now let's figure out how we can make our goals actually become reality.
Best regards, Stefan
On 09/05/08 08:32 -0400, Marc Karasek wrote:
All,
To help move us forward.
Some of you know that I am looking at coreboot as the *first choice* for a project I am working on here at Sun. There are still a lot of details to be worked out, but the more information I gather, the better things are looking. What I need to do is get a stable environment up and running on SimNOW. The GPLing of the AGESA code and how this all fits into Coreboot is also a major item.
I am working on the SimNOW issue, trying to get LAB working first, but would need to show multiple (LAB, gPXE, etc.) running on SimNOW. This would greatly help my case within Sun. The target for this is to be able to boot over the network/fabric. Local storage/boot media needs to be limited to flash.
I am here to help. As a quick census, here is where the buildrom payloads stand with regard to SimNow:
LAB -> You are working on this right now etherboot -> Unknown. Embaressingly, I have never gotten network to work on SimNow ... :( filo -> Needs a minor workaround, but works ofw -> unknown openbios -> unknown memtest -> works kernel -> works coreinfo -> works tint -> works grub2 - > unknown
I'm beginning to think that we should post ROMs for SimNow + these payloads on the coreboot website (like we do with Qemu), so that people can play with them. Would that be of interest to anybody?
Jordan
On Fri, May 9, 2008 at 8:13 AM, Jordan Crouse jordan.crouse@amd.com wrote:
I'm beginning to think that we should post ROMs for SimNow + these payloads on the coreboot website (like we do with Qemu), so that people can play with them. Would that be of interest to anybody?
very much so.
I'd like to create a Perceus payload for coreboot to demo cluster-in-a-ROM.
ron
LAB -> You are working on this right now etherboot -> Unknown. Embaressingly, I have never gotten network to work on SimNow ... :( filo -> Needs a minor workaround, but works ofw -> unknown openbios -> unknown memtest -> works kernel -> works coreinfo -> works tint -> works grub2 - > unknown
I'm beginning to think that we should post ROMs for SimNow + these payloads on the coreboot website (like we do with Qemu), so that people can play with them. Would that be of interest to anybody?
When buildrom just works, this isn't necessary is it?
Myles
On Fri, May 9, 2008 at 11:06 AM, Myles Watson mylesgw@gmail.com wrote:
When buildrom just works, this isn't necessary is it?
The GNU toolchain will never cease making our life exciting. A set of 'known good' binaries can help you diagnose the inevitable problems ...
ron
On 09/05/08 15:38 -0700, ron minnich wrote:
On Fri, May 9, 2008 at 11:06 AM, Myles Watson mylesgw@gmail.com wrote:
When buildrom just works, this isn't necessary is it?
The GNU toolchain will never cease making our life exciting. A set of 'known good' binaries can help you diagnose the inevitable problems ...
Are you volunteering to be our buildmeister? Here is the job description:
* Write and maintain the toolchain targets - this involves downloading and building binutils and gcc (please see buildroot or OpenEmebedded for examples of how complex this can be).
* Write and maintain a libc target - either uclibc or glibc, uclibc is easier, but if you choose uclibc then you may be responsible for fixing payloads that might not know how to work with uclibc.
* Make sure all the buildrom code is aware of the toolchain, and work around the inevitable library issues.
* Don't forget that we need to be able to support both 32 and 64 bit binaries.
* Be ready at all times to update the toolchain to support the kernel when it inevitably decides to drop an old version of the compiler.
* Answer all the complaints when the buildrom process goes from a few minutes to 30 minutes just to build a "known good" toolchain.
Or, alternatively - we can just skip the whole thing and figure out why we are so darn toolchain specific. And if it isn't us, then we yell at the responsible parties. I don't see a single line of code in our entire repository that says "We need GCC foo to work".
Jordan
On Fri, May 9, 2008 at 3:53 PM, Jordan Crouse jordan.crouse@amd.com wrote:
Are you volunteering to be our buildmeister? Here is the job description:
jordan, I was not really very clear on my note. What I was trying to say:
You had volunteered to put some binary rom images up on coreboot. I think it's a great idea. This is what I meant by 'binaries'. The reason is that if someone (e.g. me) has a problem with a rom, I can try to figure out if it is a simnow, toolchain, or other problem by downloading the JordanWare image from coreboot.
I was trying to respond to the question of whether source is sufficient. Given toolchain issues that have plagued us for almost 9 years, I think the rom images on coreboot.org could be extremely useful.
thanks and sorry for confusing things
ron
- Write and maintain the toolchain targets - this involves downloading
and building binutils and gcc (please see buildroot or OpenEmebedded for examples of how complex this can be).
Or see http://git.infradead.org/users/segher/buildall.git for an example of how simple it is. This builds toolchains (for pretty much any target arch) without libc support; they can build an OS kernel or a firmware just fine.
Segher
On 10/05/08 15:39 +0200, Segher Boessenkool wrote:
- Write and maintain the toolchain targets - this involves downloading and
building binutils and gcc (please see buildroot or OpenEmebedded for examples of how complex this can be).
Or see http://git.infradead.org/users/segher/buildall.git for an example of how simple it is. This builds toolchains (for pretty much any target arch) without libc support; they can build an OS kernel or a firmware just fine.
Which is great, but here our very problem is that we need libc support.
Jordan
well I've built and booted coreboot on simnow and am quite impressed! It's quite nice.
ron
Ron,
What did you build and how did you do it? Inquiring minds want to know...
Marc
********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************
ron minnich wrote:
well I've built and booted coreboot on simnow and am quite impressed! It's quite nice.
ron
I pulled down buildrom to my FC8 32-bit system, and made the tint payload. It worked first time out. Resizing for the 1M bios -- there was no resizing to do.
If you're cross-building, however, that might make it fun.
My next payload is Plan 9.
ron
Ron,
What is tint??
Ok I have been able to build a filo payload. And it did work. I think were the problem lies is in LAB.
I am wondering how critical is it to have uclibc or a "common/standard" toolchain for building coreboot/payloads.
I have built and maintained cross-compilers before. Nothing with uClibc in it but with glibc.
Marc
********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************
ron minnich wrote:
I pulled down buildrom to my FC8 32-bit system, and made the tint payload. It worked first time out. Resizing for the 1M bios -- there was no resizing to do.
If you're cross-building, however, that might make it fun.
My next payload is Plan 9.
ron
On 12/05/08 12:58 -0400, Marc Karasek wrote:
Ron,
What is tint??
Ok I have been able to build a filo payload. And it did work. I think were the problem lies is in LAB. I am wondering how critical is it to have uclibc or a "common/standard" toolchain for building coreboot/payloads.
I have built and maintained cross-compilers before. Nothing with uClibc in it but with glibc.
We seem to bring it up every time we discuss this, but there is probably a reason for it: Should we consider outsourcing bulding the LAB to buildroot or some other third-party build system that is more willing to build and maintain the toolchains?
Jordan
ron minnich wrote:
I pulled down buildrom to my FC8 32-bit system, and made the tint payload. It worked first time out. Resizing for the 1M bios -- there was no resizing to do.
If you're cross-building, however, that might make it fun.
My next payload is Plan 9.
ron
Jordan, Marc, Ron, et all.
I found the problem with building coreboot-v2. It was the binutils. I believe the seg fault in linking tint/coreinfo is the same issue. I will try to verify this soon.
I would like to propose that we move to a cross-compile type of environment. We could use crosstools scripts to build a complete environment that would go under /opt/crosstools. This could then be used by buildrom to build with. The advantage is that everyone will be on the same page in terms of gcc/binutils/glibc versions and we can have a better control over what tools are used. It gets us away from any distro/tools dependencies. It will also let us test new toolchains in a very controlled environment. Another added bonus with a common set of tools is that third-party developers can use this without worrying about toolchain issues.
I have some experience in using cross-compilers from other embedded projects. I have already setup crosstools with gcc 4.1.0 / binutils 2.16 / glibc 2.3.6 on my system. I could take on the task of modifying buildrom to use this toolchain instead of the "native" toolchain. I
Marc
********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************
Jordan Crouse wrote:
On 12/05/08 12:58 -0400, Marc Karasek wrote:
Ron,
What is tint??
Ok I have been able to build a filo payload. And it did work. I think were the problem lies is in LAB. I am wondering how critical is it to have uclibc or a "common/standard" toolchain for building coreboot/payloads.
I have built and maintained cross-compilers before. Nothing with uClibc in it but with glibc.
We seem to bring it up every time we discuss this, but there is probably a reason for it: Should we consider outsourcing bulding the LAB to buildroot or some other third-party build system that is more willing to build and maintain the toolchains?
Jordan
ron minnich wrote:
I pulled down buildrom to my FC8 32-bit system, and made the tint payload. It worked first time out. Resizing for the 1M bios -- there was no resizing to do.
If you're cross-building, however, that might make it fun.
My next payload is Plan 9.
ron
On 14/05/08 10:58 -0400, Marc Karasek wrote:
Jordan, Marc, Ron, et all.
I found the problem with building coreboot-v2. It was the binutils. I believe the seg fault in linking tint/coreinfo is the same issue. I will try to verify this soon.
I would like to propose that we move to a cross-compile type of environment. We could use crosstools scripts to build a complete environment that would go under /opt/crosstools. This could then be used by buildrom to build with. The advantage is that everyone will be on the same page in terms of gcc/binutils/glibc versions and we can have a better control over what tools are used. It gets us away from any distro/tools dependencies. It will also let us test new toolchains in a very controlled environment. Another added bonus with a common set of tools is that third-party developers can use this without worrying about toolchain issues.
I have some experience in using cross-compilers from other embedded projects. I have already setup crosstools with gcc 4.1.0 / binutils 2.16 / glibc 2.3.6 on my system. I could take on the task of modifying buildrom to use this toolchain instead of the "native" toolchain. I
I feel very strongly that this should not be mandatory. I appreciate the trouble you have had, but I think that adding a mandatory cross-compile toolchain is too high a barrier for entry for novice buildrom users.
I have always believed, and I will always believe that the reason that any given toolchain doesn't work out of the box is the fault of the software you are compiling and not the fault of the toolchain. The moment we start to turn a blind eye to our own faults and start blaming toolchains, then we have started down a slippery slope. Eventually, coreboot and buildrom and the payloads will only be compilable with a special toolchain that is six years old and we'll be content to sit around and blame it all on the compiler team. Thats not a future I relish.
If libpayload based payloads are not building, then I consider that a personal failure, and we need to resolve it. Please send me the details.
That all said, I would be perfectly happy to let the user specify a local toolchain to compile buildrom, as long as that behavior is configurable and the default remains to use the system toolchain. I'm sure that your experience with crosstools will be good for a wiki page describing the care and feeding of a cross-compile toolchain and how to use it with buildrom. I look forward to seeing that.
But I beg you, please give us as much information as you have about your failures so that we can try to fix them in the code. And everybody else, we need to stop throwing our hands up when we encounter toolchain issues - we need to understand them and why there is a much better then average chance that it is our code that is to blame.
Thanks, Jordan
Jordan,
I agree with you about it being more of a coreboot problem than a toolchain problem. (Although, building a cross-compiler is really quite simple, if you use the crosstools scripts. It is just a matter of running a script.) I will put together all of my information on what is broken and what errors I am seeing as soon as I can.
I know that (recently) gcc/binutils has been through a "tightening" process where they have been trying to cleanup their act, by following more strict compiling/linking. This has resulted in quite a few builds being broken due to things that were once allowed and are not allowed now.
I like the idea of being able to "specify" a local toolchain. This would give someone the option to compile and build with a "known" good toolchain. I feel this is useful in that toolchain problems can be very difficult to track down. They normally manifest themselves in a seg fault when running the compiled application or a very ambiguous error message during linking/compiling. This would provide a path for someone to continue on with their development/testing while (potentialy) someone else looks at the build problem.
I will look at this and see what changes would need to be made to buildrom to make so you can specify a different local compiler. This would follow along the lines of $(CROSS-COMPILER) macro that is usually used for compiling an application with a cross-compiler.
Marc
********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************
Jordan Crouse wrote:
On 14/05/08 10:58 -0400, Marc Karasek wrote:
Jordan, Marc, Ron, et all.
I found the problem with building coreboot-v2. It was the binutils. I believe the seg fault in linking tint/coreinfo is the same issue. I will try to verify this soon.
I would like to propose that we move to a cross-compile type of environment. We could use crosstools scripts to build a complete environment that would go under /opt/crosstools. This could then be used by buildrom to build with. The advantage is that everyone will be on the same page in terms of gcc/binutils/glibc versions and we can have a better control over what tools are used. It gets us away from any distro/tools dependencies. It will also let us test new toolchains in a very controlled environment. Another added bonus with a common set of tools is that third-party developers can use this without worrying about toolchain issues.
I have some experience in using cross-compilers from other embedded projects. I have already setup crosstools with gcc 4.1.0 / binutils 2.16 / glibc 2.3.6 on my system. I could take on the task of modifying buildrom to use this toolchain instead of the "native" toolchain. I
I feel very strongly that this should not be mandatory. I appreciate the trouble you have had, but I think that adding a mandatory cross-compile toolchain is too high a barrier for entry for novice buildrom users.
I have always believed, and I will always believe that the reason that any given toolchain doesn't work out of the box is the fault of the software you are compiling and not the fault of the toolchain. The moment we start to turn a blind eye to our own faults and start blaming toolchains, then we have started down a slippery slope. Eventually, coreboot and buildrom and the payloads will only be compilable with a special toolchain that is six years old and we'll be content to sit around and blame it all on the compiler team. Thats not a future I relish.
If libpayload based payloads are not building, then I consider that a personal failure, and we need to resolve it. Please send me the details.
That all said, I would be perfectly happy to let the user specify a local toolchain to compile buildrom, as long as that behavior is configurable and the default remains to use the system toolchain. I'm sure that your experience with crosstools will be good for a wiki page describing the care and feeding of a cross-compile toolchain and how to use it with buildrom. I look forward to seeing that.
But I beg you, please give us as much information as you have about your failures so that we can try to fix them in the code. And everybody else, we need to stop throwing our hands up when we encounter toolchain issues - we need to understand them and why there is a much better then average chance that it is our code that is to blame.
Thanks, Jordan
Jordan, et all,
There is one caveat to my previous email.
Currently for LAB busybox is compiled with uClibc using the -nostdlib option. According to the uClibc FAQ is no longer supported (since 0.22). It was handled through a toolchain wrapper and the uClibc guys decided that it was too much of a problem in maintaining it and pulled the support. They now recommend building a toolchain with buildroot and using this to compile your application/program.
Marc
********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************
Marc Karasek wrote:
Jordan,
I agree with you about it being more of a coreboot problem than a toolchain problem. (Although, building a cross-compiler is really quite simple, if you use the crosstools scripts. It is just a matter of running a script.) I will put together all of my information on what is broken and what errors I am seeing as soon as I can.
I know that (recently) gcc/binutils has been through a "tightening" process where they have been trying to cleanup their act, by following more strict compiling/linking. This has resulted in quite a few builds being broken due to things that were once allowed and are not allowed now.
I like the idea of being able to "specify" a local toolchain. This would give someone the option to compile and build with a "known" good toolchain. I feel this is useful in that toolchain problems can be very difficult to track down. They normally manifest themselves in a seg fault when running the compiled application or a very ambiguous error message during linking/compiling. This would provide a path for someone to continue on with their development/testing while (potentialy) someone else looks at the build problem.
I will look at this and see what changes would need to be made to buildrom to make so you can specify a different local compiler. This would follow along the lines of $(CROSS-COMPILER) macro that is usually used for compiling an application with a cross-compiler.
Marc
Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415
Jordan Crouse wrote:
On 14/05/08 10:58 -0400, Marc Karasek wrote:
Jordan, Marc, Ron, et all.
I found the problem with building coreboot-v2. It was the binutils. I believe the seg fault in linking tint/coreinfo is the same issue. I will try to verify this soon.
I would like to propose that we move to a cross-compile type of environment. We could use crosstools scripts to build a complete environment that would go under /opt/crosstools. This could then be used by buildrom to build with. The advantage is that everyone will be on the same page in terms of gcc/binutils/glibc versions and we can have a better control over what tools are used. It gets us away from any distro/tools dependencies. It will also let us test new toolchains in a very controlled environment. Another added bonus with a common set of tools is that third-party developers can use this without worrying about toolchain issues.
I have some experience in using cross-compilers from other embedded projects. I have already setup crosstools with gcc 4.1.0 / binutils 2.16 / glibc 2.3.6 on my system. I could take on the task of modifying buildrom to use this toolchain instead of the "native" toolchain. I
I feel very strongly that this should not be mandatory. I appreciate the trouble you have had, but I think that adding a mandatory cross-compile toolchain is too high a barrier for entry for novice buildrom users.
I have always believed, and I will always believe that the reason that any given toolchain doesn't work out of the box is the fault of the software you are compiling and not the fault of the toolchain. The moment we start to turn a blind eye to our own faults and start blaming toolchains, then we have started down a slippery slope. Eventually, coreboot and buildrom and the payloads will only be compilable with a special toolchain that is six years old and we'll be content to sit around and blame it all on the compiler team. Thats not a future I relish.
If libpayload based payloads are not building, then I consider that a personal failure, and we need to resolve it. Please send me the details.
That all said, I would be perfectly happy to let the user specify a local toolchain to compile buildrom, as long as that behavior is configurable and the default remains to use the system toolchain. I'm sure that your experience with crosstools will be good for a wiki page describing the care and feeding of a cross-compile toolchain and how to use it with buildrom. I look forward to seeing that.
But I beg you, please give us as much information as you have about your failures so that we can try to fix them in the code. And everybody else, we need to stop throwing our hands up when we encounter toolchain issues - we need to understand them and why there is a much better then average chance that it is our code that is to blame.
Thanks, Jordan
On 16/05/08 08:51 -0400, Marc Karasek wrote:
Jordan, et all,
There is one caveat to my previous email.
Currently for LAB busybox is compiled with uClibc using the -nostdlib option. According to the uClibc FAQ is no longer supported (since 0.22). It was handled through a toolchain wrapper and the uClibc guys decided that it was too much of a problem in maintaining it and pulled the support. They now recommend building a toolchain with buildroot and using this to compile your application/program.
This is indeed a problem, and even more makes me think that we're going to need to turn to an outside build engine (such as buildroot) to build our LAB images.
Jordan
Marc Karasek wrote:
Jordan,
I agree with you about it being more of a coreboot problem than a toolchain problem. (Although, building a cross-compiler is really quite simple, if you use the crosstools scripts. It is just a matter of running a script.) I will put together all of my information on what is broken and what errors I am seeing as soon as I can.
I know that (recently) gcc/binutils has been through a "tightening" process where they have been trying to cleanup their act, by following more strict compiling/linking. This has resulted in quite a few builds being broken due to things that were once allowed and are not allowed now.
I like the idea of being able to "specify" a local toolchain. This would give someone the option to compile and build with a "known" good toolchain. I feel this is useful in that toolchain problems can be very difficult to track down. They normally manifest themselves in a seg fault when running the compiled application or a very ambiguous error message during linking/compiling. This would provide a path for someone to continue on with their development/testing while (potentialy) someone else looks at the build problem.
I will look at this and see what changes would need to be made to buildrom to make so you can specify a different local compiler. This would follow along the lines of $(CROSS-COMPILER) macro that is usually used for compiling an application with a cross-compiler.
Marc
Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415
Jordan Crouse wrote:
On 14/05/08 10:58 -0400, Marc Karasek wrote:
Jordan, Marc, Ron, et all.
I found the problem with building coreboot-v2. It was the binutils. I believe the seg fault in linking tint/coreinfo is the same issue. I will try to verify this soon.
I would like to propose that we move to a cross-compile type of environment. We could use crosstools scripts to build a complete environment that would go under /opt/crosstools. This could then be used by buildrom to build with. The advantage is that everyone will be on the same page in terms of gcc/binutils/glibc versions and we can have a better control over what tools are used. It gets us away from any distro/tools dependencies. It will also let us test new toolchains in a very controlled environment. Another added bonus with a common set of tools is that third-party developers can use this without worrying about toolchain issues.
I have some experience in using cross-compilers from other embedded projects. I have already setup crosstools with gcc 4.1.0 / binutils 2.16 / glibc 2.3.6 on my system. I could take on the task of modifying buildrom to use this toolchain instead of the "native" toolchain. I
I feel very strongly that this should not be mandatory. I appreciate the trouble you have had, but I think that adding a mandatory cross-compile toolchain is too high a barrier for entry for novice buildrom users.
I have always believed, and I will always believe that the reason that any given toolchain doesn't work out of the box is the fault of the software you are compiling and not the fault of the toolchain. The moment we start to turn a blind eye to our own faults and start blaming toolchains, then we have started down a slippery slope. Eventually, coreboot and buildrom and the payloads will only be compilable with a special toolchain that is six years old and we'll be content to sit around and blame it all on the compiler team. Thats not a future I relish.
If libpayload based payloads are not building, then I consider that a personal failure, and we need to resolve it. Please send me the details.
That all said, I would be perfectly happy to let the user specify a local toolchain to compile buildrom, as long as that behavior is configurable and the default remains to use the system toolchain. I'm sure that your experience with crosstools will be good for a wiki page describing the care and feeding of a cross-compile toolchain and how to use it with buildrom. I look forward to seeing that.
But I beg you, please give us as much information as you have about your failures so that we can try to fix them in the code. And everybody else, we need to stop throwing our hands up when we encounter toolchain issues
we need to understand them and why there is a much better then average chance that it is our code that is to blame.
Thanks, Jordan
Jordan,
I can take a look (when I get some time) at how to have buildroot do the LAB payload. Either this or use the crosstools scripts to do it. Both will create a cross-compiler and build environment.
I will prob not be able to get to this for a few weeks, I will be on vacation next week and have some other tasks I need to get done.
Marc
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Jordan Crouse wrote:
On 16/05/08 08:51 -0400, Marc Karasek wrote:
Jordan, et all,
There is one caveat to my previous email.
Currently for LAB busybox is compiled with uClibc using the -nostdlib option. According to the uClibc FAQ is no longer supported (since 0.22). It was handled through a toolchain wrapper and the uClibc guys decided that it was too much of a problem in maintaining it and pulled the support. They now recommend building a toolchain with buildroot and using this to compile your application/program.
This is indeed a problem, and even more makes me think that we're going to need to turn to an outside build engine (such as buildroot) to build our LAB images.
Jordan
Marc Karasek wrote:
Jordan,
I agree with you about it being more of a coreboot problem than a toolchain problem. (Although, building a cross-compiler is really quite simple, if you use the crosstools scripts. It is just a matter of running a script.) I will put together all of my information on what is broken and what errors I am seeing as soon as I can.
I know that (recently) gcc/binutils has been through a "tightening" process where they have been trying to cleanup their act, by following more strict compiling/linking. This has resulted in quite a few builds being broken due to things that were once allowed and are not allowed now.
I like the idea of being able to "specify" a local toolchain. This would give someone the option to compile and build with a "known" good toolchain. I feel this is useful in that toolchain problems can be very difficult to track down. They normally manifest themselves in a seg fault when running the compiled application or a very ambiguous error message during linking/compiling. This would provide a path for someone to continue on with their development/testing while (potentialy) someone else looks at the build problem.
I will look at this and see what changes would need to be made to buildrom to make so you can specify a different local compiler. This would follow along the lines of $(CROSS-COMPILER) macro that is usually used for compiling an application with a cross-compiler.
Marc
Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415
Jordan Crouse wrote:
On 14/05/08 10:58 -0400, Marc Karasek wrote:
Jordan, Marc, Ron, et all.
I found the problem with building coreboot-v2. It was the binutils. I believe the seg fault in linking tint/coreinfo is the same issue. I will try to verify this soon.
I would like to propose that we move to a cross-compile type of environment. We could use crosstools scripts to build a complete environment that would go under /opt/crosstools. This could then be used by buildrom to build with. The advantage is that everyone will be on the same page in terms of gcc/binutils/glibc versions and we can have a better control over what tools are used. It gets us away from any distro/tools dependencies. It will also let us test new toolchains in a very controlled environment. Another added bonus with a common set of tools is that third-party developers can use this without worrying about toolchain issues.
I have some experience in using cross-compilers from other embedded projects. I have already setup crosstools with gcc 4.1.0 / binutils 2.16 / glibc 2.3.6 on my system. I could take on the task of modifying buildrom to use this toolchain instead of the "native" toolchain. I
I feel very strongly that this should not be mandatory. I appreciate the trouble you have had, but I think that adding a mandatory cross-compile toolchain is too high a barrier for entry for novice buildrom users.
I have always believed, and I will always believe that the reason that any given toolchain doesn't work out of the box is the fault of the software you are compiling and not the fault of the toolchain. The moment we start to turn a blind eye to our own faults and start blaming toolchains, then we have started down a slippery slope. Eventually, coreboot and buildrom and the payloads will only be compilable with a special toolchain that is six years old and we'll be content to sit around and blame it all on the compiler team. Thats not a future I relish.
If libpayload based payloads are not building, then I consider that a personal failure, and we need to resolve it. Please send me the details.
That all said, I would be perfectly happy to let the user specify a local toolchain to compile buildrom, as long as that behavior is configurable and the default remains to use the system toolchain. I'm sure that your experience with crosstools will be good for a wiki page describing the care and feeding of a cross-compile toolchain and how to use it with buildrom. I look forward to seeing that.
But I beg you, please give us as much information as you have about your failures so that we can try to fix them in the code. And everybody else, we need to stop throwing our hands up when we encounter toolchain issues
we need to understand them and why there is a much better then average chance that it is our code that is to blame.
Thanks, Jordan
I know that (recently) gcc/binutils has been through a "tightening" process where they have been trying to cleanup their act, by following more strict compiling/linking.
You mean that GCC continually improves its user error detection.
This has resulted in quite a few builds being broken due to things that were once allowed and are not allowed now.
"Things used to work accidentally, and are now correctly flagged as errors".
I like the idea of being able to "specify" a local toolchain.
Of course -- this is how every other project is built!
This would give someone the option to compile and build with a "known" good toolchain.
Or a known-bad. Or just a different one, for testing or whatever.
I feel this is useful in that toolchain problems can be very difficult to track down.
Yes, they can be. They usually aren't though.
They normally manifest themselves in a seg fault when running the compiled application or a very ambiguous error message during linking/compiling.
Make sure you enable lots of compiler warnings, they help find fishy code.
If you don't understand the errors the compiler is throwing, please ask (on gcc-help, for example), or read the manual. I'm sure many error messages can be improved; please file PRs for that, or send patches, etc.
I will look at this and see what changes would need to be made to buildrom to make so you can specify a different local compiler. This would follow along the lines of $(CROSS-COMPILER) macro that is usually used for compiling an application with a cross-compiler.
Most people use $(CC) and $(CFLAGS), etc.
Segher
I feel very strongly that this should not be mandatory. I appreciate the trouble you have had, but I think that adding a mandatory cross-compile toolchain is too high a barrier for entry for novice buildrom users.
It's also wholly unnecessary. The only thing it would do is replace some build machinery that detects what specific toolchain commands to use with build machinery that detects how to build a specific toolchain.
I have always believed, and I will always believe that the reason that any given toolchain doesn't work out of the box is the fault of the software you are compiling and not the fault of the toolchain.
Strongly agreed, with the caveat that the toolchain *can* have bugs -- but it's childish to start blaming the toolchain until you have proof it's doing something wrong. Much more often it's pilot error.
The moment we start to turn a blind eye to our own faults and start blaming toolchains, then we have started down a slippery slope. Eventually, coreboot and buildrom and the payloads will only be compilable with a special toolchain that is six years old and we'll be content to sit around and blame it all on the compiler team.
Hey, coreboot runs into a broken linker more often than into a broken compiler, even ;-)
That all said, I would be perfectly happy to let the user specify a local toolchain to compile buildrom, as long as that behavior is configurable and the default remains to use the system toolchain.
The default should be to try to find some toolchain if nothing was specified, sure. A few lines of script for a lot of user-friendliness.
I'm sure that your experience with crosstools will be good for a wiki page describing the care and feeding of a cross-compile toolchain and how to use it with buildrom. I look forward to seeing that.
Aye.
But I beg you, please give us as much information as you have about your failures so that we can try to fix them in the code. And everybody else, we need to stop throwing our hands up when we encounter toolchain issues - we need to understand them and why there is a much better then average chance that it is our code that is to blame.
Better than 95% chance? :-)
Segher
I have always believed, and I will always believe that the reason that any given toolchain doesn't work out of the box is the fault of the software you are compiling and not the fault of the toolchain. The moment we start to turn a blind eye to our own faults and start blaming toolchains, then we have started down a slippery slope. Eventually, coreboot and buildrom and the payloads will only be compilable with a special toolchain that is six years old and we'll be content to sit around and blame it all on the compiler team. Thats not a future I relish.
I'd love to get several builds working on my system (FC6 with updated gcc and binutils). The latest is LegacyBIOS. I can't get the serial port to work when it's built on my machine, even though other people's builds seem to work. The funny thing about that is that it still boots Windows XP on qemu, but there's no serial output.
Any advice on where to start looking? I'm stumped.
Thanks, Myles
PS Jordan: Did you find out what's wrong with the serial port in SimNOW?
Ok I get a : collect2: ld terminated with signal 11 [Segmentation fault] when I try to compile tint..
I am going to try a fresh buildrom to see if that helps...
********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************
ron minnich wrote:
I pulled down buildrom to my FC8 32-bit system, and made the tint payload. It worked first time out. Resizing for the 1M bios -- there was no resizing to do.
If you're cross-building, however, that might make it fun.
My next payload is Plan 9.
ron
One issue is this:
CONFIG_VERBOSE=y
[root@simnow buildrom-devel]# make Building TINT... make: *** [/root/buildrom/buildrom-devel/work/tint/tint-0.03b/tint.elf] Error 2 [root@simnow buildrom-devel]#
That's all I get on this system: Caos NSA: Node - Server - Appliance (release 0.9/Cato) (64 bit)
but on this: Fedora release 7 (Moonshine) )(32 bit)
I get all kinds of output.
Marc, you getting verbose output?
you might want to build on 32 bit only. ron
Dear Richard,
Am Freitag, den 09.05.2008, 14:17 +0200 schrieb Stefan Reinauer:
Now let's figure out how we can make our goals actually become reality.
I guess, you travel around a lot and participate in all kind of conferences?
Were you already be able to get coreboot running on one of your machines? I can imagine, that you could tell people from your (hopefully satisfying) experience and in doing so make coreboot more aware to the public. I think a lot of people do not know about coreboot and even do not think that a BIOS can be substituted by a free BIOS. At least I did not know it.
I hope, that then some interested people will try to get their motherboard supported and a few of them will send patches, do porting, test patches or support the project in other ways.
I assume, that besides getting the documentation from the manufacturer time to work on the project is most important. And therefore more developers are appreciated.
I hope, I am making sense and that this idea does not contradict to any standpoints or policy of the main developers of coreboot in respect of marketing coreboot.
Thanks,
Paul
I do talk about the issue of free BIOS in my speeches, especially now that I am using an OLPC which I chose specifically to use a free BIOS.
My suggestion is that we try to work with these guys, and find the right people inside the vendors and convince them that helping coreboot can only be a corporate advantage for them. I _know_ there is quite a reasonable number of such people in any of the corporations we're facing, including both Intel and NVidia.
I have nothing against that approach. In fact, that is what I would try first in any given case.
However, since InVidious has gone for years without listening to us, maybe a protest by one of is what is required to make them pay attention to the other.
On Sat, May 10, 2008 at 5:38 PM, Richard M Stallman rms@gnu.org wrote:
My suggestion is that we try to work with these guys, and find the right people inside the vendors and convince them that helping coreboot can only be a corporate advantage for them. I _know_ there is quite a reasonable number of such people in any of the corporations we're facing, including both Intel and NVidia.
I have nothing against that approach. In fact, that is what I would try first in any given case.
However, since InVidious has gone for years without listening to us, maybe a protest by one of is what is required to make them pay attention to the other.
I'm sorry Richard, I've always had the greatest respect for you, but I have to strongly disagree. I imagine Nvidia has probably already done a cost-benefit analysis, and determined that it's not worth it for them to participate on a larger level then they already have (who got yhlu to do mcp55, was it nvidia or tyan?). As more companies get onboard, that sentiment may change. I can't see a protest possibly helping the situation. Would you prick a doctor with a pin until he gave you a complimentary open heart surgery? Perhaps not the best analogy, but it's been a long day. What I'm trying to say is, if we want these companies to get onboard, we have to be able to offer them some sort of benefit for doing so. v3 is, IMO, getting there.
-Corey
I'm sorry Richard, I've always had the greatest respect for you, but I have to strongly disagree. I imagine Nvidia has probably already done a cost-benefit analysis, and determined that it's not worth it for them to participate
I doubt that they are rational -- I think they overestimate the importance of secrecy. Thus, I think that terms such as "cost-benefit analysis" are misleading.
Meanwhile, public disapproval is a significant factor in their conclusions. Protests can affect them.
Also there is another factor to consider : - maybe they are bound by (secret) trade agreements with .. (ahem..) various other corporations and organisations all around the world.. Like it or not this is the reality in the corporate world today.. :/ Just my 2 (euro)cents.. Florentin
Quoting Richard M Stallman rms@gnu.org:
I'm sorry Richard, I've always had the greatest respect for you, but Ihave to strongly disagree. I imagine Nvidia has probably already done a cost-benefit analysis, and determined that it's not worth it for them to participate
I doubt that they are rational -- I think they overestimate the importance of secrecy. Thus, I think that terms such as "cost-benefit analysis" are misleading.
Meanwhile, public disapproval is a significant factor in their conclusions. Protests can affect them.
-- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
I agree with Carl-Daniel here, we should focus on the positive not the negative. Publishing anything about Intel's stubbornness would probably come back to bite us in the ass one day. Karma, what you give, will always come back. It may not be tomorrow but someday it will come back.
Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org
-----Original Message----- From: coreboot-bounces@coreboot.org [mailto:coreboot-bounces@coreboot.org] On Behalf Of Carl-Daniel Hailfinger Sent: Tuesday, May 06, 2008 7:33 PM To: rms@gnu.org Cc: coreboot@coreboot.org Subject: Re: [coreboot] [Fwd: Re: Contact Intel]
On 07.05.2008 01:06, Richard M Stallman wrote:
Would you like me to encourage a friendly journalist to contact you to
write about Intel's refusal to cooperate?
The preferred way would be to focus any article on praising the companies supporting coreboot. We had a detailed list somewhere, we could dig it up and mail it to you. Usually, shaming companies into contributing doesn't work, but giving the good ones lots of good publicity strengthens the positions of coreboot supporters in those companies. Besides that, while the tech media like to bash "evil" companies every so often, writing about cool gadgets with cool features is what lures readers to them.
I'd suggest we wait with contacting any journalist until we can offer all the information needed for an article in one neat package.
Regards, Carl-Daniel
-- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
I agree with Carl-Daniel here, we should focus on the positive not the negative. Publishing anything about Intel's stubbornness would probably come back to bite us in the ass one day. Karma, what you give, will always come back. It may not be tomorrow but someday it will come back.
Being good is not the same as being nice; if there is anything valid about the concept of karma, resisting Intel would give you good karma.
Anyway, I will cooperate with whatever you decide. If and when you want me to write to a journalist, please let me know.
On Thursday 01 May 2008, Richard M Stallman wrote:
Some of the points are simply distractions or illogical. For instance:
BIOS is a part of the reliability and performance promise of the hardware.Is that true? If so, so what? That is no reason not to let us run our own BIOS.
Well, sort of. From my experience, which very likely most on this list can share, BIOS is used to cover up defects in the hardware. Thus, it's a PR question, not a technical one.
Chipset specifications at the level being discussed are commonly considered proprietary by all silicon vendors, not just Intel.
As Peter has already mentioned, that's a lie^W^Woutdated. Additionally to Peter's points, the new "gallium" driver for mesa is being developed for a pure software pipeline and, as the only hardware implementation,... TADAAA: intel onboard graphics i915.
However, it is false: some computer models do work with free BIOS. Intel compares badly with them. This is one of the statements that maybe could be criticized in a published response.
The open source firmware work that Intel *is* sponsoring could lead to a solution where proprietary low-level chipset initialization code from silicon vendors is made compatible with open source higher-level platform initialization and pre-boot management.As they say, this is not a complete free BIOS, just part of one.
As things look like today, it's a layer _on_top_ of what's currently known as BIOS. Besides, did they lift the royalties clause on UEFI yet? (http://www.uefi.org/specs/agreement : "...implementation ... requires a license")
Torsten
Well, sort of. From my experience, which very likely most on this list can share, BIOS is used to cover up defects in the hardware. Thus, it's a PR question, not a technical one.
If that is true, maybe they are making much ado about little. Suppose there is a problem in the machine that would only affect users that make changes in the BIOS. That won't be very bad publicity.
On Wed, Apr 30, 2008 at 06:59:02PM +0200, arc wrote:
Is there a vendor that showed some interest in the free bios project?
Indeed there are.
AMD is actively supporting coreboot with documentation and code. They presented some nice slides at the coreboot meeting in Denver last month: http://www.coreboot.org/images/6/60/Coreboot_summit_08.pdf
VIA releases documentation under NDA, allowing GPL code to be written from it. Some developers have signed. VIA are pretty slow though, it regularly takes several weeks for them to send the requested documentation even when agreements are in place.
SiS have contributed code to coreboot.
PC Engines have assisted with technical information needed to port coreboot to their boards.
Kontron just recently contributed code to make flashrom work with some of their products.
US-based Silicon Mechanics offers a particular Opteron rack server preinstalled with coreboot.
Stefan Reinauer's company coresystems GmbH and my company Konsult Stuge both offer professional coreboot services.
My company also offers the Gigabyte GA-M57SLI-S4 mainboard modified with a second, 2Mbyte large, flash chip and a BIOS switch, preinstalled with coreboot for sale to businesses worldwide and end users in certain european countries. (Restrictions due to EU environmental legislation.)
There are several other vendors who have either helped further the project or have offers on products and services related to it:
http://www.coreboot.org/Sponsors http://www.coreboot.org/Products
Is there something I could do to push vendors to help?
I think that only a solid business case fitting the vendor's existing model of operation is convincing enough.
//Peter
Does coreboot have a web page with this list of vendors and how they cooperate? Or even a partial list? That could be used to put pressure on Intel and others when they claim that everyone acts like them.
-
Andreas B. Mundt -
arc -
Carl-Daniel Hailfinger -
Corey Osgood -
Florentin Demetrescu -
Joe -
Jordan Crouse -
Marc Karasek -
Myles Watson -
Patrick Georgi -
Paul Menzel -
Peter Lemenkov -
Peter Stuge -
Ralph Green -
Richard M Stallman -
Robert Vogel -
ron minnich -
Segher Boessenkool -
Stefan Reinauer -
Torsten Duwe