Re: [Openocd-development] RFC Release Cycle
On Tue, Jun 21, 2011 at 1:30 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: After some consideration, I've changed my view to that the release manager should have git access and that the master branch developers *should* follow the release managers marching orders and that we follow the cycle Jean-Christophe outlined... I think perhaps that 2-4 releases / year would be plenty for OpenOCD though. 2 release is quite good. 4 release will be wonderful if there are enough changes or bug fixes. I think it is not necessary if there are not enough changes to justify 4 release. 6-release may be too aggressive for a project like OpenOCD due to limit resources (unless more maintainers and volunteers jump in). I am looking forward to seeing the OpenOCD 0.5 release. At least Peter Stuge will have one less reason to argue for his idea that not-release-forever project is still active. :-) http://libusb.6.n5.nabble.com/Re-Openocd-development-Peter-Stuge-is-now-an-OpenOCD-maintainer-tp4476710p4481873.html Peter Stuge's idea about release and what is an active project. If none works on code then a project is inactive. Activity = anything happens. Activity != releases happen. You and Xiaofan seem to agree with me that OpenOCD is an active project. As you know, OpenOCD has gone longer than libusb without a release. Of course he has a point but I hope most of the project admins not to follow his ideas about release. Release is not that expensive -- so it should be done once in a while. Release is not too cheap (if project is complex enough or with limited resources) -- so it should be done not that often. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal / OBJECTION
On 21/06/2011, at 3:59 PM, Laurent Gauch wrote: On 21/06/2011, at 1:07 AM, Laurent Gauch wrote: / // / On Mon, Jun 20, 2011 at 1:00 PM, Steve Bennett steveb at workware.net.au https://lists.berlios.de/mailman/listinfo/openocd-development wrote: // // On 20/06/2011, at 8:54 PM, Øyvind Harboe wrote: // // // On Mon, Jun 20, 2011 at 12:50 PM, Steve Bennett steveb at workware.net.au https://lists.berlios.de/mailman/listinfo/openocd-development wrote: // // Instead, just produce a warning // // // Why? // // // It merits a comment at least? // // // Seems self-evident to me. // // Why should it be fatal just because a value couldn't be read? // // Doesn't stop anything from working. // // // Why should we support broken hardware or drivers? // // // Better the user is told to toss his busted dongle / hardware than to tangle // // with subtle followon errors? // / // Nothing to do with hardware. It's a problem with the driver. // See http://www.mail-archive.com/openocd-development@lists.berlios.de/msg15945.html // // / / // Objection ! // // If we cannot read this value back, this means we reach trouble with driver or device somewhere. // Also, this trouble could affect following access ... // This is why we stop with fatal error. / OK. So what alternative solution would you suggest to make this driver work? What version of the driver do you use. If it really come from the driver and if this is the last official driver, then ask the writer of the driver to correct. If no correction are done quickly by the writer of the driver, then yes, you may just produce a warning. http://www.ftdichip.com/Drivers/D2XX.htm Latest version, 1.0.4. Same behaviour on both MacOSX and Linux. Sure. I'll ask if they would like to fix this problem. I will let you know what useful response I get. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Openocd release known issues
Try this: http://repo.or.cz/w/jimtcl.git/commit/fbc998db178da5c462e164b63da128a7d7412e37 With your recent changes, now 'make distcheck' works for me. Many thanks :-) I am away on holiday at the moment so will not get time to look at this again until next week. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal / OBJECTION
Steve Bennett wrote: On 21/06/2011, at 3:59 PM, Laurent Gauch wrote: On 21/06/2011, at 1:07 AM, Laurent Gauch wrote: / // / On Mon, Jun 20, 2011 at 1:00 PM, Steve Bennett steveb at workware.net.au https://lists.berlios.de/mailman/listinfo/openocd-development wrote: // // On 20/06/2011, at 8:54 PM, Øyvind Harboe wrote: // // // On Mon, Jun 20, 2011 at 12:50 PM, Steve Bennett steveb at workware.net.au https://lists.berlios.de/mailman/listinfo/openocd-development wrote: // // Instead, just produce a warning // // // Why? // // // It merits a comment at least? // // // Seems self-evident to me. // // Why should it be fatal just because a value couldn't be read? // // Doesn't stop anything from working. // // // Why should we support broken hardware or drivers? // // // Better the user is told to toss his busted dongle / hardware than to tangle // // with subtle followon errors? // / // Nothing to do with hardware. It's a problem with the driver. // See http://www.mail-archive.com/openocd-development@lists.berlios.de/msg15945.html // // / / // Objection ! // // If we cannot read this value back, this means we reach trouble with driver or device somewhere. // Also, this trouble could affect following access ... // This is why we stop with fatal error. / OK. So what alternative solution would you suggest to make this driver work? What version of the driver do you use. If it really come from the driver and if this is the last official driver, then ask the writer of the driver to correct. If no correction are done quickly by the writer of the driver, then yes, you may just produce a warning. http://www.ftdichip.com/Drivers/D2XX.htm Latest version, 1.0.4. Same behaviour on both MacOSX and Linux. Sure. I'll ask if they would like to fix this problem. I will let you know what useful response I get. Great. But are you sure to have the correct libusb version. On linux and mac, the libusb is the kernel driver for the d2xx. Regards, Laurent Gauch http://www.amontec.com Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal / OBJECTION
On 21/06/2011, at 4:45 PM, Laurent Gauch wrote: Steve Bennett wrote: On 21/06/2011, at 3:59 PM, Laurent Gauch wrote: On 21/06/2011, at 1:07 AM, Laurent Gauch wrote: / // / On Mon, Jun 20, 2011 at 1:00 PM, Steve Bennett steveb at workware.net.au https://lists.berlios.de/mailman/listinfo/openocd-development wrote: // // On 20/06/2011, at 8:54 PM, Øyvind Harboe wrote: // // // On Mon, Jun 20, 2011 at 12:50 PM, Steve Bennett steveb at workware.net.au https://lists.berlios.de/mailman/listinfo/openocd-development wrote: // // Instead, just produce a warning // // // Why? // // // It merits a comment at least? // // // Seems self-evident to me. // // Why should it be fatal just because a value couldn't be read? // // Doesn't stop anything from working. // // // Why should we support broken hardware or drivers? // // // Better the user is told to toss his busted dongle / hardware than to tangle // // with subtle followon errors? // / // Nothing to do with hardware. It's a problem with the driver. // See http://www.mail-archive.com/openocd-development@lists.berlios.de/msg15945.html // // / / // Objection ! // // If we cannot read this value back, this means we reach trouble with driver or device somewhere. // Also, this trouble could affect following access ... // This is why we stop with fatal error. / OK. So what alternative solution would you suggest to make this driver work? What version of the driver do you use. If it really come from the driver and if this is the last official driver, then ask the writer of the driver to correct. If no correction are done quickly by the writer of the driver, then yes, you may just produce a warning. http://www.ftdichip.com/Drivers/D2XX.htm Latest version, 1.0.4. Same behaviour on both MacOSX and Linux. Sure. I'll ask if they would like to fix this problem. I will let you know what useful response I get. Great. But are you sure to have the correct libusb version. On linux and mac, the libusb is the kernel driver for the d2xx. Yes. I am using the static library of libftd2xx which includes libusb. (openocd does not build with the shared library) Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal / OBJECTION
On Tue, Jun 21, 2011 at 2:45 PM, Laurent Gauch laurent.ga...@amontec.com wrote: Latest version, 1.0.4. Same behaviour on both MacOSX and Linux. Sure. I'll ask if they would like to fix this problem. I will let you know what useful response I get. Great. But are you sure to have the correct libusb version. On linux and mac, the libusb is the kernel driver for the d2xx. This has been discussed before and I think in this case an exception should be granted and the patch should be accepted. Thread: http://lists.berlios.de/pipermail/openocd-development/2011-March/018422.html I was suggesting the user to use the open source libftdi and libftdi-1.0 under Linux instead but D2XX might still have some benefits so that users may still want to use it. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal / OBJECTION
On Tue, Jun 21, 2011 at 2:55 PM, Xiaofan Chen xiaof...@gmail.com wrote: But are you sure to have the correct libusb version. On linux and mac, the libusb is the kernel driver for the d2xx. This has been discussed before and I think in this case an exception should be granted and the patch should be accepted. Thread: http://lists.berlios.de/pipermail/openocd-development/2011-March/018422.html I was suggesting the user to use the open source libftdi and libftdi-1.0 under Linux instead but D2XX might still have some benefits so that users may still want to use it. It is a long thread but I was able to reproduce the error. http://lists.berlios.de/pipermail/openocd-development/2011-March/018434.html I think the latest d2xx library needs some fix from the OpenOCD side or from the d2xx side. It is more difficult to ask FTDI for a fix so it may better to fix this from OpenOCD side. Therefore I think the patch should be accepted. When FTDI fixes D2xx, then probably the patch can be reverted. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal / OBJECTION
On 21/06/2011, at 5:01 PM, Xiaofan Chen wrote: On Tue, Jun 21, 2011 at 2:55 PM, Xiaofan Chen xiaof...@gmail.com wrote: But are you sure to have the correct libusb version. On linux and mac, the libusb is the kernel driver for the d2xx. This has been discussed before and I think in this case an exception should be granted and the patch should be accepted. Thread: http://lists.berlios.de/pipermail/openocd-development/2011-March/018422.html I was suggesting the user to use the open source libftdi and libftdi-1.0 under Linux instead but D2XX might still have some benefits so that users may still want to use it. It is a long thread but I was able to reproduce the error. http://lists.berlios.de/pipermail/openocd-development/2011-March/018434.html I think the latest d2xx library needs some fix from the OpenOCD side or from the d2xx side. It is more difficult to ask FTDI for a fix so it may better to fix this from OpenOCD side. Therefore I think the patch should be accepted. When FTDI fixes D2xx, then probably the patch can be reverted. I have reported the problem to FTDI, but in my experience we can not expect a response soon, if ever. I think there are two options, either apply the patch as a workaround (note that the returned value is *never* used), or remove support for D2XX. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal / OBJECTION
Xiaofan Chen wrote: On Tue, Jun 21, 2011 at 2:55 PM, Xiaofan Chen xiaof...@gmail.com wrote: But are you sure to have the correct libusb version. On linux and mac, the libusb is the kernel driver for the d2xx. This has been discussed before and I think in this case an exception should be granted and the patch should be accepted. Thread: http://lists.berlios.de/pipermail/openocd-development/2011-March/018422.html I was suggesting the user to use the open source libftdi and libftdi-1.0 under Linux instead but D2XX might still have some benefits so that users may still want to use it. It is a long thread but I was able to reproduce the error. http://lists.berlios.de/pipermail/openocd-development/2011-March/018434.html I think the latest d2xx library needs some fix from the OpenOCD side or from the d2xx side. It is more difficult to ask FTDI for a fix so it may better to fix this from OpenOCD side. Therefore I think the patch should be accepted. When FTDI fixes D2xx, then probably the patch can be reverted. Yes, right. I revert my objection. We can merge this patch and we will revert it lately. Regards, Laurent ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal
Steve Bennett wrote: On 21/06/2011, at 5:01 PM, Xiaofan Chen wrote: On Tue, Jun 21, 2011 at 2:55 PM, Xiaofan Chen xiaof...@gmail.com wrote: But are you sure to have the correct libusb version. On linux and mac, the libusb is the kernel driver for the d2xx. This has been discussed before and I think in this case an exception should be granted and the patch should be accepted. Thread: http://lists.berlios.de/pipermail/openocd-development/2011-March/018422.html I was suggesting the user to use the open source libftdi and libftdi-1.0 under Linux instead but D2XX might still have some benefits so that users may still want to use it. It is a long thread but I was able to reproduce the error. http://lists.berlios.de/pipermail/openocd-development/2011-March/018434.html I think the latest d2xx library needs some fix from the OpenOCD side or from the d2xx side. It is more difficult to ask FTDI for a fix so it may better to fix this from OpenOCD side. Therefore I think the patch should be accepted. When FTDI fixes D2xx, then probably the patch can be reverted. I have reported the problem to FTDI, but in my experience we can not expect a response soon, if ever. I think there are two options, either apply the patch as a workaround (note that the returned value is *never* used), or remove support for D2XX. Thank you Steve, If you do not get any reply on next Monday, please let me know I will ask them. Amontec has good contacts to FTDI team. Please apply the patch as a workaround. But if the returned value is never used, there are no reason to give a warning ! Laurent http://www.amontec.com Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] ft2232: Failure to get latency should not be fatal
On 21/06/2011, at 5:18 PM, Laurent Gauch wrote: Steve Bennett wrote: On 21/06/2011, at 5:01 PM, Xiaofan Chen wrote: On Tue, Jun 21, 2011 at 2:55 PM, Xiaofan Chen xiaof...@gmail.com wrote: But are you sure to have the correct libusb version. On linux and mac, the libusb is the kernel driver for the d2xx. This has been discussed before and I think in this case an exception should be granted and the patch should be accepted. Thread: http://lists.berlios.de/pipermail/openocd-development/2011-March/018422.html I was suggesting the user to use the open source libftdi and libftdi-1.0 under Linux instead but D2XX might still have some benefits so that users may still want to use it. It is a long thread but I was able to reproduce the error. http://lists.berlios.de/pipermail/openocd-development/2011-March/018434.html I think the latest d2xx library needs some fix from the OpenOCD side or from the d2xx side. It is more difficult to ask FTDI for a fix so it may better to fix this from OpenOCD side. Therefore I think the patch should be accepted. When FTDI fixes D2xx, then probably the patch can be reverted. I have reported the problem to FTDI, but in my experience we can not expect a response soon, if ever. I think there are two options, either apply the patch as a workaround (note that the returned value is *never* used), or remove support for D2XX. Thank you Steve, If you do not get any reply on next Monday, please let me know I will ask them. Amontec has good contacts to FTDI team. Will do. Please apply the patch as a workaround. It is on the list. Perhaps some kind maintainer will do so. But if the returned value is never used, there are no reason to give a warning ! Agreed. But it seemed less of a step from fatal error to warning than ignoring it completely. Cheers, Steve -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [OpenOCD] [PATCH 1/1] load_image should use virtual (p_vaddr) instead of physical (p_paddr) ELF segment addr
Hi all,
yesterday I run into the ELF like this :
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x74 0x8000 0x 0xe1f18 0xe1f18 RWE 0x1
LOAD 0x0e1f8c 0x0060f028 0x 0x1103f 0x1103f RWE 0x1
As it can be seen from the readelf output, PhysAddress of the segments
is 0x0, and this posed problems for the load_image command of OpenOCD.
However, arm GDB was very happy to load it, loading section by section
at appropriate virtual addresses.
I did some investigation, and I found out (from ELF specification) :
p_vaddr : This member gives the virtual address at which the first
byte of the segment resides in
memory.
p_paddr : On systems for which physical addressing is relevant, this
member is reserved for the
segment’s physical address. Because System V ignores physical
addressing for application
programs, this member has unspecified contents for executable files and shared
objects.
Then I run into these posts :
http://cygwin.com/ml/binutils/2002-09/msg00516.html
http://lists.gnu.org/archive/html/bug-gnu-utils/2002-08/msg00319.html
ARM ELF specification seems to be stating explicitly that p_paddr in
the Program Header Table should be put to zero for all Text, Data and
BSS segments:
p_vaddr - load address of the segment
p_paddr - 0
Further on, in Scatter-loaded Executables part of the same document it says :
sh_addr: same as p_vaddr of corresponding Segment
The p_vaddr field of each Segment of a scatter-loaded Executable is
the load address
of the Segment, which need not necessarily be its execution address.
Startup code can
move (part of) a Segment to its execution address using the symbols:
Load$$reg$$Base
Image$$reg$$Base
Image$$reg$$Length
as described in the Software Development Toolkit User Guide.
I am guessing that GDB uses this method and always takes p_vaddr
(OpenOCD is not consistent to GDB in this case).
To conclude, I crafted a trivial patch which will impose taking
p_vaddr as the load destination of the segment whenever p_paddr is
0x0.
I was a bit afraid to go for p_vaddr only_and_always, but left this as
a solution, because I do not know the impact on other architectures,
so I followed this post :
http://www.mail-archive.com/bug-grub@gnu.org/msg00715.html
What do you think ?
Best regards,
Drasko
From f4d2841959946ed156f569314dc82795c880bae9 Mon Sep 17 00:00:00 2001
From: Drasko DRASKOVIC drasko.drasko...@gmail.com
Date: Tue, 21 Jun 2011 13:10:35 +0200
Subject: [PATCH] load_image command should use virtual address (p_vaddr) for ELF
So far image_load command tries to load ELF binaries to address
discovered by reading p_paddr member of a Program header of an ELF
segment.
However, ELF specifications says for p_paddr : ...Because System V ignores physical addressing
for application programs, this member has unspecified contents for executable files
and shared objects.
ARM ELF specifiaction goes even further, demanding that this member be
set to zero, using the p_vaddr as a segment load address.
To avoid the cases to wrong addr where p_paddr is zero,
we are now using p_vaddr to as a load destination in case that p_paddr
== 0. If p_addr is !=0, we are using it and not p_vaddr (to keep compatibility
with other platforms, if any).
---
src/target/image.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/src/target/image.c b/src/target/image.c
index 454fc6c..af12d7c 100644
--- a/src/target/image.c
+++ b/src/target/image.c
@@ -478,7 +478,10 @@ static int image_elf_read_headers(struct image *image)
if ((field32(elf, elf-segments[i].p_type) == PT_LOAD) (field32(elf, elf-segments[i].p_filesz) != 0))
{
image-sections[j].size = field32(elf,elf-segments[i].p_filesz);
- image-sections[j].base_address = field32(elf,elf-segments[i].p_paddr);
+ if (elf-segments[i].p_paddr != 0)
+image-sections[j].base_address = field32(elf,elf-segments[i].p_paddr);
+ else
+image-sections[j].base_address = field32(elf,elf-segments[i].p_vaddr);
image-sections[j].private = elf-segments[i];
image-sections[j].flags = field32(elf,elf-segments[i].p_flags);
j++;
--
1.5.6.5
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD] [PATCH 1/1] load_image should use virtual (p_vaddr) instead of physical (p_paddr) ELF segment addr
Some more posts on this interesting topic : http://blackfin.uclinux.org/gf/project/u-boot/tracker/?action=TrackerItemEdittracker_item_id=642 http://lists.gnu.org/archive/html/bug-gnu-utils/2002-08/msg00324.html Seems to me that solution proposed in the patch is OK, but I am still wondering : is there a case on some architectures where you can have valid load physicall address of 0x0 (i.e. if you want to load U-Boot at the address 0x0, and it has normally different execution address (vma), as it is linked to address where it will auto-relocate, and only the beginning is executed PIC code executed from addr 0x0) ? This is the only case (if exists) that this patch will not handle, but will go for vma addr (i.e. will load U-Boot at the address for which it was compiled to run after auto-relocation, not at the address where this is supposed, 0x0). BR, Drasko On Tue, Jun 21, 2011 at 2:59 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: Hi all, yesterday I run into the ELF like this : Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x74 0x8000 0x 0xe1f18 0xe1f18 RWE 0x1 LOAD 0x0e1f8c 0x0060f028 0x 0x1103f 0x1103f RWE 0x1 As it can be seen from the readelf output, PhysAddress of the segments is 0x0, and this posed problems for the load_image command of OpenOCD. However, arm GDB was very happy to load it, loading section by section at appropriate virtual addresses. I did some investigation, and I found out (from ELF specification) : p_vaddr : This member gives the virtual address at which the first byte of the segment resides in memory. p_paddr : On systems for which physical addressing is relevant, this member is reserved for the segment’s physical address. Because System V ignores physical addressing for application programs, this member has unspecified contents for executable files and shared objects. Then I run into these posts : http://cygwin.com/ml/binutils/2002-09/msg00516.html http://lists.gnu.org/archive/html/bug-gnu-utils/2002-08/msg00319.html ARM ELF specification seems to be stating explicitly that p_paddr in the Program Header Table should be put to zero for all Text, Data and BSS segments: p_vaddr - load address of the segment p_paddr - 0 Further on, in Scatter-loaded Executables part of the same document it says : sh_addr: same as p_vaddr of corresponding Segment The p_vaddr field of each Segment of a scatter-loaded Executable is the load address of the Segment, which need not necessarily be its execution address. Startup code can move (part of) a Segment to its execution address using the symbols: Load$$reg$$Base Image$$reg$$Base Image$$reg$$Length as described in the Software Development Toolkit User Guide. I am guessing that GDB uses this method and always takes p_vaddr (OpenOCD is not consistent to GDB in this case). To conclude, I crafted a trivial patch which will impose taking p_vaddr as the load destination of the segment whenever p_paddr is 0x0. I was a bit afraid to go for p_vaddr only_and_always, but left this as a solution, because I do not know the impact on other architectures, so I followed this post : http://www.mail-archive.com/bug-grub@gnu.org/msg00715.html What do you think ? Best regards, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT
My objective is not to block feature.Never,never,never ... But we have to avoid any trouble in generic ft2232 driver regarding specific layout. That's all. Your TCL bitbang will control the port of the FTDI from an higher level than FT2232.c. OK but you TCL bitbang is specific to the layout used. How do you accept or not the use of the TCL procedure, if you do not have the notion of layout in this function ??? You have two solutions: You need to write a specifc driver (), or you need to filter the TCL bitbang action in the ft2232 generic driver. The filter must be specifc to the open layout ... The same is for SRST TRST control. The ft2232.c driver has specific functions for SRST TRST regarding layout used ... we have to do this for ANY other specific layout signal in the ft2232.c or write a specific driver. I think there is an misunderstanding here. My reading of Tomek's emails indicates there is a layout specific mechanism to filter which pins can be bitbanged. The interface config file will define which pins can be bitbanged and how. Is this correct? Phil___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD] [PATCH 1/1] load_image should use virtual (p_vaddr) instead of physical (p_paddr) ELF segment addr
http://www.mail-archive.com/bug-grub@gnu.org/msg00715.html From 1999? Time flies, eh? What do you think ? Until we understand this better, I think we can wait with applying the patch. Look at gdb source code? Perhaps bfd library? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD] [PATCH 1/1] load_image should use virtual (p_vaddr) instead of physical (p_paddr) ELF segment addr
On Tue, Jun 21, 2011 at 6:18 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
http://www.mail-archive.com/bug-grub@gnu.org/msg00715.html
From 1999? Time flies, eh?
For BDF time flies slowely ;)... Anyway, I gave this just as example
of implementation (as I underlined, btw.), but real reasons are
explained in other posts.
What do you think ?
Until we understand this better, I think we can wait with applying the
patch.
To understand this better all the posts I mentioned deserve reading.
The subject is not so obvious and deserves a little study..
Look at gdb source code?
I gave an example from the U-Boot sources, ARM ELF specification
(which is clearly not respected), bunh of posts, etc... Thought that
that would be more than enough for someone who want to dig into the
subject.
Perhaps bfd library?
Yes, that would be the right place, but I hoped to avoid further digging ;).
Here is something interesting, from the gdb's src/bfd/elf.c, line 963
(and it is related to one of the posts I mentioned previously) :
if ((flags SEC_ALLOC) != 0)
{
Elf_Internal_Phdr *phdr;
unsigned int i, nload;
/* Some ELF linkers produce binaries with all the program header
p_paddr fields zero. If we have such a binary with more than
one PT_LOAD header, then leave the section lma equal to vma
so that we don't create sections with overlapping lma. */
phdr = elf_tdata (abfd)-phdr;
for (nload = 0, i = 0; i elf_elfheader (abfd)-e_phnum; i++, phdr++)
if (phdr-p_paddr != 0)
break;
else if (phdr-p_type == PT_LOAD phdr-p_memsz != 0)
++nload;
if (i = elf_elfheader (abfd)-e_phnum nload 1)
return TRUE;
Basically, BFD (and thus GDB) knows a workaround - which seems to be
the same thing I did - if your ELF has p_paddr == 0, make it equal to
p_vaddr, and use this as LMA.
ARM ELF compliant linker _must_ produce ELF with p_paddr = 0.
It seems like GNU ld (which probably uses these workarounds from BFD)
equals p_paddr to p_vaddr, so that the problem is masked, and OpenOCD
is using p_paddr.
Once you stumble upon ELF linked with some ARM ELF compliant liker,
OpenOCD will go wrong, while GDB will do fine by using the upper
mentioned procedure.
My opinion is that we currently have *broken* OpenOCD load_image
behavior (works with GNU ld, though), and that we can not make it any
worst with this patch.
I hope that this clarifies my assumptions and gives more material for
others to jump in with suggestions.
I also opened the question - is there a valid ELF that has p_paddr 0x0
and p_vaddr != 0. Obviously, regarding the upper mentioned code from
BFD, production of such ELF is not possible with GNU ld, because it
will keep p_paddr_valid flag at FALSE and equalize p_paddr to p_vaddr
at some point...
Let's wait for some more responses on this list and I can post the
question on Binutils dev list, to clear this subject...
BR,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Request for review: driver for Keil ULINK
On Tue, 21 Jun 2011 18:34:16 +0200, Martin Schmölzer martin.schmoel...@student.tuwien.ac.at wrote: Hi, my ULINK driver for OpenOCD is finally in a usable state. Attached is a patch set that adds this driver + the custom firmware for the ULINK adapter. Currently, this is only tested with an Olimex STM32-P103 development board (STM32F103RBT6). stm32x mass_erase and flash write_image erase both work. The driver/firmware uses one USB bulk endpoint and is designed to queue several commands into one packet for better throughput. The first version of the driver used the naive approach of one packet per command which (of course) had horrible performance (~ 800 Byte/sec flash speed for the STM32). The current implementation reaches about 4.5 kB/sec, which seems to be the maximum I can get out of the Cypress EZ-USB MCU that is used in the ULINK adapter. Some features are still incomplete: - Pathmove commands - TCK speed: Currently, the ULINK only works at its maximum TCK frequency (about 150 kHz, measured using a digital storage oscilloscope). I'm planning to complete these features and further testing by early/mid july. Feedback is highly appreciated! Best regards, Martin Hi Martin, I've got a ulink at home with an MCB board (I forgot the exact number), so this is exciting news for me. I've been wanting to lean the internals of OCD and Jtag for a while, could anybody suggest some technical jtag/gdb/arm documents? I am also curious, how did you figure out the format of the data in the packets you're sending to the Ulink? thanks, -Chris ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD] [PATCH 1/1] load_image should use virtual (p_vaddr) instead of physical (p_paddr) ELF segment addr
Am 06/21/2011 07:19 PM, schrieb Drasko DRASKOVIC:
Perhaps bfd library?
Yes, that would be the right place, but I hoped to avoid further digging ;).
Here is something interesting, from the gdb's src/bfd/elf.c, line 963
(and it is related to one of the posts I mentioned previously) :
if ((flags SEC_ALLOC) != 0)
{
Elf_Internal_Phdr *phdr;
unsigned int i, nload;
/* Some ELF linkers produce binaries with all the program header
p_paddr fields zero. If we have such a binary with more than
one PT_LOAD header, then leave the section lma equal to vma
so that we don't create sections with overlapping lma. */
phdr = elf_tdata (abfd)-phdr;
for (nload = 0, i = 0; i elf_elfheader (abfd)-e_phnum; i++, phdr++)
if (phdr-p_paddr != 0)
break;
else if (phdr-p_type == PT_LOAD phdr-p_memsz != 0)
++nload;
if (i = elf_elfheader (abfd)-e_phnum nload 1)
return TRUE;
Basically, BFD (and thus GDB) knows a workaround - which seems to be
the same thing I did - if your ELF has p_paddr == 0, make it equal to
p_vaddr, and use this as LMA.
Um - unless I misread the code, there is an important difference:
In the gdb code, the workaround only kicks in if *all* p_paddr from all
sections are zero, while your patch will kick in if a single section's
p_paddr is zero. The gdb solution seems safer to me.
ARM ELF compliant linker _must_ produce ELF with p_paddr = 0.
It seems like GNU ld (which probably uses these workarounds from BFD)
equals p_paddr to p_vaddr, so that the problem is masked, and OpenOCD
is using p_paddr.
Once you stumble upon ELF linked with some ARM ELF compliant liker,
OpenOCD will go wrong, while GDB will do fine by using the upper
mentioned procedure.
My opinion is that we currently have *broken* OpenOCD load_image
behavior (works with GNU ld, though), and that we can not make it any
worst with this patch.
Yes, we can: loading code at 0 may fail.
I also opened the question - is there a valid ELF that has p_paddr 0x0
and p_vaddr != 0. Obviously, regarding the upper mentioned code from
BFD, production of such ELF is not possible with GNU ld, because it
will keep p_paddr_valid flag at FALSE and equalize p_paddr to p_vaddr
at some point...
Address 0 is a valid starting address - I know systems with RAM or FLASH
at 0, so code with p_paddr==0 for one section is a valid case.
I have no objection against implementing the gdb workaround (checking if
*all* sections are zero)
cu
Michael
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Request for review: driver for Keil ULINK
On Tuesday 21 June 2011 19:11:17 Christopher Harvey wrote: Hi Martin, I've got a ulink at home with an MCB board (I forgot the exact number), so this is exciting news for me. I've been wanting to lean the internals of OCD and Jtag for a while, could anybody suggest some technical jtag/gdb/arm documents? I am also curious, how did you figure out the format of the data in the packets you're sending to the Ulink? thanks, -Chris Hi Chris, sorry, I forgot to mention a few things in my last mail: the ULINK adapter includes a Cypress EZ-USB microcontroller which has volatile code memory. The host application needs to download the firmware via USB control transfers each time the ULINK is first connected to the host. This driver does not use the same protocol as Keil's proprietary software, instead it uses my custom firmware (see 0002-Add-OpenULINK-firmware.patch). This firmware is compiled with SDCC and downloaded as part of the OpenOCD adapter init function. Once the ULINK is disconnected, the EZ-USB memory contents are lost and the firmware needs to be downloaded again the next time the ULINK is used. Therefore, backwards compatibility with Keil software is a non-issue - to use the adapter with uVision again, it just needs to be disconnected and re- connected. Also, this only works for the original Keil ULINK. Newer variants (ULINK2, ULINK-ME, ULINKpro are based on completely different hardware and need extra work to be usable with OpenOCD). Best regards, Martin ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
