[LinuxBIOS] issue 20, island aruma update

[Ronald G Minnich]

      stepan, this one looks harmless to me, any changes since you submitted a 
month ago?

ron

[Stefan Reinauer]

      * Ronald G Minnich <rminnich(a)lanl.gov&gt; [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

[Ronald G Minnich]

      Stefan Reinauer wrote:
  * Ronald G Minnich <rminnich(a)lanl.gov&gt; [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

[Richard Smith]

 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

[Ronald G Minnich]

      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

[Richard 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

[yhlu]

      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(a)gmail.com&gt; 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(a)openbios.org
 http://www.openbios.org/mailman/listinfo/linuxbios

[Ronald G Minnich]

      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]

      * Ronald G Minnich <rminnich(a)lanl.gov&gt; [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

[Richard Smith]

  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

[Ronald G Minnich]

      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

[Stefan Reinauer]

      * Ronald G Minnich <rminnich(a)lanl.gov&gt; [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

[Richard Smith]

  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

[Ronald G Minnich]

      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

[Richard Smith]

  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

[Ronald G Minnich]

      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

[Stefan Reinauer]

      * Ronald G Minnich <rminnich(a)lanl.gov&gt; [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

[Peter Stuge]

      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

[Stefan Reinauer]

      * Peter Stuge <stuge-linuxbios(a)cdy.org&gt; [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

[Peter Stuge]

      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

[Stefan Reinauer]

      * Peter Stuge <stuge-linuxbios(a)cdy.org&gt; [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

[Peter Stuge]

      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

[Richard Smith]

      On 11/24/05, Peter Stuge <stuge-linuxbios(a)cdy.org&gt; 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

[Ronald G Minnich]

      Richard Smith wrote:
  On 11/24/05, Peter Stuge
<stuge-linuxbios(a)cdy.org&gt; 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]

      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.

[Stefan Reinauer]

      * Paul Millar <paul(a)astro.gla.ac.uk&gt; [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

[Paul Millar]

      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.

[Richard 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

[Ronald G Minnich]

      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

[Stefan Reinauer]

      * Richard Smith <smithbone(a)gmail.com&gt; [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

      Stefan Reinauer <stepan(a)openbios.org&gt; writes:

  * Richard Smith <smithbone(a)gmail.com&gt; [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

[Stefan Reinauer]

      * Eric W. Biederman <ebiederman(a)lnxi.com&gt; [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(a)openbios.org&gt; writes:

  * Eric W. Biederman <ebiederman(a)lnxi.com&gt;
[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

[Stefan Reinauer]

      * Eric W. Biederman <ebiederman(a)lnxi.com&gt; [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

[Ronald G Minnich]

      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]

      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(a)lnxi.com&gt; wrote:
  Stefan Reinauer <stepan(a)openbios.org&gt; writes:

  * Richard Smith <smithbone(a)gmail.com&gt;
[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(a)openbios.org
 http://www.openbios.org/mailman/listinfo/linuxbios

[Stefan Reinauer]

      * yhlu <yinghailu(a)gmail.com&gt; [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.

[yhlu]

      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(a)openbios.org&gt; wrote:
  * yhlu <yinghailu(a)gmail.com&gt; [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.

[Stefan Reinauer]

      * Richard Smith <smithbone(a)gmail.com&gt; [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]

      Stefan Reinauer wrote:
  * Richard Smith <smithbone(a)gmail.com&gt; [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