[LinuxBIOS] LInuxBIOSv3 - Reset and CAR code

[Stefan Reinauer]

* 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.
 
> > 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. How does code quality improve when you
make three files out of it?

> 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 don't really like the way it is done at the moment, working around
> > weird bugs instead of fixing them, and I do quite some ironing out of
> > the weird hacks in "lar".
> 
> No chance to fix it upstream? Thats our way: Don't patch every new release, 
> send the patches upstream.
 
In binutils you mean?

We do, and they keep introducing new bugs, because the gnu toolchain is
not made for bios development but for high level os stuff. We misuse it
for a different purpose, and we have to pay the price.

> > 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.

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.

I am not convinced that the gain is worth the effort. 

Any ideas to change that are welcome!!!

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de  • http://www.coresystems.de/