Re: USB bulk transfert from GRUB ?

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- 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 --]