Re: [Libusbx-devel] [PATCH] Windows CE backend and driver
Finally got around to have a closer look at the winCE branch. I don't have much to say with regards to the bulk of the code which looks OK to me (perhaps move STATUS_HALT_FLAG from wince_usb.c to the header?). Note that the Windows backend chose not to reference WinUSB.h and link against WinUSB.lob because it was a headache to do so for all of MSVC, cygwin, MinGW and WDK, and hooking directly into the DLL avoided adding an extra dependency. But maybe this approach doesn't make as much sense for CEUSBKWrapper, and you could avoid DLL_LOAD and use a CEUSBKWrapper.h directly to simplify things. Still, either way is fine with me. Following are my notes, by order of importance: * Major - some of the fixes that went into poll_windows.c have not been applied to poll_wince.c (eg. "InterlockedExchange((LONG *)&compat_spinlock, 0)", malloc -> calloc). Note that this can be alleviated if we just use a single poll_windows.c to which we add the CE changes (see below). * Important - I would very much like to have the xusb sample compiled in the project. Currently only listdevs is. The rationale is that xusb can be quite useful when trying to troubleshoot issues... - A diff between poll_windows.c and poll_wince.c indicates that the differences between the two are minimal enough to consider merging the two into a single file, especially as it would avoid the missing fixes above. My take on doing that would be: - exit_polling() can be sorted out with a couple of WINCE #ifdefs - usbi_pipe() and usbi_create_fd() could also be duplicated and put behind #ifdefs - Another #ifdef can be set in cancel_io, usbi_close and free_index. We can keep the business about CancelIoEx as well as the extra attributes in _poll_fd untouched as they should be ignored on CE. - We can probably sort out the various Sleep() vs SleepEx() in a more efficient manner by using a macro (eg. usbi_Sleep or something) that either resolve to Sleep(t) or SleepEx(t, TRUE) according to the availability of SleepEx. Note that I don't have much of an issue taking care of the above during integration, if you don't have a chance to address them, especially as I'm going to merge and reorganize some of your patches anyway. The only issue is that I can't be able to test further than compiling the code. But I can create a CE integration branch and give you some chance to test it, before it gets merged into mainline. * Minor issues (can be left for after integration) - The wince directory uses subdirectories for the project files (libusb-1.0, listdevs), whereas the msvc one doesn't. With these subdirectories only containing one file, I think they are a bit unnecessary and we probably want to follow the same approach in both instances. Likewise, the project files just places all the .c at the same level, whereas you have an os/ and wince/ group. The .def is also better placed in the "Resource Files" category - The project is only set to build a DLL. Do you think there will be many CE users to wanting to build a static library? If so, we may want to have both a static and dynamic lib project as with the regular Windows backend. - The Windows solution file places the built libraries and executables into a /Win32 or /x64 a the top level, whereas CE places those into /wince/STANDARDSDK_500 (ARMV4I). For the sake of consistency, we probably want to have the CE build directory at top level. - Using /msvc for non CE Windows is going to become a misnomer, since MSVC/VS also applies for CE users, so maybe we should rename it. Or we could use something /msvc_wince for CE and which should make it more explicit that /msvc is for Windows x86_32/x86_64 (and most likely Windows RT) - There's some easy factorization of the wince_usb/windows_usb.h that could be placed into a windows_common.h (The safe_... and DLL_... macros). - Same goes for some of the calls in windows_usb.c/wince_usb.c, though this would require some update of the autotools scripts for Windows => better left for later. For now, if you just push the addon patches that you think are relevant from the elements mentioned above, ontop of what you already have in your branch, and I'll take it from here (i.e. no need to re-do your existing patches). Regards, /Pete -- 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
[Libusbx-devel] [PATCH] Samples: Add FX2/FX3 firmware upload to RAM
Hi Markus,
Since I got my hands on an EZ-FX2 board (and I can only wish it won't be
long before basic FX3 boards come as cheap as the FX2 ones), I amended
your patch to add support for FX2 firmware upload as well.
I don't think the modifications I added will impact the FX3 upload, but
the changes were fairly intrusive, so I wouldn't mind get some
confirmation before I push the patch. If you have a chance to apply this
patch on top of latest libusbx and confirm that FX3 upload still works,
I would appreciate it.
Regards,
/Pete
PS: I am aware that Cypress use "download" where xusb uses "upload", but
since we are considering things from an xusb user's perspective, I think
upload makes more logical sense.
>From fafac9f91787004183504dfea272163885383793 Mon Sep 17 00:00:00 2001
From: Markus Schatzl
Date: Sat, 4 Aug 2012 17:12:26 +0100
Subject: [PATCH] Samples: Add FX2/FX3 firmware upload to RAM
---
examples/xusb.c | 186 ++
1 files changed, 175 insertions(+), 13 deletions(-)
diff --git a/examples/xusb.c b/examples/xusb.c
index 3e8d262..fbae778 100644
--- a/examples/xusb.c
+++ b/examples/xusb.c
@@ -47,14 +47,13 @@
#define false (!true)
#endif
-
// Future versions of libusbx will use usb_interface instead of interface
// in libusb_config_descriptor => catter for that
#define usb_interface interface
// Global variables
bool binary_dump = false;
-char binary_name[64] = "raw.bin";
+char binary_name[256] = "data.bin";
static int perr(char const *format, ...)
{
@@ -138,6 +137,8 @@ enum test_type {
USE_XBOX,
USE_SCSI,
USE_HID,
+ USE_FX2,// Cypress FX2/FX3 code upload
+ USE_FX3,
} test_mode;
uint16_t VID, PID;
@@ -729,6 +730,149 @@ static void
read_ms_winsub_feature_descriptors(libusb_device_handle *handle, uin
}
}
+// Set an FX2 device in or out of reset mode, for RAM upload.
+// See chapter 3.8 of the FX2 EZ-USB Technical Reference Manual
+static int fx2_reset(libusb_device_handle *handle, bool set)
+{
+ unsigned char cpucs_data = (set)?0x01:0x00;
+ int status = 0;
+
+ // Set the CPU in or out of reset mode to upload data to RAM
+ printf("Putting FX2 %s reset mode\n", (set)?"in":"out of");
+ status = libusb_control_transfer(handle,
+
LIBUSB_ENDPOINT_OUT|LIBUSB_REQUEST_TYPE_VENDOR|LIBUSB_RECIPIENT_DEVICE,
+ 0xA0,// bRequest: Vendor (Cypress)
+ 0xE600, // wValue (LSW)
+ 0x, // wIndex (MSW) => CPUCS register at 0xE600
+ &cpucs_data, // data
+ 1, // wLength
+ 1000); // timeout in ms
+ if (status < 0) {
+ perr(" Failed: %s\n", libusb_error_name(status));
+ return 1;
+ }
+ return 0;
+}
+
+// Upload 8051 (BIX format) or ARM (IMG format) code to the RAM of a Cypress
FX2/FX3 device in bootloader mode
+static int upload_to_fx_ram(libusb_device_handle *handle, char* path, bool
fx3_mode)
+{
+ unsigned char header[4];
+ unsigned char data[4096];
+ const uint32_t RETRY_LIMIT = 5;
+ FILE *fw;
+ int status = 0;
+ uint32_t retry;
+ uint32_t segment_addr = 0, cur_addr = 0;
+ uint32_t segment_len = sizeof(data), bytes_remaining, bytes_this_chunk;
+
+ printf("\nUploading firmware to FX2 device's RAM:\n");
+
+ fw = fopen(path, "rb");
+ if ( fw == NULL) {
+ perr(" Failed to open %s: %s\n", path, strerror(errno));
+ return -1;
+ }
+
+ if (fx3_mode) {
+ // Validate the header
+ if (!fread(header, sizeof(char), sizeof(header), fw))
+ return -1;
+
+ if ((header[0] != 'C') || (header[1] != 'Y')) {
+ perr(" Invalid file: missing CYpress signature\n");
+ return -1;
+ }
+
+ if (header[3] != 0xB0) {
+ perr(" Invalid file: format 0x%02X, expected 0xB0\n",
header[3]);
+ return -1;
+ }
+ } else {
+ // Set the CPU in reset mode to upload data to RAM
+ if (fx2_reset(handle, true))
+ return 1;
+ (void) header;
+ }
+
+ // Now process the data segments
+ do {
+ if (fx3_mode) {
+ if (!fread(&segment_len, sizeof(segment_len), 1, fw))
+ break;
+
+ if (!fread(&segment_addr, sizeof(segment_len), 1, fw))
+ break;
+ segment_len = segment_len << 2;
+ cur_addr= segment_addr;
+ }
+ bytes_remaining = segment_len;
+
+ // Make sure we run one time after segment
[Libusbx-devel] pbatard commented on issue 39 on libusbx/libusbx
[pbatard][1] commented on [pull request 39][2] on [libusbx/libusbx][3] August 05, 2012 > Thanks - patch has now been applied. [1]: https://github.com/pbatard [2]: https://github.com/libusbx/libusbx/issues/39#issuecomment-7514096 (Windows: Add workaround for Intel USB 3.0 root hubs ) [3]: https://github.com/libusbx/libusbx URL: https://github.com/libusbx/libusbx/issues/39#issuecomment-7514096 -- 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
