linuxbios build problems

Eric W. Biederman ebiederman at lnxi.com
Wed Feb 12 02:44:00 CET 2003


"Steve M. Gehlbach" <steve at nexpath.com> writes:

> > > more summary: the problem is limited to those cases where someone
> > > wants to
> > > use SERIAL_POST.
> > >
> > > Seems pretty fixable.
> > >
> >
> > Any more ideas on this?  I chased it around a bit but there sure
> > seems to be
> > a symbol conflict on _start.
> >
> 
> Okay I see the point, these are separate pieces of code.  Looks like the
> post is inlined unless SERIAL_POST is set, at which point console_tx_al is
> called in crt0.  The address of console_tx_al is not fixed at the point
> c_start.o is linked.  Not easy to fix, maybe someone else has some ideas.

O.k. I believe I see what is going on.

When CONFIG_COMPRESS was introduced intel_chip_post simply yielded
a post code.  So it was safe to call it both from both binaries.

Then someone modified intel_chip_post to change it's behavior
when SERIAL_POST is called to output the post code to the serial port.

That is so bad, and broken.

It breaks the compile of c_start.S because it attempts to call code
in another binary.  It potentially breaks all callers of intel_chip_post
because the set of registers stomped has gone from %al to:
%eax %esp %edx  

Extremely unexpected.

If we want post codes to show up on the serial port even from the assembly
code we need to introduce another macro, and carefully replace the users
of intel_chip_post.  Rather than change the calling conventions of
intel_chip_post.

So for the short term the proper fix is to revert the recent change
to intel_chip_post....

Eric




More information about the coreboot mailing list