On Thu, 2009-05-21 at 21:50 +0100, Wookey wrote: > +++ Wookey [2009-05-19 12:29 +0100]: > > As described on > > http://www.balloonboard.org/balloonwiki/Balloon3OpenOCD I have working > > configs for use with the balloon board and Olimex and Amontec JTAG > > dongles. I won't copy them all into this message - look at that page > > for the detailed file contents. > > > > Putting this config into openOCD itself as board support seems > > sensible. However there about a million ways of setting out these > > config files, and proper paramerisation and having info reside at the > > right levels is tricky. I partly adressed this in my pxa.cfg patch > > mail (where should the reset config and CPUTAPID live), but here are > > some other queries that arise. > > This message didn't generate quite as much discussion as I was hoping > for. I guess it may have got lost in the impressive stream of > mail/actvity on this list. > > The echo/message thing is mostly dealt with (thanx for checking in the > doc patch, zach) > > The 'noise from port defaults' I suppose needs someone to actually do > something about it. I sugest changing it so it's not a warning; the > defaults are used automatically. I think the message to that effect > should only appear at debug level 1, but maybe other disagree and it > should report ports used every time?
I like the idea for a base.cfg file, as it allows users to tweak the defaults of their installed OpenOCD. In this light, I can see us pushing default settings like this out of the C code and into TCL. More generally, I like the idea of building logical layers of TCL files, which seems to be your principle thrust here. > No-one has covered point 3: the " A" on the end issue. > or point 4) whinges about scan values and masks. There has been discussion about the " A"'s on the list, and it seems to relate to the proprietary FTD2XX libraries. This would be a nice thing to document in an "OpenOCD FTDI Interface Guide" (as proposed recently). > And no-one has said anything about the important issue I wanted to get > some feedback on: how best to split up config files. Perhaps I should just > send in a patch and see what people have to say about it? I think an opportunity exists for an architect to bring more order to the TCL files. The lack of response to your query indicates to me that no one can "whip out" a quick description for you, so you may have given this topic more recent and considered thought than others. A patch might be nice, but it might also be too concrete. I would enjoy reading a description of a process that developers could use to structure their own configuration files. Of course, it would be better to have both, so we can see both your intentions and actualizations. But best of all, you might even add said documentation as doc/manual/<apropos>.txt. I figure that writing this up should not take much effort, if you already have a plan in mind for making a patch. I suggest the doxygen manual rather than the user guide, because it seems to be the intent for OpenOCD to provide "complete" configurations that can simply be used without tinkering. Thus, their architecture and development rules seems belong in the developer manual, and I think this would be a great step forward for us. If nothing else, I hope this suggestion might spur others to consider preempting this documentary effort with the architectural plans that led us to the current status quo. If not, you will have a clean slate. Cheers, Zach > I'll leave the rest of the message in for reference/ease of reply. > > > I have top-level files for a port/dongle/interface-cabling/board > > combination like this: > > balloon3-cpu-olimex.cfg (olimex dongle, pxa jtag port, full init) > > balloon3-cpld-olimex.cfg (olimex dongle, cpld jtag port, xsvf-only init) > > and then script files for uploading code: > > loadloon.cfg (load bootloader and kernel/initrd into NOR) > > loadfpga.cfg (load FPGA image into NOR) > > loadcpld.cfg (just play xsvf file) > > > > The top-level files refer to: > > base.cfg > > <dongle>.cfg (should be stock from openOCD) > > pxa270.cfg (should be stock from openOCD, but currently isn't) > > then specify > > * a CPUTAPID > > * a reset config > > * a NOR flash device > > * initialisation of chain ready for programming > > > > Things are complicated because we have build flavours with FPGA and > > CPLD, and various dongle/interface arrangements to the CPU and > > CPLD/FPGA which sometimes chain the JTAG ports and sometimes don't. > > > > This seems to leave a choice between an awful lot of top-level files > > (one for each combo of dongle/chaining) or loads of tiny little files > > and a lot of knowledge required to know which set to select. I have > > tried to find a happy medium here, and offer these files for > > inclusion, but some of this stuff has wider implications for board > > files in general I suspect so am happy to take suggestions about how > > best to do this. > > > > I also have some questions about how things currently work. > > > > [1) done] > > > > > 2) base.cfg just specifies the default port info: > > ----- > > telnet_port 4444 > > gdb_port 3333 > > tcl_port 6666 > > ----- > > But if I don't put this in I get warning messages about how these are > > "not specified- using defaults". Is that really necessary? Shouldn't it > > just quietly use the defaults and save us all having to specify these > > in thousands of config files? If not then having this 'base.cfg' for > > such default info might be a good idea generally? > > > > 3) What's with the 'A' on the end of all the USB ft2232_device_desc > > names? > > Originally I had to change the Olimex.cfg file to a) have the correct > > vip_pid numbers (now correct in svn) and b) remove the A, so it > > worked. Now it seems that leaving the A in can work because OpenOCD > > strings it off and tries without it, but it still seems confusing. > > Shouldn't the config file not have this info and it gets added on and > > checked for in the strange Windows case where apparently it is needed? > > > > 4) When running correctly I get a lot of grumbling which I don't > > understand how to fix: > > tap creation outputs: > > ----- > > Info : JTAG tap: pxa270.cpu tap/device found: 0x49265013 (Manufacturer: > > 0x009, Part: 0x9265, Version: 0x4) > > Info : JTAG Tap/device matched > > ----- > > > > so that's OK, but then 'reset halt' gives: > > --------- > > Info : JTAG tap: pxa270.cpu tap/device found: 0x49265013 (Manufacturer: > > 0x009, Part: 0x9265, Version: 0x4) > > Info : JTAG Tap/device matched > > Warn : TAP pxa270.cpu: > > Warn : value captured during scan didn't pass the requested check: > > Warn : captured: 0x00 check_value: 0x02 check_mask: 0x07 > > Warn : in_handler: w/o "in_value", mismatch in SDR > > Error: JTAG error while writing DCSR > > Warn : TAP pxa270.cpu: > > Warn : value captured during scan didn't pass the requested check: > > Warn : captured: 0x00 check_value: 0x01 check_mask: 0x7F > > Warn : in_handler: w/o "in_value", mismatch in SIR > > target state: halted > > target halted in ARM state due to debug-request, current mode: Supervisor > > cpsr: 0x580000d3 pc: 0x00000000 > > MMU: disabled, D-Cache: disabled, I-Cache: disabled > > (processor reset) > > ------------ > > What are the 'requested checks' referred-to? What should I specify > > where to stop it whinging? > > > > erm. There is probably more but that'll do for now :-) > > > > I hope this stuff is useful. > > > > Wookey > > -- > > Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian > > http://wookware.org/ > > _______________________________________________ > > Openocd-development mailing list > > [email protected] > > https://lists.berlios.de/mailman/listinfo/openocd-development > Wookey _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
