Re: [Openocd-development] inf file for libusb
On Thursday 18 June 2009, Michael Fischer wrote: I think we should start to collect the inf files too? In SVN? I'd think so. Along with installation and upgrade instructions, since that's rarely painless on Windows. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] inf file for libusb
On Fri, Jun 19, 2009 at 3:13 PM, David Brownelldavi...@pacbell.net wrote: On Thursday 18 June 2009, Michael Fischer wrote: I think we should start to collect the inf files too? In SVN? I'd think so. Along with installation and upgrade instructions, since that's rarely painless on Windows. For libusb-win32, it is not too bad. You use the INF wizard to create the INF file and then point to the directory with the inf file. You can even use the undocumented method to install the driver. rundll32 libusb0.dll,usb_install_driver_np_rundll your_inf_file.inf Details: http://www.nabble.com/-Libusb-win32-devel--HID-device-problem-td5937112.html -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jtag_add_callback() change
Committed.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/jtag/driver.c
===
--- src/jtag/driver.c (revision 2284)
+++ src/jtag/driver.c (working copy)
@@ -40,7 +40,7 @@
struct jtag_callback_entry *next;
jtag_callback_t callback;
- uint8_t *in;
+ jtag_callback_data_t data0;
jtag_callback_data_t data1;
jtag_callback_data_t data2;
jtag_callback_data_t data3;
@@ -465,13 +465,13 @@
}
/* add callback to end of queue */
-void interface_jtag_add_callback4(jtag_callback_t callback, uint8_t *in,
jtag_callback_data_t data1, jtag_callback_data_t data2, jtag_callback_data_t
data3)
+void interface_jtag_add_callback4(jtag_callback_t callback,
jtag_callback_data_t data0, jtag_callback_data_t data1, jtag_callback_data_t
data2, jtag_callback_data_t data3)
{
struct jtag_callback_entry *entry=cmd_queue_alloc(sizeof(struct
jtag_callback_entry));
entry-next=NULL;
entry-callback=callback;
- entry-in=in;
+ entry-data0=data0;
entry-data1=data1;
entry-data2=data2;
entry-data3=data3;
@@ -495,7 +495,7 @@
struct jtag_callback_entry *entry;
for (entry=jtag_callback_queue_head; entry!=NULL;
entry=entry-next)
{
- retval=entry-callback(entry-in, entry-data1,
entry-data2, entry-data3);
+ retval=entry-callback(entry-data0, entry-data1,
entry-data2, entry-data3);
if (retval!=ERROR_OK)
break;
}
@@ -507,14 +507,14 @@
return retval;
}
-static int jtag_convert_to_callback4(uint8_t *in, jtag_callback_data_t data1,
jtag_callback_data_t data2, jtag_callback_data_t data3)
+static int jtag_convert_to_callback4(jtag_callback_data_t data0,
jtag_callback_data_t data1, jtag_callback_data_t data2, jtag_callback_data_t
data3)
{
- ((jtag_callback1_t)data1)(in);
+ ((jtag_callback1_t)data1)(data0);
return ERROR_OK;
}
-void interface_jtag_add_callback(jtag_callback1_t callback, uint8_t *in)
+void interface_jtag_add_callback(jtag_callback1_t callback,
jtag_callback_data_t data0)
{
- jtag_add_callback4(jtag_convert_to_callback4, in,
(jtag_callback_data_t)callback, 0, 0);
+ jtag_add_callback4(jtag_convert_to_callback4, data0,
(jtag_callback_data_t)callback, 0, 0);
}
Index: src/target/arm720t.c
===
--- src/target/arm720t.c(revision 2284)
+++ src/target/arm720t.c(working copy)
@@ -120,7 +120,7 @@
{
fields[1].in_value = (uint8_t *)in;
jtag_add_dr_scan(2, fields, jtag_get_end_state());
- jtag_add_callback(arm7flip32, (uint8_t *)in);
+ jtag_add_callback(arm7flip32, (jtag_callback_data_t)in);
} else
{
jtag_add_dr_scan(2, fields, jtag_get_end_state());
Index: src/pld/virtex2.c
===
--- src/pld/virtex2.c (revision 2284)
+++ src/pld/virtex2.c (working copy)
@@ -88,8 +88,9 @@
return ERROR_OK;
}
-static __inline__ void virtexflip32(uint8_t *in)
+static __inline__ void virtexflip32(jtag_callback_data_t arg)
{
+ uint8_t *in=(uint8_t *)arg;
*((uint32_t *)in) = flip_u32(le_to_h_u32(in), 32);
}
@@ -112,7 +113,7 @@
jtag_add_dr_scan(1, scan_field,
jtag_set_end_state(TAP_DRPAUSE));
- jtag_add_callback(virtexflip32, (uint8_t *)words);
+ jtag_add_callback(virtexflip32, (jtag_callback_data_t)words);
words++;;
}
Index: src/target/arm_adi_v5.c
===
--- src/target/arm_adi_v5.c (revision 2284)
+++ src/target/arm_adi_v5.c (working copy)
@@ -132,7 +132,7 @@
fields[1].in_value = (uint8_t *)invalue;
jtag_add_dr_scan(2, fields, jtag_get_end_state());
- jtag_add_callback(arm_le_to_h_u32, (uint8_t *)invalue);
+ jtag_add_callback(arm_le_to_h_u32, (jtag_callback_data_t)
invalue);
} else
{
Index: src/target/xscale.c
===
--- src/target/xscale.c (revision 2284)
+++ src/target/xscale.c (working copy)
@@ -293,8 +293,9 @@
}
-static void xscale_getbuf(uint8_t *in)
+static void xscale_getbuf(jtag_callback_data_t arg)
{
+ uint8_t *in=(uint8_t *)arg;
*((uint32_t *)in)=buf_get_u32(in, 0, 32);
}
@@ -365,7 +366,7 @@
jtag_add_dr_scan_check(3, fields,
jtag_set_end_state(TAP_IDLE));
- jtag_add_callback(xscale_getbuf, (uint8_t *)(field1+i));
+
Re: [Openocd-development] OpenOCD + libftdi on Windows
On Fri, Jun 19, 2009 at 7:27 AM, Gene Smithg...@chartertn.net wrote: I already have libusb working fine on windows with jlink. Now I am trying to add libftdi. I have built and installed enough of libftdi to enable a build of openocd with --enable-ft2232_libftdi. And I installed the new libusb0.sys described above. How do you install the modified libusb0.sys? That may be critical. Your need to check that you are really using the modified libusb0.sys in Device Manager. When I plug in the USB from the olimex arm-usb-ocd, a driver installation dialog pops up (which I have so far ignored) and I see the Olimex OpenOCD JTAG device detected in device manager. Then when I run openocd I get the device not found message as Freddie originally described. Do I still need to install the proprietary driver from the olimex CD? I thought that installing libusb and libftdi on windows would be enough. That should be enough. In fact, I kind of believe that you do not need to use the modified libusb0.sys but rather a proper inf file generated by the INF wizard for the whole device. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] inf file for libusb
On Friday 19 June 2009, Xiaofan Chen wrote: On Fri, Jun 19, 2009 at 3:13 PM, David Brownelldavi...@pacbell.net wrote: On Thursday 18 June 2009, Michael Fischer wrote: I think we should start to collect the inf files too? In SVN? I'd think so. Along with installation and upgrade instructions, since that's rarely painless on Windows. For libusb-win32, it is not too bad. You use the INF wizard to create the INF file and then point to the directory with the inf file. This requires a lot of Win32 knowledge. I never even knew there *was* such a thing as an INF wizard... You can even use the undocumented method to install the driver. rundll32 libusb0.dll,usb_install_driver_np_rundll your_inf_file.inf Details: http://www.nabble.com/-Libusb-win32-devel--HID-device-problem-td5937112.html -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] inf file for libusb
On Fri, Jun 19, 2009 at 5:35 PM, David Brownelldavi...@pacbell.net wrote: For libusb-win32, it is not too bad. You use the INF wizard to create the INF file and then point to the directory with the inf file. This requires a lot of Win32 knowledge. I never even knew there *was* such a thing as an INF wizard... You can even use the undocumented method to install the driver. rundll32 libusb0.dll,usb_install_driver_np_rundll your_inf_file.inf Details: http://www.nabble.com/-Libusb-win32-devel--HID-device-problem-td5937112.html INF wizard is part of libusb-win32. It is actually very easy to use. ;-) I can not code, but I happened to know quite a bit about libusb and libusb-win32 after playing with USB in my spare time on and off for almost 4 years. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] inf file for libusb
I think we should start to collect the inf files too? Agree, it would be nice to have a libusb - INF file for all ftdi based chips that point to libusb :-) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD + libftdi on Windows
Xiaofan Chen wrote: On Fri, Jun 19, 2009 at 7:27 AM, Gene Smithg...@chartertn.net wrote: I already have libusb working fine on windows with jlink. Now I am trying to add libftdi. I have built and installed enough of libftdi to enable a build of openocd with --enable-ft2232_libftdi. And I installed the new libusb0.sys described above. How do you install the modified libusb0.sys? That may be critical. Your need to check that you are really using the modified libusb0.sys in Device Manager. The article said copy the file to windows/system32/drivers and plug/unplug devices and it should take effect. When I plug in the USB from the olimex arm-usb-ocd, a driver installation dialog pops up (which I have so far ignored) and I see the Olimex OpenOCD JTAG device detected in device manager. Then when I run openocd I get the device not found message as Freddie originally described. Do I still need to install the proprietary driver from the olimex CD? I thought that installing libusb and libftdi on windows would be enough. Well, I went ahead and installed the stuff from the cd. Now I see in device mgr that my driver is windows/system32/drivers/ftdibus.sys instead of libusb0.sys That should be enough. In fact, I kind of believe that you do not need to use the modified libusb0.sys but rather a proper inf file generated by the INF wizard for the whole device. I used the wizard to generate and install the inf. But it was for jlink when I did it several days ago. Maybe I need to redo this procedure for the ftdi olimex device. I will uninstall the olimex driver and try the procedure again. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] inf file for libusb
On Fri, Jun 19, 2009 at 5:39 PM, Xiaofan Chenxiaof...@gmail.com wrote:
On Fri, Jun 19, 2009 at 5:35 PM, David Brownelldavi...@pacbell.net wrote:
For libusb-win32, it is not too bad. You use the INF wizard to create the
INF file and then point to the directory with the inf file.
This requires a lot of Win32 knowledge. I never even knew
there *was* such a thing as an INF wizard...
INF wizard is part of libusb-win32. It is actually very easy to use. ;-)
For example, here is the step to generate an INF file for a FTDI FT2232D
device (on a Infineon XE166 demo board).
Run inf-wizard.exe from libusb-win32-device-bin-0.1.12.1 directory.
Click Next
Click the correct VID/PID: 0x058B 0x002B USB Composite Device
Click Next
Save the inf file as ftdi_libusb.inf in the same directory.
Click Finish
That is it. Simple, right?
[Version]
Signature = $Chicago$
provider = %manufacturer%
DriverVer = 03/20/2007,0.1.12.1
CatalogFile = usbcomposite.cat
CatalogFile.NT = usbcomposite.cat
CatalogFile.NTAMD64 = usbcomposite_x64.cat
Class = LibUsbDevices
ClassGUID = {EB781AAF-9C70-4523-A5DF-642A87ECA567}
[ClassInstall]
AddReg=libusb_class_install_add_reg
[ClassInstall32]
AddReg=libusb_class_install_add_reg
[libusb_class_install_add_reg]
HKRLibUSB-Win32 Devices
HKR,,Icon,,-20
[Manufacturer]
%manufacturer%=Devices,NT,NTAMD64
;--
; Files
;--
[SourceDisksNames]
1 = Libusb-Win32 Driver Installation Disk,,
[SourceDisksFiles]
libusb0.sys = 1,,
libusb0.dll = 1,,
libusb0_x64.sys = 1,,
libusb0_x64.dll = 1,,
[DestinationDirs]
libusb_files_sys = 10,system32\drivers
libusb_files_sys_x64 = 10,system32\drivers
libusb_files_dll = 10,system32
libusb_files_dll_wow64 = 10,syswow64
libusb_files_dll_x64 = 10,system32
[libusb_files_sys]
libusb0.sys
[libusb_files_sys_x64]
libusb0.sys,libusb0_x64.sys
[libusb_files_dll]
libusb0.dll
[libusb_files_dll_wow64]
libusb0.dll
[libusb_files_dll_x64]
libusb0.dll,libusb0_x64.dll
;--
; Device driver
;--
[LIBUSB_DEV]
CopyFiles = libusb_files_sys, libusb_files_dll
AddReg= libusb_add_reg
[LIBUSB_DEV.NT]
CopyFiles = libusb_files_sys, libusb_files_dll
[LIBUSB_DEV.NTAMD64]
CopyFiles = libusb_files_sys_x64, libusb_files_dll_wow64, libusb_files_dll_x64
[LIBUSB_DEV.HW]
DelReg = libusb_del_reg_hw
AddReg = libusb_add_reg_hw
[LIBUSB_DEV.NT.HW]
DelReg = libusb_del_reg_hw
AddReg = libusb_add_reg_hw
[LIBUSB_DEV.NTAMD64.HW]
DelReg = libusb_del_reg_hw
AddReg = libusb_add_reg_hw
[LIBUSB_DEV.NT.Services]
AddService = libusb0, 0x0002, libusb_add_service
[LIBUSB_DEV.NTAMD64.Services]
AddService = libusb0, 0x0002, libusb_add_service
[libusb_add_reg]
HKR,,DevLoader,,*ntkern
HKR,,NTMPDriver,,libusb0.sys
; Older versions of this .inf file installed filter drivers. They are not
; needed any more and must be removed
[libusb_del_reg_hw]
HKR,,LowerFilters
HKR,,UpperFilters
; Device properties
[libusb_add_reg_hw]
HKR,,SurpriseRemovalOK, 0x00010001, 1
;--
; Services
;--
[libusb_add_service]
DisplayName= LibUsb-Win32 - Kernel Driver 03/20/2007, 0.1.12.1
ServiceType= 1
StartType = 3
ErrorControl = 0
ServiceBinary = %12%\libusb0.sys
;--
; Devices
;--
[Devices]
USB Composite Device=LIBUSB_DEV, USB\VID_058bPID_002b
[Devices.NT]
USB Composite Device=LIBUSB_DEV, USB\VID_058bPID_002b
[Devices.NTAMD64]
USB Composite Device=LIBUSB_DEV, USB\VID_058bPID_002b
;--
; Strings
;--
[Strings]
manufacturer = (Standard USB Host Controller)
Run cmd.exe as admin (under Vista) and
D:\libusb-win32-device-bin-0.1.12.1\binc:\windows\sys
tem32\rundll32 libusb0.dll,usb_install_driver_np_rundll usbcomposite.inf
Windows will pop up a warning. Click Install this driver software anyway.
After a while, the new device should be listed in Device Manager as
LibUSB-Win32 Devices -- USB Composite Device
D:\libusb-win32-device-bin-0.1.12.1\bintestlibusb.exe
Dev #0: -
Dev #1: INFINEON - DAS JTAG over USB EK XE167
D:\libusb-win32-device-bin-0.1.12.1\bintestlibusb-win.exe
A popup window will appear. Here is the content.
DLL version:0.1.12.1
Driver version: 0.1.12.1
bus/device idVendor/idProduct
bus-0/\\.\libusb0-0001--0x058b-0x002b 058B/002B
- Manufacturer : INFINEON
- Product : DAS JTAG over USB EK XE167
- Serial Number: EK054019
wTotalLength: 55
bNumInterfaces:
Re: [Openocd-development] OpenOCD + libftdi on Windows
On Fri, Jun 19, 2009 at 9:08 PM, Gene Smithg...@chartertn.net wrote: That should be enough. In fact, I kind of believe that you do not need to use the modified libusb0.sys but rather a proper inf file generated by the INF wizard for the whole device. I used the wizard to generate and install the inf. But it was for jlink when I did it several days ago. Maybe I need to redo this procedure for the ftdi olimex device. I will uninstall the olimex driver and try the procedure again. Yes I think that should be the way to go. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] inf file for libusb
Xiaofan Chen wrote:
On Fri, Jun 19, 2009 at 5:39 PM, Xiaofan Chenxiaof...@gmail.com wrote:
On Fri, Jun 19, 2009 at 5:35 PM, David Brownelldavi...@pacbell.net wrote:
For libusb-win32, it is not too bad. You use the INF wizard to create the
INF file and then point to the directory with the inf file.
This requires a lot of Win32 knowledge. I never even knew
there *was* such a thing as an INF wizard...
INF wizard is part of libusb-win32. It is actually very easy to use. ;-)
For example, here is the step to generate an INF file for a FTDI FT2232D
device (on a Infineon XE166 demo board).
Run inf-wizard.exe from libusb-win32-device-bin-0.1.12.1 directory.
I see it in the bin dir.
Click Next
Click the correct VID/PID: 0x058B 0x002B USB Composite Device
Click Next
Save the inf file as ftdi_libusb.inf in the same directory.
The bin dir? (Or does it matter?)
Click Finish
That is it. Simple, right?
Right, but when I try to update the driver, I find the olimex.inf
that is saved but it always tells me the specifed location does not
contain information about your hardware.
This seems to work find somehow when I installed the jlink. Now the
olimex is being difficult. Any idea what I am missing here? (You can
have jlink and ftdi/olimex drivers both installed, right?)
[Version]
Signature = $Chicago$
provider = %manufacturer%
DriverVer = 03/20/2007,0.1.12.1
CatalogFile = usbcomposite.cat
CatalogFile.NT = usbcomposite.cat
CatalogFile.NTAMD64 = usbcomposite_x64.cat
Class = LibUsbDevices
ClassGUID = {EB781AAF-9C70-4523-A5DF-642A87ECA567}
[ClassInstall]
AddReg=libusb_class_install_add_reg
[ClassInstall32]
AddReg=libusb_class_install_add_reg
[libusb_class_install_add_reg]
HKRLibUSB-Win32 Devices
HKR,,Icon,,-20
[Manufacturer]
%manufacturer%=Devices,NT,NTAMD64
;--
; Files
;--
[SourceDisksNames]
1 = Libusb-Win32 Driver Installation Disk,,
[SourceDisksFiles]
libusb0.sys = 1,,
libusb0.dll = 1,,
libusb0_x64.sys = 1,,
libusb0_x64.dll = 1,,
[DestinationDirs]
libusb_files_sys = 10,system32\drivers
libusb_files_sys_x64 = 10,system32\drivers
libusb_files_dll = 10,system32
libusb_files_dll_wow64 = 10,syswow64
libusb_files_dll_x64 = 10,system32
[libusb_files_sys]
libusb0.sys
[libusb_files_sys_x64]
libusb0.sys,libusb0_x64.sys
[libusb_files_dll]
libusb0.dll
[libusb_files_dll_wow64]
libusb0.dll
[libusb_files_dll_x64]
libusb0.dll,libusb0_x64.dll
;--
; Device driver
;--
[LIBUSB_DEV]
CopyFiles = libusb_files_sys, libusb_files_dll
AddReg= libusb_add_reg
[LIBUSB_DEV.NT]
CopyFiles = libusb_files_sys, libusb_files_dll
[LIBUSB_DEV.NTAMD64]
CopyFiles = libusb_files_sys_x64, libusb_files_dll_wow64, libusb_files_dll_x64
[LIBUSB_DEV.HW]
DelReg = libusb_del_reg_hw
AddReg = libusb_add_reg_hw
[LIBUSB_DEV.NT.HW]
DelReg = libusb_del_reg_hw
AddReg = libusb_add_reg_hw
[LIBUSB_DEV.NTAMD64.HW]
DelReg = libusb_del_reg_hw
AddReg = libusb_add_reg_hw
[LIBUSB_DEV.NT.Services]
AddService = libusb0, 0x0002, libusb_add_service
[LIBUSB_DEV.NTAMD64.Services]
AddService = libusb0, 0x0002, libusb_add_service
[libusb_add_reg]
HKR,,DevLoader,,*ntkern
HKR,,NTMPDriver,,libusb0.sys
; Older versions of this .inf file installed filter drivers. They are not
; needed any more and must be removed
[libusb_del_reg_hw]
HKR,,LowerFilters
HKR,,UpperFilters
; Device properties
[libusb_add_reg_hw]
HKR,,SurpriseRemovalOK, 0x00010001, 1
;--
; Services
;--
[libusb_add_service]
DisplayName= LibUsb-Win32 - Kernel Driver 03/20/2007, 0.1.12.1
ServiceType= 1
StartType = 3
ErrorControl = 0
ServiceBinary = %12%\libusb0.sys
;--
; Devices
;--
[Devices]
USB Composite Device=LIBUSB_DEV, USB\VID_058bPID_002b
[Devices.NT]
USB Composite Device=LIBUSB_DEV, USB\VID_058bPID_002b
[Devices.NTAMD64]
USB Composite Device=LIBUSB_DEV, USB\VID_058bPID_002b
;--
; Strings
;--
[Strings]
manufacturer = (Standard USB Host Controller)
Run cmd.exe as admin (under Vista) and
D:\libusb-win32-device-bin-0.1.12.1\binc:\windows\sys
tem32\rundll32 libusb0.dll,usb_install_driver_np_rundll usbcomposite.inf
Windows will pop up a warning. Click Install this driver software anyway.
Re: [Openocd-development] inf file for libusb
On Fri, Jun 19, 2009 at 10:21 PM, Gene Smithg...@chartertn.net wrote: Run inf-wizard.exe from libusb-win32-device-bin-0.1.12.1 directory. I see it in the bin dir. Click Next Click the correct VID/PID: 0x058B 0x002B USB Composite Device Click Next Save the inf file as ftdi_libusb.inf in the same directory. The bin dir? (Or does it matter?) Yes. That matters. Right, but when I try to update the driver, I find the olimex.inf that is saved but it always tells me the specifed location does not contain information about your hardware. Hmm, that should not happen. Could you post the Olimex inf file content? What is the VID/PID combination? This seems to work find somehow when I installed the jlink. Now the olimex is being difficult. Any idea what I am missing here? (You can have jlink and ftdi/olimex drivers both installed, right?) Have you tried the following method? Run cmd.exe as admin (under Vista) and D:\libusb-win32-device-bin-0.1.12.1\binc:\windows\sys tem32\rundll32 libusb0.dll,usb_install_driver_np_rundll olimex.inf -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] inf file for libusb
Xiaofan Chen wrote: On Fri, Jun 19, 2009 at 10:21 PM, Gene Smithg...@chartertn.net wrote: Run inf-wizard.exe from libusb-win32-device-bin-0.1.12.1 directory. I see it in the bin dir. Click Next Click the correct VID/PID: 0x058B 0x002B USB Composite Device Click Next Save the inf file as ftdi_libusb.inf in the same directory. The bin dir? (Or does it matter?) Yes. That matters. Right, but when I try to update the driver, I find the olimex.inf that is saved but it always tells me the specifed location does not contain information about your hardware. Hmm, that should not happen. Could you post the Olimex inf file content? What is the VID/PID combination? This seems to work find somehow when I installed the jlink. Now the olimex is being difficult. Any idea what I am missing here? (You can have jlink and ftdi/olimex drivers both installed, right?) Have you tried the following method? Run cmd.exe as admin (under Vista) and D:\libusb-win32-device-bin-0.1.12.1\binc:\windows\sys tem32\rundll32 libusb0.dll,usb_install_driver_np_rundll olimex.inf I didn't see this at first on your previous email down at the bottom. But this works! It is now seeing the device. So you don't need the driver installations wizards to install the driver? Thanks! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] inf file for libusb
On Fri, Jun 19, 2009 at 10:51 PM, Gene Smithg...@chartertn.net wrote: Have you tried the following method? Run cmd.exe as admin (under Vista) and D:\libusb-win32-device-bin-0.1.12.1\binc:\windows\sys tem32\rundll32 libusb0.dll,usb_install_driver_np_rundll olimex.inf I didn't see this at first on your previous email down at the bottom. But this works! It is now seeing the device. So you don't need the driver installations wizards to install the driver? Thanks! That is right. This is an undocumented feature of libusb-win32 that the author of libusb-win32 taught me to use back in 2007. He is a very nice guy. Unfortunately he seems to be busy lately so not much progress in the libusb-win32 front. More important question. ;-) Does openocd work with this libusb-win32 driver? -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] inf file for libusb
Xiaofan Chen wrote: On Fri, Jun 19, 2009 at 10:51 PM, Gene Smithg...@chartertn.net wrote: Have you tried the following method? Run cmd.exe as admin (under Vista) and D:\libusb-win32-device-bin-0.1.12.1\binc:\windows\sys tem32\rundll32 libusb0.dll,usb_install_driver_np_rundll olimex.inf I didn't see this at first on your previous email down at the bottom. But this works! It is now seeing the device. So you don't need the driver installations wizards to install the driver? Thanks! That is right. This is an undocumented feature of libusb-win32 that the author of libusb-win32 taught me to use back in 2007. He is a very nice guy. Unfortunately he seems to be busy lately so not much progress in the libusb-win32 front. More important question. ;-) Does openocd work with this libusb-win32 driver? Well, your're a nice guy too for helping with with this! Any yes, it works find with oocd. Not sure if the serial port works but I will try that on windows (it worked OK on linux). Still need to try jlink again on windows oocd (but it is also detected under LibUSB-Win32 Devices when I plug it in). Thanks again! -gene P/S: This really needs to documented somewhere (other than random postings) :) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] inf file for libusb
On Fri, Jun 19, 2009 at 11:09 PM, Gene Smithg...@chartertn.net wrote: That is right. This is an undocumented feature of libusb-win32 that the author of libusb-win32 taught me to use back in 2007. He is a very nice guy. Unfortunately he seems to be busy lately so not much progress in the libusb-win32 front. More important question. ;-) Does openocd work with this libusb-win32 driver? Well, your're a nice guy too for helping with with this! Any yes, it works find with oocd. Not sure if the serial port works but I will try that on windows (it worked OK on linux). Still need to try jlink again on windows oocd (but it is also detected under LibUSB-Win32 Devices when I plug it in). Thanks again! I am glad to be of some help. I tried J-Link under Windows using libusb-win32 driver and it seems to work fine. P/S: This really needs to documented somewhere (other than random postings) :) Yes I agree. Once you confirm this works with OpenOCD, we can make a documentation on this topic. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH v2] FA526 support
Hi list,
This is minimal patch to support FA526 ARMv4 compatible core.
Since it is very similar to ARM920T I tried to reuse as much
code as possible.
CPU and board configs will follow soon.
Changes since v1:
- add fa526 argument description to target command documentation
- sync with latest SVN rev.
BR,
Paulius Zaleckas
Index: src/target/fa526.c
===
--- src/target/fa526.c (revision 0)
+++ src/target/fa526.c (revision 0)
@@ -0,0 +1,430 @@
+/***
+ * Copyright (C) 2009 by Paulius Zaleckas*
+ * paulius.zalec...@gmail.com*
+ * *
+ * This program is free software; you can redistribute it and/or modify *
+ * it under the terms of the GNU General Public License as published by *
+ * the Free Software Foundation; either version 2 of the License, or *
+ * (at your option) any later version. *
+ * *
+ * This program is distributed in the hope that it will be useful, *
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of*
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the *
+ * GNU General Public License for more details. *
+ * *
+ * You should have received a copy of the GNU General Public License *
+ * along with this program; if not, write to the *
+ * Free Software Foundation, Inc., *
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. *
+ ***/
+
+/*
+ * FA526 is very similar to ARM920T with following differences:
+ *
+ * - execution pipeline is 6 steps
+ * - Unified TLB
+ * - has Branch Target Buffer
+ * - does not support reading of I/D cache contents
+ */
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#include arm920t.h
+#include target_type.h
+
+int fa526_target_create(struct target_s *target, Jim_Interp *interp);
+int fa526_init_target(struct command_context_s *cmd_ctx, struct target_s
*target);
+int fa526_quit(void);
+
+target_type_t fa526_target =
+{
+ .name = fa526,
+
+ .poll = arm7_9_poll,
+ .arch_state = arm920t_arch_state,
+
+ .target_request_data = arm7_9_target_request_data,
+
+ .halt = arm7_9_halt,
+ .resume = arm7_9_resume,
+ .step = arm7_9_step,
+
+ .assert_reset = arm7_9_assert_reset,
+ .deassert_reset = arm7_9_deassert_reset,
+ .soft_reset_halt = arm920t_soft_reset_halt,
+
+ .get_gdb_reg_list = armv4_5_get_gdb_reg_list,
+
+ .read_memory = arm920t_read_memory,
+ .write_memory = arm920t_write_memory,
+ .bulk_write_memory = arm7_9_bulk_write_memory,
+ .checksum_memory = arm7_9_checksum_memory,
+ .blank_check_memory = arm7_9_blank_check_memory,
+
+ .run_algorithm = armv4_5_run_algorithm,
+
+ .add_breakpoint = arm7_9_add_breakpoint,
+ .remove_breakpoint = arm7_9_remove_breakpoint,
+ .add_watchpoint = arm7_9_add_watchpoint,
+ .remove_watchpoint = arm7_9_remove_watchpoint,
+
+ .register_commands = arm920t_register_commands,
+ .target_create = fa526_target_create,
+ .init_target = fa526_init_target,
+ .examine = arm9tdmi_examine,
+ .quit = fa526_quit
+};
+
+void fa526_change_to_arm(target_t *target, uint32_t *r0, uint32_t *pc)
+{
+ LOG_ERROR(%s: there is no Thumb state on FA526, __func__);
+}
+
+void fa526_read_core_regs(target_t *target, uint32_t mask, uint32_t*
core_regs[16])
+{
+ int i;
+ /* get pointers to arch-specific information */
+ armv4_5_common_t *armv4_5 = target-arch_info;
+ arm7_9_common_t *arm7_9 = armv4_5-arch_info;
+ arm_jtag_t *jtag_info = arm7_9-jtag_info;
+
+ /* STMIA r0-15, [r0] at debug speed
+* register values will start to appear on 4th DCLK
+*/
+ arm9tdmi_clock_out(jtag_info, ARMV4_5_STMIA(0, mask 0x, 0, 0), 0,
NULL, 0);
+
+ /* fetch NOP, STM in DECODE stage */
+ arm9tdmi_clock_out(jtag_info, ARMV4_5_NOP, 0, NULL, 0);
+ /* fetch NOP, STM in SHIFT stage */
+ arm9tdmi_clock_out(jtag_info, ARMV4_5_NOP, 0, NULL, 0);
+ /* fetch NOP, STM in EXECUTE stage (1st cycle) */
+ arm9tdmi_clock_out(jtag_info, ARMV4_5_NOP, 0, NULL, 0);
+
+ for (i = 0; i = 15; i++)
+ {
+ if (mask (1 i))
+ /* nothing fetched, STM in MEMORY (i'th cycle) */
+ arm9tdmi_clock_data_in(jtag_info, core_regs[i]);
+ }
+}
+
+void
Re: [Openocd-development] inf file for libusb
Xiaofan Chen wrote: On Fri, Jun 19, 2009 at 11:09 PM, Gene Smithg...@chartertn.net wrote: That is right. This is an undocumented feature of libusb-win32 that the author of libusb-win32 taught me to use back in 2007. He is a very nice guy. Unfortunately he seems to be busy lately so not much progress in the libusb-win32 front. More important question. ;-) Does openocd work with this libusb-win32 driver? Well, your're a nice guy too for helping with with this! Any yes, it works find with oocd. Not sure if the serial port works but I will try that on windows (it worked OK on linux). Still need to try jlink again on windows oocd (but it is also detected under LibUSB-Win32 Devices when I plug it in). Thanks again! I am glad to be of some help. I tried J-Link under Windows using libusb-win32 driver and it seems to work fine. P/S: This really needs to documented somewhere (other than random postings) :) Yes I agree. Once you confirm this works with OpenOCD, we can make a documentation on this topic. I can switch back and forth between jlink and olimex/ftdi OK in openocd and debug wiht insight. They both work OK. However, I don't see a new serial port in Dev mgr for the olimex. Where should I see this? I only see the built-in COM1 when I plug in the olimex ftdi adapter I see no new COM ports. (On linux it appeared as /dev/USB0tty and and I could send output to minicom.) In windows I only see builtin COM1 in hyperterm and on dev mgr. I tried the hacked libusb0.sys driver and it made no difference. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] committed - printf() warning fixes
On Fri, 2009-06-19 at 19:18 -0400, Duane Ellis wrote: FYI - I committed several cygwin specific printf() warning fixes. Simple cast to fix these where causing -Werror failures on cygwin. I was just about to post some patches to show how to fix all of these correctly, as casts are not the right way to do it. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 0/2] Minor improvements in types.h.
This series includes small patches that improve the core types. 1/2 Include inttypes.h from types.h. 2/2 Demonstrate C99 PRIuN formatting specifiers in trace.c. --- Summary of Patches 1-2: helper/types.h |3 +++ target/trace.c |5 +++-- 2 files changed, 6 insertions(+), 2 deletions(-) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 2/2] Demonstrate C99 PRIuN formatting specifiers in trace.c.
Demonstrate C99 PRIuN formatting specifiers in trace.c.
---
trace.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Demonstrate C99 PRIuN formatting specifiers in trace.c.
---
trace.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
==
only in patch2:
unchanged:
--- src/target/trace.c (revision 2292)
+++ src/target/trace.c (working copy)
@@ -58,9 +58,10 @@
for (i = 0; i trace-num_trace_points; i++)
{
- command_print(cmd_ctx, trace point 0x%8.8x (%lld times hit),
+ command_print(cmd_ctx,
+ trace point 0x%8.8 PRIx32 (% PRIu64 times hit),
trace-trace_points[i].address,
- (long long)trace-trace_points[i].hit_counter);
+ trace-trace_points[i].hit_counter);
}
return ERROR_OK;
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Openocd-svn] r2293 - trunk/src/jtag
On Sat, 2009-06-20 at 01:16 +0200, du...@mail.berlios.de wrote: Author: duane Date: 2009-06-20 01:15:58 +0200 (Sat, 20 Jun 2009) New Revision: 2293 [snip] +/* + * Local Variables: + * c-basic-offset: 4 + * tab-width: 4 + * End: + */ I think this kind of stuff should be prohibited from source files. This is noise for anyone that does not use one specific editor. Attached is a patch that removes three such blocks from the tree. Cheers, Zach Remove editor preferences from source files. --- helper/jim.c |9 - helper/jim.h |7 --- jtag/tcl.c |7 --- 3 files changed, 23 deletions(-) == only in patch2: unchanged: --- src/helper/jim.c (revision 2293) +++ src/helper/jim.c (working copy) @@ -12833,12 +12833,3 @@ return Jim_GetString( debug_string_obj, NULL ); } - - - -/* - * Local Variables: *** - * c-basic-offset: 4 *** - * tab-width: 4 *** - * End: *** - */ only in patch2: unchanged: --- src/helper/jim.h (revision 2293) +++ src/helper/jim.h (working copy) @@ -1322,10 +1322,3 @@ #endif #endif /* __JIM__H */ - -/* - * Local Variables: *** - * c-basic-offset: 4 *** - * tab-width: 4 *** - * End: *** - */ only in patch2: unchanged: --- src/jtag/tcl.c (revision 2293) +++ src/jtag/tcl.c (working copy) @@ -1502,10 +1502,3 @@ return ERROR_OK; } - -/* - * Local Variables: - * c-basic-offset: 4 - * tab-width: 4 - * End: - */ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Openocd-svn] r2293 - trunk/src/jtag
I think this kind of stuff should be prohibited from source files. This is noise for anyone that does not use one specific editor. I disagree.. - But since you are so proactive ... Please also fix arm-jtag-ew.c - remove the VIM version of the same thing. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] committed - printf() warning fixes
On Fri, 2009-06-19 at 19:38 -0400, Duane Ellis wrote: Zach Welch wrote: On Fri, 2009-06-19 at 19:18 -0400, Duane Ellis wrote: FYI - I committed several cygwin specific printf() warning fixes. Simple cast to fix these where causing -Werror failures on cygwin. I was just about to post some patches to show how to fix all of these correctly, as casts are not the right way to do it. I can stop... revert my patch... By all means, continue forward; I am not sure whether it will be easier to revert the patch or simply apply a new patch that retouches the same lines. Personally, I would just go for a new patch and skip reverting. How soon -can you have this done? Me, personally? I am not working to a specific schedule, though I realize this is a problem and have been trying to think about how to address it (short of trying to get volunteers to help clean up my mess). Since I am the one that committed it, I will take responsibility for fixing it, but I want to avoid creating more problems in doing so. I have been dead in the water for a few days because of this... and started fixing things. Patches are definitely welcome; they just need to do the right thing. Please feel free to continue committing patches modeled after the one that I just sent. If you have doubt about the integrity of your fixes, you should probably post them here first, which is what I was working toward with my just-posted fragment of a series. I have other things [new work] that *need* -Werror fixed! By all means, continue supplying fixes. I am sorry to have caused these temporary problems, but the code will be well-audited once it is fixed. In that regard, I will only be glad to have made these changes if the correct fixes are going to be applied. Personally, I think these issues show that OpenOCD's type system was not working as intended on all platforms, and we have simply exposed latent bugs that needed to be addressed. And as far as I am aware, only CygWin has been broken by these changes: even MinGW32 compiles correctly, if I have interpreted Michael Fischer's recent reports correctly. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Openocd-svn] r2293 - trunk/src/jtag
On Fri, 2009-06-19 at 19:49 -0400, Duane Ellis wrote: I think this kind of stuff should be prohibited from source files. This is noise for anyone that does not use one specific editor. I disagree.. - But since you are so proactive ... Please also fix arm-jtag-ew.c - remove the VIM version of the same thing. Committed r2293. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] committed - printf() warning fixes
duane FYI - I committed several cygwin specific printf() warning fixes. duaneSimple cast to fix duane these where causing -Werror failures on cygwin. zach I was just about to post some patches to show how to fix all of these zach correctly, as casts are not the right way to do it. In some cases, I can agree, but in others - I don't agree. A cast is by far the most simplest solution. For instance, look at this: LOG_WARNING(writing %d bytes only - as image section is %d bytes and bank is only %d bytes, \ (int)(c-base + c-size - run_address), (int)(run_size), (int)(c-size)); (a) look at what is being printed (b) the possible ranges of numbers (c) the number of parameters involved in the expressions At some point - having to dig back 20 to 30 -lines- to *random* places - because some variables are: (1) function parameters (2) defined at the top most block (3) defined locally to the local block (4) defined a few lines down from the top most block (5) often simplistic 'i/j/k' type vars that are reused because they are handy. (6) By the time I personally dig through the above, and determine all types involved (7) Then understand the underlying arithmetic integer promotion order... *note* this set of equations are simple... (8) a cast to a basic type is truly a very *simple* solution, (9) a cast to a basic type in this case is the K.I.S.S. solution. Either that - or we *need* a different solution here, the above is absurd. Comments? -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
On Fri, 2009-06-19 at 18:26 +0200, Harald Kipp wrote: Hello all, I may have missed one or the other statement given in that long license discussion thread. Nevertheless, Michael asked me to post my view to this forum. If I'm repeating statements that had been posted already: Sorry for the noise. David Brownell wrote: The source code should still build with both. However, nobody is allowed to distribute binaries that depend on the D2XX libraries. No question, it is illegal to distribute binaries that had been linked with FTD2XX.lib. Dynamic linking to proprietary libraries by adding LoadLibrary and GetProcAddress to OpenOCD is a gray area. While the FSF would not allow this, some lawyers may have a different view. The big problem with gray areas is that you can be sued anyway, and -- even if you have lots of money -- you will have no idea as to whether or not you will be able to defend the legality of your actions. If a dispute arose on such grounds, your legal representation would be wise to advise you to reach a settlement, unless you could demonstrate irrefutable evidence that vindicates you (which is nearly impossible). The costs of going to trial and losing would be daunting in the face of such uncertainty. Inevitably, that means that you will be back to complying with the terms of the GPL, everyone gains the pleasure of paying their lawyers to learn more about the license, and maybe worse. The community would be well advised to avoid these risks: use libftdi. IMHO, the best solution is to create a new DLL, which is distributed under LGPL or GPL with a special exception (may be even BSDL). It should not provide any problems to link OpenOCD with this new library. And for this library it should be no problem to link to FTD2XX.dll. OpenOCD(GPL) - links - OpenFTD2XX(LGPL) - links - FTD2XX(Closed) I would be just as opposed to such circumvention as I would to linking to it directly, but I believe the legality of this strategy is suspect. Quite simply, an exception to the LGPL would create a new license, and the modified legal verbiage would no longer be compatible with the GPL. To reiterate my earlier statements on this subject, I will consider distribution of any OpenOCD binary that links to FTD2XX to be a violation of the GPL. If the libftd2xx library loads in the OpenOCD process, then distributing the binary would violate the GPL. I have contributed enough to OpenOCD now that anyone contravening this interpretation will be directly opposing the wishes of a copyright holder who sees things that way. I would expect this should seriously impair the defense of any violations found in the future: the community has been explicitly warned not to do this. This is black and white. The best solution is to fix libftdi; it is a replacement for FTD2XX. I will say it again: libusb and libftdi can be improved to do anything that the proprietary alternative does. Addressing any remaining issues with those libraries (e.g. driver certification) will cost pennies on the dollar when compared to what should be expected from trying to circumvent the binary distribution restrictions of the GPL. Sincerely, Zachary T Welch Corvallis, OR P.S. At least one technical solution does exist that would allow FTD2XX to be used with OpenOCD, without loading libftd2xx inside OpenOCD. However, I think developing this feature will cost much more than simply fixing any bugs and deficiencies with libusb and libftdi, and fixing those libraries has more value for the broader open source community. For this reason, my technical solution deserves to be rejected as well. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] committed - printf() warning fixes
On Fri, 2009-06-19 at 20:31 -0400, Duane Ellis wrote: duane FYI - I committed several cygwin specific printf() warning fixes. duaneSimple cast to fix duane these where causing -Werror failures on cygwin. zach I was just about to post some patches to show how to fix all of these zach correctly, as casts are not the right way to do it. In some cases, I can agree, but in others - I don't agree. A cast is by far the most simplest solution. For instance, look at this: LOG_WARNING(writing %d bytes only - as image section is %d bytes and bank is only %d bytes, \ (int)(c-base + c-size - run_address), (int)(run_size), (int)(c-size)); (a) look at what is being printed (b) the possible ranges of numbers (c) the number of parameters involved in the expressions At some point - having to dig back 20 to 30 -lines- to *random* places - because some variables are: (1) function parameters (2) defined at the top most block (3) defined locally to the local block (4) defined a few lines down from the top most block (5) often simplistic 'i/j/k' type vars that are reused because they are handy. (6) By the time I personally dig through the above, and determine all types involved (7) Then understand the underlying arithmetic integer promotion order... *note* this set of equations are simple... (8) a cast to a basic type is truly a very *simple* solution, (9) a cast to a basic type in this case is the K.I.S.S. solution. Either that - or we *need* a different solution here, the above is absurd. Comments? The simple solution is not the correct one in this case. The problem is that your assumptions about ranges are not portable; that is the point in using these macros. I don't care one white about KISS if the code is wrong. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Openocd-svn] r2293 - trunk/src/jtag
Rather than casting to int, should the printf's be using the PRI*
macros for uint32_t?
--
Rick Altherr
kc8...@kc8apf.net
He said he hadn't had a byte in three days. I had a short, so I split
it with him.
-- Unsigned
On Jun 19, 2009, at 4:16 PM, du...@mail.berlios.de wrote:
Author: duane
Date: 2009-06-20 01:15:58 +0200 (Sat, 20 Jun 2009)
New Revision: 2293
Modified:
trunk/src/jtag/arm-jtag-ew.c
trunk/src/jtag/core.c
trunk/src/jtag/ft2232.c
trunk/src/jtag/jlink.c
trunk/src/jtag/presto.c
trunk/src/jtag/tcl.c
Log:
printf() warning fixes due to uint32_t change-over
Modified: trunk/src/jtag/arm-jtag-ew.c
===
--- trunk/src/jtag/arm-jtag-ew.c2009-06-19 22:39:35 UTC (rev 2292)
+++ trunk/src/jtag/arm-jtag-ew.c2009-06-19 23:15:58 UTC (rev 2293)
@@ -472,14 +472,14 @@
if (result == 0)
{
unsigned int u_tg = buf_get_u32(usb_in_buffer, 0, 16);
- LOG_INFO(U_tg = %d mV, U_aux = %d mV, U_tgpwr = %d mV, I_tgpwr =
%d mA, D1 = %d, Target power %s %s\n, \
- buf_get_u32(usb_in_buffer + 0, 0, 16), \
- buf_get_u32(usb_in_buffer + 2, 0, 16), \
- buf_get_u32(usb_in_buffer + 4, 0, 16), \
- buf_get_u32(usb_in_buffer + 6, 0, 16), \
- usb_in_buffer[9], \
- usb_in_buffer[11] ? OVERCURRENT : OK, \
- usb_in_buffer[10] ? enabled : disabled);
+ LOG_INFO(U_tg = %d mV, U_aux = %d mV, U_tgpwr = %d mV, I_tgpwr =
%d mA, D1 = %d, Target power %s %s\n,
+(int)(buf_get_u32(usb_in_buffer + 0, 0, 16)),
+(int)(buf_get_u32(usb_in_buffer + 2, 0, 16)),
+(int)(buf_get_u32(usb_in_buffer + 4, 0, 16)),
+(int)(buf_get_u32(usb_in_buffer + 6, 0, 16)),
+usb_in_buffer[9],
+usb_in_buffer[11] ? OVERCURRENT : OK,
+usb_in_buffer[10] ? enabled : disabled);
if (u_tg 1500)
{
Modified: trunk/src/jtag/core.c
===
--- trunk/src/jtag/core.c 2009-06-19 22:39:35 UTC (rev 2292)
+++ trunk/src/jtag/core.c 2009-06-19 23:15:58 UTC (rev 2293)
@@ -862,10 +862,13 @@
const char *name, uint32_t idcode)
{
log_printf_lf(level, __FILE__, __LINE__, __FUNCTION__,
- JTAG tap: %s %16.16s: 0x%08x
- (mfg: 0x%3.3x, part: 0x%4.4x, ver: 0x%1.1x),
- name, msg, idcode,
- EXTRACT_MFG(idcode), EXTRACT_PART(idcode), EXTRACT_VER(idcode)
);
+ JTAG tap: %s %16.16s: 0x%08x
+ (mfg: 0x%3.3x, part: 0x%4.4x, ver: 0x%1.1x),
+ name, msg,
+ (unsigned int)idcode,
+ (unsigned int)EXTRACT_MFG(idcode),
+ (unsigned int)EXTRACT_PART(idcode),
+ (unsigned int)EXTRACT_VER(idcode) );
}
static bool jtag_idcode_is_final(uint32_t idcode)
@@ -889,7 +892,7 @@
if (!triggered jtag_idcode_is_final(idcode))
continue;
LOG_WARNING(Unexpected idcode after end of chain: %d 0x%08x,
- count, idcode);
+ count, (unsigned int)idcode);
triggered = true;
}
}
@@ -1100,7 +1103,7 @@
LOG_DEBUG(Created Tap: %s @ abs position %d,
irlen %d, capture: 0x%x mask: 0x%x, tap-dotted_name,
tap-abs_chain_position, tap-ir_length,
- tap-ir_capture_value, tap-ir_capture_mask);
+ (unsigned int)(tap-ir_capture_value), (unsigned int)(tap-
ir_capture_mask));
jtag_tap_add(tap);
}
Modified: trunk/src/jtag/ft2232.c
===
--- trunk/src/jtag/ft2232.c 2009-06-19 22:39:35 UTC (rev 2292)
+++ trunk/src/jtag/ft2232.c 2009-06-19 23:15:58 UTC (rev 2293)
@@ -411,7 +411,9 @@
if (*bytes_read size)
{
- LOG_ERROR(couldn't read the requested number of bytes from
FT2232 device (%i %i), *bytes_read, size);
+ LOG_ERROR(couldn't read the requested number of bytes from
FT2232 device (%i %i),
+ (unsigned int)(*bytes_read),
+ (unsigned int)size);
return ERROR_JTAG_DEVICE_ERROR;
}
@@ -963,7 +965,8 @@
LOG_ERROR(couldn't write MPSSE commands to FT2232);
exit(-1);
}
- LOG_DEBUG(ft2232_buffer_size: %i, bytes_written: %i,
ft2232_buffer_size, bytes_written);
+ LOG_DEBUG(ft2232_buffer_size: %i, bytes_written: %i,
+
Re: [Openocd-development] committed - printf() warning fixes
On Fri, 2009-06-19 at 17:40 -0700, Zach Welch wrote: On Fri, 2009-06-19 at 20:31 -0400, Duane Ellis wrote: duane FYI - I committed several cygwin specific printf() warning fixes. duaneSimple cast to fix duane these where causing -Werror failures on cygwin. zach I was just about to post some patches to show how to fix all of these zach correctly, as casts are not the right way to do it. In some cases, I can agree, but in others - I don't agree. A cast is by far the most simplest solution. For instance, look at this: LOG_WARNING(writing %d bytes only - as image section is %d bytes and bank is only %d bytes, \ (int)(c-base + c-size - run_address), (int)(run_size), (int)(c-size)); (a) look at what is being printed (b) the possible ranges of numbers (c) the number of parameters involved in the expressions At some point - having to dig back 20 to 30 -lines- to *random* places - because some variables are: (1) function parameters (2) defined at the top most block (3) defined locally to the local block (4) defined a few lines down from the top most block (5) often simplistic 'i/j/k' type vars that are reused because they are handy. (6) By the time I personally dig through the above, and determine all types involved (7) Then understand the underlying arithmetic integer promotion order... *note* this set of equations are simple... (8) a cast to a basic type is truly a very *simple* solution, (9) a cast to a basic type in this case is the K.I.S.S. solution. Either that - or we *need* a different solution here, the above is absurd. Comments? The simple solution is not the correct one in this case. The problem is that your assumptions about ranges are not portable; that is the point in using these macros. I don't care one white about KISS if the code is wrong. s/white/whit/ To be more constructive, I see two possibilities: 1) Revisit all of the places where warnings require format changes, and make the correct changes to support the C99 types. 2) Revert the changes to the type system. I am opposed to reverting the changes; I would rather we take some time to audit the code and fix the system to ensure we improve portability. In the same process, we could also fix up the 160 odd places where strtoul is used without sufficient error checking. With a few volunteers and some coordinated effort, we could address a lot of minor issues throughout the tree without any individual investing much effort. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Openocd-svn] r2293 - trunk/src/jtag
A-yup. :)
On Fri, 2009-06-19 at 18:13 -0700, Rick Altherr wrote:
Rather than casting to int, should the printf's be using the PRI*
macros for uint32_t?
--
Rick Altherr
kc8...@kc8apf.net
He said he hadn't had a byte in three days. I had a short, so I split
it with him.
-- Unsigned
On Jun 19, 2009, at 4:16 PM, du...@mail.berlios.de wrote:
Author: duane
Date: 2009-06-20 01:15:58 +0200 (Sat, 20 Jun 2009)
New Revision: 2293
Modified:
trunk/src/jtag/arm-jtag-ew.c
trunk/src/jtag/core.c
trunk/src/jtag/ft2232.c
trunk/src/jtag/jlink.c
trunk/src/jtag/presto.c
trunk/src/jtag/tcl.c
Log:
printf() warning fixes due to uint32_t change-over
Modified: trunk/src/jtag/arm-jtag-ew.c
===
--- trunk/src/jtag/arm-jtag-ew.c2009-06-19 22:39:35 UTC (rev 2292)
+++ trunk/src/jtag/arm-jtag-ew.c2009-06-19 23:15:58 UTC (rev 2293)
@@ -472,14 +472,14 @@
if (result == 0)
{
unsigned int u_tg = buf_get_u32(usb_in_buffer, 0, 16);
- LOG_INFO(U_tg = %d mV, U_aux = %d mV, U_tgpwr = %d mV, I_tgpwr
=
%d mA, D1 = %d, Target power %s %s\n, \
- buf_get_u32(usb_in_buffer + 0, 0, 16), \
- buf_get_u32(usb_in_buffer + 2, 0, 16), \
- buf_get_u32(usb_in_buffer + 4, 0, 16), \
- buf_get_u32(usb_in_buffer + 6, 0, 16), \
- usb_in_buffer[9], \
- usb_in_buffer[11] ? OVERCURRENT : OK, \
- usb_in_buffer[10] ? enabled : disabled);
+ LOG_INFO(U_tg = %d mV, U_aux = %d mV, U_tgpwr = %d mV, I_tgpwr
=
%d mA, D1 = %d, Target power %s %s\n,
+(int)(buf_get_u32(usb_in_buffer + 0, 0, 16)),
+(int)(buf_get_u32(usb_in_buffer + 2, 0, 16)),
+(int)(buf_get_u32(usb_in_buffer + 4, 0, 16)),
+(int)(buf_get_u32(usb_in_buffer + 6, 0, 16)),
+usb_in_buffer[9],
+usb_in_buffer[11] ? OVERCURRENT : OK,
+usb_in_buffer[10] ? enabled : disabled);
if (u_tg 1500)
{
Modified: trunk/src/jtag/core.c
===
--- trunk/src/jtag/core.c 2009-06-19 22:39:35 UTC (rev 2292)
+++ trunk/src/jtag/core.c 2009-06-19 23:15:58 UTC (rev 2293)
@@ -862,10 +862,13 @@
const char *name, uint32_t idcode)
{
log_printf_lf(level, __FILE__, __LINE__, __FUNCTION__,
- JTAG tap: %s %16.16s: 0x%08x
- (mfg: 0x%3.3x, part: 0x%4.4x, ver: 0x%1.1x),
- name, msg, idcode,
- EXTRACT_MFG(idcode), EXTRACT_PART(idcode), EXTRACT_VER(idcode)
);
+ JTAG tap: %s %16.16s: 0x%08x
+ (mfg: 0x%3.3x, part: 0x%4.4x, ver: 0x%1.1x),
+ name, msg,
+ (unsigned int)idcode,
+ (unsigned int)EXTRACT_MFG(idcode),
+ (unsigned int)EXTRACT_PART(idcode),
+ (unsigned int)EXTRACT_VER(idcode) );
}
static bool jtag_idcode_is_final(uint32_t idcode)
@@ -889,7 +892,7 @@
if (!triggered jtag_idcode_is_final(idcode))
continue;
LOG_WARNING(Unexpected idcode after end of chain: %d 0x%08x,
- count, idcode);
+ count, (unsigned int)idcode);
triggered = true;
}
}
@@ -1100,7 +1103,7 @@
LOG_DEBUG(Created Tap: %s @ abs position %d,
irlen %d, capture: 0x%x mask: 0x%x, tap-dotted_name,
tap-abs_chain_position, tap-ir_length,
- tap-ir_capture_value, tap-ir_capture_mask);
+ (unsigned int)(tap-ir_capture_value), (unsigned
int)(tap-
ir_capture_mask));
jtag_tap_add(tap);
}
Modified: trunk/src/jtag/ft2232.c
===
--- trunk/src/jtag/ft2232.c 2009-06-19 22:39:35 UTC (rev 2292)
+++ trunk/src/jtag/ft2232.c 2009-06-19 23:15:58 UTC (rev 2293)
@@ -411,7 +411,9 @@
if (*bytes_read size)
{
- LOG_ERROR(couldn't read the requested number of bytes from
FT2232 device (%i %i), *bytes_read, size);
+ LOG_ERROR(couldn't read the requested number of bytes from
FT2232 device (%i %i),
+ (unsigned int)(*bytes_read),
+ (unsigned int)size);
return ERROR_JTAG_DEVICE_ERROR;
}
@@ -963,7 +965,8 @@
LOG_ERROR(couldn't write MPSSE commands to FT2232);
exit(-1);
}
- LOG_DEBUG(ft2232_buffer_size: %i, bytes_written: %i,
Re: [Openocd-development] committed - printf() warning fixes
Zach Welch wrote:
On Fri, 2009-06-19 at 20:31 -0400, Duane Ellis wrote:
duane FYI - I committed several cygwin specific printf() warning fixes.
duaneSimple cast to fix
duane these where causing -Werror failures on cygwin.
zach I was just about to post some patches to show how to fix all of these
zach correctly, as casts are not the right way to do it.
In some cases, I can agree, but in others - I don't agree. A cast is by
far the most simplest solution.
For instance, look at this:
LOG_WARNING(writing %d bytes only - as image section is %d
bytes and bank is only %d bytes, \
(int)(c-base + c-size - run_address),
(int)(run_size), (int)(c-size));
(a) look at what is being printed
(b) the possible ranges of numbers
(c) the number of parameters involved in the expressions
At some point - having to dig back 20 to 30 -lines- to *random* places -
because some variables are:
(1) function parameters
(2) defined at the top most block
(3) defined locally to the local block
(4) defined a few lines down from the top most block
(5) often simplistic 'i/j/k' type vars that are reused because they are
handy.
(6) By the time I personally dig through the above, and determine all
types involved
(7) Then understand the underlying arithmetic integer promotion order...
*note* this set of equations are simple...
(8) a cast to a basic type is truly a very *simple* solution,
(9) a cast to a basic type in this case is the K.I.S.S. solution.
Either that - or we *need* a different solution here, the above is absurd.
Comments?
The simple solution is not the correct one in this case. The problem
is that your assumptions about ranges are not portable; that is the
point in using these macros.
You miss an important point, it is *NOT* the possible range of values
the *TYPE* may take on.
It is the range of values the **ACTUAL*DATA** might take on that is
important here.
Consider:
uint32_t x;
void funny_function( uint32_t );
for( x = 0 ; x 10 ; x++ ){
printf( X = %d, Calling funny function\n, (int)(x));
funny_function( x ) ;
}
In the above, I have several choices, (a) I could have used an int
variable - then *cast* it to a uint32_t at the function call (note here:
I am partial to x as a loop control variable, others like i/j/k) or -
because (b) the value will never be negative, I just choose 'uint32_t'
because it was convient.
Is the printf() statement *WRONG* - or is the printf() statement
*CORRECT* in this senario.
If we had to fix this, what would we do to fix this:
Today - we do not have macros, or types like GDB/GCC/GAS.
GDB for instance uses CORE_ADDR - and has infrastructure behind it.
Here, under OpenOCD we generally:
(1) assume that all embedded openocd targets are *32bit* at most...
(2) assume all host platforms are at least 32bit host platforms
(3) and thus, target addresses are generally equal to - or smaller then
the host unsigned integers
(4) In most, if not all of the u32 cases, the format string specifies
%08x or equal.
Are these assumptions *wrong*? If so, we have major other problems we
must deal with.
There are numerous examples of this where - for instance the code does
the following:
LOG_ERROR(Verfication error address 0x%08x, read back 0x%02x,
expected 0x%02x, address + wrote + i, readback[i], chunk[i]);
In this specific case, the *correct* fix is something else.
The address parameter really needs a *function* that handles the width
value. Otherwise, a 64bit target will not work. We are not proposing
to fix these situations today are we? Doing so would really be better
served by a function something like:
char *target_address_as_hex( CORE_ADDR address_value );
One can 'question' the two 8bit values printed, allow me to make my
point another way.
Here is another example:
LOG_INFO( device id = 0x%08x (manuf 0x%03x dev 0x%02x, ver 0x%03x),
device_id, (device_id1)0x7ff, (device_id12)0xff,
(device_id20)0xfff );
The format strings alone tell me that a 32bit unsigned *INTEGER* is
sufficient.
As does the math operators.
Since our *basic* assumption of the host platform is at least a 32bit
unsigned int
A simple cast is valid here.
Are you suggesting that our *basic* host assumption is wrong?
duane 9) a cast to a basic type in this case is the K.I.S.S.
solution.duane
zach I don't care one white about KISS if the code is wrong.
Is this a pedantic position/point you are trying to make?
The code today has *major* problems if/when we have a 64bit target.
The code is more *wrong* when we have 32bit hosts and 64bit targets.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] committed - printf() warning fixes
zach I am opposed to reverting the changes; I would rather zach we take some time to audit the code and fix the system zach to ensure we improve portability. Agreed 100% zach In the same process, we could also fix zach up the 160 odd places where strtoul is zach used without sufficient error checking. Agreed, but i'm messing with other stuff right now and these changes are disruptive. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Openocd-svn] r2293 - trunk/src/jtag
Rick Altherr wrote: Rather than casting to int, should the printf's be using the PRI* macros for uint32_t? To be clear, the LOG_INFO() format string is: LOG_INFO(U_tg = %d mV, U_aux = %d mV, U_tgpwr = %d mV, I_tgpwr = %d mA, D1 = %d, Target power %s %s\n, \ Really, if that is *truly* what is needed here, then I want to purchase one of those chips. Imagine, if that chip could *REALLY* withstand a 2^31 - millivolt input *and* handle 2^31 milliAmps. The truth is somewhere else: There are no convince functions to extract a simple integer instead. The value is a U32 because the developer was _lazy_. The solution you suggest - is the tail wagging the dog. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
On Sat, Jun 20, 2009 at 9:04 AM, Zach Welchz...@superlucidity.net wrote: P.S. At least one technical solution does exist that would allow FTD2XX to be used with OpenOCD, without loading libftd2xx inside OpenOCD. However, I think developing this feature will cost much more than simply fixing any bugs and deficiencies with libusb and libftdi, and fixing those libraries has more value for the broader open source community. For this reason, my technical solution deserves to be rejected as well. That would be a wonderful situation. Here are my thoughts. I can not code. But I can certainly help testing. I just need to buy a FT2232x based Jtag debugger. Or somebody can help me to get one. ;-) There may be quite some efforts to achieve this. One of the major obstacles may be to find good Windows driver programmers who are willing to help. And this will all be post 0.20. 1) Fixing libusb 0.1+libftdi-- Under Linux and Mac OS X, there is libusb 1.0 already. That may be the way to go. You can probably replace libusb 0.1+libftdi with libusb 1.0 directly. There will be performance gains. Or it is possible to get libftdi switching to libusb 1.0 (at least under Linux and Mac OS X). One example: http://github.com/qdot/libnifalcon/tree/master http://github.com/qdot/libnifalcon/tree/d0f176d9323fc314086f4b54bf5da502cb7d1a62/src/comm For FreeBSD and other users: port libusb 1.0 to your favorite OS. HPS is now revamping the USB stack for FreeBSD and he has the capability to port libusb 1.0 to FreeBSD or put up a compatible library since he has already developed libusb20 compatibility lib for libusb 0.1. Of course, libusb 0.1 can still be supported, but there may be performance penalties compared to libusb 1.0. 2) Fixing libusb-win32 0.1+libftdi for Windows. Solution 1: help libusb-win32 to fix the remaining issue (driver signing/certification, USB composite device handling, etc). And maybe fix the performance issue of libftdi or OpenOCD's way of using libftdi. Solution 2: port libusb 1.0 to Windows. That would be a nice solution. It can use the codes from libusb-win32. The driver signing/certification will still cost money. Then it can use the same code base from 1). -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] committed - printf() warning fixes
On Fri, 2009-06-19 at 21:24 -0400, Duane Ellis wrote:
Zach Welch wrote:
On Fri, 2009-06-19 at 20:31 -0400, Duane Ellis wrote:
duane FYI - I committed several cygwin specific printf() warning fixes.
duaneSimple cast to fix
duane these where causing -Werror failures on cygwin.
zach I was just about to post some patches to show how to fix all of these
zach correctly, as casts are not the right way to do it.
In some cases, I can agree, but in others - I don't agree. A cast is by
far the most simplest solution.
For instance, look at this:
LOG_WARNING(writing %d bytes only - as image section is %d
bytes and bank is only %d bytes, \
(int)(c-base + c-size - run_address),
(int)(run_size), (int)(c-size));
(a) look at what is being printed
(b) the possible ranges of numbers
(c) the number of parameters involved in the expressions
At some point - having to dig back 20 to 30 -lines- to *random* places -
because some variables are:
(1) function parameters
(2) defined at the top most block
(3) defined locally to the local block
(4) defined a few lines down from the top most block
(5) often simplistic 'i/j/k' type vars that are reused because they are
handy.
(6) By the time I personally dig through the above, and determine all
types involved
(7) Then understand the underlying arithmetic integer promotion order...
*note* this set of equations are simple...
(8) a cast to a basic type is truly a very *simple* solution,
(9) a cast to a basic type in this case is the K.I.S.S. solution.
Either that - or we *need* a different solution here, the above is absurd.
Comments?
The simple solution is not the correct one in this case. The problem
is that your assumptions about ranges are not portable; that is the
point in using these macros.
You miss an important point, it is *NOT* the possible range of values
the *TYPE* may take on.
It is the range of values the **ACTUAL*DATA** might take on that is
important here.
Consider:
uint32_t x;
void funny_function( uint32_t );
for( x = 0 ; x 10 ; x++ ){
printf( X = %d, Calling funny function\n, (int)(x));
funny_function( x ) ;
}
In the above, I have several choices, (a) I could have used an int
variable - then *cast* it to a uint32_t at the function call (note here:
I am partial to x as a loop control variable, others like i/j/k) or -
because (b) the value will never be negative, I just choose 'uint32_t'
because it was convient.
Is the printf() statement *WRONG* - or is the printf() statement
*CORRECT* in this senario.
It is wrong if you want to be safe when the ranges change, and with
general purpose functions the ranges may be set outside the scope of a
function that uses them. Safe code would not be making such assumptions
about the actual data; even if they hold today, they may not tomorrow.
That said, your pedantic example would work acceptably, though I would
argue the cast would be more correct to 'unsigned' using format '%u'.
If we had to fix this, what would we do to fix this:
Today - we do not have macros, or types like GDB/GCC/GAS.
GDB for instance uses CORE_ADDR - and has infrastructure behind it.
Here, under OpenOCD we generally:
(1) assume that all embedded openocd targets are *32bit* at most...
Today maybe, but this is an unacceptable shortcoming.
(2) assume all host platforms are at least 32bit host platforms
Again, this is a fair assumption today, but I do not think it again to
be a shortcoming that C99 types are designed to overcome.
(3) and thus, target addresses are generally equal to - or smaller then
the host unsigned integers
This is why we have intptr_t. The code shouldn't care. It's a bug if
it does.
(4) In most, if not all of the u32 cases, the format string specifies
%08x or equal.
It should... an audit would be required to confirm this is the case.
Are these assumptions *wrong*? If so, we have major other problems we
must deal with.
We have major other problems that we must deal with.
There are numerous examples of this where - for instance the code does
the following:
LOG_ERROR(Verfication error address 0x%08x, read back 0x%02x,
expected 0x%02x, address + wrote + i, readback[i], chunk[i]);
In this specific case, the *correct* fix is something else.
The address parameter really needs a *function* that handles the width
value. Otherwise, a 64bit target will not work. We are not proposing
to fix these situations today are we? Doing so would really be better
served by a function something like:
char *target_address_as_hex( CORE_ADDR address_value );
One can 'question' the two 8bit values printed, allow me to make my
point another way.
Yup. I am definitely not advocating for completely pedantic replacement
of all format strings.
Re: [Openocd-development] [Openocd-svn] r2293 - trunk/src/jtag
On Fri, 2009-06-19 at 21:35 -0400, Duane Ellis wrote: Rick Altherr wrote: Rather than casting to int, should the printf's be using the PRI* macros for uint32_t? To be clear, the LOG_INFO() format string is: LOG_INFO(U_tg = %d mV, U_aux = %d mV, U_tgpwr = %d mV, I_tgpwr = %d mA, D1 = %d, Target power %s %s\n, \ Really, if that is *truly* what is needed here, then I want to purchase one of those chips. Imagine, if that chip could *REALLY* withstand a 2^31 - millivolt input *and* handle 2^31 milliAmps. The truth is somewhere else: There are no convince functions to extract a simple integer instead. The value is a U32 because the developer was _lazy_. The solution you suggest - is the tail wagging the dog. The reality is that those values probably come across the wire in those data types, so it was _safer_ to use that type -- which is then known to be sufficient to hold all possible data values. This is particularly important in case these values are stored in a fixed point value, though your case in point does not demonstrate such need. The C99 macro solution will fix the warnings correctly without disrupting code that is unrelated to formatting existing values. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] committed - printf() warning fixes
On Fri, 2009-06-19 at 21:24 -0400, Duane Ellis wrote: [snip] If we had to fix this, what would we do to fix this: Today - we do not have macros, or types like GDB/GCC/GAS. GDB for instance uses CORE_ADDR - and has infrastructure behind it. [snip] This point deserves emphasis. This is the correct solution! Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Will the next release 0.2.0 build on FTD2XX support?
On Sat, Jun 20, 2009 at 9:04 AM, Zach Welchz...@superlucidity.net wrote: The community would be well advised to avoid these risks: use libftdi. I think it is not that difficult for people under Linux to use libftdi. But it is certainly not so easy to do that under Windows. Maybe a mini-howto will help for Windows user who want to libftdi. (for those who want to follow the GPL, accept the extra steps and potential performance penalties). But as it stands now, FTD2XX library is the nature choices for Windows users. So probably a more detailed document to build OpenOCD under Windows with FTD2XX is needed. The GPL issue can be highlighted and that the users can only use it as a private build and not distribute the binaries. P.S. At least one technical solution does exist that would allow FTD2XX to be used with OpenOCD, without loading libftd2xx inside OpenOCD. However, I think developing this feature will cost much more than simply fixing any bugs and deficiencies with libusb and libftdi, and fixing those libraries has more value for the broader open source community. For this reason, my technical solution deserves to be rejected as well. Just curious what is your technical solution and how difficult it is? It may be easier than fixing libusb+libftdi. You use the word 'simply. In reality it might be not that simple to fix libusb-win32+libftdi. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD + libftdi on Windows
On Fri, Jun 19, 2009 at 3:36 AM, Freddie Chopinfreddie_cho...@op.pl wrote: Anyway, about that equal performance with libftdi: Tested with a ~29kB image on LPC2103 (upload to flash): libftdi: Start address 0x3c, load size 29640 Transfer rate: 6 KB/sec, 14820 bytes/write. ftd2xx: Start address 0x3c, load size 29640 Transfer rate: 15 KB/sec, 14820 bytes/write. So: libftdi is 2.5x slower Tested with ~114kB image on STM32 (upload to flash): libftdi: Start address 0x8000134, load size 114432 Transfer rate: 8 KB/sec, 16347 bytes/write. ftd2xx: Start address 0x8000134, load size 114432 Transfer rate: 11 KB/sec, 16347 bytes/write. Again slower, this time only about 30%, but still, that's nowhere to comparable From libftdi mailing lists and various places, it seems the major issue of libftdi compared to FTD2XX is because of the use of libusb 0.1 and synchronous I/O. http://developer.intra2net.com/mailarchive/html/libftdi/2009/msg00093.html My second question is: Does anyone know why an FT_Read with FT's D2XX lib does return so fast? (I measured approx. 0.01ms compared to my 1ms with the ftdi_read_data.) D2XX uses threads to constantly poll and read the device. The read function just fetches the data from the internal buffer AFAIK. *** Actually libusb-win32 0.1 already supports asynchronous I/O. And libusb 1.0 under Linux and Mac OS X supports asynchronous I/O as well. So it is possible to fix this issue with libftdi. It will be a major change for OpenOCD as well. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD + libftdi on Windows
On Sat, 2009-06-20 at 11:13 +0800, Xiaofan Chen wrote: On Fri, Jun 19, 2009 at 3:36 AM, Freddie Chopinfreddie_cho...@op.pl wrote: Anyway, about that equal performance with libftdi: Tested with a ~29kB image on LPC2103 (upload to flash): libftdi: Start address 0x3c, load size 29640 Transfer rate: 6 KB/sec, 14820 bytes/write. ftd2xx: Start address 0x3c, load size 29640 Transfer rate: 15 KB/sec, 14820 bytes/write. So: libftdi is 2.5x slower Tested with ~114kB image on STM32 (upload to flash): libftdi: Start address 0x8000134, load size 114432 Transfer rate: 8 KB/sec, 16347 bytes/write. ftd2xx: Start address 0x8000134, load size 114432 Transfer rate: 11 KB/sec, 16347 bytes/write. Again slower, this time only about 30%, but still, that's nowhere to comparable From libftdi mailing lists and various places, it seems the major issue of libftdi compared to FTD2XX is because of the use of libusb 0.1 and synchronous I/O. http://developer.intra2net.com/mailarchive/html/libftdi/2009/msg00093.html My second question is: Does anyone know why an FT_Read with FT's D2XX lib does return so fast? (I measured approx. 0.01ms compared to my 1ms with the ftdi_read_data.) D2XX uses threads to constantly poll and read the device. The read function just fetches the data from the internal buffer AFAIK. *** Actually libusb-win32 0.1 already supports asynchronous I/O. And libusb 1.0 under Linux and Mac OS X supports asynchronous I/O as well. So it is possible to fix this issue with libftdi. It will be a major change for OpenOCD as well. I think many developers realize the benefits of non-blocking I/O, and -- as you say -- they also realize the changes will be fairly dramatic. This is on The List (the TODO file) in the JTAG section (search for 'non-blocking'), but it is definitely post 0.2.0. For 0.2.0, you can build your own personal binaries that use FTD2XX or use distributed binaries with libftdi (and try to live with any performance degradations). Such is the GPL. However, I hope this motivates the community at large to work on removing the limitations in our open source solutions. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] inf file for libusb
Xiaofan Chen wrote, On 06/19/2009 07:35 PM: Glad to hear that OpenOCD works with the libusb-win32/libftdi combination. As for the com port, if it is part of the device, then using libusb-win32 device driver (as the driver of the whole USB composite device) will disable it. That is the side effect. http://article.gmane.org/gmane.comp.lib.libusb.devel.windows/2088 whole device? You have to replace the 'composite device driver' by libusb's device driver. It should work then. See http://tinyurl.com/dxxnal for an architecture overview. This method has one drawback though: your device doesn't work as a mass-storage-device or printer any more since Windows will stop loading the drivers. Stephan Meyer (author of libusb-win32) was answering the question of how to use libusb-win32 with a usb composite device (printer/mass storage/etc). I notice that there is another composite usb device under usb devices in dev mgr. I also see it on the list when I run the inf wizard. I think you are saying I need to make another inf file for that device (with wizard) and replace its microsoft driver with the libusb driver for that device too. That will allow the serial port to work on the olimex (and the jtag functionality to continue). However, if I plug in, say, a usb memory stick or my usb camera (mass storage) or a printer it will not be seen since the driver is replaced by libusb. Am I anywhere close to understanding what this means? Losing the ability to have USB mass storage (or a printer) is kind of bad, if I understand what you are saying. I assume, also, that you don't have these limitations with the proprietary ftd2xx driver? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
