Supporting extension ROMs and beyond...

[Eric W. Biederman]

SONE Takeshi <ts1 at tsn.or.jp> writes:

> On Fri, Aug 08, 2003 at 10:51:23AM -0600, Eric W. Biederman wrote:
> > > Now if we want to have a way to choose seperate ELF payloads or direct 
> > > linking them in at build time, that makes lots of sense to me. We can try 
> > > to look at that. 
> > 
> > I am not certain about multiple payloads.  
> 
> I've seen there is no way to ensure images to not overwrite each
> other.
> When LinuxBIOS loads ELF image at the same location as itself,
> it moves itself to top of memory (below 4GB).
> Etherboot (>=5.1) relocates itself to the same top memory,
> since it is usually safe place when loading kernel.
> Other future bootloaders would do the same.
> 
> Probably this could be resolved by indicating LinuxBIOS's location
> in the memory map of LinuxBIOS table?

Yes that would resolve the problem.
 
> > Taking boot loaders to the next step is a very interesting question.  For
> > the normal case where traditional BIOS's work ADLO looks to be a very
> > satisfying solution. 
> 
> If ADLO works at all.

True.  ADLO is not quite ready to handle that yet.
 
> > For things to think about.  The reason traditional BIOS's are 16bit
> > real mode beasts is because Windows runs parts of them in vm86 mode.
> > Which is why 32bit extensions are not common.
> 
> I've been thinking about the same thing.
> I guess you refer to the DOS-based Windows (-95/98/Me).

Correct. 

> Of couse the DOS applications like EMM386 and things like DPMI 
> won't run with a BIOS which does it's job in 32-bit.
> And nowadays nobody uses those application.

Dosemu which uses DPMI still has a surprising number of users.

So while I don't think it is absolutely mandatory to support that kind
of think I think it is worth considering very carefully.

I believe FreeBSD also does BIOS calls from vm86 mode.

> Open source applications I've seen so far (setup of Linux, GRUB, Etherboot,
> LILO...) are calling BIOS from pure real mode, so they won't notice
> if the BIOS services they are calling are in fact 32-bit code.
> I'm not sure but I guess NT-based Windows and its bootloader are
> like Linux and its bootloaders.

Possibly.
 
> If we cut off some of lagacy applications, we can implement a
> clean 32-bit minimum legacy layer.

That is a hard question.   Remember thought that we have 256KB to
work with.  So it may not be too bad.  Traditional BIOS services
are pretty stupid.

I guess my preference would be to make a 16bit clean core that supports
option ROMS and those options roms could be like etherboot and do the extension.

Also of course we can put all of the 32bit entry points in high memory.

By and large I want to support as many legacy uses as we can.  That
allows use to be a complete replacement for AMI, and Phoenix.

Eric