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 kevin@koconnor.net -----
From: Kevin O'Connor kevin@koconnor.net To: bochs-developers@lists.sourceforge.net 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 -----
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
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
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
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
I think we should generate e820 and it would not be hard ..
ron
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
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
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
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
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
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
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
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
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
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
Hi Kevin,
On 2/22/08, Kevin O'Connor kevin@koconnor.net 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
On 2/25/08, Jun Koi junkoi2004@gmail.com wrote:
Hi Kevin,
On 2/22/08, Kevin O'Connor kevin@koconnor.net 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
On 2/25/08, Jun Koi junkoi2004@gmail.com wrote:
On 2/25/08, Jun Koi junkoi2004@gmail.com wrote:
Hi Kevin,
On 2/22/08, Kevin O'Connor kevin@koconnor.net 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
On 2/25/08, Jun Koi junkoi2004@gmail.com wrote:
On 2/25/08, Jun Koi junkoi2004@gmail.com wrote:
On 2/25/08, Jun Koi junkoi2004@gmail.com wrote:
Hi Kevin,
On 2/22/08, Kevin O'Connor kevin@koconnor.net 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
On Mon, Feb 25, 2008 at 06:25:14PM +0900, Jun Koi wrote:
On 2/25/08, Jun Koi junkoi2004@gmail.com 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
Jun Koi wrote:
Hi Kevin,
On 2/22/08, Kevin O'Connor kevin@koconnor.net 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.
On 2/25/08, Stefan Reinauer stepan@coresystems.de wrote:
Jun Koi wrote:
Hi Kevin,
On 2/22/08, Kevin O'Connor kevin@koconnor.net 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
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
On Mon, Feb 25, 2008 at 01:35:18PM +0900, Jun Koi wrote:
Hi Kevin,
On 2/22/08, Kevin O'Connor kevin@koconnor.net 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
On 2/22/08, Kevin O'Connor kevin@koconnor.net 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
On Mon, Feb 25, 2008 at 07:41:56PM +0900, Jun Koi wrote:
On 2/22/08, Kevin O'Connor kevin@koconnor.net 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 kevin@koconnor.net [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
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.
-
Carl-Daniel Hailfinger -
Jun Koi -
Kevin O'Connor -
Peter Stuge -
ron minnich -
Stefan Reinauer