using bios after linux

using bios after linux

[C Michael Sundius]

Hi,

  I've been working on a project where we are using linux as an 
operating environment for some
  setup work prior to booting windows. our control flow looks like this

  reset => (1)linux & linux aplication  =>
  (2)kexec => (3)proprietery 16bit real code (uses bios) =>
  (4)ntloader => (5)Windows

  I have come into this project in the middle, however I've seen enough 
to understand that its not an easy
  task to run bios calls after linux, especially int13 and power 
management stuff. The contractor that
  has been working on this prior to me, used Grub-for-DOS as glue code 
to get most machines to boot correctly.
  i.e. kexec-tools loads Grub-for-DOS (GFD) and our proprietery 
pre-windows real mode code (I'll call that the
  real mode "stuff" from here on); kexec starts GFD, which then starts 
the RM "stuff" that does some thing
  and then finally kicks off ntloader and Windows.

  It seems as though Grub-for-DOS does some magic since if we simply 
load our RM STUFF using some simple
  pergetory code to switch us into real mode the processor goes off into 
the weeds when we call BIOS
  int13; not on all machines of course, but many more than with GFD.

  I'll also say that we are working off of an older version of 
kexec-tools, say 6mo to 1year ago.

  QUESTIONS:
  1) Is GFD the defacto way of running BIOS calls after linux (chain 
booting DOS or windows) or has
  the kexec team or anyone else gotten some a simpler program to go from 
linux to realmode (and BIOS)?
  Any pointers to previous work or helpful hints would be greatly 
appreciated.


  2) It would be best if our linux application that runs before kexec 
call kexec directly*. Thus has anyone
  thought to provide a kexec-tools-lib and an api such that programs can 
acess the same high level utility of
  the kexec program just as easily as from the shell? This would be a 
great help.  Are the
  "kexec-tools-powers-that-be" interested in that being integrated into 
your project? (if we contributed it or
  part of it)

  * I'll just add that we would like to pass pointers to the buffer (of 
code that is loaded) directly to
  the kexec user program instead of having to store them somewhere (in a 
file) and then let the kexec
  program retrieve them (i'm talking about our Real Mode STUFF that runs 
before windows and after linux).

  Apologies if you have discussed this before, I've looked through your 
archives quite a ways back and didn't
  see anything that exactly answered my questions. thanks for your help.

  Mike


C Michael Sundius
Solico Group LLC
232 Nevada St
San Francisco, CA 94110
msundius@sundius.com
(415)608-0121
http://www.sundius.com

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: using bios after linux

[Vivek Goyal]

On Thu, Sep 27, 2007 at 06:57:30AM -0700, C Michael Sundius wrote:
> 
> Hi,
> 
>   I've been working on a project where we are using linux as an 
> operating environment for some
>   setup work prior to booting windows. our control flow looks like this
> 
>   reset => (1)linux & linux aplication  =>
>   (2)kexec => (3)proprietery 16bit real code (uses bios) =>
>   (4)ntloader => (5)Windows
> 

Interesting. Just curious to know that how above setup is useful?

>   I have come into this project in the middle, however I've seen enough 
> to understand that its not an easy
>   task to run bios calls after linux, especially int13 and power 
> management stuff. The contractor that
>   has been working on this prior to me, used Grub-for-DOS as glue code 
> to get most machines to boot correctly.
>   i.e. kexec-tools loads Grub-for-DOS (GFD) and our proprietery 
> pre-windows real mode code (I'll call that the
>   real mode "stuff" from here on); kexec starts GFD, which then starts 
> the RM "stuff" that does some thing
>   and then finally kicks off ntloader and Windows.
> 
>   It seems as though Grub-for-DOS does some magic since if we simply 
> load our RM STUFF using some simple
>   pergetory code to switch us into real mode the processor goes off into 
> the weeds when we call BIOS
>   int13; not on all machines of course, but many more than with GFD.
> 

I have never done that but Eric Biederman in the past had mentioned that
it is not reliable to call BIOS routines once linux as taken control and
we are out of real mode.

>   I'll also say that we are working off of an older version of 
> kexec-tools, say 6mo to 1year ago.
> 
>   QUESTIONS:
>   1) Is GFD the defacto way of running BIOS calls after linux (chain 
> booting DOS or windows) or has
>   the kexec team or anyone else gotten some a simpler program to go from 
> linux to realmode (and BIOS)?
>   Any pointers to previous work or helpful hints would be greatly 
> appreciated.
> 

Kexec does provide option for real mode entry. It will drop to real mode
and then new kernel will execute real mode code (including bios calls). Not
sure how reliable is that.

I had tried something similar in the past. Drop to real mode and then try
to invoke BIOS calls to rest the display. I think I had partial success.
 
> 
>   2) It would be best if our linux application that runs before kexec 
> call kexec directly*. Thus has anyone
>   thought to provide a kexec-tools-lib and an api such that programs can 
> acess the same high level utility of
>   the kexec program just as easily as from the shell? This would be a 
> great help.  Are the
>   "kexec-tools-powers-that-be" interested in that being integrated into 
> your project? (if we contributed it or
>   part of it)
> 
>   * I'll just add that we would like to pass pointers to the buffer (of 
> code that is loaded) directly to
>   the kexec user program instead of having to store them somewhere (in a 
> file) and then let the kexec
>   program retrieve them (i'm talking about our Real Mode STUFF that runs 
> before windows and after linux).
> 

So you want library just because you don't want to put real mode code in 
a file and then pass it to kexec? You want these to be dynamic options 
and pass the buffers. I would say, easier way is to put everything into
a file and then let kexec read/parse it.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: using bios after linux

[yhlu]

On 9/30/07, Vivek Goyal <vgoyal@in.ibm.com> wrote:
> On Thu, Sep 27, 2007 at 06:57:30AM -0700, C Michael Sundius wrote:
> >
> > Hi,
> >
> >   I've been working on a project where we are using linux as an
> > operating environment for some
> >   setup work prior to booting windows. our control flow looks like this
> >
> >   reset => (1)linux & linux aplication =>
> >   (2)kexec => (3)proprietery 16bit real code (uses bios) =>
> >   (4)ntloader => (5)Windows
> >
>
> Interesting. Just curious to know that how above setup is useful?

is it possible to use some emulator under linux and at some point to
exit the emulator and jump the entry..

YH

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

using bios after linux

[msundius]

--------------------------------------------------
Here is a message for you from http://web2mail.com
The easy way to read and send POP email on the web
--------------------------------------------------

Vivek,



Thank you for your reply.



I can't really say what our application is, as I'm a contractor and paid to keep my mouth shut.



As for the question of kexec as a library. yes it would be easier for me,

but we are not always paid to do the easy thing. My client 

wants to be sure that it is difficult for others to find the payload of

kexec. that means not writing it to a file. I also think that enough

applications will eventually exist out there that want to restart 

the OS that a library call is warrented.



Other questions:.. what happened to lists.infradead.org? seems to have been 

vaporized. 



more importantly, yes, I've read in the archives that Eric gave up on 

calling bios after linux. Was this because linux stomped on the state of 

bios, or that linux (its drivers really) leaves the physical hardware 

(devices) in such an undeterminate state such that  bios cannot handle 

the sudden change or complicated confiuration. 



Before you answer, that last one, I realize that it is largely symantic, 

but what I mean is that is this more of a problem inherent in how some

bios' are not well behaved and should be fixed or is it that linux does

not close down nicely and therefore should be fixed? we will never 

shutdown as in the case of a crash dump, but rather do our best to clean

up after ourselves. 



Thus, we probably don't have a problem fixing a bug or two to make that happen

so bios runs.  on the other hand the decision makers want to avoid having

a whole army of people fixing drivers to make them turn off correctly.



(or better, am I on a fools errend or should I keep up the fight?)



well, thanks for your input. 



Mike



ps sorry for not quoting the original email, I'm not on my normal computer

and am writing from web2mail :[



 





_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec