Hsiangkai Wang [Wed, 14 Aug 2013 06:46:58 +0000 (14:46 +0800)]
target: enhance target profiling
1. gprof uses 2-bytes as minimum bucket size.
2. As user wants to use gprof --sum to summarize multiple
profiling data files, the range MUST be the same.
Add new arguments to specify profiling range.
Change-Id: Ie7e6afa6a4d82250e2d194a0eed2b428c1479ea1 Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1572 Tested-by: jenkins Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Hsiangkai Wang [Fri, 30 Aug 2013 05:45:42 +0000 (13:45 +0800)]
target: increase the maximum number of buckets
I do not know what is the reasonable number of buckets.
If there are enough buckets, the result will be accurate.
I propose increase the maximum number of buckets to 128K.
If the size of program text section is less than 256KB, every
two bytes will be occupied by one buckets.
(The minimum size of one buckets is 2 bytes in gprof implementation.)
Change-Id: If9147743cefdc36f40f21e6dc73b9b28f28c9e1e Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1608 Tested-by: jenkins Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Anton Kolesov [Tue, 27 Aug 2013 09:38:50 +0000 (13:38 +0400)]
gdb_server: Do not set gdb_con->sync to true for new connections
In GDB connected to OpenOCD there is a command "monitor gdb_sync" which makes
next stepi command to be ignored while GDB still will get an updated target
state. This command sets gdb_connection->sync field to true to notify that stepi
should be ignored. This field is set to true for all new connection and is set
to false after first "continue" command. However if first resume command is
stepi/nexti then it will be ignored and result will confuse GDB client, it will
report that target received signal SIGINT. This patch sets this field to false
for new connections, thus stepi/nexti will work properly when it is a first
resume command.
Change-Id: I7c9ebd69c3dc35f3e316041aa99f4e9d3425c0b6 Signed-off-by: Anton Kolesov <akolesov@synopsys.com>
Reviewed-on: http://openocd.zylin.com/1587 Tested-by: jenkins Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Rewrite the target_*_buffer_default to generate as large accesses as
possible while maintaining natural alignment.
These versions are easy to extend to generate 8-byte accesses to support
64-bit targets, although it requires some conformity from all target
implementations (i.e. they need to refuse unsupported access sizes with
some defined error code, so we can try again with a smaller one).
Change-Id: I00ddcbb1d2fd33f9f8b99cb448cc93505a2421fc Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-on: http://openocd.zylin.com/1221 Tested-by: jenkins Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
The only remaining user is arm7_9 so remove it from the target API and add
it to struct arm7_9_common to support all its variants with minimal
changes. Many of the variants are likely not correct in the cache/mmu
handling when the bulk write is triggered. This patch does nothing to
change that, except for arm946e, where it was easier to do what might be
the right thing.
Change-Id: Ie73ac07507ff0936fefdb90760046cc8810ed182 Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-on: http://openocd.zylin.com/1220 Tested-by: jenkins Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Cosmin Gorgovan [Fri, 9 Aug 2013 16:52:46 +0000 (17:52 +0100)]
mini51: support for Nuvoton NuMicro Mini51 series flash memory
Adds a flash driver for Nuvoton MINI51, MINI52 and MINI54 microcontrollers.
At the moment, it only supports the erase and write operations.
These microcontrollers have a 4 / 8 / 16 KB APROM for application code and a
2 KB LDROM for bootloaders. When the MCU has booted off the APROM, the LDROM
isn't mapped in memory but can be programmed, and the other way around.
This means that the ARM core is typically rebooted for programming. After a
successful write or erase operation, it is rebooted again, using the initial
boot source.
This driver only supports programming the APROM.
This driver is a pure JTAG implementation, it doesn't use any SRAM.
I've tested it on a MINI54ZAN microcontroller using an ST-LINK/V2. With the
microcontroller running at the default clock frequency of 22.1184 MHz, speed
seems to be around 1.1 KB/s.
This patch adds a driver for the jtag_vpi server [1]. This server is
now part of the ORPSoC version 3 (OpenRISC Reference Platform SoC).
The jtag_vpi server provides an interface between OpenOCD and a simulated
core.
Hsiangkai Wang [Wed, 28 Aug 2013 02:59:29 +0000 (10:59 +0800)]
target: Remove error messages as no .get_gdb_fileio_info
If target does not support semi-hosting function, it has
no need to provide .get_gdb_fileio_info callback. OpenOCD
will use default function target_get_gdb_fileio_info_default.
The default function just return ERROR_FAIL and gdb_server
will treat every halted condition as normal halted and
return "Txx" to gdb.
Change-Id: I9ddb2be3a1145eae2ef5b712bdea89eb2e0fbc20 Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1586 Tested-by: jenkins Reviewed-by: Nemui Trinomius <nemuisan_kawausogasuki@live.jp> Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Andrey Smirnov [Tue, 20 Aug 2013 19:26:19 +0000 (12:26 -0700)]
stlink: Add workaround for intermittent FW info retrieval failure
It appears that on some host USB configurations(2012 MacBook Air)
multiple restarts of openocd tool cause the FW on STLINKv2 dongle to
go into a weird state in which it will no longer respond to
STLINK_GET_VERSION command. This patch adds code that, if said request
fails for the first time, attempts to reset the device and retry to
initialize it and obtain FW information one more time.
Change-Id: I7227fc972adb49d52ae700ad48ab9f66b2aaa72c Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Reviewed-on: http://openocd.zylin.com/1561 Tested-by: jenkins Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk> Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
This commit adds two tcl configuration files, one for the Altera
Cyclone V SoC series, and one for the SoCkit development board.
The board configuration is able to halt and resume the cpu cores,
and dump register contents etc. It has not been fully tested, however.
Unfortunately the Medium+ density and 0x436 devices have their F_SIZE register
at a different location: 0x1FF800CC instead of 0x1FF8004C. Fix this for
the 0x427 Medium+ devices and also the 0x436 devices. Furthermore, for
0x436 devices the flash size is reported as a 0 or 1 code rather than
the size in Kb. Please see RM0038 r8 or newer for an explanation, as
noted in the comments.
Paul Fertser [Wed, 17 Jul 2013 05:47:43 +0000 (09:47 +0400)]
target: clear running_alg flag after reset
After the target was reset we can be sure it's not running any
algorithm.
This fixes the following failure scenario:
On my STM32F103 board after I start the firmware and then stop and try
to "load" in gdb (before doing mon reset halt), I get
Error: timeout waiting for algorithm, a target reset is recommended
However, target reset doesn't help as the flag is still there ("Error:
Target is already running an algorithm"), so I have no choice but to
restart the OpenOCD process.
I'm not sure yet what exactly prevents load from working after my
firmware is initialised, most probably some interrupt is firing and my
handler produces a fault due to garbled RAM.
Change-Id: Idd977f2780a64d84800e3abd412cffc1ab6801b0 Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/1512 Tested-by: jenkins Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Paul Fertser [Mon, 29 Jul 2013 13:22:07 +0000 (17:22 +0400)]
mdr32fx: support for Milandr's MDR32Fx internal flash memory
This adds example config and flash driver for russian Cortex-M3
microcontroller model.
Run-time tested on MDR32F9Q2I evaluation board; the flash driver
should be compatible with MDR32F2x (Cortex-M0) too but I lack hardware
to test.
There're no status bits at all, the datasheets specifies some delays
for flash operations instead. All being in <100us range, they're hard
to violate with JTAG, I hope. There're also no flash identification
registers so the flash size and type has to be hardcoded into the
config.
The flashing is considerably complicated because the flash is split
into pages, and each page consists of 4 interleaved non-consecutive
"sectors" (on MDR32F9 only, MDR32F2 is single-sectored), so the
fastest way is to latch the page and sector address and then write
only the part that should go into the current page and current sector.
Performance testing results with adapter_khz 1000 and the chip running
on its default HSI 8MHz oscillator:
When working area is specified, a target helper algorithm is used:
wrote 131072 bytes from file testfile.bin in 3.698427s (34.609 KiB/s)
This can theoretically be sped up by ~1.4 times if the helper
algorithm is fed some kind of "loader instructions stream" to allow
sector-by-sector writing.
Pure JTAG implementation (when target memory area is not available)
flashes all the 128k memory in 49.5s.
Flashing "info" memory region is also implemented, but due to the
overlapping memory addresses (resulting in incorrect memory map
calculations for GDB) it can't be used at the same time, so OpenOCD
needs to be started this way: -c "set IMEMORY true" -f
target/mdr32f9q2i.cfg
It also can't be read/verified because it's not memory-mapped anywhere
ever, and OpenOCD NOR framework doesn't really allow to provide a
custom handler that would be used when verifying.
Change-Id: I80c0632da686d49856fdbf9e05d908846dd44316 Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/1532 Tested-by: jenkins Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Enable reading the SWO trace output via STLinkv2 dongles that support
it.
This adds an optional initialization parameter "trace" with which the user
specifies a destination file where SWO trace output is appended as it comes in
as well as the trace module's source clock rate.
STLink will be configured for a 2MHz SWO data rate (STLink's highest
supported rate) if the source clock is > 2MHz, otherwise the source
clock is used as the data rate directly.
If "trace" is specified with a usable file path, the stlink_usb driver will
attempt to configure and read SWO trace data as follows:
- on _run(), the target's TPI and TMI are configured and the STLinkv2 is told
to enable tracing. Only generic ARM TPI and TMI registers are
configured, any MCU-specific settings (ex: pin routing) are the
responsibility of the target firmware. The configuration applied is
based on the STLinkv2's capabilities (UART emulation).
- on _v2_get_status(), the trace data (if any) is fetched from the
STLink after the target status is checked and the target is found to
be running.
- on _halt(), the STLink is told to disable tracing.
When fetching trace data, the entire trace frame is written to the output file
and that data is flushed. An external tool may be used to parse the
trace data into a more human-readable format.
Tested on ARM Cortex M4F and M3 MCUs (STM32F407 and STM32L152).
Change-Id: Ic3983d46c82ba77010c23b0e18ce7b275d917f12 Signed-off-by: Andrey Yurovsky <yurovsky@gmail.com>
Reviewed-on: http://openocd.zylin.com/1524 Tested-by: jenkins Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk> Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Hsiangkai Wang [Thu, 11 Jul 2013 02:44:59 +0000 (10:44 +0800)]
gdb_server: check target before executing event callback
As debugging multi-targets, every target has its own gdb connection.
If there are two connections, gdb_target_callback_event_handler will
be registered twice. Everytime event occurs, the registered callback
will be executed twice. If both targets are running, as user issues
ctrl-c in one gdb client, both connections will send "stop reply" to
GDB clients even TARGET_EVENT_GDB_HALT is caused by one of them.
The commit fix above problem as debugging multi-targets.
Change-Id: I1e12d4846927d7dcf1e3bb9aeb1affabc80df813 Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1501 Tested-by: jenkins Reviewed-by: Sergey Borshch <sb-sf@users.sourceforge.net> Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Hsiangkai Wang [Wed, 6 Mar 2013 01:39:52 +0000 (09:39 +0800)]
gdb_server: add target_debug_reason for program exit detection
Currently, there is no way to notify gdb that program has exited.
Add new target_debug_reason called DBG_REASON_EXIT to notify gdb
the condition has occured. If the debug reason is DBG_REASON_EXIT,
gdb_server will send 'W' packet to tell gdb the process has exited.
Change-Id: I7a371da292716a3e6ac4cc2c31b009a651fe047a Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1242 Tested-by: jenkins Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Hsiangkai Wang [Wed, 2 Jan 2013 04:02:00 +0000 (12:02 +0800)]
gdb_server: support File-I/O Remote Protocol Extension
The File I/O remote protocol extension allows the target to use the
host's file system and console I/O to perform various system calls.
To use the function, targets need to prepare two callback functions:
* get_gdb_finish_info: to get file I/O parameters from target
* gdb_fileio_end: pass file I/O response to target
As target is halted, gdb_server will try to get file-I/O information
from target through target_get_gdb_fileio_info(). If the callback function
returns ERROR_OK, gdb_server will initiate a file-I/O request to gdb.
After gdb finishes system call, gdb will pass response of the system call
to target through target_gdb_fileio_end() and continue to run(continue or step).
To implement the function, I add a new data structure in struct target,
called struct gdb_fileio_info, to record file I/O name and parameters.
Details refer to GDB manual "File-I/O Remote Protocol Extension"
Change-Id: I7f4d45e7c9e967b6d898dc79ba01d86bc46315d3 Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1102 Tested-by: jenkins Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Hsiangkai Wang [Wed, 26 Dec 2012 11:11:03 +0000 (19:11 +0800)]
gdb server: new feature, add stop reason in stop reply packet for gdb
In GDB remote serial protocol, the stop reply packet could contain more
detail stop reason. The currently defined stop reasons are listed below.
* watch
* rwatch
* awatch
* library
* replaylog
This commit adds stop reason, watch/rwatch/awatch, in stop reply packet for
just hit watchpoint. As manual indicates, at most one stop reason should be present.
The function needs target to implement new hook, hit_watchpoint. The hook will fill
the hit watchpoint in second parameter. The information will assist gdb to locate
the watchpoint. If no such information, gdb needs to scan all watchpoints by itself.
Refer to GDB Manual, D.3 Stop Reply Packets
Change-Id: I1f70a1a9cc772e88e641b6171f1a009629a43bd1 Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1092 Tested-by: jenkins Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Hsiangkai Wang [Tue, 7 May 2013 13:43:35 +0000 (21:43 +0800)]
gdb_server: support gdb target description
* Add a parameter in .get_gdb_reg_list() to return different
register lists as generating target description.
* Modify STRUCT REG to let gdb generate target description
according to register information.
The modified structure of register is
struct reg {
const char *name;
uint32_t number; /* for regnum="num" */
struct reg_feature *feature; /* for register group feature name */
bool caller_save; /* for save-restore="yes|no" */
void *value;
bool dirty;
bool valid;
bool exist;
uint32_t size;
struct reg_data_type *reg_data_type; /* for type="type" */
const char *group; /* for group="general|float|vector" */
void *arch_info;
const struct reg_arch_type *type;
};
Change-Id: I2096b67adf94518ba0b8b23d8c6a9f64ad7932b8 Signed-off-by: Hsiangkai Wang <hsiangkai@gmail.com>
Reviewed-on: http://openocd.zylin.com/1382 Tested-by: jenkins Reviewed-by: Franck Jullien <franck.jullien@gmail.com> Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk> Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Simplify the API by making all MPSSE command functions return void instead
of an error code. If there is an error during an implicit flush in a
command call, further commands are ignored until an explicit flush is
performed. The flush function returns and clears any error code set.
The only command functions that still return an error code are those that
can fail directly based on the type of the FTDI chip, i.e. when trying to
enable RCLK or divide-by-5 on a non-high-speed chip.
Adapt the ftdi adapter driver to the new API.
Change-Id: I12979c723c81f7fd022c25821b029112f02b3f95 Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-on: http://openocd.zylin.com/1499 Tested-by: jenkins Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
The current AX_CONFIG_SUBDIR_OPTION macro assumes that $srcdir is a
relative path. If it is not, jimtcl/configure.gnu is generated such that
an out-of-tree build will fail at the configure step unless the build dir
is a sibling to the source dir.
Change the generated jimtcl/configure.gnu wrapper to use the same
`dirname $0` trick as jimtcl/configure (which itself is a wrapper around
autosetup).
Change-Id: I0fb19ae114ba37169b422b28313262f9bd83eb6f Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-on: http://openocd.zylin.com/1528 Tested-by: jenkins Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk> Reviewed-by: Xiaofan <xiaofanc@gmail.com>
Paul Fertser [Sat, 20 Jul 2013 17:39:55 +0000 (21:39 +0400)]
automake: use subdir-objects option
Automake 1.14 introduced several non-fatal warnings that should help
projects prepare to the next major automake release (2.0).
Considering the way OpenOCD automake files are written, using
subdir-objects doesn't have any adverse effects, so enable it for the
future compatibility.
Paul Fertser [Tue, 23 Jul 2013 16:15:32 +0000 (20:15 +0400)]
lpcspifi: assume flash is unprotected after probing
Since the driver doesn't support any hardware flash protection, it
doesn't make sense to report "protected" status after probing, as it
requires extra commands to unprotect before flashing and might be
confusing for the end-users.
Change-Id: I04d96790cc42412df5334951f39fb6723c972ced Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/1525 Tested-by: jenkins Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Add support for the new STM32F401 parts. These are similar to the
STM32F405/407 however they are a new Low Power variant with ID code
0x423 and have 256K of Flash. Tested with a modified F4 discovery
board.
Change-Id: Ida5fb14a0832934b4d6d1ec11e602df5076edbc8 Signed-off-by: Andrey Yurovsky <yurovsky@gmail.com>
Reviewed-on: http://openocd.zylin.com/1521 Tested-by: jenkins Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com> Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Paul Fertser [Tue, 16 Jul 2013 07:29:15 +0000 (11:29 +0400)]
etm: prevent segfault when reading bogus information
When I do not have the JTAG adapter connected to the target, I often
end up always reading 1s from the chain. If the OpenOCD is configured
to connect to an ETM-equipped target (i.MX25 ARM9 in my case), this
results in writing garbage values in the etm reg_cache as the ETM bit
fields for the comparators, counters and outputs are wider than the
amount of entries in the corresponding arrays. This later results in a
segfault in the first etm_reg_lookup() call.
Change-Id: Ied81fdbf3a53a3dd749e2e5e97adf86c012df575 Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/1505 Tested-by: jenkins Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
mips32_pracc: jump to 0xff20.0200 if cpu reads wrong addr
On some CPUs, like bcm7401 with EJTAG v2.0 we can have situation where
CPU do not stops execution. For example, all CP0 commands will have this issue.
In this case we should some hove recover our session. Currently
jump to 0xff20.0200 seems to be good option. If it brake some thing on
newer EJTAG, then check for EJTAG v2.0 should be added.
This image has been re-compiled with SDCC 3.3.0 and achieves slightly better
performance (50-100 Byte/s for STM32F103 flash write) due to new/improved
compiler optimizations.
Successfully tested with ULINK probe and STM32F103 (debug, erase and write
flash).
Change-Id: I4329aa42f50461fa3719fd63d0054d8e86982727 Signed-off-by: Martin Schmölzer <martin.schmoelzer@student.tuwien.ac.at>
Reviewed-on: http://openocd.zylin.com/1486 Tested-by: jenkins Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
OpenULINK firmware: change .lnk file extension to .lk in "make clean"
Recent versions of SDCC generate .lk files instead of .lnk - change the
OpenULINK Makefile "clean" target and top level .gitignore file to reflect
this.
Change-Id: I36f38638b712b962498c69c362f123378e1aa045 Signed-off-by: Martin Schmölzer <martin.schmoelzer@student.tuwien.ac.at>
Reviewed-on: http://openocd.zylin.com/1485 Tested-by: jenkins Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
ULINK driver and OpenULINK firmware: whitespace and comment fixes (trivial)
In commit de0130a0aad83c1ef692ee4d68ab996a8668424d, some doxygen documentation
blocks of the form "///< ..." (documentation after member) got changed to
"/* /< ...", which is not recognized by doxygen. This commit changes them to
the correct form "/**< ...".
Also, remove some leading whitespace characters and fix alignment of comment
blocks where appropriate.
Change-Id: I73a5cf55753722fa0e1d6551f05c47ee88172f0f Signed-off-by: Martin Schmölzer <martin.schmoelzer@student.tuwien.ac.at>
Reviewed-on: http://openocd.zylin.com/1483 Tested-by: jenkins Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
OpenULINK firmware: fix name of USB Jump Table symbol
Fix a case mistake in the name of the USB Jump Table ("USB_jump_table"
vs. "USB_Jump_Table") which led to an assembler error when attempting
to build the firmware with recent SDCC versions, because the assembler
now treats symbol names as case-sensitive.
Successfully tested with ULINK probe and STM32F103 (debug, erase and write
flash).
Change-Id: I979667b9130efcdccc3ac73269c38f06e0590048 Signed-off-by: Martin Schmölzer <martin.schmoelzer@student.tuwien.ac.at>
Reviewed-on: http://openocd.zylin.com/1482 Tested-by: jenkins Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Added missing breakpoint/watchpoint implementation to dsp563xx target.
Implementation is not yet complete, which means it does not leverage all
available features of the once debug interface.
This does NOT use the openocd breakpoint/watchpoint command because of
the "special" memory address spaces (X/Y/P/L) of the 56k DSP series.
Change-Id: I6840a3ff1e6fdebb38ab7758f164886aff773af6 Signed-off-by: Bernhard Kiesbauer <bernhard@kiesbauer.com>
Reviewed-on: http://openocd.zylin.com/1468 Tested-by: jenkins Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Marek Vasut [Fri, 28 Jun 2013 00:27:07 +0000 (02:27 +0200)]
target: Pull out the jtag_rtck from iMX5x files
Pull the jtag_rtck setting from imx51.cfg and imx53.cfg . Since
not all boards using these CPUs do support RTCK signal, move the
configuration of RTCK into board files.
Change-Id: I632c5d38e00ada8779a451cd26428fd122452001 Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Reviewed-on: http://openocd.zylin.com/1460 Tested-by: jenkins Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
flash/stm32*: Sync all device/rev IDs with reference manuals
Uppercase device/family names and change them to be more specific and
consistent across all STM32 families.
High-density STM32F10x has a Rev Y according to RM0008 Rev 14, so add
it.
I have a STM32F30x Rev Y, sitting on my desk, but it isn't described in
the reference manual. Add it as well.
Split the STM32L1xx Medium+ Density devices based on ID, to match the
reference manual. If I read it correctly, the Medium+ devices have
different revision mappings depending on their package/device ID. I have
no real devices to examine, however.
Change-Id: I5b95e5fa3cdeba219aa96838ea06ec1bb62bd921 Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-on: http://openocd.zylin.com/1497 Tested-by: jenkins Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Paul Fertser [Mon, 8 Jul 2013 06:10:19 +0000 (10:10 +0400)]
oocd_trace: fix warnings
gcc (Gentoo Hardened 4.6.3 p1.13) produces a warning about the variable
assigned but not used. write() can sometimes write less than the specified
count so it's marked with warn_unused_result in the system headers and its
return value can't be ignored. The most correct solution would be to have a
loop writing the buffer until all bytes are written or an error is
returned but here it's impractical.
Change-Id: I75f7482e2b26fe0e6d70d34947518d3a8f0afe5c Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/1490 Reviewed-by: Laszlo Papp <lpapp@kde.org> Tested-by: jenkins Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Paul Fertser [Sat, 6 Jul 2013 07:09:44 +0000 (11:09 +0400)]
aice: fix FTBFS on ARM
This fixes a bunch of errors like this:
aice_usb.c: In function 'aice_pack_htdc':
aice_usb.c:63:4: error: cast increases required alignment of target type [-Werror=cast-align]
Compile-tested only.
I think this can be seen as another justification for an ARM Jenkins
build target.
Also, the aice code I've seen so far seems to be assuming it runs on a
little-endian machine so probably there're some endianness issues
hiding. Hsiangkai, please get an old PowerPC Mac (or at least some
fast usb-equipped MIPS SOHO WiFi AP/router for which you can
cross-compile OpenOCD with OpenWrt) and do some real-life testing for
your code on Big-Endian. I propose it to be a requirement for any
non-trivial code submitted by a commercial entity of reasonable size.
Change-Id: I45e05257687d0020d7172b26a8666ebc1950e00c Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/1477 Tested-by: jenkins Reviewed-by: Hsiangkai Wang <hsiangkai@gmail.com> Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Paul Fertser [Wed, 3 Jul 2013 09:54:16 +0000 (13:54 +0400)]
ft2232_libftdi: perform basic configure checking when cross-compiling
When cross-compiling, current configure script fully ignores libftdi
unavailability and proceeds with LIBS having -lftdi -lusb, that
results in a non-obvious failure much later.
Try to verify libftdi is available by checking if ftdi_new function is
linkable.
Change-Id: I4f593d8ada1f38f82e7f1baa1a4b37b09619e1b4 Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/1473 Tested-by: jenkins Reviewed-by: Xiaofan <xiaofanc@gmail.com> Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
projects / openocd / log