stepan, this one looks harmless to me, any changes since you submitted a month ago?
ron
* Ronald G Minnich rminnich@lanl.gov [051123 05:32]:
stepan, this one looks harmless to me, any changes since you submitted a month ago?
It is. But I am trying to move them to the newest tree, including cache as ram. So I suggest we have this wait until I get the current tree up to date and merge that stuff in then.
Stefan
Stefan Reinauer wrote:
- Ronald G Minnich rminnich@lanl.gov [051123 05:32]:
stepan, this one looks harmless to me, any changes since you submitted a month ago?
It is. But I am trying to move them to the newest tree, including cache as ram. So I suggest we have this wait until I get the current tree up to date and merge that stuff in then.
what do you see as the most important issues to work on while we get CAR going everywhere?
ron
what do you see as the most important issues to work on while we get CAR going everywhere?
What do you plan to do for platforms like VIA, geode or other embedded setups which may never support CAR? Or at least it will be awhile until they do.
-- Richard A. Smith
Richard Smith wrote:
What do you plan to do for platforms like VIA, geode or other embedded setups which may never support CAR? Or at least it will be awhile until they do.
I want to deprecate ROMCC as much as we possibly can. Over time, we're going to find all systems supporting CAR, so in the long run, ROMCC will be gone. Of course, as long as we need ROMCC, it will be there; but if a system can use CAR, it should never use ROMCC!
I really think ROMCC is one of the neatest things I've ever seen, but I would still like to get it out of linuxbios, now that we know how CAR works. I don't like having a C compiler as part of LinuxBIOS -- we have enough code to maintain.
Also, it's not clear that CAR won't work on these other platforms, now that we know the "CAR trick". It has not been tested. I suspect it will work on VIA.
ron
* Ronald G Minnich rminnich@lanl.gov [051123 16:32]:
It is. But I am trying to move them to the newest tree, including cache as ram. So I suggest we have this wait until I get the current tree up to date and merge that stuff in then.
what do you see as the most important issues to work on while we get CAR going everywhere?
I think we need to decide which of the LNXI patches are going to stay in as is and give them a resolved. Leaving them open maybe helps the guilty conscience of some people here but it does not get us a step ahead.
We rather need to close them and open issues describing the problems that we have _now_, like "This function is missing for all motherboard builds in this list: xxx,yyy,zzz" and then we can decide if for example CAR is an appropriate solution for the problem or if we have to add/readd a function or if we check the aruma changes in the code and try to move them to all the other mainboards as well..
when we have the tree in it's old well-known marvelous state again we should require that every patch that goes into the tree from the tracker is proven to break nothing by attaching an abuild of the whole tree before and after the patch. This is 10min work for that one developer per patch, but safes weeks for all of us.
Stefan
when we have the tree in it's old well-known marvelous state again we should require that every patch that goes into the tree from the tracker is proven to break nothing by attaching an abuild of the whole tree before and after the patch. This is 10min work for that one developer per patch, but safes weeks for all of us.
What do you plan to do for archs that need a cross compiler?
-- Richard A. Smith
Richard Smith wrote:
when we have the tree in it's old well-known marvelous state again we should require that every patch that goes into the tree from the tracker is proven to break nothing by attaching an abuild of the whole tree before and after the patch. This is 10min work for that one developer per patch, but safes weeks for all of us.
What do you plan to do for archs that need a cross compiler?
cross-compiler is a solved problem. If you are sure that your work only impacts, e.g., K8, then we can subset the build requirement.
ron
* Richard Smith smithbone@gmail.com [051123 21:26]:
when we have the tree in it's old well-known marvelous state again we should require that every patch that goes into the tree from the tracker is proven to break nothing by attaching an abuild of the whole tree before and after the patch. This is 10min work for that one developer per patch, but safes weeks for all of us.
What do you plan to do for archs that need a cross compiler?
Hm. We could put out a close description of how to build cross compilers for the suite or allow developers to submit their patches and get the results to it from the linuxbios.org machine.
Stefan
* Ronald G Minnich rminnich@lanl.gov [051123 21:28]:
Richard Smith wrote:
What do you plan to do for archs that need a cross compiler?
cross-compiler is a solved problem. If you are sure that your work only impacts, e.g., K8, then we can subset the build requirement.
I think the implicit question was: "Do we guys have to build cross compilers now for every new platform LinuxBIOS supports before we can contribute?"
And probably the question should be no, without having to check code in ;-)
Stefan
Stefan Reinauer wrote:
- Richard Smith smithbone@gmail.com [051123 21:26]:
when we have the tree in it's old well-known marvelous state again we should require that every patch that goes into the tree from the tracker is proven to break nothing by attaching an abuild of the whole tree before and after the patch. This is 10min work for that one developer per patch, but safes weeks for all of us.
What do you plan to do for archs that need a cross compiler?
Hm. We could put out a close description of how to build cross compilers for the suite or allow developers to submit their patches and get the results to it from the linuxbios.org machine.
Stefan
The thing is, it's just not possible to be casual about patches any more, as we were in the past. We've had the megapatch mess on our hands for almost 2 months, the tree is still a mess, and it's very hard to dig out. A BIOS is a much more sensitive piece of software than an operating system. You screw up the BIOS, you've got a lot of dead hardware on your hands and there is no way out. I think placing some sort of burden of proof on committers is a good idea. We've got to get this under control.
ron
I think the implicit question was: "Do we guys have to build cross compilers now for every new platform LinuxBIOS supports before we can contribute?"
And probably the question should be no, without having to check code in ;-)
So I guess you will have to have a "patch master" for each arch who will sign off that the patch did not break thier compile(s)? That or the developer would have to install the cross compiler for all the archs.
Or possibly a system like Debian has for source packages where auto builders go and try to build everything and only after it passes all archs does it get accepted. You would e-mail your patch to the autobuilder and it would spit you back a log file.
-- Richard A. Smith
Richard Smith wrote:
Or possibly a system like Debian has for source packages where auto builders go and try to build everything and only after it passes all archs does it get accepted. You would e-mail your patch to the autobuilder and it would spit you back a log file.
excellent idea.
ron
Or possibly a system like Debian has for source packages where auto builders go and try to build everything and only after it passes all archs does it get accepted. You would e-mail your patch to the autobuilder and it would spit you back a log file.
excellent idea.
This all gets you around compile problems but theres still the "Does it actually work?" issue. Somehow you have to go verify those changes actually work on the boards. Especially if your end goal is to prevent bricking the hardware.
For that you probally will need some sort of maintainer for each board or group of boards.
-- Richard A. Smith
Richard Smith wrote:
For that you probally will need some sort of maintainer for each board or group of boards.
I tried that 'board owner' thing on V1 and could NOT get it to work. We need some really convenient way for a board owner to say 'my board works with release #XXXX" so people can know what svn revs to use.
ron
* Richard Smith smithbone@gmail.com [051123 22:04]:
Or possibly a system like Debian has for source packages where auto builders go and try to build everything and only after it passes all archs does it get accepted. You would e-mail your patch to the autobuilder and it would spit you back a log file.
excellent idea.
This all gets you around compile problems but theres still the "Does it actually work?" issue. Somehow you have to go verify those changes actually work on the boards. Especially if your end goal is to prevent bricking the hardware.
Until we have a large distributed cluster of machines connected to promices we should stick to code reviews and assiduous maintainers.
Stefan
* Ronald G Minnich rminnich@lanl.gov [051123 22:06]:
Richard Smith wrote:
For that you probally will need some sort of maintainer for each board or group of boards.
I tried that 'board owner' thing on V1 and could NOT get it to work. We need some really convenient way for a board owner to say 'my board works with release #XXXX" so people can know what svn revs to use.
This is getting easier with tree wide revisions in SVN
Stefan
On Wed, Nov 23, 2005 at 02:06:34PM -0700, Ronald G Minnich wrote:
I tried that 'board owner' thing on V1 and could NOT get it to work. We need some really convenient way for a board owner to say 'my board works with release #XXXX" so people can know what svn revs to use.
How about the wiki? Although it requires a username.
This mailing list? Someone (me?) could update the wiki page.
//Peter
* Peter Stuge stuge-linuxbios@cdy.org [051124 02:59]:
On Wed, Nov 23, 2005 at 02:06:34PM -0700, Ronald G Minnich wrote:
I tried that 'board owner' thing on V1 and could NOT get it to work. We need some really convenient way for a board owner to say 'my board works with release #XXXX" so people can know what svn revs to use.
How about the wiki? Although it requires a username.
This mailing list? Someone (me?) could update the wiki page.
I think this is a great idea! We do have a page with supported motherboards already, but it tends to get outdated very easily. Having reliable information there would definitely push the project.
Stefan
On Thu, Nov 24, 2005 at 10:10:44AM +0100, Stefan Reinauer wrote:
How about the wiki? Although it requires a username. This mailing list? Someone (me?) could update the wiki page.
I think this is a great idea! We do have a page with supported motherboards already, but it tends to get outdated very easily. Having reliable information there would definitely push the project.
That page is quite long, with a lot of information missing.
I'm thinking perhaps a table with a couple of fields;
motherboard_human_name motherboard_linuxbios_name confirmed_working_svn comments
Example:
Epia-M epia-m 2100 "To enable VGA, extract VGA BIOS with dd if=.."
Should I add it to the top of that page or just make a new page?
//Peter
* Peter Stuge stuge-linuxbios@cdy.org [051124 10:54]:
That page is quite long, with a lot of information missing.
I'm thinking perhaps a table with a couple of fields;
motherboard_human_name motherboard_linuxbios_name confirmed_working_svn comments
Example:
Epia-M epia-m 2100 "To enable VGA, extract VGA BIOS with dd if=.."
Should I add it to the top of that page or just make a new page?
I'd prefer a new page which is linked from the old one. But, since you are doing the work, do what you consider best.
Stefan
On Thu, Nov 24, 2005 at 11:09:38AM +0100, Stefan Reinauer wrote:
Should I add it to the top of that page or just make a new page?
I'd prefer a new page which is linked from the old one.
I agree.
http://wiki.linuxbios.org/index.php/Confirmed_working_svn_revisions
I'll try to update it whenever I see confirmations on the list, but by all means feel free to beat me to it. :)
I took the liberty of optimizing the dd command for epia-m a bit, making it slightly less error-prone. While I cannot see why it would make any difference I would appreciate if someone could test that it does indeed work as it should. If not, I'll quickly change that back.
//Peter
On Thursday 24 November 2005 09:10, Stefan Reinauer wrote:
I think this is a great idea! We do have a page with supported motherboards already, but it tends to get outdated very easily.
<delurk> Something I've been mulling over is having some simple app that uses lshw (for example) to punt the information to some central What-Hardware-Works central brain. lshw can generate XML, so we can do some funky modern XML-based data-processing.
Perhaps this app should also allow people to put in some hand-chosen words in there. </delurk>
Cheers,
Paul.
* Paul Millar paul@astro.gla.ac.uk [051124 13:18]:
On Thursday 24 November 2005 09:10, Stefan Reinauer wrote:
I think this is a great idea! We do have a page with supported motherboards already, but it tends to get outdated very easily.
<delurk> Something I've been mulling over is having some simple app that uses lshw (for example) to punt the information to some central What-Hardware-Works central brain. lshw can generate XML, so we can do some funky modern XML-based data-processing.
Perhaps this app should also allow people to put in some hand-chosen words in there.
</delurk>
Go ahead. We could set up some service on linuxbios.org to receive such information, collect it and present it.
Can you write such a thing?
Stefan
On Thursday 24 November 2005 12:42, Stefan Reinauer wrote:
Something I've been mulling over is having some simple app that uses lshw (for example) to punt the information to some central What-Hardware-Works central brain.
Go ahead. We could set up some service on linuxbios.org to receive such information, collect it and present it.
Can you write such a thing?
Technically, yes, I believe I can. The problem is the usual: not having enough free time.
That said, I can have a look into it. What sort of information should be stored, d'ya think? There looks to be a lot of potentially useful info in there. Is any of it stuff that people are likely to consider private or sensitive?
Cheers,
Paul.
On 11/24/05, Peter Stuge stuge-linuxbios@cdy.org wrote:
On Thu, Nov 24, 2005 at 11:09:38AM +0100, Stefan Reinauer wrote:
Should I add it to the top of that page or just make a new page?
I'd prefer a new page which is linked from the old one.
I agree.
http://wiki.linuxbios.org/index.php/Confirmed_working_svn_revisions
I'll try to update it whenever I see confirmations on the list, but by all means feel free to beat me to it. :)
I suggest some sort of date updated. Perhpas the wiki does this automatically?
You may also want to add that the page is new and needs people to submit success stories. For all the viewers that hit the page that are not on the lb list.
-- Richard A. Smith
Something I've been mulling over is having some simple app that uses lshw (for example) to punt the information to some central What-Hardware-Works central
I see lshw understands OpenFirmware. What would be really cool is if it could be made to understand linuxbios tables as well.
Even more cool would be using all this data to automate the "Does LB work on my main board?" question that hits the list all the time.
The user would do an lshw and then send it to the "brain" which would report back success reports based on matching hardware. I think a fairly simple matching scheme would work.
ie: for each device in lshw tree: if exists success board rpt with matching device: append sucess report. send report
That way you would get back a listing of all boards that had at least one of your devices on them. So in the case where the board is not supported directly the user would be able to cherry pick the parts and perhaps produce the framework of a working setup.
-- Richard A. Smith
Also, it's not clear that CAR won't work on these other platforms, now that we know the "CAR trick". It has not been tested. I suspect it will work on VIA.
So what is this magical "trick." First I've heard of talk for a universal CAR.
-- Richard A. Smith
Please look at the src/cpu/amd/car..., and cache_as_ram_auto.c
only difference is for Intel need to disable Hyperthreading at first....
So if you got time, try on other platform
Because of CAR, is much fast than ROMCC, you may have some problem with timing....
YH
On 11/24/05, Richard Smith smithbone@gmail.com wrote:
Also, it's not clear that CAR won't work on these other platforms, now that we know the "CAR trick". It has not been tested. I suspect it will work on VIA.
So what is this magical "trick." First I've heard of talk for a universal CAR.
-- Richard A. Smith
-- LinuxBIOS mailing list LinuxBIOS@openbios.org http://www.openbios.org/mailman/listinfo/linuxbios
Richard Smith wrote:
On 11/24/05, Peter Stuge stuge-linuxbios@cdy.org wrote:
On Thu, Nov 24, 2005 at 11:09:38AM +0100, Stefan Reinauer wrote:
Should I add it to the top of that page or just make a new page?
I'd prefer a new page which is linked from the old one.
I agree.
http://wiki.linuxbios.org/index.php/Confirmed_working_svn_revisions
I'll try to update it whenever I see confirmations on the list, but by all means feel free to beat me to it. :)
I suggest some sort of date updated. Perhpas the wiki does this automatically?
You may also want to add that the page is new and needs people to submit success stories. For all the viewers that hit the page that are not on the lb list.
this page is really wonderful, though. It's just what we needed.
ron
Paul Millar wrote:
On Thursday 24 November 2005 09:10, Stefan Reinauer wrote:
I think this is a great idea! We do have a page with supported motherboards already, but it tends to get outdated very easily.
<delurk> Something I've been mulling over is having some simple app that uses lshw (for example) to punt the information to some central What-Hardware-Works central brain. lshw can generate XML, so we can do some funky modern XML-based data-processing.
Perhaps this app should also allow people to put in some hand-chosen words in there.
</delurk>
sure, if you want to prototype it let's take a look.
Thanks for lurking :-)
ron
Richard Smith wrote:
Also, it's not clear that CAR won't work on these other platforms, now that we know the "CAR trick". It has not been tested. I suspect it will work on VIA.
So what is this magical "trick." First I've heard of talk for a universal CAR.
-- Richard A. Smith
eswar, let's get your slides up on the wiki. I would like to get all the presentations made at linuxbios summit up there. I uploaded mine, but then couldn't figure out how to set up the links to them.
ron
Stefan Reinauer stepan@openbios.org writes:
- Richard Smith smithbone@gmail.com [051123 22:04]:
Or possibly a system like Debian has for source packages where auto builders go and try to build everything and only after it passes all archs does it get accepted. You would e-mail your patch to the autobuilder and it would spit you back a log file.
excellent idea.
This all gets you around compile problems but theres still the "Does it actually work?" issue. Somehow you have to go verify those changes actually work on the boards. Especially if your end goal is to prevent bricking the hardware.
Until we have a large distributed cluster of machines connected to promices we should stick to code reviews and assiduous maintainers.
That is part of what the fallback/normal split is about. And this is why I scream about CAR only being setup in fallback.
It isn't perfect but it should let you test 99% of everything at least to the does it boot level. If you have a working fallback you don't need a promice in your test cluster.
Eric
* Eric W. Biederman ebiederman@lnxi.com [051203 22:35]:
Until we have a large distributed cluster of machines connected to promices we should stick to code reviews and assiduous maintainers.
That is part of what the fallback/normal split is about. And this is why I scream about CAR only being setup in fallback.
It isn't perfect but it should let you test 99% of everything at least to the does it boot level. If you have a working fallback you don't need a promice in your test cluster.
I've had a funny case of the normal image failing while fallback was working fine. Unfortunately it seems the boot count was not touched. Bummer, the system stayed in normal until I flashed a new bios with the promice.
Stefan
Stefan Reinauer stepan@openbios.org writes:
- Eric W. Biederman ebiederman@lnxi.com [051203 22:35]:
Until we have a large distributed cluster of machines connected to promices we should stick to code reviews and assiduous maintainers.
That is part of what the fallback/normal split is about. And this is why I scream about CAR only being setup in fallback.
It isn't perfect but it should let you test 99% of everything at least to the does it boot level. If you have a working fallback you don't need a promice in your test cluster.
I've had a funny case of the normal image failing while fallback was working fine. Unfortunately it seems the boot count was not touched. Bummer, the system stayed in normal until I flashed a new bios with the promice.
I didn't say it was perfect only good enough for building a cluster of test machines.
As for your problem there is also the clear cmos jumper :)
Bugs in fallback happen and they suck. But for 90%+ of testing the fallback/normal works. For building a cluster of test machines I believe that is a lot more doable.
Eric
* Eric W. Biederman ebiederman@lnxi.com [051203 23:33]:
I didn't say it was perfect only good enough for building a cluster of test machines.
As for your problem there is also the clear cmos jumper :)
Bugs in fallback happen and they suck. But for 90%+ of testing the fallback/normal works. For building a cluster of test machines I believe that is a lot more doable.
optimally all of fallback handling should be in the fallback image, so no matter how bad normal is, return is always possible. Never looked all to deep into it though.. It is a great mechanism, no doubt.
Stefan
Do you mean the old cluster will only update the normal part with CAR, and don't touch the fallback part that still use romcc...?
At that case, We may need to remove the #if USE_FALLBACK_IMAGE in cache_as_ram.inc....
YH
On 12/3/05, Eric W. Biederman ebiederman@lnxi.com wrote:
Stefan Reinauer stepan@openbios.org writes:
- Richard Smith smithbone@gmail.com [051123 22:04]:
Or possibly a system like Debian has for source packages where auto builders go and try to build everything and only after it passes all archs does it get accepted. You would e-mail your patch to the autobuilder and it would spit you back a log file.
excellent idea.
This all gets you around compile problems but theres still the "Does it actually work?" issue. Somehow you have to go verify those changes actually work on the boards. Especially if your end goal is to prevent bricking the hardware.
Until we have a large distributed cluster of machines connected to promices we should stick to code reviews and assiduous maintainers.
That is part of what the fallback/normal split is about. And this is why I scream about CAR only being setup in fallback.
It isn't perfect but it should let you test 99% of everything at least to the does it boot level. If you have a working fallback you don't need a promice in your test cluster.
Eric
-- LinuxBIOS mailing list LinuxBIOS@openbios.org http://www.openbios.org/mailman/listinfo/linuxbios
Eric W. Biederman wrote:
Bugs in fallback happen and they suck. But for 90%+ of testing the fallback/normal works. For building a cluster of test machines I believe that is a lot more doable.
fallback has saved our lives more than once on 1000+ node clusters, and doubtless Eric's life too.
ron
* yhlu yinghailu@gmail.com [051204 02:14]:
Do you mean the old cluster will only update the normal part with CAR, and don't touch the fallback part that still use romcc...?
At that case, We may need to remove the #if USE_FALLBACK_IMAGE in cache_as_ram.inc....
Will this work for both cases then? If so, we should do it.
the problem is the normal may need to get init detect too...
it can not figure out to use the one passed by fallback boot or get it itself....
YH
On 12/6/05, Stefan Reinauer stepan@openbios.org wrote:
- yhlu yinghailu@gmail.com [051204 02:14]:
Do you mean the old cluster will only update the normal part with CAR, and don't touch the fallback part that still use romcc...?
At that case, We may need to remove the #if USE_FALLBACK_IMAGE in cache_as_ram.inc....
Will this work for both cases then? If so, we should do it.
-
ebiederman＠lnxi.com -
Paul Millar -
Peter Stuge -
Richard Smith -
Ronald G Minnich -
Stefan Reinauer -
yhlu