Re: [Openocd-development] jtag_add_scan_check Assertion Error
On Thu, Dec 22, 2011 at 1:21 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: Commenting out this assert everything seems to be OK. Indeed: http://openocd.zylin.com/297 Great, thanks Øyvind for the fix. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] jtag_add_scan_check Assertion Error
Hi all, with new git repo clone of OpenOCD I have been hitting this assert during the scan chain init : openocd: core.c:421: jtag_add_scan_check: Assertion `(field-check_value == ((void *)0)) || (field-in_value != ((void *)0))' failed. Commenting out this assert everything seems to be OK. I am using libftdi-0.19, and have seen same issue on both ARM946 and MIPS targets. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jtag_add_scan_check Assertion Error
On Wed, Dec 21, 2011 at 3:54 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
Please run this in gdb and do a bt(backtrace).
Seems to be working fine, at least OpenOCD does not break.
I have in the end of the listing
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
but I guess not related to this problem.
I can see that this was recent commit :
[ddraskovic@lardos:/home/ddraskovic/openocd]git show a30a4f0f
commit a30a4f0fc76b72936a6557e08d6b55b3a46eaafd
Author: Øyvind Harboe oyvind.har...@zylin.com
Date: Tue Dec 13 23:44:34 2011 +0100
jtag: make caller always allocate buffer
simplifies the API and there is only one remaining user at this point.
Is the implementation busted where the check does not actually happen
now?
Change-Id: I776a43766f5576a08df320f6fe41a2750d101bde
Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com
Reviewed-on: http://openocd.zylin.com/264
Tested-by: jenkins
Reviewed-by: Spencer Oliver s...@spen-soft.co.uk
diff --git a/src/jtag/core.c b/src/jtag/core.c
index 3090ddd..529e9bc 100644
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -417,12 +417,8 @@ static void jtag_add_scan_check(struct jtag_tap
*active, void (*jtag_add_scan)(s
for (int i = 0; i in_num_fields; i++)
{
struct scan_field *field = in_fields[i];
- field-allocated = 0;
- field-modified = 0;
- if (field-check_value || field-in_value)
- continue;
- interface_jtag_add_scan_check_alloc(field);
- field-modified = 1;
+ /* caller must provide in_buffer if needed for callback */
+ assert((field-check_value == NULL) || (field-in_value != NULL));
}
Seems to be introducing a bit of regression... Some unchanged files remain ?
BR,
Drasko
On Wed, Dec 21, 2011 at 3:52 PM, Drasko DRASKOVIC
drasko.drasko...@gmail.com wrote:
Hi all,
with new git repo clone of OpenOCD I have been hitting this assert
during the scan chain init :
openocd: core.c:421: jtag_add_scan_check: Assertion
`(field-check_value == ((void *)0)) || (field-in_value != ((void
*)0))' failed.
Commenting out this assert everything seems to be OK.
I am using libftdi-0.19, and have seen same issue on both ARM946 and
MIPS targets.
BR,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
--
Øyvind Harboe - Can Zylin Consulting help on your project?
US toll free 1-866-980-3434
http://www.zylin.com/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Show of hands for/against gerrit
+1 Combination git/gerrit seems to become more and more adapted by the professional companies, as it improves workflow. Git patches end up in gerrit base until verified by integrator and submitted to the trunk, or returned to the developer for correction. Gerrit seems to handle this (both directions) very nicely, and makes very powerful tool when used with git in combination. BR, Drasko On Fri, Oct 7, 2011 at 11:02 PM, Austin, Alex alex.aus...@spectrumdsi.com wrote: +2 Reviewed, +1 Verified... :) Having used Gerrit a little bit, where I work, it seems to enforce a workflow that this mailing list already uses. Any submitted patch needs to go through the review process before it is accepted into Trunk. If a patch needs work, a second version can be submitted with the same Change-Id, and the history of reviews for both patches will be attached together, and only the final revision will be accepted into trunk. My only issue is, I wonder where it would be hosted? Can SourceForge do that? What about appspot.com (AppEngine)? - Alex -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of Øyvind Harboe Sent: Thursday, October 06, 2011 4:02 PM To: openocd-development@lists.berlios.de Subject: [Openocd-development] Show of hands for/against gerrit I find gerrit intriguing as a way of managing patches. Can I have a show of hands of contributors for/against/don't care/don't know? -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Fwd: [OpenOCD][PULL Request][MIPS32] CP0 coprocessor manipulation and cache synchronization routines
Hi Øyvind, do you have any update on this pull request ? Maybe some other maintainer can integrate it ? Sorry I am nagging, but you asked yourself ;). BR, Drasko -- Forwarded message -- From: Drasko DRASKOVIC drasko.drasko...@gmail.com Date: Thu, Jul 7, 2011 at 7:27 PM Subject: [OpenOCD][PULL Request][MIPS32] CP0 coprocessor manipulation and cache synchronization routines To: Openocd-Dev openocd-development@lists.berlios.de Hi all, I am happy to present you several exciting enhancements to the MIPS32 target. Most notably : 1) Implemented mips32_cp0_read() and mips32_cp0_write() routines that can affect CP0 copro regs. 2) Implemented command interfaces for these commands, so that they can be called from Telnet interface 3) Implemented cache synchronization, so that we can now support soft breaks on cached regions. Linux can be debugged fine now. All this has been discussed before on ML. I have split all in logically independent commits, so that it can be more easy integrated into the master (I tested each commit independently, and overall version). In the end, I rebased to souceforge's master, so all you have to do is to pull the changes from my github branch. BR, Drasko The following changes since commit ac43d7a69fca52df1ad287b51c44013653ad2f61: Drasko DRASKOVIC (1): mips_m4k and arm7_9 : Fix soft bkpt endianess for 16-bit instructions are available in the git repository at: git://github.com/drasko/openocd.git master Drasko DRASKOVIC (4): mips32: Removed Unnecessary JTAG Queue Flush mips_m4k: common_magic should be unsigned mips32: Added CP0 coprocessor R/W routines mips32: Sync Caches to Make Instr Writes Effective src/target/mips32.c | 106 ++ src/target/mips32.h | 117 --- src/target/mips32_pracc.c | 342 +++-- src/target/mips32_pracc.h | 41 +- src/target/mips_m4k.c | 108 ++- src/target/mips_m4k.h | 7 +- 6 files changed, 679 insertions(+), 42 deletions(-) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: [OpenOCD][PULL Request][MIPS32] CP0 coprocessor manipulation and cache synchronization routines
On Fri, Aug 12, 2011 at 11:29 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: Near as I can tell it's merged. if you check out the tip of your branch locally, then do a git rebase origin/master = do you see any residual commits? I checked and saw no residual commits - it seems to be perfect. Thanks a lot ! BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: [OpenOCD][PULL Request][MIPS32] Fixed single byte memory write
On Fri, Aug 12, 2011 at 11:31 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: It's merged already. Nice :). Thanks ! BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Please welcome Andreas Fritiofson as a new OpenOCD maintainer!
On Fri, Aug 12, 2011 at 12:08 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: Please give Andreas Fritiofson a warm welcome as a new OpenOCD maintainer! Very nice news ! Andreas has indeed given great contribution to the project and shown outstanding skills and knowledge, and also has been there to kindly help. Congratulations ! BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] rebase vs. merge
On Wed, Aug 10, 2011 at 6:53 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: I am genuinely interested in hearing the pros and cons of rebasing vs. merging pull requests. rebasing yields a nice linear history, which I like. Perhaps I'm just old fashioned and used to it from Subversion days... Hi Øyvind, as I understand, merging would merge in all ones personal commits to a personal git tree in a OpenOCD log history once it is is merged on the master branch. Rebase will leave just one commit on the top of the master. I am opting for the rebase - why do we need many personal commit logs in the official OpenOCD tree. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] rebase vs. merge
On Wed, Aug 10, 2011 at 11:25 AM, Tormod Volden lists.tor...@gmail.com wrote: On Wed, Aug 10, 2011 at 10:09 AM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: On Wed, Aug 10, 2011 at 6:53 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: I am genuinely interested in hearing the pros and cons of rebasing vs. merging pull requests. rebasing yields a nice linear history, which I like. Perhaps I'm just old fashioned and used to it from Subversion days... Hi Øyvind, as I understand, merging would merge in all ones personal commits to a personal git tree in a OpenOCD log history once it is is merged on the master branch. Rebase will leave just one commit on the top of the master. No, I think you are talking about squashing all your new commits into one commit (which /can/ be done during a rebase). Rebasing itself just reorders all commits so that your added commits are nicely on top of the latest head, whereas a merge would possibly have your commits spread down the git history between other commits. Yes, I was thinking about this... I am opting for the rebase - why do we need many personal commit logs in the official OpenOCD tree. If you are correcting one of your commits in a second commit (both not applied to master yet) then squashing these together make sense before sending your pull requests. If your work consists of many small, relatively independent (builds and runs at each step) then they should be kept separately, for the sake of later review and bisecting. I agree. What I'd like to avoid is this situation : you do development on your independent branch, making many temporary commits which leave temporary logs. These temporary logs should not be seen in the official master's history, but only one commit/merge done by the official maintainer. I think that merging a branch would show all your temporary steps arriving to the final result... BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Fwd: [OpenOCD][PULL Request][MIPS32] CP0 coprocessor manipulation and cache synchronization routines
Hi all, as per Øyvind's request I am re-sending this outstanding pull request. BR, Drasko -- Forwarded message -- From: Drasko DRASKOVIC drasko.drasko...@gmail.com Date: Thu, Jul 7, 2011 at 7:27 PM Subject: [OpenOCD][PULL Request][MIPS32] CP0 coprocessor manipulation and cache synchronization routines To: Openocd-Dev openocd-development@lists.berlios.de Hi all, I am happy to present you several exciting enhancements to the MIPS32 target. Most notably : 1) Implemented mips32_cp0_read() and mips32_cp0_write() routines that can affect CP0 copro regs. 2) Implemented command interfaces for these commands, so that they can be called from Telnet interface 3) Implemented cache synchronization, so that we can now support soft breaks on cached regions. Linux can be debugged fine now. All this has been discussed before on ML. I have split all in logically independent commits, so that it can be more easy integrated into the master (I tested each commit independently, and overall version). In the end, I rebased to souceforge's master, so all you have to do is to pull the changes from my github branch. BR, Drasko The following changes since commit ac43d7a69fca52df1ad287b51c44013653ad2f61: Drasko DRASKOVIC (1): mips_m4k and arm7_9 : Fix soft bkpt endianess for 16-bit instructions are available in the git repository at: git://github.com/drasko/openocd.git master Drasko DRASKOVIC (4): mips32: Removed Unnecessary JTAG Queue Flush mips_m4k: common_magic should be unsigned mips32: Added CP0 coprocessor R/W routines mips32: Sync Caches to Make Instr Writes Effective src/target/mips32.c | 106 ++ src/target/mips32.h | 117 --- src/target/mips32_pracc.c | 342 +++-- src/target/mips32_pracc.h | 41 +- src/target/mips_m4k.c | 108 ++- src/target/mips_m4k.h | 7 +- 6 files changed, 679 insertions(+), 42 deletions(-) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Fwd: [OpenOCD][PULL Request][MIPS32] Fixed single byte memory write
Hi all, another outstanding pull request, that I made after previously introduced MIPS CP0 manipulation routines (it is independent, though and not related). This is actually a bugfix, not an enhancement. BR, Drasko -- Forwarded message -- From: Drasko DRASKOVIC drasko.drasko...@gmail.com Date: Tue, Jul 26, 2011 at 11:59 AM Subject: [OpenOCD][PULL Request][MIPS32] Fixed single byte memory write To: Openocd-Dev openocd-development@lists.berlios.de The following changes since commit 2cdb7e8dfb0ce818377db2d30d179423c6cc: Drasko DRASKOVIC (1): mips32: Sync Caches to Make Instr Writes Effective are available in the git repository at: git://github.com/drasko/openocd.git master Drasko DRASKOVIC (1): mips32 : Fixed memory byte access src/target/mips_m4k.c | 51 ++-- 1 files changed, 28 insertions(+), 23 deletions(-) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Mon, Jul 11, 2011 at 1:50 PM, Mahr, Stefan stefan.m...@sphairon.com wrote: Yes, if BE target shifts out an 32 bit value from address 0, it will begin with bit0:7, that is byte address 0x03 at targets memory. And host will do the same. When it shifts out 32-bit value , it will put contents of it's address 0x3 to output buffer[0] and send this first. I am talking about BE host, off course. LE host will put contents of it's 0x0 address to buffer[0] and send this out first. Yes, that's the way buf_get_u32 and buf_set_u32 works. OK, I think that things are clear now, and as I see it patching all the functions in PrAcc as you suggested seem to be realistic fix... BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
BTW, Stefan and all others, thank you very much for this long discussion and for the effort on explaining things. I think it was very useful. BR, Drasko On Tue, Aug 9, 2011 at 11:20 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: On Mon, Jul 11, 2011 at 1:50 PM, Mahr, Stefan stefan.m...@sphairon.com wrote: Yes, if BE target shifts out an 32 bit value from address 0, it will begin with bit0:7, that is byte address 0x03 at targets memory. And host will do the same. When it shifts out 32-bit value , it will put contents of it's address 0x3 to output buffer[0] and send this first. I am talking about BE host, off course. LE host will put contents of it's 0x0 address to buffer[0] and send this out first. Yes, that's the way buf_get_u32 and buf_set_u32 works. OK, I think that things are clear now, and as I see it patching all the functions in PrAcc as you suggested seem to be realistic fix... BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Do nag
On Tue, Aug 9, 2011 at 11:23 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: If there is a patch or pull request that has fallen between the cracks, then you as the patch submitter must nag. The maintainers do not mind! Especially for some of the pull requests and patches where there has been long and fruitful discussions maintainers may have no clue which patch that should go in at this point... A fresh reminder post is then most welcome! Hi Øyvind, I totally agree. I am trying to re-send my pull requests replying to the thread of discussion, so thet reference can be kept. I hope that this is OK. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Do nag
On Tue, Aug 9, 2011 at 11:32 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: Hi Øyvind, I totally agree. I am trying to re-send my pull requests replying to the thread of discussion, so thet reference can be kept. I hope that this is OK. I think for some of those discussions you have to repost the pull request and/or the correct version of the patch. This is what I am trying to do. I am not sure that I am correctly rebased, but patches should be independent, so you can rebase them upon pull... Otherwise I can do it, but every time I have to completely rewrite my github source tree ( I have not found a way to rebase fetch from sourceforge to github). There are so many back and forth's. maintainers are not going to be able to dive into the discussions and extract the good patches or read up on the thread. I understand. I will try to make it as easy as possible for integration. If there is any problems or question, please signal. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD][PULL Request][MIPS32] Fixed single byte memory write
On Sat, Jul 30, 2011 at 4:26 AM, Mahr, Stefan stefan.m...@sphairon.com wrote: Hi Drasko. Drasko DRASKOVIC (1): mips32 : Fixed memory byte access Your patch fixes the broken byte access, but not the big endian host issue. Hi Stefan, this is true. But my intention was not to go in changing all these functions, especially since you volunteered to do it yourself :)). Besides, I have an impression that you know what you are doing. I was just trying to remove obviously blocking and annoying bug quickly and not introducing any regression. Since both problems are tied together, I would prefer a more common solution. Solution is more common, but the commit history is not clearer. You are fixing several bugs in one patch... Attached patch hopefully fixes both issues. It should also fix alignment warning that Øyvind had reported. Unfortunately I can't test it for the time being. Looks OK to me. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] GDB always executes code on the first declared target in a multi-target configuration
Hi all, I have a multicore SoC, and I use target create command to create several targets, one for each CPU. Main CPU is mentioned first. When I want to load and execute Linux kernel on secondary CPU, I use mon targets second to switch to the second target from within GDB, and then I do load to load kernel to SDRAM of my remote target. At this moment I have OpenOCD complaining about work area, although I had defined working area for the secondary (but not primary) CPU. That means that code load is executed by the primary CPU, and not secondary as I thought, because I can see tha OpenOCD keeps star on second target, marking this one as active. Also, once the code is loaded it is executed on the primary CPU. How come ? And why the OpenOCD is marking that second CPU is the active target ? How to force GDB to use second target in a multi-target configuration, and not always the first declared by the target create command ? Best regards, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] GDB always executes code on the first declared target in a multi-target configuration
On Thu, Jul 28, 2011 at 5:16 PM, Spencer Oliver s...@spen-soft.co.uk wrote: It has been a while since i tested openocd with multiple targets - over a year at a guess. Hard to give an answer, but if i get a chance i will run some test tomorrow. Hi Spen, thanks. I looked quickly at gdb_new_connection() and it seems that Target info is taken from gdb_service-target, which is initialized as : struct gdb_service *gdb_service = connection-service-priv; I am wondering if changes of active target by OpenOCD command targets xy affect this information in GDB... I.e. is GDB aware which target is currently active ? I also noted that switching to another target in Telnet interface before GDB connection does not change the things - GDB always connects to the first created target in cfg script, not to the one that is currently active ! BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [OpenOCD][PULL Request][MIPS32] Fixed single byte memory write
The following changes since commit 2cdb7e8dfb0ce818377db2d30d179423c6cc: Drasko DRASKOVIC (1): mips32: Sync Caches to Make Instr Writes Effective are available in the git repository at: git://github.com/drasko/openocd.git master Drasko DRASKOVIC (1): mips32 : Fixed memory byte access src/target/mips_m4k.c | 51 ++-- 1 files changed, 28 insertions(+), 23 deletions(-) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [OpenOCD][PATCH][MIPS32] Byte memory access broken
Hi all,
I have noticed that accessing (more precise: writing) memory
byte-by-byte on MIPS32 targets is currently borken.
Temporary array allocated for endianess swap replaces the contenst of
the buffer. However, this temporary array is set-up only for hword and
word accesses.
This, in the case of byte access, it just (unnecessarily) overwrites
buffer with random (uninitialized) value.
As a fix, I propose patch attached.
I will wait for comments and send PULL request from my github MIPS
maintained branch, as I usually do.
BR,
Drasko
From b61cc1ec5d5420436fc933146d9fd4a91f79db15 Mon Sep 17 00:00:00 2001
From: Drasko DRASKOVIC drasko.drasko...@gmail.com
Date: Mon, 25 Jul 2011 14:23:35 +0200
Subject: [PATCH] mips32 : Fixed memory byte access
Function mips_m4k_write_memory() does endianess byte swap,
but this procedure break one byte access (temporary array
overwrites content in buffer).
As a fix, this endianess swap and buffer affecting
is preformed only on hword and word accesses (not on byte access).
---
src/target/mips_m4k.c | 51 ++--
1 files changed, 28 insertions(+), 23 deletions(-)
diff --git a/src/target/mips_m4k.c b/src/target/mips_m4k.c
index 350ed51..e4ab044 100644
--- a/src/target/mips_m4k.c
+++ b/src/target/mips_m4k.c
@@ -923,33 +923,38 @@ static int mips_m4k_write_memory(struct target *target, uint32_t address,
if (((size == 4) (address 0x3u)) || ((size == 2) (address 0x1u)))
return ERROR_TARGET_UNALIGNED_ACCESS;
- /* mips32_..._write_mem with size 4/2 requires uint32_t/uint16_t in host */
- /* endianness, but byte array represents target endianness */
- uint8_t * t = NULL;
- t = malloc(count * sizeof(uint32_t));
- if (t == NULL)
+ /** correct endianess if we have word or hword access */
+ uint8_t *t = NULL;
+ if (size 1)
{
- LOG_ERROR(Out of memory);
- return ERROR_FAIL;
- }
+ /* mips32_..._write_mem with size 4/2 requires uint32_t/uint16_t in host */
+ /* endianness, but byte array represents target endianness */
+ t = malloc(count * sizeof(uint32_t));
+ if (t == NULL)
+ {
+ LOG_ERROR(Out of memory);
+ return ERROR_FAIL;
+ }
- uint32_t i, t32;
- uint16_t t16;
- for(i = 0; i (count*size); i += size)
- {
- switch(size)
+ uint32_t i, t32;
+ uint16_t t16;
+ for(i = 0; i (count*size); i += size)
{
- case 4:
- t32 = target_buffer_get_u32(target,buffer[i]);
- h_u32_to_le(t[i], t32);
- break;
- case 2:
- t16 = target_buffer_get_u16(target,buffer[i]);
- h_u16_to_le(t[i], t16);
- break;
+ switch(size)
+ {
+ case 4:
+t32 = target_buffer_get_u32(target,buffer[i]);
+h_u32_to_le(t[i], t32);
+break;
+ case 2:
+t16 = target_buffer_get_u16(target,buffer[i]);
+h_u16_to_le(t[i], t16);
+break;
+ }
}
+
+ buffer = t;
}
- buffer = t;
/* if noDMA off, use DMAACC mode for memory write */
int retval;
--
1.7.6
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [OpenOCD]Pre-init slave CPU wake-up
Hi all, I have a following problem : I have a slave CPU which is under constant reset in a multicore SoC. This slave CPU is woken up by the write to certain register bu main CPU. Then reset from slave CPU is removed and it can be halted, written to, etc. My problem is that I created two targets in my OpenOCD config, but when I say halt or reset init in my script it tries to halt both targets - so it fails. Reset init is never done, so SDRAM is not set up. What would be the best place -the best event - to put there this slave reset register write ? I tried defining -event reset-start, reset-init and reset-assert to contain this reg write - no sucess. It seems like OpenOCD still tries to halt both targets before doing reset. So I inserted this reg write into -event halted. THis works but seems to be impractical - I'll have this regiter written on every halt, and I want to have it written only after SoC reset, but before first halt was issued (otherwise halt will fail, because slave CCPU will stay under reset until waken-up by main CPU)... BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Mon, Jul 11, 2011 at 12:31 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Mon, Jul 11, 2011 at 12:17 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: On Mon, Jul 11, 2011 at 7:31 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: Now a sequence of 8 bit words happens to be identical to little endian representation In what way ? 8 bits is 8 bits - one byte, bits 7:0. I do not see BE or LE representation here... Consider a series of words in memory where the width is greater than 8. Clearly a BE series has a different representation than a LE version. For a series of words that are 8 bits long, then the BE series and LE series are identical. Further, if you have 32 bits stored in a series of bytes in memory, then the memory layout is identical to the memory layout of little endian layout. Sorry Øyvind, I did not get at first that you meant on this - a byte array in the mem. Yes, I agree, it has LE order when memory is observed (which is one of the main arguments of the LE camp why LE is natural). BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Mon, Jul 11, 2011 at 11:53 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: I think there is a fundamental misunderstanding about JTAG and OpenOCD. Let me try to clarify: JTAG clocks in and out bits, not bytes, so the concept of big/small-endian does not enter the picture at the JTAG level. Sat that we have 0x12345678 at addr 0x0 on LE host. You will shift out byte 0x78 first, shifting out from LSB upwards. I.e. You will be starting with shifting out addr 0x0 on the host. Now, if the host is BE, you will again be shifting LSB first, but this time that means that you will be starting withs shifting out addr 0x3 (on the host) first. Am I correct so far ? At what addr will EJTAG on the other side write this byte ? At addr 0x0, or addr 0x03 - this is the main question. If it is LE, Byte0, as they say in manual, will be put to 0x0, and if it is BE MIPS, it will be put always to 0x3. So, the first 8 bits that MIPS EJTAG shifts in, which will be noted Byte0 in their terminology and represent bits 7:0, will be put to either addr 0x0 or 0x3 - depending on endianess of the MIPS target. That would say to me that MIPS EJTAG is actually doing following : 1) Takes the value of Byte0, in this case 0x78 2) Cast it to uint32_t, getting 0x0078 3) Stores the word in memory - and if it is BE MIPS, 0x78 byte will end-up on addr 0x3. This way, EJTAG is endianess-agnostic - it really do not care about your host endianess, as long as you are are sending it LSB fist. It will arrange then to store the Byte0 at appropriate address once it gathers bits 7:0. This is what I think. Now, when EJTAG is sending back data to the host, it will also send LSB first, i.e. it's Byte0. But in the case of BE, this Byte0 lives on the address 0x3, so it will start with sending addr 0x3. When receives data as a byte array, host can not give any conclusions about target endianess. It just know that it gets LSB first, and we have to use buf_get_u32() to make some meaning on the host of a byte array value that came. This way target endianess is completely unimportant to the OpenOCD, and we can not even know it by observing bytes that come we will always see LSB coming first. Does this all makes sense for you ? BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Mon, Jul 11, 2011 at 12:52 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Mon, Jul 11, 2011 at 12:45 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: On Mon, Jul 11, 2011 at 11:53 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: I think there is a fundamental misunderstanding about JTAG and OpenOCD. Let me try to clarify: JTAG clocks in and out bits, not bytes, so the concept of big/small-endian does not enter the picture at the JTAG level. Sat that we have 0x12345678 at addr 0x0 on LE host. You will shift out byte 0x78 first, shifting out from LSB upwards. You're on the wrong track here. Shifting out happens with *bits*. When I said LSB I meant Least Significant *Bit*, not *Byte*. So the situation is: - you have a host word. 8, 16, 32 or 64 bit wide. - that word must be copied over to an array of bytes to be shifted out. At this point any memory of host representation is gone. - the jtag layer now shifts out the bits, starting with bit 0 in byte 0. What is byte 0 for you ? I'd say, on a BE host it lives at addr 0x3. On LE host it lives at addr 0x0. When you start shifting out LSB (bit) from the BE host, will you start shifting out contents of address 0x3, or the address 0x0 ? In my opinion, it will be content of the addr 0x3 that will be shifted out first (as it holds bits 0:7 for on the BE host). - the target receives the bits in order completely oblivious to how you put them on the wire. Yes - it receives LSB (bit) first. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Mon, Jul 11, 2011 at 1:30 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Mon, Jul 11, 2011 at 1:10 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: On Mon, Jul 11, 2011 at 12:52 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Mon, Jul 11, 2011 at 12:45 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: On Mon, Jul 11, 2011 at 11:53 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: I think there is a fundamental misunderstanding about JTAG and OpenOCD. Let me try to clarify: JTAG clocks in and out bits, not bytes, so the concept of big/small-endian does not enter the picture at the JTAG level. Sat that we have 0x12345678 at addr 0x0 on LE host. You will shift out byte 0x78 first, shifting out from LSB upwards. You're on the wrong track here. Shifting out happens with *bits*. When I said LSB I meant Least Significant *Bit*, not *Byte*. So the situation is: - you have a host word. 8, 16, 32 or 64 bit wide. - that word must be copied over to an array of bytes to be shifted out. At this point any memory of host representation is gone. - the jtag layer now shifts out the bits, starting with bit 0 in byte 0. What is byte 0 for you ? An array of bytes as an unambiguous representation in memory and C programming model. When I say byte 0 of an array of bytes, there is no question about what that is. This is not arguable. What I am asking you here is how do you create this array of bytes you want to shift out ? I'd say - on BE host, when you want to shift out word you put addr 0x3 to be shifted out first, and then in the end addr 0x0, because LSB of your value lives on addr 0x3. Here is how you prepare your shift-out buffer of 8-bit long elements : buffer[0] = (contents_of_the_host_addr 0x3); buffer[1] = (contents_of_the_host_addr 0x2); buffer[2] = (contents_of_the_host_addr 0x1); buffer[3] = (contents_of_the_host_addr 0x0); And then you shift out buffer[0] first, then buffer[1], etc. Which would in the end say - when you want to shift 32-bit word from the BE host, it will be contents addr 0x3 that will be going out on the wire first, this is all I am trying to say. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Mon, Jul 11, 2011 at 1:41 PM, Mahr, Stefan stefan.m...@sphairon.com wrote: When you start shifting out LSB (bit) from the BE host, will you start shifting out contents of address 0x3, or the address 0x0 ? In my opinion, it will be content of the addr 0x3 that will be shifted out first (as it holds bits 0:7 for on the BE host). Yes, if BE target shifts out an 32 bit value from address 0, it will begin with bit0:7, that is byte address 0x03 at targets memory. And host will do the same. When it shifts out 32-bit value , it will put contents of it's address 0x3 to output buffer[0] and send this first. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Mon, Jul 11, 2011 at 1:43 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: Yes, if BE target shifts out an 32 bit value from address 0, it will begin with bit0:7, that is byte address 0x03 at targets memory. And host will do the same. When it shifts out 32-bit value , it will put contents of it's address 0x3 to output buffer[0] and send this first. I am talking about BE host, off course. LE host will put contents of it's 0x0 address to buffer[0] and send this out first. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Sat, Jul 9, 2011 at 10:44 AM, Mahr, Stefan stefan.m...@sphairon.com wrote: How do they convert then, when they do not know from which endianes to convert from ? Conversion is done from byte array of jtag chain. How ? buf_get_u32 does conversion from uint8* array example: mips_ejtag_get_impcode (mips_ejtag.c) field.in_value is filled by jtag_add_dr_scan with 4 times uint8. buf_get_u32 converts byte array to host endian uint32 How ? It does not convert anything. It just takes the data and puts it into array, in the order that it comes. No, you do *arithmetical* operations on host, so it is ensured that result is always in host endianness. buf_get_u32: return (((uint32_t)buffer[3]) 24) | (((uint32_t)buffer[2]) 16) | (((uint32_t)buffer[1]) 8) | (((uint32_t)buffer[0]) 0); I do not get this function at all... What I see is that it is presumed that host executing this code must be in the same endianess as the target who filled this buffer. Otherwise bytes get flipped. Here is an experiment : Let's imagine that target is BE. Then it will put word 0x12345678 read from the it's (target's) mem like this : buffer[0] = 0x12 buffer [1] = 0x34 buffer[2] = 0x56 buffer[3] = 0x78 Because BE keeps MSB on lower addr. On the LE host, function buf_get_u32() will shift 0x78 to addr 0x3, 0x56 to addr 0x2, etc and you will get : | 78 | 56 | 34 | 12 | --- value (hex) | 3 | 2 | 1 | 0 | --- addr i.e, you will have 0x78453412 as a return on a LE host, which is, ay you see, flipped value. It is because you kept MSB part put by the target in beuffer[0] on your host's addr 0x0, i.e. you did not shift it you addr 0x3. On LE arch MSB is kept on higher addresses. Similar will happen if you have LE target and BE host. That's why I do not think that this function was ever meant to do any conversion to host's endianess, as you say. What I thing is that it is a function that *must* be used locally on the host, and *only* on the data filled by the host, because then we are guaranteed that the person who fills the buffer[] is the same who reads it, i.e. endianess is same for the reader and for the writer. Do you agree with me on this, or am I missing something ? What is funny however, is that I have BE target and LE host, and MIPS code seems to be working fine... Which would say that EJTAG somehow speaks LE with my host. Crazy thing. The endianness of MIPS EJTAG tap seems to have always the same endianness, no matter of MIPS CPU memory endianness. What makes you think so ? Because openocd works in all combinations of BE and LE host and target. (If you revert commit 2482244b0788c007dd789c21a4416379c229ea5c.) So yes, it's just a guess. Which might mean that all commands are sent to EJTAG in appropriate target format in which CPU expects them (be it BE or LE, depends in which mode it runs). I can't find code that swaps target endianness in mips32_pracc.c or mips_ejtag.c Could this be the explanation: http://downloads.buffalo.nas-central.org/LS2_MIPSel/DevelopmentTools/JTAG/MD00047-2B-EJTAG-SPC-03.10.pdf Page 97: Byte 0 refers to bits 7:0, byte 1 refers to bits 15:8, byte 2 refers to bits 23:16, and byte 3 refers to bits 31:24, independent of endianess. This is _always_ the case in _all_ architectures. But, as you see, this Byte0 is put to lower addresses for LE and to higher for BE. This is always the case. Byte 0 refers to bits 7:0, byte 1 refers to bits 15:8, byte 2 refers to bits 23:16, and byte 3 refers to bits 31:24, independent of endianess. My guess is, if you read out a 32bit value, target endianness doesn't matter. This is the only sane solution I can think of. It would say that EJTAG is a bi-endian machine that can read both BE and LE if we feed it fixed instr. size. Do you know some examples of architectures (bi-endian) like this ? How can it exactly guess the endianess of the program and adopt itself appropriately ? If a 8bit value is read out, you get byte0 for address 0 in LE mode and byte3 at address 0 in BE mode. OK, but this does not change anything for any architecture in the world, as I said - this chapter is just the MIPS terminology, theirs notation, nothing significant there, IMHO. As I said, for value 0x12345678, on BE byte0 is bits 7..0 = 0x78. Reading addr 0x0 you will get MSB on BE, as it stores MSB on lower addr, so you will get 0x12, which is in MIPS (or any other notation) byte3 of the 4-byte value, as it holds MSB, i.e. bits 31..28. As I said, I do not see nothing special there, but it might be that I am missing something you want to point out. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Fri, Jul 8, 2011 at 11:47 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Fri, Jul 8, 2011 at 11:43 AM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: On Thu, Jul 7, 2011 at 11:58 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: Note that this problem has cropped up many places over the OpenOCD code. I'd like to get rid of it once and for all I absolutely intend to fix it for MIPS, but I'd like a good long term solution. With jtag queue callbacks, a user data pointer to the callback is cast to a void pointer, then cast back to e.g. uint32_t *. Casting to/from void * does not yield a warning(should not anyway, right?), Why shouldn't it ? I mean, you can have unaligned acces by casting void* to unaligned addr to uint32* and then reference, right ? Such warnings would be hopelessly noisy. A callback generally takes a pointer to *something* and then inside the callback you cast back the pointer to whatever you *know* you passed in. Of course C++ the whole casting business is much more advanced than i C. From my point of view casting uint8_t* to uint32* is dangerous as casting void* to uint32_t*. Isee no difference, as void* can point to unaligned addr. There is no difference in danger, but what the compiler is telling you is that if you do need to have a generic pointer, then use void *, not uint8_t *. OK, I am starting to get this... Thanks Øyvind. But looking from to the code, I see no explicit casting uint8_t* to uint32_t in mips_pracc code. Where did you exactly run into compiler warning ? BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Thu, Jul 7, 2011 at 11:52 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: 011/7/7 Mahr, Stefan stefan.m...@sphairon.com: Øyvind Harboe wrote: It is not obvious at all from the context that there is an alignment guarantee. If alignment is not guaranteed, casting from uint32 to void would cause problems too, wouldn't it? Why? http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob;f=src/target/mips32_pracc.c;h=af60d321638652aad0a52a573add2aceacbfb7d9;hb=HEAD#l310 = this is strange, why cast to uint8_t ? return mips32_pracc_read_mem16(ejtag_info, addr, count, (uint8_t*)buf); There is no particular need to cast this into uint8_t* and this can be kept as a void*. Would that suppress the warnings ? BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Fri, Jul 8, 2011 at 12:14 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
There is no particular need to cast this into uint8_t* and this can be
kept as a void*. Would that suppress the warnings ?
It does look like this code is using uint8_t * in lieu of void *...
Why ? It is just an address of 1-byte placeholder to which you would
like to copy byte read from the memory.
All you have to do late is to copy values read into each memeber of
uint32_t array to each corresponding member of uint8_t array.
This loop :
for (i = 0; i count; i++)
{
buf[i] = param_out[i];
}
I see no problem of alignment there, as actually uint32_t will be
casted to uint8_t, which should be OK (while the other way around is
dangerous).
But even that can be avoided, as
retval = mips32_pracc_exec(ejtag_info, ARRAY_SIZE(code), code,
ARRAY_SIZE(param_in), param_in, count, param_out, 1);
will get you values in param_out[] array. This array is an array of
uint32_t values, I do not know for which reason...
Actually, copy from RAM address to our buffer is done in this loop :
/* loop */
MIPS32_BEQ(0,10,8),
/* beq 0, $10, end */
MIPS32_NOP,
MIPS32_LBU(8,0,9),
/* lw $8,0($9), Load t4 with the byte @mem[t1] */
MIPS32_SW(8,0,11),
/* sw $8,0($11) */
MIPS32_ADDI(10,10,NEG16(1)),
/* $10-- */
MIPS32_ADDI(9,9,1),
/* $9 += 1 */
MIPS32_ADDI(11,11,4),
/* $11 += 4 */
MIPS32_B(NEG16(8)),
/* b loop */
/* end */
Where $11 holds the adress of our buffer member (dst addr). Because we
said that our destination buffer is consisted of uint32_t, this
address is incremented by 4 in every pass:
MIPS32_ADDI(11,11,4),
/* $11 += 4 */
I think that using uint8_t array and using $11 += 1 in the loop should
do the same thing...
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Fri, Jul 8, 2011 at 12:10 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: OK, I am starting to get this... Thanks Øyvind. But looking from to the code, I see no explicit casting uint8_t* to uint32_t in mips_pracc code. Where did you exactly run into compiler warning ? git revert 2482244b0788c007dd789c2 I reverted this commit : commit e442054bf9acf70cb2b9b2ac297cba2b15df5642 Author: Drasko DRASKOVIC drasko.drasko...@gmail.com Date: Fri Jul 8 12:32:42 2011 +0200 Revert mips4k: fix big-endian hosts and host alignment problems This reverts commit 2482244b0788c007dd789c21a4416379c229ea5c. I still can not reproduce a problem - it buidls just fine. No warnings whatsoever. gcc version 4.3.2 (Debian 4.3.2-1.1) BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Fri, Jul 8, 2011 at 12:35 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Fri, Jul 8, 2011 at 12:31 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: On Fri, Jul 8, 2011 at 12:14 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: There is no particular need to cast this into uint8_t* and this can be kept as a void*. Would that suppress the warnings ? It does look like this code is using uint8_t * in lieu of void *... Why ? It is just an address of 1-byte placeholder to which you would like to copy byte read from the memory. It's not about what you do, it is about telling the compiler as much as possible about the types so that it can check for problems. I don't know the code too well to comment about which types should be used. Especially with big/small endian... I know this code, and I can change it. I just do not see any casting to unaligned access by visual inspection, and I can not reproduce the problem. So I do not know where to start changing - everything looks OK to me here. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Fri, Jul 8, 2011 at 12:42 PM, Øyvind Harboe oyvind.har...@zylin.com wrote:
I still can not reproduce a problem - it buidls just fine. No warnings
whatsoever.
libtool: compile: nios2-linux-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I.
-I/home/oyvind/workspace/zy1000/build/../openocd/src/target -I../..
-I/home/oyvind/workspace/zy1000/build/../openocd/src -I../../src
-DPKGDATADIR=\/opt/zy1000/share/openocd\
-DPKGLIBDIR=\/opt/zy1000/lib/openocd\ -O3 -g
-I/home/oyvind/nios2-linux/uClinux-dist/staging/usr/include
-I/opt/zy1000/include -Wall -Wstrict-prototypes -Wformat-security
-Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast
-Wcast-align -Wredundant-decls -Werror -MT mips_m4k.lo -MD -MP -MF
.deps/mips_m4k.Tpo -c
/home/oyvind/workspace/zy1000/build/../openocd/src/target/mips_m4k.c
-o mips_m4k.o
cc1: warnings being treated as errors
/home/oyvind/workspace/zy1000/build/../openocd/src/target/mips_m4k.c:
In function 'mips_m4k_read_memory':
/home/oyvind/workspace/zy1000/build/../openocd/src/target/mips_m4k.c:880:
warning: cast increases required alignment of target type
/home/oyvind/workspace/zy1000/build/../openocd/src/target/mips_m4k.c:884:
warning: cast increases required alignment of target type
/home/oyvind/workspace/zy1000/build/../openocd/src/target/mips_m4k.c:
In function 'mips_m4k_write_memory':
/home/oyvind/workspace/zy1000/build/../openocd/src/target/mips_m4k.c:933:
warning: cast increases required alignment of target type
/home/oyvind/workspace/zy1000/build/../openocd/src/target/mips_m4k.c:937:
warning: cast increases required alignment of target type
/home/oyvind/workspace/zy1000/build/../openocd/src/target/mips_m4k.c:
In function 'mips_m4k_bulk_write_memory':
/home/oyvind/workspace/zy1000/build/../openocd/src/target/mips_m4k.c:1077:
warning: cast increases required alignment of target type
OK, I was looking at mips32_pracc.c, but actually it is this in mips_m4k.c :
for(i = 0; i (count*size); i += size)
{
switch(size)
{
case 4:
t32 = *(uint32_t*)buffer[i];
target_buffer_set_u32(target,buffer[i], t32);
break;
case 2:
t16 = *(uint16_t*)buffer[i];
target_buffer_set_u16(target,buffer[i], t16);
break;
}
}
that casts void* buf to uint32_t*.
BR,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Fri, Jul 8, 2011 at 12:52 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: What puzzles me is that there is no warning on x86, even if I the -Wcast-align option is there This kind of explains why I never saw it... BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Wed, Jul 6, 2011 at 2:42 PM, Mahr, Stefan stefan.m...@sphairon.com wrote: mips32_pracc_read_mem and mips32_pracc_write_mem return values (buffer[i]) are already in host endianness, so le_to_h_u32 fails on big endian hosts. I already mentioned this in previous discussions. Hi Stefan, are you sure about this ? It seems to me that buffer[i] is directly filled by target, and I see no reason that it is in the host endianess... BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Fri, Jul 8, 2011 at 1:13 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: that casts void* buf to uint32_t*. Actually buffer is uint8_t *. The definition of target-type-read_memory is bad in that it uses uint8_t * instead of void *. Which is kinda the root of this mess. Well, this propagate through all the targets... BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
I am just wandering, would : t32 = *(uint32_t*)((void *)buffer[i]); quite the compiler ;) BR, Drasko On Fri, Jul 8, 2011 at 1:14 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: On Fri, Jul 8, 2011 at 1:13 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: that casts void* buf to uint32_t*. Actually buffer is uint8_t *. The definition of target-type-read_memory is bad in that it uses uint8_t * instead of void *. Which is kinda the root of this mess. Well, this propagate through all the targets... BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Fri, Jul 8, 2011 at 1:20 PM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Fri, Jul 8, 2011 at 1:17 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: I am just wandering, would : t32 = *(uint32_t*)((void *)buffer[i]); quite the compiler ;) Yes probably, but it would still crash on an architecture that doesn't support unaligned accesses. Yes, if there is a reason for crash. I am not sure that it is the case here... I am trying to investigate... BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Fri, Jul 8, 2011 at 1:19 PM, Andreas Fritiofson
andreas.fritiof...@gmail.com wrote:
I looked briefly at the memory read functions in mips32_dmaacc.c and
mips32_pracc.c and it looks like the type usage is a bit confused. The
difference between the *_read_mem{32,16,8} functions should only be what
kind of access is made *on the target*.
How do we determine that ?
I thought that it is kept in the size parameter, and
mips32_pracc_read_mem is doing exactly this :
int mips32_pracc_read_mem(struct mips_ejtag *ejtag_info, uint32_t
addr, int size, int count, void *buf)
{
switch (size)
{
case 1:
return mips32_pracc_read_mem8(ejtag_info, addr, count,
(uint8_t*)buf);
case 2:
return mips32_pracc_read_mem16(ejtag_info, addr, count,
(uint16_t*)buf);
case 4:
if (count == 1)
return mips32_pracc_read_u32(ejtag_info, addr,
(uint32_t*)buf);
else
return mips32_pracc_read_mem32(ejtag_info,
addr, count, (uint32_t*)buf);
}
return ERROR_OK;
}
Host data buffer type should be
identical, preferrably void*, with no alignment requirement, and count
should be in number of bytes.
Problem is not in the mips32_pracc.c, thought, but when you come back
to mips_m4k_read_memory(), in which buf is uint8_t*.
BR,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Fri, Jul 8, 2011 at 1:38 PM, Mahr, Stefan stefan.m...@sphairon.com wrote: are you sure about this ? It seems to me that buffer[i] is directly filled by target, and I see no reason that it is in the host endianess... Hi Drasko, Yes I'm sure. I tested it on my big endian host platform. I do not understand the code completely, but I think it's caused by the mips ejtag functions. Example: - mips_ejtag_drscan_32 uses uint32 for data Ok, I see no problem there... - buf_set_u32 and buf_get_u32 make sure that data is in host endianness Why ? Don't we want the data to be in target endianess ? BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Fri, Jul 8, 2011 at 1:54 PM, Mahr, Stefan stefan.m...@sphairon.com wrote: Problem is not in the mips32_pracc.c, thought, but when you come back to mips_m4k_read_memory(), in which buf is uint8_t*. That's why the solution could be to add swapping to _mem16, _mem32 etc. and alway return uint8*. I agree with you, but we should look for the best solution. We can always fall back to this brute force if we do not find anything better. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Fri, Jul 8, 2011 at 2:05 PM, Mahr, Stefan stefan.m...@sphairon.com wrote: Where are those functions defined and how do they know what the target endianness is? They doesn't know the target endianness, but host endianness. It sounds a little strange to do the swapping at this low level. You need swapping when reading and comparing debug registers or send code to MIPS CPU. Can you give the example of some of these comparisons in the source code ? You are referring to some comparisons in mips32_pracc.c ? BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Fri, Jul 8, 2011 at 3:08 PM, Andreas Fritiofson
andreas.fritiof...@gmail.com wrote:
On Fri, Jul 8, 2011 at 1:26 PM, Drasko DRASKOVIC
drasko.drasko...@gmail.com wrote:
On Fri, Jul 8, 2011 at 1:19 PM, Andreas Fritiofson
andreas.fritiof...@gmail.com wrote:
I looked briefly at the memory read functions in mips32_dmaacc.c and
mips32_pracc.c and it looks like the type usage is a bit confused. The
difference between the *_read_mem{32,16,8} functions should only be what
kind of access is made *on the target*.
How do we determine that ?
I thought that it is kept in the size parameter, and
mips32_pracc_read_mem is doing exactly this :
int mips32_pracc_read_mem(struct mips_ejtag *ejtag_info, uint32_t
addr, int size, int count, void *buf)
{
switch (size)
{
case 1:
return mips32_pracc_read_mem8(ejtag_info, addr,
count, (uint8_t*)buf);
case 2:
return mips32_pracc_read_mem16(ejtag_info, addr,
count, (uint16_t*)buf);
case 4:
if (count == 1)
return mips32_pracc_read_u32(ejtag_info,
addr, (uint32_t*)buf);
else
return mips32_pracc_read_mem32(ejtag_info,
addr, count, (uint32_t*)buf);
}
return ERROR_OK;
}
Host data buffer type should be
identical, preferrably void*, with no alignment requirement, and count
should be in number of bytes.
Problem is not in the mips32_pracc.c, thought, but when you come back
to mips_m4k_read_memory(), in which buf is uint8_t*.
But already here buf is cast to uint{8,16,32}_t* (from void* so no warning
but equally risky) which shouldn't be needed because all read_mem* functions
could accept a void* buffer and write the data to arbitrary alignment. Main
point is that the alignment requirement (buffer data type) on the host
should not be coupled to the access size used on the target.
I do not know all the OpenOCD internals, but I guess that size
represent data access size you are mentioning.
like, if count is 5 and size is 4 that would mean I want 5 ints.
If my presumption is true, then I agree with you, and looking at the
PrAcc code that we can safely use void for these buffer pointers.
They are just addresses where read data will be put.
However, data will be read (accessed) in the size - if it is 4 we
will use MIPS32_LW which loads word from memory, and if it is 2, we
will use MIPS32_LHU - load halfword unsigned.
So, from this point everything seems to be OK, except from this
unnecessary casting void* to uintX_t*.
Problem is however in mips_m4k_read_memory(), where you have explicit
casting t32 = *(uint32_t*)buffer[i];
And also the
data returned in the host buffer should be identical, regardless of which
target access size is chosen (this requirement probably gives the answer to
whether endian swapping should be done here or not). Does this make sense?
Yes, and it is (IMHO).
Of course you may not be able to do an access with size 2 or 4 to an
unaligned *target address* but that has nothing to do with host buffer
alignment.
If the memory functions only handle byte addressed generic memory blocks,
there are no endian issues (here). They pop up first when higher level code
tries to interpret the memory contents as multi-byte entities (instructions,
addresses, ...) in which case that code must be aware of the target
endianness. Again, I may be confused here.
I've got lost here...
BR,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Fri, Jul 8, 2011 at 4:10 PM, Mahr, Stefan stefan.m...@sphairon.com wrote:
- buf_set_u32 and buf_get_u32 make sure that data is in host endianness
Why ? Don't we want the data to be in target endianess ?
You need swapping when reading and comparing debug registers or send code
to MIPS CPU.
Can you give the example of some of these comparisons in the source
code ? You are referring to some comparisons in mips32_pracc.c ?
example:
mips_m4k.c: mips_m4k_poll
mips_ejtag_set_instr(ejtag_info, EJTAG_INST_CONTROL);
retval = mips_ejtag_drscan_32(ejtag_info, ejtag_ctrl);
...
if (ejtag_ctrl EJTAG_CTRL_ROCC)
{...
ejtag_ctrl is host endian uint32. If mips_ejtag_drscan_32 would be in
target endianness you need to swap here or write and use a new function
that does swapping.
I agreee. Code like this is present on even lower level, im mips32_pracc.c, like
while (1)
{
retval = mips_ejtag_drscan_32(ejtag_info, ejtag_ctrl);
if (retval != ERROR_OK)
return retval;
if (ejtag_ctrl EJTAG_CTRL_PRACC)
break;
if ( (timeout = timeval_ms()-then) 1000 )
{
LOG_DEBUG(DEBUGMODULE: No memory access in progress!);
return ERROR_JTAG_DEVICE_ERROR;
}
}
It has to be that way - so code must be in the host endianess right
after drscan.
Is this swap to host endianess done by buf_get_u32() in
mips_ejtag_drscan_32() after the queue has been executed ?
BR,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Fri, Jul 8, 2011 at 2:05 PM, Mahr, Stefan stefan.m...@sphairon.com wrote: Where are those functions defined and how do they know what the target endianness is? They doesn't know the target endianness, but host endianness. How do they convert then, when they do not know from which endianes to convert from ? /** * Sets @c num bits in @c _buffer, starting at the @c first bit, * using the bits in @c value. This routine fast-paths writes * of little-endian, byte-aligned, 32-bit words. * @param _buffer The buffer whose bits will be set. * @param first The bit offset in @c _buffer to start writing (0-31). * @param num The number of bits from @c value to copy (1-32). * @param value Up to 32 bits that will be copied to _buffer. */ static inline void buf_set_u32(void *_buffer, unsigned first, unsigned num, uint32_t value) BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Fri, Jul 8, 2011 at 4:23 PM, Mahr, Stefan stefan.m...@sphairon.com wrote: Is this swap to host endianess done by buf_get_u32() in mips_ejtag_drscan_32() after the queue has been executed ? Yes, buf_get_u32() and buf_set_u32() make sure uint32 is in host endianness. OK, we are slowely nailing it... Just let me see how the hell these functions do the conversion target/host endianess Do you have any idea ? BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Fri, Jul 8, 2011 at 4:30 PM, Mahr, Stefan stefan.m...@sphairon.com wrote: How do they convert then, when they do not know from which endianes to convert from ? Conversion is done from byte array of jtag chain. How ? The endianness of MIPS EJTAG tap seems to have always the same endianness, no matter of MIPS CPU memory endianness. What makes you think so ? EJTAG specification, Document Number: MD00047 describes bit in Debug Control Register ENM (bit 29 of DCR) Endianess in which the processor is running in kernel and Debug Mode. If your CPU runs in the BE, you'll have to feed it with BE code. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Fri, Jul 8, 2011 at 6:30 PM, Mahr, Stefan stefan.m...@sphairon.com wrote: How do they convert then, when they do not know from which endianes to convert from ? Conversion is done from byte array of jtag chain. How ? buf_get_u32 does conversion from uint8* array example: mips_ejtag_get_impcode (mips_ejtag.c) field.in_value is filled by jtag_add_dr_scan with 4 times uint8. buf_get_u32 converts byte array to host endian uint32 How ? It does not convert anything. It just takes the data and puts it into array, in the order that it comes. The endianness of MIPS EJTAG tap seems to have always the same endianness, no matter of MIPS CPU memory endianness. What makes you think so ? Because openocd works in all combinations of BE and LE host and target. (If you revert commit 2482244b0788c007dd789c21a4416379c229ea5c.) So yes, it's just a guess. Which might mean that all commands are sent to EJTAG in appropriate target format in which CPU expects them (be it BE or LE, depends in which mode it runs). Could this be the explanation: http://downloads.buffalo.nas-central.org/LS2_MIPSel/DevelopmentTools/JTAG/MD00047-2B-EJTAG-SPC-03.10.pdf Page 97: Byte 0 refers to bits 7:0, byte 1 refers to bits 15:8, byte 2 refers to bits 23:16, and byte 3 refers to bits 31:24, independent of endianess. This is _always_ the case in _all_ architectures. But, as you see, this Byte0 is put to lower addresses for LE and to higher for BE. This is always the case. Please also see Chapter 6.3.3, 6.3.6, 6.4.1, etc. TAPs are alway LSB first, so endianness doesn't matter here. This is always the case, for all JTAG TAPS. No, there must be something else... BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fujitsu FM3 Flash drivers for OpenOCD integration
On Thu, Jul 7, 2011 at 9:58 AM, openOCD.fseu openocd.f...@de.fujitsu.com wrote: Dear all, attached you can find our OpenOCD support package for the new Cortex-M3 Family offered by Fujitsu Semiconductor again. Posting proprietary-format archive (zip) packets to the open source mailing list is not the most intelligent thing to do, besides being annoying an repelling. As to be said, posting anything besides plain text is already strange. Is there anybody responsible for integrating it to the OpenOCD project? Yes - you. Format your patches. Is there any other issue needed for integration? Yes. You did not read the basic documentation on OpenOCD development participation. The drivers were developed by our own, compiled together with the OpenOCD modules and tested successfully with our target MCUs with an FTDI-USB-JTAG adapter. This is good. I took a quick look, looks very nice. We would appreciate, if anybody could take care of this issue. Follow the guidelines and you'll be OK. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD][MIPS32]Cache non-coherent - sync missing
On Wed, Jul 6, 2011 at 9:32 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: Open questions are : 1) As I mentioned before, is this KSEG discovery good ? Do I get well which segment we are (look my previous post on the subject) 2) mips32_c0_write() is not used for the moment, so it can not be commited to master. I will have to finish all before posting PULL request. My idea is to create some kind of interface towards these mips32_cp0_read/write() functions, so that we can R/W CP0 regs directly from the Telnet client, similar as we can do for ARM's CP15. That would be something ! OK, I closed two remaining questions by : 1) Verifying the docs and comparing how things are done in Linux. I think that this seg look-up works well, and it show correct results in my tests. 2) Implementing Telnet interface to CP0 manipulation commands - this way they are both always used, and with a good reason - now we can manipulate C0 copro directly from OpenOCD ! I did a several tests, and I like it. I will be posting PULL Request. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [OpenOCD][PULL Request][MIPS32] CP0 coprocessor manipulation and cache synchronization routines
Hi all, I am happy to present you several exciting enhancements to the MIPS32 target. Most notably : 1) Implemented mips32_cp0_read() and mips32_cp0_write() routines that can affect CP0 copro regs. 2) Implemented command interfaces for these commands, so that they can be called from Telnet interface 3) Implemented cache synchronization, so that we can now support soft breaks on cached regions. Linux can be debugged fine now. All this has been discussed before on ML. I have split all in logically independent commits, so that it can be more easy integrated into the master (I tested each commit independently, and overall version). In the end, I rebased to souceforge's master, so all you have to do is to pull the changes from my github branch. BR, Drasko The following changes since commit ac43d7a69fca52df1ad287b51c44013653ad2f61: Drasko DRASKOVIC (1): mips_m4k and arm7_9 : Fix soft bkpt endianess for 16-bit instructions are available in the git repository at: git://github.com/drasko/openocd.git master Drasko DRASKOVIC (4): mips32: Removed Unnecessary JTAG Queue Flush mips_m4k: common_magic should be unsigned mips32: Added CP0 coprocessor R/W routines mips32: Sync Caches to Make Instr Writes Effective src/target/mips32.c | 106 ++ src/target/mips32.h | 117 --- src/target/mips32_pracc.c | 342 +++-- src/target/mips32_pracc.h | 41 +- src/target/mips_m4k.c | 108 ++- src/target/mips_m4k.h |7 +- 6 files changed, 679 insertions(+), 42 deletions(-) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD][PULL Request][MIPS32] CP0 coprocessor manipulation and cache synchronization routines
On Thu, Jul 7, 2011 at 7:48 PM, Michael Schwingen rincew...@discworld.dascon.de wrote: Am 07/07/2011 07:27 PM, schrieb Drasko DRASKOVIC: Hi all, I am happy to present you several exciting enhancements to the MIPS32 target. This is great! Hi Michael, thanks. I hope it will not be a pain for integration. I do not (yet) use MIPS, but from the descriptions of what you did, this should bring OpenOCD a good step forward. Changes can be visible from my branch github web interface : https://github.com/drasko/openocd There is a lot of insertions, which is good - a newly contributed code that enables new (so far non-existing and missing) features for MIPS platform. Particularly nasty are ASM parts implemented in opcode macros and passed to CPU via EJTAG shared mem as a pure bytecode miniprograms. These are difficult to debug, but once mechanism is understood it can be done (one just have to be very careful). I did my best to explain this mechanism before in my EJTAG doc (posted to this list, but pending to be pretty-formated and commited) and also to place appropriate comments in the code. All in all, I am satisfied with these changes and I think that they make MIPS platform way more versatile. In any case, it will represent a good base for new additions and changes, and I'll try to maintain this branch and contribute as I move along. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Wed, Jul 6, 2011 at 6:35 PM, Mahr, Stefan stefan.m...@sphairon.com wrote: Did you see this by testing or by inspection? Both :) Do we even have the right macros here? It would be something like unaligned uint32_t access macros, which will have to exist in host endian versions. mips32_pracc_read_mem casts uint32 to void, so we need to cast it back to uint32 Where exactly ? I can see that void* is casted in uint32*, but not vice versa... I can see also that in mips_m4k_read_memory() uint8_t* is casted to void*. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Thu, Jul 7, 2011 at 12:59 AM, Andreas Fritiofson
andreas.fritiof...@gmail.com wrote:
No, casting a pointer-to-any-type to a pointer-to-void and back will never
cause alignment issues. The question is who makes the guarantee that the
function is only ever called with uint32-aligned generic pointers. If it
just happens to be so that all *current* callers pass a uint32 pointer cast
to void pointer, it would be a terribly bad idea to suddenly assume that. If
it is guaranteed by design/contract, why is a void pointer used at all? Just
use a pointer to uint32 then.
I have no experience with the MIPS code or arch at all, but if it was up to
me I'd prefer if a *_read_mem function didn't interpret the data and thus it
should deal with void pointers.
I see no other way... Actually, any data you want to write must be
transfered to 32-bit value put to the register... Acutually, it is
transformed in 32-bit parameter, put onto the miniprogram EJTAG stack,
and then copied in the miniprogram (a small Monitor ROM, if you want,
written dynamically via dongle) to register. This register is the
written to RAM.
Now, there must be a way to put 8-bit values to EJTAG stack and then
just put this 8 bits into the reg in a miniprogram, but that would
demand quite a bit of changes of assembly bytecode miniprograms, IMHO.
I don't know at this point, I'll have to study MIPS code more throughly.
It would by design be totally free from all
endian issues and conversions. Moreover, a function accepting a
pointer-to-void should be prepared to handle any kind of alignment thrown at
it (unless explicitly stated). That excludes direct casts to uint32_t*.
That's why GCC is complaining. Sometimes...
It should never complain when casting a generic pointer to another pointer,
right? You shouldn't even need an explicit cast IIRC.
Where param_in is uint32_t*, and buf is uint8_t* ?
Is is maybe because of code like this :
for (i = 0; i count; i++)
{
param_in[i + 2] = buf[i];
}
Dunno... I never seen the warnings so far...
BR,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Thu, Jul 7, 2011 at 11:04 PM, Michael Schwingen rincew...@discworld.dascon.de wrote: Am 07/07/2011 10:41 PM, schrieb Mahr, Stefan: Probably the best way would be to remove endianness swapping from mips_m4k_read_memory and put it to mips32_pracc/dma_read_mem32/16. Same for write. pro: mips32_pracc_read_mem32, ... will return a byte array in target endianness, so no cast necessary. con: Add swapping to at least 10 seperate functions Not sure about this. Without having a look at the code, I would expect a function with read_mem32 in the name to return a 32-bit value, not a byte array, and I would expect to get a 32-bit value without a cast. Which cast exacly are you mentioning, and in which function ? static int mips32_pracc_read_mem32(struct mips_ejtag *ejtag_info, uint32_t addr, int count, uint32_t *buf) does not do any casting and returns 32-bit value. Especially if this is used in 10 places, this looks like there *is* a need for a function that returns swapped 32-bit values, only the function uses the wrong data types. I have seen some things that can be avoided in mips32_pracc code. Can you point me exactly to the places, I can not seem to get the particular problem... BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS target, big endian host
On Thu, Jul 7, 2011 at 10:41 PM, Mahr, Stefan stefan.m...@sphairon.com wrote: If alignment is not guaranteed, casting from uint32 to void would cause problems too, wouldn't it? Why? Sorry for confusion. I meant the casting within mips32_pracc_read_mem. This is also a cast from void* to uint32_t*. If there will be an alignment error, it will occur here too. That's correct. There is no way to know from the code context, is there? No documentation either. Probably the best way would be to remove endianness swapping from mips_m4k_read_memory and put it to mips32_pracc/dma_read_mem32/16. Same for write. pro: mips32_pracc_read_mem32, ... will return a byte array in target endianness, so no cast necessary. con: Add swapping to at least 10 seperate functions I am not keen to have code repetition in MIPS32 PrAcc code, which is already bloated and very difficult to maintain... I think we should well understand what is happening here before resolving the problem in the most elegant manner. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On Wed, Jul 6, 2011 at 11:02 AM, Luc ANTOLINOS luciogi...@gmail.com wrote: Hi, I'm working with an LPC2388 (arm7tdmi-s core). I use the IDLE power mode to stop the arm core to reduce power consumption. All IT and peripheral are still ON in this mode, only the arm core is sleeping. The problem is when we want to use our probe (Olimex ARM-USB-OCD) with OpenOCD (0.5.0 from git 2011-05-20) we obtain an error message if the software already running on the board is using the IDLE mode : JTAG scan chain interrogation failed: all zeroes Check JTAG interface, timings, target power, etc. Trying to use configured scan chain anyway... Bypassing JTAG setup events due to errors I the software running on the CPU doesn't use the power reduction mode (arm core is still ON in this case) then I have no problem with the jtag. The problem seams to be related only to the power mode. Whatever the openocd command I use (reset, halt, soft_reset_halt, resume 0x00) openocd error is like : Halt timed out, wake up GDB. timed out while waiting for target halted in procedure 'halt' If I try to directly write to the CPU register to disable the IDLE mode, i get (a normal error message): Target not halted So I can not disable the IDLE mode with my jtag. I have to use the CPU integrated bootloader to reload a software with no IDLE mode through the RS232 link before I can use my Jtag again. I've seen other messages related to this point on the ML but has anyone found a solution to this problem ? From OpenOCD Manual Chapter 5.6 Target Software Changes : ARM Wait-For-Interrupt... Many ARM chips synchronize the JTAG clock using the core clock. Low power states which stop that core clock thus prevent JTAG access. Idle loops in tasking environments often enter those low power states via the WFI instruction (or its coprocessor equivalent, before ARMv7). You may want to disable that instruction in source code, or otherwise prevent using that state, to ensure you can get JTAG access at any time. For example, the OpenOCD halt command may not work for an idle processor otherwise. As a more polite alternative, some processors have special debug-oriented registers which can be used to change various features including how the low power states are clocked while debugging. The STM32 DBGMCU CR register is an example; at the cost of extra power consumption, JTAG can be used during low power states. Chapter 6.2.4 Warning: On most ARMs, JTAG clock detection is coupled to the core clock, so software using a ‘wait for interrupt’ operation blocks JTAG access. Adaptive clocking provides a partial workaround, but a more complete solution just avoids using that instruction with JTAG debuggers. Chapter 15.2 Target State handling Warning: On ARM cores, software using the wait for interrupt operation often blocks the JTAG access needed by a halt command. This is because that operation also puts the core into a low power mode by gating the core clock; but the core clock is needed to detect JTAG clock transitions. One partial workaround uses adaptive clocking: when the core is interrupted the operation completes, then JTAG clocks are accepted at least until the interrupt handler completes. However, this workaround is often unusable since the processor, board, and JTAG adapter must all support adaptive JTAG clocking. Also, it can’t work until an interrupt is issued. A more complete workaround is to not use that operation while you work with a JTAG debugger. Tasking environments generaly have idle loops where the body is the wait for interrupt operation. (On older cores, it is a coprocessor action; newer cores have a ‘wfi’ instruction.) Such loops can just remove that operation, at the cost of higher power consumption (because the CPU is needlessly clocked). Chapter 22 FAQ You can still debug the ’low power’ situations - you just need to either use a fixed and very slow JTAG clock rate ... or else manually adjust the clock speed at every step. (Adjusting is painful and tedious, and is not always practical.) It is however easy to “code your way around it” - i.e.: Cheat a little, have a special debug mode in your application that does a “high power sleep”. If you are careful - 98% of your problems can be debugged this way. Note that on ARM you may need to avoid using the wait for interrupt operation in your idle loops even if you don’t otherwise change the CPU clock rate. That operation gates the CPU clock, and thus the JTAG clock; which prevents JTAG access. One consequence is not being able to halt cores which are executing that wait for interrupt operation. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On Wed, Jul 6, 2011 at 1:08 PM, Luc ANTOLINOS luciogi...@gmail.com wrote: On 6 July 2011 12:37, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: From OpenOCD Manual Thanks for all the pointers to the documentation. From these informations, I understand the better way is to not use the wait for IRQ or other related low power consumption mode. It is off course possible to remove the IDLE mode for my software in As a rule of the thumb, stay away from ARMS wfi (wait for interrupt) instruction in your DEBUG more (in idle loop). This will prevent low-power mode, but at least you will be able to debug. However, normal behavior would be to use slow JTAG speed that ARM can handle in low-power mode and everything should work, even without adaptive clocking (you will be doomed to debug everything verly slow, though). BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On Wed, Jul 6, 2011 at 1:40 PM, Andreas Fritiofson andr...@fritiofson.net wrote: How could this work if the core clock is stopped? This should work, as host JATG inteface embedded in the ARM core has a procedure to remove WFI when it gets debug request from the dongle (if everything is well conetcted on AMBA bus and ARM's state machine procedures are well respected, which I do not doubt in LPC case). After this moment core is awaken, and you can JTAG can halt it. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On Wed, Jul 6, 2011 at 1:36 PM, Luc ANTOLINOS luciogi...@gmail.com wrote: On 6 July 2011 13:17, Spencer Oliver s...@spen-soft.co.uk wrote: Openocd did work ok for wfi as long as the jtag clock was slow enough. However this was broken in HEAD last time i tested it - it has been on my look at list for a while I'm not using 'WFI' instruction, I've found this one in the instruction set. I suppose this arm (Armv4T architecture) has not. I'm using a LPC2388 specific register to command entering low power mode (IDLE) (up to the next IRQ, so I obtain an same behavior that with WFI). For the sake of experiment, can you try with WFI, and tell us what you are getting ? BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM IDLE mode and JTAG scan chain interrogation failed
On Wed, Jul 6, 2011 at 1:57 PM, Spencer Oliver s...@spen-soft.co.uk wrote: On 6 July 2011 12:36, Luc ANTOLINOS luciogi...@gmail.com wrote: On 6 July 2011 13:17, Spencer Oliver s...@spen-soft.co.uk wrote: Openocd did work ok for wfi as long as the jtag clock was slow enough. However this was broken in HEAD last time i tested it - it has been on my look at list for a while I'm not using 'WFI' instruction, I've found this one in the instruction set. I suppose this arm (Armv4T architecture) has not. I'm using a LPC2388 specific register to command entering low power mode (IDLE) (up to the next IRQ, so I obtain an same behavior that with WFI). I know, just updating Drasko on the wfi status for armv7m arch. LPC2388 has ARM7TDMI-S which should be ARMv4, right ? ARMv7 are little Cortexes ;). BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD][MIPS32]Cache non-coherent - sync missing
On Wed, Jul 6, 2011 at 12:45 AM, Drasko DRASKOVIC
drasko.drasko...@gmail.com wrote:
On Wed, Jul 6, 2011 at 12:33 AM, Igor Skochinsky skochin...@mail.ru wrote:
Hello Drasko,
Wednesday, July 6, 2011, 12:00:11 AM, you wrote:
DD On the first look, this can be accomplished by reading CP0 PRId
DD register, but Revision field is not quite well explained.
DD I have no idea how to obtain info if the proc is MIPS32/64 Rev2
compliant.
You should use the Config register (CP0 Register 16). AT field (bits
14:13) tells if it's MIPS32 or MIPS64, and AR (12:10) is the release.
DD Hi Igor,
DD thanks, I just took a quick look, and I thought that CP0 PRId would be
DD more appropriate. I saw that bits 7:0 encode the release, but I did
DD not get the codes - they are not well explained in the doc.
I would expect that too, but it's not the case, apparently. Bits 7:0
is the manufacturer-specific chip revision ID, not the ISA release.
DD Maybe CP0 Config would be a better place to look, though naming is not
DD suggestive - Config is used to configure your CPU (it should be RW)
DD and ID is where you want to read Read Only information...
Actually, most of the fields in Config are read-only. Not very
logical but that's how it is.
Yes, not very logical, but actually it seems to be quite fine -
because in the same config reg, CP0 CONFIG0, we find K0, KU and K23
field which tel us reachability of KUSG, KSEG0 and KSEG23
respectively. This is good, because it saves us from another CP0 read
(which must be done by executing miniprogram).
I did some progress implementing all these selections and
mips32_cp0_read/write() functions and I am in the process of testing -
so far so good.
I just wanted to verify one thing : how we exactly discover which
segment we should treat (which segment we are in) ?
What I am currently doing in the mips32_pracc_write_mem, which has a
signature like this :
int mips32_pracc_write_mem(struct mips_ejtag *ejtag_info, uint32_t
addr, int size, int count, void *buf)
is
/**
* If we are in the cachable regoion and cache is activated,
* we must clean D$ + invalidate I$ after we did the write,
* so that changes do not continue to live only in D$, but to be
* replicated in I$ also (maybe we wrote the istructions)
*/
uint32_t conf = 0;
int cached = 0;
mips32_cp0_read(ejtag_info, conf, 16, 0);
switch (KSEGX(addr))
{
case KUSEG:
cached = (conf MIPS32_CONFIG0_KU_MASK)
MIPS32_CONFIG0_KU_SHIFT;
break;
case KSEG0 :
cached = (conf MIPS32_CONFIG0_K0_MASK)
MIPS32_CONFIG0_K0_SHIFT;
break;
case KSEG1:
/* uncachable segment - nothing to do */
break;
case KSEG2:
case KSEG3:
cached = (conf MIPS32_CONFIG0_K23_MASK)
MIPS32_CONFIG0_K23_SHIFT;
break;
default:
/* what ? */
break;
}
where I borrowed KSEGX(addr) macro from Linux :
/** Returns the kernel segment base of a given address */
#define KSEGX(a)((a) 0xe000)
So, as you see, for segment discovery I use addr variable, but that is
the write destination address. Can it be in the different segment that
the one from we are currently in ?
What should I look for to discover appropriate segment of execution,
so I can look for the appropriate cacheability flags (KU, K0 or K23) ?
BR,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [OpenOCD] Defined but not used
Hi all, I'd like to add a function that is not necesarely used today, but most probably will be in a recent future. How do we handle these ? Do I put it between #if 0 / #endif and commit like that ? Currently, compilation breaks because of strict error checking (werror) cc1: warnings being treated as errors mips32_pracc.c:658: error: ‘mips32_cp0_write’ defined but not used make[5]: *** [mips32_pracc.lo] Error 1 BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD] Defined but not used
On Wed, Jul 6, 2011 at 9:16 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: Split it into a separate patch and push it off into a iwillusethissoon branch? So we can not have code that is currently is not used but is useful by all means in master ? For example, I created mips32_c0_read() function that reads C0 coprocesor registers. I also created it's pair, mips32_c0_write(), and tested. Now, for the current needs, I only want to read configuration, but I can see well that someone (me, soon, for example) might use this function, already tested and proven to be working. But it can not end up in a master... I thought that there might be a method of leaving this stuff into the code but preceding it wit some macro NOT_USED, or something... BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD][MIPS32]Cache non-coherent - sync missing
Hi all,
based on the previous discussions about this subject, I came up with this patch.
It :
1) Looks if the segment is cacheable
2) If yes, Adds cache sync via synci, if REV is 2
3) If REV1, it uses cache instruction
Now it should work for both Revisions.
I also added mips32_c0_read/write() functions which can really help
developer - we can now read and write all C0 coprocessor regs !
I used these helper functions to find out Release number, and also to
read cacheability bits on a given segment, but also to find cache line
size.
I tested all this, and it seems to work. I have Revision 2 CPU, but I
forced it to use both synci and cache verisons in a different
tests - all PASSes.
Open questions are :
1) As I mentioned before, is this KSEG discovery good ? Do I get well
which segment we are (look my previous post on the subject)
2) mips32_c0_write() is not used for the moment, so it can not be
commited to master. I will have to finish all before posting PULL
request. My idea is to create some kind of interface towards these
mips32_cp0_read/write() functions, so that we can R/W CP0 regs
directly from the Telnet client, similar as we can do for ARM's CP15.
That would be something !
In the meanwhile it would be great if you can comment on this
implementation (or even better if somebody can integrate it and test
it - remember --disable-werror), so that I can improve it (it looks
like a quite a piece to be added). Once it is polished I'll post PULL
request from my MIPS github branch.
BR,
Drasko
From 9b5e82b2df6a3de4b8a5e178ffd5bd2c0e8fbbd3 Mon Sep 17 00:00:00 2001
From: Drasko DRASKOVIC drasko.drasko...@gmail.com
Date: Tue, 5 Jul 2011 17:20:33 +0200
Subject: [PATCH] mips32: Sync Caches to Make Instr Writes Effective
Pprogram that loads another program into memory is actually writing the
D- side cache.
The instructions it has loaded can't be executed until they reach the
I-cache.
After the instructions have been written, the loader should arrange to
write back any containing D-cache line and invalidate any locations
already in the I-cache.
For the MIPS Architecture Release2 cores, we can use synci command
that does this job.
For Release1 we must use cache instruction.
This patch also adds mips32_cp0_read() and mips32_cp0_write()
functions that can be used to discover various parameters
of the CPU, like cacheablity, Release number or cache line size.
---
src/target/mips32.h | 115 ---
src/target/mips32_pracc.c | 351 -
2 files changed, 437 insertions(+), 29 deletions(-)
diff --git a/src/target/mips32.h b/src/target/mips32.h
index 4f0f0ef..cb9712c 100644
--- a/src/target/mips32.h
+++ b/src/target/mips32.h
@@ -4,6 +4,8 @@
* *
* Copyright (C) 2008 by David T.L. Wong *
* *
+ * Copyright (C) 2011 by Drasko DRASKOVIC drasko.drasko...@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 *
@@ -28,6 +30,39 @@
#define MIPS32_COMMON_MAGIC 0xB320B320
+/**
+ * Memory segments (32bit kernel mode addresses)
+ * These are the traditional names used in the 32-bit universe.
+ */
+#define KUSEG 0x
+#define KSEG0 0x8000
+#define KSEG1 0xa000
+#define KSEG2 0xc000
+#define KSEG3 0xe000
+
+/** Returns the kernel segment base of a given address */
+#define KSEGX(a) ((a) 0xe000)
+
+/** CP0 CONFIG regites fields */
+#define MIPS32_CONFIG0_KU_SHIFT 25
+#define MIPS32_CONFIG0_KU_MASK (0x7 MIPS32_CONFIG0_KU_SHIFT)
+
+#define MIPS32_CONFIG0_K0_SHIFT 0
+#define MIPS32_CONFIG0_K0_MASK (0x7 MIPS32_CONFIG0_K0_SHIFT)
+
+#define MIPS32_CONFIG0_K23_SHIFT 28
+#define MIPS32_CONFIG0_K23_MASK (0x7 MIPS32_CONFIG0_K23_SHIFT)
+
+#define MIPS32_CONFIG0_AR_SHIFT 10
+#define MIPS32_CONFIG0_AR_MASK (0x7 MIPS32_CONFIG0_AR_SHIFT)
+
+#define MIPS32_CONFIG1_DL_SHIFT 10
+#define MIPS32_CONFIG1_DL_MASK (0x7 MIPS32_CONFIG1_DL_SHIFT)
+
+#define MIPS32_ARCH_REL1 0x0
+#define MIPS32_ARCH_REL2 0x1
+
+
/* offsets into mips32 core register cache */
enum
{
@@ -92,10 +127,14 @@ struct mips32_algorithm
enum mips32_isa_mode isa_mode;
};
+#define MIPS32_OP_ADDIU 0x21
+#define MIPS32_OP_ANDI 0x0C
#define MIPS32_OP_BEQ 0x04
+#define MIPS32_OP_BGTZ 0x07
#define MIPS32_OP_BNE 0x05
#define MIPS32_OP_ADDI 0x08
#define MIPS32_OP_AND 0x24
+#define MIPS32_OP_CACHE 0x2F
#define MIPS32_OP_COP0 0x10
#define MIPS32_OP_JR 0x08
#define MIPS32_OP_LUI 0x0F
@@ -106,12 +145,21 @@ struct mips32_algorithm
#define MIPS32_OP_MTHI 0x11
#define MIPS32_OP_MFLO 0x12
#define MIPS32_OP_MTLO 0x13
+#define
Re: [Openocd-development] [OpenOCD] Defined but not used
On Wed, Jul 6, 2011 at 9:34 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: #if 0 + comment is fine. But if you have code that you will start using soon, then it's better if you keep it around and submit it along with your next patches when it is ready. OK, I'll see... Maybe it will be more convenient to post it as a comment, if I have not time to implement Telnet interface to this command (in order to actually use it). There is always *something* to tinker with in a fn that hasn't been tested... Everything has been tested. I tested the implementation during the development process, but in the end I just do not use write function, just read (but like to commit write one also, in a pair). BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD][MIPS32]Cache non-coherent - sync missing
On Thu, Jun 30, 2011 at 6:25 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: Now, in case of EJTAG communication implementation in mips32_pracc.c this is not a simple thing to implement. I am currently adding missing opcodes and trying to craft a miniprogram based on bytecode, similar to existing stuff. It is quite a headache to debug, but I previously spent a lot of time on demistfying this implementation and wrote one draft doc to this list (more complete doc is on the way, and will be contributed as a separate patch). OK, I have first draft of the patch which adds raw bytecodes and spits them out to CPU via EJTAG, implementing miniprogram that is given in the MIPS32 Architecture For Programmers Volume II: The MIPS32 Instruction Set (pasted below) I have debugged and tested this implementation and it seems that it works quite fine, even without notable performance penalty. So, the good new is that I can now debug Linux on MIPS with OpenOCD, because soft breakpointswork fine and caches are coherent. I will let this patch cook for a while and then send an official PULL reques once it is completely ready. I am just posting it now so that I can get some responses and commenets - what do you thisnk about this implementation ? Does this sound reasonable ? In the MIPS official doc MD00086 (MIPS32™ Architecture For Programmers Volume II: The MIPS32™ Instruction Set), we can find interesting procedure to synchronize caches using synci (Synchronize Caches to Make Instruction Writes Effective) instruction. I am referencing here Programming Notes given in the chapter describing this instruction (page 287). Based on this, I re-implemented this procedure to the detail in bytecode minirpogram and I have first working draft. Here is the program from the mentioned ref. manual that I implemented via opcodes : Programming Notes: When the instruction stream is written, the SYNCI instruction should be used in conjunction with other instructions to make the newly-written instructions effective. The following example shows a routine which can be called after the new instruction stream is written to make those changes effective. Note that the SYNCI instruction could be replaced with the corresponding sequence of CACHE instructions (when access to Coprocessor 0 is available), and that the JR.HB instruction could be replaced with JALR.HB, ERET, or DERET instructions, as appropriate. /* * This routine makes changes to the instruction stream effective to the * hardware. It should be called after the instruction stream is written. * On return, the new instructions are effective. * * Inputs: * a0 = Start address of new instruction stream * a1 = Size, in bytes, of new instruction stream */ addu a1, a0, a1 /* Calculate end address + 1 */ rdhwr v0, HW_SYNCI_Step /* Get step size for SYNCI from new */ /* Release 2 instruction */ beq v0, zero, 20f /* If no caches require synchronization, */ nop /* branch around */ 10: synci 0(a0) /* Synchronize all caches around address */ sltu v1, a0, a1 /* Compare current with end address */ bne v1, zero, 10b /* Branch if more to do */ addu a0, a0, v0 /* Add step size in delay slot */ sync /* Clear memory hazards */ 20: jr.hb ra /* Return, clearing instruction hazards */ nop Best regards, Drasko From 04da97fd411df3de844f50864c598df2e479b688 Mon Sep 17 00:00:00 2001 From: Drasko DRASKOVIC drasko.drasko...@gmail.com Date: Tue, 5 Jul 2011 16:26:49 +0200 Subject: [PATCH] mips32 : Synchronize Caches to Make Instruction Writes Effective Pprogram that loads another program into memory is actually writing the D- side cache. The instructions it has loaded can't be executed until they reach the I-cache. After the instructions have been written, the loader should arrange to write back any containing D-cache line and invalidate any locations already in the I-cache. --- src/target/mips32.h | 70 +- src/target/mips32_pracc.c | 119 - 2 files changed, 153 insertions(+), 36 deletions(-) diff --git a/src/target/mips32.h b/src/target/mips32.h index 4f0f0ef..7dde7e7 100644 --- a/src/target/mips32.h +++ b/src/target/mips32.h @@ -4,6 +4,8 @@ * * * Copyright (C) 2008 by David T.L. Wong * * * + * Copyright (C) 2011 by Drasko DRASKOVIC drasko.drasko...@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 * @@ -92,7 +94,9 @@ struct mips32_algorithm enum mips32_isa_mode isa_mode; }; +#define MIPS32_OP_ADDIU 0x21 #define MIPS32_OP_BEQ 0x04 +#define MIPS32_OP_BGTZ
Re: [Openocd-development] [OpenOCD][MIPS32]Cache non-coherent - sync missing
On Tue, Jul 5, 2011 at 5:32 PM, Spencer Oliver s...@spen-soft.co.uk wrote: After a quick look over i see your patch assumes that synci is supported by the target - may not be the case. Hi Spen, yes, this is true. Otherwise we can re-implement this with cache command, but it will not be so nice. If we decide to support both Release 1 and Release 2 of MIPS architecture, then we will not be allowed to use bunch of functions that are present only in Rel 2, which is by my opinion 10 years old. What do you think ? BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD][MIPS32]Cache non-coherent - sync missing
On Tue, Jul 5, 2011 at 6:17 PM, Spencer Oliver s...@spen-soft.co.uk wrote: I think your patch is ok, but would be better if it checks the arch version and issue a warning about cache writes not supported or something along those lines. On the first look, this can be accomplished by reading CP0 PRId register, but Revision field is not quite well explained. I have no idea how to obtain info if the proc is MIPS32/64 Rev2 compliant. Having all this in mind, I think it would be more reasonable to re-implement the procedure using cache opcode. But I would have to dynamically figure out size of cache line (I'll have to read it from CP0) in that case, and plus it will be less effective, I think. When I look at this, I think that some additional commands for manipulating copro CP0 directly from OpenOCD would be quite handy, something like we have for ARM's CP15. I'll take a look at this and try to implement it. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD][MIPS32]Cache non-coherent - sync missing
2011/7/5 Igor Skochinsky skochin...@mail.ru: Hello Drasko, Tuesday, July 5, 2011, 7:01:44 PM, you wrote: DD On Tue, Jul 5, 2011 at 6:17 PM, Spencer Oliver s...@spen-soft.co.uk wrote: I think your patch is ok, but would be better if it checks the arch version and issue a warning about cache writes not supported or something along those lines. DD On the first look, this can be accomplished by reading CP0 PRId DD register, but Revision field is not quite well explained. DD I have no idea how to obtain info if the proc is MIPS32/64 Rev2 compliant. You should use the Config register (CP0 Register 16). AT field (bits 14:13) tells if it's MIPS32 or MIPS64, and AR (12:10) is the release. Hi Igor, thanks, I just took a quick look, and I thought that CP0 PRId would be more appropriate. I saw that bits 7:0 encode the release, but I did not get the codes - they are not well explained in the doc. Maybe CP0 Config would be a better place to look, though naming is not suggestive - Config is used to configure your CPU (it should be RW) and ID is where you want to read Read Only information... I will look tomorrow again, I do not have docs at my disposal now. BTW. CP0 Config (reg 16) has 3 selects. Which one did you mention - 0, 1 or 2 ? I think that I will end up writing both cache and synci version, and switch in dependence of architecture used. I just want to write mips32_cp0_read() and mips_cp0_write() functions before, which I started today, so that we have more versatile interface. I need this in order to read cache line size and similar cache configs if I want to use cache instruction (which I so wanted to avoid, but life is though...) BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD][MIPS32]Cache non-coherent - sync missing
On Wed, Jul 6, 2011 at 12:33 AM, Igor Skochinsky skochin...@mail.ru wrote: Hello Drasko, Wednesday, July 6, 2011, 12:00:11 AM, you wrote: DD On the first look, this can be accomplished by reading CP0 PRId DD register, but Revision field is not quite well explained. DD I have no idea how to obtain info if the proc is MIPS32/64 Rev2 compliant. You should use the Config register (CP0 Register 16). AT field (bits 14:13) tells if it's MIPS32 or MIPS64, and AR (12:10) is the release. DD Hi Igor, DD thanks, I just took a quick look, and I thought that CP0 PRId would be DD more appropriate. I saw that bits 7:0 encode the release, but I did DD not get the codes - they are not well explained in the doc. I would expect that too, but it's not the case, apparently. Bits 7:0 is the manufacturer-specific chip revision ID, not the ISA release. DD Maybe CP0 Config would be a better place to look, though naming is not DD suggestive - Config is used to configure your CPU (it should be RW) DD and ID is where you want to read Read Only information... Actually, most of the fields in Config are read-only. Not very logical but that's how it is. DD I will look tomorrow again, I do not have docs at my disposal now. DD BTW. CP0 Config (reg 16) has 3 selects. Which one did you mention - 0, DD 1 or 2 ? Select 0. See MIPS64 Arch vol 3 for more details. http://mips.com/products/architectures/mips64/#specifications Hi Igor, thanks a lot. I'll take a look at it tomorrow morning and maybe for the first version implement just cache_sync() with synci if REV == REV2, else warning No candies for you, as Spencer has suggested. I thing it would be good to have something, at this look quite good as the implementation, it's already there, plus I have been able to test it and it gives good results. For the second version I'll go towards mips32_c0_read/write() functions and cache opcode implementation if REV != REV2, to support older archs also... BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD][PULL Request]Fix MIPS32 and ARM7_9 16-bit soft bkpt endianess
On Mon, Jul 4, 2011 at 6:18 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: I rebased the commit and pushed it to master. Why would we want to merge such a change rather than rebase and push? I creates a fork in the history for no reason that I can think of. You've got the point, it is better. Is this due to digital signing? I can see how rebasing would break digital signatures and merged would retain them. Well, when I have sent pull request I had an impression that I was rebased to the Sourceforge's master. This is the question I asked before, just to be sure - do I rebase to Sourceforge's master and then push all to my remote (which I think is better), or everyone works on it's own branch and then changes are merged by integrator... I think I should always rebase to Sourceforge's master and then just push, so that whoever integrates to the maser can just pull (no need to merge). And as I said, at the time of sending of pull request I thought I was rebased to master, so that you can just pull from the branch. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Current master branch state
On Mon, Jul 4, 2011 at 1:23 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: On Mon, Jul 4, 2011 at 1:12 PM, Spencer Oliver s...@spen-soft.co.uk wrote: On 2 July 2011 15:35, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: On Fri, Jul 1, 2011 at 11:37 PM, Spencer Oliver s...@spen-soft.co.uk wrote: On 01/07/2011 22:22, Drasko DRASKOVIC wrote: could you send the log of the previous working version where you did not need to pass --disable-option-checking Hi Spend, please find it attached. HEAD was hard-reseted to commit before yours, Looking at the logs i would say two things have happened. 1. your autoconf is broken, disable-option-checking should be passed to submodules when SUBDIRS is used. OK. I noted however that it's a known Debian bug : https://bugs.launchpad.net/debian/+source/libmcrypt/+bug/253991 But I currently can not change autotools (due to the permissions), so I'll stick with adding disable-option-checking manually. 2. jimtcl configure is now compliant and fails if it sees an unknown option, as it should. Then it's OK, I'll test at my home Debian to see if the issue repeats. If not, I'll try updating my home Debian's autotools to see if this remedies the issue. I tried last master on another machine, my Debian : drasko@Marx:~/openocd/openocd$ cat /proc/version Linux version 2.6.32-5-686 (Debian 2.6.32-18) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-2) ) #1 SMP Sat Jul 24 02:27:10 UTC 2010 ./bootstrap is givin another warnings now, but ./configure passes OK : drasko@Marx:~/openocd/openocd$ ./bootstrap + aclocal configure.in:2: warning: AC_INIT: not a literal: OpenOCD Mailing List openocd-development@lists.berlios.de + libtoolize --automake --copy + autoconf configure.in:2: warning: AC_INIT: not a literal: OpenOCD Mailing List openocd-development@lists.berlios.de + autoheader configure.in:2: warning: AC_INIT: not a literal: OpenOCD Mailing List openocd-development@lists.berlios.de + automake --gnu --add-missing --copy configure.in:2: warning: AC_INIT: not a literal: OpenOCD Mailing List openocd-development@lists.berlios.de Setting up submodules Bootstrap complete. Quick build instructions: ./configure --enable-maintainer-mode But this seems to be a known issue : https://bugs.launchpad.net/ubuntu/+source/autoconf/+bug/641611 http://savannah.gnu.org/support/?107450 BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] GPL wiz
Does it have to have somekig of copyright notice ? Here (http://en.wikibooks.org/wiki/FOSS_Licensing/Print_Version) I can see : Nowadays, copyright law does not require formalities. The author does not need to publish, register, pay a registration fee of any kind, nor attach a copyright notice to his/her/its work, for the copyright to take effect. Copyright is automatically applied to a work once it is created [9] and the creator of the work automatically becomes the copyright holder. Based on this, do we need at least some king of copyright notice that transfers the rights (which inherently belong to author, if not stated otherwise) ? http://www.gnu.org/prep/maintain/maintain.html#Copyright-Notices On Fri, Jul 1, 2011 at 11:23 AM, Nils Faerber nils.faer...@kernelconcepts.de wrote: Just my $0.05 from experience... Am 01.07.2011 07:28, schrieb Øyvind Harboe: Is there a GPL wiz in the house? Can we accept anonymous contributions just like that? I know there are anonymous contributions in Linux. The major issue with such contributions is when it comes to a dispute. If you do not have a clear copyright holder and statement with the original patch then anything can happen later. The original author might suddenly pop up, provide proof the he/she is the author and claim rights to this code/patch that are incompatible with the project or other code it was included into. This can cause *major* pain. So before accepting patches it is simply a wise guideline to always require clear authorship and license before incorporating third party code, no matter what size or significance. Almost any line of code can break your code/license when it comes to dispute (look at the many law suites from the past and current, e.g. SCO vs. Linux, Oracle vs. Android). Cheers nils -- Forwarded message -- From: Uhler, Richard ruh...@qualcomm.com Date: Fri, Jul 1, 2011 at 12:24 AM Subject: RE: [Openocd-development] [PATCH] Implementation of a remote bitbang jtag driver To: Øyvind Harboe oyvind.har...@zylin.com Cc: openocd-development@lists.berlios.de openocd-development@lists.berlios.de I have been instructed we can only make the contribution if no explicit copyright claim is required. Is that acceptable? Richard From: Øyvind Harboe [oyvind.har...@zylin.com] Sent: Sunday, June 26, 2011 8:42 AM To: Uhler, Richard Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] [PATCH] Implementation of a remote bitbang jtag driver Hi, some comments: - new files, except for config and macro files, must have the gpl 2 or later license header and it must state the copyright holder(you in this case). - the option should be --enable-remote-bitbang, not --enable-remote_bitbang to be more consistent with other options. -- Ø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/ -- kernel concepts GbR Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] GPL wiz
On Fri, Jul 1, 2011 at 3:13 PM, Nils Faerber nils.faer...@kernelconcepts.de wrote: Based on this, do we need at least some king of copyright notice that transfers the rights (which inherently belong to author, if not stated otherwise) ? http://www.gnu.org/prep/maintain/maintain.html#Copyright-Notices A copyright transfer is a very ugly thing and should be the last resort since it requires real paperwork - a boilerplate text inside the code is legally not enough for this. The GNU project usually requires this for parts that shall become GNU projects so that the GNU foundation can at all times also change the license on its own without having to consult with the copyrights owners again. I do not know what we mean exactly by copyright transfer. I meant some header notice, giving anyone right to use. distribute, etc... the code, and permits derived work. Also, I think that it should *must* have the notice to the user that it comes without any warranties (I think that some laws absolutely demand this). What I want to say, can someone who want to donate code to OpenOCD, but not put it in GPL licence then note in the notice explicitly that it gives the code and permits the users to keep it and modify it ? Would this be sufficient that we can keep this code forever, and prevent author to ever demand his code to be closed, or non distributable, or similar. Do we really need paperwork, or one statement : I give you this code is sufficient ? What you will want is rather a) a statement of authorship Author can not do differently than state that he holds the authorship on the code. But do every file really needs this ? and b) a license statement by this author. Must it be some official licence, or I give you this code forever (to distribute, modify, etc.) would be sufficient ? If the author chooses a license like the GPL then this will give you the perpetual right to use this code in its current state under all freedoms and restriction of the GPL (as they are known) at all times. Fro my point of view mixing licences can get complicated. IMHO GPL demands that all derived work remains GPL. Would linking with this code donated under FOO or BAR licence would be considered derived work ? If yes, then you must distribute it under GPL. If you do not have that, as mentioned above, you have the risk that at some later point the author might claim rights that you can not fulfil. PS: I am not a copyright lawyer - just for completeness ;) So do not take my rant for granted, this is just my personal view from personal experience and many discussions. Me even less. But I think that any discussion on this subject is beneficial for the project... BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Current master branch state
Hi all, is current maser broken ? ./config breaks on jimtcl configuration BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Current master branch state
Hmm.. Reseting hard to one beyond HEAD seems to workaround the prob : git-reset --hard HEAD~1 Spen, can you see on this check-in : http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commit;h=f6026a8295faf158e500a7acb9884f9fd4c30ad1 ? BR, Drasko On Fri, Jul 1, 2011 at 7:26 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: Hi all, is current maser broken ? ./config breaks on jimtcl configuration BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD][MIPS32][PATCH] Fix soft breakpoint unsetting endianess
On Fri, Jul 1, 2011 at 7:32 AM, Øyvind Harboe oyvind.har...@zylin.com wrote:
You need to translate words to the host endianness if the
host is to interpret the words.
However, if you are just copying memory, then you can read
words and write them back, without worrying about endianness.
Yes, that's it. And target_read_memory() just gets to the host data
bytes from the target, but thay are kept on the host in _target_
endianess. That's OK if we just want to temporarily store this data on
the host, like we do for example with breakpoint-orig_instr. But
before any comparison of this data with some macros defined on the
host, we must transform it to the _host_ endianess via
target_buffer_get_u32() function.
In mips_m4k.c code we currently have :
/* check that user program has not modified breakpoint instruction */
if ((retval = target_read_memory(target,
breakpoint-address, 4, 1,
(uint8_t*)current_instr)) != ERROR_OK)
{
return retval;
}
if (current_instr == MIPS32_SDBBP)
{
if ((retval = target_write_memory(target,
breakpoint-address, 4, 1,
breakpoint-orig_instr)) !=
ERROR_OK)
{
return retval;
}
}
i.e. we have comparison of current_instr which we obtained from target
via target_read_memory() and is kept in the host in _target_ endianess
with MIPS32_SDBBP macro which is defined on the host and thus kept in
the _host_ endianess.
Now, if target and host have same endianenss, this can pass unnoticed.
But if the endianess between host and the target differ, this check
will never pass, although there is really soft-break instruction in
the target.
Because this check never pass, original instruction is never wrote
back to the target and it keeps hitting breakpoint over and over.
If we take a look at arm7_9_common.c, we can see that it is properly
done this way :
/* check that user program as not modified breakpoint instruction */
if ((retval = target_read_memory(target,
breakpoint-address, 4, 1,
(uint8_t*)current_instr)) != ERROR_OK)
{
return retval;
}
current_instr = target_buffer_get_u32(target,
(uint8_t *)current_instr);
if (current_instr == arm7_9-arm_bkpt)
if ((retval = target_write_memory(target,
breakpoint-address, 4,
1, breakpoint-orig_instr)) != ERROR_OK)
{
return retval;
}
i.e. current_instr is transformed to _host_ endianess prior to
comparison via target_buffer_get_u32() function.
Finally, the patch for MIPS should consist of only adding this missing line.
BR,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Current master branch state
On Fri, Jul 1, 2011 at 9:59 PM, Spencer Oliver s...@spen-soft.co.uk wrote: On Jul 1, 2011 7:34 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: Hmm.. Reseting hard to one beyond HEAD seems to workaround the prob : git-reset --hard HEAD~1 Make sure you do a bootstrap and configure. I have tested on the usual platforms and all is working here. Hi Spencer, I did bootstrap before. I always do : make clean distclean ./bootstrap to have proper environment. I tested several times, only the last commit does not work for me. It should maybe noted that I have Debian system with known bug (https://bugs.launchpad.net/debian/+source/libmcrypt/+bug/253991) : [ddraskovic@marx:/home/ddraskovic/sandbox/github/openocd]./bootstrap + aclocal /usr/share/aclocal/libmcrypt.m4:17: warning: underquoted definition of AM_PATH_LIBMCRYPT /usr/share/aclocal/libmcrypt.m4:17: run info '(automake)Extending aclocal' /usr/share/aclocal/libmcrypt.m4:17: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal + libtoolize --automake --copy + autoconf + autoheader + automake --gnu --add-missing --copy Setting up submodules Submodule path 'jimtcl': checked out '411e92fea9621630eb350e0c2bb43543e553b84f' Bootstrap complete. Quick build instructions: ./configure --enable-maintainer-mode [ddraskovic@marx:/home/ddraskovic/sandbox/github/openocd] But this bug is otherwise harmless, and worked before for me, and works still until the last merge. On the origin/maser HEAD, ./configure explodes like this : config.status: creating src/flash/nor/Makefile config.status: creating src/flash/nand/Makefile config.status: creating src/pld/Makefile config.status: creating doc/Makefile config.status: creating config.h config.status: executing depfiles commands === configuring in jimtcl (/home/ddraskovic/sandbox/github/openocd/jimtcl) configure: running /bin/sh ./configure.gnu '--prefix=/usr/local' '--enable-maintainer-mode' '--enable-ft2232-libftdi' 'CFLAGS= -I/home/ddraskovic/libftdi/include' 'LDFLAGS= -L/home/ddraskovic/libftdi/lib' --cache-file=/dev/null --srcdir=. Host System...i686-pc-linux-gnu Build System...i686-pc-linux-gnu C compiler...ccache cc -I/home/ddraskovic/libftdi/include C++ compiler...ccache c++ -I/home/ddraskovic/libftdi/include Checking for stdlib.h...ok Error: Unknown option --ft2232-libftdi Try: 'configure --help' for options configure: error: ./configure.gnu failed for jimtcl [1]21931 exit 1 ./configure --enable-maintainer-mode --enable-ft2232-libftdi BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD][MIPS32][PATCH] Fix soft breakpoint unsetting endianess
On Fri, Jul 1, 2011 at 7:34 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: Seems like you're on top of it! BTW, target_write_memory() and target_write_u32() is not the luckiest function name choice, as they have different behaviors... Can you prepare a patch that fixes naming and documents the behaviour? This is indeed a source of confusion and you may find bugs in OpenOCD just going over each invocation. Boring tedious work, but probably no more than an hour... Hi Øyvind, Firstly I would like to see if I got all the git branching stuff OK and that I have proper environment to continue working on. If the first pull request passes OK, I will finish my work on more complicated MIPS issue (cache syncronization), and then open discussion about this confusing function naming, so that we can find the best way to handle this naming issue. For now it holds the water, especially when we demystified it a little bit now... BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [OpenOCD][PULL Request][MIPS32] Fix soft breakpoint endianess handling
Dear Øyvind, The following changes since commit f6026a8295faf158e500a7acb9884f9fd4c30ad1: Spencer Oliver (1): jimtcl: update to 0.71 based release are available in the git repository at: git://github.com/drasko/openocd.git master Drasko DRASKOVIC (1): mips_m4k : Fix soft breakpoint endianess handling src/target/mips_m4k.c |8 1 files changed, 8 insertions(+), 0 deletions(-) Best regards, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Please welcome Jean-Christophe as release manager
Great news. Bonne chance JCP ! BR, Drasko 2011/6/30 Tomek CEDRO tomek.ce...@gmail.com: On Thu, Jun 30, 2011 at 6:23 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: Please give a warm welcome to Jean-Christophe as the release manager. Hello Jean-Christophe :-) You have been long awaited! Good luck and have fun with OpenOCD project! :-) Best regards! :-) Tomek Cedro -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD][MIPS32][PATCH] Fix soft breakpoint unsetting endianess
Hi all,
any responses on this ?
MIPS32 target is currently broken for soft breakpoint handling :
reading of the original instruction swaps the bytes, so
breakpoint-orig_instr is badly recorded. Reading of the current
instruction does this also, so we never read MIPS32_SDBBP needed for
OpenOCD to break.
I am crafting the complete patch that will fix these issues, but I
would like to here some responses...
BR,
Drasko
On Wed, Jun 29, 2011 at 2:47 PM, Drasko DRASKOVIC
drasko.drasko...@gmail.com wrote:
Hi all,
I have additional questions about target_read_memory() and
target_read_u32() used to set/unset breakpoints.
I can see that target_read_memory() simply calls
mips_m4k_write_memory() and since I have big endian MIPS target, bytes
are not swapped.
However, target_read_u32(), besides calling target_read_memory(), it
also swappes the bytes returned (I pasetd the function definition
below).
Would that mean that all the time when we want to read 4 or 2 bytes
values, like breakpoints instructions, we must *always* use
target_read_u32 and target_read_u16, and never target_read_memory() ?
If answer is yes, I'll change rest of the file where this should be
done, and post more complete patch.
Best regards,
Drasko
int target_read_u32(struct target *target, uint32_t address, uint32_t *value)
{
uint8_t value_buf[4];
if (!target_was_examined(target))
{
LOG_ERROR(Target not examined yet);
return ERROR_FAIL;
}
int retval = target_read_memory(target, address, 4, 1, value_buf);
if (retval == ERROR_OK)
{
*value = target_buffer_get_u32(target, value_buf);
LOG_DEBUG(address: 0x%8.8 PRIx32 , value: 0x%8.8 PRIx32 ,
address,
*value);
}
else
{
*value = 0x0;
LOG_DEBUG(address: 0x%8.8 PRIx32 failed,
address);
}
return retval;
}
On Mon, Jun 27, 2011 at 8:31 PM, Drasko DRASKOVIC
drasko.drasko...@gmail.com wrote:
Hi all,
I've noticed that unsetting soft breaks is currently broken on BE MIPS
4Kc targets.
This patch fix it by using target_read_u32() and target_read_u16()
instead of target_read_memory().
BR,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD][MIPS32][PATCH] Fix soft breakpoint unsetting endianess
On Thu, Jun 30, 2011 at 5:14 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: Perhaps you would like to volunteer as a MIPS submaintainer? :-) Hi Øyvind, I would be honored :). It should be noted that I do not have enormous knowledge of MIPS32 architecture, but I am in the process of learning and my day-to-day job is and will be based on this architecture. That would say that I will be focused on OpenOCD on this architecture daily. I am currently porting Linux kernel to MIPS32 based SoC and I am fixing OpenOCD code on the way, seeing some issues that I could not see before when I did JTAG testing with simpler programs. Seeing that currently does not seem to be a lot of OpenOCD hackers around this arch (I've got this impression by seeing responses to some of discussions I started), I would gladly take responsibilities of submaintainer and try to consolidate MIPS32 EJTAG code, at least until someone more competent volunteers to take up this role. Best regards, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [OpenOCD][MIPS32]Cache non-coherent - sync missing
Hi all, Currently for MIPS32 target we do mem writes using mips32_pracc_write_mem() function. And this works fine, but only untill kseg0 memory segment is uncached (i.e. K0 field of the Config Register (CP0 Register 16, Select 0) are set to 0x2, which is a reset value). However, this memory region is cachable, and it is it's primary use (in difference to kseg1, which is always uncached). The moment I tried to turn on cache, using Cacheable, noncoherent, write-back, write allocate set-up (0x3 in the K0 field), I saw that all data writes are left in cache. Linux turns on these caches by default - and this is quite normal, and a proper way to do. From this point on OpenOCD debugging via GDB is unusable : writing breakpoint instruction will happily live in your D$ and will never be seen by CPU, who will keep executing instructions from I$ (not coherent from this moment on). As done for all architectures before, proper way to handle write on a cached reginos is folowing : 1) do your write 2) clean and drain D$, so that data and instructions you wrote will end up in RAM (you do not necessarily have to invalidate it - it will be coherent from this point on) 3) invalidate I$, so that CPU will pick up newly written instructions from RAM, and not continue executing it's I$ (which is btw. no longer coherent) Now, in case of EJTAG communication implementation in mips32_pracc.c this is not a simple thing to implement. I am currently adding missing opcodes and trying to craft a miniprogram based on bytecode, similar to existing stuff. It is quite a headache to debug, but I previously spent a lot of time on demistfying this implementation and wrote one draft doc to this list (more complete doc is on the way, and will be contributed as a separate patch). In the MIPS official doc MD00086 (MIPS32™ Architecture For Programmers Volume II: The MIPS32™ Instruction Set), we can find interesting procedure to synchronize caches using synci (Synchronize Caches to Make Instruction Writes Effective) instruction. I am referencing here Programming Notes given in the chapter describing this instruction (page 287). Based on this, I re-implemented this procedure to the detail in bytecode minirpogram and I have first working draft. Here is what I tested : 1) I put a soft breakpoint on start_kernel() just after image download. It is after-reset state, and kseg0 is uncached (by default) 2) I do continue in GDB and program hits this breakpoint. It should, it is well in the memory (and copied to I$) 3) On further resume, OpenOCD will replace this breakpoint with original instruction that lived on this addr. That will, however, be put in D$ and never reflected in I$ upon resume 4) CPU keeps hitting soft breakpoint, because it is what it really sees in I$ - original instruction has never been really brought back ! I think that synci is a good candidate for this fix, rather than explicitly using cache instructions. I give a reference to similar discussion : http://comments.gmane.org/gmane.linux.ports.mips.general/4267. Some nice information can also be found in See Mips Run book (http://www.scribd.com/doc/39654922/161/Synci-Cache-Management-for-Instruction-Writers). Normally, it should do exactly what is needed - clean D$ and invalidate I$ at the same time. As I said, I did some fixes and OpenOCD started to work correctly even on cached regions, so I can proceeded debugging Linux kernel with it). I will post the patch soon, just after I clean the code and test it a little bit more. In the meantime, I would like to hear some observations like : Did anyone else experienced this problem ? Would synci be better than cache instruction ? What happens with FASTDATA - should we clean after these bulk loads too ? Best regards, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD][MIPS32][PATCH] Fix soft breakpoint unsetting endianess
OK,
I am staring to get this. After looking more thoughly how it is
implementer in other architectures, I think that :
1) We use target_write_u32() to write instructions defined on the host
(in host endianess) to target. This function transform MIPS32_SDBBP
from host (usualy PC with LE) to good endianess on the target
2) target_read_memory() is needed to get to the host the bytes of
original instruction in *target* endianes. Comparing these bytes with
something on host makes no sense if not host and target differ in
endianess and read bytes are not adapted before comparisons with
target_buffer_get_u32(target, (uint8_t *)current_instr), and this is
what is currently missing in MIPS32 implementation
3) Whenever target_read_memory() to get original instruction, then
target_write_memory() must be used to write it back. Pairing
target_read_memory() with target_write_u32() is wrong, as first will
preserve target endianess, and second will do transformation from host
endiness to target endiness. Suppose that target is BE and host is LE
- then target_read_memory() will get BE bytes to the host, and
target_write_u32() will take these bytes, consider them as LE (because
it thinks that it is some host's data) and flip them again to be BE.
However, target_write_memory() will think that these bytes to be
written are already BE (because it will know that it is target, and
not host's data - just temporarily lives on the host in
breakpoint-orig_instr), and will not flip them.
So, with this in mind, I will try to add just a missing line and do
some tests tomorrow.
BTW, target_write_memory() and target_write_u32() is not the luckiest
function name choice, as they have different behaviors...
BR,
Drasko
On Wed, Jun 29, 2011 at 2:47 PM, Drasko DRASKOVIC
drasko.drasko...@gmail.com wrote:
Hi all,
I have additional questions about target_read_memory() and
target_read_u32() used to set/unset breakpoints.
I can see that target_read_memory() simply calls
mips_m4k_write_memory() and since I have big endian MIPS target, bytes
are not swapped.
However, target_read_u32(), besides calling target_read_memory(), it
also swappes the bytes returned (I pasetd the function definition
below).
Would that mean that all the time when we want to read 4 or 2 bytes
values, like breakpoints instructions, we must *always* use
target_read_u32 and target_read_u16, and never target_read_memory() ?
If answer is yes, I'll change rest of the file where this should be
done, and post more complete patch.
Best regards,
Drasko
int target_read_u32(struct target *target, uint32_t address, uint32_t *value)
{
uint8_t value_buf[4];
if (!target_was_examined(target))
{
LOG_ERROR(Target not examined yet);
return ERROR_FAIL;
}
int retval = target_read_memory(target, address, 4, 1, value_buf);
if (retval == ERROR_OK)
{
*value = target_buffer_get_u32(target, value_buf);
LOG_DEBUG(address: 0x%8.8 PRIx32 , value: 0x%8.8 PRIx32 ,
address,
*value);
}
else
{
*value = 0x0;
LOG_DEBUG(address: 0x%8.8 PRIx32 failed,
address);
}
return retval;
}
On Mon, Jun 27, 2011 at 8:31 PM, Drasko DRASKOVIC
drasko.drasko...@gmail.com wrote:
Hi all,
I've noticed that unsetting soft breaks is currently broken on BE MIPS
4Kc targets.
This patch fix it by using target_read_u32() and target_read_u16()
instead of target_read_memory().
BR,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [OpenOCD][MIPS32][PATCH] Fix soft breakpoint unsetting endianess
Hi all,
I have additional questions about target_read_memory() and
target_read_u32() used to set/unset breakpoints.
I can see that target_read_memory() simply calls
mips_m4k_write_memory() and since I have big endian MIPS target, bytes
are not swapped.
However, target_read_u32(), besides calling target_read_memory(), it
also swappes the bytes returned (I pasetd the function definition
below).
Would that mean that all the time when we want to read 4 or 2 bytes
values, like breakpoints instructions, we must *always* use
target_read_u32 and target_read_u16, and never target_read_memory() ?
If answer is yes, I'll change rest of the file where this should be
done, and post more complete patch.
Best regards,
Drasko
int target_read_u32(struct target *target, uint32_t address, uint32_t *value)
{
uint8_t value_buf[4];
if (!target_was_examined(target))
{
LOG_ERROR(Target not examined yet);
return ERROR_FAIL;
}
int retval = target_read_memory(target, address, 4, 1, value_buf);
if (retval == ERROR_OK)
{
*value = target_buffer_get_u32(target, value_buf);
LOG_DEBUG(address: 0x%8.8 PRIx32 , value: 0x%8.8 PRIx32 ,
address,
*value);
}
else
{
*value = 0x0;
LOG_DEBUG(address: 0x%8.8 PRIx32 failed,
address);
}
return retval;
}
On Mon, Jun 27, 2011 at 8:31 PM, Drasko DRASKOVIC
drasko.drasko...@gmail.com wrote:
Hi all,
I've noticed that unsetting soft breaks is currently broken on BE MIPS
4Kc targets.
This patch fix it by using target_read_u32() and target_read_u16()
instead of target_read_memory().
BR,
Drasko
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [OpenOCD][MIPS32][PATCH] Fix soft breakpoint unsetting endianess
Hi all,
I've noticed that unsetting soft breaks is currently broken on BE MIPS
4Kc targets.
This patch fix it by using target_read_u32() and target_read_u16()
instead of target_read_memory().
BR,
Drasko
From 8a24b7dc8db8a8b8193030ee210a9964792a0dc5 Mon Sep 17 00:00:00 2001
From: Drasko DRASKOVIC drasko.drasko...@gmail.com
Date: Mon, 27 Jun 2011 20:15:04 +0200
Subject: [PATCH] [MIPS32] Fix soft breakpoint unsetting endianess
In order to verify that curent instruction is indeed BP,
we compare it's read value to MIPS32_SDBBP. For this comparison
to work, we have to use read function that correctly handles endianess
differences between the host and the target (i.e. use target_read_u32()
instead of target_read_memory()).
---
src/target/mips_m4k.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/target/mips_m4k.c b/src/target/mips_m4k.c
index 03c9969..840eb3b 100644
--- a/src/target/mips_m4k.c
+++ b/src/target/mips_m4k.c
@@ -611,8 +611,7 @@ static int mips_m4k_unset_breakpoint(struct target *target,
uint32_t current_instr;
/* check that user program has not modified breakpoint instruction */
- if ((retval = target_read_memory(target, breakpoint-address, 4, 1,
- (uint8_t*)current_instr)) != ERROR_OK)
+ if ((retval = target_read_u32(target, breakpoint-address, current_instr)) != ERROR_OK)
{
return retval;
}
@@ -630,8 +629,7 @@ static int mips_m4k_unset_breakpoint(struct target *target,
uint16_t current_instr;
/* check that user program has not modified breakpoint instruction */
- if ((retval = target_read_memory(target, breakpoint-address, 2, 1,
- (uint8_t*)current_instr)) != ERROR_OK)
+ if ((retval = target_read_u16(target, breakpoint-address, current_instr)) != ERROR_OK)
{
return retval;
}
--
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
Hi Øyvind, thanks for the merge. Just for the reference, I double-checked the issue on bunutils mailing lists : http://sourceware.org/ml/binutils/2011-06/msg00252.html From this little discussion I conclude that this patch is good, and that will fix OABI linker issues (and potentially some other architectures besides ARM). In any case, should make load addr handling more robust. BR, Drasko On Fri, Jun 24, 2011 at 11:01 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: Merged. Thanks! -- Ø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/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [doc] MIPS EJTAG Communication Demystified
On Thu, Apr 14, 2011 at 4:02 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Thu, Apr 14, 2011 at 3:53 PM, Tomek CEDRO tomek.ce...@gmail.com wrote: On Thu, Apr 14, 2011 at 11:52 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: If you look at the OpenOCD documentation, you'll find that Zach Welch did write up development documentation and that it's in git repository. Hi Øyvind, I've taken a look into this set of Doxygen documents, but I still don't get - why are not they build during the build process of OpenOCD ? I do not have HTMLs created... Should not something like this http://openocd.berlios.de/doc/doxygen/html/index.html be produced locally, once we do a build build of OpenOCD ? Also, I noticed here : http://openocd.berlios.de/doc/doxygen/html/patchguide.html which maybe should be completely updated with your HACKING info (which is extremly usefull, btw.) Best regards, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [doc] MIPS EJTAG Communication Demystified
On Thu, Jun 23, 2011 at 12:46 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Thu, Jun 23, 2011 at 12:21 PM, Drasko DRASKOVIC drasko.drasko...@gmail.com wrote: On Thu, Apr 14, 2011 at 4:02 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: On Thu, Apr 14, 2011 at 3:53 PM, Tomek CEDRO tomek.ce...@gmail.com wrote: On Thu, Apr 14, 2011 at 11:52 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: If you look at the OpenOCD documentation, you'll find that Zach Welch did write up development documentation and that it's in git repository. Hi Øyvind, I've taken a look into this set of Doxygen documents, but I still don't get - why are not they build during the build process of OpenOCD ? I do not have HTMLs created... Should not something like this http://openocd.berlios.de/doc/doxygen/html/index.html be produced locally, once we do a build build of OpenOCD ? make doxygen? Yeap, this worked, and created doxygen dir inside openocd with all HTMLs. I grepped before for .txt files, but could not find where they were referenced... Also, I noticed here : http://openocd.berlios.de/doc/doxygen/html/patchguide.html which maybe should be completely updated with your HACKING info (which is extremly usefull, btw.) Patch gladly accepted! :-) I asked because I want to add my MIPS EJTAG doc, and I will use this opportunity to do some work on this documentation. Hopefully patches are to follow soon. BR, Drasko ___ 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 8:09 PM, Drasko DRASKOVIC
drasko.drasko...@gmail.com wrote:
On Tue, Jun 21, 2011 at 7:35 PM, Michael Schwingen
rincew...@discworld.dascon.de wrote:
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.
Hi Øyvind,
as per discussion led, please find the patch attached, with
corrections based on Michaels suggestions and deeper study of BFD's
implementation.
Basically, this patch re-implements this peice of code from BFD's elf.c :
/* 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;
which looks if :
1) All (not just one) segments have p_paddr equal to zero (which hints
either p_paddr not initialized or deliberatly initialized to zero,
like some ARM linkers do in otder to repect ARM ELF specification)
2) If this is the case, is there more than one loadable segment
(because we can and we *must* allow one loadable segment at physical
(lma) address 0x0 - this is perfectly valid)
3) If there is however more than one p_paddr zeroed and loadable
segment, we suspect that things are not right and we go for p_vaddr
This will make OpenOCD more conistent to GDB solution and correct the
bug present for ARM ELF compliant linkers.
Best regards,
Drasko
From ee79560a904746536eff2f284c192d45853ebc4a Mon Sep 17 00:00:00 2001
From: Drasko DRASKOVIC drasko.drasko...@gmail.com
Date: Wed, 22 Jun 2011 12:45:21 +0200
Subject: [PATCH] Fix load_image for ELF with all p_paddr set to zero
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 *all*
p_paddr == 0. Basically, this patch re-implements the approach present in
BDF's elf.c, which is used by GDB also (so that we can be consistent).
---
src/target/image.c | 26 +-
1 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/src/target/image.c b/src/target/image.c
index 454fc6c..21ce11f 100644
--- a/src/target/image.c
+++ b/src/target/image.c
@@ -396,6 +396,7 @@ static int image_elf_read_headers(struct image *image)
size_t read_bytes;
uint32_t i,j;
int retval;
+ uint32_t nload,load_to_vaddr=0;
elf-header = malloc(sizeof(Elf32_Ehdr));
@@ -471,6 +472,26 @@ static int image_elf_read_headers(struct image *image)
for (i = 0;i elf-segment_count;i++)
if ((field32(elf, elf-segments[i].p_type) == PT_LOAD) (field32(elf, elf-segments[i].p_filesz) != 0))
image-num_sections++;
+
+ /**
+ * some ELF linkers produce binaries with *all* the program header
+ * p_paddr fields zero (there can be however one loadable segment
+ * that has valid physical address 0x0).
+ * If we have such a binary with more than
+ * one PT_LOAD header, then use p_vaddr instead of p_paddr
+ * (ARM ELF standard demands p_paddr = 0 anyway, and BFD
+ * library uses this approach to workaround zero-initialized p_paddrs
+ * when obtaining lma - look at elf.c of BDF)
+ */
+ for (nload = 0, i = 0; i elf-segment_count; i++)
+ if (elf-segments[i].p_paddr != 0)
+ break;
+ else if ((field32(elf, elf-segments[i].p_type) == PT_LOAD) (field32(elf, elf-segments[i].p_memsz) != 0))
+ ++nload;
+
+ if (i = elf-segment_count nload 1)
+ load_to_vaddr = 1;
+
/* alloc and fill sections array with loadable segments */
image-sections = malloc(image-num_sections * sizeof(struct imagesection));
for (i = 0,j = 0;i elf-segment_count;i++)
@@ -478,7 +499,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 (load_to_vaddr)
+image-sections[j].base_address = field32(elf,elf-segments[i].p_vaddr);
+ else
+image-sections[j].base_address = field32(elf,elf-segments[i].p_paddr);
image-sections[j].private = elf-segments[i
Re: [Openocd-development] Request for review: driver for Keil ULINK
Wow! Great work, Martin. BR, Drasko ___ 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] [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] [PATCH] Implementation of a remote bitbang jtag driver
On Wed, Jun 15, 2011 at 6:04 PM, Uhler, Richard ruh...@qualcomm.com wrote: This has been very useful to us Hi Richard, what is the exact benefit of this driver ? I.e. when it should be used and for what purposes - can you give me some example ? Best regards, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Peter Stuge is now an OpenOCD maintainer
On Fri, Jun 10, 2011 at 8:10 AM, Xiaofan Chen xiaof...@gmail.com wrote: On Fri, Jun 10, 2011 at 1:25 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: I'm very pleased to announce Peter Stuge as an OpenOCD maintainer. Congrats, nice news for the community. Good luck Peter. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
