Hi Igor, > -----Original Message----- > From: Stoppa, Igor [mailto:[email protected]] > Sent: Friday, November 22, 2013 3:36 PM > To: Krzysztof Opasiak > Cc: Yang Chengwei; Taeyoung Kim; Krogerus, Heikki; > [email protected]; Brad T Peters > Subject: Re: [Dev] usb-manager: set correct usb gadget attributes > > (+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
Flash is done using ttyXACM not usb raw transport directly so there is no problem to address each target directly. When you connect two targets you will get ttyACM0 and ttyACM1 so the only thing we have to do is to write flash tool correctly so you can set which pseudo device you would like to use for flashing. > b) automatically detached and re-attached to perform some task in a > scenario > more similar to normal usage (iow no cables) > This scenario could be done using some extension to sdb. Tizen will use ConfigFS, we plan to provide API for usb gadgets management. One of the benefits of ConfigFS is that we can simply disable and enable gadget in a runtime when device is plugged in. So This scenario could be realized if sdb will be able to use this API and provide some extension to do this. For example sdb could simply execute $ gt disable sdb_gadget; sleep 5; gt enable sdb_gadget > 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) Please see above response. > 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. > I have spoken with my colleagues and they told me that this problem is not only in usb. There are other parts of system which needs unique numbers. Maybe there should be general solution made for this problem? The solution could be similar to this which you described, a special partition flashed in factory, but there are some problems. For example we should ensure that user will not be able to change the content of this partition even with rooted device. -- BR's Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics [email protected] _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
