[LinuxBIOS] Executing Real-Mode Binaries

[San Mehat]

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

[Richard Smith]

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

[San Mehat]

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

[San Mehat]

For sure, I'll definetly start hunting around more.

Thanks for the response.

-san

On 9/23/05, Richard Smith  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.