Simplify hexify() and do not longer use 0 as special case for the
parameter 'count' to determine the string length of the binary input.
Instead, use strlen() outside of the function if needed.
Additionally, fix the return value and return the length of the
converted string. The old function always returned 2 * count.
Also, use more appropriate data types for the function parameters and
add a small documentation.
Change-Id: I133a8ab786b8f7c1296afcaf9c0a0b43881e5112
Signed-off-by: Marc Schink <openocd-dev@marcschink.de>
Reviewed-on: http://openocd.zylin.com/3793
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
The current implementation is not suitable for user provided data
because it does not detect invalid inputs in many cases. For example,
the string "aa0xbb" is successfully converted to the 3 bytes: 0xaa,
0x00 and 0xbb. An other example is "aabi" which is successfully
converted to the 2 bytes: 0xaa and 0x0b. Both are obviously incorrect.
Make unhexify() robust on invalid data and use more appropriate data
types for its parameters. Also, add a small documentation for the
function.
Change-Id: Idb799beb86fc608b066c8a76365021ed44c7f890
Signed-off-by: Marc Schink <openocd-dev@marcschink.de>
Reviewed-on: http://openocd.zylin.com/3792
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Because of the cast, the const decoration on the parameter provided no
guarantee against modification since it was silently discarded.
Change-Id: Ib83ade955e1a61ee2175c690620437b5e19cbb6a
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-on: http://openocd.zylin.com/1776
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Add support for OpenRISC target. This implementation
supports the adv_debug_sys debug unit core. The mohor
dbg_if is not supported. Support for mohor TAP core
and Altera Virtual JTAG core are also provided.
Change-Id: I3b1cfab1bbb28e497c4fca6ed1bd3a4362609b72
Signed-off-by: Franck Jullien <franck.jullien@gmail.com>
Reviewed-on: http://openocd.zylin.com/1547
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
The current implementation of hexify was not correctly handling signed chars.
This function is currently used by the ti-icdi driver and as such was causing
random write issues.
As a note perhaps a better long term fix would be to change to using uint8_t
buffers rather than char. This will require changes to the ti-icdi driver
aswell.
Change-Id: I572e69ff2b99227a7d412de056458c0393794b03
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/1124
Tested-by: jenkins
Reviewed-by: Øyvind Harboe <oyvindharboe@gmail.com>
This is the new proprietary interface replacing the older FTDI based adapters.
It is currently fitted to the ek-lm4f232 and Stellaris LaunchPad.
Change-Id: I794ad79e31ff61ec8e9f49530aca9308025c0b60
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/922
Tested-by: jenkins
Interface drivers regularly need to keep track of where each part of a long
read buffer should be copied, once that data arrives. Both source and
destination are often at an arbitrary bit offset.
This queued bit-level copy can help with that, by allowing the driver to
perform postponed reads from the receive buffer already when building the
transmit buffer, and have those reads executed at a later time when data is
available.
For simplicity, it uses the linked list implementation list.h imported from
the Linux kernel.
Change-Id: I06862a0a6f057cbbcacfb021f17a795195faded2
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-on: http://openocd.zylin.com/450
Tested-by: jenkins
Reviewed-by: Xiaofan <xiaofanc@gmail.com>
Reviewed-by: Freddie Chopin <freddie.chopin@gmail.com>
Reviewed-by: Peter Stuge <peter@stuge.se>
This issue was caused by uncrustify not correctly converting the doxygen
comments.
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Change-Id: Ie6dc3b057a08603b670cb27312e5f0d989426e6c
Reviewed-on: http://openocd.zylin.com/431
Tested-by: jenkins
Also i have checked the input of this function and in many cases
a simple byte copy is possible.
I have added this check now and is it possible the buffer is
copied byte by byte and not bit by bit.
With byte boundary input the test looks like this:
buf_set_buf 0x02000000 iteration test:
runtime (seconds): old: 6.828559 new: 0.436191 diff: 6.392368
runtime (seconds): old: 6.853636 new: 0.430389 diff: 6.423247
runtime (seconds): old: 6.794985 new: 0.423065 diff: 6.371920
Without:
buf_set_buf 0x02000000 iteration test:
runtime (seconds): old: 6.370869 new: 5.552624 diff: 0.818245
runtime (seconds): old: 6.420730 new: 5.665887 diff: 0.754843
runtime (seconds): old: 6.583306 new: 5.599021 diff: 0.984285
Regards,
Mathias
Rewrite buf_cmp to use memcpy for bulk of comparison. Add static
helper to perform comparison of trailing byte, which uses another
static helper to perform a maksed comparison. The masked comparison
helper is used by the buf_cmp_mask to simplify its loop.
Improve types to use void *, unsigned, and return bool.
Purge an unused routine from the tree and remove a layering violation.
If this code is needed, it should reappear somwhere in src/jtag/,
where struct scan_field gets defined.
