Re: [Openocd-development] Proposition of new target cfg files scheme
Hi! Currently there is no single scheme used. Some chips (like STM32) use only one generic target cfg file with (more or less accurate) default values that (more or less) suit the whole family. Other chips (like LPC from NXP) have separate cfg files for each chip. In a recent discussion (Problems with workareasize and STM32F100 (8kB of RAM)) I mentioned problems with default values of WORKAREASIZE in stm32.cfg (16kB), that made flashing chips with lower amount of RAM (16kB) really slow (~200 bytes/s) beacuse block writes are impossible then. Of course this default value could be changed to least common denominator throughout the family (4kB IIRC), but this would limit the flashing speed of chips that actually have more RAM (tests - https://lists.berlios.de/pipermail/openocd-development/2010-October/016792.html ). Therefore I propose a completely new target cfg files scheme for OpenOCD - separate cfg files for all target devices and organized directories. Something like: - target - STM32 stm32f103rb.cfg stm32f107v8.cfg stm32f100rb.cfg ... stm32.cfg // generic file - LPC17xx lpc1758.cfg lpc1768.cfg ... lpc17xx.cfg // generic file - LPC2xxx lpc2103.cfg lpc2148.cfg lpc2214.cfg ... lpc2xxx.cfg // generic file - STR7xx ... - STR9xx ... - ... and so on. The idea is to still have generic cfg files (if possible) with safe defaults (least common denominator). Chip-specific cfg files would just define right values and include generic family files. It should be possible to still use generic files alone - just like now. Main pros: - user-friendliness - there would be no need to change anything (or very little - crystal frequency) in target cfg files - low impact on current setups (only change the path to file - target/stm32.cfg - target/stm32/stm32.cfg [or sth like that]) - maximize performance - no need to limit workareasize for chips with lots of RAM Main con: - a lot of files (there are 80 stm32f's, and so on) I'm willing to prepare patch, but I'd like to hear maintainers' opinion first, as my time is limited and wasting it is not my purpose (; under target directories we should add the architecture family directories as - target - arm - STM32 stm32f103rb.cfg stm32f107v8.cfg stm32f100rb.cfg ... stm32.cfg // generic file - LPC17xx lpc1758.cfg lpc1768.cfg ... lpc17xx.cfg // generic file - LPC2xxx lpc2103.cfg lpc2148.cfg lpc2214.cfg ... lpc2xxx.cfg // generic file - STR7xx ... - STR9xx ... - ... - mips - PIC32 ... - ... Regards, Laurent Gauch http://www.amontec.com JTAGkey Generic USB JTAG Debugger / Programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposition of new target cfg files scheme
I think that you raise an excellent point here: automate this. It would be much better if we could draw up a plan to automate more of the configuration rather than organize hundreds to thousands of configuration files. What we have to day are basically a bunch of more or less tested example files. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposition of new target cfg files scheme
I think that you raise an excellent point here: automate this. It would be much better if we could draw up a plan to automate more of the configuration rather than organize hundreds to thousands of configuration files. What we have to day are basically a bunch of more or less tested example files. This will be excellent ! Also, if we are able to automate this, we will be able to autowrite a lot of specific configurations files ! Regards, Laurent Gauch http://www.amontec.com JTAGkey Generic USB JTAG Debugger / Programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposition of new target cfg files scheme
On Thu, Nov 4, 2010 at 9:17 AM, Laurent Gauch laurent.ga...@amontec.com wrote: I think that you raise an excellent point here: automate this. It would be much better if we could draw up a plan to automate more of the configuration rather than organize hundreds to thousands of configuration files. What we have to day are basically a bunch of more or less tested example files. This will be excellent ! Also, if we are able to automate this, we will be able to autowrite a lot of specific configurations files ! David outlined some good places to start writing patches. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposition of new target cfg files scheme
Laurent Gauch wrote: under target directories we should add the architecture family directories as - target - arm - STM32 stm32f103rb.cfg stm32f107v8.cfg stm32f100rb.cfg This gets quite annoying to type when specifying the target, and it makes it necessary to have lots of small files for all the variants. How about specifying a CPU variant on the commandline instead of the filename? I am thinking about a mechanism where OpenOCD reads some kind of index file, looks up the CPU variant that I passed on the commandline, and calls the generic config file where that CPU is supported, passing the variant via some variable. The generic config file can then deduce RAM size etc. using that variable, instead of splitting this in multiple small files. The index could be built automatically from the generic config files, in a way that each config file provides a list of the CPU variants that it supports. Extracting the index could be done by two ways: - at compile/install time, using a simple script - at runtime, by reading *all* config files and building the list dynamically in memory. Comments? cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposition of new target cfg files scheme
I think you're looking at a real problem here, but I'd be loathe to charge off in a particular direction here until we've had some time to let the idea mature and cool off. I'd like any design here to be at least 30% better than what we have today, i.e. noticeably better to just about anybody who runs and/or maintains OpenOCD. Also, I'd like something that is pretty close to what we want long term. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposition of new target cfg files scheme
On 2010-11-02 21:32, Øyvind Harboe wrote: I think you're looking at a real problem here, but I'd be loathe to charge off in a particular direction here until we've had some time to let the idea mature and cool off. Fine with me, but I'm affraid that this good idea may die if it will be put on hold for indeterminate period of time. I'd like any design here to be at least 30% better than what we have today, i.e. noticeably better to just about anybody who runs and/or maintains OpenOCD. This would be better for me, and for the guy who was in trouble using OpenOCD with STM32F100 [; Also, I'd like something that is pretty close to what we want long term. You'll have to tell what you want long term then... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposition of new target cfg files scheme
Also, I'd like something that is pretty close to what we want long term. You'll have to tell what you want long term then... I don't know what the answer is long term. I would, like you, like to hear thoughts from others on this. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposition of new target cfg files scheme
Main con: - a lot of files (there are 80 stm32f's, and so on) ? Since there are 80 some odd versions - could a number of these items be determined directly from the part number? Look at the ordering information from this STM32 PDF http://www.st.com/stonline/products/literature/ds/15057/stm32f102c4.pdf The 11th symbol is the FLASH size, 4=16K, 6=32K, could be generalize like this if not defined( $STMCHIPNUMBER ) then FAIL WITH ERROR endif if STMCHIPNUMBER == STM32F103C6 STM32FLASHSIZE = 32 STM32RAMSIZE=10 endif ... then later do this if not defined( $STM32FLASHSIZE) ) then FAIL with unknown STM32 chip type endif === OR this could be put into a simple table of some type. Indexed by MODEL NUMBER === -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposition of new target cfg files scheme
--- On Tue, 11/2/10, Øyvind Harboe oyvind.har...@zylin.com wrote: I don't know what the answer is long term. I would, like you, like to hear thoughts from others on this. There's a bug filed about us not reporting the memory maps correctly, with specific reference to RAM/SRAM regions. Fixing that would help make GDB behave better ... it'd use different commands to write flash vs RAM, etc. There are three parts to that problem: collecting and saving that region info, and most simply, feeding it to GDB with the rest of the mem map. My current thought is: - internal API to declare RAM/SRAM regions to later be reported to GDB (or used internally). Call that API via some Tcl script command that takes address and size, in at least some config scripts (if we must). For some chips that info is easily gotten via chip probe, instead of model-specific (and messy/error-prone) config files. For example the Stellaris chips report how much SRAM they've got in flash info, but that info could be stashed via the API and then accessed later. Other chips may need to have drivers consult tables driven by part numbers, working a bit differently from the Stellaris chips. I'm not suggesting a place the chip probing should be done; sometime during setup, obviously. THere could be a command that says allocate some of the RAM/SRAM for a work-area. I suspect the different flash drivers would want different defaults for work area sizes. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
