Ram initialization and small c.

[Eric W. Biederman]

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On 12 Feb 2003, Eric W. Biederman wrote:
> 
> > Ron.  I am going to need to do a branch soon as I do the Hammer
> > port and integrate a small C compiler.  And I want to make some
> > clean fixes and remove some of the backwards compatibility cruft, and
> > the linuxbios 1.0 code base is an inappropriate place to target.
> > It should be possible to roll in most of the improvements into the 1.0
> > codebase, but that will just increase the clutter of the codebase.
> 
> OK, but be aware that a person here is doing the PPC port, so we'll need 
> to see how to keep him up-to-date with what you're doing. 

I intend to be as public as I can about it, so the LinuxBIOS list
should work.

> Although the PPC code is mostly C, since the cache-as-ram trick is 
> actually well-supported and working on that architecture. 

Yes, which is one of the things that encouraged me to try it.

> We don't want to drop too many mainboards off the edge in the long term.

Agreed. But at the same time our code base is such that hardwaremain()
is not as fixed as it should be.  Which means that without great care
things break.  

> 
> A branch would be a good place to fix up support for multiple south and 
> north bridges.

I have to.  Multiple identical northbridges, and southbridges will
actually be quite common on the Hammer architecture.  I actually have
a fix present in the pci code to detect and handle these but I have
not currently pushed the code.

What I expect is that initially everything will work in the 1.0
codebase but only a subset will work with the 2.0 codebase.  At the
same time a goal of the 2.0 codebase is that the infrastructure should
be clean enough that we don't have to keep continually modifying it
and breaking things when more boards are brought online.

Ron I don't know how to manage it but we need to setup a system where
we have releases of the core codebase.   And one of the tasks of
doing a release need to be to review the changes that went in since
the last release so we can avoid things like a broken intel_chip_post
macro.  Having code like that temporarily in CVS is fine.  In the core
that is a pain.

The way I expect developers to work is that they start with a stable
release of the core, do a port.  And the occasionally update to a
later core.  And when the code is on an uptodate core submitting code
back to the core LinuxBIOS tree.

That roughly seems to fit how Tyson and other embedded guys work, and
how I do ports I can support.  The problem with submitting code back
right now is that the CVS tree is a moving target.  And I am very very
cautious about importing it into my tree as it may break something, on
a port I support.

Eric