(+Brad) Hi Krzysztof,
On 22 November 2013 14:15, Krzysztof Opasiak <[email protected]> wrote: [snip] > Let me summarize and please correct me if I'm wrong. We have a PC in > host mode and multiple devices with tizen in USB device mode. Typically. However from time to time these devices will be: a) re-flashed to upgrade to a newer tizen build b) automatically detached and re-attached to perform some task in a scenario more similar to normal usage (iow no cables) > We are > using sdb on the host and we would like to be able to communicate witch > each particular device directly. > yes, however during a) there will be some flashing tool at work, rather than sdb. At that time the device will not be executing tizen, but rather something else (ex: FW/ROM code) If above is true, it means that we would like to use sdb on a host with > -s option: > > $sdb -h > > -s <serial number> - directs command to the USB device or > emulator with the given serial number. > This will be true while the device is running tizen. > Serial number belongs to device descriptor (device strings exactly). So > the issue is that usb-manager should generate unique serials while first > system boot up and it should be configured in each gadget. This solution > is easy to apply but has some issues. How to ensure that Serials will be > globally unique? I men that some other Linux distribution would like to > also use sdb but without usb--manager? Maybe we should change sdb and > connect to <VendorID> <ProductID> <serial> not only to serial? What do > you think? Maybe there are other requirements which I don't know and > both solutions are wrong? > No, there is no need to generate anything. The SN is something that is typically generated and programmed at the factory, on the assembly line. In (some of) Intel platform it is made available as RO eMMC partition, through sysfs What the usb manager has to do is: read the value and write it back to the appropriate sysfs entry for the usb gadget. So the triplet <VendorID> <ProductID> <SN> should be unique, worldwide, and identify that specific physical device. This should be sufficient, from host PC side, to identify uniquely a certain target device, even when Tizen is not running, provided that the FW/BootROM exposes the same parameters. Most likely that will not be the case, but luckily the device should still expose at least the SN, which is typically long enough to ensure extremely low chances of collision. Ex: devices from different OEMs might have the same SN, but that's the same chance of having 2 random numbers of 8-10 digits to match. The only exception I can think of is when, at the very beginning of the development of a new product, even the SW used on the assembly line is not complete enough to be able to write the SN. In that case one gets a device with blank SN, but it's such a corner case that I would worry about it only if it should really happen and affect somebody. -- cheers, igor --------------------------------------------------------------------- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
