[LinuxBIOS] LInuxBIOSv3 - Reset and CAR code

[Juergen Beisert]

Hi Stefan,

On Friday 18 May 2007 23:56, Stefan Reinauer wrote:
> * Juergen Beisert <juergen127 at kreuzholzen.de> [070518 20:53]:
> > currently I'm trying to understand how it works in assembly until C
> > starts. Could we divide the stage0_i586.S file into its three parts?
> > Resetvector, Jump to protected mode and the CAR code? Maybe it would be
> > easier to understand and to maintain.
>
> If you look in the history of linuxbiosv3 (ie via linuxbios.org/viewvc)
> you will find that that is the way I implemented it. While this worked
> fine with new binutils and compiler, some old toolchains terribly broke
> this when you start to change small things. It was very fragile.

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

> 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? A 
few years ago I made a BIOS replacement for a SC520 CPU (486). Same way: 
Small real mode code, switching to PM immediately, setup cache as RAM and all 
the rest was done in C. In this project the linker was the key to get simple 
and working code.

> > With my GeodeGX1 systems I cannot use the mtrr registers to get some
> > memory from the cache. To replace it a complete new file would be
> > required. Maybe it would be better to support different methods how to
> > get CAR and link them on demand?
>
> 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.
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.

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

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

Juergen