Re: [Libusbx-devel] [PATCH] Samples: Add FX2/FX3 firmware upload to RAM
Hi Pete, my answers became a bit longer than intended. Here's my 5 cent, but generally, I'd leave the decision to you: > Now, this being said, I don't have that much of an issue bumping the > limit, but 4K seems awfully large for a file path. Would 512 bytes > be OK with you? I'm perfectly ok with that. > >Furthermore, as the FX3 files are expected to come as an .img > >file, I'd suggest not to use "data.bin" as default file name > >(I'd rather opt for no default filename at all for FX2/FX3). > > And the FX2 ones come as .bix, so if we wanted to satisfy everyone, > we'd need a .bin for the mass storage dump, .bix for FX2 and .img > for FX3, plus the logic that goes with it. Except it's a sample, so > we might as well keep things simple. > > Likewise, you'll see that I reused the data.bin section we already > had for the -b option, which was optional, so that's the reason why > it's still optional for the FXes. If you think it's preferable, I > can make the filename mandatory of all of -b|f|g, but I didn't see > it as a major point and it helped minimizing the diff. I see what you mean. But from a usability standpoint I would opt for mentioning at least the suffix the firmware is expected to have for a given Cypress board. This relieves the forum from answering basic questions on the one hand and saves firmware developers from reading the xusb code for understanding the transfer. So I would at least mention the designated firmware file suffix in the command description. For the FX3, I did some searching myself until it was clear to me that only the Cypress generated .img file format is supported due to the preamble it provides [2]. I consider mandatory filenames more sensible than a random one, as said. > >As for upload vs. download, this seems to be a matter of taste. > > From my experience, the hardware development crowd tends to > >prefer download when flashing firmware to a device. > > I'd say you should always consider users who aren't familiar with > the operation first and foremost, as they're the ones for whom the > terminology will matter. > > If it goes from PC to an external device, and the program that is > run by the end user to perform the data transfer executes on the PC > (or, in a more general manner, if the environment where the end user > is going to actively perform actions is not the target), then, as > far as I'm concerned, it should logically be labelled as an upload. I don't have much of a preference here, since both parties arguments are valid in my opinion. The final reason I chose download in favor of upload was that the Cypress docs do so as well [1]. All the best, /Markus [1] "Getting Started with FX3 SDK.pdf" (as part of the SDK install) [2] http://www.cypress.com/?app=forum&id=167&rID=53996 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Handles for Windows WaitForXXX API?
Peter, On 09/08/2012 02:53, Peter Stuge wrote: > g...@novadsp.com wrote: > > Another point is that the code is absolutely unportable, which kindof > misses one big point of using the portable libusb-1.0 API. Indeed. Not an issue here. > No good since there can be no data from device until you initiate a > transfer. ? err, no. My device might well start to write back down the pipe as soon as it has been configured. Jerry -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Handles for Windows WaitForXXX API?
g...@novadsp.com wrote: > > No good since there can be no data from device until you initiate a > > transfer. > > ? err, no. My device might well start to write back down the pipe as > soon as it has been configured. That would be a violation of the USB protocol. What device controller are you using? Most of them interrupt when they are asked by the host to transfer data, and then your main firmware hands over whatever data is ready to be transmitted to the (internal or external) USB device controller. The device controller is not allowed to transmit on the wire until the host controller instructs it to. The misunderstanding is common. Bus communication is explained in chapters 5 and 8 of the USB 2.0 spec, they are really readable and I recommend reading through them. //Peter -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Handles for Windows WaitForXXX API?
Hello Pete On 09/08/2012 15:33, Peter Stuge wrote: >> >> ? err, no. My device might well start to write back down the pipe as >> soon as it has been configured. > > That would be a violation of the USB protocol. > My bad. Sloppy phrasing. Configured as in 'told what to do'. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Handles for Windows WaitForXXX API?
g...@novadsp.com wrote: > Hello Pete (Note that Pete is another guy. :) > >> ? err, no. My device might well start to write back down the pipe as > >> soon as it has been configured. > > > > That would be a violation of the USB protocol. > > My bad. Sloppy phrasing. Configured as in 'told what to do'. The key point is that it isn't told to transmit (by the host controller) until you tell the host controller (via libusb or another API) that you want data from the device. //Peter -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Handles for Windows WaitForXXX API?
g...@novadsp.com wrote: >> No good since there can be no data from device until you initiate a >> transfer. > ? err, no. My device might well start to write back down the pipe as > soon as it has been configured. No, although it may be a matter of semantics. Your device can queue up data to be sent, but it is not allowed to put anything on the wire until it gets an IN token from the host, and that will only happen if the host controller driver has a pending request from you. If you don't ask for it, the device is never given the opportunity to send. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusb segfaults - causes pcscd to crash
On 2012.08.09 11:31, sebasti...@gmx-topmail.de wrote: > Maybe we got the jackpot (at least I hope so)?! My test computer finally > showed the segmentation fault today morning. Good. The more data we get, the better we'll be able to fix the issue. > You'll find all information in the attached file! (I limited the debug > information of libusbx to the last 12 seconds before the crash happened.) > > The last lines in the libusbx output file: > Aug 9 06:11:02 logger: [144215.086624] [0393] libusbx: debug > [usbi_handle_transfer_completion] transfer 0xb640049c has callback 0xfd71fb > Aug 9 06:11:02 logger: [144215.086653] [0393] libusbx: debug > [bulk_transfer_cb] actual_length=17 > Aug 9 06:11:02 logger: [144215.086750] [0393] libusbx: debug > [add_to_flying_list] arm timerfd for timeout in 500ms (first in line) > Aug 9 06:11:02 logger: [144215.086785] [0393] libusbx: warning > [add_to_flying_list] failed to arm first timerfd (error -1) OK, first thing I notice is that the timerfd report is output as a warning rather than debug, so if your test machine is behaving the same way as your other server, it means that you have silenced warnings there, which I'd strongly recommend against. To confirm that the timerfd_settime() is the call that's causing us an issue, can you please try to set your production servers to at least output warning messages? The expectation is that, unlike debug, warnings aren't going to clog your log, and as you can see above, they can give precious clues as to where libusbx is not behaving nominally, and why. I'd strongly recommend to have libusbx logging set to at least warning level (or info) if you can. You don't even have to recompile libusbx. Just make sure that the environment variable LIBUSB_DEBUG is set to 2 (Warning) or 3 (INFO) before starting pcscd. Now, unfortunately, we don't display errno on error (we'll need to patch that), so we just get an indication that timerfd_settime() failed. I'll try to push a patch to make sure we get errno displayed. In the meantime, I'd encourage you to change line 1207 in io.c from: usbi_warn(ctx, "failed to arm first timerfd (error %d)", r); to usbi_warn(ctx, "failed to arm first timerfd (errno %d)", errno); Now, to the possible causes, according to the man page [1]: timerfd_settime() can fail with the following errors: o EBADF fd is not a valid file descriptor. o EINVAL fd is not a valid timerfd file descriptor. Doubtful, as it would mean we've messed up our ctx structure. o EINVAL flags is invalid. We pass TFD_TIMER_ABSTIME as a constant for flags, so no. o EFAULT new_value or old_value is not valid a pointer. Well, that's an interesting one, considering we always use NULL for old_value in our call [2]. Maybe this needs to be a valid pointer after all? But then it's kind of puzzling it wouldn't fail every time... o EINVAL new_value is not properly initialized (one of the tv_nsec falls outside the range zero to 999,999,999). I don't see that as a likely, but we may want to print these values just in case, when timerfd_settime() fails. To do that, you can add the following line after the one I mentioned above: usbi_warn(ctx, "it.it_value = %d:%d)", it.it_value.tv_sec, it.it_value.tv_nsec); Now, I'm hoping that you can apply these changes to your production server, as well as set your logging to WARN there. Hopefully, we'll catch a "failed to arm first timerfd" that will give us more clues. If we get an EFAULT, then we'll know how we're supposed to patch this issue. Regards, /Pete [1] http://www.kernel.org/doc/man-pages/online/pages/man2/timerfd_create.2.html [2] https://github.com/libusbx/libusbx/blob/master/libusb/io.c#L1205 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Samples: Add FX2/FX3 firmware upload to RAM
On Thu, Aug 9, 2012 at 3:01 AM, Markus wrote: > Hi Pete, > > my answers became a bit longer than intended. Here's my 5 cent, > but generally, I'd leave the decision to you: > >> Now, this being said, I don't have that much of an issue bumping the >> limit, but 4K seems awfully large for a file path. Would 512 bytes >> be OK with you? > > I'm perfectly ok with that. You should use PATH_MAX from limits.h period. POSIX says it should be there on *nix and it is also there on windows, being equal to MAX_PATH+1 iirc. Its 4K on linux but its also what the the libc is going to assume so you know you won't run into issues. Hardcoding anything smaller is just asking for issues especially on sample code that people are likely to just Copy/Paste into their projects. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH] Samples: Add FX2/FX3 firmware upload to RAM
On Thu, Aug 9, 2012 at 4:57 PM, Jon Sturm wrote: > On Thu, Aug 9, 2012 at 3:01 AM, Markus wrote: > > Hi Pete, > > > > my answers became a bit longer than intended. Here's my 5 cent, > > but generally, I'd leave the decision to you: > > > >> Now, this being said, I don't have that much of an issue bumping the > >> limit, but 4K seems awfully large for a file path. Would 512 bytes > >> be OK with you? > > > > I'm perfectly ok with that. > > You should use PATH_MAX from limits.h period. POSIX says it should be > there on *nix and it is also there on windows, being equal to > MAX_PATH+1 iirc. Its 4K on linux but its also what the the libc is > going to assume so you know you won't run into issues. Hardcoding > anything smaller is just asking for issues especially on sample code > that people are likely to just Copy/Paste into their projects. > It's only defined if _POSIX_ is set in the limits.h from Visual Studio 2010 and then it's defined to 512 so I wouldn't be counting on it being defined sensibly for Windows (where MAX_PATH+1 is your best bet... unless of course you prefix all your paths with "\\?\" and make sure all '/'s are switched to '\'s when the limit is somewhere close to 32768 characters*. Yes, you can create paths in Windows greater than MAX_PATH long, though it's a tossup whether any given application can handle them.) I'd do something like the following: #include #if defined(WIN32) && !defined(PATH_MAX) #define PATH_MAX (MAX_PATH+1) #endif and use PATH_MAX like you suggested. Orin. *for native APIs. The shell APIs have the MAX_PATH limitation which is another can of worms... -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
