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 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 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 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 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 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
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=TrackerItemEdit&tracker_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 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 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 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
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 7:35 PM, Michael Schwingen
wrote:
> 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.
Hi Michael,
yes, you got the point. BFD seems to be allowing one_and_only_one
p_paddr to be zero for loadable segments.
Here is some posts on this :
http://lists.gnu.org/archive/html/bug-gnu-utils/2002-02/msg00098.html
and
http://www.opensource.apple.com/source/binutils/binutils-36/src/bfd/elf.c
>> 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 mentioned this as a special question, I agree on this. If virtual
address is != 0, that means you linked for this address. Normally, you
would expect GDB to load binary to it's execution address.
If you do not want to do this (i.e. you have pic code and want to run
binaries from addresses for which they are not linked) then you know
exactly what you are doing and you are providing load address
explicitly to load_image command as an argument...
I agree on this, things might break.
>> 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)
Yes,
I think that would be the most correct way.
BR,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
