On Thu, Dec 22, 2011 at 1:21 PM, Øyvind Harboe 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-developmen
/* 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,
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
+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 directi
On Fri, Aug 12, 2011 at 11:31 AM, Øyvind Harboe 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
On Fri, Aug 12, 2011 at 11:29 AM, Øyvind Harboe 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 lo
One more nag...
BR,
Drasko
-- Forwarded message --
From: Drasko DRASKOVIC
Date: Tue, Jul 26, 2011 at 11:59 AM
Subject: [OpenOCD][PULL Request][MIPS32] Fixed single byte memory write
To: Openocd-Dev
The following changes since commit 2cdb7e8dfb0ce818377db2d30d179423c6cc
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
Date: Thu, Jul 7, 2011 at 7:27 PM
Subject: [OpenOCD][PULL Request
On Fri, Aug 12, 2011 at 12:08 AM, Øyvind Harboe 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.
C
On Thu, Aug 11, 2011 at 12:42 AM, Mahr, Stefan wrote:
> Hi Drasko
>
>
>> Solution is more common, but the commit history is not clearer. You
>> are fixing several bugs in one patch...
>
> Serveral? Just one and a half :-)
> However, I stripped the alignment fix to a seperate patch file. Please fin
On Wed, Aug 10, 2011 at 11:25 AM, Tormod Volden wrote:
> On Wed, Aug 10, 2011 at 10:09 AM, Drasko DRASKOVIC
> wrote:
>> On Wed, Aug 10, 2011 at 6:53 AM, Øyvind Harboe
>> wrote:
>>> I am genuinely interested in hearing the pros and cons of rebasing
&g
On Wed, Aug 10, 2011 at 6:53 AM, Øyvind Harboe 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
On Sat, Jul 30, 2011 at 4:26 AM, Mahr, Stefan 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
On Tue, Aug 9, 2011 at 11:32 PM, Øyvind Harboe 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 r
On Tue, Aug 9, 2011 at 11:23 PM, Øyvind Harboe 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
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
wrote:
> On Mon, Jul 11, 2011 at 1:50 PM, Mahr, Stefan
> wrote:
>>>>&
On Mon, Jul 11, 2011 at 1:50 PM, Mahr, Stefan 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
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
Date: Tue, Jul
Hi all,
as per Øyvind's request I am re-sending this outstanding pull request.
BR,
Drasko
-- Forwarded message --
From: Drasko DRASKOVIC
Date: Thu, Jul 7, 2011 at 7:27 PM
Subject: [OpenOCD][PULL Request][MIPS32] CP0 coprocessor manipulation
and cache synchronization routin
On Thu, Jul 28, 2011 at 5:16 PM, Spencer Oliver 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 se
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
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
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
17 00:00:00 2001
From: Drasko DRASKOVIC
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
On Mon, Jul 11, 2011 at 1:43 PM, Drasko DRASKOVIC
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
>
On Mon, Jul 11, 2011 at 1:41 PM, Mahr, Stefan 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
On Mon, Jul 11, 2011 at 1:30 PM, Øyvind Harboe wrote:
> On Mon, Jul 11, 2011 at 1:10 PM, Drasko DRASKOVIC
> wrote:
>> On Mon, Jul 11, 2011 at 12:52 PM, Øyvind Harboe
>> wrote:
>>> On Mon, Jul 11, 2011 at 12:45 PM, Drasko DRASKOVIC
>>> wrote:
>>&
On Mon, Jul 11, 2011 at 12:52 PM, Øyvind Harboe wrote:
> On Mon, Jul 11, 2011 at 12:45 PM, Drasko DRASKOVIC
> wrote:
>> On Mon, Jul 11, 2011 at 11:53 AM, Øyvind Harboe
>> wrote:
>>> I think there is a fundamental misunderstanding about JTAG
>>> and Op
On Mon, Jul 11, 2011 at 11:53 AM, Øyvind Harboe 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 w
On Mon, Jul 11, 2011 at 12:31 PM, Øyvind Harboe wrote:
> On Mon, Jul 11, 2011 at 12:17 PM, Drasko DRASKOVIC
> wrote:
>> On Mon, Jul 11, 2011 at 7:31 AM, Øyvind Harboe
>> wrote:
>>> Now a sequence of 8 bit words happens to be identical to
>>> little endian re
On Mon, Jul 11, 2011 at 7:31 AM, Øyvind Harboe 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...
BR,
Drasko
On Mon, Jul 11, 2011 at 11:10 AM, Mahr, Stefan wrote:
>>> buf_get_u32:
>>> return (((uint32_t)buffer[3]) << 24) |
>>> (((uint32_t)buffer[2]) << 16) |
>>> (((uint32_t)buffer[1]) << 8) |
>>> (((uint32_t)buffer[0]) <<
On Sat, Jul 9, 2011 at 10:44 AM, Mahr, Stefan 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:
>
On Fri, Jul 8, 2011 at 6:30 PM, Mahr, Stefan 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_imp
On Fri, Jul 8, 2011 at 4:30 PM, Mahr, Stefan 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
On Fri, Jul 8, 2011 at 4:23 PM, Mahr, Stefan 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 m
On Fri, Jul 8, 2011 at 2:05 PM, Mahr, Stefan 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 ?
On Fri, Jul 8, 2011 at 4:10 PM, Mahr, Stefan 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 g
On Fri, Jul 8, 2011 at 3:08 PM, Andreas Fritiofson
wrote:
>
>
> On Fri, Jul 8, 2011 at 1:26 PM, Drasko DRASKOVIC
> wrote:
>>
>> On Fri, Jul 8, 2011 at 1:19 PM, Andreas Fritiofson
>> wrote:
>> > I looked briefly at the memory read functions in mips32_dmaacc
On Fri, Jul 8, 2011 at 2:05 PM, Mahr, Stefan 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 sw
On Fri, Jul 8, 2011 at 1:54 PM, Mahr, Stefan 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
On Fri, Jul 8, 2011 at 1:38 PM, Mahr, Stefan 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 un
On Fri, Jul 8, 2011 at 1:19 PM, Andreas Fritiofson
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 m
On Fri, Jul 8, 2011 at 1:20 PM, Andreas Fritiofson
wrote:
>
>
> On Fri, Jul 8, 2011 at 1:17 PM, Drasko DRASKOVIC
> wrote:
>>
>> I am just wandering, would :
>> t32 = *(uint32_t*)((void *)&buffer[i]);
>> quite the compiler ;)
>
> Yes probably, bu
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
wrote:
> On Fri, Jul 8, 2011 at 1:13 PM, Øyvind Harboe wrote:
>>> that casts void* buf to uint32_t*.
>>
>> Actua
On Fri, Jul 8, 2011 at 1:13 PM, Øyvind Harboe 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 t
On Wed, Jul 6, 2011 at 2:42 PM, Mahr, Stefan 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
On Fri, Jul 8, 2011 at 12:52 PM, Øyvind Harboe 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
O
On Fri, Jul 8, 2011 at 12:42 PM, Øyvind Harboe 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
On Fri, Jul 8, 2011 at 12:35 PM, Øyvind Harboe wrote:
> On Fri, Jul 8, 2011 at 12:31 PM, Drasko DRASKOVIC
> wrote:
>> On Fri, Jul 8, 2011 at 12:14 PM, Øyvind Harboe
>> wrote:
>>>> There is no particular need to cast this into uint8_t* and this can be
>>>
;> warning ?
>
> git revert 2482244b0788c007dd789c2
I reverted this commit :
commit e442054bf9acf70cb2b9b2ac297cba2b15df5642
Author: Drasko DRASKOVIC
Date: Fri Jul 8 12:32:42 2011 +0200
Revert "mips4k: fix big-endian hosts and host alignment problems"
This reverts commit 2482244b0788
On Fri, Jul 8, 2011 at 12:14 PM, Øyvind Harboe 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 plac
On Thu, Jul 7, 2011 at 11:52 AM, Øyvind Harboe wrote:
> 011/7/7 Mahr, Stefan :
>> Ø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
On Fri, Jul 8, 2011 at 11:47 AM, Øyvind Harboe wrote:
> On Fri, Jul 8, 2011 at 11:43 AM, Drasko DRASKOVIC
> wrote:
>> On Thu, Jul 7, 2011 at 11:58 AM, Øyvind Harboe
>> wrote:
>>> Note that this problem has cropped up many places over the OpenOCD
>>> code. I&
On Thu, Jul 7, 2011 at 11:58 AM, Øyvind Harboe 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
On Thu, Jul 7, 2011 at 10:41 PM, Mahr, Stefan 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
On Thu, Jul 7, 2011 at 11:04 PM, Michael Schwingen
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_mem3
On Thu, Jul 7, 2011 at 12:59 AM, Andreas Fritiofson
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 happe
On Wed, Jul 6, 2011 at 6:35 PM, Mahr, Stefan 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_pr
On Thu, Jul 7, 2011 at 7:48 PM, Michael Schwingen
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 inte
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 a
On Wed, Jul 6, 2011 at 9:32 PM, Drasko DRASKOVIC
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
&
On Thu, Jul 7, 2011 at 9:58 AM, openOCD.fseu
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 intelli
On Wed, Jul 6, 2011 at 9:34 PM, Øyvind Harboe 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
shed I'll post PULL
request from my MIPS github branch.
BR,
Drasko
From 9b5e82b2df6a3de4b8a5e178ffd5bd2c0e8fbbd3 Mon Sep 17 00:00:00 2001
From: Drasko DRASKOVIC
Date: Tue, 5 Jul 2011 17:20:33 +0200
Subject: [PATCH] mips32: Sync Caches to Make Instr Writes Effective
Pprogram that loads another
On Wed, Jul 6, 2011 at 9:16 PM, Øyvind Harboe 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
c
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 treat
On Wed, Jul 6, 2011 at 12:45 AM, Drasko DRASKOVIC
wrote:
> On Wed, Jul 6, 2011 at 12:33 AM, Igor Skochinsky wrote:
>> Hello Drasko,
>>
>> Wednesday, July 6, 2011, 12:00:11 AM, you wrote:
>>
>>>> DD> On the first look, this can be accomplished by readin
On Wed, Jul 6, 2011 at 1:57 PM, Spencer Oliver wrote:
> On 6 July 2011 12:36, Luc ANTOLINOS wrote:
>> On 6 July 2011 13:17, Spencer Oliver 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
On Wed, Jul 6, 2011 at 1:36 PM, Luc ANTOLINOS wrote:
> On 6 July 2011 13:17, Spencer Oliver 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 'WF
On Wed, Jul 6, 2011 at 1:40 PM, Andreas Fritiofson
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 A
On Wed, Jul 6, 2011 at 1:08 PM, Luc ANTOLINOS wrote:
> On 6 July 2011 12:37, Drasko DRASKOVIC 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
On Wed, Jul 6, 2011 at 11:02 AM, Luc ANTOLINOS 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
On Wed, Jul 6, 2011 at 12:33 AM, Igor Skochinsky 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 obt
2011/7/5 Igor Skochinsky :
> Hello Drasko,
>
> Tuesday, July 5, 2011, 7:01:44 PM, you wrote:
>
> DD> On Tue, Jul 5, 2011 at 6:17 PM, Spencer Oliver
> 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
On Tue, Jul 5, 2011 at 6:17 PM, Spencer Oliver 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, bu
On Tue, Jul 5, 2011 at 5:32 PM, Spencer Oliver 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
On Thu, Jun 30, 2011 at 6:25 PM, Drasko DRASKOVIC
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 existi
On Mon, Jul 4, 2011 at 1:23 PM, Drasko DRASKOVIC
wrote:
> On Mon, Jul 4, 2011 at 1:12 PM, Spencer Oliver wrote:
>> On 2 July 2011 15:35, Drasko DRASKOVIC wrote:
>>> On Fri, Jul 1, 2011 at 11:37 PM, Spencer Oliver
>>> wrote:
>>>> On 01/07/2011 22:22, Dras
On Mon, Jul 4, 2011 at 6:18 PM, Øyvind Harboe 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 du
On Mon, Jul 4, 2011 at 1:12 PM, Spencer Oliver wrote:
> On 2 July 2011 15:35, Drasko DRASKOVIC wrote:
>> On Fri, Jul 1, 2011 at 11:37 PM, Spencer Oliver wrote:
>>> On 01/07/2011 22:22, Drasko DRASKOVIC wrote:
>>> could you send the log of the previous working version
).
Here is a small patch for both ARM and MIPS that fix this issue (bot
32 and 16-bit instructions should be treated consistently)
BR,
Drasko
The following changes since commit bad3ee87ac170150a9a8a72c731aa631a1ad8cf5:
Drasko DRASKOVIC (1):
mips_m4k : 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
On Fri, Jul 1, 2011 at 7:34 AM, Øyvind Harboe 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?
On Fri, Jul 1, 2011 at 9:59 PM, Spencer Oliver wrote:
> On Jul 1, 2011 7:34 PM, "Drasko DRASKOVIC"
> wrote:
>>
>> Hmm.. Reseting hard to one beyond HEAD seems to workaround the prob :
>>
>> > git-reset --hard HEAD~1
>>
>
> Make sure you do
On Fri, Jul 1, 2011 at 7:29 AM, Øyvind Harboe wrote:
> Looks good to me!
>
> Please put it into your mips branch and post a pull request once
> everything is ready. I know you were working on something else too.
Hi Øyvind,
I forked a branch from current master HEAD and pushed all the code to
my
On Fri, Jul 1, 2011 at 7:32 AM, Øyvind Harboe 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 tar
:26 PM, Drasko DRASKOVIC
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.
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
On Fri, Jul 1, 2011 at 3:13 PM, Nils Faerber
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 copyri
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 h
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
wrote:
>
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
On Thu, Jun 30, 2011 at 5:14 PM, Øyvind Harboe 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
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
wrote:
> Hi all,
> I have additional questions about target_read_memory() and
> target_read_u32() used
Great news.
Bonne chance JCP !
BR,
Drasko
2011/6/30 Tomek CEDRO :
> On Thu, Jun 30, 2011 at 6:23 AM, Øyvind Harboe
> 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 OpenOC
LOG_DEBUG("address: 0x%8.8" PRIx32 " failed",
address);
}
return retval;
}
On Mon, Jun 27, 2011 at 8:31 PM, Drasko DRASKOVIC
wrote:
> Hi all,
> I've noticed that unsetting soft breaks is currently broken on BE MIPS
> 4Kc targets.
>
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 DRAS
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
On Thu, Jun 23, 2011 at 12:46 PM, Øyvind Harboe wrote:
> On Thu, Jun 23, 2011 at 12:21 PM, Drasko DRASKOVIC
> wrote:
>> On Thu, Apr 14, 2011 at 4:02 PM, Øyvind Harboe
>> wrote:
>>> On Thu, Apr 14, 2011 at 3:53 PM, Tomek CEDRO wrote:
>>>> On Thu,
1 - 100 of 276 matches
Mail list logo
