All, The following patches are ready to merge to master:
3556: introduces RTOS support for uC/OS-III. Currently, only FPU-less ARM Cortex-M targets are supported. 3559: adds support for the qXfer:threads:read packet. In addition to providing a more efficient method of updating thread state, recent versions of GDB (7.11.1 and up) can also report remote thread names. 3566: support fileio operation; adds support for bridging semihosting to GDB’s File-I/O remote protocol extension. The remainder of the patches have either been withdrawn (3533), or merged into other changes (3537). Cheers, Steve On Wed, Nov 9, 2016 at 10:07 AM, Steven Stallion <[email protected]> wrote: > I have a list of change requests I’d like to see included (in order of > preference) as well: > > 3556: introduces RTOS support for uC/OS-III. Currently, only FPU-less ARM > Cortex-M targets are supported. > > 3556: support fileio operation; adds support for bridging semihosting to > GDB’s File-I/O remote protocol extension. > > 3559: adds support for the qXfer:threads:read packet. In addition to > providing a more efficient method of updating thread state, recent versions > of GDB (7.11.1 and up) can also report remote thread names. > > 3533: additional cfg for k21f MCUs; cosmetic > > 3537: permits OpenOCD to search for scripts relative to the executable on > OS X. Unfortunately a general approach is not reliable as each OS provides > independent mechanisms for determining the executable path. The mechanism > employed in this patch is similar to Windows. > > Cheers, > > Steve > > On Tue, Nov 8, 2016 at 3:49 AM, Matthias Welwarsky <[email protected]> > wrote: > >> On Friday 04 November 2016 14:51:33 Paul Fertser wrote: >> > Hi, >> > >> > I'm proposing to start active preparations to officially release the >> > next version of OpenOCD. >> > >> > It would be nice to do it as quick as reasonably so that 64-bit >> > changes can be pulled in to main branch as soon as possible (without >> > fear of breaking existing targets right before a release). >> > >> > So basically I'm proposing to merge whatever is ready for merging and >> > tag a release. Of course, it's not that simple because we need to try >> > hard to avoid regressions (users getting OpenOCD from distribution's >> > repositories expect any update to be no worse for their specific >> > usecases). >> > >> > So if you think you know about something that works in 0.9.0 but >> > doesn't work in current git HEAD, please do speak up! >> > >> > If you would like some nice and non-risky (from regressions point of >> > view) changes to be reviewed and included in 0.10.0, please say so >> > now. >> >> I would like to see the following changes merged: >> >> 3213: the negative review from Jiri Kastner IMHO is not relevant since it >> concerns ARMv8 targets, which have to be treated differently anyway. >> >> 3639: this enables multi-core debugging in AMP systems. The automatic >> detection of the access port for the embedded Cortex-M core fails too >> frequently to be useful. >> >> 3076: this is a really useful feature, but it's also a bit dangerous. I >> would >> very much like to see it merged but cannot test it with enough depth. >> If should be neutral if the "-defer-examine" option is not used, so the >> risk >> is acceptably, IMHO. There is a pending comment that I will take care of >> in >> the next few days. >> >> 2869: helpful during production testing and with little risk. I will >> upload a >> new patchset that implements the change I requested myself. >> >> 3641: I know it's an ugly hack but it fixes a regression with reset and >> SWD. >> It's not intended to stay, the whole reset procedure will be reworked in >> 3720, >> which is too risky for the current merge window. >> >> BR, >> Matthias >> >> > >> > I know it's annoying many changes are not getting prompt reviews and >> > merging, some of the changes I've sent myself are still pending >> > review, but that's how it is currently. Usually if the change attracts >> > attention from other users and developers, it gets in eventually, so >> > do not hesitate to nag everybody about everything that you believe to >> > be important. >> >> >> ------------------------------------------------------------ >> ------------------ >> Developer Access Program for Intel Xeon Phi Processors >> Access to Intel Xeon Phi processor-based developer platforms. >> With one year of Intel Parallel Studio XE. >> Training and support from Colfax. >> Order your platform today. http://sdm.link/xeonphi >> _______________________________________________ >> OpenOCD-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/openocd-devel >> > >
------------------------------------------------------------------------------
_______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
