USB device not seen by grub

USB device not seen by grub

[Chris Jones]

I am trying to have grub boot off a partition on a USB stick.

I issued the following command from the grub command line:

% insmod uhci

grub was hung and I had to do a hard reset.

Is this to be expected, considering that this is a fairly old system and
the BIOS knows nothing about USB devices.

Thanks,

CJ

Re: USB device not seen by grub

[BandiPat]

Chris Jones wrote:
> I am trying to have grub boot off a partition on a USB stick.
> 
> I issued the following command from the grub command line:
> 
> % insmod uhci
> 
> grub was hung and I had to do a hard reset.
> 
> Is this to be expected, considering that this is a fairly old system and
> the BIOS knows nothing about USB devices.
> 
> Thanks,
> 
> CJ
> 
> 
> _______________________________________________
If your BIOS on the computer does not support booting from USB devices 
then you probably got the correct result.  :-)

You might check to see if there is a newer bios for your motherboard 
that does support USB booting, but if not, I can't see how you could 
ever get it to work!

Regards,
Pat

-- 
        ---Zenwalk v6.x--Linux 2.6.31---
"In brightest day, in darkest night, let those
that worship evil, beware Green Lantern's Light!"

Re: USB device not seen by grub

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Chris Jones wrote:
> I am trying to have grub boot off a partition on a USB stick.
>
>   
You can't chainload to disk invisible by BIOS. But you can load
supported OSes from it.
> I issued the following command from the grub command line:
>
> % insmod uhci
>
> grub was hung and I had to do a hard reset.
>   
Can you issue:
debug=all
insmod uhci
insmod usbms
debug=all
ls -l
debug=
ls -l
And to post the result?
> Is this to be expected, considering that this is a fairly old system and
> the BIOS knows nothing about USB devices.
>
> Thanks,
>
> CJ
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: USB device not seen by grub

[Chris Jones]

On Thu, Dec 03, 2009 at 10:16:17AM EST, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Chris Jones wrote:

> > I am trying to have grub boot off a partition on a USB stick.
> >
> >   
> You can't chainload to disk invisible by BIOS. But you can load
> supported OSes from it.
> > I issued the following command from the grub command line:
> >
> > % insmod uhci
> >
> > grub was hung and I had to do a hard reset.
> >   
> Can you issue:
> debug=all
> insmod uhci
> insmod usbms
> debug=all
> ls -l
> debug=
> ls -l
> And to post the result?

Certainly.

Any way I could redirect the output to something like a file, both in
the interest of efficiency and accuracy?

CJ

Re: USB device not seen by grub

[Duboucher Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris Jones a écrit :
> On Thu, Dec 03, 2009 at 10:16:17AM EST, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> Chris Jones wrote:
> 
>>> I am trying to have grub boot off a partition on a USB stick.
>>>
>>>   
>> You can't chainload to disk invisible by BIOS. But you can load
>> supported OSes from it.
>>> I issued the following command from the grub command line:
>>>
>>> % insmod uhci
>>>
>>> grub was hung and I had to do a hard reset.
>>>   
>> Can you issue:
>> debug=all
>> insmod uhci
>> insmod usbms
>> debug=all
>> ls -l
>> debug=
>> ls -l
>> And to post the result?
> 
> Certainly.
> 
> Any way I could redirect the output to something like a file, both in
> the interest of efficiency and accuracy?
> 
> CJ
> 

	You could do this easily using a serial null-modem cable, but I don't
think you have one. :(
	Also, the uhci module was making Grub2 hang on an HP nc8430, though I
don' remember having reported this here.

	Thomas.

> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksYGVIACgkQBV7eXqefhqiO1gCfX3jZIoGe/f8bIx8OjeB4Obue
MmAAoLPb9uVbMN7b97Halx8NnitzJqkE
=2XT1
-----END PGP SIGNATURE-----

Re: USB device not seen by grub

[Vladimir 'φ-coder/phcoder' Serbinenko]

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


>
>     You could do this easily using a serial null-modem cable, but I don't
> think you have one. :(
>     Also, the uhci module was making Grub2 hang on an HP nc8430, though I
> don' remember having reported this here.
>
There is an issue that somewhere grub misses a delay between uhci
commands. When enabling debug=all this hang goes away. My laptop has
this issue too. I hope to have time soon to fix it


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel



-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: USB device not seen by grub

[Chris Jones]

On Thu, Dec 03, 2009 at 03:02:27PM EST, Duboucher Thomas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

[..]

> 	You could do this easily using a serial null-modem cable, but I don't
> think you have one. :(

;-)

Another fascinating hardware aspect I never got down to investigating.

So if I had one, I would plug it into a serial port and connect that to
the serial port of another host and then what?

> 	Also, the uhci module was making Grub2 hang on an HP nc8430, though I
> don' remember having reported this here.

OK, so it's just not me or my antique of a laptop, then.

CJ

Re: USB device not seen by grub

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Chris Jones wrote:
>> Can you issue:
>> debug=all
>> insmod uhci
>> insmod usbms
>> debug=all
>> ls -l
>> debug=
>> ls -l
>> And to post the result?
>>     
>
> Certainly.
>
> Any way I could redirect the output to something like a file, both in
> the interest of efficiency and accuracy?
>   
No. We don't have any file writing support except saving environment
because although handy for cases like this it's potentially dangerous. I
guess you prefer to have to use your camera to take a picture of GRUB
rather than having GRUB damage your FS.
> CJ
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: USB device not seen by grub

[Chris Jones]

On Thu, Dec 03, 2009 at 03:24:31PM EST, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Chris Jones wrote:
> >> Can you issue:
> >> debug=all
> >> insmod uhci
> >> insmod usbms
> >> debug=all
> >> ls -l
> >> debug=
> >> ls -l
> >> And to post the result?
> >>     
> >
> > Certainly.
> >
> > Any way I could redirect the output to something like a file, both in
> > the interest of efficiency and accuracy?
> >   
> No. We don't have any file writing support except saving environment
> because although handy for cases like this it's potentially dangerous. I
> guess you prefer to have to use your camera to take a picture of GRUB
> rather than having GRUB damage your FS.

Don't I hate those camera shots of grub that I see online. They don't
pay tribute to the beauty of the  beast. :-)

One feature I've never come to terms with is that a machine's grub
environment has to live somewhere on the HDD. So if you have a
multi-boot box with a bunch of legacy and future systems under
evaluation alongside your 'production' systems, you have to make a
decision where the active grub should live, which is always
inconvenient. Somehows, mine has so far ended up on a sacrificial goat
of a Karmic ubuntu system.

Along the same lines, I was thinking that if you cloned your grub
environment to external media, and used that to boot the box, said media
could have a some safe playing ground, where you could dump logs,
screenshots or whatever. 

Then boot back into one of you systems, mount the media and process the
data - very vague thoughts, I admit, but maybe there's something to it?

Thank you very much for your comments, let me run the above test and
report the outcome.

CJ

Re: USB device not seen by grub

[Chris Jones]

On Thu, Dec 03, 2009 at 03:24:31PM EST, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Chris Jones wrote:
> >> Can you issue:
> >> debug=all
> >> insmod uhci
> >> insmod usbms
> >> debug=all
> >> ls -l
> >> debug=
> >> ls -l
> >> And to post the result?

Barring typos or omissions, the trace reveals that the perceived 'hang'
after issuing 'insmod uhci' is in fact grub looping over the following
code:

/build/buildd/grub2-1.97~beta4/kern/disk.c:389 Reading hd0,11

hda,11 correponds to the partition where grub is managed, but also
perhaps more to the point, it happens to be the first bootable entry in
my grub.cfg

The version of grub is the one currently in the ubuntu 9.10 repos.

Thanks,

CJ

Re: USB device not seen by grub

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Chris Jones wrote:
> On Thu, Dec 03, 2009 at 03:24:31PM EST, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>   
>> Chris Jones wrote:
>>     
>>>> Can you issue:
>>>> debug=all
>>>> insmod uhci
>>>> insmod usbms
>>>> debug=all
>>>> ls -l
>>>> debug=
>>>> ls -l
>>>> And to post the result?
>>>>         
>
> Barring typos or omissions, the trace reveals that the perceived 'hang'
> after issuing 'insmod uhci' is in fact grub looping over the following
> code:
>
> /build/buildd/grub2-1.97~beta4/kern/disk.c:389 Reading hd0,11
>
>   
This is just module loading. I guess your terminal is slow which causes
an enormous slowback when loading module. You can using
debug=usb,uhci,ohci
instead of
debug=all
> hda,11 correponds to the partition where grub is managed, but also
> perhaps more to the point, it happens to be the first bootable entry in
> my grub.cfg
>
> The version of grub is the one currently in the ubuntu 9.10 repos.
>
> Thanks,
>
> CJ
>
>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: USB device not seen by grub

[Chris Jones]

On Thu, Dec 03, 2009 at 05:52:37PM EST, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Chris Jones wrote:

[..]

> > Barring typos or omissions, the trace reveals that the perceived
> > 'hang' after issuing 'insmod uhci' is in fact grub looping over the
> > following code:

> > /build/buildd/grub2-1.97~beta4/kern/disk.c:389 Reading hd0,11

> This is just module loading. I guess your terminal is slow which causes
> an enormous slowback when loading module. 

I let it run for the time it takes to make a coffee pot, which I would
say is about five minutes. And it was not like it took any perceptible
length of time ot display one message, could just about see them
scrolling.

OTOH, when editing I did notice that the terminal is indeed very slow. I
don't know what's causing this. I have gfxmode=1024x768, seems to slow
things down a bit.

> You can using

> debug=usb,uhci,ohci
> instead of
> debug=all

Let's have a look.

Thanks,

CJ

Re: USB device not seen by grub

[Chris Jones]

On Thu, Dec 03, 2009 at 05:52:37PM EST, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Chris Jones wrote:

[..]

> > Barring typos or omissions, the trace reveals that the perceived
> > 'hang' after issuing 'insmod uhci' is in fact grub looping over the
> > following code:

> > /build/buildd/grub2-1.97~beta4/kern/disk.c:389 Reading hd0,11
> >

> This is just module loading. I guess your terminal is slow which causes
> an enormous slowback when loading module. You can using

> debug=usb,uhci,ohci instead of debug=all

I did as you requested with the following results:

------------------------------------------------------------------------
$ debug=usb,uhci,ohci
$ insmod uhci

[..]

/build/buildd/grub2-1.97~beta4/kern/disk.c:543 transaction failed
/build/buildd/grub2-1.97~beta4/kern/disk.c:403 transaction endp=0, type=0, addr=0,toggle=0, size=8, data=0x7fc6c, td=0x1792b040
/build/buildd/grub2-1.97~beta4/kern/disk.c:403 transaction endp=0, type=0, addr=0,toggle=1, size=0, data=0x0, td=0x1792b020
/build/buildd/grub2-1.97~beta4/kern/disk.c:476 setup transaction 0
/build/buildd/grub2-1.97~beta4/kern/disk.c:482 iniate transation
/build/buildd/grub2-1.97~beta4/kern/disk.c:493 >t status=0xf000ff53 data=0xf00ff50 td=0x0
/build/buildd/grub2-1.97~beta4/kern/disk.c:539 transaction complete
/build/buildd/grub2-1.97~beta4/kern/disk.c:543 transaction failed
/build/buildd/grub2-1.97~beta4/kern/disk.c:631 detect=0x80 port=1
/build/buildd/grub2-1.97~beta4/kern/disk.c:633 registered

$ insmod usbms

[..]

/build/buildd/grub2-1.97~beta4/kern/disk.c:403 transaction endp=0, type=2, addr=1,toggle=8, size=8, data=0x7fcec, td=0x1792b000
/build/buildd/grub2-1.97~beta4/kern/disk.c:403 transaction endp=0, type=0, addr=1,toggle=1, size=0, data=0x0, td=0x1792b040
/build/buildd/grub2-1.97~beta4/kern/disk.c:476 setup transaction 0
/build/buildd/grub2-1.97~beta4/kern/disk.c:482 iniate transation
/build/buildd/grub2-1.97~beta4/kern/disk.c:493 >t status=0xf000ff53 data=0xf00ff50 td=0x0
/build/buildd/grub2-1.97~beta4/kern/disk.c:539 transaction complete
/build/buildd/grub2-1.97~beta4/kern/disk.c:543 transaction failed

$ ls -l

[endless messages]

I rebooted and issued the same commands, resetting debug= after the
insmod's:

------------------------------------------------------------------------
$ debug=usb,uhci,ohci
$ insmod uhci

[..]

/build/buildd/grub2-1.97~beta4/kern/disk.c:633 registered

$ insmod usbms

[..]

/build/buildd/grub2-1.97~beta4/kern/disk.c:539 transaction complete
/build/buildd/grub2-1.97~beta4/kern/disk.c:543 transaction failed

$ debug=

$ ls -l

Device usb0:
------------------------------------------------------------------------

Nothing further happened that I could see - gave up after about 10
minutes. 

But, I did notice something rather promising: on both occasions the
orange light on the USB stick came on just after the insmod usbms, I
believe.

Thanks,

CJ

[solved] Re: USB device not seen by grub

[Chris Jones]

On Thu, Dec 03, 2009 at 05:52:37PM EST, Vladimir 'φ-coder/phcoder' Serbinenko wrote:

[..]

> This is just module loading. I guess your terminal is slow which causes
> an enormous slowback when loading module. You can using

> debug=usb,uhci,ohci
> instead of
> debug=all

I was able to boot the partition I had copied over to the USB stick after
this:

grub:> debug=uhci,ohci,usbms
grub:> insmod uhci
grub:> insmod usbms
grub:> debug=

Why do I have to enable tracing to make it work?

Also, is there any way I can run the grub command line on a system
that's already booted, so I can explore its possibities in a context
where I have internet access, browse documentation, etc..?

Thanks,

CJ

Re: [solved] Re: USB device not seen by grub

[richardvoigt]

On Fri, Dec 4, 2009 at 8:26 PM, Chris Jones <cjns1989@gmail.com> wrote:
> On Thu, Dec 03, 2009 at 05:52:37PM EST, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>
> [..]
>
>> This is just module loading. I guess your terminal is slow which causes
>> an enormous slowback when loading module. You can using
>
>> debug=usb,uhci,ohci
>> instead of
>> debug=all
>
> I was able to boot the partition I had copied over to the USB stick after
> this:
>
> grub:> debug=uhci,ohci,usbms
> grub:> insmod uhci
> grub:> insmod usbms
> grub:> debug=
>
> Why do I have to enable tracing to make it work?

Yesterday Vladimir wrote:

(quote)
There is an issue that somewhere grub misses a delay between uhci
commands. When enabling debug=all this hang goes away. My laptop has
this issue too. I hope to have time soon to fix it
(/quote)

This makes a lot of sense, the UHCI controller may require some time
for processing certain commands before it can accept the next one, and
tracing slows things down enough to let the controller catch up.  It's
a very good sign (for having a fix soon) that one of the major
programmers has not only reproduced the problem but is affected by it.

Re: [solved] Re: USB device not seen by grub

[Chris Jones]

On Fri, Dec 04, 2009 at 09:58:23PM EST, richardvoigt@gmail.com wrote:
> On Fri, Dec 4, 2009 at 8:26 PM, Chris Jones <cjns1989@gmail.com> wrote:

[..]

> > Why do I have to enable tracing to make it work?
> 
> Yesterday Vladimir wrote:
> 
> (quote)
> There is an issue that somewhere grub misses a delay between uhci
> commands. When enabling debug=all this hang goes away. My laptop has
> this issue too. I hope to have time soon to fix it
> (/quote)

> This makes a lot of sense, the UHCI controller may require some time
> for processing certain commands before it can accept the next one, and
> tracing slows things down enough to let the controller catch up.  It's
> a very good sign (for having a fix soon) that one of the major
> programmers has not only reproduced the problem but is affected by it.

Thanks for reminding me.

CJ

Re: [solved] Re: USB device not seen by grub

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 1373 bytes --]

Chris Jones wrote:
> On Thu, Dec 03, 2009 at 05:52:37PM EST, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>
> [..]
>
>   
>> This is just module loading. I guess your terminal is slow which causes
>> an enormous slowback when loading module. You can using
>>     
>
>   
>> debug=usb,uhci,ohci
>> instead of
>> debug=all
>>     
>
> I was able to boot the partition I had copied over to the USB stick after
> this:
>
> grub:> debug=uhci,ohci,usbms
> grub:> insmod uhci
> grub:> insmod usbms
> grub:> debug=
>
> Why do I have to enable tracing to make it work?
>
>   
Because a dprintf acted as a forgotten millisleep. This patch should fix
it. On my machine I still have issues because uhci.c has problems with
second port
> Also, is there any way I can run the grub command line on a system
> that's already booted, so I can explore its possibities in a context
> where I have internet access, browse documentation, etc..?
>
>   
I'm working on it but the current problem is that I haven't found a
syscall in linux to get physical address of a page. Does anyone has a
suggestion?
> Thanks,
>
> CJ
>
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: uhciclean.diff --]
[-- Type: text/x-diff; name="uhciclean.diff", Size: 2948 bytes --]

=== modified file 'bus/usb/uhci.c'
--- bus/usb/uhci.c	2009-10-14 08:11:59 +0000
+++ bus/usb/uhci.c	2009-12-05 09:13:21 +0000
@@ -23,7 +23,6 @@
 #include <grub/usb.h>
 #include <grub/usbtrans.h>
 #include <grub/pci.h>
-#include <grub/cpu/pci.h>
 #include <grub/i386/io.h>
 #include <grub/time.h>
 
@@ -435,6 +434,7 @@
   grub_uhci_td_t td_prev = NULL;
   grub_usb_err_t err = GRUB_USB_ERR_NONE;
   int i;
+  grub_uint64_t endtime;
 
   /* Allocate a queue head for the transfer queue.  */
   qh = grub_alloc_qh (u, GRUB_USB_TRANSACTION_TYPE_CONTROL);
@@ -483,6 +483,7 @@
 
   /* Wait until either the transaction completed or an error
      occurred.  */
+  endtime = grub_get_time_ms () + 1000;
   for (;;)
     {
       grub_uhci_td_t errtd;
@@ -534,6 +535,13 @@
 	     updated.  */
 	  grub_dprintf ("uhci", "transaction fallthrough\n");
 	}
+      if (grub_get_time_ms () > endtime)
+	{
+	  err = GRUB_USB_ERR_STALL;
+	  grub_dprintf ("uhci", "transaction timed out\n");
+	  goto fail;
+	}
+      grub_cpu_idle ();
     }
 
   grub_dprintf ("uhci", "transaction complete\n");
@@ -573,6 +581,7 @@
   struct grub_uhci *u = (struct grub_uhci *) dev->data;
   int reg;
   unsigned int status;
+  grub_uint64_t endtime;
 
   grub_dprintf ("uhci", "enable=%d port=%d\n", enable, port);
 
@@ -595,6 +604,7 @@
   status = grub_uhci_readreg16 (u, reg);
   grub_uhci_writereg16 (u, reg, status & ~(1 << 9));
   grub_dprintf ("uhci", "reset completed\n");
+  grub_millisleep (10);
 
   /* Enable the port.  */
   grub_uhci_writereg16 (u, reg, enable << 2);
@@ -602,7 +612,10 @@
 
   grub_dprintf ("uhci", "waiting for the port to be enabled\n");
 
-  while (! (grub_uhci_readreg16 (u, reg) & (1 << 2)));
+  endtime = grub_get_time_ms () + 1000;
+  while (! (grub_uhci_readreg16 (u, reg) & (1 << 2)))
+    if (grub_get_time_ms () > endtime)
+      return grub_error (GRUB_ERR_IO, "UHCI Timed out");
 
   status = grub_uhci_readreg16 (u, reg);
   grub_dprintf ("uhci", ">3detect=0x%02x\n", status);

=== modified file 'bus/usb/usbhub.c'
--- bus/usb/usbhub.c	2009-07-16 22:14:09 +0000
+++ bus/usb/usbhub.c	2009-12-04 16:54:09 +0000
@@ -48,7 +48,7 @@
       if (! grub_usb_devs[i])
 	break;
     }
-  if (grub_usb_devs[i])
+  if (i == 128)
     {
       grub_error (GRUB_ERR_IO, "Can't assign address to USB device");
       return NULL;
@@ -60,6 +60,7 @@
 			 | GRUB_USB_REQTYPE_TARGET_DEV),
 			GRUB_USB_REQ_SET_ADDRESS,
 			i, 0, 0, NULL);
+
   dev->addr = i;
   dev->initialized = 1;
   grub_usb_devs[i] = dev;

=== modified file 'commands/usbtest.c'
--- commands/usbtest.c	2009-11-09 17:43:53 +0000
+++ commands/usbtest.c	2009-12-04 01:33:17 +0000
@@ -146,6 +146,7 @@
       usb_print_str ("Configuration:", dev, config->strconfig);
     }
 
+  if (dev->config[0].descconf)
   for (i = 0; i < dev->config[0].descconf->numif; i++)
     {
       int j;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: [solved] Re: USB device not seen by grub

[Chris Jones]

On Sat, Dec 05, 2009 at 04:16:45AM EST, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Chris Jones wrote:

[..]

> > Why do I have to enable tracing to make it work?
> >
> Because a dprintf acted as a forgotten millisleep. This patch should
> fix it. On my machine I still have issues because uhci.c has problems
> with second port

Excellent.

> > Also, is there any way I can run the grub command line on a system
> > that's already booted, so I can explore its possibities in a context
> > where I have internet access, browse documentation, etc..?
> >   
> I'm working on it but the current problem is that I haven't found a
> syscall in linux to get physical address of a page. Does anyone has a
> suggestion?

That would be great. The worst time to experiment and learn new tricks
is when you're in a fix and your system won't boot. Be prepared!

Thanks again for your help.

CJ

Re: [solved] Re: USB device not seen by grub

[Chris Jones]

On Sat, Dec 05, 2009 at 04:16:45AM EST, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Chris Jones wrote:

Hello Vladimir,

[..]

> > Also, is there any way I can run the grub command line on a system
> > that's already booted, so I can explore its possibities in a context
> > where I have internet access, browse documentation, etc..?
> >
> >   
> I'm working on it but the current problem is that I haven't found a
> syscall in linux to get physical address of a page. Does anyone has a
> suggestion?

Just curious as to whether anything came of this.

One thing further regarding booting a kernel that lives on a USB stick,
is that where it works fine when grub lives on the HDD, oddly enough, I
have not been able to boot that same kernel from a CD image created via
grub-mkrescue.

What I was trying to do is have some means of booting the USB stick in
the event the target machine has a bootable CD/DVD device and does not
let you boot off of a USB device.

When I leave the debug=uhci tracing on, I can see that it is generating
a few screenful of messages at:

  uhci.c:403 ..................

They're all basically the same as previously, giving some details like
flags settings, addresses, completion codes, etc. for what appear to be
USB 'transactions'.

This is followed by exactly three identical sequences of entries at
lines:

  uhci.c:478 ..................
  uhci.c:482 
  uhci.c:493 
  uhci.c:539 
  uhci.c:543

In turn this is followed by a branch back to uhci.c:403 where the same
messages as previously are displayed at the terminal.

I must have let this run for about a half hour and even without tracing,
the boot process never took off.

Again this does not occur when I used the copy of grub that lives on the
hard drive.

The CD images were created with each of the versions of grub that I have
on this machine, 1.96 that comes with debian 'lenny', 1.97 beta3, that
comes with debian 'squeeze' at least when I installed it about two
months ago, and 1.97 beta4 that calme with ubuntu 9.10.

Incidentally, I just checked the exact spelling of grub-mkrescue and
found that there is also a grub-mkimage, so maybe I'm using the wrong
script.

In any event, since I have pretty much abandoned this project of booting
off of a USB stick for the time being, I am not too concerned about this
being fixed or worked around, but I thought I might as well report that
I ran into this problem.

Thank you again for your help.

CJ

Re: USB device not seen by grub

[richardvoigt]

2009/12/3 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
> Chris Jones wrote:
>> I am trying to have grub boot off a partition on a USB stick.
>>
>>
> You can't chainload to disk invisible by BIOS. But you can load
> supported OSes from it.

What would be necessary to enable chainload to such devices?  Install
an IRQ 19 handler?  Invoke the extension ROM of the host adapter so
that it hooks IRQ 19?  Hook some other system calls?

Re: USB device not seen by grub

[Robert Millan]

On Thu, Dec 03, 2009 at 06:27:07PM -0600, richardvoigt@gmail.com wrote:
> 2009/12/3 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
> > Chris Jones wrote:
> >> I am trying to have grub boot off a partition on a USB stick.
> >>
> >>
> > You can't chainload to disk invisible by BIOS. But you can load
> > supported OSes from it.
> 
> What would be necessary to enable chainload to such devices?  Install
> an IRQ 19 handler?

Yeah, something like that.  In essence, GRUB acting as a BIOS.  Sounds awful,
but hey we already have "efiemu".

> Invoke the extension ROM of the host adapter so
> that it hooks IRQ 19?

There's usually no such ROM.  Except for adapters that come in discrete
PCI cards.  And even then, I doubt it's always present.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: USB device not seen by grub

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Robert Millan wrote:
> On Thu, Dec 03, 2009 at 06:27:07PM -0600, richardvoigt@gmail.com wrote:
>   
>> 2009/12/3 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>>     
>>> Chris Jones wrote:
>>>       
>>>> I am trying to have grub boot off a partition on a USB stick.
>>>>
>>>>
>>>>         
>>> You can't chainload to disk invisible by BIOS. But you can load
>>> supported OSes from it.
>>>       
>> What would be necessary to enable chainload to such devices?  Install
>> an IRQ 19 handler?
>>     
>
> Yeah, something like that.  In essence, GRUB acting as a BIOS.  Sounds awful,
> but hey we already have "efiemu".
>
>   
It's by far not the same thing. EfiEmu emulates only RuntimeServices.
EFI has two types of functions: BootServices and RuntimeServices.
BootServices are only available when boot loader is running and are
terminated on kernel launch. RuntimeServices are always available but
have very small number of functions. And actually GRUB acts only as a
loader to efiemu??.o and real functions are contained in efiemu??.o
which is quite small
For BIOS disks emulations we would need much more functions but we could
adopt a similar approach. E.g:
bioshook usbbios.o <parameters>
chainloader (usb0,1)+1
usbbiso.o may of course be compiled from GRUB files but has to be
standalone. There are few tricky parts associated with this process but
basically it would be an overblown drivemap.

But I don't see any real reason to make even small fraction of required
effort since GRUB2 is able to load many free OS directly and so can load
them of an BIOS-invisible disks without any problems. Some free OS are
still out of GRUB family like Minix is but I would gladly accept a port
of it (which is orders of magnitude easier to do)
As of proprietary OS I think we need to support them only to the etent
of what they are able to do themselves. Documentation on such OS are
often scarce and anything we do may completely break with new version.
And all of this only to make good to someone who would like to see every
free software die?



-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: USB device not seen by grub

[richardvoigt]

2009/12/4 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
> Robert Millan wrote:
>> On Thu, Dec 03, 2009 at 06:27:07PM -0600, richardvoigt@gmail.com wrote:
>>
>>> 2009/12/3 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>>>
>>>> Chris Jones wrote:
>>>>
>>>>> I am trying to have grub boot off a partition on a USB stick.
>>>>>
>>>>>
>>>>>
>>>> You can't chainload to disk invisible by BIOS. But you can load
>>>> supported OSes from it.
>>>>
>>> What would be necessary to enable chainload to such devices?  Install
>>> an IRQ 19 handler?
>>>
>>
>> Yeah, something like that.  In essence, GRUB acting as a BIOS.  Sounds awful,
>> but hey we already have "efiemu".
>>
>>
> It's by far not the same thing. EfiEmu emulates only RuntimeServices.
> EFI has two types of functions: BootServices and RuntimeServices.
> BootServices are only available when boot loader is running and are
> terminated on kernel launch. RuntimeServices are always available but
> have very small number of functions. And actually GRUB acts only as a
> loader to efiemu??.o and real functions are contained in efiemu??.o
> which is quite small
> For BIOS disks emulations we would need much more functions but we could
> adopt a similar approach. E.g:
> bioshook usbbios.o <parameters>
> chainloader (usb0,1)+1
> usbbiso.o may of course be compiled from GRUB files but has to be
> standalone. There are few tricky parts associated with this process but
> basically it would be an overblown drivemap.
>
> But I don't see any real reason to make even small fraction of required
> effort since GRUB2 is able to load many free OS directly and so can load
> them of an BIOS-invisible disks without any problems. Some free OS are
> still out of GRUB family like Minix is but I would gladly accept a port
> of it (which is orders of magnitude easier to do)
> As of proprietary OS I think we need to support them only to the etent
> of what they are able to do themselves. Documentation on such OS are
> often scarce and anything we do may completely break with new version.

SCSI adapter vendors manage to implement IRQ 19 in a way that provides
universal OS support, I don't see how this would be different.

> And all of this only to make good to someone who would like to see every
> free software die?

Not all supporters of free software share that philosophy, quite a few
of us like to be able to tell people "that proprietary software you
use, well, it works better with free software".  And sometimes free
software is enriched by playing well with closed-source.

For example, more people would dual-boot if there was a grub-tools
package for Windows and Mac OS that added "Reboot to linux" to the
start menu (by changing the default boot selection in the grub
config).  If grub-win existed which could install grub from inside
Windows, we'd have even more users of both grub and free OSes to
dual-boot with.  And a Windows driver that jumped directly to grub
code at an appropriate point during shutdown (i.e. after flushing disk
write caches, which is probably when anti-virus drivers unload)
thereby avoiding the BIOS POST delays and making dual-booting even
faster and less painless would equate to even more users.

I happen to have a licence for VMWare workstation 6.x which emulates a
USB host controller (IIRC devices include emulated mouse as well as
real devices attached to the host, including mass storage), but
doesn't support booting from it.  This annoyed me at one point when I
was trying to prepare a bootable USB stick and couldn't test it.  So
I'm willing to give this a shot.

Which Linux distribution do most of you use for grub development (I
value the fact that commands to install the correct version of bzr,
which I've not used before, were recently posted to the list).  That
was for Debian Lenny, but would I get started faster with another
version?  NB: I'm most experienced with gentoo, which is definitely
NOT a quick start.

Ben Voigt

Re: USB device not seen by grub

[Robert Millan]

On Fri, Dec 04, 2009 at 09:28:32PM -0600, richardvoigt@gmail.com wrote:
> > And all of this only to make good to someone who would like to see every
> > free software die?
> 
> Not all supporters of free software share that philosophy, quite a few
> of us like to be able to tell people "that proprietary software you
> use, well, it works better with free software".  And sometimes free
> software is enriched by playing well with closed-source.

Our standpoint is very clear: proprietary software restraints users; this
is unethical and therefore proprietary software should not exist.

However, we do support interoperation with proprietary software.  In fact
the Linux images that are loaded by GRUB include non-free firmware in them
more often than not.  And we also support systems that are entirely non-free.

When we do this, it is not a matter of principle but a matter of strategy.
MS Windows already has its own proprietary bootloader, and GRUB isn't even
capable of acting as a full replacement to it.  GRUB isn't helping Microsoft
build their proprietary OS (the GPL prevents this), so there's no benefit
in refusing to support it.

The situation is similar for e.g. MacOS X.

As for adding generic support for BIOS callbacks, I appreciate Vladimir's
remarks, and conclude that this needs to be considered carefully.  Even from
a purely technical point of view, I don't have a clear idea what it would be
used for.  Perhaps you can explain the situations on which you think this is
useful?

If you seek to persuade us, this is much more effective than the philosophical
debate, since our goals are already well stablished, and the only question
is whether this proposed feature helps us bring them further or does the
opposite instead.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: USB device not seen by grub

[richardvoigt]

On Fri, Dec 4, 2009 at 3:36 PM, Robert Millan <rmh@aybabtu.com> wrote:
> On Thu, Dec 03, 2009 at 06:27:07PM -0600, richardvoigt@gmail.com wrote:
>> 2009/12/3 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>> > Chris Jones wrote:
>> >> I am trying to have grub boot off a partition on a USB stick.
>> >>
>> >>
>> > You can't chainload to disk invisible by BIOS. But you can load
>> > supported OSes from it.
>>
>> What would be necessary to enable chainload to such devices?  Install
>> an IRQ 19 handler?
>
> Yeah, something like that.  In essence, GRUB acting as a BIOS.  Sounds awful,
> but hey we already have "efiemu".

As Vladimir says, the legacy grub "map" command must already be
installing such a hook (although it proxies implementation to the
existing BIOS after changing the drive number, rather than calling a
grub storage driver).

>
>> Invoke the extension ROM of the host adapter so
>> that it hooks IRQ 19?
>
> There's usually no such ROM.  Except for adapters that come in discrete
> PCI cards.  And even then, I doubt it's always present.

There are actually quite a lot of devices like this.  Most notebooks
have broken BIOS that won't load the extension ROM from a PCMCIA slot,
if grub could do so it would enable booting from a wide variety of
PCMCIA/CardBus/ExpressCard-to-SCSI/SATA/USB adapters.

Here's one example that I happen to own, and got frustrated with
system BIOS not allowing boot from expansion card:
http://www.newegg.com/Product/Product.aspx?Item=N82E16820161325&cm_re=SolidGO-_-20-161-325-_-Product

I'm fairly sure there is an extension BIOS because some people report
being able to boot from it, however most laptops cannot.

>
> --
> Robert Millan
>
>  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
>  how) you may access your data; but nobody's threatening your freedom: we
>  still allow you to remove your data and not access it at all."
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: USB device not seen by grub

[Robert Millan]

On Fri, Dec 04, 2009 at 04:45:01PM -0600, richardvoigt@gmail.com wrote:
> There are actually quite a lot of devices like this.  Most notebooks
> have broken BIOS that won't load the extension ROM from a PCMCIA slot,
> if grub could do so it would enable booting from a wide variety of
> PCMCIA/CardBus/ExpressCard-to-SCSI/SATA/USB adapters.

PCI ROM processing is a feature we need.  The reason we need this is
not to help proprietary OSes, but so that modules like vbe or biosdisk
can work on other platforms (e.g. coreboot).

The code in those ROMs is often proprietary, but it is external to the
motherboard.  This is important, because GRUB may act as the primary
firmware for PC-class motherboards (when combined with coreboot).  In
this kind of setup, GRUB itself can't support external cards using its
own drivers and must rely on the PCI ROM ones.  Therefore this interaction
is always needed.

Also, some platforms like EFI insist on acting as a wrapper between these
PCI ROM drivers and the bootloader.  Since this wrapper is completely useless
and just adding overhead, we might as well skip it.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."