USB bulk transfert from GRUB ?

USB bulk transfert from GRUB ?

[Nicolas de Pesloüan]

Hi,

Some USB devices require a specific command to be sent (using USB bulk transfer) before they switch
to "storage mode". Such devices are switched by USBmodeSwitch
(http://www.draisberghof.de/usb_modeswitch/), after the operating system start. USBmodeSwitch use
libusb to send the right command to the right USB endpoint, depending on the ID of the USB device.

In order to be able to boot from such devices, one needs to switch the device early, before the 
operating system is started. I think GRUB2 should be the right place for this.

For as far as I understand, libusb is available from inside GRUB2, so it shouldn't be really 
difficult to add a command to initiate a given bulk transfert to a given USB endpoint. (My 
understanding is that no such command already exists).

Contrary to USBModeSwitch that use a database at runtime to decide how to switch the device, it is 
probably easier to decide this at grub-mkconfig time, using the same database.

Of course, I perfectly understand that the first part of GRUB2 cannot be located from this kind of 
USB devices, because it needs to be loaded before GRUB2 start, and we would face a chicken and egg 
problem.

Any comments ?

	Nicolas.

Re: USB bulk transfert from GRUB ?

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

On 12/20/2010 09:12 PM, Nicolas de Pesloüan wrote:
> Hi,
>
> Some USB devices require a specific command to be sent (using USB bulk
> transfer) before they switch
> to "storage mode". Such devices are switched by USBmodeSwitch
> (http://www.draisberghof.de/usb_modeswitch/), after the operating
> system start. USBmodeSwitch use
> libusb to send the right command to the right USB endpoint, depending
> on the ID of the USB device.
>
> In order to be able to boot from such devices, one needs to switch the
> device early, before the operating system is started. I think GRUB2
> should be the right place for this.
>
> For as far as I understand, libusb is available from inside GRUB2, 
No it's not. We use our own routines for USB transfers. Have a look at
include/grub/usb.h. E.g:
grub_usb_err_t
grub_usb_bulk_write (grub_usb_device_t dev,
                     int endpoint, grub_size_t size, char *data);
> so it shouldn't be really difficult to add a command to initiate a
> given bulk transfert to a given USB endpoint. (My understanding is
> that no such command already exists).
grub_usb_bulk_write does exactly this. However it's not to be exported
as a command
>
> Contrary to USBModeSwitch that use a database at runtime to decide how
> to switch the device, it is probably easier to decide this at
> grub-mkconfig time, using the same database.
>
Doing any USB detection at grub-mkconfig time is a bad idea. USB is in
flux and you can't possibly know e.g. the address of target device on
runtime. On the other hand it should be easy to write a parser for
device_reference.txt. It's also probably easier to write something that
small from scratch than to port it (all the value is in the database,
not code). Another question is how much autoconfigured it should be.
Some people may prefer these devices be in non-storage mode as usually
the only thing they store are useless buggy drivers.
> Of course, I perfectly understand that the first part of GRUB2 cannot
> be located from this kind of USB devices, because it needs to be
> loaded before GRUB2 start, and we would face a chicken and egg problem.
>
> Any comments ?
>
>     Nicolas.
>
> _______________________________________________
> 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: 294 bytes --]

Re: USB bulk transfert from GRUB ?

[Nicolas de Pesloüan]

On 12/25/2010 01:38 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 12/20/2010 09:12 PM, Nicolas de Pesloüan wrote:

Hi Vladimir, thanks for your feedback.

>> Some USB devices require a specific command to be sent (using USB bulk
>> transfer) before they switch
>> to "storage mode". Such devices are switched by USBmodeSwitch
>> (http://www.draisberghof.de/usb_modeswitch/), after the operating
>> system start. USBmodeSwitch use
>> libusb to send the right command to the right USB endpoint, depending
>> on the ID of the USB device.
>>
>> In order to be able to boot from such devices, one needs to switch the
>> device early, before the operating system is started. I think GRUB2
>> should be the right place for this.
>>
>> For as far as I understand, libusb is available from inside GRUB2,
> No it's not. We use our own routines for USB transfers. Have a look at
> include/grub/usb.h. E.g:
> grub_usb_err_t
> grub_usb_bulk_write (grub_usb_device_t dev,
>                       int endpoint, grub_size_t size, char *data);

Ok, that sounds good, at least for a "small" try.

>> so it shouldn't be really difficult to add a command to initiate a
>> given bulk transfert to a given USB endpoint. (My understanding is
>> that no such command already exists).
> grub_usb_bulk_write does exactly this. However it's not to be exported
> as a command

Whould you support adding such command?

usb_bulk_write <usbid> <endpoint> <string>

>> Contrary to USBModeSwitch that use a database at runtime to decide how
>> to switch the device, it is probably easier to decide this at
>> grub-mkconfig time, using the same database.
>>
> Doing any USB detection at grub-mkconfig time is a bad idea. USB is in
> flux and you can't possibly know e.g. the address of target device on
> runtime. On the other hand it should be easy to write a parser for
> device_reference.txt.

Yes, you are right. I didn't plan to try and use a fixed USB address. But, it sounds reasonable to 
assume that, for a given user, the device is always the same (usb id). So, the usb id of the device, 
the endpoint number and the string to send to the endpoint could be selected at grub-mkconfig time 
and given as arguments to the grub command I plan to create.

> It's also probably easier to write something that small from scratch than to port it (all the
> value is in the database, not code). Another question is how much autoconfigured it should be.
> Some people may prefer these devices be in non-storage mode as usually the only thing they store
> are useless buggy drivers.

The kind of device I know provides two different modes:

- default mode, where the device is seen as a CD reader and gives access to a virtual CD that hold 
the Windows drivers for the device. (Mostly useless, from a non Windows point of view).
- switched mode, where the device is seen as a 3G modem plus a micro-SD card reader. I plan to boot 
from this micro-SD card.

 From a grub point of view, deciding to switch or to stay to the default mode depends on whether the 
"kernel" one plan to boot is located on a normal device or one a device that need to be switched 
prior to be usable.

So the switch command should only be incorporated into the menu entry that is designed to boot on 
the switchable device that hold the micro-SD card.

And by the way, it is possible to virtually "burn" an ISO image into the device, so it is possible 
to use the virtual CD reader to hold grub. But that is another story.

	Nicolas.

Re: USB bulk transfert from GRUB ?

[Vladimir 'φ-coder/phcoder' Serbinenko]

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


>>> so it shouldn't be really difficult to add a command to initiate a
>>> given bulk transfert to a given USB endpoint. (My understanding is
>>> that no such command already exists).
>> grub_usb_bulk_write does exactly this. However it's not to be exported
>> as a command
>
> Whould you support adding such command?
>
> usb_bulk_write <usbid> <endpoint> <string>
>
usb bus/address is assigned on runtime and depends on enumeration order
so no way to know it in advance for sure. If usbid = vendor/device id
then it's posssible although doesn't seem optimal. Which interface does
usb-modeswitch use?
>>> Contrary to USBModeSwitch that use a database at runtime to decide how
>>> to switch the device, it is probably easier to decide this at
>>> grub-mkconfig time, using the same database.
>>>
>> Doing any USB detection at grub-mkconfig time is a bad idea. USB is in
>> flux and you can't possibly know e.g. the address of target device on
>> runtime. On the other hand it should be easy to write a parser for
>> device_reference.txt.
>
> Yes, you are right. I didn't plan to try and use a fixed USB address.
> But, it sounds reasonable to assume that, for a given user, the device
> is always the same (usb id). So, the usb id of the device, the
> endpoint number and the string to send to the endpoint could be
> selected at grub-mkconfig time and given as arguments to the grub
> command I plan to create.
>
I still don't a clear grasp of target usecases and hence of the
appropriate ways to autoconfig.
>> It's also probably easier to write something that small from scratch
>> than to port it (all the
>> value is in the database, not code). Another question is how much
>> autoconfigured it should be.
>> Some people may prefer these devices be in non-storage mode as
>> usually the only thing they store
>> are useless buggy drivers.
>
> The kind of device I know provides two different modes:
>
> - default mode, where the device is seen as a CD reader and gives
> access to a virtual CD that hold the Windows drivers for the device.
> (Mostly useless, from a non Windows point of view).
> - switched mode, where the device is seen as a 3G modem plus a
> micro-SD card reader. I plan to boot from this micro-SD card.
>
> From a grub point of view, deciding to switch or to stay to the
> default mode depends on whether the "kernel" one plan to boot is
> located on a normal device or one a device that need to be switched
> prior to be usable.
>
> So the switch command should only be incorporated into the menu entry
> that is designed to boot on the switchable device that hold the
> micro-SD card.
Interesting possibility. Perhaps such devices could be scanned on
runtime and we look at present files.
>
> And by the way, it is possible to virtually "burn" an ISO image into
> the device, so it is possible to use the virtual CD reader to hold
> grub. But that is another story.
>
I've vaguely heard that this way you can actually change the device
firmware so I wouldn't exepriment with this unless I can allow myself
brick the device in question (I actually have one such device)
>     Nicolas.
>


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



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

Re: USB bulk transfert from GRUB ?

[Nicolas de Pesloüan]

On 12/25/2010 09:13 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:

>> Whould you support adding such command?
>>
>> usb_bulk_write <usbid>  <endpoint>  <string>
>>
> usb bus/address is assigned on runtime and depends on enumeration order
> so no way to know it in advance for sure. If usbid = vendor/device id
> then it's posssible although doesn't seem optimal. Which interface does
> usb-modeswitch use?

Yes, usbid is vendor/device id.

usb-modeswitch uses vendor/device id to detect switchable devices.

Depending on the device, the way to switch might change. Some devices simply require an SCSI eject 
command to switch. Most require a bulk transfer of a given string. Some require extra stuff.

>> Yes, you are right. I didn't plan to try and use a fixed USB address.
>> But, it sounds reasonable to assume that, for a given user, the device
>> is always the same (usb id). So, the usb id of the device, the
>> endpoint number and the string to send to the endpoint could be
>> selected at grub-mkconfig time and given as arguments to the grub
>> command I plan to create.
>>
> I still don't a clear grasp of target usecases and hence of the
> appropriate ways to autoconfig.

I propose to try on a "non-autoconfig" way, then decide later if we can find a good way to 
autoconfig things.

>> The kind of device I know provides two different modes:
>>
>> - default mode, where the device is seen as a CD reader and gives
>> access to a virtual CD that hold the Windows drivers for the device.
>> (Mostly useless, from a non Windows point of view).
>> - switched mode, where the device is seen as a 3G modem plus a
>> micro-SD card reader. I plan to boot from this micro-SD card.
>>
>>  From a grub point of view, deciding to switch or to stay to the
>> default mode depends on whether the "kernel" one plan to boot is
>> located on a normal device or one a device that need to be switched
>> prior to be usable.
>>
>> So the switch command should only be incorporated into the menu entry
>> that is designed to boot on the switchable device that hold the
>> micro-SD card.
> Interesting possibility. Perhaps such devices could be scanned on
> runtime and we look at present files.

By "look at present files", do you mean "look at the files in the ISO image"?

>> And by the way, it is possible to virtually "burn" an ISO image into
>> the device, so it is possible to use the virtual CD reader to hold
>> grub. But that is another story.
>>
> I've vaguely heard that this way you can actually change the device
> firmware so I wouldn't exepriment with this unless I can allow myself
> brick the device in question (I actually have one such device)

The device I own (made by Option) support two totally different update parts and corresponding 
update softwares:

- One is the firmware, and I don't plan to update it, even if the software to do so is easily available.
- One is the ISO image for the virtual CD reader. The software to update the ISO image is apparently 
no more available, but I have a copy of it. The software is designed to update the Windows drivers 
provided by the device.

I successfully "burn" a new ISO image, in eltorito format, that have GRUB and /boot inside. /boot 
contains the kernel and an enhanced initrd image to be able to switch the device, before accessing / 
from the micro-SD. All this work. The only problem is that every time I upgrade the kernel (/boot), 
I need to build and burn the ISO image again.

In would prefer to only have a reasonably stable version of grub in the ISO image, that only switch 
the device, then chainload to another grub, located on the micro-SD. This would require far less 
frequent updates of the ISO image. This would also allow for normal operation for everything on the 
micro-SD, including a fresh version of grub if necessary.

Of course, if someone want to do some reverse engineering on the "burning" software, then it might 
become far more convenient to "burn" the ISO image, removing the need for grub to be able to switch.

But a more general framework to initiate a bulk transfer would allow for more devices to be 
supported, including those which lack the ability to update the ISO image.

	Nicolas.

Re: USB bulk transfert from GRUB ?

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

On 12/25/2010 11:32 PM, Nicolas de Pesloüan wrote:
>
> usb-modeswitch uses vendor/device id to detect switchable devices.
>
I understand how it works, I meant how do you control it?
> Depending on the device, the way to switch might change. Some devices
> simply require an SCSI eject command to switch. Most require a bulk
> transfer of a given string. Some require extra stuff.
>
usbms can send arbitrary SCSI command.
>> I still don't a clear grasp of target usecases and hence of the
>> appropriate ways to autoconfig.
>
> I propose to try on a "non-autoconfig" way, then decide later if we
> can find a good way to autoconfig things.
>
It's ok to do thing partially or non-autoconf but it should be done in a
way to avoid of being stuck with inconvenient interface because once a
command added it can't e removed.Interesting possibility. Perhaps such
devices could be scanned on
>> runtime and we look at present files.
>
> By "look at present files", do you mean "look at the files in the ISO
> image"?
>
Yes. Perhaps even:
look for disk with UUID=myUUID
if failed switch device, look again.
How much overhead is switching?
> The device I own (made by Option) support two totally different update
> parts and corresponding update softwares:
>
Wouldn't it be a HSPA modem? Swisscom by any chance? I had one of those
but itbroke when I've put my laptop into the bag with the modem still in
USB port.
> - One is the firmware, and I don't plan to update it, even if the
> software to do so is easily available.
> - One is the ISO image for the virtual CD reader. The software to
> update the ISO image is apparently no more available, but I have a
> copy of it. The software is designed to update the Windows drivers
> provided by the device.
>
> I successfully "burn" a new ISO image, in eltorito format, that have
> GRUB and /boot inside. /boot contains the kernel and an enhanced
> initrd image to be able to switch the device, before accessing / from
> the micro-SD. All this work. The only problem is that every time I
> upgrade the kernel (/boot), I need to build and burn the ISO image again.
>
> In would prefer to only have a reasonably stable version of grub in
> the ISO image, that only switch the device, then chainload to another
> grub, 
Even if you make the USB device switch BIOS still won't see the new
device (very few BIOSes support hotplug). Moreover it's a bad idea to
revert to BIOS routines once you started sending direct USB/ATA/AHCI
messages. While some form of chainloading (using multiboot) is still
possible in this config I recommend against it. Just make GRUB on ISO
boot linux on microSD. Current GRUB should be compatible with future linuxes
> Of course, if someone want to do some reverse engineering on the
> "burning" software, then it might become far more convenient to "burn"
> the ISO image, removing the need for grub to be able to switch.
>
It's outside of GRUB scope.
> But a more general framework to initiate a bulk transfer would allow
> for more devices to be supported, including those which lack the
> ability to update the ISO image.
>
>     Nicolas.
>


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



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

Re: USB bulk transfert from GRUB ?

[Nicolas de Pesloüan]

On 12/26/2010 00:25 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 12/25/2010 11:32 PM, Nicolas de Pesloüan wrote:
>>
>> usb-modeswitch uses vendor/device id to detect switchable devices.
>>
> I understand how it works, I meant how do you control it?

Sorry, but I don't understand your question. I don't "control" usb-modeswitch nor "control" de 
device. udev, when detecting the device, calls the usb-modeswitch executable, that in turn switchs 
the device based on it vendor/device id and a database of the well known devices that need to be 
switched. If I don't want the device to be switched, I need to remove the udev rule for the device.

>> Depending on the device, the way to switch might change. Some devices
>> simply require an SCSI eject command to switch. Most require a bulk
>> transfer of a given string. Some require extra stuff.
>>
> usbms can send arbitrary SCSI command.

Yes, but unfortunately, the device I own is not switched by the SCSI eject command, but by a 
proprietary (non-SCSI) command sent using USB bulk transfer.

>> I propose to try on a "non-autoconfig" way, then decide later if we
>> can find a good way to autoconfig things.
>>
> It's ok to do thing partially or non-autoconf but it should be done in a
> way to avoid of being stuck with inconvenient interface because once a
> command added it can't e removed.

Of course, I'm currently at the "proof of concept" stage, and don't plan to have anything 
incorporated into the standard GRUB distribution until we find the right way to do it.

>> By "look at present files", do you mean "look at the files in the ISO
>> image"?
>>
> Yes. Perhaps even:
> look for disk with UUID=myUUID
> if failed switch device, look again.
> How much overhead is switching?

Interesting. Do you mean that is might be better to add an extra option to the search command, for 
example "--switch-on-failure"? And use the usb-modeswitch database inside the search command, to do 
whatever is required to switch devices?

This may lead to switching several devices (if several are connected at boot time), which might be 
undesirable. I think we should avoid switching any device except the one(s) which is/are clearly 
necessary to access the volume(s) we plan to boot from. Other devices would be switched later, by 
the operating system, if appropriate.

So I think we need two different options for search command :

--switch-all
--switch vendor-id:device-id

The first (and most used) one would switch all switchable device before search (or after a first 
failed search).
The second one would switch only a particular device and would be used for the arguably very special 
case where we don't want all switchable devices to be switched.

The overhead of switching is not really major but not negligible. From a system point of view, it is 
seen a unpluging an USB device and pluging another one.

>> The device I own (made by Option) support two totally different update
>> parts and corresponding update softwares:
>>
> Wouldn't it be a HSPA modem? Swisscom by any chance? I had one of those
> but itbroke when I've put my laptop into the bag with the modem still in
> USB port.

The device I own is a Vodafone K3760, which really is an Option Icon 411:

http://www.option.com/en/products/products/usb-modems/icon411/

>> In would prefer to only have a reasonably stable version of grub in
>> the ISO image, that only switch the device, then chainload to another
>> grub,
> Even if you make the USB device switch BIOS still won't see the new
> device (very few BIOSes support hotplug). Moreover it's a bad idea to
> revert to BIOS routines once you started sending direct USB/ATA/AHCI
> messages. While some form of chainloading (using multiboot) is still
> possible in this config I recommend against it. Just make GRUB on ISO
> boot linux on microSD. Current GRUB should be compatible with future linuxes

If I properly understand, you recommend not to chainload to another grub (because chainload uses 
BIOS int13h ?), but there is no problem directly booting the OS in the micro-SD from GRUB on the 
ISO. Right ? The only point is that I need to "burn" an new ISO if I want to upgrade GRUB or change 
de grub.cfg file.

>> Of course, if someone want to do some reverse engineering on the
>> "burning" software, then it might become far more convenient to "burn"
>> the ISO image, removing the need for grub to be able to switch.
>>
> It's outside of GRUB scope.

Yes, I know. Unfortunately, I think few people would have the time and the required skill to do so.

	Nicolas.

Re: USB bulk transfert from GRUB ?

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

On 12/26/2010 11:26 AM, Nicolas de Pesloüan wrote:
> On 12/26/2010 00:25 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> On 12/25/2010 11:32 PM, Nicolas de Pesloüan wrote:
>>>
>>> usb-modeswitch uses vendor/device id to detect switchable devices.
>>>
>> I understand how it works, I meant how do you control it?
>
> Sorry, but I don't understand your question. I don't "control"
> usb-modeswitch nor "control" de device. udev, when detecting the
> device, calls the usb-modeswitch executable, that in turn switchs the
> device based on it vendor/device id and a database of the well known
> devices that need to be switched. If I don't want the device to be
> switched, I need to remove the udev rule for the device.
>
That's what I wanted to know. So you modify udev rules to control the
behaviour of switching. Not really applicable to GRUB. Perhaps one would
use a reduced database with only the devices one wants to switch?
>>> By "look at present files", do you mean "look at the files in the ISO
>>> image"?
>>>
>> Yes. Perhaps even:
>> look for disk with UUID=myUUID
>> if failed switch device, look again.
>> How much overhead is switching?
>
> Interesting. Do you mean that is might be better to add an extra
> option to the search command, for example "--switch-on-failure"? And
> use the usb-modeswitch database inside the search command, to do
> whatever is required to switch devices?
>
> This may lead to switching several devices (if several are connected
> at boot time), which might be undesirable. I think we should avoid
> switching any device except the one(s) which is/are clearly necessary
> to access the volume(s) we plan to boot from. Other devices would be
> switched later, by the operating system, if appropriate.
>
> So I think we need two different options for search command :
>
> --switch-all
> --switch vendor-id:device-id
>
> The first (and most used) one would switch all switchable device
> before search (or after a first failed search).
> The second one would switch only a particular device and would be used
> for the arguably very special case where we don't want all switchable
> devices to be switched.
>
> The overhead of switching is not really major but not negligible. From
> a system point of view, it is seen a unpluging an USB device and
> pluging another one.
>
>>> The device I own (made by Option) support two totally different update
>>> parts and corresponding update softwares:
>>>
>> Wouldn't it be a HSPA modem? Swisscom by any chance? I had one of those
>> but itbroke when I've put my laptop into the bag with the modem still in
>> USB port.
>
> The device I own is a Vodafone K3760, which really is an Option Icon 411:
>
> http://www.option.com/en/products/products/usb-modems/icon411/
>
Probably the same as swisscom one.
>>> In would prefer to only have a reasonably stable version of grub in
>>> the ISO image, that only switch the device, then chainload to another
>>> grub,
>> Even if you make the USB device switch BIOS still won't see the new
>> device (very few BIOSes support hotplug). Moreover it's a bad idea to
>> revert to BIOS routines once you started sending direct USB/ATA/AHCI
>> messages. While some form of chainloading (using multiboot) is still
>> possible in this config I recommend against it. Just make GRUB on ISO
>> boot linux on microSD. Current GRUB should be compatible with future
>> linuxes
>
> If I properly understand, you recommend not to chainload to another
> grub (because chainload uses BIOS int13h ?), but there is no problem
> directly booting the OS in the micro-SD from GRUB on the ISO. Right ?
Right
> The only point is that I need to "burn" an new ISO if I want to
> upgrade GRUB or change de grub.cfg file.
>
you can even have grub.cfg on microSD using configfile directive.

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



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

Re: USB bulk transfert from GRUB ?

[Nicolas de Pesloüan]

Le 26/12/2010 11:47, Vladimir 'φ-coder/phcoder' Serbinenko a écrit :

>> If I don't want the device to be switched, I need to remove the udev rule for the device.

> That's what I wanted to know. So you modify udev rules to control the behaviour of switching. Not
> really applicable to GRUB. Perhaps one would use a reduced database with only the devices one
> wants to switch?

This is the reason why I suggested to give the vendor/device id, end-point number and string as 
arguments. Because only few users will have several different switchable devices and probably fewer 
will have several they plan to boot from.

I think we can reasonably discover the particular switchable and bootable device a grub-mkconfig 
time and put the single (vendor-id, device-id, end-point-number, switch-string) in grub.cfg :

usb_bulk_write --vendor 0x0af0 --device 0x7501 --endpoint 0 \
	--string 0x55534243785634120100000080000601000000000000000000000000000000

(example from /etc/usb_modeswitch.d/0af0:7501)

>> The only point is that I need to "burn" an new ISO if I want to upgrade GRUB or change de
>> grub.cfg file.
>>
> you can even have grub.cfg on microSD using configfile directive.

You mean, by using configfile by hand from the grub prompt? Or by having a small grub.cfg in the 
ISO, that only switch the device, then use configfile to load grub.cfg from the micro-SD?

	Nicolas.

Re: USB bulk transfert from GRUB ?

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

On 12/26/2010 12:46 PM, Nicolas de Pesloüan wrote:
> Le 26/12/2010 11:47, Vladimir 'φ-coder/phcoder' Serbinenko a écrit :
>
>>> If I don't want the device to be switched, I need to remove the udev
>>> rule for the device.
>
>> That's what I wanted to know. So you modify udev rules to control the
>> behaviour of switching. Not
>> really applicable to GRUB. Perhaps one would use a reduced database
>> with only the devices one
>> wants to switch?
>
> This is the reason why I suggested to give the vendor/device id,
> end-point number and string as arguments. Because only few users will
> have several different switchable devices and probably fewer will have
> several they plan to boot from.
>
> I think we can reasonably discover the particular switchable and
> bootable device a grub-mkconfig time and put the single (vendor-id,
> device-id, end-point-number, switch-string) in grub.cfg :
>
> usb_bulk_write --vendor 0x0af0 --device 0x7501 --endpoint 0 \
>     --string
> 0x55534243785634120100000080000601000000000000000000000000000000
>
> (example from /etc/usb_modeswitch.d/0af0:7501)
>
How exactly do we do it on mkconfig time? What prevents doing it on runtime?
>>> The only point is that I need to "burn" an new ISO if I want to
>>> upgrade GRUB or change de
>>> grub.cfg file.
>>>
>> you can even have grub.cfg on microSD using configfile directive.
>
> You mean, by using configfile by hand from the grub prompt? Or by
> having a small grub.cfg in the ISO, that only switch the device, then
> use configfile to load grub.cfg from the micro-SD?
>
The second
>     Nicolas.
>


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



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

Re: USB bulk transfert from GRUB ?

[Nicolas de Pesloüan]

Le 26/12/2010 13:05, Vladimir 'φ-coder/phcoder' Serbinenko a écrit :

>> I think we can reasonably discover the particular switchable and
>> bootable device a grub-mkconfig time and put the single (vendor-id,
>> device-id, end-point-number, switch-string) in grub.cfg :
>>
>> usb_bulk_write --vendor 0x0af0 --device 0x7501 --endpoint 0 \
>>      --string
>> 0x55534243785634120100000080000601000000000000000000000000000000
>>
>> (example from /etc/usb_modeswitch.d/0af0:7501)
>>
> How exactly do we do it on mkconfig time? What prevents doing it on runtime?

Thinking about it for long, I don't really know which of mkconfig time or runtime is the best.

##### mkconfig time #####

I originally thought I would simply add the required switch command into some menuentry in grub.cfg, 
to switch the device, if the volume is located on a well known switchable device.

In prepare_grub_to_access_device() (in /usr/lib/grub/grub-mkconfig_lib), one can add some commands 
(or options to the search command), to switch the device, if the device that hold the boot volume is 
known to be switchable.

I also thought grub-probe might be enhanced (in probe() function) to query the vendor/product id of 
the underlying physical device and look for those vendor/product id in the usb_modeswitch database, 
then report "switchable" as an abstraction.

But, having a closer look at it, I now understand that this would require crossing all the levels 
down to the physical device, which might be a little tricky. (I don't know, may be it is something 
already done somewhere).

##### runtime #####

Nothing prevent selecting the right switch string and end-point at run time, based on the 
vendor/product id and the usb_modeswitch database. This is exactly what usb_modeswitch do. It might 
even be possible to share part of the code between usb_modeswitch and the GRUB counterpart, only 
changing the function calls from libusb to GRUB usb library. (Of course, the license for 
usb_modeswitch should be double checked before).

But we need to have a way to decide which device to switch and which not to switch, based on whether 
we need this particular device to boot. Again, switching a device early might lead to some problem 
later, in the operating system. For example, if we boot Windows from GRUB, having the Option device 
connected (and switched by GRUB), then Windows won't have access to the driver (which is located on 
the virtual CD), preventing the installation of this driver.

But here, we face a chicken and egg problem: In order to know a given device should be switched, we 
need to search the UUID (ou label or whatever) in this device.

##########

May be I walk the wrong way. It might be enough to add "usb_modeswitch" to GRUB_PRELOAD_MODULES in 
/etc/default/grub if one plan to boot from a switchable device, and let the "usb_modeswitch" module 
switch all known devices at runtime. This assume people able to build such a boot environment are 
not in trouble with installing the Windows driver by hand if they use Windows...

Or may be we can just add the switch feature in all menuentry except those clearly linked to Windows 
in 30_os-prober, assuming that switching early cannot cause trouble to any OS except Windows.

I don't know...

	Nicolas.

Re: USB bulk transfert from GRUB ?

[Nicolas de Pesloüan]

Le 26/12/2010 17:39, Nicolas de Pesloüan a écrit :
> Le 26/12/2010 13:05, Vladimir 'φ-coder/phcoder' Serbinenko a écrit :
>
>>> I think we can reasonably discover the particular switchable and
>>> bootable device a grub-mkconfig time and put the single (vendor-id,
>>> device-id, end-point-number, switch-string) in grub.cfg :
>>>
>>> usb_bulk_write --vendor 0x0af0 --device 0x7501 --endpoint 0 \
>>> --string
>>> 0x55534243785634120100000080000601000000000000000000000000000000
>>>
>>> (example from /etc/usb_modeswitch.d/0af0:7501)
>>>
>> How exactly do we do it on mkconfig time? What prevents doing it on
>> runtime?
>
> Thinking about it for long, I don't really know which of mkconfig time
> or runtime is the best.

<snip>

> May be I walk the wrong way. It might be enough to add "usb_modeswitch"
> to GRUB_PRELOAD_MODULES in /etc/default/grub if one plan to boot from a
> switchable device, and let the "usb_modeswitch" module switch all known
> devices at runtime. This assume people able to build such a boot
> environment are not in trouble with installing the Windows driver by
> hand if they use Windows...

Thinking about it again and talking with the author of usb_modeswitch:

Let's switch all known switchable devices at runtime, through an "usb_modeswitch" module, as 
proposed just above.

If the device is required, to boot, it will be switched and that's the expected effect. And for the 
very limited case where we would unnecessary switch some devices, the user still have the option not 
to plug them at boot time. We talk about removable device, after all...

So, I will try and develop an usb_modeswitch module. By the way, is it possible and advisable to 
provide external module to GRUB ? I mean, the usb_modeswitch GRUB module should probably be part of 
usb_modeswitch, not part of GRUB2...

	Nicolas.+