Greetings,
Are there any facilities for linking in and executing real mode binaries? I have a 'blob' that I need to execute fairly early in real mode.
If not its fine, I can start on one...
thanks ;)
-san
Greetings,
Are there any facilities for linking in and executing real mode binaries? I have a 'blob' that I need to execute fairly early in real mode.
If not its fine, I can start on one...
You want to look at ADLO in V1. ADLO is a payload that drops back to real mode an executes the BIOS from the bochs project.
See the wiki for lots more detail.
Since ADLO is just a payload it should come forward into V2 pretty easy.
There aren't many users. In fact I think I (Bitworks, Inc) has been the only user for a long time. The project that used that is now dead so I haven't messed withit for a while.
I'll be happy to help you all I can. What kind of hardware are you using this on?
One key thing about the current way ADLO works is that you have to enable the shadow areas of your chipset. (Again see the wiki) and this is specific to each motherboard so you have to tweak the ADLO code to eable this.
The ADLO in V1 works for the board that Adam orginally got it working on. I have patches that make it work for a Intel 440bx based board. But other than that you have to customize it.
There have been some discussions on the list previously of a possible generic method of enableing the shadow areas for a chipset. But the payload boundry makes that somewhat difficult.
Search the archives for "shadow" and I think you will find those threads. I don't remember the end result.
So is google looking at using LinuxBIOS on some of it systems?
-- Richard A. Smith
Hmm... that doesnt actually look like ADLO is what I need. Basically I have a binary blob that i need to jump into very early to do early setup tasks. This initial task doesnt look *that* difficult.. I'm thinking I'll just get the blob to link in at the segment it needs to run at (e000 segment), and write an asm wrapper for it which drops to big real mode, calls the blob, then pops back into pmode.
In the long run, I think perhaps some kind of generic 16 bit 'callout' mechanism may be required for early call blobs and whatnot (perhaps even later.. option roms (gak)).
As far as Google goes, we're currently trying to get LinuxBIOS to function for us to evaluate the featureset. So far it looks pretty good, and I'm excited to get it going, and enhance it with what I can...
Thanks for the help, i appreciate the quick response.
On 9/23/05, Richard Smith smithbone@gmail.com wrote:
Greetings,
Are there any facilities for linking in and executing real mode
binaries? I
have a 'blob' that I need to execute fairly early in real mode.
If not its fine, I can start on one...
You want to look at ADLO in V1. ADLO is a payload that drops back to real mode an executes the BIOS from the bochs project.
See the wiki for lots more detail.
Since ADLO is just a payload it should come forward into V2 pretty easy.
There aren't many users. In fact I think I (Bitworks, Inc) has been the only user for a long time. The project that used that is now dead so I haven't messed withit for a while.
I'll be happy to help you all I can. What kind of hardware are you using this on?
One key thing about the current way ADLO works is that you have to enable the shadow areas of your chipset. (Again see the wiki) and this is specific to each motherboard so you have to tweak the ADLO code to eable this.
The ADLO in V1 works for the board that Adam orginally got it working on. I have patches that make it work for a Intel 440bx based board. But other than that you have to customize it.
There have been some discussions on the list previously of a possible generic method of enableing the shadow areas for a chipset. But the payload boundry makes that somewhat difficult.
Search the archives for "shadow" and I think you will find those threads. I don't remember the end result.
So is google looking at using LinuxBIOS on some of it systems?
-- Richard A. Smith
This initial task doesnt look *that* difficult.. I'm thinking I'll just get the blob to link in at the segment it needs to run at (e000 segment), and write an asm wrapper for it which drops to big real mode, calls the blob, then pops back into pmode.
Ah ok. I think others have done similar stuff. Perhpas some of them will pipe up.
In the long run, I think perhaps some kind of generic 16 bit 'callout' mechanism may be required for early call blobs and whatnot (perhaps even later.. option roms (gak)).
We already have this. Its the x86 emu code. You are comming in a little late in the game but the only way to do this and maintain cross-platform compability was to run the code under an emulator.
Its in the V2 codebase and is used to POST many vga cards and some SCSI card option roms.
You may wan't to go look at that and see if it fits your needs. Actually in fact I would ask you to go look at that and if it dosen't fit your needs please tell us why.
-- Richard A. Smith
For sure, I'll definetly start hunting around more.
Thanks for the response.
-san
On 9/23/05, Richard Smith smithbone@gmail.com wrote:
This initial task doesnt look *that* difficult.. I'm thinking I'll just
get
the blob to link in at the segment it needs to run at (e000 segment),
and
write an asm wrapper for it which drops to big real mode, calls the blob, then pops
back
into pmode.
Ah ok. I think others have done similar stuff. Perhpas some of them will pipe up.
In the long run, I think perhaps some kind of generic 16 bit 'callout' mechanism may be required for early call blobs and whatnot (perhaps even later.. option roms (gak)).
We already have this. Its the x86 emu code. You are comming in a little late in the game but the only way to do this and maintain cross-platform compability was to run the code under an emulator.
Its in the V2 codebase and is used to POST many vga cards and some SCSI card option roms.
You may wan't to go look at that and see if it fits your needs. Actually in fact I would ask you to go look at that and if it dosen't fit your needs please tell us why.
-- Richard A. Smith
-
Richard Smith -
San Mehat