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.