status information

Eric W. Biederman ebiederman at
Thu Oct 28 18:01:01 CEST 2004

Li-Ta Lo <ollie at> writes:

> On Thu, 2004-10-28 at 08:14, Ronald G. Minnich wrote:
> > On Thu, 28 Oct 2004, Eric W. Biederman wrote:
> > 
> > > I will (hopefully) commit later today, but I have found one general
> > > technique that will cut down the code size but a small amount.
> > > In the chip_operations struct we have a name for debugging.
> > > Since we are no longer printing that name there is no point in
> > > keeping it.
> > 
> > hmm, this sounds like a lot of potential pain for a small gain. Can we 
> > talk about this a bit first. 
> > 
> Some points I didn't make clear during the LNXI visit about the size 
> problem are:
> 	1. Virtually no one is putting the kernel in the FLASH ROM,
> 	   people use CF instead. Every payload/bootloader we are
> 	   using can support that.

With kexec finally in the kernel and a knowledge of what is needed
to keep kernel size under control and an availability of 1MiB flash
parts, it is my intention to start soon.  But it requires a moment
to breath.  What seems clear is that while we have hit a plateau with
a working set of bootloaders we need to do something better.

As for CF.  I guess I have only seen LANL doing that, and it
seems a little unsatisfactory.  There is no reason why beoboot
needs that much space for example.

> 	2. The size of FLASH grows exponentially if there is no stupid
> 	   limitation such as address lines in DIP32 package. Currently
> 	   LinuxBIOS only grows linearly. 

Hmm.  I don't have enough data points to support that yet. 

Currently romcc makes code that is 3x larger but more maintainable.
512KiB flash parts seem to be the norm for server boards.
Although I think I have sighted 1MiB parts in the wild.

Still my fallback image size has already moved from 64KiB to 128KiB.
And I really don't want to see it get much larger...

> So why can not we relax the 64kB limit of LinuxBIOS ? 

If we can still set an arbitrary limit when we rearrange the
code I don't have a problem.  For the current set of ports I don't
need to and I would rather trim a little fat then to push things
very far.  

One of the challenges is that to keep the flashing sane the fallback
image needs to fall nicely on flash block boundaries.  Which are
64KiB in the worst case.

> I do think removing the name of the device is a wrong direction.

It is wrong to remove the unused name of the chip?


More information about the coreboot mailing list