Avoiding DOC hotplug when Grub fails

Avoiding DOC hotplug when Grub fails

[Karim Yaghmour]

As far as I can see by browsing this mailing list archive, one
has to hotplug the DOC device in order to have the HD come up
first if Grub fails in some way after having hijacked int 19h.
This is rather inconvenient, to say the least.

Why not just hijack int 16h (keyboard) while we're at it, write
a small keyboard int handler, and check if the space-bar (or
some other key) is held down while Grub is booting? If it is,
then Grub invokes the BIOS's original int 19h which then proceeds
normally. If it isn't, then Grub continues with its own load
procedure.

Comments?

Karim

===================================================
                 Karim Yaghmour
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

Re: Avoiding DOC hotplug when Grub fails

[Mark Meade]

Karim Yaghmour wrote:

> As far as I can see by browsing this mailing list archive, one
> has to hotplug the DOC device in order to have the HD come up
> first if Grub fails in some way after having hijacked int 19h.
> This is rather inconvenient, to say the least.

I've recently found an easier way - with the M-Sys ISA Eval card, anyway.  I 
assume the PCI card would be similar.

On the ISA card, there is a jumper used to set the DoC Address (C800, D000, 
etc).  If this jumper is removed, the DoC is no longer recognized by the 
BIOS.

If the DoC has int 19h, simply boot without the jumper in place, and then put 
it back after the hard drive boot has finished.  If you have the MTD stuff 
compiled as modules, don't do the modprobe until after the jumper is 
replaced.   Works great, plus eliminates the risky procedure of hotplugging 
the DoC or Eval card.

> Why not just hijack int 16h (keyboard) while we're at it, write
> a small keyboard int handler, and check if the space-bar (or
> some other key) is held down while Grub is booting? If it is,
> then Grub invokes the BIOS's original int 19h which then proceeds
> normally. If it isn't, then Grub continues with its own load
> procedure.

One potential problem is that the low level Grub code that grabs int 19 is 
limited to 512 bytes.  With all the other things that code has to do, there 
might not be enough room to add another int handler.

Mark

RE: Avoiding DOC hotplug when Grub fails

[Gregg C Levine]

Hello from Gregg C Levine
Our correspondent mentions the M-Sys ISA Eval card. I would assume
anyway that the gizmo exists. Can someone also tell me how much this
thing would also cost? I've been attempting to track down a relatively
easy method of evaluating such hardware, and I remembered that most
providers of such hardware also make this cards. If anyone actually has
one that they do not need, plus any blank disks I'd be glad to take it
off their hands.
-------------------
Gregg C Levine hansolofalcon@worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."  Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )



> -----Original Message-----
> From: linux-mtd-admin@lists.infradead.org [mailto:linux-mtd-
> admin@lists.infradead.org] On Behalf Of Mark Meade
> Sent: Thursday, August 08, 2002 10:02 PM
> To: linux-mtd@lists.infradead.org
> Cc: karim@opersys.com
> Subject: Re: Avoiding DOC hotplug when Grub fails
> 
> Karim Yaghmour wrote:
> 
> > As far as I can see by browsing this mailing list archive, one
> > has to hotplug the DOC device in order to have the HD come up
> > first if Grub fails in some way after having hijacked int 19h.
> > This is rather inconvenient, to say the least.
> 
> I've recently found an easier way - with the M-Sys ISA Eval card,
anyway.  I
> assume the PCI card would be similar.
> 
> On the ISA card, there is a jumper used to set the DoC Address (C800,
D000,
> etc).  If this jumper is removed, the DoC is no longer recognized by
the
> BIOS.
> 
> If the DoC has int 19h, simply boot without the jumper in place, and
then put
> it back after the hard drive boot has finished.  If you have the MTD
stuff
> compiled as modules, don't do the modprobe until after the jumper is
> replaced.   Works great, plus eliminates the risky procedure of
hotplugging
> the DoC or Eval card.
> 
> > Why not just hijack int 16h (keyboard) while we're at it, write
> > a small keyboard int handler, and check if the space-bar (or
> > some other key) is held down while Grub is booting? If it is,
> > then Grub invokes the BIOS's original int 19h which then proceeds
> > normally. If it isn't, then Grub continues with its own load
> > procedure.
> 
> One potential problem is that the low level Grub code that grabs int
19 is
> limited to 512 bytes.  With all the other things that code has to do,
there
> might not be enough room to add another int handler.
> 
> Mark
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Avoiding DOC hotplug when Grub fails

[Karim Yaghmour]

Mark Meade wrote:
> > As far as I can see by browsing this mailing list archive, one
> > has to hotplug the DOC device in order to have the HD come up
> > first if Grub fails in some way after having hijacked int 19h.
> > This is rather inconvenient, to say the least.
> 
> I've recently found an easier way - with the M-Sys ISA Eval card, anyway.  I
> assume the PCI card would be similar.
> 
> On the ISA card, there is a jumper used to set the DoC Address (C800, D000,
> etc).  If this jumper is removed, the DoC is no longer recognized by the
> BIOS.
> 
> If the DoC has int 19h, simply boot without the jumper in place, and then put
> it back after the hard drive boot has finished.  If you have the MTD stuff
> compiled as modules, don't do the modprobe until after the jumper is
> replaced.   Works great, plus eliminates the risky procedure of hotplugging
> the DoC or Eval card.

Interesting. I hadn't thought of this. It sure beats the hotplugging
circus, but it still involves risky runtime hardware manipulation _and_
it only works if you have a jumper to set the address of the DOC, such
as with the eval board (which I am using myself).

> > Why not just hijack int 16h (keyboard) while we're at it, write
> > a small keyboard int handler, and check if the space-bar (or
> > some other key) is held down while Grub is booting? If it is,
> > then Grub invokes the BIOS's original int 19h which then proceeds
> > normally. If it isn't, then Grub continues with its own load
> > procedure.
> 
> One potential problem is that the low level Grub code that grabs int 19 is
> limited to 512 bytes.  With all the other things that code has to do, there
> might not be enough room to add another int handler.

That's a possibility. Although I'm sure some of the folks on this list
have DOS asm wizardry in some past life. There are, nevertheless, other
ways to rely on keyboard input to influence Grub's behavior without
implementing a complete int 9 handler (I made a mistake in my previous
mail, int 16h is the BIOS's service routine for keyboard ops while
int 9 is the actual interrupt handler for the keyboard). Here are two 
I can think of:

1) The BIOS keeps all keyboard input in a buffer starting at 0040:001E
and measuring 16 words (2 bytes per word). This is a circular buffer
and appropriate head and tail pointers are located at 0040:001A and
0040:001C. We don't need those pointers, however. By keeping the
space-bar down, this buffer will fill with space-bar characters. When
Grub's int 19 handler starts executing, it would scan the content of
the keyboard buffer and check whether one of the character is the
space-bar. If it is, then continue with the default BIOS int 19h.

2) The BIOS provides keyboard services through int 16h. Function 02h
of this interrupt handler returns a bit field in AL which has a "1"
set in the appropriate position if one of these keys is active:
right shift, left shift, ctrll, alt, scroll lock, num lock, caps lock,
and insert. Grub's int 19 need only call on this function, do the
appropriate test, and jump to an alternate path in case, say, "ctrl"
is held down.

Both of these should be very short and trivial in assembly (the second
one should be 5 instructions more: 1 to store the old handler before
overwritting it with Grub's handler, 1 to fill AH with 02h, 1 to call
int 16h, 1 to test the appropriate bit, and one to jump to the old
handler according to the test result). Unfortunately, my DOS/BIOS/real-
mode asm past life is very far away. My hope is that someone on this
list has this experience a little bit closer to memory than I.
Otherwise I'll have to go looking for my old spell books in the attic ...

Karim

===================================================
                 Karim Yaghmour
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================