No more DoC hotplug on Grub fail [tested & working]

No more DoC hotplug on Grub fail [tested & working]

[Karim Yaghmour]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]


I modified doc_stage1.S to check whether the user is holding
down the "ctrl" key while booting. If so, then it uses the
BIOS's original bootstrap handler instead of its own. This
avoids having to hotplug the DOC in case you misconfigure it
or if it fails to boot adequately for some other reason.

I had suggested this idea earlier on this list, but I figured
I'd dig up some of my old real-mode witchcraft and get it over
with. I sent a preliminary version of the code earlier, but
now that I tested it out, I know that that version doesn't
work. The version attached with the current e-mail, however,
does work.

The scheme works as described in my earlier emails.

Hopefully this saves some folks some cold sweat (me included).

Karim

P.S.: For some reason, gas 2.9.5 is unable to build my modified
doc_stage1.S in the prescribed 512 bytes. gas 2.12, nevertheless,
works just fine.

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

[-- Attachment #2: doc_stage1.S.bz2 --]
[-- Type: application/octet-stream, Size: 4734 bytes --]

Re: No more DoC hotplug on Grub fail [tested & working]

[Mark Meade]

Karim,

I tested your Grub patch on a DoC Millennium, it works fine.  I used the 0.92 
patch, but I had to reduce the length of some of the text messages to make 
everything fit.  This may have been the gas 2.9.5 problem you described 
earlier.

This patch, while potentially useful during debugging, takes up precious 
space that may be needed later (to add support for new flash devices, etc).  
Also, once Grub is booting correctly from the DoC, I would think this feature 
would not be needed.

For what it's worth, I'd recommend that this patch be made available in the 
patches directory of the CVS tree, rather than making it part of the official 
GRUB code.

I'm willing to revise my GRUB/DoC HOWTO to include instructions on the use of 
this patch, for those who are concerned about this issue.

Mark

Karim Yaghmour wrote:
> I modified doc_stage1.S to check whether the user is holding
> down the "ctrl" key while booting. If so, then it uses the
> BIOS's original bootstrap handler instead of its own. This
> avoids having to hotplug the DOC in case you misconfigure it
> or if it fails to boot adequately for some other reason.

> I had suggested this idea earlier on this list, but I figured
> I'd dig up some of my old real-mode witchcraft and get it over
> with. I sent a preliminary version of the code earlier, but
> now that I tested it out, I know that that version doesn't
> work. The version attached with the current e-mail, however,
> does work.

> The scheme works as described in my earlier emails.

> Hopefully this saves some folks some cold sweat (me included).

> Karim

> P.S.: For some reason, gas 2.9.5 is unable to build my modified
> doc_stage1.S in the prescribed 512 bytes. gas 2.12, nevertheless,
> works just fine.

Re: No more DoC hotplug on Grub fail [tested & working]

[Henrik Nordström]

On Wed, 4 Sep 2002, Mark Meade wrote:

> This patch, while potentially useful during debugging, takes up precious 
> space that may be needed later (to add support for new flash devices, etc).  

Exacly what kind of precious space does it take up? If you have another
kind of flash device you better make another stage1 for that device,
right?

If the stage1 are size is a concern on DoC, then perhaps it should be 
considered to have a kind of "stage1.5" for DoC. 

Also, for most practical purposes, having the "skip GRUB on this boot"  
check in stage2 would also be fine I think, except for the few who are
playing around with custom stage1 loaders and those who are should
probably have a setup where they can reflash their DoC without these
concerns anyway..

> Also, once Grub is booting correctly from the DoC, I would think this feature 
> would not be needed.

Except if a later upgrade of GRUB fails.. or you for some other reason 
need to bypass the GRUB in service purposes. Such as if the GRUB menu has 
got fucked up with no way to get to the GRUB prompt.

> For what it's worth, I'd recommend that this patch be made available in the 
> patches directory of the CVS tree, rather than making it part of the official 
> GRUB code.

Better than nothing ;-)

> I'm willing to revise my GRUB/DoC HOWTO to include instructions on the use of 
> this patch, for those who are concerned about this issue.

I would not install a GRUB without it. Have had to use it (and the M-Sys 
Alt+B sister) several times already due to various reasons..

Regards
Henrik

Re: No more DoC hotplug on Grub fail [tested & working]

[Karim Yaghmour]

Mark,

Mark Meade wrote:
> I tested your Grub patch on a DoC Millennium, it works fine.

Great. I'm glad someone else can confirm that it works.

>  I used the 0.92
> patch, but I had to reduce the length of some of the text messages to make
> everything fit.  This may have been the gas 2.9.5 problem you described
> earlier.

True.

> This patch, while potentially useful during debugging, takes up precious
> space that may be needed later (to add support for new flash devices, etc).
> Also, once Grub is booting correctly from the DoC, I would think this feature
> would not be needed.
>
> For what it's worth, I'd recommend that this patch be made available in the
> patches directory of the CVS tree, rather than making it part of the official
> GRUB code.

This is one way of looking at it. However, it seems that this then enforces
a policy on the way developers use their hardware. Providing it as part of
the official GRUB and having it disabled by default would provide a capability
without enforcing a policy. A developer could then pass the
"--enable-doc-check-keybrd" option to "configure" in order to activate the
keyboard detection. This should be fairly easy to implement since all the
added code is enclosed in "#ifdef KEYBRD_READ" statements.

> I'm willing to revise my GRUB/DoC HOWTO to include instructions on the use of
> this patch, for those who are concerned about this issue.

A mention of any alternatives to the DOC hotplug would certainly be great.

Karim

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

Re: No more DoC hotplug on Grub fail [tested & working]

[Henrik Nordstrom]

Karim Yaghmour wrote:

> Mark Meade wrote:
> > I tested your Grub patch on a DoC Millennium, it works fine.
>
> Great. I'm glad someone else can confirm that it works.

I can also confirm that the patch to selectively bypass grub works, at least 
on a DoC 2000 24MB. However due to other problems (discussed separately) I 
have not yet been able to use the GRUB firmware in production. Currently 
loading GRUB via the DOS firmware.

> This is one way of looking at it. However, it seems that this then enforces
> a policy on the way developers use their hardware. Providing it as part of
> the official GRUB and having it disabled by default would provide a
> capability without enforcing a policy. A developer could then pass the
> "--enable-doc-check-keybrd" option to "configure" in order to activate the
> keyboard detection. This should be fairly easy to implement since all the
> added code is enclosed in "#ifdef KEYBRD_READ" statements.

Agreed. It is a very valuable patch for anyone considering using GRUB DoC 
firmware, and certainly a must have for the first installs until one gets 
customized to the way GRUB works. Even with a boot loader as fancy as GRUB it 
is easy to fuck things up beyond repair...

Regards
Henrik

Re: No more DoC hotplug on Grub fail [tested & working]

[Mark Meade]

Henrik Nordström wrote:
> > This patch, while potentially useful during debugging, takes up precious
> > space that may be needed later (to add support for new flash devices,
> > etc).
>
> Exacly what kind of precious space does it take up? If you have another
> kind of flash device you better make another stage1 for that device,
> right?
>
> If the stage1 are size is a concern on DoC, then perhaps it should be
> considered to have a kind of "stage1.5" for DoC.

The boot block on the DoC Millennium is 512 bytes.  I believe this is also 
true for the DoC 2000.  Karim's patch used up the few remaining bytes, plus 
it was necessary to remove parts of the informational messages to make things 
fit.

To clarify, I was referring to adding support for detecting additional 
256-bytes per page devices.  The latest code looks at the device ID code to 
differentiate between 256-byte and 512-byte parts.

There really is no way to have a "stage1.5" in this case -- everything that 
is currently being done in doc_stage1 is required to copy Grub from the DoC 
to RAM.

> Also, for most practical purposes, having the "skip GRUB on this boot"
> check in stage2 would also be fine I think, except for the few who are
> playing around with custom stage1 loaders and those who are should
> probably have a setup where they can reflash their DoC without these
> concerns anyway..

Maybe, but then the stage2 code would have to know where to look for the 
BIOS's original handler, and also which one it was (18 or 19).  It would be 
*much* cleaner to leave this in stage1.

If this patch ends up in official GRUB, I'd recommend that we remove the 
section that displays the manufacturer and chip ID codes.  This should save 
enough space to make everything fit.

Mark

Re: No more DoC hotplug on Grub fail [tested & working]

[Mark Meade]

Karim Yaghmour wrote:
> This is one way of looking at it. However, it seems that this then enforces
> a policy on the way developers use their hardware. Providing it as part of
> the official GRUB and having it disabled by default would provide a
> capability without enforcing a policy. A developer could then pass the
> "--enable-doc-check-keybrd" option to "configure" in order to activate the
> keyboard detection. This should be fairly easy to implement since all the
> added code is enclosed in "#ifdef KEYBRD_READ" statements.

Agreed.  It's just a matter of making everything fit into a very limited 
space.  As I mentioned earlier, maybe this feature is more valuable than the 
code that displays the manufacturer and chip ID codes.  Another option would 
be to make the SHOW_INFO and KEYBRD_READ conditionals mutually exclusive.

Mark

Re: No more DoC hotplug on Grub fail [tested & working]

[Karim Yaghmour]

Mark Meade wrote:
> Agreed.

Great, I'm glad there is a consensus on this.

>  It's just a matter of making everything fit into a very limited
> space.  As I mentioned earlier, maybe this feature is more valuable than the
> code that displays the manufacturer and chip ID codes.  Another option would
> be to make the SHOW_INFO and KEYBRD_READ conditionals mutually exclusive.

Isn't there a way to get the manufacturer and chip ID codes display outside
the first 512 bytes? Couldn't the code for this go in stage2 instead? We
could then have the best of both worlds.

Karim

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

Re: No more DoC hotplug on Grub fail [tested & working]

[Mark Meade]

Karim Yaghmour wrote:
> Isn't there a way to get the manufacturer and chip ID codes display outside
> the first 512 bytes? Couldn't the code for this go in stage2 instead? We
> could then have the best of both worlds.

The manufacturer and chip ID codes are already displayed in stage2.  In fact, 
most of the functionality of the assembly code in doc_stage1 is also present 
in stage2/bdev_diskonchip.c.  

The display of these codes in stage1 are there to help diagnose any failures 
caused by incorrectly identifying any 256-byte/page devices.   If we get 
this wrong, we'll never get to stage 2.

Besides the ID's, enabling SHOW_INFO displays the DoC type and window, and 
also the "Jumping to Grub" message which signifies the end of stage1.

Mark