Re: USB bulk transfert from GRUB ?

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

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