[LinuxBIOS] LInuxBIOSv3 - Reset and CAR code

Juergen Beisert juergen127 at kreuzholzen.de
Sat May 19 12:00:53 CEST 2007


Hi Stefan,

On Saturday 19 May 2007 11:08, Stefan Reinauer wrote:
> * Juergen Beisert <juergen127 at kreuzholzen.de> [070519 10:43]:
> > What do you mean with "old toolchains"? How old? I made some local
> > changes to support my Geode GX1 and I would try it also with older
> > toolchains (currently I'm working with a 4.1.2 cross toolchain).
>
> Some current red hat eh fedore versions I think. No idea. Never had the
> issue.
>
> > > So we changed it. Now it is exactly as fragile, but it is one fragile
> > > mess, not three of them.
> >
> > My question is: What is fragile in this code? To get the correct opcodes
> > from the assembler instructions? To link this code to correct fixed
> > addresses? To get correct binary sizes? Problems with mirroring 0xF0000
> > and 0xFFFF0000?
>
> Mostly to mix 32bit and 16bit code and still get the offsets in the
> jumps right. Check and see how we do db 0xe9 and then add a fake offset
> manually. I hate that code.

I know this problem.

> > > The overhead of the reset vector and switching to protected mode before
> > > you enable CAR is 17 instructions (roughly). While you could factor
> > > that out, it is at the border between moving the complexity from one
> > > side (1 big file) to the other (composing several files and watching
> > > the code flow) and the philosophic unseemliness of having to duplicate
> > > 17 instructions per cpu type.
> >
> > IMHO its not a question of "small code, no matter if duplicated". Its a
> > matter of code quality: Its open source.
>
> Exactly. And code quality does not gain from splitting a single small
> task into 5 different files. We had that in v2, and nobody would
> understand it. stage0_xxx.S is something that never ever gets touched
> once it is written for a new CPU.

And if you try to support a new CPU? Where to start? Copying one of the 
existing stage0_xxx.S and modifying until it works? ("Debug into existence")

> How does code quality improve when you 
> make three files out of it?

Assembler is always very specific. So one file for one dedicated function. The 
buildsystem is responsible to select and combine the right ones.

> > Such current code I saw in many other closed source projects (a colleague
> > calls it "Industrial Code Quality"). I believe we could make it better.
>
> It was better. We changed it back. But feel free to offer a patch or a
> terse description on improvement ideas.
>
> LinuxBIOS is far better than "industrial code quality", if you ever had
> to read industrial bios code.

I did, yes :-)

> > > We're not a toolchain project, so we probably have to live with it ;)
> >
> > Would it help, if we do our work with one or more reference toolchain(s)?
> > GCC3.x, GCC4.x and so on? (*real* cross toolchains).
>
> Well yes and no. It works because then we have three code lines that
> noone ever touches can be made to look like sugar.

No! We will win reproducibility and reliability!

> On the other hand it does not work because everybody would have to start
> building cross tool chains and we dont have enough people supporting
> them with their problems in this project.

The question is: Will this increase or decrease user's problems to work with 
LinuxBIOS? So can we have the focus on real hardware issues or have to waste 
time to worry about broken toolchains? Yes, the preparation needs more time, 
but after it we could start with the real job.

> I am not convinced that the gain is worth the effort.
>
> Any ideas to change that are welcome!!!

 - reference toolchain(s)
 - documentation, the fragile a part is the more documentation it needs

I offer to work on both.

Juergen




More information about the coreboot mailing list