[RFC] port bochs-bios to gcc

[Kevin O'Connor]

FYI.  I'm interested in reviving the ADLO effort.  I sent the
following email to the bochs developers mailing list.

-Kevin

----- Forwarded message from Kevin O'Connor  -----

From: Kevin O'Connor 
To: [e-mail]
Date: Thu, 21 Feb 2008 22:31:28 -0500
Subject: [RFC] port bochs-bios to gcc

Hi,

I'm interested in porting the "bochs bios" code to gcc.  This is the
code currently located in the "bochs/bios/" directory - mostly in the
file "rombios.c".

I've gotten my port far enough along to boot a freedos floppy image.
There is still plenty of work to be done, but I believe I have gotten
the code to a point where I can demonstrate that the methodology is
sound.

I am looking for comments on the idea, feedback on the code, and
hopefully to spur other developer interest.

In order to use gcc to build 16 bit code, the code uses the
".code16gcc" feature of the gnu assembler (gas).  This same option is
used in the boot code of recent Linux kernels.

The code should build using standard gnu tools.  (Just untar the
package and run "make".)  I use a standard FC8 Linux machine.  The
code isn't too big, so I will try to attach it to this email.

As above, the code is in an "early alpha" state, but one should be
able to test it with an emulator.  (I tested it with qemu.)

Why do this?  My main interest is in eventually getting the code to
run on real hardware.  The current rombios.c code is rather scary - it
is about eleven thousand lines of code, of which about a third is
assembler.  I'm hoping a port to standard C will spur greater
flexibility and interest in the project.

Comments?
-Kevin

----- End forwarded message -----

[Carl-Daniel Hailfinger]

Hi Kevin,

this is a great project and I hope you succeed making the Bochs BIOS 
code more easily extensible/changeable. Please note that a substantial 
part of the code should be obsolete when run with coreboot.

Regards,
Carl-Daniel

[Kevin O'Connor]

On Fri, Feb 22, 2008 at 09:46:11PM +0100, Carl-Daniel Hailfinger wrote:
> Hi Kevin,
>
> this is a great project and I hope you succeed making the Bochs BIOS code 
> more easily extensible/changeable. Please note that a substantial part of 
> the code should be obsolete when run with coreboot.

Thanks Carl-Daniel.

I'm not aware of much overlap.  As I understand it, coreboot mostly
deals with low-level hardware initialization.  The bochs-bios was
designed to be used in an emulator and thus doesn't really bother with
hardware initialization.

Most of what is in the bochs-bios deals with implementing the legacy
bios software interrupts, building of the memory bios tables, and
loading of the OS from floppy/harddrive.

Am I missing something?

-Kevin

[Carl-Daniel Hailfinger]

On 22.02.2008 22:02, Kevin O'Connor wrote:
> On Fri, Feb 22, 2008 at 09:46:11PM +0100, Carl-Daniel Hailfinger wrote:
> > this is a great project and I hope you succeed making the Bochs BIOS code 
> > more easily extensible/changeable. Please note that a substantial part of 
> > the code should be obsolete when run with coreboot.
>
> I'm not aware of much overlap.  As I understand it, coreboot mostly
> deals with low-level hardware initialization.  The bochs-bios was
> designed to be used in an emulator and thus doesn't really bother with
> hardware initialization.
>
> Most of what is in the bochs-bios deals with implementing the legacy
> bios software interrupts, building of the memory bios tables, and
> loading of the OS from floppy/harddrive.
>
> Am I missing something?

I think I saw code to initialize the keyboard controller inside 
rombios.c. Such code would not be needed under coreboot.
Also code building memory BIOS tables is partly in coreboot and partly 
in some payloads, so there may be more overlap.

The most ideal course of action would be to fit coreboot v3 and your 
ADLO effort together. The design of v3 is still flexible and maybe we 
can stuff a payload library in v3 which has functionality like 
generation of e820 tables etc. That would save payload authors from 
duplicating code needlessly.

Regards,
Carl-Daniel

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
> The most ideal course of action would be to fit coreboot v3 and your 
> ADLO effort together. The design of v3 is still flexible and maybe we 
> can stuff a payload library in v3 which has functionality like 
> generation of e820 tables etc. That would save payload authors from 
> duplicating code needlessly.

I wonder whether we would want to create e820 tables directly in 
coreboot, instead of putting it into a payload library.
It's something every OS needs, and requiring a payload to call a 
function like "make_e820_from_cbtable()" unconditionally makes little 
sense.  As a comparison, we don't leave pirq, mptable and ACPI to the 
payload, either. Making e820 an exception here is one of the design 
inconsitencies we are suffering from. It also bites a couple of 
projects, like open firmware on coreboot. Torsten Duwe ran into funny 
issues here.

Stefan

[ron minnich]

I think we should generate e820 and it would not be hard ..

ron

[Kevin O'Connor]

On Sat, Feb 23, 2008 at 02:55:54PM +0100, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
> > The most ideal course of action would be to fit coreboot v3 and your ADLO 
> > effort together. The design of v3 is still flexible and maybe we can stuff 
> > a payload library in v3 which has functionality like generation of e820 
> > tables etc. That would save payload authors from duplicating code 
> > needlessly.
>
> I wonder whether we would want to create e820 tables directly in coreboot, 
> instead of putting it into a payload library.
> It's something every OS needs, and requiring a payload to call a function 
> like "make_e820_from_cbtable()" unconditionally makes little sense.  As a 
> comparison, we don't leave pirq, mptable and ACPI to the payload, either.

I think it would be great if coreboot built the e820 info.

I do wonder... if coreboot builds pirq, mptable, ACPI, and e820
tables.  Why not have it also populate that other bios "table" - the
64K one at 0xf0000-0xfffff?

-Kevin

[Peter Stuge]

On Sun, Feb 24, 2008 at 01:34:29PM -0500, Kevin O'Connor wrote:
> I do wonder... if coreboot builds pirq, mptable, ACPI, and e820
> tables.  Why not have it also populate that other bios "table" -
> the 64K one at 0xf0000-0xfffff?

If by "table" you mean code the answer is that coreboot does not like
callbacks by design.

Otherwise I guess we have to store legacy data struct wherever they
can be found.

//Peter

[Jun Koi]

Hi Kevin,

On 2/22/08, Kevin O'Connor  wrote:
> FYI.  I'm interested in reviving the ADLO effort.  I sent the
>  following email to the bochs developers mailing list.

I think one of the reasons why they wrote the BIOS in asm is because
it makes the result code small, as the size is limited in 64KB. What
do you do to make sure that the ported code stays within the limit?

Even if it is now, how about future, when you want to add more code?

Thanks,
Jun

[Jun Koi]

On 2/25/08, Jun Koi  wrote:
> Hi Kevin,
>
> On 2/22/08, Kevin O'Connor  wrote:
> > FYI.  I'm interested in reviving the ADLO effort.  I sent the
> >  following email to the bochs developers mailing list.

I looked at the code, and found a lot of tricks there. Interesting! I
just wonder where the __start symbol is defined? (which you use it to
fix the jump at set_entry32)

Thanks,
J

[Jun Koi]

On 2/25/08, Jun Koi  wrote:
> On 2/25/08, Jun Koi  wrote:
> > Hi Kevin,
> >
> > On 2/22/08, Kevin O'Connor  wrote:
> > > FYI.  I'm interested in reviving the ADLO effort.  I sent the
> > >  following email to the bochs developers mailing list.
>
> I looked at the code, and found a lot of tricks there. Interesting! I
>  just wonder where the __start symbol is defined? (which you use it to
>  fix the jump at set_entry32)

Hmm somehow I missed it: that is the _start in romlayout.S. But then
the question is: why the _start code jump back to itself at start
up???

Thanks,
J

[Jun Koi]

On 2/25/08, Jun Koi  wrote:
> On 2/25/08, Jun Koi  wrote:
> > On 2/25/08, Jun Koi  wrote:
> > > Hi Kevin,
> > >
> > > On 2/22/08, Kevin O'Connor  wrote:
> > > > FYI.  I'm interested in reviving the ADLO effort.  I sent the
> > > >  following email to the bochs developers mailing list.
> >
> > I looked at the code, and found a lot of tricks there. Interesting! I
> >  just wonder where the __start symbol is defined? (which you use it to
> >  fix the jump at set_entry32)
>
> Hmm somehow I missed it: that is the _start in romlayout.S. But then
>  the question is: why the _start code jump back to itself at start
>  up???

Ah, now I see what happens. The -fwhole-program --combine option
really confuses me!

An idea: the BIOS code is not only used by Bochs, but others as well
(qemu and Xen come first in my mind). So how about maintaining it
separately from Bochs code? That makes patches to be merged quickly
than it should be, and new versions should be released more quickly,
too.

Thanks,
J

[Stefan Reinauer]

Peter Stuge wrote:
> On Sun, Feb 24, 2008 at 01:34:29PM -0500, Kevin O'Connor wrote:
> > I do wonder... if coreboot builds pirq, mptable, ACPI, and e820
> > tables.  Why not have it also populate that other bios "table" -
> > the 64K one at 0xf0000-0xfffff?
>
> If by "table" you mean code the answer is that coreboot does not like
> callbacks by design.
>
> Otherwise I guess we have to store legacy data struct wherever they
> can be found.

One thing though:

I do believe we should merge what we call ADLO as another loader into 
v3. Augusto Pedroza wrote a patch for that for GSoC iirc.

Just like we have ELF loading and lar segment loading and VSA loading now.

Maybe we could even use the VSA loader to run bochs bios, instead of 
ADLO? It's all 16bit lumber ;)

Then using BIOS compatibility would just mean putting a bochsbios.bin 
into the lar.

ADLO is so fragile because it was written in assembler (so no stack is 
needed?!?), reimplementing all the things we have in coreboot in C. So 
recognizing that it just another loader would simplify and stabilize 
things quite a bit.

Someone might say we can do this with libpayload or by adding a lot of 
chipset specific code to ADLO and rewrite it from scratch. Then we're at 
2500 lines of code instead of 25 and we have a nasty multi-staging.

Stefan

[Stefan Reinauer]

Jun Koi wrote:
> Hi Kevin,
>
> On 2/22/08, Kevin O'Connor  wrote:
> > FYI.  I'm interested in reviving the ADLO effort.  I sent the
> >  following email to the bochs developers mailing list.
>
> I think one of the reasons why they wrote the BIOS in asm is because
> it makes the result code small, as the size is limited in 64KB. What
> do you do to make sure that the ported code stays within the limit?

plus, some addresses in those 64k are hard wired to specific interrupt 
handlers. Quite some code out there assumes this.

It's still possible, but it wont be completely clean and easy.

[Jun Koi]

On 2/25/08, Stefan Reinauer  wrote:
> Jun Koi wrote:
> > Hi Kevin,
> >
> > On 2/22/08, Kevin O'Connor  wrote:
> > > FYI.  I'm interested in reviving the ADLO effort.  I sent the
> > >  following email to the bochs developers mailing list.
> >
> > I think one of the reasons why they wrote the BIOS in asm is because
> > it makes the result code small, as the size is limited in 64KB. What
> > do you do to make sure that the ported code stays within the limit?
>
> plus, some addresses in those 64k are hard wired to specific interrupt
>  handlers. Quite some code out there assumes this.

Kevin solved that by putting some in asm (romlayout.S)
> It's still possible, but it wont be completely clean and easy.

Yes, but now the asm code significantly reduced!

The curent code is not complete, but looks pretty clean. This is
definitely way to go. Keep it up, Kevin!

Thanks,
J

[Carl-Daniel Hailfinger]

On 25.02.2008 10:44, Stefan Reinauer wrote:
> I do believe we should merge what we call ADLO as another loader into 
> v3. Augusto Pedroza wrote a patch for that for GSoC iirc.
>
> Just like we have ELF loading and lar segment loading and VSA loading 
> now.
>
> Maybe we could even use the VSA loader to run bochs bios, instead of 
> ADLO? It's all 16bit lumber ;)
>
> Then using BIOS compatibility would just mean putting a bochsbios.bin 
> into the lar.
>
> ADLO is so fragile because it was written in assembler (so no stack is 
> needed?!?), reimplementing all the things we have in coreboot in C. So 
> recognizing that it just another loader would simplify and stabilize 
> things quite a bit.
>
> Someone might say we can do this with libpayload or by adding a lot of 
> chipset specific code to ADLO and rewrite it from scratch. Then we're 
> at 2500 lines of code instead of 25 and we have a nasty multi-staging.

There is another possibility: Use the recently published official 
documents about the data expected by NTLDR and successors. While this 
does not help the *BSD use of ADLO, the Windows use of it could be 
scrapped and we'd probably end up with a lot less code than what ADLO is 
now.

Comments?

Regards,
Carl-Daniel

[Stefan Reinauer]

Carl-Daniel Hailfinger wrote:
> There is another possibility: Use the recently published official 
> documents about the data expected by NTLDR and successors.

I think the ReactOS loader uses this information. It can load several 
commercial versions of Windows meanwhile.

If someone from the coreboot community could help the reactos 
developers, I think they would be eager too, to see their bootloader 
load windows on top of coreboot.
> While this does not help the *BSD use of ADLO, the Windows use of it 
> could be scrapped and we'd probably end up with a lot less code than 
> what ADLO is now.

I doubt that. ADLO is now 461 lines of assembler code. Most of which is 
comments. That is only for a single platform, because it really is a 
hack. When integrating this loader, it would become saner at almost no cost.

While I think using our own NTLDR is an option for the problem of 
booting windows, we should also think about having a sane way of 
integrating 16bit bios calls. Otherwise we will not get the chance to be 
the default firmware on motherboards out there. Even EFI systems do that.

Stefan

[Jun Koi]

On 2/22/08, Kevin O'Connor  wrote:
> FYI.  I'm interested in reviving the ADLO effort.  I sent the
>  following email to the bochs developers mailing list.
>
> -Kevin

I compiled the 0.1.1 version, and got errors like below:

mkdir out
  Generating whole program assembler out/blob.16.s
In file included from src/disk.c:10:
src/util.h:58: error: conflicting types for '__debug_enter'
src/util.h:58: error: previous declaration of '__debug_enter' was here
src/util.h:59: error: conflicting types for '__debug_exit'
src/util.h:59: error: previous declaration of '__debug_exit' was here
.....

I am on Ubuntu 7.10, gcc 4.1.3

Thanks,
J

[Kevin O'Connor]

On Mon, Feb 25, 2008 at 07:41:56PM +0900, Jun Koi wrote:
> On 2/22/08, Kevin O'Connor  wrote:
> > FYI.  I'm interested in reviving the ADLO effort.  I sent the
> >  following email to the bochs developers mailing list.
> >
> > -Kevin
>
> I compiled the 0.1.1 version, and got errors like below:
>
> mkdir out
>   Generating whole program assembler out/blob.16.s
> In file included from src/disk.c:10:
> src/util.h:58: error: conflicting types for '__debug_enter'
> src/util.h:58: error: previous declaration of '__debug_enter' was here
> src/util.h:59: error: conflicting types for '__debug_exit'
> src/util.h:59: error: previous declaration of '__debug_exit' was here
> .....
>
> I am on Ubuntu 7.10, gcc 4.1.3

Hi Jun,

I'll take a look at this later tonight (along with your other
questions).

I have been placing my most recent work at:

http://linuxtogo.org/~kevin/legacybios/

Indeed, I just pushed a 0.1.2 tar file.  I agree this needs to be
moved to source control - I just need to find a home.

Thanks for looking at this.
-Kevin

[Kevin O'Connor]

On Sun, Feb 24, 2008 at 08:30:50PM +0100, Peter Stuge wrote:
> On Sun, Feb 24, 2008 at 01:34:29PM -0500, Kevin O'Connor wrote:
> > I do wonder... if coreboot builds pirq, mptable, ACPI, and e820
> > tables.  Why not have it also populate that other bios "table" -
> > the 64K one at 0xf0000-0xfffff?
>
> If by "table" you mean code the answer is that coreboot does not like
> callbacks by design.

Well, it wouldn't be coreboot that got the callbacks, it would be that
binary blob at 0xf0000.

Seriously though, I don't think implementing the real-mode irq
handlers is that technically challenging - I'd guess it is no harder
than implementing filo was.  The calling interface is stable -
implement it once and there's not likely to be a lot of maintenance.

So, I'd look at it as coreboot initializing and loading another
"table" at a certain area of memory.  Some OSs will make use of it -
others wont.  I don't see a lot of down sides to deploying it.

The big upside is that, with the proper handlers, all modern OSes will
load out of the box.  This will be a big selling point to hardware
vendors - especially those that want to deploy a single solution for
both mass-market and niche markets.

-Kevin

[Kevin O'Connor]

On Mon, Feb 25, 2008 at 10:44:55AM +0100, Stefan Reinauer wrote:
> Maybe we could even use the VSA loader to run bochs bios, instead of ADLO? 
> It's all 16bit lumber ;)

Hi Stefan,

ADLO is a fork of the bochs bios - so, they're really the same thing.
There are some new things added to bochs-bios (for example, acpi table
creation), so I've decided to start with it.

I plan to have a 32-bit entry point for the code, so I don't think any
special loader is needed.  Just load it in ram and jump to it.
> ADLO is so fragile because it was written in assembler (so no stack is 
> needed?!?), reimplementing all the things we have in coreboot in C. So 
> recognizing that it just another loader would simplify and stabilize things 
> quite a bit.

ADLO (and the bochs bios) is using the bcc compiler.  The code itself
is a mix of C and 16bit assembler.  The code uses the stack liberally
so that's not a reason for using assembler.

Also, I don't really see a lot of overlap between coreboot and
bochs-bios.  The former seems more interested in initializing
hardware, while the latter is primarily implementing real-mode
callbacks.  I see more overlap between filo and bochs-bios.
> Someone might say we can do this with libpayload or by adding a lot of 
> chipset specific code to ADLO and rewrite it from scratch. Then we're at 
> 2500 lines of code instead of 25 and we have a nasty multi-staging.

I don't see a 16bit bios needing a lot of chipset specific code.
Sure, the bios needs to access the harddrives, keyboard, rtc, etc..
However, it only needs to implement basic PIO support, and most
hardware vendors implement a backwards compatibility mode for these
devices.

-Kevin

[Kevin O'Connor]

On Mon, Feb 25, 2008 at 10:50:17AM +0100, Stefan Reinauer wrote:
> plus, some addresses in those 64k are hard wired to specific interrupt 
> handlers. Quite some code out there assumes this.
>
> It's still possible, but it wont be completely clean and easy.

Hi Stefan,

Implemeting the hardcoded memory addresses is not as hard as it
sounds.  All the hardcoded addresses (at least the ones implemented by
bochs) are in the last 8K of the bios.  So, you just need to make sure
the C code fits in the first 54K.  A simple assembler file can then
put trampolines at the fixed addresses.

As Jun points out, I've already done this.

-Kevin

[Kevin O'Connor]

On Mon, Feb 25, 2008 at 06:25:14PM +0900, Jun Koi wrote:
> On 2/25/08, Jun Koi  wrote:
> > Hmm somehow I missed it: that is the _start in romlayout.S. But then
> >  the question is: why the _start code jump back to itself at start
> >  up???
>
> Ah, now I see what happens. The -fwhole-program --combine option
> really confuses me!

Hi Jun,

The code is entered in 16bit mode at ffff:fff0 (romlayout.S) - it then
jumps to "post16" in romlayout.S.  The code there transitions the CPU
to 32bit mode and jumps to _start in post.c.  After we initilize
everything, the cpu is transitioned back to 16bit mode and an "int
0x19" is executed to start the standard boot process.

The _start in romlayout.S is confusing - I put it there to silence a
linker warning.  I'll clean that up.

-Kevin

[Kevin O'Connor]

On Mon, Feb 25, 2008 at 01:35:18PM +0900, Jun Koi wrote:
> Hi Kevin,
>
> On 2/22/08, Kevin O'Connor  wrote:
> > FYI.  I'm interested in reviving the ADLO effort.  I sent the
> >  following email to the bochs developers mailing list.
>
> I think one of the reasons why they wrote the BIOS in asm is because
> it makes the result code small, as the size is limited in 64KB. What
> do you do to make sure that the ported code stays within the limit?
>
> Even if it is now, how about future, when you want to add more code?

Hi Jun,

My plan was to move all of the initialization code to 32bit mode.
That is why the first thing the code does is transition to 32bits.
The init code could then be relocated to anywhere in ram.  That would
leave the entire 0xf0000 block available for the real-mode irq
handlers.

That said, I'm finding the gcc generated code to be significantly
smaller than the existing code.  I figure I'm more than half way
through porting of features, and I've used only about a fourth of the
available space.

-Kevin

[Peter Stuge]

On Mon, Feb 25, 2008 at 07:29:15PM -0500, Kevin O'Connor wrote:
> > If by "table" you mean code the answer is that coreboot does not
> > like callbacks by design.
>
> Well, it wouldn't be coreboot that got the callbacks, it would be
> that binary blob at 0xf0000.

..
> Seriously though, I don't think implementing the real-mode irq
> handlers is that technically challenging

No, certainly not. However, I think that coreboot being legacy-free
is a very important, if not the most important, feature.

Yes, there is a transition period where some systems need a legacy
layer in order to start up, but I really want that to be distinct
from coreboot.
> So, I'd look at it as coreboot initializing and loading another
> "table" at a certain area of memory.

I draw the line at code (hence my dislike for ACPI and VSA) and had
this in fact been nothing but a table I would not mind, but since it
is code I think it should never be closer to coreboot than being a
payload.
> Some OSs will make use of it - others wont.  I don't see a lot of
> down sides to deploying it.

It would always be present, regardless of whether an OS does make
use of it or not. It would waste resources and be generally unclean.
Worst-case it would cause conflicts or confusion.
> The big upside is that, with the proper handlers, all modern OSes
> will load out of the box.  This will be a big selling point to
> hardware vendors - especially those that want to deploy a single
> solution for both mass-market and niche markets.

I consider the BIOS interface to be useless for new systems and I
don't want to further expanded BIOS use in any way.

Your point is crystal clear, and I completely agree that at present
there simply must be a way to get these legacy interfaces.

I certainly appreciate you reviving ADLO and your effort with
bochs-bios, but I do not want it included and always-on.

//Peter

[Peter Stuge]

On Mon, Feb 25, 2008 at 10:44:55AM +0100, Stefan Reinauer wrote:
> I do believe we should merge what we call ADLO as another loader
> into v3. Augusto Pedroza wrote a patch for that for GSoC iirc.

I like this a lot! In v2 I guess the loader (but not bochs-bios)
would always be included and in v3 it would be controlled by Kconfig.
> Maybe we could even use the VSA loader to run bochs bios, instead
> of ADLO? It's all 16bit lumber ;)

That would be nice.
> Then using BIOS compatibility would just mean putting a
> bochsbios.bin into the lar.

Perfect!
> recognizing that it just another loader would simplify and
> stabilize things quite a bit.

Agreed.

//Peter

[Kevin O'Connor]

On Mon, Feb 25, 2008 at 11:14:33AM +0100, Stefan Reinauer wrote:
> > While this does not help the *BSD use of ADLO, the Windows use of it could 
> > be scrapped and we'd probably end up with a lot less code than what ADLO 
> > is now.
>
> I doubt that. ADLO is now 461 lines of assembler code. Most of which is 
> comments. That is only for a single platform, because it really is a hack. 
> When integrating this loader, it would become saner at almost no cost.

I think I misunderstood some of your emails.  You consider ADLO just
the loader - I was thinking of ADLO as the loader plus the modified
bochs bios.

The mainline bochs bios is already using some 32bit code, so I don't
think we need a special loader just for that.  Getting the blob into
0xf0000 might require some hardware tricks though (to enable/disable
shadowing).

-Kevin

[Stefan Reinauer]

* Kevin O'Connor  [080225 15:03]:
> I'll take a look at this later tonight (along with your other
> questions).
>
> I have been placing my most recent work at:
>
> http://linuxtogo.org/~kevin/legacybios/
>
> Indeed, I just pushed a 0.1.2 tar file.  I agree this needs to be
> moved to source control - I just need to find a home.

We'd be glad to host the project on coreboot.org, if you wish.

Stefan

[Kevin O'Connor]

On Sun, Mar 02, 2008 at 01:12:55PM +0100, Stefan Reinauer wrote:
> > Indeed, I just pushed a 0.1.2 tar file.  I agree this needs to be
> > moved to source control - I just need to find a home.
>
> We'd be glad to host the project on coreboot.org, if you wish.
>
> Stefan

Hi Stefan,

I've got a temporary location using git at http://git.linuxtogo.org/
After I've finished porting the code, I'll look for a permanent home.
Thanks for the offer - it sounds like a good idea.

-Kevin

P.S. things are moving along.  I've ported disk access and can boot
Linux under qemu.