Re: [Openocd-development] 0.3 anyone?
On Monday 21 September 2009, Øyvind Harboe wrote: Could he be repairing a bug in the driver where the driver does not track the JTAG state correctly after a srst that pulls trst? Could be; I hope he reports what's up ... :) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Some variable initialisation and typecasting patches
On Tuesday 22 September 2009, Nico Coesel wrote: I had some problems (warnings) to get OpenOCD to compile with gcc 4.x on a MIPS platform. Attached you'll the patches with the modifications required to get it to compile without warnings. I'm wondering why these didn't turn up earlier. The alignment warnings showed up on ARM too. It's not clear just disabling them is safe ... they can expose real problems, because unaligned access is not necessarily going to work. They seem to need Real Fixes, like by switching to more generic bitmap utilities (such as the ones in Linux, which also embed CPU-specific optimizations) which don't wrongly assume unaligned access is peachy. I think you must also have seen an awful lot of bogus use-before-assign warning from you compiler. Some versions of GCC are bad that way; can you switch to a newer compiler, which doesn't suffer from that bug? Also, your editor somehow mangles UTF-8 characters... like the sanity test provided by Øyvind's name. ;) - Dave Is everyone still using gcc 3.x? Or is the x86 version of gcc 4.x much more relaxed? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JTAG controllers disabled while SRST is asserted
On Tuesday 22 September 2009, michal smulski wrote: The offending code is called from this function: static int ft2232_init_ftd2xx(uint16_t vid, uint16_t pid, int more, int* try_more) And the actual function call is here: status = FT_OpenEx(openex_string, openex_flags, ftdih); I'm not quite following here. First, what's wrong? In what way does that offend, what's the failure mechanism? Second, does this happen with libftdi too, or does that behave properly? ftd2xx is a closed source library. However, openocd should not rely on any libraries to properly reset a chip since these libraries do not know what is a 'proper reset.' Openocd knows how it should reset the chip from *.tcl scripts. So I propose to add a reset after ft2232_init (or any other generic libs such as libftdi*) and before the first JTAG scan to properly reset devices on the scan chain. Again, I don't follow. What are you saying the init sequence should be? Which chip(s) should get reset when, and why? Are you referring to one of the chips on the target board? Or maybe the FT2232 chip? What OpenOCD tries to do today is first validate the scan chain defined to it using only TRST to ensure the TAPs are in a known state, one which exposes their IDCODE registers (if any) ... and if that works, it starts up without any SRST assertion, which is IMO the correct default behavior. If that fails, then jtag_init() will retry after a hard SRST assertion. Kind of unavoidable; maybe worth logging, that's kind of harsh. I don't to see a running board needlessly get reset just because OpenOCD got started. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new lpc2xxx cfg files layout
David Brownell pisze: On Tuesday 22 September 2009, Freddie Chopin wrote: +set CRYSTAL_FREQ 1200 Really? It's not possible to use these chips except with 12 MHz crystals, which is why all these target config files now specify 12 MHz? For grins, I grabbed the LPC210[123] data sheet, and it says otherwise: any fOSC in the range 1MHz .. 25MHz is fine. Which is what I'd expect: flexibility to reuse any clock on the board, or low-cost inventory, to shave system costs. Those frequency specs can go into board.cfg files ... but not target.cfg ones. I really don't know what's your point... ALL LPC2xxx files specify a frequency, and that is done in a pretty hidden way now, down at the very bottom: # flash bank lpc2000 base size 0 0 target# variant clock [calc_checksum] flash bank lpc2000 0x0 0x8000 0 0 0 lpc2000_v2 12000 calc_checksum This frequency is required for the flashing algorithms. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
